|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21246 Location: Chicago, IL |
Posted: Fri Jul 22, 2005 11:27 pm Post subject: Encryption used for UEI binary upgrade files (for Slingbox) |
|
|
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: | 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: | 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". _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Last edited by The Robman on Tue Aug 25, 2009 3:08 pm; edited 2 times in total |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21246 Location: Chicago, IL |
Posted: Sat Jul 23, 2005 4:38 pm Post subject: |
|
|
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.php?action=file&file_id=1961
If anyone can help be get the formula to work for all of the codes, I'd appreciate it. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21246 Location: Chicago, IL |
Posted: Sat Jul 23, 2005 4:55 pm Post subject: |
|
|
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) _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
Mark Pierson Expert
Joined: 03 Aug 2003 Posts: 3017 Location: Connecticut, USA |
Posted: Sat Jul 23, 2005 5:44 pm Post subject: |
|
|
The Robman wrote: | Never mind, I've got it. | [Disclaimer]This is a professional hacker on a closed circuit. Do not attempt these calculations at home!
8) _________________ Mark |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Sat Jul 23, 2005 6:27 pm Post subject: |
|
|
Mark Pierson wrote: | The Robman wrote: | 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 _________________ Mike England |
|
Back to top |
|
|
DaleMac
Joined: 29 Apr 2005 Posts: 27 Location: Brisbane, Australia |
Posted: Sat Jul 23, 2005 6:35 pm Post subject: |
|
|
If I tried those calculations at home, I think my head would explode.
Now I REALLY know why you guys are called experts. |
|
Back to top |
|
|
Nils_Ekberg Expert
Joined: 02 Aug 2003 Posts: 1689 Location: Near Albany, NY |
Posted: Sat Jul 23, 2005 7:04 pm Post subject: |
|
|
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 _________________ Nils
Files Section
Diagnosis File Section |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21246 Location: Chicago, IL |
Posted: Sat Jul 23, 2005 7:23 pm Post subject: |
|
|
Nils_Ekberg wrote: | 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: | ***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. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21246 Location: Chicago, IL |
Posted: Wed Aug 10, 2005 3:34 pm Post subject: |
|
|
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) _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Last edited by The Robman on Fri May 19, 2006 10:40 am; edited 1 time in total |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21246 Location: Chicago, IL |
Posted: Sun Aug 14, 2005 1:10 pm Post subject: |
|
|
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. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21246 Location: Chicago, IL |
Posted: Tue Aug 25, 2009 3:30 pm Post subject: |
|
|
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.php?action=file&file_id=3318 _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|