Hi,
I write some code that can modify the ROMs, it can save your time to add and delete files by hand.
RomMaster V2.0 Beta
Usage: RomMaster [options] imagefile
-d[m] <dfile> - delete file
replace file/module together with -a option
'm' delete module, deleting module isn't suggested
-a[c] <afile> - add file into the rom
'c' means use compress(need CECompressv4.dll)
-o <ofile> - output imagefile name
-v <0~9> - print info, 0 detail, 9 only show errors, default is 5
-w <5> - 5 is 2005, default is 2003&SE
-x - only save XIP(OS) data
-s <0x...> - Fix XIP start address(Hex)
-e <0x...> - Fix XIP end address(Hex)
In replace mode, 'c'&'m' is useless
It is now 2.0 Bata Release.
You can delete file/modules you don’t like from the ROM.
RomMaster –d “filename” –o “newROMname” “ROMname”
You can add files into the ROM.
RomMaster –a “newfilename” –o “newROMname” “ROMname”
You can replace file in the ROM
RomMaster –d “filename” –a “newfilename” –o “newROMname” “ROMname”
“newfile”’s size should be the same or small than the file you want to replace, new file will occupy the same space as the old one.
I test some ROM in my SP; include SDA, Dopod 575 & 585. I only tested one 2005 ROM. Replace module may don’t work, I am still working on it.
Before you burn the image generated by the tool, make sure you finish follow step:
1. RomMaster –o “TestROM” “SrcROM”
2. Do binary compare “SrcROM” with “TestROM”
a) If they are 100% same, I think you can safely use this tool.
b) If they are 99% same, you should be careful, make sure you only burn the OS part. Because some ROM are modified by someone before, there are maybe some useless data in the ROM, only burn the OS part won’t damage your SP.
c) Else, the “SrcROM” may contain some unknown structure or data, the “TestROM” may won’t work, don’t try burning it into you SP. If you want to modify it, tell me where I can find the ROM, if I am free, I can give some help.
3. I only tested one 2005 ROM, its structure isn’t very correct, and I think that ROM is extracted form emulation ROM. So if 2005 ROM isn’t 100% same, don’t try and be careful even they are 100% same.
This is great!!!
Going to try it!
ncruz,
I'll wait for your experience, cause if this is working we can all save space by directly burning upgraded cameras etc into the rom. will save me at least 1MB ram or storage.
The tools sounds great gmap.
There already exists MKROM tool - http://www.xs4all.nl/~itsme/projects/xda/romtools.html
it is 100% working with WM2003/2003SE devices. But it is rather inconvenient.
I'll test your "-w 5" option on a real device. Real WM5 device has one XIP kernel section with only few modules and about 1Mb free space. All other data is kept in IMGFS partition, I'm currently working on a tool that would work with it.
And one question. When you add new files to ROM, do you add them to a new XIP or extend the existing XIP? And when you delete modules, do you reuse the freed space after adding new ones?
mamaich said:
There already exists MKROM tool - http://www.xs4all.nl/~itsme/projects/xda/romtools.html
it is 100% working with WM2003/2003SE devices. But it is rather inconvenient.
I'll test your "-w 5" option on a real device. Real WM5 device has one XIP kernel section with only few modules and about 1Mb free space. All other data is kept in IMGFS partition, I'm currently working on a tool that would work with it.
And one question. When you add new files to ROM, do you add them to a new XIP or extend the existing XIP? And when you delete modules, do you reuse the freed space after adding new ones?
Click to expand...
Click to collapse
That's great if we can modify IMGFS partition I am waiting for it.
I know that tool and i don't know how it works. I made this tool only for interesting.
You can find XIP chain in 2003 ROM, by XIP chain, you can know the address and length of each XIP section. I will scan the hole XIP region before inserting the new file to reduce memory fragment. When a module is deleted, its space will be freed and reused when adding files. I freed about 6M space in my own ROM by deleteing the useless files, and add about 5M files into it, it works OK.
It seems 2005 don't have XIP chain information in the ROM, i only test one 2005 ROM, and i didn't find the XIP chain info. If your 2005 ROM don't have XIP chain info too, you should modify ROMHDR.physlast to a correct value by hand. Because if i can't find the XIP chian info, I use ROMHDR.physlast to decide the end address of XIP. Or, there are almost no space for you to add new file. My 2005 ROM physlast=0x8c253278, and only about 78732 bytes free before 0x8c253278.
I update the the tool V2.2 , fixed a bug when deeling with MDA(818) ROM.
gmap said:
That's great if we can modify IMGFS partition I am waiting for it.
Click to expand...
Click to collapse
I've PMed you a test version. I'll make it available to public later.
... If your 2005 ROM don't have XIP chain info too, you should modify ROMHDR.physlast to a correct value by hand.
Click to expand...
Click to collapse
My ROM has all needed info, I had to extract everything from rom image after 1C0000 address to a separate file and gave it to your tool. It is working perfectly. I've managed to delete and add a new file to ROM. I have not tested "-dm" option. It seems that all modules/files in XIP section of WM5 are uncompressed. I'm using BlueAngel's WM5 ROM. Later I'll try to replace boot.hv file with my own version.
Can you add a switch to your program "-s bytes" so that it woud skip the given number of bytes from file start, so it would be possible to work directly on NBA files with header?
gmap, can you tell me what file i can use this with? Is it for nbk or nba files? Thanks
I'm not able to edit the xip sextion ...
i've tried your tool on 1.60c.07CHS rom for xdaII :
RomMaster.exe -w 5 -x -o test.bin nk.nba
result :
[Info] It is a common ROM.
[Error] File is damaged, end address small than start address.
[Error] File is damaged, end address small than start address.
RomMaster.exe -w 5 -x -o test.bin imgfs_raw_data.bin (created with mamaich's tool)
result :
[Info] It is a common ROM.
[Error] Load nb00 failed.
RomMaster.exe -w 5 -x -o test.bin img.bin (created by nba part 1C0000 to end)
result :
[Info] It is a common ROM.
[Error] File is damaged, end address small than start address.
[Error] File is damaged, end address small than start address.
How to save the XIP section ?
TofClock said:
RomMaster.exe -w 5 -x -o test.bin imgfs_raw_data.bin (created with mamaich's tool)
Click to expand...
Click to collapse
This would not work. My tool works with IMGFS and you need to edit XIP
and ... how to edit XIP ?
mamaich said:
My ROM has all needed info, I had to extract everything from rom image after 1C0000 address to a separate file and gave it to your tool. It is working perfectly. I've managed to delete and add a new file to ROM. I have not tested "-dm" option. It seems that all modules/files in XIP section of WM5 are uncompressed. I'm using BlueAngel's WM5 ROM. Later I'll try to replace boot.hv file with my own version.
Can you add a switch to your program "-s bytes" so that it woud skip the given number of bytes from file start, so it would be possible to work directly on NBA files with header?
Click to expand...
Click to collapse
mamaich, or anyone else, what did you use to extract after 1C0000?
splitrom?
any help would be greatly appreciated.
Russ
Wow , just an hex-editor like winhex or edithexa
i tried that w/xvi32, and it didn't seem to work. I guess I'll try again
Thx gmap for this great tool. 8)
Recently I want to replace the TureFFS.dll at the XIP area of Wizard OS ROM.
ftp://xda:[email protected]/Uploads/HTC_Wizard/Roms/Qtek/Qtek_9100_1_6_7_ENG__OS_ONLY.zip
I type the following command and it says that it cannot replace the file.
Code:
D:\>RomMaster.exe -d TrueFFS.dll -a TrueFFS.dll -w 5 -o new.nba os.nba
[Info] It is a common ROM.
[Warning] o32_rom(0x8c268ef8)'s o32_data at 0x00000000 is zero.
[Warning] Found dif-referenced region [OLD] Address=0x8c1e1290 Length=0x00000800 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c1e1290 Length=0x00000800 ObjectType=0x00008000
[Warning] Found dif-referenced region [OLD] Address=0x8c1fe538 Length=0x00000600 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c1fe538 Length=0x00000600 ObjectType=0x00008000
[Warning] Found dif-referenced region [OLD] Address=0x8c211018 Length=0x00000a00 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c211018 Length=0x00000a00 ObjectType=0x00008000
[Warning] Memory Block(0x8c101000,0x8c1510ac) overlap with Block(0x8c10288c,0x8c1028b8).
[Error] You want to get an object whose size is 108, but it is 112. RomOffset=0x8c268e00
[Error] Could not replace 'TrueFFS.dll' with 'TrueFFS.dll'.
However, I can successfully replace the boot.hv file. Do you know why?
ahlok_hk said:
Thx gmap for this great tool. 8)
Recently I want to replace the TureFFS.dll at the XIP area of Wizard OS ROM.
ftp://xda:[email protected]/Uploads/HTC_Wizard/Roms/Qtek/Qtek_9100_1_6_7_ENG__OS_ONLY.zip
I type the following command and it says that it cannot replace the file.
Code:
D:\>RomMaster.exe -d TrueFFS.dll -a TrueFFS.dll -w 5 -o new.nba os.nba
[Info] It is a common ROM.
[Warning] o32_rom(0x8c268ef8)'s o32_data at 0x00000000 is zero.
[Warning] Found dif-referenced region [OLD] Address=0x8c1e1290 Length=0x00000800 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c1e1290 Length=0x00000800 ObjectType=0x00008000
[Warning] Found dif-referenced region [OLD] Address=0x8c1fe538 Length=0x00000600 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c1fe538 Length=0x00000600 ObjectType=0x00008000
[Warning] Found dif-referenced region [OLD] Address=0x8c211018 Length=0x00000a00 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x8c211018 Length=0x00000a00 ObjectType=0x00008000
[Warning] Memory Block(0x8c101000,0x8c1510ac) overlap with Block(0x8c10288c,0x8c1028b8).
[Error] You want to get an object whose size is 108, but it is 112. RomOffset=0x8c268e00
[Error] Could not replace 'TrueFFS.dll' with 'TrueFFS.dll'.
However, I can successfully replace the boot.hv file. Do you know why?
Click to expand...
Click to collapse
In replace mode, new file should not biger than old file. So, you should delete old 'TrueFFS.dll' first, then add the new one(You can delete some file next to 'TrueFFS.dll' to get free space or move it to a big free space, then modify the file size and related infomation of 'TrueFFS.dll' by hand to make it bigger). Replacing module isn't stable, I confused by some of the module data. If you want to replace a module, it may not work. I haven't find a way that can be used to calculate all of the data.
gmap said:
In replace mode, new file should not biger than old file. So, you should delete old 'TrueFFS.dll' first, then add the new one(You can delete some file next to 'TrueFFS.dll' to get free space or move it to a big free space, then modify the file size and related infomation of 'TrueFFS.dll' by hand to make it bigger). Replacing module isn't stable, I confused by some of the module data. If you want to replace a module, it may not work. I haven't find a way that can be used to calculate all of the data.
Click to expand...
Click to collapse
Thx for your explanation. Actually the new file is smaller than the one being replaced. And I just found that I can only delete those non-module files while all modules could not be deleted.
Thx again. Hope to see new version if you have time to find out how to calculate the data. :wink:
How can i extract a kernel file (kbbdrv.dll)?
thanks
dherrero said:
How can i extract a kernel file (kbbdrv.dll)?
thanks
Click to expand...
Click to collapse
dumprom tool
But if you'll extract this or any other XIP DLL and then readd it to the same, or any other ROM it would not work.
Hello,
I have a Apache Rom,
I would like to delete nk.exe are replace it.
iv tryed:
rommaster -w 5 -d nk.exe nk.nba
also
rommaster -w 5 -d nk.exe -a nk.exe nk.nba
keeps telling me i can delete that file.
just to let you know: if i use dumprom i get the boot partition files (containing nk.exe) and if i use imgfs i get all the os files (not containing nk.exe)
Any help would be great thanks
you cannot delete nk.exe, and you should not even need to do that.
Related
Using 'mkrom', you can create your own ROM, including your own files, using a new boot splash image, changing cold-boot registry settings to match your own taste.
Click here
Thanks for your work
Peter Poelman said:
Using 'mkrom', you can create your own ROM, including your own files
Click to expand...
Click to collapse
Can this be used to add files to a WM2003 ROM ?? Or is it very version specific. Are there tools to split out the contents of a WM2003 ROM yet ?
working on it.
dumprom can extract files from 4.x roms with the '-4' commandline option.
i tried running dumprom with -4 option and nothing is extracted for some reason.
is this the right command? dumprom nk.nbf -4 files >nkinfo.txt ?
thanks
alex
XDA developer Itsme said:
working on it.
dumprom can extract files from 4.x roms with the '-4' commandline option.
Click to expand...
Click to collapse
OK, any doc's in progress - is the ROM image well documented somewhere on the web ? Just downloaded the SDK from MS ...
A Little help please? I think I'm close to getting mkrom to work for me.
Here's the output for my mkrom command (the result is the same if I use my Nb1 or Nbf)
$ ./mkrom.sh test.nb1
write xip block starting at 81800000, with 13 files
write xip block starting at 819c0000, with 198 files
./mkrom.sh: line 69: file: command not found
316+0 records in
316+0 records out
013c0000 added mainrom
0+1 records in
1+0 records out
013d0000 added xipchain
60+0 records in
60+0 records out
017c0000 added MISC
14+1 records in
15+0 records out
018b0000 added xda1
153600+0 records in
2+1 records out
018e5800 added bitmap
1+1 records in
2+0 records out
01980000 added operator rom
16+1 records in
17+0 records out
01dc0000 added xda2
0+0 records in
0+0 records out
01ec0000 added end
rommap: 80000000-80040000, 80040000-81f00000
80000000 - 80040000 -- bootloaer 0 files 1 modules
80040000 - 8015df08 -- kernel 5 files 5 modules
80180000 - 80376ef0 -- kernel 10 files 14 modules
80380000 - 8064306c -- kernel 20 files 36 modules
80670000 - 80be66a8 -- kernel 107 files 88 modules
80c00000 - 8102ce98 -- kernel 11 files 36 modules
81050000 - 813ef114 -- kernel 95 files 44 modules
81400000 - 814019a4 -- xip chain 10 xip entries
815f0000 - 8171bc7c -- kernel 56 files 19 modules
81800000 - 818e0c14 10 XDA_DEVELOPERS1 13 files 0 modules
81900000 - 81925800 -- bitmap : 424d4858 .. f9fff9ff
81940000 - 8198b6e5 -- operator rom 20 files
819c0000 - 81de4928 11 XDA_DEVELOPERS2 198 files 0 modules
e59d3134 - e5933004 -- kernel -509550577 files -44373180
0 modules
[email protected] /cygdrive/c/perl/bin
$
It loks like there;s one error at line 69? What is that?
The process actually produces an nb1 and nbf file. When I upload the nb1 to my sd card with xdatools then into the xda it all looks good until the cold reboot. Then it comes up with a black screen(not the default xda boot.img) with the 4.00.21 and right radio stack version in the bottom right corner. It never gets past that. I upload my backup 4.00.16 and all is back to normal.
I think I'm on the brink of getting the mkrom to work. Does anybody have any suggestions? Thanks - Jim
Well, I got it to work for a 3,17 ROM now I'm looking fopr advice on the 4.x ROms. Here's the link to my post. Thanks - Jim
http://forum.xda-developers.com/viewtopic.php?t=4450&highlight=mkrom+sh
it is advisable to use a more recent version of mkrom, which can be found at http://www.xs4all.nl/~itsme/projects/xda/romtools.html
Thanks for the pointer. I'm using the scripts from there now and having a few problems. The splitrom.pl is finding an overlap in it's checkforoverlap subroutine and exiting at that point.
I kow that could be any of a thousand things but is there any one or two things it's more likely to be? Thanks - Jim
you should be able to see from the output what memory ranges overlap.
most likely it is the operator rom, or the bootsplash image.
you have to put the correct parameters in the params file.
kalex said:
is this the right command? dumprom nk.nbf -4 files >nkinfo.txt ?
Click to expand...
Click to collapse
Not with the versions I am using. Use this:
dumprom nk.nbf -4 -d files >nkinfo.txt
LD
I just can not get the default.fdf right.
I used dumprom on 4.00.xx rom. tried 05 11 16 21.
1. download the latest dumprom
2. used -4 option
3. tried both on windows and linux
but the extracted default.fdf is only about 17k large which is not right.
any hint here?
well, itsme pointed out the default.fdf should be about 17k large.. However, still get into trouble.
downloaded the romtool, use 4.00.11 rom image. followed the instruction. I could cook up a good rom without putting any files in the "files" directory. xda works fine
however, when I put in about 3M files in "files" directory. all the rest not modified, XDA won't boot up with the cooked rom. froze at the screen shows the image and the rom version and radio stack version number.
I got from the kitchen that I can put 3906k files inside this rom. is that right?
pine said:
I got from the kitchen that I can put 3906k files inside this rom. is that right?
Click to expand...
Click to collapse
This depends on the settings for mkrom.
What settings do you use?
Stefan
what kind of setting? I assume the params file
I used
wincever=4
start1=81740000
size1=00040000
start2=81b00000
size2=003c0000
startbmp=81ec0000
startop=81b00000
otherwise, I don't remember there is any place for setting. I used 4.00.11 rom, which i suppose does not include the t-mobile stuff
Hi all (sorry for my english)... First post
I dont want to seem stupid but I want to know thomething...
I've got a SPV 1G and want to know if there is also a ROMCoocker (mkrom) for Smartphone (WinCE 2k2/2k3) devices ?
Thx for your participation
Sidarus
Ping? :mrgreen:
create or rename into my own extended rom version name.. hel
can any1 help me how to create own version name for my own cooked rom? tnx! id like to customize my version into my own numbers.. tnx!
hi i have tryed to get the rom to work but just need to first 3 steps to get me on the right path :? thanks guys
Community, hey!
First of all I want to thank ITSME and all the other good contributers that has added value to the "scene".
I see that many with me needs to modify the HTC Magician ExtRom partition. In this message i want to discuss how this can be done, and eventually help implement the kind of solution needed.
I am quite new to the device, so please clearify on the bulletpoints. [ Sanitycheck / reject / comment ]
A) I see three different scenarios for changing ExtRom on Magician.
-a1- mount the extrom as disk, and modify directly on device.
-a2- modify .nb* file before flashing of the phone.
-a3- modify flashmem directly through bootloadermodus.
B) Extended ROM image for Magician has been decrypted by Itsme, so modifying .nb* file, apply encryption and flash will be a suitable way to modify Ext ROM ?
C) All that has to be done is to make a tool to modify and recrypt the .NB* file prior to flashing?
D) Is the format of the decrypted .NB* file well defined?
E) Any other "issues" i should think about?
I understand that many of these Q's probably is answerd through out the message board, but i wan't to have one focused tread that eventually ends up in someone (me?) implementing the solution in a public tool.
Regards InkDot
Does the Ext Rom of Magician allso have the same structure as described by Itsme when decrypted? - If so we can mount it as Fat16 like Qtek 2020 early days modifications?? - Please comment..
--- from itsme XDA-II flashfile formats writeup---
ms_.nbf
this file is build up as follows: 00000000 00000040 NBF header
00000040 00000028 devtype, operator, language
00008040 00025800 first bitmap
00030040 00025800 second bitmap
00070040 01000000 FAT16 filesystem
01070040 end of image
the bootsplash image is there twice, at
Short update!
It did mount as expected on linux...
now the problem is to encode it back to its original coded state..
Trying to understand doctor Itsme's perl - not easy for me.. no perl skills.. ;( If someone else has tried this, please reply with your findings..
What scares me is the "Checksum" in the header!
If it is an actual checksum of the Fat16 structure like Itsmes naming can indicate; we have a problem unless we find the checksum algo that is used.
I can allways encrypt it with the same "checksum"-variable and hope that the naming is "scam".
Please add comments.. i'm in pain
I'am using dumb method
for example.... we have ms.nbf file (encrypted) you need decrypt it at first.....
after i'am split file for two parts .... ms.header - (first 128 bytes) and other ms.main part.(section starting from header)
After that i simply opening ms.main as disk image.... copying that i need... saving ...
Yep that works!! The problem is to Encrypt it again!!
If the Magician uses a real checksum of the fat16 datapartition as the initial XOR encryption key, i must know the checksum algo used to calculate it to be able to encrypt it back... ;/
type ms.header > ms_.nba
type ms.main >> ms_.nba
xda3nbftool -c -u ms_.nba
try this
tupisdin,
Are you using xda3nbftool.exe to calculate a checksum for the Magician extended ROM ?
yes
tupisdin said:
yes
Click to expand...
Click to collapse
Good for you
1. First i split the original crypted file into two parts.
ms_.nbf ---> ms_header(172bytes) ms_fat(all the remaining bytes)
2. Then i decode the header with the modified UUEncoder routine found on the board. This gives me a good looking readable header. Now = 128bytes.
3. Now I have one "ms_header" file and one "ms_Fat16 part"
the ms_header is 128 bytes big and no longer "base64-like-encoded". It looks good!
4. Then i decode the ms_fat16 part with the new XOR routine from itsme.
5. To check that everything is ok.. i merge the files into one again, and recalculate the checksum with xda3nbftool.
Unfortunately the checksum differs from the original checksum. ;/
1 ) Where can i find the source for XDA3nbftool??
2 ) What is wrong with my procedure
3 ) Is the checksum calculated only from the Fat16 part or does it include other header data?
Regards,
InkDot
Checksum changed every time.
tupisdin said:
Checksum changed every time.
Click to expand...
Click to collapse
Hemm, i understand that the checksum changes if data is changed! But i try to merge the SAME data as i decrypted and splitted 1 minute earlier..
That should give me the same checksum (!?)
Therefor i beleve that i got wrong version of XDA3nbf tool, or or something else is wrong..
How did you decrypt the header???
xda3nbftool recalculating checksum every time.
It is not an error.
for example.
xda3nbftool -x ms_.nbf ms_.nba 0x20040522
After that open ms_.nba with your favourite hex editor cut first 128 bytes and save them to another file(ms.header).
Save another part to another file(ms.main).
no you can delete original ms_.nba
Open main part(fat virtual disk) in winimage (for example)
Add, modify what you want....
After that in command promt:
"type ms.header > ms_.nba"
"type ms.main >> ms_.nba"
Then:
xda3nbftool -c -u ms_.nba
And at last
xda3nbftool -x ms_.nba ms_.nbf 0x20040522
No you can flash your new ms_.nbf file to your device(do not forget to change operator and language id)
That's dumb and simple method.
Now i understand!
What i have learned from this is that there is ONE or more Magican operator roms that uses the old XOR technique that is decodable with Xda3nbf
And ONE or more Magican operator roms that uses the NEW encryption method.
You Tupisdin is one of the lucky ones to work with a Rom based on the old structure! Please correct me if i'm wrong.
I think that the rom you started with had an header that was not Base-64-like-encoded
Regards,
InkDot
Encryption method is changed in new ROM versions.
New NBF format described by mamaich here
http://forum.xda-developers.com/viewtopic.php?t=14877&highlight=encryption
tupisdin said:
Encryption method is changed in new ROM versions.
Click to expand...
Click to collapse
Yes, and the only thing that remains is to calculate a correct checksum for the extended rom...
To solve that we have tried to find the algorithm / method used to get the same checksum as it was in the original decrypted rom..
InkDot..
Something goes wrong?
This method perfectly works for me.
Or you are trying to encode something with new method?
As i sad checksum will be change every time when you recalculate it.
tupisdin said:
As i sad checksum will be change every time when you recalculate it.
Click to expand...
Click to collapse
1. Ofcourse CRC changes if data changes! AND therefor i try to find the right CRC algorithm using a datasource i allready know the correct CRC of! Still i cannot get back to the correct CRC, that prooves my algorithm or method wrong.
2. I need to make the extendedrom into a mountable file. To do this I could have uses XDA3NBF.exe, but it does not work with the new encryption technique.
3. I therefore decrypt it manually with Itsme's method, and get a perfectly mountable datafile. I allso do the base64 transelation of the header into a classical readable format.
4. To build a file that i can FLASH to the device i need to put an uncrypted header, and an uncrypted FAT together, and apply the correct checksum.. And then xor the data with the checksum as initial XOR password! (if you have seen the new algorithm.)
5. Unfortunately i cannot get the same CRC as the file had initially. that means that the CRC check is not served the exact same data as before.
This is a problem because the CRC value is now used as encryption password!!
Conclusion: Either i have something accidentaly wrong in my rebuildt nbf file, OR the technique for calculating data differs from the technique used in XDA3NBFTOOL.
For you, tupisdin, it means that either you have an old rom using traditional XOR encryption from Password, not CRC, or you did not manipulate the extended rom. Did you use password? Ie. the password supplied by NightMarE? (That method does not work with newer roms..)
Regards
Inkdot
for new roms i use same method....
There is only one difference.
I'am decoding ms_.nba with new algo.
change in fat part what i need.... after i'am replacing header with old one..... and use xda3nbftool and old maupgrade to update extended rom in my device
Dumb and simple
Hi, I am trying to extract a file (actually, cplmain.,cpl) from a rom image. It all seems to work fine, but the size of the extracted file is lesser than the right one.
File seems to be truncated.
I did:
1) get the "B000FF" file (.bin), 24,856,907 bytes
2) Since dumprom seems not to "like" this format, I converted it using splitrom:
perl splirom.pl file.bin -wo file.rom
3) I don't know which format it generates to file to, but now dumprom works:
dumprom -d result file.rom > res.txt
4) A few snapshots of the file res.txt, regarding the file cplmain.cpl:
NOTE: section at fee73000 iso 00044000 for cplmain.cpl
806f5fe4 - 806f5ff0 L0000000c modname cplmain.cpl
8072d000 - 8076fe1c L00042e1c o32 region_0 rva=00001000 vsize=00042e1c real=02e61000 psize=00043000 f=60000020 for cplmain.cpl
80770000 - 8079e600 L0002e600 o32 region_3 rva=00048000 vsize=0002f000 real=02ea8000 psize=0002e600 f=40000040 for cplmain.cpl
808c7650 - 808c76bc L0000006c e32 struct 4 objs, img=212e entrypt=0000b408 base=02e60000 v4.20 tp9 cplmain.cpl
808c76bc - 808c771c L00000060 o32 struct cplmain.cpl
80a36870 - 80a36ff6 L00000786 o32 region_1 rva=00044000 vsize=00001800 real=01cd3000 psize=00000786 f=c0002040 for cplmain.cpl
80a4d0d8 - 80a4dffd L00000f25 o32 region_2 rva=00046000 vsize=00001ca8 real=02ea6000 psize=00000f25 f=40002040 for cplmain.cpl
80be2ed8 - 80be2ef8 L00000020 modent 20 00000005 01c3f9e1932529f0 486400 8119a000 cplmain.cpl
...............
5) Last line's "486400" is actually the *right* size of the file, but the real size of the extracted file (in directory "result") is 477,184.
I have not checked other files, since this is the one I am interested in.
Any idea?
Thanks in advance
XIP files would report incorrect size. Because they are XIP
If XIP files report wrong size (I guess you mean inside the very NB1 file), how can one fix this?
Spasiva!
I guess i am not using the same alignment of blocks in the reconstructed .exe file, as was used for constructing the rom.
it is not a really important issue, that the file is not exactly the same size.
there are also sections missing in the rom, that were in the original file, like the relocation information.
the main use of dumprom extracted modules, is that you can reverse engineer them with something like IDA. .. not that they are useful as real executables.
willem
Hi Willem,
Well the thing is that I need this file to be the right size. I agree that size is not important (that's what I actually say to my girlfriend ;-) ) as long as the extracted file's is greater, not lesser (which implies truncation) than the original's. The problem is that the file I got is smaller, so there is some missing data in.
Actually, I copy cplmain.cpl to the ppc as cplmain2.cpl, I do:
ctlpnl cplmain2.cpl,2 (for instance)
and it simply does not do anything.
Excuse my ignorance, but, what is IDA?
Dank u vel
IDA: http://www.datarescue.com/idabase/
you can't use a file extracted with dumprom on another device.
most executables and dll's ( and cpl's ) are fixed to work at a specific location in memory in one specific ROM. you can't use it on another device, it will most likely have a different memory layout.
willem
If you have two versions of the same DLL that are different only in code and data base addresses, you can restore the .reloc section and get a working DLL. I've wrote a simple program that when used with any relocation rebuilder tool would produce a working DLL. And even if DLL is not working, it is much easier to decompile it with IDA because it uses relocation information internally during analysis.
The DLLs should be exactly the same, for example they can be taken from the same ROM builds that differ only in language (of cause in this case DLLs should not be localized).
Hi all,
I'm an owner of FSC T830 Loox...
With the great help of bepe and mamaich I'm trying to cook my own rom... (thx guys, really!)
At the moment replacing even one module makes the device not to boot.
The problem is now upgrading the rom from aku 2.x to 3.x
As mamaich says newer AKUs have added new functions to coredll, therefore I need to port the XIP section...
I need help on this case:
I succesfully dump the XIP of my ROM
dump -o 0x00250000 myrom.rom xip.bin
dumprom -5 xip.bin -d xip
The question is: how can I port the XIP section from a newer AKU?
Thanks for all your valuable helps!
hi turchino,
do you find a solution for flash a loox t to a newer os version?
bg joy
Hi!
I'm also trying to port the xip section from a newer AKU to the T830.
It seems that none of the current tools is working correctly with that rom. Rommaster isn't working at all. Dumpromx can extract files, but not replace any (e.g. replacing a bigger file with a smaller ->not enough space...)
I've tried to manually replace coredll.dll in the t830 xip section with the newer one but it didn't want to boot. The strange thing is that t830's coredll.dll is much bigger than one from AKU 3.5.2. Any ideas about that? (maybe compression?)
I've also noticed one realaddr of a .pdata section from nk.exe is pointing out of the xip section?! (psize:00000000, dataptr:00000000)?
Also relocating a completely AKU 3.5.2 xip section to t830's base address and changing boot.hv isn't booting.
Any ideas how to get that running?
hey. bepe's xipport is designed for dealing with WM5/WM6 xip's.
with dumpromx you would need to increase the image file size by adding 00 bytes at its end before attempting to add anything. be careful, if the xip section grows too large then it may not fit in the partition in your nand flash....
also i'm not sure if it supports wm5/wm6 xip editing or just ce 4.x/wm2003/ce3.
rommaster is too buggy dont even try that one i think...
manual replacing isn't too tricky if you know what you're doing.... you need to know about PE header stuff. how did you try to replace it?
also, the new coredll should have the same base address as the original one or one that isn't conflicting with anything else.
did you make sure about that?
did you also edit romheader properly - because if this new coredll was larger than the original one the image is larger for sure and romheader needs editing.
don't forget about compression issues either. maybe that's why the original one is much bigger. but i would need to see the coredll's in question
anyway it is possible to do a coredll replace manually (did that before), no worries. but bepe's tool might make it easier
you say: "I've also noticed one realaddr of a .pdata section from nk.exe is pointing out of the xip section?! (psize:00000000, dataptr:00000000)?"
if psize is 0, then the .pdata section isn't really initialized data. it's a zero sized section and will only be existing when the loader loads the executable into ram.
but it sounds kind of strange to have a .pdata with 0 size, which file had this section?
edit: ok i see you meant nk.exe heheh. that's fine. it usually does have a zero sized section
you say: "Also relocating a completely AKU 3.5.2 xip section to t830's base address and changing boot.hv isn't booting."
how did you do the relocating?
xipport was the exactly the tool I was looking for. After a few modifications "realloc P" of the unmodified xip gave me exactly the same map.txt as the original t830 xip map.txt. After exchanging all kernel files (except hd.dll and osaxst0.dll which were needed to keep another oem file in the same location as it was before), reallocing and changing the header address in nk.exe it still isn't booting (it runs nk.exe but gets stuck somewhere in there). Maybe you can have a look at the whole thing (download here, with modified xipport)
As for the coredll, it turned out that dumprom missed a section.
I did the relocation by writing a little app which runs through all pointers and changes them, but this is also possible by editing romheader.txt from xipport.
ok I've changed the other dlls too (had the same size), but it still wont boot. Is there a kernelflag which I can set to get debug messages on the screen? Or do you know if the nandflash driver trueffs.dll from AKU2 is compatible with AKU3?
hey. sorry for the delay.
did you solve the problem yet?
if not, i'm going to check it for you soon.
about coredll. OK but how do you mean dumprom missed a section? i've never heard that before about it.
relocation: yeah, romheader.txt is the trick there. but, must be a nice app. i'll check it out (i see it's in the zip)
edit: OK i took a very quick look (i need to go now). the xips you uploaded have completely different romheaders and rom mappings (0x88xxxxx vs 0x80xxxxxx). what you said about relocation sounded like you already fixed that, but why did you upload this old version then? or did you upload original T830 and original AKU 3.5 from another device? i'd like to see your xip (that doesn't boot).
p.s.: did you make sure the hard coded romheader pointer in the kernel matches the romheader pointer/location in your xip ?
"edit: OK i took a very quick look (i need to go now). the xips you uploaded have completely different romheaders and rom mappings (0x88xxxxx vs 0x80xxxxxx). what you said about relocation sounded like you already fixed that, but why did you upload this old version then? or did you upload original T830 and original AKU 3.5 from another device? i'd like to see your xip (that doesn't boot)."
The xip in "xipport" is the modified t830 xip that doesn't boot. (btw. xip.bin in that folder is the original t830 xip). And the xip in "xipport aku3.5.2" is the xip I want to port to the t830.
The only success I had to now was getting the original wm5 aku 2.3 rom to run with the aku 3.5.2 coredll.dll. Is there anything else I have to do after I have replaced the t830 sys folder with an aku3.5.2 folder and building the reg/imgfs? Or does the kernel want to have some files at a specified address?
"p.s.: did you make sure the hard coded romheader pointer in the kernel matches the romheader pointer/location in your xip ?"
yep, the kernel always gives a me message when it has found the romheader and continues booting. Therefore I always know when I missed something
hey.
OK that sounds more clear now about which xip is which!
i'll look at it again soon.
until then: did you verify the copyentries are all OK? xipport sometimes has a silly bug regarding them.
easiest is to just delete hd.dll and osaxstxxxxx.dll - they are the ones that require copyentries apart from kernel. (kernel copyentry isnt screwed up by xipport anyway.)
but, they are not needed for a booting kernel, just debug stuff afaik. so deleting is easy..
btw, even if the copyentries are OK, using the wrong hd.dll/osaxstxxxx.dll will make the xip unbootable.
also pay attention to map.txt see if the base addresses overlap or not (usually not but worth checking), also if .data base addresses (the 0x01Fxxxxx ones) have not been changed. they should not be changed. another xipport bug sometimes.
new--->
update: i looked at your xip now.. none of the above seem to apply. i'll leave that stuff there though.
last thing i can think of is try editing physlast in romheader to point to last actually used byte in xip.. that shouldn't matter but who knows
can you tell me how far does your system boot. maybe the xip is fine and your IMGFS part is wrong. check for module overlaps.
what is last message you get from your kernel?
and, to answer your question about kernel wanting to have files at specified addresses. well, the kernel regions have to stay at the original addresses in the xip, except for the region that is copied out and for the discardable last region (same for the debug crap dlls)
Core_Z said:
"
The only success I had to now was getting the original wm5 aku 2.3 rom to run with the aku 3.5.2 coredll.dll. Is there anything else I have to do after I have replaced the t830 sys folder with an aku3.5.2 folder and building the reg/imgfs? Or does the kernel want to have some files at a specified address?
Click to expand...
Click to collapse
Hi Core_Z,
I'm trying to accomplish the same thing for our XDA Atom. I was wondering if you could describe how you achieve above. I, too, would like to replace the coredll.dll in our old AKU2.2 from the AKU3.X
These are the steps, I made using the modified XIPport (with realloc function):
1. coredll.dll comes from XIP of Atom Life which has same base address
2. replaced the modules and corresponding txt file into ATOM AKU2.2
3. new core is larger than the old one; so, I increase the ROMHDR.txt physlast to accommodate it.
4. realloc / write new maps.
5. move the rom header pointer in the nk.exe S000 module to the new one
6. built xip_out.bin
7. wrote the new bin to ROM image file
8. flash the device.
It won't boot. Did I miss anything?
cmonex said:
easiest is to just delete hd.dll and osaxstxxxxx.dll - they are the ones that require copyentries apart from kernel. (kernel copyentry isnt screwed up by xipport anyway.)
but, they are not needed for a booting kernel, just debug stuff afaik. so deleting is easy..
btw, even if the copyentries are OK, using the wrong hd.dll/osaxstxxxx.dll will make the xip unbootable.
Click to expand...
Click to collapse
Hello cmonex / core_z,
I followed this by removing the files you mentioned above. So, my current AKU2.2 XIP has the new coredll.dll from AKU3.X boots now. This means, that hd.dll / osaxstxxxx.dll is preventing my revised XIP to boot.
Question is: How do we restore this modules correctly?
Jiggs
I have another concern...
I have utilized the new XIP with new AKU3.X \SYS files, and rebuilt the ROM using the Scoter Kitchen. In the IMGFS section there is .ROM module wherein the ROM header is also described. However, there is one entry which is not clear to me... which is the e32_imageflags
The old AKU2.2 uses 0x00001e01, the new AKU3.3 uses 0x00002801. If I use the new values, the SDCard driver will not be loaded. If I use the old value, it will be loaded. What does this mean?
Now, because of this, after I build the ROM each time, I have to manually hex edit these values from 28 to 1e. Why? because not all entries of 28 has to be converted to 1e.
check this out Jiggs,
http://www.pxdxa.com/read.php?tid=40125&fpage=1&toread=&page=1
jiggs said:
Hello cmonex / core_z,
I followed this by removing the files you mentioned above. So, my current AKU2.2 XIP has the new coredll.dll from AKU3.X boots now. This means, that hd.dll / osaxstxxxx.dll is preventing my revised XIP to boot.
Question is: How do we restore this modules correctly?
Jiggs
Click to expand...
Click to collapse
hey! i'm back if you still need help: you dont need these dlls, they just take up space. if you really want them then you can do one of two things:
1) use the original dlls from the device's original xip
OR
2) rebase them but this can be more difficult than with ordinary dlls.
(i did not try either, because those dlls are just for debugging anyway.)
jiggs said:
I have another concern...
I have utilized the new XIP with new AKU3.X \SYS files, and rebuilt the ROM using the Scoter Kitchen. In the IMGFS section there is .ROM module wherein the ROM header is also described. However, there is one entry which is not clear to me... which is the e32_imageflags
The old AKU2.2 uses 0x00001e01, the new AKU3.3 uses 0x00002801. If I use the new values, the SDCard driver will not be loaded. If I use the old value, it will be loaded. What does this mean?
Now, because of this, after I build the ROM each time, I have to manually hex edit these values from 28 to 1e. Why? because not all entries of 28 has to be converted to 1e.
Click to expand...
Click to collapse
those values arent really e32_imageflags... i dunno why the imageinfo txt is created in that way for .ROM and .VM
thats to do with the imgfs memory space. probably the SD driver's image base is lower than the new imgfs memory space start address (which is what you were seeing)
to confirm that check the base address (e32 vbase) in imageinfo.txt for the sd dll.
cmonex said:
those values arent really e32_imageflags... i dunno why the imageinfo txt is created in that way for .ROM and .VM
thats to do with the imgfs memory space. probably the SD driver's image base is lower than the new imgfs memory space start address (which is what you were seeing)
to confirm that check the base address (e32 vbase) in imageinfo.txt for the sd dll.
Click to expand...
Click to collapse
Thanks for the info! I'll look at this later.
Here goes nothing: I've been trying to understand the whole porting process but no one ever posts on my threads, so I figured I'd post on this one since it's about the same thing. I'm reading the thread and I'm following... most... ok, half of it. I thought the process of porting the XIP and the SYS was as simple as well... this. If someone wants to correct me, by all means, please do so.
While cooking my german GPS rom I noticed that there is very little information about the ExtROM nb format. Right now we can't extract it, we can't rebuild it, we can't resize the partition.
So I figured it was time to put some research into the matter. I made a package that contains the following:
- 04_ExtROM.nb (from RUU_Trinity_HTC_GER_1.23.407.2_103_6275_1.38.00.11_108)
- extrom_dump.raw (a dump of the extrom area after flashing it)
- Content (content of the extrom, copied from device after unhiding)
The idea is to analyse how files are written from NB to flash and how they are stored inside the NB. The format should be identical with Hermes and maybe other devices.
The goals of this research are:
1) understanding the Extrom NB format
2) making an extraction tool for getting files out of extrom.nb files
3) making a rebuild tool that allows us to make custom extrom.nb files
4) Resizing the Extrom partition
Please post your findings in this thread, you can also contact me on IRC (#xda-devs on irc.freenode.net
Here's the file:
http://rapidshare.com/files/24740192/ExtromResearch.rar.html
Here's what I found out so far (only worked on it for a few minutes):
R1:
The Extrom nb seems to hold 7 versions of each file, probably for 7 different languages. Search for PP_AKv33-DefaultPage_ and you'll find:
PP_AKv33-DefaultPage_FIN-040b.CAB
PP_AKv33-DefaultPage_WWE-0409.CAB
PP_AKv33-DefaultPage_WWE-0409.CAB
PP_AKv33-DefaultPage_RUS-0419.CAB
PP_AKv33-DefaultPage_FRA-040c.CAB
PP_AKv33-DefaultPage_GER-0407.CAB
PP_AKv33-DefaultPage_FIN-040b.CAB
Those occur in the 7 different config.txt files. Maybe those cabs are not all really in the NB, at the very least they must be very similar. Otherwise it wouldn't be so easy to compress. I found 7 occurences of several cab files in the NB by searching for the first few bytes of them.
R2:
The raw dump does not contain the config.txt files (at least I couldn't find them). Maybe config.txt gets stored elsewhere. I also didn't find the cabs in the dump so far, maybe a different format or a bad dump.
I had used
pdocread.exe -w -d EXT_FLA -p Part00 0 0xa00000 extrom.raw
R3: Only one of the 7 files in NB actually is actually in the ExtROM content.
My conclusion from R1 and R3:
The extrom.nb holds information for different languages or OS versions. Depending on some information only one of those actually gets flashed.
I'm finding it strange that the extracted ext_rom and the dumped ext_rom haven't the same structure.
I own a wizard (Qtek9100) and using Typho5 to extract it from the RUU and using podcread to dump it from the phone i always get a FAT16 image file. I can then use a program like Winimage to browse and edit it as i like.
Are you sure the extracted ext_rom is correct?
I believe I did everything correctly, yes.
Trinity and Hermes are different from Wizard but my dump also seems to be FAT16. If you have experience with it could you please see if the Wizard tools work on my dump?
R4: The filesystem used for ExtROM seems to be TFAT16 (Transaction-Safe FAT).
The NB files contains 90 TFAT16 occurences. I'll see if there are tools for viewing/editing TFAT16.
ZakMcRofl said:
I believe I did everything correctly, yes.
Click to expand...
Click to collapse
If you remove the first 0x1040 bytes from the nb file you get something looking like a FAT16 image, but still not working correctly. I wonder if the nbh decoder by itsme as a bug that produces a corrupted extension_rom?
ZakMcRofl said:
Trinity and Hermes are different from Wizard but my dump also seems to be FAT16. If you have experience with it could you please see if the Wizard tools work on my dump?
Click to expand...
Click to collapse
I did I downloaded your dump and used Winimage to check the raw file and it showed an empty confused FAT16 image
ZakMcRofl said:
R4: The filesystem used for ExtROM seems to be TFAT16 (Transaction-Safe FAT).
The NB files contains 90 TFAT16 occurences. I'll see if there are tools for viewing/editing TFAT16.
Click to expand...
Click to collapse
Winimage allows it. There's a tutorial by Faria on how to cook ext_roms and flash it back to wizards and winimage is advised
cheers
This post says otherwise (regarding TFAT16, not FAT16)
The simpliest method.
1. Take MS_.NBA (a decrypted version of MS_.NBF). Open it in any hex editor, and search for bytes "EB FE 90 4D 53 57 49 4E 34 2E 31 00" ("ыРMSWIN4.1", there would be "FAT16" string a bit lower). The string should be found near offset 0x70000. Extract everything starting from the place you've found and up to the end of file to a file named "extrom.img"
2. Open "extrom.img" in WinImage, edit it as you like, save the file
3. Open the hex aditor and place modified "extrom.img" to the same place in MS.NBA file where it was before extraction.
that's all. Convert NBF to NBA and flash your ROM.
The same method cannot be used on Universal. It has TFAT16 instead of FAT16, WinImage knows nothing about TFAT and destroys FAT table. But there is a simple workaround.
Click to expand...
Click to collapse
Source: http://forum.xda-developers.com/showpost.php?p=847312&postcount=10
Well, winimage works perfectly with wizard nb files (decrypted nbf files)
Yes, apparently Wizard uses FAT16 whereas Universal (and Trinity Extrom) use TFAT16. The former can be opened, the latter not.
I'm currently compiling a file list for further analysis.
ZakMcRofl said:
Yes, apparently Wizard uses FAT16 whereas Universal (and Trinity Extrom) use TFAT16. The former can be opened, the latter not.
I'm currently compiling a file list for further analysis.
Click to expand...
Click to collapse
Maybe that's why Wizard's extended roms get corrupted when users try to delete files in it. Perhaps WM5 or WM6 use TFAT16 upon rebooting and it
screws up the reading
Filelist
I took the content files and searched for their occurrences in extrom.nb.
Here is the filelist with hex positions:
Code:
0x0000A280 BT_Table.CAB
0x0001F3B0 Config.txt (FIN)
0x00020A08 HTC_WM5DST_signed.cab
0x000485D0 MP_CVSDcpl_20060920.cab
0x000685B0 PP_AKv30-DefaultPage_ALL.CAB
0x0007DCF8 PP_AKv33-DefaultPage_???.CAB
0x00093850 PP_ExtVersion.xml
0x000956C8 PP_FixITS2654_SMD.CAB
0x000A2800 BT_Table.CAB
0x000B7930 Config.txt (WWE)
0x000B8F88 HTC_WM5DST_signed.cab
0x000E0B50 MP_CVSDcpl_20060920.cab
0x00100B30 PP_AKv30-DefaultPage_ALL.CAB
0x0012B7B8 PP_ExtVersion.xml
0x0012D630 PP_FixITS2654_SMD.CAB
0x0013A768 BT_Table.CAB
0x0014F898 Config.txt (WWE)
0x00150EF0 HTC_WM5DST_signed.cab
0x00178AB8 MP_CVSDcpl_20060920.cab
0x00198A98 PP_AKv30-DefaultPage_ALL.CAB
0x001C3720 PP_ExtVersion.xml
0x001C5598 PP_FixITS2654_SMD.CAB
0x001D26D0 BT_Table.CAB
0x001E7800 Config.txt (RUS)
0x001E8E58 HTC_WM5DST_signed.cab
0x00210A20 MP_CVSDcpl_20060920.cab
0x00230A00 PP_AKv30-DefaultPage_ALL.CAB
0x00246148 PP_AKv33-DefaultPage_???.CAB
0x0025BCA0 PP_ExtVersion.xml
0x0025DB18 PP_FixITS2654_SMD.CAB
0x0026AC50 BT_Table.CAB
0x0027FD80 Config.txt (FRA)
0x002813D8 HTC_WM5DST_signed.cab
0x002A8FA0 MP_CVSDcpl_20060920.cab
0x002C8F80 PP_AKv30-DefaultPage_ALL.CAB
0x002DE6C8 PP_AKv33-DefaultPage_???.CAB
0x002F4220 PP_ExtVersion.xml
0x002F6098 PP_FixITS2654_SMD.CAB
0x003031D0 BT_Table.CAB
0x00318300 Config.txt (GER)
0x00319958 HTC_WM5DST_signed.cab
0x00341520 MP_CVSDcpl_20060920.cab
0x00361500 PP_AKv30-DefaultPage_ALL.CAB
0x00376C48 PP_AKv33-DefaultPage_GER-0407.CAB
0x0038C7A0 PP_ExtVersion.xml
0x0038E618 PP_FixITS2654_SMD.CAB
0x0050DE80 MP_CVSDcpl_20060920.cab
0x00527EE8 Config.txt (FIN)
0x005282F8 HTC_WM5DST_signed.cab
0x005C9298 PP_AKv30-DefaultPage_ALL.CAB
0x005DE9E0 PP_AKv33-DefaultPage_???CAB
0x005F4538 PP_ExtVersion.xml
0x005F63B0 PP_FixITS2654_SMD.CAB
R5: Files are stored sequentially for each language.
I haven't found where the offsets and how the offsets are stored, maybe relative to the beginning of a language section. I haven't found the absolute offsets anywhere yet.