HELP! - Decryption challenge...

[SL4P]

I have the following data samples from a project I'm working on.
-- Where the connected device issues a challenge - and I have to return a response string.

Several sample transactions are shown below - if anyone has any ideas - or just likes a challenge...
These were taken by monitoring the conversation between the OEM controller and the device

First line (9 bytes) is the pseudo-random challenge,
Second line (6 bytes) is the response I have to generate.  I have no idea what strategy they have used - simple or complex.

 
FF A7 2B 3A 4D 9D 26 A7 4B
01 04 7E 48 CE 2D
   
FF 3A 7D 9D 3E A7 47 3A 7B
01 04 BA F4 15 36
   
FF 9D 3D 27 46 FA 7B FD 3D
01 04 4D 8E 06 D4
 
FF 17 46 E2 7B F1 3D 11 46
01 04 0A 82 60 6F
 
FF E1 7B 19 65 65 6A DB 6D
01 04 3B 53 C3 E0
 
FF 04 6E 02 37 81 1B 29 55
01 04 54 48 F7 96
 
FF 7D 72 D7 61 02 68 01 34
01 04 9F 0B 2A E8
 
FF 99 46 A5 7B 3B 65 74 6A
01 04 31 15 5F F7

[Mechanical Menace]

Is that all the data you've got? If not are all the responses in the 01 04 range?

Also how certain are you the challenge is pseudo-random? Have you worked out how the challenge is generated or at least have an idea of what are definitely not valid challenges?

[SL4P]

Yes - in this conversation - all the 'responses' start with 01 04
But that may be a red-herring --- perhaps the challenge is derived from the RTC yym ??
-- all samples have been taken in the last few days...
-- or they could be static flags (not part of the response?)

Here are two more samples I took right now  (sync & CRC bytes removed)
<- FF 52 21 A9 10 BD 50 B7 70
-> 01 04 02 4C 95 52

<- FF CC 7F E6 3F F3 1F 10 57
-> 01 04 61 02 B7 E8

[Mechanical Menace]

Yes - in this conversation - all the 'responses' start with 01 04
But that may be a red-herring --- perhaps the challenge is derived from the RTC yym ??
-- all samples have been taken in the last few days...
-- or they could be static flags (not part of the response?)

I'd guess that FF and 01 04 are both some sort of packet header. While that indeed could be a red herring it's at least a starting point. If FF is indeed an "I'm issuing you a challenge" flag you could try spoofing some incremental challenges, if they all get responses you've some nice data if they don't all get responses the ones that do will give you some sort of clue to where you need to focus your efforts on generating responses.

[Bud]

FF is a command byte telling the device to perform a specific operation, in this case do something with the 8 bytes that follow the FF.

01 04 is a response header , indicating 1 packet (or sequence number) of data 4 bytes long is returned.

The controller and device may have a shared encryption key preloaded, then the controller issues a challenge and compare the returned encrypted result from the device with what the controller calculated internally. Therefore without knowing the encryption key you cannot construct the 4 bytes in the response.

[bitwelder]

Is any of the sides sending any 'real' information (e.g. sampling values) to the other side, or is the whole system only about one side challenging the identity of the other side?

[amyk]

Your thread about meter reading didn't get enough views?

This does not look to be a trivial protocol to me, you'll need to dive in and do some more RE work.

[Mechanical Menace]

FF is a command byte telling the device to perform a specific operation, in this case do something with the 8 bytes that follow the FF.

01 04 is a response header , indicating 1 packet (or sequence number) of data 4 bytes long is returned.

Makes sense, thanks.

The controller and device may have a shared encryption key preloaded, then the controller issues a challenge and compare the returned encrypted result from the device with what the controller calculated internally. Therefore without knowing the encryption key you cannot construct the 4 bytes in the response.

Or a disassembly of the code running on either device (preferably the challenging device), if they've made a mistake in the implantation you may not need to get your hands on the keystore. It could also for speed not be using a particularly secure algorithm to begin with...

[SL4P]

I was trying to keep the initial conversation simple, but the packet header, incl. sync byte, byte clout and CRC-16 bytes have been removed... the data shown is the actual data payload of each side of the conversation.

