Difference between revisions of "Talk:Northstar 7D11 (iPhone1,1)"

From The iPhone Wiki
Jump to: navigation, search
Line 37: Line 37:
   
 
[[User:Itsme|Itsme]] 09:42, 12 October 2009 (UTC)
 
[[User:Itsme|Itsme]] 09:42, 12 October 2009 (UTC)
  +
  +
guess I got it backwards. the header claims 7933952(0x791000(00 79 10 00)) bytes but it expects 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
  +
--[[User:Posixninja|posixninja]] 13:14, 12 October 2009 (UTC)

Revision as of 13:14, 12 October 2009

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 expects 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)