Osiris

October 24th, 2007, 23:52

I've been working on this for about 1.5 weeks and have been stuck and getting nowhere for the last 5 days so I'm posting in hopes that someone will have a hint or maybe I'm a total newb and am overlooking something.

The software in question is uses a USB interface (the black box) to communicate with embedded systems. To use the program, a 35 character alphanumeric key is entered which tells the interface which devices it will allow communication with. This key is independant of the key which was previously in use (all required information is contained in a single key). When the key is changed, only functionality related to that single key can be used.

My objective is to determine what data these keys contain and be able to create my own.

What I've done so far:

The software does a preliminary verification on the key before sending it to the black box.

- Each character has 32 possible values

- These characters translate to a 5-bit number equivalent by lookup table

- I have recreated the lookup table, I will present keys in number form only

- The data is then XOR-encrypted with a 5-bit value, each bit is taken from a different location within the key

- If the XOR value is even, the first 4 characters must be an even value, the 5th char must be odd. The opposite is true for an odd XOR value.

- Interface serial IDs are stored as 4-6 bit decimal strings (e.g. 123 = 01 02 03), the bits are spread out among the characters

- There is a 16-bit checksum of the key, again the bits are separated and stored in different characters

- The checksum calculation algorithm is sum(char[n]) * 0x3B, interestingly it masks out the bits that contain the checksum AND another 16 bits

- I believe the unidentified 16 bits form another WORD value, possibly another checksum? When the bits are sequenced in the same order as the checksum bits, I get a value that is always a multiple of 0xFF. If it is indeed a checksum, I have no clue how to get the algorithm. My guesses haven't gotten anywhere.

So in total:

- There are 175 data bits

- I've identified 107

- There is another suspicious group of 16 that is possible a checksum

- 52 bits remaining to be ID'd

I believe the remaining bits contain 2-4 numbers, say n1 to n4. Possible values range from 0-999+. Values could represented as 4-bits or a min. 3-char, 4-bit string of the number, example from above: 123 = 01 02 03

Now, if I still make sense after all that, I have 3 valid keys that work with the hardware. I also made my own keys that pass the software check, but fail the black box check.

So here they are in number form, with corresponding known n values, and sum values (sum2 is the unknown algorithm)

These are the bit sequences for known data (my notation is char.bit, zero-based hex, bit 0 = LSB):

And lastly, the remaining bit values which I have not identified (all sequenced together in binary format):

I've tried a few operations (xor, and, or) to compare the 3 sets of unknown bits but no patterns have shown up that are apparent to me. I can't bruteforce because the USB must be unplugged/replugged to try a new key.

Any ideas?

The software in question is uses a USB interface (the black box) to communicate with embedded systems. To use the program, a 35 character alphanumeric key is entered which tells the interface which devices it will allow communication with. This key is independant of the key which was previously in use (all required information is contained in a single key). When the key is changed, only functionality related to that single key can be used.

My objective is to determine what data these keys contain and be able to create my own.

What I've done so far:

The software does a preliminary verification on the key before sending it to the black box.

- Each character has 32 possible values

- These characters translate to a 5-bit number equivalent by lookup table

- I have recreated the lookup table, I will present keys in number form only

- The data is then XOR-encrypted with a 5-bit value, each bit is taken from a different location within the key

- If the XOR value is even, the first 4 characters must be an even value, the 5th char must be odd. The opposite is true for an odd XOR value.

- Interface serial IDs are stored as 4-6 bit decimal strings (e.g. 123 = 01 02 03), the bits are spread out among the characters

- There is a 16-bit checksum of the key, again the bits are separated and stored in different characters

- The checksum calculation algorithm is sum(char[n]) * 0x3B, interestingly it masks out the bits that contain the checksum AND another 16 bits

- I believe the unidentified 16 bits form another WORD value, possibly another checksum? When the bits are sequenced in the same order as the checksum bits, I get a value that is always a multiple of 0xFF. If it is indeed a checksum, I have no clue how to get the algorithm. My guesses haven't gotten anywhere.

So in total:

- There are 175 data bits

- I've identified 107

- There is another suspicious group of 16 that is possible a checksum

- 52 bits remaining to be ID'd

