2 keys compared

[A543]

I disected sbingners dump of the first 2MB of his 10GB DMS and extracted the key.  I compared that with my key.  Out of 130k of data only 239 bytes were different and all of those bytes were confined to the last sector.  That would be absolute sector 2047 on the DMS.  It is possible that the only unique data that is to found in the keys will be limited to that last sector.  I still wonder if the other 129+k is executable code.

[sbingner]

do you have the offset for the beginning of the 239 different bytes?

I didn't see any ascii text before the beginning of the first partition... except for "fwZ" and that COULD be coincidence

[sbingner]

hmm, is ARM little-endian or big-endian?  Maybe we need to reverse the bit order to see things properly?

[A543]

Most likely little, but I think ARMs can use either method.

[sbingner]

I took the two signatures and compared them (the 128K of the actual signatures) this is the output of a diff of the hex dump of the two 128k.bin.hd is mine 128k-2.bin.hd is from a third party:

--- 128k.bin.hd 2005-03-18 10:15:51.917645632 -1000
+++ 128k-2.bin.hd       2005-03-18 10:16:03.330910552 -1000
@@ -7545,22 +7545,21 @@
001f5f0 4690 477f 0000 0000 0000 0000 0000 0000
001f600 0000 0000 0000 0000 0000 0000 0000 0000
*
-001fe00 0778 0000 2a0f 4a91 51aa 51a9 0459 1508
-001fe10 1006 4012 4152 6446 6445 6544 4020 14a0
-001fe20 1465 1520 5525 5120 1164 0464 1046 1116
-001fe30 8552 8440 9100 8154 2410 2110 0815 0814
-001fe40 1855 0845 0940 1904 5604 1205 4654 1244
-001fe50 0464 0564 8165 6011 6401 6450 6154 5641
-001fe60 1194 0058 5058 4459 5549 1858 4911 4064
-001fe70 1120 4465 1108 9408 8411 2145 5944 0585
-001fe80 4059 5052 6406 2515 6501 6510 6110 0604
-001fe90 5565 4042 8552 8515 1805 1581 4419 5059
-001fea0 0548 1416 4212 5061 2159 8000 0250 4215
-001feb0 1165 5448 0146 1406 9456 9110 5800 0841
-001fec0 4941 4601 5601 0650 0552 8146 9501 8011
-001fed0 9105 8454 2144 5854 4844 1240 5184 5084
-001fee0 9448 9540 1901 0201 1644 5611 5464 0049
-001fef0 0018 00a8 0000 0000 0000 0000 0000 0000
-001ff00 0000 0000 0000 0000 0000 0000 0000 0000
+001fe00 0722 0000 2a4f 2a14 46a9 42a5 4095 0520
+001fe10 4465 4120 9461 8014 5841 4125 5024 4825
+001fe20 5854 4900 4485 5091 9156 9050 9500 2050
+001fe30 0951 1911 5811 0805 4650 5591 5480 1192
+001fe40 4118 4419 2049 0650 0524 1024 5509 8118
+001fe50 2145 0549 6019 1855 5811 1215 4254 5181
+001fe60 4460 4158 5506 4452 9112 4180 0059 5512
+001fe70 9506 9141 0845 5940 0940 8109 9444 1844
+001fe80 5651 0204 2561 6115 2544 1495 0409 8546
+001fe90 2444 0164 5064 4564 0561 4912 5815 1840
+001fea0 1254 0080 8449 9140 5641 4655 1561 5064
+001feb0 4464 5164 0082 4518 1046 1402 4802 5841
+001fec0 6611 6540 1915 5900 1915 4644 4095 5595
+001fed0 5085 9484 9054 8110 9501 0644 5491 5024
+001fee0 5161 0558 6149 a000 0002 0000 0000 0000
+001fef0 0000 0000 0000 0000 0000 0000 0000 0000
*
0020000

[sbingner]

This does make me think that it is very possible that the previous code could be boot-related... it should be noted that this different code on the drive always begins at 130560 bytes (127.5K) into the 128K leaving only 256 bytes to be used before the end of the (second) cylinder (halfway through sector 2047) and the beginning of the PHATSYS partition... one signature was 233bytes long and the other was 231bytes long.  This lines right up with the average sizes of the .sig files.  I suspect we could take the rest of the data in that 128K and run their signature generation utility against it, and the drive serial number we would be able to generate the data for this area.... too bad we don't have anything to generate proper sigs

[A543]

This lines right up with the average sizes of the .sig files.

Good find.

I'd just like to point out that unlike trying to crack a public/private cypher with just a cryptic file and public key, we have a cryptic file, at least a public key (somewhere in the code, it has to be) AND the original data.  I'm not saying it's gonna be easy, but certainly more easy then if we only had two pieces.

So we really could use a decompile on that 128k of data. Anyone able to do this?

[sbingner]

That shouldn't be a matter of decompiling -- it should already be in the same format as any of the .sig files, so if we can get something that will verify a .sig file, we should be able to use it to find EXACTLY what data is being used to generate that 256bytes of code by trying different things till we get that signature to verify.

For cracking purposes, we should be able to use rc.sh and rc.sh.sig to find the private key.  I doubt that will be very easy to do

[A543]

oh, I meant the other 130k of code, not the sig part.  It might tell us what the key is based on.

[sbingner]

http://www.datarescue.com/idabase/idaarm710a.htm

There's a decompiler.... I'll try playing with it if there's a version available, but it'll probably just confuse me

[para]

Hehe, just like the old days

I'd just like to point out that unlike trying to crack a public/private cypher with just a cryptic file and public key, we have a cryptic file, at least a public key (somewhere in the code, it has to be) AND the original data

Where do we have the original data? As we assume that the last part of that data chunk contains the encrypted drive information we first need to know how it is generated (which hdd info, calculation method etc.)...