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.
Related
OK, I'll start by saying sorry for my stupidness and thankyou for listening to my plea.
I downloaded Jeff's XDA special edition .exe file and unzipped it to a Dir seeing all the files needed to upload a new ROM to my XDA.
I (in all my wisdom) decided to run the osimagetool with the --register and proceeded to right click on the nbf 30mb rom image and selected burn...thinking this was the way to do it (not even trying to run the original exe)
The "programme a" program started and started updating my xda. It started off updating and after a few seconds i heard the "BLIMP" of the activesync telling me it has disconnected, then another blimp telling me it had restarted and re-connected to active sync, but the loader on the screen quickly zipped to 100% done and told me to remove and reboot the xda. The xda however was telling me "upgrading... It will take about 5 minutes". Urk
Now im left with an XDA that sit's on this upgrading screen even after reboot of it.
OK... ive done wrong.. im silly... would any one step up and help me out here (BIG PLEASE AND TY also). Ive got an XDA serial cable sitting here next to me as well as the usb cradle (which im sure wont help now the xda cant run active sync)....
Ideas? Can i run the original rom uploader (xredit?) rather than osimagetool with the serial cable to upload either the new rom i have or the rom i backed up of my old device before doing all this (yes i did back it up to my harddrive first - phew?).
Thanks for reading, and i hope someone can point me to a place in the forum where all people like me end up, or even better send me an email pointing me in the right direction.
Thank you! (email Tony at [email protected])
Note: my original version was 3.17.03 and the "programme a" upgrade program said it was upgrading to 3.16.
can you tell me what splitrom says about the nk.nbf that is now in the 'english' subdirectory of the path
pointed to by the registry key "Software\\XDA Developers\\OsImageWriter", "Programme A Path" ( in current-user )
thanks for coming back to me.
unfortionately, i dont have perl installed on my windows xp machine so the batch file you linked to do doesnt work. If you have a link for a perl install anywhere I'll be happy to install and run it.
In the key you mentioned, here is the value: D:\XDAtools-Jeff\binaries
The directory i unzipped Jeff's version of your tools to.
Im not sure if you perl script does other things, so in the meantime, i'll go and try and find perl (im sure ive installed it on a work machine i had years ago - seem to remember adding local path variables for it)... i'll check my cd archive for it.
Thanks for the help, much appriciated
Tony.
perl can be obtained from either http://www.cygwin.com/setup.exe or http://www.activestate.com/Products/Download/Download.plex?id=ActivePerl
cheers, i'll dl then run the script....
n1 guv
C:\Documents and Settings\tkett.ADPLATES>D:\splitrom.bat
Can't locate List/Util.pm in @INC (@INC contains: C:/Perl/lib C:/Perl/site/lib .
) at D:\splitrom.bat line 86.
BEGIN failed--compilation aborted at D:\splitrom.bat line 86.
^^
Thats the error message i get when running that perl script.
Ive searched the hdd for Util.pm and its sitting in my c:\perl\lib\sgi dir
Things just arent going right for me at the mo.
this module is standard with perl 5.8, with perl 5.6 you have to install
it manually.
as a quick fix, you may also just add a 'min' function manually
Code:
sub min {
my $min;
for (@_) {
$min= $_ if (!defined $min || $_ < $min);
}
return $min;
}
and uncomment the line
Code:
#use List::Util qw(min);
C:\Documents and Settings\tkett.ADPLATES>D:\splitrom.bat
Usage: splitrom <romimage(s)> [options]
-wx xipchain where to write xipchain
-wo osrom where to write output image
-wb bitmap where to write bitmap
-wl bootloader where to write bootloader
-rl bootloader which bootloader to use for NBF
-n nbfinfotext what NBF header to use [ex: PW10A1-EN
-ri nbfinfofile or where to read NBF header info from
-wi nbfinfofile where to save NBF header info
-rx xipchain where to get xipchain from
-rb bitmap where to get bitmap from
-rm [email protected] insert new romsection.
-ob offset where to find the bootup image
-oe offset the end of the desired os image ( def
0000 )
-t NBF | B000FF | NB? | IMG type of result image (default is NB1)
^^^^ Ive put your routine in replacement of that line and am given the options above when running splitrom now. What parameter would you like me to run ?
As always.... a big thanks for the help.
Tony
Itsme, thanks for your interest in my problem. And im very glad people like you are around to help
I have however and thankfully repaired the fault.
Here, (for other newb's like me that get stuck) is how i done it:
I had already backed up my ROM using the osimagetool program to a nb1 file on my pc called "oldrom.nb1". Now because my XDA wasnt booting into Pocket PC windows, i couldnt use active sync to sent the rom image I backed up, back to the XDA...so I had to go and buy a cheap SD reader from my local Dixons store and run osimagetool again. This time writing the rom i had backed up to the SD card in the new SD reader.
Then I rebooted the XDA into the bootloader (hold down the top power button and do a soft reset) and selected to reflash the XDA using the SD card.
If you havent already backed up your rom from your xda to file, then I presume, you have to find another person with an XDA so you can download thers to your SD card (once your in the bootloader menu, press the contacts button to get the options to dump their rom to your card). OR find an NB1 file on the internet that matches your phone version.
These may be simple instructions for most of you, but i've seen a few posts that directly relate to the problem i had, and saw people crying for help, just like i did...hopefully this will help those few.
I did also have a serial cable, and im sure there is a way to upload roms you have on your pc to the XDA via that (using the xda developers old rom tool), but im afriad i didnt read into that after finding out this method. (this way may be better for the skint people who dont want to buy an SD reader, but can get hold of a serial cable for cheap)
REMEMBER FOLKS
It was silly of me to try and flash the device in the first place without reading loads and loads of entries on these forums and really finding out what is going on instead of just flashing blindly in the hope that it would work first time.... please dont follow my lead. :shock:
Thanks again for your help Itsme...and one last question... do you think that with that registry entry as it was above, that i can try again with the .exe jeff made (possibly downloading it again in case of corruption)
(yes i am a glutten for punishment)
Tony
still I'd like to know what went wrong in your case.
can you type 'splitrom nk.nbf' ( in the 'english' subdirectory )
sure:
D:\XDAtools-Jeff\binaries\English>splitrom.bat nk.nbf
this rom seems to be 3.17.03 ENG 2003-05-15 o2euro
this bootloader seems to be V5.15 2002-06-06 20:29:17
no bitmap found
80000000 - 80040000 -- bootloader 0 files 1 modules
80040000 - 8026a804 -- kernel 13 files 11 modules
802c2000 - 8057d330 9 OS 15 files 32 modules
80580000 - 8075a69c 8 SHELL 79 files 27 modules
80780000 - 80a13b04 7 BROWSING 9 files 14 modules
80a40000 - 80d8a33c 6 COREAPPS 46 files 30 modules
80dc0000 - 80ebd150 5 SYNC 12 files 22 modules
80ec0000 - 810388e0 4 24MAPPS 13 files 13 modules
81080000 - 81348248 3 24MCONSUMER 69 files 1 modules
81400000 - 81401484 -- xip chain 8 xip entries
81440000 - 817f6f14 1 MISC 209 files 40 modules
81940000 - 81d2d2b5 -- operator rom 81 files
Tony.
ahhh... haNG ON.... the one i used was in the .exe's folder.. not jeffs tools folder:
D:\XDA-developers-SER-v12\English>splitrom.bat nk.nbf
this rom seems to be 3.16.52 ENG 2003-03-10 XDASER-12
this bootloader seems to be V5.22 2003-05-15 17:46:55
no bitmap found
80000000 - 80040000 -- bootloader 0 files 1 modules
80040000 - 8026a804 -- kernel 13 files 11 modules
802c2000 - 8057d330 9 OS 15 files 32 modules
80580000 - 8075a69c 8 SHELL 79 files 27 modules
80780000 - 80a13b04 7 BROWSING 9 files 14 modules
80a40000 - 80d8a33c 6 COREAPPS 46 files 30 modules
80dc0000 - 80ebd150 5 SYNC 12 files 22 modules
80ec0000 - 810388e0 4 24MAPPS 13 files 13 modules
81080000 - 81348248 3 24MCONSUMER 69 files 1 modules
81400000 - 814019a4 -- xip chain 10 xip entries
81440000 - 817f6f14 1 MISC 209 files 40 modules
81800000 - 818e0c14 10 XDA_DEVELOPERS1 13 files 0 modules
81940000 - 8198b6e5 -- operator rom 20 files
819c0000 - 81ee9a58 11 XDA_DEVELOPERS2 202 files 0 modules
hence the 3.16 now.
Hi Ajkett,
Thanks for sharing your knowledge of how to resolve your problem with us. I have however used a new 64 mb sd card to flash my old rom (3.16) to it before trying out the Jeff rom kitchen exe and thank god things are fine for me. Now I have bought a cheap 6 in 1 card reader/writer and would like to keep the old rom in a safe place in my hard disk hence freeing my sd card so that I could use it. I have read those threads in the rom tool section many times and still can't work out how to use the osimagetool. When I clicked on it, it gives me the interactive screen but always do not read my sd card. Even with the card reader, it seems to "think" that the sd card is unformatted and ask to format the card for me. Now the question is whether the rom is inside or not? How can I use the rom tools to read the sd card and copy the rom to the hard disk? What does a rom file appear as? Is it like the nk.nb1 file created in Jeff's rom kitchen?
Cheers
Vic
ahhh your trying to read the rom from the sd card after dumping it to the sd card from the xda?
the way i got it onto my harddrive was without an sd card. Just run the osimage tool and select the xda current memory as the source and then type c:\oldrom.nb1 as the destination.... it will use activesync to read the rom straight from the device.... you dont need the sd card to back it up.
Then when i ****ed my xda up, i run the osimage tool again and wrote from source - oldrom.nb1 to the sd card reader to a formatted sd card.
When it writes it, it gets rid of all the formatting so you wont be able to see whats on it on your pc....the only thing its good for then is to use on the xda to overwrite the rom, until you format it again that is.
Its not like a file on the sd card... its like a bootdisk with the rom written in a way that the xda will understand that its a bootdisk and will boot from it to overwrite itself... like the file is in raw format... not a nb1 file or anything (looks like lots of gobbledigoop) and the pc will not read it.
Thanks Ajkett,
Thanks for your kind reply anyway.
Got it done. The osimagetool could read but I did not write the path correctly; it has to be rom.nb1 apparently for it to work. I even used the card reader and managed to write the rom again the same way to my hard disk. I hope this is the correct way of doing it and it seems that the rom.nb1 file on my harddisk is about 30.5 mb which is probably about right for the old 3.16 rom I had dumped onto it by the XDA.
What puzzles me is that if it can read as source rom.nb1 file when you say you rewrite it to the sdcard, it becomes mumbo jumbo again but it should flash ok within bootloader mode via the XDA. Is this correct?
Cheers
Vic
yep your correct... even thogh it doesnt write a nice 30mb rom.nb1 file to your sdcard, the xda still reads it to boot from.... it must need it a raw info.
Hi, I am trying to extract a file (actually, cplmain.,cpl) from a rom image. It all seems to work fine, but the size of the extracted file is lesser than the right one.
File seems to be truncated.
I did:
1) get the "B000FF" file (.bin), 24,856,907 bytes
2) Since dumprom seems not to "like" this format, I converted it using splitrom:
perl splirom.pl file.bin -wo file.rom
3) I don't know which format it generates to file to, but now dumprom works:
dumprom -d result file.rom > res.txt
4) A few snapshots of the file res.txt, regarding the file cplmain.cpl:
NOTE: section at fee73000 iso 00044000 for cplmain.cpl
806f5fe4 - 806f5ff0 L0000000c modname cplmain.cpl
8072d000 - 8076fe1c L00042e1c o32 region_0 rva=00001000 vsize=00042e1c real=02e61000 psize=00043000 f=60000020 for cplmain.cpl
80770000 - 8079e600 L0002e600 o32 region_3 rva=00048000 vsize=0002f000 real=02ea8000 psize=0002e600 f=40000040 for cplmain.cpl
808c7650 - 808c76bc L0000006c e32 struct 4 objs, img=212e entrypt=0000b408 base=02e60000 v4.20 tp9 cplmain.cpl
808c76bc - 808c771c L00000060 o32 struct cplmain.cpl
80a36870 - 80a36ff6 L00000786 o32 region_1 rva=00044000 vsize=00001800 real=01cd3000 psize=00000786 f=c0002040 for cplmain.cpl
80a4d0d8 - 80a4dffd L00000f25 o32 region_2 rva=00046000 vsize=00001ca8 real=02ea6000 psize=00000f25 f=40002040 for cplmain.cpl
80be2ed8 - 80be2ef8 L00000020 modent 20 00000005 01c3f9e1932529f0 486400 8119a000 cplmain.cpl
...............
5) Last line's "486400" is actually the *right* size of the file, but the real size of the extracted file (in directory "result") is 477,184.
I have not checked other files, since this is the one I am interested in.
Any idea?
Thanks in advance
XIP files would report incorrect size. Because they are XIP
If XIP files report wrong size (I guess you mean inside the very NB1 file), how can one fix this?
Spasiva!
I guess i am not using the same alignment of blocks in the reconstructed .exe file, as was used for constructing the rom.
it is not a really important issue, that the file is not exactly the same size.
there are also sections missing in the rom, that were in the original file, like the relocation information.
the main use of dumprom extracted modules, is that you can reverse engineer them with something like IDA. .. not that they are useful as real executables.
willem
Hi Willem,
Well the thing is that I need this file to be the right size. I agree that size is not important (that's what I actually say to my girlfriend ;-) ) as long as the extracted file's is greater, not lesser (which implies truncation) than the original's. The problem is that the file I got is smaller, so there is some missing data in.
Actually, I copy cplmain.cpl to the ppc as cplmain2.cpl, I do:
ctlpnl cplmain2.cpl,2 (for instance)
and it simply does not do anything.
Excuse my ignorance, but, what is IDA?
Dank u vel
IDA: http://www.datarescue.com/idabase/
you can't use a file extracted with dumprom on another device.
most executables and dll's ( and cpl's ) are fixed to work at a specific location in memory in one specific ROM. you can't use it on another device, it will most likely have a different memory layout.
willem
If you have two versions of the same DLL that are different only in code and data base addresses, you can restore the .reloc section and get a working DLL. I've wrote a simple program that when used with any relocation rebuilder tool would produce a working DLL. And even if DLL is not working, it is much easier to decompile it with IDA because it uses relocation information internally during analysis.
The DLLs should be exactly the same, for example they can be taken from the same ROM builds that differ only in language (of cause in this case DLLs should not be localized).
I am trying to extend the bepe's kitchen in order to include support for Mio A701 and Mio A700 (Scoter platform). Some of you are already aware of it.
Our DOC architecture is quite simple:
- DOC's static RAM: G3/G4 Initial Program Loader
- DOC BDK0 Binary partition that keeps the Bootloader
- DOC BDK1 Binary partition that keeps the Microsoft Initial Program Loader (also called SPL over these forums, isn't it)
- DOC BDTL0 TrueFFS partition that keeps the WM5. This partition is exactly 50MB (0x3200000 bytes). It is a MSFLSH50 image containing a 0x400 bytes header followed by 4 subpartitions.
- DOC BDTL1 TrueFFS partition that keeps the user data in a FAT32 filesystem.
BDTL0 has 4 subpartitions:
- Part00 Starts at offset 0x400 inside the MSFLSH50 image. Unknown format, it has 'SRPX' signature at offset 0x40.
- Part01 Unknown format, it has 'SRPX' signature at offset 0x40.
- Part02 IMGFS segment.
- Part03 segment with an empty FAT16 filesystem used for padding the size of 50MB required for the BDTL0_MSFLSH50 partition.
I can extract everything but those files stored in Part00 and Part01. IMGFS can be easily extracted and built with the IMGFS_tools by Mamaich.
In HTC devices the kernel and critical drivers are stored in 2 XIP chains, but these files do not seem to be XIP chains since they are compressed or encrypted. Thew SRPX signature is not very common, Buzz Lightyear talked about it here:
buzz_lightyear said:
hi willem,
hmm... I know, it's a problem...
wm5 compression signature is 'SRPX' (as far as I remember coz i'm 1 month away from it). it's XPRS other way around. XPRS is some standard compression. I guess it is also included in cecompress.dll from CEPB5.
...just a thought... maybe a bit of help...
is it also used in smartphones with wm5?
thanx
buzz
Click to expand...
Click to collapse
After that no one else has talked about this kind of segments or SRPX signature.
If you want to take a look at the unknown segments/subpartitions of the MSFLSH50 WM5 image then you can download a dump of Part00 and Part01 from here.
I need to extract and insert files into this segments, can you help me with any related information about it please?
Thanks a lot,
Oki
Hi Oki,
where did yo dig that post about SRPX out, please )))
Anyway, i still have no info about that, but i'm wondering, what would you like to put inside...
Oki said:
Microsoft Initial Program Loader (also called SPL over these forums, isn't it)
Click to expand...
Click to collapse
))) it actually is SPL
buzz
It is nice receiving a quick answer here. I have already posted this in your site.
It seems that Microsoft calls the SPL as MS IPL. It does not matter, in the MiTAC world bootloader is known as UBoot and has a nice menu for selecting the part that you want to flash so we only need to create a customized MSFLSH50 image and that's all, the OS is upgraded.
I want to create a customized image for my device so I need to apply the certmod.dll patch described by mamaich. Any other solution?
The kernel file, some critical DLLs and boot.rgu among other important files are in those two segments, so in order to create a customized OS I will need to access these files and replace them.
Let me ask you where did you found the SRPX signature? Is there any other device with this image format?
Thanks,
Oki
Oki said:
It is nice receiving a quick answer here. I have already posted this in your site.
Click to expand...
Click to collapse
)))) maybe because i was on this site, when i've got notification...
But i first answered at buzzdev.net ))))) LOL
"Hi Oki,
so SRPX... )) i saw that very long time ago in some Himalaya WM5 ROM. i really can't remember, where exactly.
all i know is, that XPRS is a kind of compression, so i thought that time, that XPRS is actually SRPX other way around.
Then, as other things poped up, i somehow forgot about that totally ))
CU
buzz"
For Oki: SRPX signature found on ATOM LIFE
Hello Oki,
The XDA Atom Life has MSFLASH50 format as well as SRPX signature for the kernel part. I was wondering what is the start of the segment for the MSFLASH50...? I couldn't seem to get msflshtool.exe to work with this ROM. It keeps on saying not a MSFLASH50 format.
BTW, your Scoter Kitchen tools worked on XDA ATOM, we are trying to port the files from XDA ATOM LIFE into our ROM... Fortunately you have covered this format so we can extract its contents...
Jiggs
request for other srpx-tool
Hello, and sorry for digging in this old thread.
I have a XDA Comet aka Atom Life and the XIP is SRPX compressed like Jiggs described.
I'm trying to update the Kernel.
I use the SRPX tools from Scoter kitchen. With MSFLSHTOOL i get 2 XIP and 1 imgfs part.
I use SRPX2XIP for the second part and the XIP is 1728 KB.
If I change back with XIP2SRPX the new part is only 1442 KB.
So I write back this part to my ROM image and the image doesn't boot.
Is this an error from SPRX tools or did I miss something ?
I can't find an other tool for that job. Google gives only a hint to "sushi-repeat-containing protein" but i guess that's not the information i realy need.
May be someone can enlighten me.
Attached a link to Atom Life XIP (If someone is interested)
http://rapidshare.com/files/79622471/LifeXIP.rar.html
scorpio16v said:
Hello, and sorry for digging in this old thread.
I have a XDA Comet aka Atom Life and the XIP is SRPX compressed like Jiggs described.
I'm trying to update the Kernel.
I use the SRPX tools from Scoter kitchen. With MSFLSHTOOL i get 2 XIP and 1 imgfs part.
I use SRPX2XIP for the second part and the XIP is 1728 KB.
If I change back with XIP2SRPX the new part is only 1442 KB.
So I write back this part to my ROM image and the image doesn't boot.
Is this an error from SPRX tools or did I miss something ?
I can't find an other tool for that job. Google gives only a hint to "sushi-repeat-containing protein" but i guess that's not the information i realy need.
May be someone can enlighten me.
Attached a link to Atom Life XIP (If someone is interested)
http://rapidshare.com/files/79622471/LifeXIP.rar.html
Click to expand...
Click to collapse
Did you do a hex comparison between old and new XIP? you could try dumping and rebuilding first without modifications, and see the difference. vivi was able to sort this thing with his asus p525.
tjlabais said:
vivi was able to sort this thing with his asus p525.
Click to expand...
Click to collapse
Thank you for the hint.
After comparing the Comet-, the Atom Life- and the rebuilded file, I'll try to hexedit the beginning and fill the end of the rebuilded file to match the right filesize.
Will report later.
edit:
after simply cosmetical changes with a hexeditor the files are identical.
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
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