Does any one recognize this binary data storage format

Christopher Subich spam.csubich+block at
Tue Aug 9 22:04:14 CEST 2005

Dejan Rodiger wrote:
> 8003346488(10)=1DD096038(16)
> 1D D0 96 03 8
> 80 03 96 D0 1D 00
> 80 03 96 d0 fd 41 Add E041

I'm pretty sure that the last full byte is a parity check of some sort. 
  I still thing that Phone2 (..F1) is a typo and should be 41.  Even if 
it's not, it could be a more detailed parity (crc-like?) check.

If the F1/41 is a typo, the last byte is ..41 if the parity of the other 
40 bits is odd, and ..42 if the parity is even. (Since ..41 and ..42 
each have two 1s, it does not change the parity of the entire string). 
If not, Lucy has some 'splaining to do.

Taking the last byte out of ther equation entirely, 40 bytes for 10 
decimal numbers is 4 bytes / number, meaning there is some redundancy 
still in the remainder (the full 10-digit number can be expressed with 
room to spare in 36 bits).

Thinking like an 80s Mess-Dos programmer, 32-bit math is out of the 
question since the CPU doesn't support it.  Five decimal digits already 
pushes the 16-bit boundary, so thinking of using the full phone number 
or any computation is insane.

#1/#2 and #4/#5 share both the first five digits of the real phone 
number and the last 16 bits of the remaining expression.  Both pairs 
*also* share bits 5-8 (the second hex digit).

Therefore, we may possibly conclude that digits 5-10 are stored in bits 
5-8 and 21-36.  This is an even 20 of the 40 data-bits.  In fact, bits 
6-8 of all expamples given were all 0, but since I can't find an 
equivalent always-x set for the other 5 digits I'm not sure that this is 

95442 = 8c701 = 1 + c701 (?)
56168 = 0ECF4 = 0 + ecf4 (?)

I'm not coming up with a terribly useful algorithm from this, though. :/ 
  My guess is that somewhere, there's a boolean check based on whether a 
digit is >= 6 [maybe 3?] (to prevent running afoul of 16-bitness).  I'm 
also 90% sure that the first and second halves of the phone number are 
processed separately, at mostly, for the same reason.

More information about the Python-list mailing list