Related
Spent a lot of time on it, trying to figure out what went wrong with mkrom when cooking 4.00.xx roms. finally figured it, well, almostly. here is a short step by step tutorial for people who do not want to set up the complicated kitchen but wish to use mkrom as in the good old 3.17 time.
I assume you already know the rom flush process already, if given a NBF file. also you need a linux box with perl.
I know quite a few people struggled and have not had a clue. and I believe there is some bugs in the mkrom package that gives the trouble.
1. download the newest mkrom from http://xda-developers.com/~itsme/download/mkrom_136.zip. this is the only piece of software you would need.
2. unpack it to, say mkrom, directory. then make directories cfg
3. get hold of a copy of rom file and its corresponding paramter files. the parameter files can be obtained from the demo kitch download ftp://kitchen:[email protected]/data look inside the "00_base ROM" and the parameter files should be under cfg directory of each rom directory. bascially the parameter files tells mkrom, where to start to put added files and how large space there is. there are two blocks of space that can be used. so the file has format
wincever=4
start1=81740000
size1=00040000
start2=81b00000
size2=003c0000
startbmp=81ec0000
startop=81b00000
the first three lines are same for all 4.00.xx roms, start2 varies for different roms, startbmp is also the same for all roms. startop should be the same as start2. size2 will be startbmp-start2, remember they are all in hex. you can calculate how large space there is once you get hold of the start2 parameter.
anyway, put the parameter files under the mkrom/cfg directory, with name "params"
4. copy a rom file (.nbf), say rom.nbf, into mkrom directory and run "./setup rom.nbf". this will creates several files under cfg.
5. mkdir a directory mkrom/romfile, enter it and make another directory file , then type "../dumprom ../cfg/rom.nb1 -4 -d file"
here comes the first bug. the setup.sh tells you that dumprom can only be used in windows box. but in fact, there is a compiled dumprom for linux in the directory (you might need to set it to be executable though). however, this linux version does not put extracted files into the "file" directory as it is supposed to, instead it just write file as "file\xxx" where xxx is the actual file name extracted from rom. it is a bug but as long as we know it, not a big deal. the is someone posted a correct version of dumprom in this forum though.
6. you should be able to find three files (or with the "file\" prefix added) with name default.fdf initobj.dat initdb.ini. these are the three files that needs to be process as indicated by setup.sh. follow the instruction to create the default.reg initobj.txt initdb.ini and copy them to cfg directory.
7. make a directory mkdir/files. you are ready to create a clean rom now by running "./mkrom output.nbf", the created output.nbf should be fine.
So far so good, followed the instruction of mkrom. next would need to add our files. then comes the problem. if you add files into the mkrom/files directory, and run "./mkrom output.nbf" again, it is almost definitely that the created rom is bad. I am not 100% sure why, but here is what I believe:
the mkrom script scan files in the "files" directory and put files in there into the "files1", "files2" directory, each of them is supposed to fill the two space in rom starting from "start1" and "start2" in parameter file. the size of files under "file1" should be less than "size1", similar "files2" and 'size2". when mkrom does this, it is highly possible that the three critial files "default.fdf, initobj.dat, initdb.ini" are placed into "files2" directory instead of "files1" directory and renders the rom bad.
here is what I did
edit the mkrom.sh, delete the line that splits files in "files" into "files1, files2" directory. change the three lines that convert the three critial files so that these three files are created in "files1" directory instead of "files" directory. then put your files into "files1" and "files2". just be careful, keep the size less than specified by "size1" and "size2".
then you can run "./mkrom.sh output.nbf" as before, and the resulted rom will be good.
hope this helps. however still a couple of problems
1. the fdf2reg.pl won't recoganize the default.fdf extracted from 4.00.21 rom or 4.01.00 rom
2. if i change the content of initobj.txt, the created rom won't boot. I might have done something wrong in initobj.txt though. but I used to be able to do this for 3.17 rom
3. I did not try to modify registry, as my only purpose is to put my files into ROM to save space. all registry can be done later by installing the software and choose not to overwrite existing files in ROM. must simpler.
the unix version of dumprom does not decompress files, that is why your default.fdf etc seem corrupted.
this is because I only have the decompression code in the form of a binary library, which I have not figured out how to link to under linux.
the only use of dumprom under unix is to find the offsets in rom where filepointers to default.fdf etc should be patched.
I should maybe disable the '-f' option in dumprom for the unix version, to make things less confusing.
but it looks to me that the dumprom under linux worked for pre- 4.00.16 rom. only not for after 4.00.21 roms. so are they different?
maybe the default.fdf was not compressed in the 3.x roms?
I am quite sure it does not work for compressed files under linux - I just did not implement the compression routines.
dumprom worked with 4.00.05 4.00.11 4.00.16 roms. I cooked 4.00.11 and 4.00.16 roms, and the rom was fine. I never used windows box during the process. only when i tried 4.00.21 and 4.01.00, there was error. anyway, i don't care, since I need as much rom as possible and 4.00.11 seems to be the best choice for me.
thanks for writting mkrom, a terrific tool. I don't like the way xda-developers.com promoting kitchen but not mkrom. mkrom is much simpler to setup and run, as long as you know about linux. the kitchen is much more complicated to get it to work and most people don't actually need such flexibility I believe.
ok i installed cygiwin and was with u till step 5, then i am lost.. when i run step 6 dumprom (in DOS) gives me an ewrror here atr the first few lines from dumprom( wiht latest ATT official release)
img 00000000 : hdr=8c0a1000 base=8c078000 commandlineoffset=8c077fe0
img 00040000 : hdr=800cdde0 base=80000000 commandlineoffset=7fffffe0
img 00180000 : hdr=8024db88 base=80000000 commandlineoffset=7fffffe0
img 00380000 : hdr=8039b334 base=80000000 commandlineoffset=7fffffe0
img 00670000 : hdr=80be2c40 base=80000000 commandlineoffset=7fffffe0
img 00c00000 : hdr=80e99400 base=80000000 commandlineoffset=7fffffe0
img 01050000 : hdr=813efc74 base=80000000 commandlineoffset=7fffffe0
img 01400000 : hdr=815d2ba4 base=80000000 commandlineoffset=7fffffe0
img 015f0000 : hdr=815f0650 base=80000000 commandlineoffset=7fffffe0
img 017c0000 : hdr=81bba0a4 base=80000000 commandlineoffset=7fffffe0
ERROR: could not find pointer for ofs 8c0a1000
invalid romhdr ofs 8c0a1000
ERROR: could not find pointer for ofs 00000000
7fffffe0 - 80000000 L00000020 unknown 30315750 452d3142 412d474e 2d30332e 2d353030 62373239 2d2d2d2d 2d2d2d2d
80000000 - 80000004 L00000004 romsection id=ea0003fe
80000004 - 80000040 L0000003c NUL
80000040 - 80000048 L00000008 'ECEC' -> 8c0a1000
errorsgalore...
so help me here how do i make sure the files extracted are all good also the size (as per ) windows explorer is 33+ not sure how all has been installed in the 32mb rom
did you get default.fdf initobj.dat initdb.ini out of dumprom. dumprom also reported tons of errors but as long as you get the three files out, it is ok.
Dumprom tries to figure out for each byte in the rom what it does. If it doesn't know it says 'unknown' this is not an error, just that dumprom could not determine the use of this byte. The 'could not find 00000000' message means that it encountered a NULL pointer somewhere in rom where it did not expect it, the other one is a pointer to RAM, which dumprom does not know exists. You can safely ignore these errors.
Dumprom was initially written to assist in figuring out what I did not know about the rom, so it tries to figure out stuff that is unknown. Later I added the code to extract files to it. Maybe I should split dumprom in one research tool, to do a detail examination of the rom, and one tool to only extract files.
Most files in rom are compressed, that is why they are more than 33M when uncompressed.
ok i understande the messages...
now here is what i did
ran ssnap and got a picture of the OS and did a compare and have a list of entries i want to add to registru and a folder with bunch of subfolders that need to be added on install
not sure how step 6 goes.. to convert the files to .reg and .txt and how/where do i add my files and registry entries....
any tips...
update...
i did fdf2reg and made a .reg file added my entries in there and then ran reg2fdf to recreatre the fdf...
i hope this is right now i need to fig out how to specify where the files i want added are to be copied i mean some go into windows some in new filders that need to be created...
plz tell me how to go forward.
you don't need to re-create the fdf file again, mkrom does it for you, you only need to take care of the default.reg file under cfg
I am not sure whether you can put files under directories other than \windows only. I did not try that. I suppose all files under /files1 and /files2 go to \windows directory just they happen to locate in different memory location in ROM
Hi folks,
I've had some sleep now so am editing the original posting to make it clearer and give due credit!
The attached application is based mostly on Wilems (itsme) tool (http://nah6.com/~itsme/cvs-xdadevtools/xda2nbftool/alpinenbfdecode.pl) - so the bulk of the credit goes to him. All I did was work out the checksum algorithm; but as I really suck at Perl, my tool is written in C.
Anyway, this tool allows the decoding of ms_.nbf extended rom files to their header and fat16 image (which can be mounted and modified).
The sneaky part of this tool then allows these two components to be encoded to give a working rom file that can be uploaded to the Alpine device using the usual ROMUpgradeUt.exe application.
Now, PLEASE USE WITH CARE - as I won't be held responsible if using this tool results in a dead Alpine device! Usual disclaimer ..... Also this is an alpha version, so any feedback would be appreciated.
The tool is command line based (no GUI yet - although I will do that soon).
Run the tool without any parameters to get the help - but here's a quick guide:
1. Extract a suitable upgrade (e.g. XDA_IIi_Upgrade_v1.11.162.exe) to a directory like c:\upgrade
2. delete nk.nbf & radio_.nbf files
3. put the alpine_ext_rom_tool.exe in this directory (c:\upgrade)
4. run it to extract the fat16 file and header :
alpine_ext_rom_tool.exe -d -n ms_.nbf
5. this creates ms_.fat and ms_.hdr
6. edit the ms_.hdr (see comments in this file for instructions)
7. mount ms_.fat and add/remove files as needed (updating Config.txt)
8. delete the old ms_.nbf file in c:\upgrade
9. run the tool to create a new nbf file:
alpine_ext_rom_tool.exe -e -f ms_.fat
10. make sure the files been created
11. run ROMUpgradeUt.exe or MaUpgradeUt_noID.exe to update the extended rom on your alpine!
Let me know how you get on if you do decide to give it a go!
Cheers
There's a new GUI version of this tool now available here : http://forum.xda-developers.com/viewtopic.php?t=34783&highlight=
Splash screen
Well as a follow up and after some experimenting - seems like the splash screen is hidden within the extended rom somewhere.
I used the Imate and O2 extended roms as bases, and even after deleting all cabs, etc, within these files and placing my own cabs within - I still get a splash screen which is different between. That is the Imate one using the imate extended rom and the o2 one using the o2 extended rom.
I assume that this is hidden somewhere, but not as a file. It would be nice to be able to edit this as well. Does anyone have any information on where the splash screen may be?
Although I haven't tried using a new, clean, FAT16 image file ... maybe that would give just the default windows mobile splash.... hmmmm
Hey ho
splash image
Splash screen is appended at the end of the FAT16 image.
The size of the fat file extracted from the nbf file is 0x18C0000 and the last 0x40000 bytes of this file are the splash screen in nb format.
So theoretically if you replace the last 0x40000 bytes of the fat file with your chosen splash screen (format as nb using nb_image_converter_859_418.exe) then that's the splash screen you'll get on startup....
Hmmmmm, quiet round here ain't it? Maybe I'll just talk to myself :wink: - more than likely this has all been figured out before ... perhaps I should've done some searching before I started?
Hey ho
hey ho! ;o)
bro, you've made a cool proggie!
don't be disappointed by no answers... maybe there are not so many Alpine users out there...
keep it up and take care...
buzz
Hi Buzz,
Dakujem - thought I was talking to myself there for a little while .... not unheard of!
I suppose until hacking these roms becomes simpler (at least until there are some nice gui programs) it'll remain a bit of a niche market.
But I'm learning to live with the short-comings of the XDA 2i ... nearly :shock:
;o)))
nemas za co... ;o)))
buzz
I don't think the same as bal666.. In fact there are many people waiting for their Alpine 's to be mungled and squeezed just like the BlueAngel There are just so many stuff for the BlueAngel and it makes some people buy BlueAngel. I believe there are a lot of non-posters here that are waiting for some stuff like yours <g>
Hi all
Yes i'm another, doing the rounds of the forum's and threads looking for a convienient solution to the extended ROM. I been sitting on the outer cause i don't think i can make a worthwhile contribution to your quest.
I'm just not prgram savy
Good at following instructions thow!!
I'm desperate to build a nice extended ROM with all the features of Special edition you guys produced some time ago.
Could you point me to a CABS listing that can tell me whats worth retaining/ updating/removing. I'm using the Dump ROM out method.
Which incidently is giving a little grief with format of the created files, ext .img. Any thoughts
So keep up the good work, i'm sure theres a stack of people counting on your good work.
Mike
Hi SubZero & Mike,
thanks for that - makes it seem somewhat more worthwhile. I actually wrote the tool out of boredom, and the fact that I continually play with my XDA and wanted an easy way to restore all my programs and settings; rather than doing it manually.
Mike, there are a number of pages/sites with extended rom cab listings - like http://www.dmmh.nl/xda/ although I couldn't get into it today.
As for your dumprom problems ... sorry mate I've never used it - although there is a thread somewhere here with that (although I'm sure you've seen it) ...
Anyway, the next program will do the same as now but also allow the alteration of the built-in splash screen image - might as well now I've started. But I doubt I'll do a gui version, it's just not worth the aggro!
Cheers
Your right link seems to be down, any other sites would be good.
How could we, the alpine community convince you to develop a GUI??
Think of the incredible personal prestige and total job satisfaction you would get from this.
This is a terrible suck job if you hadn't realized by now.
Thanks
Miket
I thought I'd post this here as a link to a thread I started on updating the XDA2i extended ROM (you are not alone in your crusade)
http://forum.xda-developers.com/viewtopic.php?p=171104#171104
There are lots of bits inside there but the method pointed to works if all you want is to modify the Extended ROM.
http://en.pdamobiz.com/en/forum/forum_posts.asp?TID=373&PN=1
Have fun,
Graham.
Checksum Algorithm
Hi GBird,
thanks for that.
Also I've had a few people ask how the checksum is calculated, so the code is included below. The alpine_crc_key_lookup uses the same keyset as the blue angel - see nbfutils from wilem (itsme); and I suspect the algorithm is the same as well (I'm not going to go and look ... too much effort involved).
Generate a crc for the fat16 image portion of the extended rom and add this to the crc for the header portion (without the checksum field, meaning only the first 120 bytes). This gives you the key you should be using to encode the whole extended rom.
Enjoy!
Bal
--------------------------------------------------
DWORD alpine_crc(
char data[],
int data_len,
DWORD crc)
{
int i = 0;
DWORD crc_new = crc;
/***********************************************************
* Calculate the CRC for this data stream
* Based on a decompilation of the RUU.dll loc_1000C174()
***********************************************************/
for (i = 0; i < data_len; i++) {
crc_new = (crc_new >> 8) ^ alpine_crc_key_lookup((data & 0xFF) ^ (crc_new & 0xFF));
}
return(crc_new);
}
Dear bal666
As a newbee, please instruct in detail the upgrade process from step # 6, 7 & 9
wait for your news
thanks for your hard work
Hi Harry
simple instructions would be as follows:
1. Extract a suitable upgrade, preferably from your provider to a directory like c:\upgrade. Mine is O2, so I use e.g. XDA_IIi_Upgrade_v1.11.162.exe
2. delete nk.nbf & radio_.nbf files from the c:\upgrade directory
3. put the alpine_ext_rom_tool.exe in this directory (c:\upgrade)
4. Open a dos window and cd to c:\upgrade
5. Run alpine_ext_rom_tool.exe to extract the fat16 file and header, like this : alpine_ext_rom_tool.exe -d -n ms_.nbf
6. this creates ms_.fat and ms_.hdr
7. download and install "Extra Drive Creator Pro" from http://www.extradrivecreator.com/download/
8. In Extra Drive Creator add a "File to Drive" using the ms_.fat file in the c:\upgrade directory
9. Add/remove files cab files as needed
10. update the Config.txt file on the mapped drive, open it in a text editor and you'll notice it contains a list of cab files and the order to install them
11. delete the old ms_.nbf file in c:\upgrade
12. run the tool to create a new nbf file: alpine_ext_rom_tool.exe -e -f ms_.fat
13. make sure the ms_.nbf file has been created in c:\upgrade
14. run ROMUpgradeUt.exe to update the extended rom on your alpine!
Hope that helps
Bal
Hi there,
Do you know if there is an issue with the size of the files that are added to the extended ROM ie can you use the whole 24MB?
Using the SD card method with the ntrw.exe file, you are limited to 20.8MB otherwise you start have corrupt CAB files in your extended ROM.
Hi Pug,
alot of my understanding of the Alpine device is based on supposition and blind experimentation .... :shock:
But, from what I believe the extended rom nbf file to do; I reckon you can use the whole 24Mb to store cab files. Let me explain:
The length and structure of the so-called fat16 image that exists in the nbf file maps rather nicely to the rom structure of the Alpine (and I assume the same holds true of other 64rom devices) - see the following web page for what I mean http://wiki.xda-developers.com/index.php?pagename=AlpineRomStructure
If you take an extended rom nbf file and decode it, you end up with a file (excluding header) that is layed out as follows:
0x0000000 - 0x17FFFFF = extended rom fat16 image
0x1800000 - 0x187FFFF = 0xFF padding
0x1880000 - 0x18A57FF = Splash image in nb format
0x18A5800 - 0x18BFFFF = 0x00 padding
This is an exact match to the rom structure - so the so called fat16 image contains alot more than just the extended rom files!
Errrr, to get back to your point - I think you can fill the whole 24Mb with cab file; but best approach would be to try it ....
Bal
Pug,
just had a thought about what you said. The size of the fat16 image (as a whole) is 24Mb on the nose.
So with overhead of MBR, FAT tables, etc - you're probably looking at something like 23.7Mb of storage ....
Thought that's what you'd say so I'm experimenting now.
23.4MB didn't work so I'm trying to slim it down now. Shouldn't have to slim it down more than about 0.5MB so I'm reckoning that 23MB will be the limit.
Now I've put it on a diet I'm trying to find files to beef it up from 21.5MB, suprising how difficult that actually is.
Will let you know when I've found out.
For the record though.....YOU ROCK.
Why thank you
Let me know how it goes ... I'm trying to get some time to update the tool to extract and insert splash screens too - but I have some real work to do too!
Thought I'd try and help out a little here:
0x0000000 - 0x17FFFFF (Extended ROM Fat 16 image)
This is a size of 25,165,824 bytes (24Mb)
FAT tables are usually in 512 chunks and each 512 chunk gives you a pointer to 256 blocks of memory. The blocks are usually in 1,024 bytes (1Kb) though this can vary (in a full file system the blocks are usually much larger).
In a standard OS there are usually two FAT tables (as a backup system) so I will assume that there are two here also.
On top of this there will be at least one block taken up with the directory structure (more if you have subdirectories).
So if my numbers are close then you will need 96 * 2 512 byte FAT tables (This makes an overhead of 98,304 bytes).
On top of this there is 1,024 bytes for the root directory giving a total overhead of around 99,328 bytes.
This leaves you with 25,066,496 bytes for data (23.9 Mb).
You may lose an extra 512*32 (16,384) if there is an MBR on the front of this, though I would think that would be elsewhere.
The rest of the space you will lose through slack space (1,024 blocks that are not completely filled by the data you are using) so if you have a large number of files this theoretical 23.9Mb may drop significantly.
For instance, the Config file is probably around 600 bytes so you will lose the rest of the 1,024 block (424 bytes) as slack space.
If any of this helps you then great
Hope you have fun,
Graham.
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.
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
What is a B000FF file
The B000FF .BIN file is a format used in some windows mobile phones and in several Windows CE devices. It is a wrapper format used to write flash memory areas on the phone that allows to save space (unused memory areas are skipped) and to make flashing more "reliable" (trough checksum verification in the bootloader but in case of failure as you can imagine the "reliability" translates into a bricked phone). What those memory areas contain depends on the manufacturer that trough the bootloader decides where to write them; anything could be present in the files, even the bootloader itself or other sensitive areas that should not it's better to not mess with so when working with those files make sure you check what's inside. Tools like OSNBtool can help to identify the content of files because they find the OS.NB inside the BIN file and write separately the data that comes before and after it but remember that just like all the other current tools OSNBTool doesn't handle RESERVED REGIONS that are areas in the OS.NB that must stay in fixed positions so some of the content that ends up removed from the os.nb could be reserved regions content that must be put back in the file for it to work on the device.
The B000FF file format
The format is composed of the following two structures (and obviously the file data):
Code:
struct BIN_HEADER {
char[7] Signature; // B000FF\n signature
DWORD ImageStart; // Image Start
DWORD ImageLength; // Image Length
};
Code:
struct BIN_BLOCK {
DWORD Address; // Address where the block should be flashed
DWORD Size; // Size of the block that is being flashed
DWORD Checksum; // Checksum (CRC32) of the block data
};
The file starts with the header structure, followed by N number of block structures each one followed by the respective data of the block and a termination block composed of a block structure where address/size/checksum are set to 0. Note that some blocks can be missing and depending on the bootloader the region could be left untouched or erased (erased bytes could have any value, it depends on the type of memory (NAND erased bytes have FF value) and on the bootloader).
How to check the integrity of a B000FF file
Read the header, read the first block and check that its address equals ImageStart, check that the termination block is present and check that the last block before the termination block address equals the sum of [ImageStart]+[ImageLength].
How to convert a B000FF file to an absolute binary format file (NB0)
Allocate an empty file with the size of ImageLength and write each of the blocks' data inside at the absolute file position of [Block Address]-[ImageStart].
The missing blocks are usually empty areas (or at least that's what are in the files generated by microsoft tools) that could be ignored by the bootloader or erased (with the bytes values depending on the memory type and on the bootloader code) but in case you encounter them make sure you investigate what those missing belong to, it could be a fancy way for the manufacturer to leave some areas reserved for the phone or bootloader and should be left untouched when re-creating the file.
Current tools available to work with BIN files
CVRTBIN/VIEWBIN to convert the file to a "ROM" file (ABX/NB0/ROM memory image, call it how you want)
OSNBTOOL (suggested, because it lets you figure out what is in the file) that can do the following operationg:
split (-sp): finds the OS.NB inside the BIN and saves the OS.NB and the unrecognized data that comes before and after it
generate BIN (-2bin): converts a file to the BIN format and has two important switches, one to set the start address of the data and one to tell it to not write the header (so that you can example append other BIN data in front of it)
fix BIN header (-fixbinheader) scans the BIN file and adjusts the imagestart and imagelength according to the content
Sorry for my stupid question..
I want to ask about getting *.bin files (B000FF) or *.nb0 from an upgrade *.exe files
I usually can get the file *.bin or *.nb0 manually search for the signature of the *.bin or *.nb0 then cut upgrade *.exe files using a hex editor (discard unused)
or directly using the osnbtool.exe with -sp argument
but i can not get *.bin files or *.nb0 of this exe Upgrade:
Samsung Intrepid
My question, are the *.bin files or *.nb0 on inside the upgrade *.exe of samsung Intrepid is encrypted?
or upgrade *.exe remove the signature of the bin or *.nb0? so we can't get the *.bin or *.nb0 files?
Thank you in advance..
tj_style said:
Sorry for my stupid question..
I want to ask about getting *.bin files (B000FF) or *.nb0 from an upgrade *.exe files
I usually can get the file *.bin or *.nb0 manually search for the signature of the *.bin or *.nb0 then cut upgrade *.exe files using a hex editor (discard unused)
or directly using the osnbtool.exe with -sp argument
but i can not get *.bin files or *.nb0 of this exe Upgrade:
Samsung Intrepid
My question, are the *.bin files or *.nb0 on inside the upgrade *.exe of samsung Intrepid is encrypted?
or upgrade *.exe remove the signature of the bin or *.nb0? so we can't get the *.bin or *.nb0 files?
Thank you in advance..
Click to expand...
Click to collapse
It's not encrypted because the OS.NB starts at 0x529ED34 (actually 0x339000 bytes before, at 0x4F65D34, due to reserved regions but tools would have problems with those) and is in clear sight. After dumping the OS.NB you need to read every 2048 bytes and remove 64bytes of data or tools won't work with it. If you don't know how to do that I already dumped everything and I can upload the files. In case you want to find out more about the rest the ROM file format used by that phone has a "SMDHEAD1" header and starts at 0x987534.
airxtreme said:
It's not encrypted because the OS.NB starts at 0x529ED34 (actually 0x339000 bytes before, at 0x4F65D34, due to reserved regions but tools would have problems with those) and is in clear sight. After dumping the OS.NB you need to read every 2048 bytes and remove 64bytes of data or tools won't work with it. If you don't know how to do that I already dumped everything and I can upload the files. In case you want to find out more about the rest the ROM file format used by that phone has a "SMDHEAD1" header and starts at 0x987534.
Click to expand...
Click to collapse
Whoa.. thank you very much for your answer..
if i open with reshacker or 7zip instead hex editor, i look too the files, so i can extract only the ROM File.
but i always get error on getting imgfs and xip from the ROM file.
now i know as your reference, it must split the data and extra of os.nb.
now i can use the NBSplit.exe with argument -data 2048 -extra 64 right?
i never know about the "SMDHEAD1" ROM File Format, are that's new file format of ROM?
tj_style said:
Whoa.. thank you very much for your answer..
if i open with reshacker or 7zip instead hex editor, i look too the files, so i can extract only the ROM File.
but i always get error on getting imgfs and xip from the ROM file.
now i know as your reference, it must split the data and extra of os.nb.
now i can use the NBSplit.exe with argument -data 2048 -extra 64 right?
Click to expand...
Click to collapse
yes. I uploaded the correct os.nb file here in case you have issues (you have to use osnbtool -sp on it to remove the reserved regions)
tj_style said:
i never know about the "SMDHEAD1" ROM File Format, are that's new file format of ROM?
Click to expand...
Click to collapse
Probably, since it seems to use CHS addresses.
airxtreme said:
yes. I uploaded the correct os.nb file here in case you have issues (you have to use osnbtool -sp on it to remove the reserved regions)
Probably, since it seems to use CHS addresses.
Click to expand...
Click to collapse
Thank you very much for uploading the correct OS.NB..
i need this for reference om cooking my ROM..
keep posting about the structure of files that we used on cooking and all other stuff that we use on developing..
very help for newbie like me..
Thank you..
Hi,
I'm new here and an abolute newbie concerning ROM/NK.BIN etc. What I've done so far: created with tool DiskRW from my device the file SMFlash.img. What I now want is to convert this file into a BIN-file, that I can run in the Windows CE Emulator. But I don't know to accomplish this. Who can advise me how to do? TIA
jwoegerbauer said:
Hi,
I'm new here and an abolute newbie concerning ROM/NK.BIN etc. What I've done so far: created with tool DiskRW from my device the file SMFlash.img. What I now want is to convert this file into a BIN-file, that I can run in the Windows CE Emulator. But I don't know to accomplish this. Who can advise me how to do? TIA
Click to expand...
Click to collapse
You can not run a device specific ROM in the emulator. The emulator itself needs its own specific set of drivers for WM to even boot If that was possible, we wouldn't need phones to test custom ROMs on, we could just run them in the emulator ! Not that sweet though....
airxtreme said:
It's not encrypted because the OS.NB starts at 0x529ED34 (actually 0x339000 bytes before, at 0x4F65D34, due to reserved regions but tools would have problems with those) and is in clear sight. After dumping the OS.NB you need to read every 2048 bytes and remove 64bytes of data or tools won't work with it. If you don't know how to do that I already dumped everything and I can upload the files. In case you want to find out more about the rest the ROM file format used by that phone has a "SMDHEAD1" header and starts at 0x987534.
Click to expand...
Click to collapse
Hi airxtreme, can you help me with Gigabyte GSmart s1205 too?
the osnbtool and imgfs tools does not work on the flash.bin. Please point me to the right direction.
many thanks!