There are no realtime samples transacted.  After a successful 'login', the host sends (similarly formatted) requests to ask for specific blocks of data, then the device returns a (similarly formatted) reply for each request.   Those packets range from a couple up to aroudn200 bytes in length.

[SL4P]

FF is a command byte telling the device to perform a specific operation, in this case do something with the 8 bytes that follow the FF.

01 04 is a response header , indicating 1 packet (or sequence number) of data 4 bytes long is returned.

Makes sense, thanks.
Seq/4-bytes... maybe...
The rest, unfortunately not true... the header, sync, byte count and CRC have already been removed in these examples.

The controller and device may have a shared encryption key preloaded, then the controller issues a challenge and compare the returned encrypted result from the device with what the controller calculated internally. Therefore without knowing the encryption key you cannot construct the 4 bytes in the response.

Or a disassembly of the code running on either device (preferably the challenging device), if they've made a mistake in the implantation you may not need to get your hands on the keystore. It could also for speed not be using a particularly secure algorithm to begin with...

I'm hoping not, and someone may recognise a pattern or technique... - sigh.

[nctnico]

Is there a PC application which can talk to the device? In the past I have had succes by using a debugger (olydbg) to step through the PC application. Recently I got lucky by using a .NET decompiler. If the answer is 4 bytes you could try to start with a CRC32 routine.

[Rerouter]

as it seems, you have to attack one end, if you can issue the same challenge more than once, that would quickly rule out a one use challenge, or some kind of time stamping,

Next up figuring out what its doing, in the past i have tried using olydbg to try and do the same for a devices serial number, but i didnt have a solid enough understanding of assembly to work out where it was starting communications via USB in that case.... kinda hoping stirng up in here might lead to a solution for us both,


Also something in my head is clicking at that data, it doesnt seem like an even number distribution, e.g. not all hex values are being used in equal amounts, it could just be due to the small data set, but its something, maybe a 4 byte address and a 4 byte time stamp sent from the computer,

[Stonent]

If you could get a .csv file with about 1000 of these challenge / response sequences, maybe we can get somewhere.

Are you trying to emulate something such as some data acquisition device connected to a main device, or are you trying to do some sort of man in the middle attack to make the device think everything is kosher when it isn't ?

[Stonent]

It sometimes helps to look at the data in more than one way.  I've converted to binary and tried aligning right and left.

Code: [Select]

FF A7 2B 3A 4D 9D 26 A7 4B 111111111010011100101011001110100100110110011101001001101010011101001011
01 04 7E 48 CE 2D 000000010000010001111110010010001100111000101101
   
FF 3A 7D 9D 3E A7 47 3A 7B 111111110011101001111101100111010011111010100111010001110011101001111011
01 04 BA F4 15 36 000000010000010010111010111101000001010100110110
   
FF 9D 3D 27 46 FA 7B FD 3D 111111111001110100111101001001110100011011111010011110111111110100111101
01 04 4D 8E 06 D4 000000010000010001001101100011100000011011010100
 
FF 17 46 E2 7B F1 3D 11 46 111111110001011101000110111000100111101111110001001111010001000101000110
01 04 0A 82 60 6F 000000010000010000001010100000100110000001101111
 
FF E1 7B 19 65 65 6A DB 6D 111111111110000101111011000110010110010101100101011010101101101101101101
01 04 3B 53 C3 E0 000000010000010000111011010100111100001111100000
 
FF 04 6E 02 37 81 1B 29 55 111111110000010001101110000000100011011110000001000110110010100101010101
01 04 54 48 F7 96 000000010000010001010100010010001111011110010110
 
FF 7D 72 D7 61 02 68 01 34 111111110111110101110010110101110110000100000010011010000000000100110100
01 04 9F 0B 2A E8 000000010000010010011111000010110010101011101000
 
FF 99 46 A5 7B 3B 65 74 6A 111111111001100101000110101001010111101100111011011001010111010001101010
01 04 31 15 5F F7 000000010000010000110001000101010101111111110111


FF A7 2B 3A 4D 9D 26 A7 4B 111111111010011100101011001110100100110110011101001001101010011101001011
01 04 7E 48 CE 2D 000000010000010001111110010010001100111000101101
   
