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
OK, I'll start by saying sorry for my stupidness and thankyou for listening to my plea.
I downloaded Jeff's XDA special edition .exe file and unzipped it to a Dir seeing all the files needed to upload a new ROM to my XDA.
I (in all my wisdom) decided to run the osimagetool with the --register and proceeded to right click on the nbf 30mb rom image and selected burn...thinking this was the way to do it (not even trying to run the original exe)
The "programme a" program started and started updating my xda. It started off updating and after a few seconds i heard the "BLIMP" of the activesync telling me it has disconnected, then another blimp telling me it had restarted and re-connected to active sync, but the loader on the screen quickly zipped to 100% done and told me to remove and reboot the xda. The xda however was telling me "upgrading... It will take about 5 minutes". Urk
Now im left with an XDA that sit's on this upgrading screen even after reboot of it.
OK... ive done wrong.. im silly... would any one step up and help me out here (BIG PLEASE AND TY also). Ive got an XDA serial cable sitting here next to me as well as the usb cradle (which im sure wont help now the xda cant run active sync)....
Ideas? Can i run the original rom uploader (xredit?) rather than osimagetool with the serial cable to upload either the new rom i have or the rom i backed up of my old device before doing all this (yes i did back it up to my harddrive first - phew?).
Thanks for reading, and i hope someone can point me to a place in the forum where all people like me end up, or even better send me an email pointing me in the right direction.
Thank you! (email Tony at [email protected])
Note: my original version was 3.17.03 and the "programme a" upgrade program said it was upgrading to 3.16.
can you tell me what splitrom says about the nk.nbf that is now in the 'english' subdirectory of the path
pointed to by the registry key "Software\\XDA Developers\\OsImageWriter", "Programme A Path" ( in current-user )
thanks for coming back to me.
unfortionately, i dont have perl installed on my windows xp machine so the batch file you linked to do doesnt work. If you have a link for a perl install anywhere I'll be happy to install and run it.
In the key you mentioned, here is the value: D:\XDAtools-Jeff\binaries
The directory i unzipped Jeff's version of your tools to.
Im not sure if you perl script does other things, so in the meantime, i'll go and try and find perl (im sure ive installed it on a work machine i had years ago - seem to remember adding local path variables for it)... i'll check my cd archive for it.
Thanks for the help, much appriciated
Tony.
perl can be obtained from either http://www.cygwin.com/setup.exe or http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl
cheers, i'll dl then run the script....
n1 guv
C:\Documents and Settings\tkett.ADPLATES>D:\splitrom.bat
Can't locate List/Util.pm in @INC (@INC contains: C:/Perl/lib C:/Perl/site/lib .
) at D:\splitrom.bat line 86.
BEGIN failed--compilation aborted at D:\splitrom.bat line 86.
^^
Thats the error message i get when running that perl script.
Ive searched the hdd for Util.pm and its sitting in my c:\perl\lib\sgi dir
Things just arent going right for me at the mo.
this module is standard with perl 5.8, with perl 5.6 you have to install
it manually.
as a quick fix, you may also just add a 'min' function manually
Code:
sub min {
my $min;
for (@_) {
$min= $_ if (!defined $min || $_ < $min);
}
return $min;
}
and uncomment the line
Code:
#use List::Util qw(min);
C:\Documents and Settings\tkett.ADPLATES>D:\splitrom.bat
Usage: splitrom <romimage(s)> [options]
-wx xipchain where to write xipchain
-wo osrom where to write output image
-wb bitmap where to write bitmap
-wl bootloader where to write bootloader
-rl bootloader which bootloader to use for NBF
-n nbfinfotext what NBF header to use [ex: PW10A1-EN
-ri nbfinfofile or where to read NBF header info from
-wi nbfinfofile where to save NBF header info
-rx xipchain where to get xipchain from
-rb bitmap where to get bitmap from
-rm [email protected] insert new romsection.
-ob offset where to find the bootup image
-oe offset the end of the desired os image ( def
0000 )
-t NBF | B000FF | NB? | IMG type of result image (default is NB1)
^^^^ Ive put your routine in replacement of that line and am given the options above when running splitrom now. What parameter would you like me to run ?
As always.... a big thanks for the help.
Tony
Itsme, thanks for your interest in my problem. And im very glad people like you are around to help
I have however and thankfully repaired the fault.
Here, (for other newb's like me that get stuck) is how i done it:
I had already backed up my ROM using the osimagetool program to a nb1 file on my pc called "oldrom.nb1". Now because my XDA wasnt booting into Pocket PC windows, i couldnt use active sync to sent the rom image I backed up, back to the XDA...so I had to go and buy a cheap SD reader from my local Dixons store and run osimagetool again. This time writing the rom i had backed up to the SD card in the new SD reader.
Then I rebooted the XDA into the bootloader (hold down the top power button and do a soft reset) and selected to reflash the XDA using the SD card.
If you havent already backed up your rom from your xda to file, then I presume, you have to find another person with an XDA so you can download thers to your SD card (once your in the bootloader menu, press the contacts button to get the options to dump their rom to your card). OR find an NB1 file on the internet that matches your phone version.
These may be simple instructions for most of you, but i've seen a few posts that directly relate to the problem i had, and saw people crying for help, just like i did...hopefully this will help those few.
I did also have a serial cable, and im sure there is a way to upload roms you have on your pc to the XDA via that (using the xda developers old rom tool), but im afriad i didnt read into that after finding out this method. (this way may be better for the skint people who dont want to buy an SD reader, but can get hold of a serial cable for cheap)
REMEMBER FOLKS
It was silly of me to try and flash the device in the first place without reading loads and loads of entries on these forums and really finding out what is going on instead of just flashing blindly in the hope that it would work first time.... please dont follow my lead. :shock:
Thanks again for your help Itsme...and one last question... do you think that with that registry entry as it was above, that i can try again with the .exe jeff made (possibly downloading it again in case of corruption)
(yes i am a glutten for punishment)
Tony
still I'd like to know what went wrong in your case.
can you type 'splitrom nk.nbf' ( in the 'english' subdirectory )
sure:
D:\XDAtools-Jeff\binaries\English>splitrom.bat nk.nbf
this rom seems to be 3.17.03 ENG 2003-05-15 o2euro
this bootloader seems to be V5.15 2002-06-06 20:29:17
no bitmap found
80000000 - 80040000 -- bootloader 0 files 1 modules
80040000 - 8026a804 -- kernel 13 files 11 modules
802c2000 - 8057d330 9 OS 15 files 32 modules
80580000 - 8075a69c 8 SHELL 79 files 27 modules
80780000 - 80a13b04 7 BROWSING 9 files 14 modules
80a40000 - 80d8a33c 6 COREAPPS 46 files 30 modules
80dc0000 - 80ebd150 5 SYNC 12 files 22 modules
80ec0000 - 810388e0 4 24MAPPS 13 files 13 modules
81080000 - 81348248 3 24MCONSUMER 69 files 1 modules
81400000 - 81401484 -- xip chain 8 xip entries
81440000 - 817f6f14 1 MISC 209 files 40 modules
81940000 - 81d2d2b5 -- operator rom 81 files
Tony.
ahhh... haNG ON.... the one i used was in the .exe's folder.. not jeffs tools folder:
D:\XDA-developers-SER-v12\English>splitrom.bat nk.nbf
this rom seems to be 3.16.52 ENG 2003-03-10 XDASER-12
this bootloader seems to be V5.22 2003-05-15 17:46:55
no bitmap found
80000000 - 80040000 -- bootloader 0 files 1 modules
80040000 - 8026a804 -- kernel 13 files 11 modules
802c2000 - 8057d330 9 OS 15 files 32 modules
80580000 - 8075a69c 8 SHELL 79 files 27 modules
80780000 - 80a13b04 7 BROWSING 9 files 14 modules
80a40000 - 80d8a33c 6 COREAPPS 46 files 30 modules
80dc0000 - 80ebd150 5 SYNC 12 files 22 modules
80ec0000 - 810388e0 4 24MAPPS 13 files 13 modules
81080000 - 81348248 3 24MCONSUMER 69 files 1 modules
81400000 - 814019a4 -- xip chain 10 xip entries
81440000 - 817f6f14 1 MISC 209 files 40 modules
81800000 - 818e0c14 10 XDA_DEVELOPERS1 13 files 0 modules
81940000 - 8198b6e5 -- operator rom 20 files
819c0000 - 81ee9a58 11 XDA_DEVELOPERS2 202 files 0 modules
hence the 3.16 now.
Hi Ajkett,
Thanks for sharing your knowledge of how to resolve your problem with us. I have however used a new 64 mb sd card to flash my old rom (3.16) to it before trying out the Jeff rom kitchen exe and thank god things are fine for me. Now I have bought a cheap 6 in 1 card reader/writer and would like to keep the old rom in a safe place in my hard disk hence freeing my sd card so that I could use it. I have read those threads in the rom tool section many times and still can't work out how to use the osimagetool. When I clicked on it, it gives me the interactive screen but always do not read my sd card. Even with the card reader, it seems to "think" that the sd card is unformatted and ask to format the card for me. Now the question is whether the rom is inside or not? How can I use the rom tools to read the sd card and copy the rom to the hard disk? What does a rom file appear as? Is it like the nk.nb1 file created in Jeff's rom kitchen?
Cheers
Vic
ahhh your trying to read the rom from the sd card after dumping it to the sd card from the xda?
the way i got it onto my harddrive was without an sd card. Just run the osimage tool and select the xda current memory as the source and then type c:\oldrom.nb1 as the destination.... it will use activesync to read the rom straight from the device.... you dont need the sd card to back it up.
Then when i ****ed my xda up, i run the osimage tool again and wrote from source - oldrom.nb1 to the sd card reader to a formatted sd card.
When it writes it, it gets rid of all the formatting so you wont be able to see whats on it on your pc....the only thing its good for then is to use on the xda to overwrite the rom, until you format it again that is.
Its not like a file on the sd card... its like a bootdisk with the rom written in a way that the xda will understand that its a bootdisk and will boot from it to overwrite itself... like the file is in raw format... not a nb1 file or anything (looks like lots of gobbledigoop) and the pc will not read it.
Thanks Ajkett,
Thanks for your kind reply anyway.
Got it done. The osimagetool could read but I did not write the path correctly; it has to be rom.nb1 apparently for it to work. I even used the card reader and managed to write the rom again the same way to my hard disk. I hope this is the correct way of doing it and it seems that the rom.nb1 file on my harddisk is about 30.5 mb which is probably about right for the old 3.16 rom I had dumped onto it by the XDA.
What puzzles me is that if it can read as source rom.nb1 file when you say you rewrite it to the sdcard, it becomes mumbo jumbo again but it should flash ok within bootloader mode via the XDA. Is this correct?
Cheers
Vic
yep your correct... even thogh it doesnt write a nice 30mb rom.nb1 file to your sdcard, the xda still reads it to boot from.... it must need it a raw info.
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,
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.
I was trying to cook a modded ROM for the i607, I was able to extract the nb0 from the bin file using cvrtbin & viewbin > then Mamaich's prepare_imgfs > viewimgfs > dump > modify/add/delete files > buildimgfs > makeimgfs and I know this is basically what you do with the Hermes ROM, however making it back to a BIN file has proven to be a "no go". I have tried splitrom.pl, rommaster, xipbin, etc, but I am afraid without the right utility this will not happen.
Does anybody know if there is a Tool to convert the cooked nb0 back into WMx B000F bin file? There is an old tool for Mobilpro xipbin.exe, however the block size and lenght of ROM does not match. Doing the splitting in sectors and retrieving the checksum manually is going to take a lifetime...
Just an idea: Could it be possible to use a blank CE.BIB with only the start and offset of the ROM and romimage from MS PB builder together with the nb0 file above?
Any good ideas are welcome.
I tried using romimage with no results
I tried to use Romimage from MS platform builder, and after many attempts I gave up. I basically used a minimal CE.BIB and the patched ROM (nb0) file as the source to be inserted. It creates the Run-time BIN file with 4K blocks where it should be making it 128Kb ones.
TO Do:
Try an HEX editor with macro or script capabilities, to perform the following process
1.- Strip the HEADER+RECORD section from the original FLASH file
2.- Strip all zeroes preceding the patched ROM (NB0) before the start point
3.- Cut the patched ROM in 128K chunks (about 500 pieces) called blocks or records
4.- Calculate the Checksum 32 of everyone of these chunks and annotate it
5.- Make the HEADER of the RECORD annotating (in little endian) : Start Address - Lenght(Block Size) - Checksum 32 for every record
6.- Join the HEADER to the respective record. Iterate this process until finished (some 500 times)
7.- Insert the above joined (HEADER+RECORD) section into the stripped flash file in step 1
8.- Here comes the scary part : flash the phone with this MOD (just the PDA section)
9.- If successful, make a program to automate steps 1 to 7
Wish me good luck...
On other comment: according to Texas Instruments, in the Code Composer Studio for OMAP processors, it can be connected to the phone via a COM port using HyperTerminal. Alternatively I think if we can flash the phone using this method and a ROM type NB0.... Perhaps no, as the flash program just connects to the phone using the Serial port qhen in Flash mode. This program also accepts img files, I tried to rename the nb0 file to img and didn't work. Does anybody know what these Samsung's img files are?
Is anybody interested on this matter? Please don't just read the post, start replying... If we really want to MOD this phone, being it the BlackJack i607 or the European i600, we need to start doing some Reverse Engineering..., the people at xda-developers had started this way to master the HTC and similars.
hey, i replied to your email. hope it will be helpful. especially if you give me a link to the image
cmonex said:
hey, i replied to your email. hope it will be helpful. especially if you give me a link to the image
Click to expand...
Click to collapse
Thank-you, however I haven't received your reply yet. I'll send you the link to the ROMS via private message .
Regards,
trinca
The modded ROM
Cmonex:
I have uploaded the modded ROM and is located at:
http://rapi*****/files/42779528/XXGD1_pda.nb0.html
******************W A R N I N G *********************
For everybody else following the thread, please be advised
this above file is a plain binary, it must be converted to a
MS WMx BIN format with a B000FF header before flashing any BJ.
Please do not attempt to flash your phone with it!
**************************************************
I haven't received your e-mail
cmonex said:
hey, i replied to your email. hope it will be helpful. especially if you give me a link to the image
Click to expand...
Click to collapse
Hi, Cmonex:
Can you please resubmit?
TKS
trinca
For those of you who would like to start cooking this ROM
I was able to extract the plain image using cvrtbin (MS tool that comes with visual studio) you may grab a copy from here:
http://www.toradex.com/colibri_downloads/Linux/linux_to_wince/?D=D
Then you will be able to use the common tools from xda-developers such as prepare_imgfs (with the switch -acer) from the WM5 kitchen made by itsme (first sticky in this forum) and so on.
Making the ROM back to the B000FF format is going to be the trouble... So far there is not an easy come back... yet!
There is also an excellent article on Mobilepro BIN roms made by cmonex, you can get a copy of that tutorial inside his Romtool package, get it from here:
http://hpcmonex.net/nec900/files/releases/romtoolpack.zip
Be informed the Mobilepro ROM is very different in the way the Runtime file is organized, however the tutorial is the best resource I have seen so far.
Besides, there are some really good tools inside that package
Best regards and start cooking!
trinca
Samsung i60x ROM: Extracting the OS payload from the Upgrader exe single file
The Upgrader program contains 3 payloads: Eboot, Phone and O/S. To extract the O/S payload follow this procedure:
1. Open the exe upgrader file using the Hex editor of your choice.
2. Locate the ASCII string B000F followed by 0x0A. The complete sequence you should look for is 0x4230303046460A. You should find 3 occurrences of the above string. Concentrate on the last one.
3. Copy from this start address all the way up to the string 0x060000EA3B, which is the start of the phone ROM.
4. Make sure your cut includes 12 trailing zeroes 0x000000000000 as they indicate the loader the end of the Runtime of the pda image.
5. Name your file ending with a bin extension. (i.e XXGD1_pda.bin)
6. Proceed with cvrtbin to extract the absolute (or plain) ROM image (ending in nb0.
7. You are ready to start cooking.
I was able to sucessfuly extract in this way the ROMS for i600 releases: XXGC6 and XXGD1 and for i607: UCGB4 and UCGD2.
How did I find out? I got the chance of getting the XXGC6 upgrade package, which included the eboot, phone and pda sections separated. Further reading in the forums indicated the B000FF is followed by 0x0A, the start address of the ROM (00000000) and the end address. From there it was easy to locate the payloads in the Upgrader single exe file.
Good luck extracting your ROMS.
Samsung i607 Service Manual
Below is the link for the SGH-i600 service manual URL. Does anybody have the service manual and/or schematics for the SGH-i607?
BIN B000FF runtime image file format
Does anybody have a detailed description of the arrangement of headers and records in this file format? The best reference I have found is this page:
http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=60&MAEULNO=23&no=242&page=1
Unfortunately I do not understand Korean...
hey, i again sent you an email. i'll quote it in PM too just to be sure.
btw, the rom tutorial that i wrote and that you linked to, fully details B000FF format. what is not clear about it?
The tutorial is right
There is nothing wrong with your tutorial, I had to use the HEX editor several times until I got that right.
cmonex said:
hey, i again sent you an email. i'll quote it in PM too just to be sure.
Click to expand...
Click to collapse
Do you know if isotherm may share the source code for xipbin? Do you have a way to contact him? I tried to contact him at hpcfactor with no results.
Trinca - ok, let's imagine you got all the needed files to B000F format. How do you plan flash it back to your i607?
Creating the B000FF Runtime image
After cooking the ROM...how to re-create the B000FF Runtime image back? That is the $1M.. question, I am still navigating uncharted waters...
Producing the Flashable runtime image back is what I am now concentrating on, as I see it there may be 4 possible ways:
1) Manually
-a) Splitting the nb0 file in [n] 128KB chunks (for a ~64MB image, there are over 500 x 128KB chunks)
-b) adding the chksum32 at the beginning of each chunk
-c) adding the address and offset to the beginning of the above.
-d) merging it all together
-e) adding B000FF, start address and offset at the beginning of the merged files
You can use an Hex editor with scripting properties such as 010Editor and write a script to accommodate a) thru e)
http://www.sweetscape.com/010editor/
Still a pain in the neck and the scripting language is similar to C, if you know this language it will be easy for you to automate the above. Still experimenting with it.
2) Using XIPBIN, made by somebody AKA isotherm, this utility will make a B000FF runtime file good for a HP/NEC mobilepro, the record length is made 0x40000 bytes long, different from 0x1FFE0 record length of the original ROM, according to cmonex, this should not be a problem provided the record is made of different length and has the right checksum per record, but I already have made several attempts and it does not work for me, when flashing the phone it gets stuck at the very beginning. You may research further here.
3) Modify xipbin and make it produce records 0x0001FFE0 bytes long, as the source code for this utility is not available, cmonex says isotherm had disappear. I am still hacking into this utility...
4) Create our own program using VC or VB, I may probably work on this one as well, as I get some time available.
I am attaching a copy of xipbin.exe, however if you have followed my instructions, you may probably have it already, please let me know of any success (or failure, we all learn from these ones too).
usage:
xipbin [myrom.nb0] [start address for myrom.nb0] [myrom.bin] [start address for myrom.bin]
For Samsung's B000FF ROMs the command will look like:
xipbin myrom.nb0 0 myrom.bin 0
myrom.bin is then recreated from scratch.
Also according to cmonex, you may do the following:
a) Get an original B000FF ROM
b) use cvrtbin.exe and obtain a nb0 ROM
c) use xipbin with this nb0 and re-create a runtime bin file.
d) apply again this cvrtbin utility to the re-created runtime bin file
e) compare the result with above b) step
f) If they match you may have a candidate procedure, if they don't do not attempt to flash the phone with the procedure above.
I will include the new viewbin and cvrtbin, which now works with start address 0 on this type of ROMs
Usage:
cvrtbin -r -a [start address] -l [length of ROM] -w [8, 16 or 32] [romfile.bin]
cvrtbin -r -a 0 -l [the length of your ROM] -W 32 [myrom.bin]
Good luck!
The format of MS BIN B000FF runtime image file
According to several sources I have consulted, including MS documentation and insights given by cmonex, plus heavy HEX editing sessions, this is my impression on how the B000FF Runtime image format looks like:
Byte------>--1--2--3--4--5--6--7--8--9--A--B--C--D--E--F
Record 0 -> 42-30-30-30-46-46-0A--<Strt add>--<ROM lgth> * * * * * * * * * * * (42-30-30-30-46-46 = B000FF in ASCII ; 0x0A = end of header B000FF)
Byte------>--1--2--3--4--5--6--7--8--9--A--B--C--<-----128KB of nb0 image------>
Record 1 ->--<Strt Add>--<Rec lgth>--<CHKSUM32>--<--Chunk Nbr 1 of nb0 image--->
Record 2 ->--<Strt Add>--<Rec lgth>--<CHKSUM32>--<--Chunk Nbr 2 of nb0 image--->
v - v
v - v
v - v
Record n-1>--<Strt Add>--<Rec lgth>--<CHKSUM32>--<---Last chunk of nb0 image--->
Last Rec-->-00-00-00-00-00-00-00-00-00-00-00-00 .* * * * * * * * * * * * * * * (The last record always ends with 12 bytes set to 0x0)
**************************************
Please note:
Record 0 and the last one are different
All data are encoded Little Endian!
**************************************
Using the command:
viewbin -r [myrom.bin]
Will give you the record content of your runtime image file.
Trinca - just ran viewbin on samsung i750 image. chunks sizes are not 128kb each. looks like chunks are actually files from ROM in XIP format (executable in place, it is usual PE files but missing reloc table and something else). I bet we should use file deleting/adding/injecting utility like romtools one for ROM image manipulation which reamins intact B000F header! I see no other way to recreate B000F.
Well, I guess your runtime differs from that on the i60x. In any case I know of a tool made by bepe the name of xipport, you can look at this thread and download it here:
http://forum.xda-developers.com/showthread.php?t=315030
The best thing I can recommend you to do, is to try to get the appropriate format of your runtime image.
trinca
unfortunately all version of xipport just crash with errors on my ROM dump.
ROm Dump
JugglerLKR:
Let's get acquainted with your procedure, and do not pretend to modify something, just to find out if the tools work:
a) Have you dumped the ROM from the phone or you just extracted it from the updater executable?
b) If you have just cut the ROM out of the executable, use the new cvrtbin posted before (which runs fine at start address 0)
c) Run Mamaich's prepare_imgfs, there are 3 possible options:
prepare_imgfs [yourROM.bin] will produce imgfs_raw_data.bin and imgfs_removed_data.bin
prepare_imgfs [yourROM.bin] -nosplit will produce imgfs_raw_data.bin and an empty imgfs_removed_data.bin
prepare_imgfs [yourROM.bin] -acer will produce imgfs_raw_data.bin and an empty imgfs_removed_data.bin, but this one is the only which has worked for the i60x
d) Now if you use viewimgfs then the dump directory will be created and the files will be extracted. It is only after this confirmation you may be assured the ROM extracted has the correct structure for manipulation. I got so much trouble using the old version of cvrtbin, that I am telling you to run these extra steps.
Now try to run the xipport tool on the above *.nb0 file. and tell us if you were successful. At this point if you are not able to run the xipport tool, then you may not have something usable. RomMaster and dumprom/dumpromx are also alternatives for working with xip modules, please remember all these tools are highly experimental and not bug-free!
trinca