PPCGeeks - *Exclusive* XIP Extractor v1.0

PPCGeeks (http://forum.ppcgeeks.com/index.php)

- HTC Titan (http://forum.ppcgeeks.com/forumdisplay.php?f=44)

- - *Exclusive* XIP Extractor v1.0 (http://forum.ppcgeeks.com/showthread.php?t=12766)

*Exclusive* XIP Extractor v1.2

This is a small tool that will extract the XIP from a HTC payload nb file. This is based of no2chemâ€™s method. As of right now i have only tested it on carrier roms so please leave feedback and bugs.

Quote:

Originally Posted by no2chem
maybe I should do a little write-up on how to port xip. essentially:

don't dump with rommaster (manually extract the rom)
to do this, first nbsplit, then on payload...
run imgfsfromnb. write down the imgfs start location.
open os.nb.payload with hex editor. go to the imgfs start location, and delete to end. go to the beginning of the file, and search for FE 03 00 EA (unconditional branch to 00 03 FE), and find the second / last occurance. (this is the second xip).
delete everything from the beginning to just before the second branch.
save this as your xip.bin

open xipport. press dump xip.bin. move stuff around, checking the maps between the donor xip and your xip. when you're done, press realloc p, and write maps. if any area shows !!!, fix it. (usually, modify realaddress[r] in imageinfo.txt, where r is the xipregion).

technically, you might need to check the nk.exe pointer in S000 of nk.exe, but i think realloc p fixes that (maybe). if you're worried, from the old map of the xip (not from the donor, but your device), search for the rom_00 header, look at where it starts, check if it matches with the new map If it doesn't you'll have to do this: if the old start address is 8ABCDEF9, search S000 of nk.exe for F9 DE BC 8A (just an example), because of the endianess of arm. replace with new start address, be sure to reverse it as well.

once you're done, write xipout.bin, and write it to os.nb.payload at the right xip2 address (for the titan, its 3200000) (sleepy and not sure if i put the right amount of zeros, but the default is 3100000, so change the 1 to a 2.)

hopefully everything boots up after this. I've used this technique to change everything except nk.exe... which is device dependent, so you'll have to do other stuff...

http://www.airscanner.com/pubs/fogieDC11.pdf is a good reference for arm assembly opcodes

Code:

XIP Extractor v1.2



Requires .net v2

Available at the bottom of this post, and in my folder on the ftp



Version 1.2 r1

-------------

Fixed : Xipport loading bug



Version 1.2

-----------

Added : support for different xipport location

Changed : 05_OS.nb.payload is now the input file

Optimized : Fixed a double conversion to int



Version 1.1

-----------

Added : -x launches xipport (if located in the same folder) after extracting XIP

Changed : File name is now XIPExtract.exe for cli convenience 

Fixed : now -2 is default 



Version 1.0

-----------

Initial release

-f specifies the payload file

-o specifies the dump output file

-1 dumps XIP1

-2 dumps XIP2



Future Versions

---------------

* merge GetStartLoc.exe with the xipextract.exe

Many thanks to no2chem for his method, the original dev of viewimgfs and everyone else in the community devoting time, ideas, and effort towards XIP development!

Quote:

Originally Posted by zeurx (Post 132741)

Code:

XIP Extractor v1.0

Requires .net v2

Available at the bottom of this post, and in my folder on the ftp

Many thanks to no2chem for his method, the original dev of viewimgfs and everyone else in the community devoting time, ideas, and effort towards XIP development!

Cool, I haven't tested it yet, but why are there two exe files?
Also, how are you finding the IMGFS start region?

A note as well, you should rename XIP Extractor to XIPExtractor, command line tools don't work well with spaces. =p Otherwise good work!

its the second file, which is viewimgfs.c but stripted to just output the start location. and yeah i found when i was going to use it i renamed it :$. anyways a new version with the support to launch xipport when finished will be uploaded very very soon

Nice, this is similar to the method I've been using. If it reliably does what we do by hand with a hex editor then it saves a few minutes :) Any time savings is good.

just wondering what method do you use, i may incorporate it if its much different

Quote:

Originally Posted by zeurx (Post 133457)

just wondering what method do you use, i may incorporate it if its much different

How I extract XIP:

Open Winhex or xvi32
Most devices have 2 XIP sections: XIP1 & XIP2. Search for the following hex

Code:

FE 03 00 EA 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The first occurance is where XIP1 starts. It ends with the byte before the beginning of XIP2, which also starts with the hex

Code:

FE 03 00 EA 00 00 00 00 00 00 00 00 00 00 00 00 00 00

XIP2 then runs up to the beginning of the img fs, which starts with the hex values: F8 AC 2C 9D. If you have trouble finding the img fs, you can run imgfsfromnb or prepare_imgfs which will identify the offset for you.

The rom structure looks like this:
|---Header, bootloader, etc---|---XIP1---|---XIP2---|---IMGFS---|...

I take it that the start of the imgfs is the same for every htc rom? and is this the way imgfstonb uses to find the start?

as for the start location of the imgfs, do we need to take the F8 AC 2C 9D offset and - it by 0x40000? doing this will get you the same as imgfstonb. or dose these FF need to goto the XIP2

Quote:

Originally Posted by zeurx (Post 133744)

I take it that the start of the imgfs is the same for every htc rom? and is this the way imgfstonb uses to find the start?

Yes, it is the same for all.

Quote:

as for the start location of the imgfs, do we need to take the F8 AC 2C 9D offset and - it by 0x40000? doing this will get you the same as imgfstonb. or dose these FF need to goto the XIP2

I'm not sure what you're asking. The imgfs starts immediately after the XIP2. and the F8 in the F8 AC 2C 9D value is the first byte of it. There sometimes can be multiple values matching F8 AC 2C 9D, so if you are unsure if you're looking at the real start of imgfs, cross reference it with the other tools to confirm you're at the correct offset.

i have been cross referencing it and the only iv been getting the same numbers is by - 0x40000 to the offset, which puts me into padding FF's is there really that much padding in the XIP2, oh and i find like 3 instenses of F8 AC 2C 9D