FF 3A 7D 9D 3E A7 47 3A 7B 111111110011101001111101100111010011111010100111010001110011101001111011
01 04 BA F4 15 36 000000010000010010111010111101000001010100110110
   
FF 9D 3D 27 46 FA 7B FD 3D 111111111001110100111101001001110100011011111010011110111111110100111101
01 04 4D 8E 06 D4 000000010000010001001101100011100000011011010100
 
FF 17 46 E2 7B F1 3D 11 46 111111110001011101000110111000100111101111110001001111010001000101000110
01 04 0A 82 60 6F 000000010000010000001010100000100110000001101111
 
FF E1 7B 19 65 65 6A DB 6D 111111111110000101111011000110010110010101100101011010101101101101101101
01 04 3B 53 C3 E0 000000010000010000111011010100111100001111100000
 
FF 04 6E 02 37 81 1B 29 55 111111110000010001101110000000100011011110000001000110110010100101010101
01 04 54 48 F7 96 000000010000010001010100010010001111011110010110
 
FF 7D 72 D7 61 02 68 01 34 111111110111110101110010110101110110000100000010011010000000000100110100
01 04 9F 0B 2A E8 000000010000010010011111000010110010101011101000
 
FF 99 46 A5 7B 3B 65 74 6A 111111111001100101000110101001010111101100111011011001010111010001101010
01 04 31 15 5F F7 000000010000010000110001000101010101111111110111
Another thing to consider is the endian-ness of the chips. Is it doing LSB first or MSB first?  What processors (cpus, mcus) do you see in the device?  Some microcontrollers and cpus have hardware encryption on them.  Knowing what's in the device can at least pinpoint a few of those things. LSB vs MSB, and possibly a method of encryption assuming there is some.

[SL4P]

as it seems, you have to attack one end, if you can issue the same challenge more than once, that would quickly rule out a one use challenge, or some kind of time stamping,

Next up figuring out what its doing, in

That's a good idea...
Now that I have control of the stream format & CRC etc, I can emulate the device - and generate 'known' challenge strings to see how the OEM host software responds...

If you could get a .csv file with about 1000 of these challenge / response sequences, maybe we can get somewhere.

Are you trying to emulate something such as some data acquisition device connected to a main device, or are you trying to do some sort of man in the middle attack to make the device think everything is kosher when it isn't ?

Yes, a large number of challenge transactions is relatively easy to provide.. give me a little while...

The solution is needed to provide data reports the OEM host doesn't provide..
They sell hundreds of thousands of these units, and are not interested in a custom report.
The solution is a 'read only' application, and does not attempt to write or change the device settings...
--- ethical hacking!

[SL4P]

It sometimes helps to look at the data in more than one way.  I've converted to binary and tried aligning right and left.

snip ---- thanks for that.. I was going to get around to a binary view sooner or later!

Another thing to consider is the endian-ness of the chips. Is it doing LSB first or MSB first?  What processors (cpus, mcus) do you see in the device?  Some microcontrollers and cpus have hardware encryption on them.  Knowing what's in the device can at least pinpoint a few of those things. LSB vs MSB, and possibly a method of encryption assuming there is some.

Sadly the device has bonded security seals...
Not yet, but if other means fail,  the customer may permit me to break those, but it will need to 'important' !

[Stonent]

The FF could mean device or broadcast. In tcpip networking FF (255) is a broadcast.
01 could be  device 1. 04 could mean I'm responding back to you or an ACK

Also the date and time the data was captured in case the date or time is embedded in the challenge or response.
Does the device run a known operating system?  If it is unix based (linux, bsd, etc) it may use epoch time.  Which with the actual date and time the data was being captured, it could be used as well.

[Stonent]

It might also help to print out several challenge response sequences (make sure to number them) so you can slide the response under the challenge and see if there's anything that's always the same between the two sequences.

Those types of things may not show up in Hex but might in binary.  There could be an indication of something being repeated back as a confirmation. You could also take all the responses in binary and stack them up and look for similar consistent binary patterns.

[Stonent]

I just looked at the challenges and noticed that they aligned like this with a beginning zero.
Not sure if that has any significance.

