Newsgroup: it.comp.sicurezza.crittografia
Titolo: SFIDA CHECKSUM!!!

Riuscite a scoprire il calcolo di questo checksum...
Io ci stņ impazzendo....
Aiutatemi vi prego, sicuramente siete + in gamba di me.
I dati essenziali sono rappresentati dai primi 5 bytes, che contengono il
credito attuale (2 bytes), il
credito precedente (2 bytes) e il checksum del credito attuale (1 byte).
Ai fini di minimizzare le operazioni di scrittura la posizione del credito
attuale puņ essere scambiato
con quella del credito precedente. Il credito precedente non partecipa al
calcolo del checksum e per
capire se il credito attuale sia contenuto nella prima coppia di bytes o
nella seconda coppia di bytes
basta guardare il checksum: se il checksum č minore di 80h allora il credito
attuale č nella prima
coppia di bytes, altrimenti č contenuto nella seconda coppia.
Esempio:
0.71  viene codificato con:
00 65 00 47 8a
essendo il checksum in questo caso >80h il credito attuale č 00 47 che in
decimale č 71 cent.
Il problema da risolvere consiste nello scoprire l'algoritmo che permette di
calcolare il checksum sulla
base di un credito attuale arbitrario, impostabile a piacere nella prima o
nella seconda coppia di
bytes.
Questi alcuni log:
0.01     00 1f 00 01 b2
0.06     00 06 00 01 5d
0.12     00 0c 00 2f 46
0.13     00 2b 00 0d b4
0.16     00 06 00 10 a9
0.39     00 4b 00 27 89
0.45     00 2d 00 4b 52
0.71     00 65 00 47 8a
1.30     00 a6 00 82 92
1.46     00 92 00 ba 7b
1.50     00 96 00 be 57
1.66     00 a6 00 c4 58
1.72     00 ac 00 ca 43
1.76     00 e2 00 b0 ac
1.86     00 ba 00 b0 77
1.86     00 e2 00 ba b7
1.90     00 e2 00 be 9b
1.96     00 e2 00 c4 aa
2.07     00 cf 00 f3 43
2.06     00 ba 00 ce b1
2.26     00 e2 00 b0 51
2.90     01 22 00 be 4b
E' interessante notare come apparentemente l'algoritmo di calcolo del
checksum cambi a seconda se
si decide di scrivere il credito attuale nella prima coppia piuttosto che
nella seconda (vedi per esempio
1.86). La differenza tra i due checksum č infatti in quel caso 40h invece
dell'atteso 80h.
Dunque puņ essere sufficiente iniziare individuando l'algoritmo di prima
coppia, con un checksum che
potrą assumere valori da 0 a 7F.
E' altresģ interessante notare come il checksum 43h valga sia per 1.72 che
per 2.07 e da successive
scritture vale 43h anche per 1.40, 2.04, 2.36, 2.68 ma non per 3.00, 3.32 e
1.08, il cui checksum
rimane sconosciuto.
grazie.
jartiello

 writes:
