Database Users

use mkrom to cook 4.00.xx rom, a tutorial and bug report

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

Actual size of file (extracted using dumprom) is not OK

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).

Tool to create custom Ext roms for Alpine

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.

Samsung i718 (i710, i718+) ROM Kitchen

Hello!
Thanks to ppl from this forum I've managed to assemble from various sources files required to dump, build and flash back to device WM6 English ROM. It is not a "plug & play" style kitchen yet, so I call it "ROM Kitchen essentials"
Most of files are made by other people. Mine part was converter and flasher hacking. As for now, you have to edit dumped ROM absolutely manually. There are no support for initflashes.dat automatisation. You may want to use rgucomp to make changes to default.hv and user.hv.
Thanks goes to (not in any order )
trinca
mamaich
bepe
itsme
faria
double_ofour
yhauwang
and many others...
Actual version is 0.1 and RAR archive is about 50Mb.
All required files (including WM6 Eng ROM distribution and flasher) can be downloaded from:
h**p://www.r*pidshare.com/files/47189318/Juggler_Samsung_WM6_Eng_ROM_Kitchen_0.1.rar.html
You also may want to download original WM6 English ROM from here:
h**p://r*pidshare.com/files/45439904/Juggler_WM6_i718ZMGF4_PDA_Eng.rar.html
And radio firmware (required for some i71x to work with WM6):
h**p://r*pidshare.com/files/45950071/Juggler_WM6_i718ZMGF4_Phone_Eng.rar.html
In case somebody don't know how to flash Samsungs i71x:
Make backup!
Have your your firmware at hand so in case of troubles you can flash your original firmware back!
Turn off device.
Disable all ActiveSync connectivity (usb, comm, etc).
Run flasher and click start.
Hold "down" button on device and turn it on while holding "down".
Flasher recongnize it and start to flash.
After flashing make a hard reset.
If GPRS/EDGE do not work your radio firmware is not compatible with new WM6. You have to go back to your original firmware or flash new radio!
To flash new radio firmware you should have SPECIAL FLASHING CABLE for samsung phones! It is not the one that comes with device!
Now you have options to buy such cable, build one yourself, flash your original fimware back or continue using WM6 without GPRS/EDGE - it is your choice.
So - to flash WM6 you need usual usb cable. New WM6 probably work with your radio. If not - you should flash radio!
Special flashing cable is the cable with USB-Serial adapter or plain serial cable:
h**p://www.fonefunshop.co.uk/datacables/samsung.htm
Search for UNLOCK / FLASH CABLES and you'll see
"Samsung D800 - T809 - E900 - D900 USB Cable
This cable is needed to unlock / flash the Samsung D800 - T809 - E900 - D900 etc."
Notice the difference with the usual USB cable supplied with device!

Have you read my thread on the Samsung i60x?
Hello, there,
Please refer to this thread:
http://forum.xda-developers.com/showthread.php?t=316647
It seems very familiar to the i600. I will download your image just for the sake of taking a look... The ROM with header B000FF is prepared with the Romimage tool from the MS WCE IDE and is named the Run-time image, the nb0 ROM (that works with the WM5 kitchen) is prepared by Romimage by splitting the nb0 ROM in 128 KB records, a header is added containing start address, record length and Checksum 32. Then all this chunks are added together and compressed with another tool named compbin, the "encryption" you are seeing is no other than the aftermath of this compbin tool.
If you read myu thread you will find I was able to extract the flat image using cvrtbin (also another 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) and so on.
Making the ROM back to the B000FF format is going to be the trouble. Again, read the thread.
There is also an excellent article on Mobilepro BIN roms made by cmonex, you can get a copy of that tutorial inside his Romtool packege, 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 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

Thanks trinca, at least I have something to read to start with. But the first thing a can't figure out how correctly RIP rom image from EXE file and then after modifing it PUT it back to flasher. There s.b. some proprietary tools for samsung phones or pdas.

Extracting the i718 ROM image: a suggestion
JugglerLKR said:
Thanks trinca, at least I have something to read ...
Click to expand...
Click to collapse
My friend, we are all navigating uncharted waters..., this requires some research, and the courage to flash the phone with the outcome of your research.
Please read my post:
http://forum.xda-developers.com/showthread.php?p=1371344#post1371344
It will give you a hint on how I found out how to extract the O/S payloads for the i60x, pretty sure it may work for your model as well. A quick look to your executable shows the arrangement may be similar, I would say for the i718, the O/S ROM is located last as it is on the i60x, starting at address 0x01620000 now, just by looking for the end indicator (following the string B000F, 0x0A, 0x00000000 which is the ROM start address, 0x00CA5F03 which should be the offset -little endian-, actually would be 035FCA00), however be noticed the runtime image is compressed using compbin during preparation, therefore I would guess is a little more beyond. You may have to do some research here.
Start by cutting the area surrounding such an offset and use viewbin to determine the offset length and cvrtbin to find if your cut was successful.
BTW it would be nice to find a tool to just decompress B000FF Runtime ROMS. (differently of what it does cvrtbin converting and decompressing Runtime images)
One other thing you may do is to use xdautils, you may find those here:
http://wiki.xda-developers.com/index.php?pagename=XdaUtils.
This collection of utilities has pdocread allowing you to extract the contents of raw partitions in the pda. Make sure to use the handle to extract each raw partition.
Regards,
Trinca