I believe the remaining bits contain 2-4 numbers, say n1 to n4. Possible values range from 0-999+. Values could represented as 4-bits or a min. 3-char, 4-bit string of the number, example from above: 123 = 01 02 03

Now, if I still make sense after all that, I have 3 valid keys that work with the hardware. I also made my own keys that pass the software check, but fail the black box check.

So here they are in number form, with corresponding known n values, and sum values (sum2 is the unknown algorithm)

Code:

n1 = 8, n2 = 0, sum1 = 3629, sum2 = 12ED { 06 06 16 16 07 1E 1C 04 07 0E 06 17 0C 0A 06 0A 04 06 0C 04 06 14 15 13 07 0A 12 04 0F 0A 07 0E 01 0C 0D }

n1 = 9, n2 = 0, sum1 = 36DA, sum2 = EF1 { 0E 06 1C 1E 0F 1E 15 0D 0C 07 0E 1E 05 0B 0B 01 0C 0F 05 0B 0F 1C 1F 03 08 03 1B 0D 06 03 0A 0B 09 07 04 }

n1 = 10, n2 = 0, sum1 = 3750, sum2 = CF3 { 06 06 14 06 07 1E 1C 14 05 0E 06 17 04 00 04 08 14 0F 04 06 06 11 17 0B 01 02 16 04 0F 0A 03 06 00 0A 0D }

These are the bit sequences for known data (my notation is char.bit, zero-based hex, bit 0 = LSB):

Code:

XORVal = 10.0, 12.0, 16.0, 19.0 // For n1 = 8 key, XORVal = 0110 = 6

// These values are constant

IDString1[0] = 0.3, 1.4, 1.1, 2.4

IDString1[1] = 2.2, 3.3, 3.1, 4.4

IDString1[2] = 4.1, 5.4, 5.0, 6.3

IDString1[3] = 7.3, 8.3, 9.1, A.3

IDString1[4] = B.1, C.1, D.0, E.3

IDString1[5] = F.3, 10.2, 11.1, 12.1

IDString1[6] = 13.4, 14.3, 15.1, 16.2

IDString1[7] = 17.1, 18.0, 19.2, 1A.4

IDString1[8] = 1B.0, 1C.4, 1D.3, 1E.1

IDString1[9] = 1F.1, 20.2, 21.0, 22.3

// 6-bit chars for IDString2

IDString2[0] = 2.3, 4.2, 5.1, 6.4, 6.0, 7.2

IDString2[1] = 7.0, 7.2, 7.0, 9.4, A.1, B.1

IDString2[2] = C.2, D.4, E.4, F.4, 10.1, 11.2

IDString2[3] = 12.4, 13.0, 14.2, 15.4, 16.4, 17.2

IDString2[4] = 18.4, 19.1, 1A.0, 1B.3, 1C.0, 1D.4

IDString2[5] = 1E.3, 1F.4, 20.3, 21.3, 22.4, 22.0

// Some other 5-bit ID number, must = 3 to pass software check

nID = 18.3, 1B.3, 1D.0, 1E.0, 20.1

// 16-bit Checksum, = sum of bytes * 0x3B, doesn't sum nChkSum2 bits

nChkSum1 = 3.2, 5.2, 7.1, 9.3, A.3, D.2, F.2, 11.3, 13.2, 15.0, 17.4, 18.1, 1A.2, 1C.1, 1F.2, 21.1

// Unknown 16-bit value, possibly a checksum

nChkSum2 = 13.3, 14.1, 15.3, 16.1, 17.3, 18.2, 19.3, 1A.3, 1B.1, 1C.3, 1D.2, 1E.2, 1F.3, 20.0, 21.2, 22.1

And lastly, the remaining bit values which I have not identified (all sequenced together in binary format):

Code:

for key n1 = 8 { 0000 0010 1010 0000 0001 0010 1000 0000 0001 0100 0000 0000 0000 }

for key n1 = 9 { 0001 0110 0010 0100 0011 0010 0010 0010 0001 0000 0000 0000 0000 }

for key n1 = 10 { 0000 0100 1011 0100 0001 0000 0101 0101 0010 0000 1000 0000 0000 }

I've tried a few operations (xor, and, or) to compare the 3 sets of unknown bits but no patterns have shown up that are apparent to me. I can't bruteforce because the USB must be unplugged/replugged to try a new key.

Any ideas?