jar> Riuscite a scoprire il calcolo di questo checksum...
jar> Io ci stò impazzendo....  Aiutatemi vi prego,
..
Hai cercato di essere preciso, ma hai usato notazioni insolite (non
precisandole) e parole inutili, poi sei stato quasi esatto,
non e` da tutti (spesso chi fa domande si sbaglia completamente).
Ma il genere di problema che descrivi (dato un campionamento di dati,
predirre l'algoritmo che li ha generati) non e` sempre banale, anzi...
e` un approccio incompleto, quindi se i dati forniti non sono *tutti*
in senso globale (metainformazioni comprese), il risultato rimane dubbio.
Similmente 1, 2, 3, ... non e` affatto detto che sia seguito da 4 (per
esempio potrebbe essere la sequenza di numeri primi o la serie di fibbonacci).
jar> I dati essenziali sono rappresentati dai primi 5 bytes,
jar> che contengono
jar> il credito attuale (2 bytes),
jar> il credito precedente (2 bytes)
i "2 byte" in notazione word  del  _numero di centesimi_
jar> e il checksum del credito attuale (1 byte).
jar> Ai fini di minimizzare le operazioni di scrittura
jar~> la posizione del credito attuale può essere scambiato^Ha
jar> con quella del credito precedente.
non dici di che operazioni di scrittura si tratta, quindi questo fine
di minimizzare mi sfugge, e` un particolare comunque non necessario.
jar> Il credito precedente non partecipa al calcolo del checksum
lo avevi gia` scritto dicendo che il checksum e` (funzione) del credito attuale
jar> e per capire se il credito attuale sia contenuto nella prima
jar> coppia di bytes o nella seconda coppia di bytes basta guardare il
jar> checksum:
jar> se il checksum è minore di 80h allora il credito attuale è nella
jar> prima coppia di bytes, altrimenti è contenuto nella seconda
jar> coppia.
o in altre parole:
il bit 7 del quinto byte indicizza la word del credito attuale
jar> Esempio: 0.71 viene codificato con:
jar> 00 65 00 47 8a
jar> essendo il checksum in questo caso >80h il credito attuale è 00
jar> 47 che in decimale è 71 cent.
guarda che  il contrario di "minore di 80h"  e`  >=80h
jar> Il problema da risolvere consiste nello scoprire l'algoritmo che
jar> permette di calcolare il checksum sulla base di un credito
jar> attuale arbitrario, impostabile a piacere nella prima o nella
jar> seconda coppia di bytes.
jar> Questi alcuni log:
...
jar> 1.72 00 ac 00 ca 43
...
jar> 1.86 00 ba 00 b0 77
jar> 1.86 00 e2 00 ba b7
...
jar> 2.07 00 cf 00 f3 43
...
jar> E' interessante notare come apparentemente l'algoritmo di calcolo
jar> del checksum cambi a seconda se si decide di scrivere il credito
jar> attuale nella prima coppia piuttosto che nella seconda (vedi per
jar> esempio 1.86).
No, hai ipotizzato.  77h e b7h hanno una differenza minima,
io non considero un checksum il bit 7 del quinto byte, seppure tu
chiami di checksum quell'intero byte; questa mia attenzione mi ha
permesso di notare che due bit piu` significativi sono invertiti,
e cosi` vale per tutti i byte, nel tu esempio infatti i bit 7 e 6
del quinto byte non sono mai 00 e 11, potrebbe significare che sono
stati usati 2 bit (al posto di 1) per dire che ordine avevano le word.
Rimangono 6 bit. Se e` come sembra chi ha fatto l'algoritmo non
sapeva gran che di codifica dell'informazione... (perche`
con questa ridondanza si e` dimezzato la bonta` del checksum)
jar> La differenza tra i due checksum è infatti in quel
jar> caso 40h invece dell'atteso 80h.
"Atteso" da una (tua)predizione infondata, e` evidente.
jar> Dunque può essere sufficiente
jar> iniziare individuando l'algoritmo di prima coppia,
jar> con un checksum che potrà assumere valori da 0 a 7F.
Nonostante il segnale di predizione errata hai proseguito nella tua ipotesi,
i valori che interessano sono da 0 a 3f dei bit 5 downto 0.
jar> E' altresì interessante notare come il checksum 43h valga sia per
jar> 1.72 che per 2.07
piu` che interessante e` fondamentale: 6 bit in funzione di due byte,
avra` mediamente max/64 collisioni ogni configurazione, tu ene hai
riportate solo 2 della configurazione 43h (03h se scorporata dai bit
che non centrano con una possibile funzione di checksum).
jar> e da successive scritture vale 43h anche per
jar> 1.40, 2.04, 2.36, 2.68
cioe`
1.40  = 00 8c  = 00000000  1000 1100	:-->	43
2.04  = 00 cc  = 00000000  1100 1100	:-->	43
2.36  = 00 ec  = 00000000  1110 1100	:-->	43
2.68  = 01 0c  = 00000001  0000 1100	:-->	43
se come pare non devono interessare i bit 6 e 7,
di 43h interessa quidi        0 0011
jar> ma non per 3.00, 3.32 e 1.08, il cui
jar> checksum rimane sconosciuto.
3.00  = 01 2c  = 00000001  0010 1100	:-->	?
3.32  = 01 4c  = 00000001  0010 1100	:-->	?
1.08  = 01 6c  = 00000000  0010 1100	:-->	?
Non vedo ragione perche` tu sappia che non vale 43h ma e` sconosciuto.
jar> grazie.  jartiello
ricapitolando, con l'ausilio di
perl -npe 's/(\w\w)$/sprintf("%0b",ord(pack("H*",$1)))."\t$1"/e'
o meglio
perl -npe 's{(\w\w)$}{join("",unpack("B*",pack("H*",$1)))." =\t$1"}e'
abbiamo questa tabella semplificata e arricchita della
rappresentazione binaria (anche in un ordine opportuno):
					    vv vvvv
0.01  =  00 01 = 00000000 0000 0001	10  11 0010 =	b2
0.16  =  00 10 = 00000000 0001 0000	10  10 1001 =	a9
0.06  =  00 06 = 00000000 0000 0110	01  01 1101 =	5d
1.30  =  00 82 = 00000000 1000 0010	10  01 0010 =	92
1.46  =  00 92 = 00000000 1001 0010	01  11 1011 =	7b
0.13  =  00 0d = 00000000 0000 1101	10  11 0100 =	b4
0.45  =  00 2d = 00000000 0010 1101	01  01 0010 =	52
0.39  =  00 27 = 00000000 0010 0111	10  00 1001 =	89
0.71  =  00 47 = 00000000 0100 0111	10  00 1010 =	8a
1.96  =  00 c4 = 00000000 1100 0100	10  10 1010 =	aa
1.76  =  00 b0 = 00000000 1011 0000	10  10 1100 =	ac
1.86  =  00 ba = 00000000 1011 1010	01  11 0111 =	77
1.86  =  00 ba = 00000000 1011 1010	10  11 0111 =	b7
1.66  =  00 a6 = 00000000 1010 0110	01  01 1000 =	58
1.50  =  00 96 = 00000000 1001 0100	01  01 0111 =	57
1.90  =  00 be = 00000000 1011 1110	10  01 1011 =	9b
2.06  =  00 ce = 00000000 1100 1110	10  11 0001 =	b1
2.07  =  00 cf = 00000000 1100 1111	01  00 0011 =	43
1.72  =  00 ac = 00000000 1010 1100	01  00 0011 =	43
1.40  =  00 8c = 00000000 1000 1100	01  00 0011 =	43
2.04  =  00 cc = 00000000 1100 1100	01  00 0011 =	43
2.36  =  00 ec = 00000000 1110 1100	01  00 0011 =	43
2.68  =  01 0c = 00000001 0000 1100	01  00 0011 =	43
1.08  =  01 6c = 00000000 0010 1100	:-->	? ma non 43
3.00  =  01 2c = 00000001 0010 1100	:-->	? ma non 43
3.32  =  01 4c = 00000001 0010 1100	:-->	? ma non 43
0.12  =  00 0c = 00000000 0000 1100	01  00 0110 =	46
2.90  =  01 22 = 00000001 0010 0010	01  00 1011 =	4b
2.26  =  00 e2 = 00000000 1110 0010	01  01 0001 =	51
Vedo che cambiano anche addirittura 3 bit dei 6 che interessano
a partire da solo 1 bit dei 16 di differenza (vedi casi 2.06, 2.07),
direi che siamo ben al di sotto dei dati necessari per formulare buone
ipotesi, intuisco solo grossolanamente che non sembra essere usato
l'operatore shift, ma apparantemente solo qualche xor e delle somme,
con piu` dati si capirebbe meglio.
Saluti,
MARco
-- 
La pubblicità è l'anima del commercio, solo se nessuno la vende al diavolo.
No allo spam.

 jar> Io ci stň impazzendo....  Aiutatemi vi prego,
  ^^^^