I had no success with cvrtbin. How to decompress image after compbin? I've found pdocread and put it to phone, but it won't work :-( Are there any tools to dump ROM to flash card or something like that?

JugglerLKR said:
I had no success with cvrtbin. How to decompress image after compbin? I've found pdocread and put it to phone, but it won't work :-( Are there any tools to dump ROM to flash card or something like that?
Click to expand...
Click to collapse
To decompress the image:
Get a tool named viewbin, also part of the MS PE, run it on your file and will tell you the start address and the offset of the img files. THen use this information with cvrtbin. If viewbin reports the start address is 0, then use 1 in cvrtbin, otherwise the extraction will fail.
To use PDOCREAD, you run it from your computer, it will install itsutils.dll in your phone and you must accept this in the smartphone. Your phone must be unlocked to do that and the policies set to allow unsigned applications to be installed in your phone. TO accomplish the above you need to modify the registry on the phone. See how it is done here:
http://www.modaco.com/index.php?showtopic=244205
TO dump the ROM with PDOCREAD, see a detailed procedure here:
http://wiki.xda-developers.com/index.php?pagename=Hermes_HowtoDumpRom
Be informed some phones like the i607 require the disk kernel handle, reported with pdocread -l, if you follow the procedure in the above link with no results, then add the disk handle.
Wish you good luck....

CAn Anybody help PLEASE????
I have a i718 but was bought in China and the OS is in Chinese. The blur me can only read English. Is the ROM in English? If I were to download it (still struggling now with the russian words), how can I change it? All I need is the phone to be in English. I do not need to improve anything as WM5 is good enough. I know I am a newbie and I might not be in the right thread. Can anybody please help? Any links to show "how-to-change the ROM" would be most appreciated. Thank you in advance

Your phone is also known as i710
Your phone Samsung i718 is the chinese version of the Samsung i710, all you have to do is to install the phone serial/modem drivers from the companion CD and place the phone in bootloader mode. If you get the ROM package cited above in the first post of this thread by JugglerLKR you will find complete instructions on how to download the ROM into your phone.
Good Luck!

Thank you
Thank you very much for the quick response sir! Really appreciate it. I finally managed to download the ROM and will give it a go this weekend. Wish me luck. I will be reading more to make sure I am doing the right thing as I am definitely a nOObie. First time flashing a phone .
I looked at the CD that came with my phone and the only thing I see is the ActiveSync 4.2. Worse of all, everthing seems to be in Chinese. Guess I have to do more research to see where I can get the drivers you mentioned. There are also alot of things I do not understand like bootloader, how to do a hard reset, etc. I will continue searching and reading and will post the development of my virgin "flash" as I move along.
Thank you once again.

Trinca - so I dumped my ROM from device to .raw files. What can I do with them now? viewbin shows only zeros on b000f .bin image extracted using winhex from .exe

Use Mamaich's ROM Kitchen
You can find instructions to do some cooking and tools here:
http://forum.xda-developers.com/showthread.php?t=249836
This is self-explanatory, tell me if this is enough or you need some extra info. Once finished, the trouble would be to put that back in B000FF format for flashing, as there is no tool to do that yet, and you can't just download a raw image back into the phone. The Runtime image is formed as follows:
Byte---->--1--2--3--4---5--6--7--8---9--10--11--12--<----------- 128KB------------>
Record 0> 42-30-30-30-46-46-06 <Start add> <lenght of ROM> -----------------(42-30-30-30-46-46 = B000FF in ASCII ; 06 = end of header B000FF)
Record 1>--<Address> < length > < CHKSUM32 > <----Chunk of Raw image-->
Record 2>--<Address> < length > < CHKSUM32 > <----Chunk of Raw image-->
" "
" "
V V
Last Rec>-00-00-00-00--00-00-00-00--00-00-00-00
I am doing some crazy splitting and Hex scripts to achieve that, but it is a pain in the neck. So I have decided to make a proggie to help me out with that. Please see the thread
http://forum.xda-developers.com/showthread.php?t=316647
on the 2nd post you will see what I am talking about.
Regards,
trinca

Tried viewbin on my extracted from .exe bin file - Image Start = 0x00000000, length = 0x02C1D3E0
Start address = 0x00000000
Done.
Looks like something is missing. Also cvrtbin is not working also, as it cannot accept 0x00000 as start adress

JugglerLKR said:
Tried viewbin on my extracted from .exe bin file - Image Start = 0x00000000, length = 0x02C1D3E0
Start address = 0x00000000
Done.
Looks like something is missing. Also cvrtbin is not working also, as it cannot accept 0x00000 as start adress
Click to expand...
Click to collapse
Start address = 0001ffe0

So, How to convert dumped LZX packed rom to B000F format for flashing to device?

How to convert dumped LZX packed rom to B000F format
Please refer to my thread:
http://forum.xda-developers.com/showthread.php?p=1392761#post1392761

I am unable to download your file (can you post it on rapidshare ou megaupload?). I am in the same situation as well but I appiled the english patch from asukal and Buzzlightyear and it worked .. I now have a device in english ... I am waiting for the firmware in english.. I have wm6 roms in chinese that I have not tested it ...
I also have a i710 rom but it's also a .bin file dumped from a i710 device ...
Hope this helps,
-Hau

I have uploaded several files... Can you tell me which one you have trouble with?
trinca

Oops ... My message was intended for Juggler uploading his ROM ...
Thanks,
-Hau

Thanks to trinca and bepe, mamich and many others i've managed rom kitchen essentials - look at first page.

i downloaded your flasher but why when i run i718ZMGF4_PDA_Eng, i click detect but nothing detected....
phone is on and connected via active sync

The B000FF bin format detailed

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!