Encryption used for UEI binary upgrade files (for Slingbox)

[The Robman]

Here are two diferent versions of the same upgrade, the only difference being that the second one is encrypted. Now, keep in mind that this is UEI encryption, so it's probably not rocket science. I haven't looked into this at all yet, but I have had confirmation that the 2nd one is encrypted, so as I won't get a chance to even start looking at it until tomorrow or maybe later, I thought I'd throw it out there in case one of you would like to take a crack at it first.

Here's upgrade code #1 (not encrypted)

Code: Select all

36 00 65 36 5a 00 fe fe fe 6a 80 00 05 20 1e bb 
68 04 78 b8 38 d8 58 98 18 e8 f0 70 30 f4 ec f8 
f8 f8 85 25 b5 35 f9 03 71 08 90 10 1c 9c b1 f4 
ec 34 0c f1 31 e5 da

Here's upgrade code #2 (encrypted)

Code: Select all

fc 6f c8 fc 05 6f 2e 2e 2e 09 8f 6f b0 77 f6 dd 
89 70 8d 9d 7d a5 85 95 75 a9 ab 8b 7b ac aa ad 
ad ad 50 b8 5c bc 6d 2f cb 71 93 73 76 96 5b ac 
aa 7c 72 6b bb 68 25

Here's how you read the 1st one...

1) The first byte "36" is the number of bytes if data that follow (ie, everything excluding the length byte itself)

2) The next byte is the offset of the protocol upgrade (when one is present).

3) The next 2 bytes are the "setup code". The first nibble (ie, "6") indicates that this is a DVD code. The next 3 nibbles (ie, "536") tell us that the setup code is 1334 (and the protocol id begins with "00").

4) The remainder of the code is simply an upgrade in hex format. If you have any upgrades in your remote, download the memory using IR.exe, go to the Devices tab, select one of them and click EDIT and you'll see code in exactly the same format.

This upgrade uses the NEC ($005A) protocol.

Just in case you're interested, this hex code comes from binary files that are used to load upgrades into a "Slingbox".

[The Robman]

OK, I'm 90% there. To convert the good data to the encrypted data, you need to first rotate it right 2 times, then you need to add 111 to it.

So, if the bits in the good byte are "abcdefgh", after the rotation they would be "ghabcdef".

This works for all but 7 of the good bytes. For these 7 bytes, the MSB (ie, leftmost bit) is wrong.

Here's a spreadsheet which shows all the codes, etc...
http://www.hifi-remote.com/forums/dload ... le_id=1961

If anyone can help be get the formula to work for all of the codes, I'd appreciate it.

[The Robman]

Never mind, I've got it.

In addition to the formula I mentioned before, you have to multiply bit-a with bit-h and 128, so the final formula would be (where A2 is the good byte) ...

=(mid(a2,7,2)&mid(a2,1,6)+111) + (mid(a2,1,1)*mid(a2,8,1)*128)

Now, as that will often yield a number over 255, you will also need to MOD it...

=MOD((mid(a2,7,2)&mid(a2,1,6)+111) + (mid(a2,1,1)*mid(a2,8,1)*128),256)

[Mark Pierson]

Never mind, I've got it.

[Disclaimer]This is a professional hacker on a closed circuit. Do not attempt these calculations at home!

8)

[mr_d_p_gumby]

Never mind, I've got it.

[Disclaimer]This is a professional hacker on a closed circuit. Do not attempt these calculations at home!

8)

Just when I was beginning to get excited, the legal department had to go and spoil it

[DaleMac]

If I tried those calculations at home, I think my head would explode.
Now I REALLY know why you guys are called experts.

[Nils_Ekberg]

I always love it when Rob creates a problem then does not let us have the fun of solving it.

And he did it all with Excel

Oh yeah, anybody watch that show numbers? Well Rob is the mathematicians twin

[The Robman]

I always love it when Rob creates a problem then does not let us have the fun of solving it.

And he did it all with Excel

Just pretend that you didn't read my solutions and try it yourself!

If you're curious as to how I got it, at first I was having problems with it as it didn't appear to be based on XOR's, as IR checksums usually are. Then, I compared the following two codes...

Code: Select all

***good***  **encrypted*
hex -binary hex -binary-
 00 00000000 6F 01101111
 04 00000100 70 01110000

I noticed that by just turning on bit-2 in the good binary, the encrypted binary was incremented by 1, then gave me the idea that maybe they'd just rotated the data and adding something to it, where the "something" is the decimal of the "01101111" binary. On a whim, I wrote this into a formula and tried it out and was astonished that it was right for 90% of the codes. Then, looking at the codes for which it didn't work, I noticed that bit-7 and bit-0 were both set where this wasn't the case for any of the other codes. When bit-7 was clear, it didn't matter whether bit-0 was set and the basic formula worked. When bit-7 was set and bit-0 was clear, the basic formula still worked, but when bit-0 was set, bit-7 of the result was comp'd.

[The Robman]

Just FYI, here are the Excel formulae that you can use to convert data from the JU format to the PL format, and back again. The PL "password" is 111, this will be different for other Slingboxes.

To go from JU to PL you would use the following formulae:

cell A2: contains the JU hex code
cell B2: =HEX2BIN(A2,8)
cell C2: =DEC2HEX(MOD((BIN2DEC(MID(B2,7,2)&MID(B2,1,6))+111)+(MID(B2,1,1)*MID(B2,8,1)*128),256),2)

(where cell C2 contains the result)

Then to convert the PL code back to a JU code, you would use the following formulae:

cell C2: contains the PL hex code
cell E2: =DEC2BIN(MOD(HEX2DEC(C2)+(256-111),256),8)
cell F2: =DEC2BIN(MOD(BIN2DEC(E2)+(MID($E2,2,1)*MID($E2,3,1)*128),256),8)
cell G2: =BIN2HEX(MID($F2,3,6)&MID($F2,1,2),2)

(where cell G2 contains the result)

[The Robman]

I've just discovered one more twist to the encryption as I now have a larger sample of data. All of the examples that I have decrypt correctly, except for when the JU hex value is "7D". In this case the PL value is "4E" and not the "CE" value that we would have expected.

As I mentioned in the 3rd post in this thread, the MSB is flipped in certain cases, and I thought I'd found all of them, but this is another example where the MSB needs to be flipped.

I don't have enough samples at this point to come up with an ammendment to the formulae that I've already posted to handle this, so for the time being, I'm going to hard code for it.

[The Robman]

Just FYI, I eventually determined that the "7D" case mentioned earlier is a special "gotchya" that UEI put in there to try and throw us, so basically, if the encrypted code translates to 7D, you need to change it to 7F, and likewise if it translates to 7F you need to change it to 7D.

I created a spreadsheet called SBAV-decrypter where you can paste in a piece of encrypted code and it will generate the un-encrypted (JU) code *and* it will calculate the "password" (ie, the 111 code mentioned earlier).

http://www.hifi-remote.com/forums/dload ... le_id=3318