MARco, gentilmente, potresti utilizzare il segno di quote standard?
Grazie.
Ciao,
un TJL73 che ci prova con le buone...
-- 
*Istituto Nazionale per le Adozioni a Distanza*
Adotta un non quotante! Con un contributo di soli 5 post al mese
potrai aiutare un non quotante a reinserirsi nella societa`,
insegnandogli a quotare nel suo paese di origine.           -- StardustŽ

 jar> 
Mi associo alla richiesta di TJL73. Usa, per cortesia, un segno standard.
E' difficile leggere il messaggio, altrimenti.
Bye, Giubbe

 writes:
TJL73> > jar> Io ci stò impazzendo....  Aiutatemi vi prego,
TJL73> > ^^^^
TJL73> MARco, gentilmente, potresti utilizzare il segno di quote
TJL73> standard?  Grazie.
E` la seconda volta che me lo chiedi, la volta scorsa avevo sorvolato
credendo che capissi da solo, quello che uso e` il quote di
emacs/mail/supercite.el, ed e` di rispettabile antica tradizione, non
ti pare?
;; Author: 1993 Barry A. Warsaw  di 
python.org
;; Maintainer:    FSF
;; Created:       February 1993
;; Last Modified: 1993/09/22 18:58:46
;; Keywords: mail, news
Me lo indicarono al CERN.
Il mio lettore inoltre e` GNUS di emacs (v. 
http://gnus.org/
),
ed e` indubbiamente il miglior mail e news reader (in quanto
ricco di intelligenza ed estensibile in emacs-lisp).
TJL73> Ciao, un TJL73 che ci prova con le buone...
TJL73> -- 
TJL73> *Istituto Nazionale per le Adozioni a Distanza* Adotta un
TJL73> non quotante! Con un contributo di soli 5 post al mese potrai
TJL73> aiutare un non quotante a reinserirsi nella societa`,
TJL73> insegnandogli a quotare nel suo paese di origine.  -- Stardust®
Ma va la`, chi non ha quotato bene in questo post sei tu, *togliendo*
ingiustificatamente la linea in cui attribuivo a jar il riferimento
da lui usato come From, seguito da "write:".
Il mio news reader funziona, colora diversamente le righe scritte
da qualcun altro sia che sia quotato con ">" che con "alias>",
tu che news reader usi?
Impostagli la regular expression ^[A-Za-z0-9 _.-]*> anziche` solo ^>
e vedrai meglio; se non sai di cosa sto parlando peggio per te, ma non
professare "standard", se non ne sei all'altezza.
Ti diro` di piu` il mio quoting e` o dovrebbe essere riconosciuto
per distinto, non meno come tu superficialmente credi. E piuttosto
che rinunciarvi non scrivo in questo newsgroup, a quanto pare
ho solo che da perderci.
Saluti e forse addio (a seconda del ravvedimento o meno),
MARco
-- 
xref: 
http://mar.i.am/~u16746.46108/it.comp.sicurezza.crittografia/q,it
x(t),y(t) = th(3t-34.5)*e^[-(3t-34.5)^2]/2-4.3+e^(-1.8/t^2)/(.8*atg(t-
3)+2)(t-1.8)-.3th(5t-42.5),(1.4e^[-(3t-34.5)^2]+1-sgn[|t-8.5|-.5]*1.5*
|sin(pi*t)|^[2e^(-(t-11.5)^2)+.5+e^(-(.6t-3.3)^2)])/(.5+t)+1  ; 0<t<14

 writes:
TJL73> Mentre vagavo smarrito sul set di "Barbie Raperonzolo", "MARco"
TJL73> mi urto` violentemente e, per scusarsi, mi disse:
Tu, TJL73, hai _tolto_ la seguente mia linea:











e vedrai meglio; se non sai di cosa sto parlando mi dispiace, ma non
professare "standard".
Comunque visto che emerge un problema di comunicazione ci guardero`.
Saluti,


 tu che news reader usi?
Nessuno ha messo in discussione il tuo newsreader ma solo il carattere 
di quoting.
Per sapere quale newsreader viene utilizzato dagli altri frequentatori 
di Usenet ti basta vedere gli header.
Ciao e buona serata.
-- 
Achille
N.B. Antispam in mail, rimuovere il maiuscolo
e sostituire il doppio .invalid con [punto]it

 professare "standard".
Non vedo perchè io debba uniformarmi all'unica persona che usa un
simbolo di quote diverso da tutti gli altri.
Ci rivedremo al tuo prossimo nick.
Bye, Giubbe

 Comunque visto che emerge un problema di comunicazione ci guardero`.
Grazie... farò altrettanto...
Ciao,
un TJL73 che ci ha provato con le buone... senza voler imporre nulla...
-- 
"Non muoverti: voglio dimenticarti proprio come sei."
                                                       -- Henny Youngman

 con piu` dati si capirebbe meglio.
