I'm looking for information on the format of Hermes nb files. I am aware that there are perl scripts to unpack these files, but they are not working on a diagnostic image i have in nbh and (converted to) nb format. When I try to unpack the nb file with rdmsflsh.pl I get: could not find imgfs header
The file has plaintext readable strings and begins with 0xB000FF.
Does anyone have technical information on this file format? I know the file is valid since it can boot into the image just fine.
-fluxist
fluxist said:
I'm looking for information on the format of Hermes nb files. I am aware that there are perl scripts to unpack these files, but they are not working on a diagnostic image i have in nbh and (converted to) nb format. When I try to unpack the nb file with rdmsflsh.pl I get: could not find imgfs header
The file has plaintext readable strings and begins with 0xB000FF.
Does anyone have technical information on this file format? I know the file is valid since it can boot into the image just fine.
-fluxist
Click to expand...
Click to collapse
There is a lot of good information about the NBH format (here) that may be useful. Also, the wiki in general may be helpful.
Related
Can anyone tell me where do i go to read on how to edit .bin images and port files from nbf to bin, edit registry in bin?
bin files only with msn messenger most editet
http://www.coolcode.cn/andot/bin2nb-nb2bin-released/277
Convert to NB and Edit NB by RomEdit Tool
Work for me.
Creative7419 said:
http://www.coolcode.cn/andot/bin2nb-nb2bin-released/277
Convert to NB and Edit NB by RomEdit Tool
Work for me.
Click to expand...
Click to collapse
Been looking for this for quite sometime and now its here courtesy of ANDOT(the famous cooking master of Tornado WM6).
Before, converting os.bin to os.nb involves tedious tasks. It involves hex editing and now with a simple typing of correct commands on dos prompt and voila you have a converted os.nb or os.bin file. Thanks ANDOT...
hi all, i have a .nb0 file which extracted from a wm5 ppc phone ( cant remember the model), and i need some help here to view this nb0 and extract some cab file from there.
This .nb0 consist a lot useful softwares, for example, soundcover (background sound during conversation), answering machine, conversation recorder and it works flawlessly on wm5 ppc phone.
Any expert??? please help.
**ok, I found the phone model, its GIGA, this is the nb0 file, latest update from thier website http://www.higiga.com/HigigaFrontStage/event/download/update/V1.12.80.zip
Hi,
Congratulations on extracting an .nb0 file. There are many methods to do so, depending on the device. Out of curiosity, which method did you use? Assuming that you correctly extracted the .nbo file of the CE image, you can treat it the same as an .nb or .bin file. use "viewimgfs *.nb0". the * of course meaning the name of your nb0 file like MSFLSH50_2.nb0, or what ever. This will give you all the files and what not. You can then use the DSMtool by bepe. This will organize all the files into packages. Then you can use cabwiz or some other program to create a cab installer. Good posts to follow are mamiach, bepe, buzzlightyear, and others, if you didn't already know. The dsmtool is found in bepe's WM5 kitchen. the viewimgfs and other imgfs tools were created by mamiach.
Regards,
Jason
thanks for your reply, i will try to use the tools to see whether i can extract anything out of it...thanks again.
I think i have successfully dump the rom to a dump folder, but i cannot see anything but only some dll files, what else i need to do??? do i need to use some tools to convert all these dll files to view the rom content?? please advise, thanks.
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.
Chinese Edition: http://www.coolcode.cn/andot/bin2nb-nb2bin-released/277
Hello, everyone. I find there is no tools can convert bin file to nb file or convert nb file to bin file. so I made these tools: bin2nb & nb2bin. They only can convert os.bin to os.nb, and os.nb os.bin, they can't convert gsm, spl or ipl nb file to bin file.
They are all command line tools, and easy to use.
if you want to convert os.bin to os.nb, you can type:
Code:
bin2nb os.bin os.nb
and then, you will get os.nb file.
when you want to convert os.nb to os.bin, you can type:
Code:
nb2bin os.nb os.bin
you will get the new os.bin file.
The default setting is Typhoon(Feeler/Amadeus), if you want to convert other device nb file to bin file, you can add two parameters:
Code:
nb2bin <file.nb> <file.bin> [offset] [partbytes]
offset is a hex number without prefix, for example, the offset of Typhoon is 80240000.
partbytes is the size of the partition, it is also a hex number without prefix, for example, the partbytes of Typhoon is 1b00000.
Excuse me,
I've a Toshiba G900, I've used the Grab_it tool to create a DUMP of the ROM.
I obtained a "dump.bin" file.
Now I've to create a .nb file from this .bin file.
Do you thing your tool could works?
I've to imput a different code becouse my device is not a Typhoon?
I hope you can help me.
Thanks.
davideuck,
Have you solve your problème? Because i have the same and bin2nb doesn't work for me (My device is a Samsung Player Addict)
Thank,
McCoy.
it doesn't support diamond NB files.... anyway, thanks
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!