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 significant. Therefore: 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. -- http://mail.python.org/mailman/listinfo/python-list