bè, hai aggiunto un tassello interessante al puzzle, ora manca il guizzo
finale per estrapolare
l'algoritmo.

puoi star certo che al 99% abbiamo la soluzione al problema
Dicevo che i dati sono quantitativamente eccessivamente di gran
lunga pochi per una crittoanalisi non standard,
non rispondermi blaterando (cioe` intuendo a vanvera)
percentuali che non conosci.
jar, dubita di piu` del tuo intuito, peche`
le *funzioni* cioe` i funzionali del tipo
	f : 16 bits -> 6 bits
Non sono infiniti, sono esattamente:
64680744183019405463588561528246236986563554245526817853728133334755\
14681718097116884204891541111439876223962897716124919955176302628242\
...(altre 1737 linee di numeri che vi risparmio)
81367707660242770247586080378604679145113103998667227141928034045056\
8615427266992333954921974481924852325586133057536
Chiamo questo numero f16to6bits.
=~= 6.468074418301941 * 10^ 118369
dai tuoi 23 campionamenti la probabilita` di trovare la funzione giusta
si ottiene con la seguente divisione:
[al numeratore c'e` l'essenza massima delle informazioni che hai portato
 con i 23 campionamenti, un numero grande, ma si vedra` non abbastanza]
   2^(23*(16+6))          2^506
 ----------------  =  ------------- =
     f16to6bit          f16to6bit
= 2.094969989053531*10^152 / 6.468074418301941*10^118369
= 3.23893921678706*10^-118218
In definitiva pur trovandola, dai tuoi dati non abbiamo il
 "99% di certezza di aver la soluzione al problema",
ma abbiamo esattamente lo 0.0000000000000000000000000000000000000000\
00000000000000000000000000000000000000000000000000000000000000000000\
(altre 1736 linee di zeri)
0000000000000000000000000000000000000000000003% di certezza di avere
la soluzione al problema.
Nota pero` che ogni campionamento in piu`
moltiplica questa percentuale per 4194304 = 2^(16+6),
(operazione che sposta la virgola di ben 6 o 7 posizioni).
Per avere un risultato certo ti occorrono altri 19703 dati, oltre questo
numero di campionamenti i campionamenti cominciano ad essere ridondanti.
QED.
E` cosi` inequivocabilmente analiticamente evidente che i 23
campionamenti non sono abbastanza per una crittoanalisi non standard.
PS: A questa incorruttibile matematica, qualcosa di soggettivo rimane:
 la semplicita`, e` soggettiva
 e visti gli errori commessi di chi ha scelto la codifica numerica
 che appare ridondante, verrebbe da presumere che non abbiano adottato
 scelte adeguate al genere di funzionali, quindi al massimo un po'
 di analisi a forza bruta esplorando metodicamente lo spazio
 funzionale piu` semplice, potrebbe trovare una soluzione semplice,
 cio` non toglie che dai dati che hai e dal tipo di problema non ne
 vale proprio l'impegno.
Queste soluzioni crittografiche (credo si tratti di offuscazione
"fai da te") sono scoraggiate dalla letteratura perche` non si
risolvono per crittoanalisi ma per reverse engineering, con scansione
dei chip dedicati.
Saluti,
MARco
-- 
xref: 
http://mar.i.am/~u16751.50043/it.c.s.crittografia/guizzofordacqua,it