Code: [Select]

11111111 10100111 0010101100111010 0100110110011101 0010011010100111 01001011
11111111 00111010 0111110110011101 0011111010100111 0100011100111010 01111011
11111111 10011101 0011110100100111 0100011011111010 0111101111111101 00111101
11111111 00010111 0100011011100010 0111101111110001 0011110100010001 01000110
11111111 11100001 0111101100011001 0110010101100101 0110101011011011 01101101
11111111 00000100 0110111000000010 0011011110000001 0001101100101001 01010101
11111111 01111101 0111001011010111 0110000100000010 0110100000000001 00110100
11111111 10011001 0100011010100101 0111101100111011 0110010101110100 01101010

[SL4P]

I just looked at the challenges and noticed that they aligned like this with a beginning zero.
Not sure if that has any significance.

Code: [Select]

11111111 10100111 0010101100111010 0100110110011101 0010011010100111 01001011
11111111 00111010 0111110110011101 0011111010100111 0100011100111010 01111011
11111111 10011101 0011110100100111 0100011011111010 0111101111111101 00111101
11111111 00010111 0100011011100010 0111101111110001 0011110100010001 01000110
11111111 11100001 0111101100011001 0110010101100101 0110101011011011 01101101
11111111 00000100 0110111000000010 0011011110000001 0001101100101001 01010101
11111111 01111101 0111001011010111 0110000100000010 0110100000000001 00110100
11111111 10011001 0100011010100101 0111101100111011 0110010101110100 01101010

I'm not sure I see what you're referring to in those dumps... (is it the MSb in each word is 0) ?
That could be worth noting - thanks

But the earlier idea of artificially generating challenges from a 'device' may be a lot of help to see how the OEM host software responds.

[android]

Probably nothing, but if you take the original challenges grouped by 16 bits:

Code: [Select]

FF A72B 3A4D 9D26 A74B
FF 3A7D 9D3E A747 3A7B
FF 9D3D 2746 FA7B FD3D
FF 1746 E27B F13D 1146
FF E17B 1965 656A DB6D
FF 046E 0237 811B 2955
FF 7D72 D761 0268 0134
FF 9946 A57B 3B65 746A...then convert from little endian to big endian order:

Code: [Select]

FF 2BA7 4D3A 269D 4BA7
FF 7D3A 3E9D 47A7 7B3A
FF 3D9D 4627 7BFA 3DFD
FF 4617 7BE2 3DF1 4611
FF 7BE1 6519 6A65 6DDB
FF 6E04 3702 1B81 5529
FF 727D 61D7 6802 3401
FF 4699 7BA5 653B 6A74...then it starts to look like some sort of rolling code. Shifting to make it clearer:

Code: [Select]

FF 2BA7 4D3A 269D 4BA7
FF      7D3A 3E9D 47A7 7B3A
FF           3D9D 4627 7BFA 3DFD
FF                4617 7BE2 3DF1 4611
FF                     7BE1 6519 6A65 6DDB  <-- turns brown colored from here though
FF                          6E04 3702 1B81 5529
FF                               727D 61D7 6802 3401
FF                                    4699 7BA5 653B 6A74

[amyk]

Whatever it is, there is likely XOR involved.

[SL4P]

that rolling code is quite visible - and possible, as the samples were taken - a few in a row, then a reset, or from a later session...
I'm reworking a bit of code, and while this is on the challenge side, it may give sone insight into how the response is formed & calculated.

thanks!

[Bud]

Re-writing android's finding a bit:

7D3A 3E9D 47A7
7B3A 3D9D 4627
7BFA 3DFD 4617
7BE2 3DF1 4611

the second column is a right-shifted copy of the first one by 1 bit, i.e. 7D3A/2=3E9D , etc
Not sure what the third column represents.

FF could be a 8-byte data block separator

The other 3-byte sequence

6E04 3702 1B81

each next word is right-shifted by one bit

So does not look random.

[SL4P]

I could see something - but hadn't figured it out yet.
The FF as a separator seems plausible.
I'm crunching code as well as analysing other stuff - so hopefully I'll have some more 'controlled' samples later today.

Many thanks