Talk:Northstar 7D11 (iPhone1,1)

Decryption of Kernelcache

Has anyone had any success decrypting the kernelcache of any of the 3.1.2 or 3.1 firmwares? Using the newest build of xpwntool, I still get thrown an error. Seems it may have to do with the compression of the kernelcache...

~/iPhone1,1_3.1.2_7D11_Restore$ xpwntool kernelcache.release.s5l8900x kernel.bin -iv 25B7F586D184C329D3D05953A6516A36 -k DD03B5B52A53D3582B18A0052EF84038
/home/admin/xpwn/ipsw-patch/img3.c:createAbstractFileFromImg3:613: 9de439b226a7982d45bb64afc9c4f9b1cf955bdcf0f4675e95be7784b3169a4a
/home/admin/xpwn/ipsw-patch/lzssfile.c:createAbstractFileFromComp:112: mismatch: 4073636 7933935 7933952 ba 8a
error: cannot open infile

--Cool name 14:28, 10 October 2009 (UTC)

until 7a341, the last block of the DATA section was not encrypted, since 7c144, it -is- encrypted, this may cause problems in xpwntool. i wrote my own tools for extracting img3 files, see this page these don't have problems extracting recent updater files Itsme 21:01, 10 October 2009 (UTC)

ahh very nice, thank you Itsme. I succeeded in using decodeimg3.pl along with lzssdec to decrypt and unpack the kernel. however, say i have patched the kernel to my liking and want to re-pack and re-encrypt it, do you have any idea how to do this? thanks. --Cool name 00:48, 11 October 2009 (UTC)

in the latest xpwntool you can add the -decrypt flag to only decrypt and not decompress the lzss part. and from there you can probably modify the lzss header to match up with what xpwntool expects. in that example the header claims there's 7933935 bytes of data once decrypted, but the lzss_decompress function is returning with 7933952 byte of data. --posixninja 17:15, 11 October 2009 (UTC)

alright, i've looked into this, and while i can just decrypt the file and see where the lzss portion starts (where it says complzss), i cannot figure out where the header claims there's 7933935 bytes of data once decrypted/uncompressed. i've googled the lzss header and tried looking in a hex editor, but nothing stands out as the value. do you know where it is exactly? --Cool name 00:46, 12 October 2009 (UTC)

decrypt:

decodeimg3 kernelcache.release.s5l8900x -iv 25B7F586D184C329D3D05953A6516A36 -k DD03B5B52A53D3582B18A0052EF84038 -o kernel.lzss

looking at the header of kernel.lzss ( the values are stored in network byte order )

00000000: "complzss"
00000008: 20 e1 90 63    - adler32
0000000c: 00 79 10 00    - uncompressed size  = 0x791000 = 7933952
00000010: 00 3e 28 a4    - compressed size    = 0x3e28a4 = 4074020-0x180

decompress:

lzssdec -o 0x180 <kernel.lzss > kernel.img

Itsme 09:42, 12 October 2009 (UTC)

guess I got it backwards. the header claims 7933952(0x791000(00 79 10 00)) bytes but it gets 7933935 bytes. the value to change should be located at offset 0x4C in a decrypted (but uncommpressed img3) btw... itsme, where did you come from? you seem to be very intelligent with this stuff, but i've never seen you before --posixninja 13:14, 12 October 2009 (UTC)

i think you get 0x790fef bytes ( just a bit less than the round nr of 0x791000) bytes because xpwntool incorrectly assumes that the last 16 bytes of the DATA section are not encrypted, giving the lzss decompressor incorrect data for the last bytes.

the last 4 byts of the kernel.lzss stream are decompressed as follows:

 DATA:     7ea3 ba8a    -> copy 3+3 bytes from a7e  then 10+3 bytes from 8ba   : total 19 bytes
 decrypted:c9ff dbff    -> copy 15+3 bytes from fc9 then 15+3 bytes from fdb   : total 36 bytes

-> when using the last 4 bytes from DATA, you end up short 36-19 bytes = 17 bytes, which is exactly 0x791000-0x790fef

... previously i was busy writing tools for windows ce devices ( http://www.xs4all.nl/~itsme/projects/xda and http://www.xda-developers.com )

Itsme 14:23, 12 October 2009 (UTC)

AES Key Usage?

alright, so now i have a new problem. i'm trying to patch the kernel for aes key usage, using the byte sequences chronic has posted on several of the pages for 3.0. i've found these byte sequences, and patched them with the values he has said. this seems to allow planetbeing's crypto util. from xpwn to work, except for that it spits back incorrect keys. anyone have any idea on this problem? --Cool name 00:34, 13 October 2009 (UTC)