aggiornamento:

E' confermato che il quinto byte NON e' univoco.

Esempio del valore 200 in prima posizione, il quinto byte puo' essere settato a 5Eh oppure a 6Ch. In entrambi i casi e' corretto.

Inserendo un valore puramente a caso invece NON funziona. Quindi possiamo essere sicuri che l'algoritmo di check effettua il controllo.

Ciao

ciao gino
oggi mi sono scervellato tutto il giorno.. un rompicapo
ho provato con le liste trovate qui..

prendo per buona quella che inizia con

credito pos1 pos2 chk(hex)

0,05 0023 0005 9e
0,05 0005 0023 5e

ero quasi felice perchè
dal 9e (bin 10 01 11 10)
ho tolto la prima coppia (10 vuol dire che la posiz significativa è quella di dx)
rimangono 011110, in dec è 30
allora ho fatto 0023 - 0005 (in dec è 35-5) = 30! cacchio.. ho pensato che era solo una differenza. poi non quadrava con i successivi
ho provato a fare xor, nor, nand, and, or, xnor.. dei valori della mia chiavetta..

ma nulla da fare.

sono daccordo sul 5° byte, come checksum e valore. ma sono assolutamente certo che le 2 cifre vanno usate insieme
da tutte le prove che ho fatto posso dire con certezza che:

il checksum o solo i i 6 bit del 5° byte non sono frutto di somme, sottrazioni o operezioni booleane tra le 2 cifre.

non è che per caso nel 1 blocco segreto c'è un valore che va usato? dico io?

no no è tutto lì vicino al quinto byte , nulla di più, nulla di meno

capito.. cioè non guardo tutta la riga.. ho provato a fare operazioni che tengano conto dei 16 byte (eccetto il quinto)
ma non ho nulla

comunque byte 1 e 2 col 3 e 4 .. secondo te è tutto li.
però sono certo, oramai, che non basta un operazione logica.. ma c'è uno shift.

Si, ovviamente non è solo un'operazione, ma una serie di operazioni senza un vero e proprio senso logico.