Let me first explain my story first, i wanted to change the LG manufacturer logo writing a new one to /dev/block/mmcblk0p22, on reboot, my logo
was shown perfectly, but inmediatly, rebooted again and again while the button lights flashing like crazy, so i assume there was some sort of CRC check on the logo or something. Bootloader and recovery mode were not available, the only option was download mode. After entering download mode i wrote a .kdz firmware to it using the kdz tool, but it did not help because the boot logo partition was not ever updated. Here's how to fix :
- Remove battery, remove usb cable.
- Press Volume Down and after that connect the usb cable, it will enter download mode.
- Extract/Decrypt the .kdz firmware of your choice using LGExtract.exe (LGExtract-0.2.1.7z), it will create a .cab file.
- Extract the .cab file and it will show, in my case, two files :
E430_TMO_EU.dz
LGUP_V3_v0.2.6.0.dll
- As shown here, the dll contains lists of partitions it will not write to, depending on the kdz options as shown on the ida dissasembly :
look on file for image 1.png and 2.png
- Open the dll with an hex editor, in my case i used ultraedit, and change string in hex :
look on file for image 3.png
to zeros :
look on file for image 4.png
and save the dll file, keep the same name.
So what we have done is just to remove BOOT_LOGO_IMAGE partition from the list of partitions the kdz tool will not try to write to.
- Now we need to create a new .cab file, easiest for me was to use Cab Maker freeware tool.
- After you have created the .cab file with the dz firmware file and the modified dll ( don't rename ) inside it, run
UpTestEX_mod2_marwin.exe go to "Encrypt cab file to kdz file", choose the new .cab file, and hit Encrypt cab->kdz button.
look on file for image 5.png
- Flash the new modified .kdz.
- Profit.
can you explain how did you change the contents of BOOT_LOGO_IMAGE? also I would like to note that it is not actually a "partition" but a binary file with a size of 512kb, it's ARM and THUMB code.. so please provide any discovering that you have made for this logo modification procedure. maybe we can find out why it's bricking the phone, but if you say you saw your modified logo, tell us how you made the modified logo! or if you have specs for the binary file understanding.
thanks!
gattytto said:
can you explain how did you change the contents of BOOT_LOGO_IMAGE? also I would like to note that it is not actually a "partition" but a binary file with a size of 512kb, it's ARM and THUMB code.. so please provide any discovering that you have made for this logo modification procedure. maybe we can find out why it's bricking the phone, but if you say you saw your modified logo, tell us how you made the modified logo! or if you have specs for the binary file understanding.
thanks!
Click to expand...
Click to collapse
i extracted the binary from /dev/block/mmcblk0p22 using dd, it created a file of size 4 194 304 bytes, it is a .rle file, i seen
no code whatsoever, after that i converted the rle to .png using "boot_screen_logo_creation_package.rar"
that it includes two tools and two .bat files, i had to modify one of them to match the resolution of the small LG screen to :
@ECHO --------------------------------------
@ECHO Converting RLE file to image file
@ECHO --------------------------------------
@ECHO .
@ECHO Using %1
@ECHO .
@ECHO [ STEP 1] - converting to RLE to RAW format...
@bin\5652rgb -rle < %1 > %1.raw
@ECHO .
@ECHO [ STEP 2] - converting to Final iamge format...
@bin\convert -depth 8 -size 240x320 rgb:%1.raw %1.png
@ECHO .
@ECHO --------------------------------------
@ECHO DONE!!!
@ECHO --------------------------------------
then opened the .png file with photoshop, changed it, saved, and ran the other
.bat file to convert it back to .rle :
@ECHO --------------------------------------
@ECHO Converting image file to RLE file
@ECHO --------------------------------------
@ECHO .
@ECHO Using %1
@ECHO .
@ECHO [ STEP 1] - converting to RAW format...
@bin\convert -depth 8 %1 rgb:%1.raw
@ECHO .
@ECHO [ STEP 2] - converting to Final RLE...
@bin\to565 -rle < %1.raw > %1.rle
@ECHO .
@ECHO --------------------------------------
@ECHO DONE!!!
@ECHO --------------------------------------
then used dd again to write the new .rle file to the /dev/block/mmcblk0p22
partition or whatever it is, yes, the logo showed perfectly, but rebooted
instantly, showed it again, rebooted, and so on over and over while lights blinking like crazy...
While i was triyng to unbrick it i downloaded a very old firmware so the files from the dz could be extracted and the
22-BOOT_LOGO_IMAGE.img file was of size 524.288 that matched the one i had extracted byte per byte, rest of the bytes
of the 4 Mb file were filled with zeros, i found no code whatsoever.
I will provide the files :
-------------------------------------------------------------------------------------------------------------------
22-BOOT_LOGO_IMAGE.img - boot image partition extracted from old kdz firmware.
boot_screen_logo_creation_package.rar - original boot_screen_logo_creation_package.
image.rle - image extracted with dd from /dev/block/mmcblk0p22
image.rle.png - new image i created in .png format.
image.replacement.rle - new image i created in .rle format, this is the one i dumped to the partition back with dd.
-------------------------------------------------------------------------------------------------------------------
Hmmm
freeusername said:
i extracted the binary from /dev/block/mmcblk0p22 using dd, it created a file of size 4 194 304 bytes, it is a .rle file, i seen
no code whatsoever, after that i converted the rle to .png using "boot_screen_logo_creation_package.rar"
that it includes two tools and two .bat files, i had to modify one of them to match the resolution of the small LG screen to :
@ECHO --------------------------------------
@ECHO Converting RLE file to image file
@ECHO --------------------------------------
@ECHO .
@ECHO Using %1
@ECHO .
@ECHO [ STEP 1] - converting to RLE to RAW format...
@bin\5652rgb -rle < %1 > %1.raw
@ECHO .
@ECHO [ STEP 2] - converting to Final iamge format...
@bin\convert -depth 8 -size 240x320 rgb:%1.raw %1.png
@ECHO .
@ECHO --------------------------------------
@ECHO DONE!!!
@ECHO --------------------------------------
then opened the .png file with photoshop, changed it, saved, and ran the other
.bat file to convert it back to .rle :
@ECHO --------------------------------------
@ECHO Converting image file to RLE file
@ECHO --------------------------------------
@ECHO .
@ECHO Using %1
@ECHO .
@ECHO [ STEP 1] - converting to RAW format...
@bin\convert -depth 8 %1 rgb:%1.raw
@ECHO .
@ECHO [ STEP 2] - converting to Final RLE...
@bin\to565 -rle < %1.raw > %1.rle
@ECHO .
@ECHO --------------------------------------
@ECHO DONE!!!
@ECHO --------------------------------------
then used dd again to write the new .rle file to the /dev/block/mmcblk0p22
partition or whatever it is, yes, the logo showed perfectly, but rebooted
instantly, showed it again, rebooted, and so on over and over while lights blinking like crazy...
While i was triyng to unbrick it i downloaded a very old firmware so the files from the dz could be extracted and the
22-BOOT_LOGO_IMAGE.img file was of size 524.288 that matched the one i had extracted byte per byte, rest of the bytes
of the 4 Mb file were filled with zeros, i found no code whatsoever.
I will provide the files :
-------------------------------------------------------------------------------------------------------------------
22-BOOT_LOGO_IMAGE.img - boot image partition extracted from old kdz firmware.
boot_screen_logo_creation_package.rar - original boot_screen_logo_creation_package.
image.rle - image extracted with dd from /dev/block/mmcblk0p22
image.rle.png - new image i created in .png format.
image.replacement.rle - new image i created in .rle format, this is the one i dumped to the partition back with dd.
-------------------------------------------------------------------------------------------------------------------
Click to expand...
Click to collapse
Ok
after playing with the converters and images for a while it appeared to me that the .rle image we get from converter is without 4 byte header (00 00 25 B4)
i'm about to flash edited image with the header
wish me luck
EDIT:
success
the missing header was the check point for lg
also you must ensure the file size is 524,288 bytes
IGGYVIP said:
Ok
after playing with the converters and images for a while it appeared to me that the .rle image we get from converter is without 4 byte header (00 00 25 B4)
i'm about to flash edited image with the header
wish me luck
EDIT:
success
the missing header was the check point for lg
also you must ensure the file size is 524,288 bytes
Click to expand...
Click to collapse
Thanks for the very usefull info, when i get my LGE430 back i will try again, just a matter of adding 00 00 25 B4 to the begginning and padding at the end of the file with zeroes until it is 524,288 bytes of size, right ?
Thanks again.
freeusername said:
Thanks for the very usefull info, when i get my LGE430 back i will try again, just a matter of adding 00 00 25 B4 to the begginning and padding at the end of the file with zeroes until it is 524,288 bytes of size, right ?
Thanks again.
Click to expand...
Click to collapse
correct
np m8
i'm uploading a quick video of booting custom
Edit:
VIDEO PROOF OF BOOTING WITH CUSTOM SPLASH LOGO
sorry 4 quality (recorded with potato from 2008) and shaky hand (i got exited i will not have to look at lg logo no more )
IGGYVIP said:
correct
np m8
i'm uploading a quick video of booting custom
Click to expand...
Click to collapse
Good work, don't think this been done before for lg phones, procedure should be similar for other lgs, great work.
freeusername said:
Good work, don't think this been done before for lg phones, procedure should be similar for other lgs, great work.
Click to expand...
Click to collapse
u see i have this job here ...
i ask for things that are not there
i find bits and pieces ....
"glue" them together ...
and tadaaaaaaaaaaaaa
Anyway it has been done on LG's but not on any of new series that came out with jb 4.1.2 or later (they changed the .rle file that was in ramdisk into partition and added that 4byte check)
nobody managed to convert and boot before
but thanks to teamwork its been done
thank you very much for providing details of your part of process
also if you don't mind i will make a thread so everyone can gain
i have L5 L5 II L7 L4 II L3 L3II in my team to test the header's
IGGYVIP said:
u see i have this job here ...
i ask for things that are not there
i find bits and pieces ....
"glue" them together ...
and tadaaaaaaaaaaaaa
Anyway it has been done on LG's but not on any of new series that came out with jb 4.1.2 or later (they changed the .rle file that was in ramdisk into partition and added that 4byte check)
nobody managed to convert and boot before
but thanks to teamwork its been done
thank you very much for providing details of your part of process
also if you don't mind i will make a thread so everyone can gain
i have L5 L5 II L7 L4 II L3 L3II in my team to test the header's
Click to expand...
Click to collapse
Ya, sure go ahead, it will help a lot of people also feel free to use my post so people can unbrick it if any mistake aslong as it enters in download mode there's hope.
Hi Iggy, since i got a new LG E430 i tried your fix, works as you said
except the image i created would only be showed 1/4 of it, did you use
another software, i tried with other paint software, two color images
of very small size, but nothing, it will just show 1/4 of the screen image
i created, rest was cut to black, did you add anything to the procedure
or used another software to convert it ? The only way to show the full
Getting ride of the 4 byte header would show full image, but then it will
brick the phone and i had to restore it with my procedure, any ideas ?
Greetings.
I figured out something, size of the .rle file before adding the 4 bytes header and the padding can't exceed 7524 ( bytes without header ) ( like the original image ) i made a .rle of around 5k and it worked perfectly. Maybe the 7524 size isn't correct, ill experiment more and keep you posted, maybe the size limit can be lifted somewhere ...
fixed, the first 4 bytes are a DWORD meaning the size of the rle image in BIG ENDIAN.
Hey freeusername!I looked at your work and i appreciate it very much!You did a perfect teamwork with IGGY...i was thinking,why don't ya join our team.We would appreciate very much your presence!Greetings giaki3003
My phone: Lg-e400 with cyanoid rom #15+cyanoid kernel 0.4(@linuxx)+supercharger v6 (@zeppenlinrox)+crossbreeder (edited zip) (@idcrisis)+swap of 50 mb (System) and 693 mb (sdcard) all this for#abetterl3
[OPTIMA TEAM]OFFICIAL MEMBER
giaki3003 said:
Hey freeusername!I looked at your work and i appreciate it very much!You did a perfect teamwork with IGGY...i was thinking,why don't ya join our team.We would appreciate very much your presence!Greetings giaki3003
My phone: Lg-e400 with cyanoid rom #15+cyanoid kernel 0.4(@linuxx)+supercharger v6 (@zeppenlinrox)+crossbreeder (edited zip) (@idcrisis)+swap of 50 mb (System) and 693 mb (sdcard) all this for#abetterl3
[OPTIMA TEAM]OFFICIAL MEMBER
Click to expand...
Click to collapse
hehe i'm afraid you are late
we have kidnapped him already
IGGYVIP said:
hehe i'm afraid you are late
we have kidnapped him already
Click to expand...
Click to collapse
XD!Great minds think alike
My phone: Lg-e400 with cyanoid rom #15+cyanoid kernel 0.4(@linuxx)+supercharger v6 (@zeppenlinrox)+crossbreeder (edited zip) (@idcrisis)+swap of 50 mb (System) and 693 mb (sdcard) all this for#abetterl3
[OPTIMA TEAM]OFFICIAL MEMBER
giaki3003 said:
XD!Great minds think alike
My phone: Lg-e400 with cyanoid rom #15+cyanoid kernel 0.4(@linuxx)+supercharger v6 (@zeppenlinrox)+crossbreeder (edited zip) (@idcrisis)+swap of 50 mb (System) and 693 mb (sdcard) all this for#abetterl3
[OPTIMA TEAM]OFFICIAL MEMBER
Click to expand...
Click to collapse
thanks a lot
Thanks to you, my dead phone is alive.
This procedure works on LG L7 P710, just for the record.
As shown here, the dll contains lists of partitions it will not write to, depending on the kdz options as shown on the ida dissasembly :
look on file for image 1.png and 2.png
- Open the dll with an hex editor, in my case i used ultraedit, and change string in hex :
look on file for image 3.png
to zeros :
look on file for image 4.png
and save the dll file, keep the same name.
So what we have done is just to remove BOOT_LOGO_IMAGE partition from the list of partitions the kdz tool will not try to write to.
- Now we need to create a new .cab file, easiest for me was to use Cab Maker freeware tool.
- After you have created the .cab file with the dz firmware file and the modified dll ( don't rename ) inside it, run
UpTestEX_mod2_marwin.exe go to "Encrypt cab file to kdz file", choose the new .cab file, and hit Encrypt cab->kdz button.
Click to expand...
Click to collapse
Have you investigate other possibilities of this dll, like enabling/disabling to flashing other partitions on devices?
I'm interesting to disable flashing recovery and bootloader (APPSSBL), so maybe I can flash root over untouched CWM with KK for LG l7 II KDZ.
Is it possible?
Thanks
Related
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
Chinese Edition: http://www.coolcode.cn/andot/bin2nb-nb2bin-released/277
Hello, everyone. I find there is no tools can convert bin file to nb file or convert nb file to bin file. so I made these tools: bin2nb & nb2bin. They only can convert os.bin to os.nb, and os.nb os.bin, they can't convert gsm, spl or ipl nb file to bin file.
They are all command line tools, and easy to use.
if you want to convert os.bin to os.nb, you can type:
Code:
bin2nb os.bin os.nb
and then, you will get os.nb file.
when you want to convert os.nb to os.bin, you can type:
Code:
nb2bin os.nb os.bin
you will get the new os.bin file.
The default setting is Typhoon(Feeler/Amadeus), if you want to convert other device nb file to bin file, you can add two parameters:
Code:
nb2bin <file.nb> <file.bin> [offset] [partbytes]
offset is a hex number without prefix, for example, the offset of Typhoon is 80240000.
partbytes is the size of the partition, it is also a hex number without prefix, for example, the partbytes of Typhoon is 1b00000.
Excuse me,
I've a Toshiba G900, I've used the Grab_it tool to create a DUMP of the ROM.
I obtained a "dump.bin" file.
Now I've to create a .nb file from this .bin file.
Do you thing your tool could works?
I've to imput a different code becouse my device is not a Typhoon?
I hope you can help me.
Thanks.
davideuck,
Have you solve your problème? Because i have the same and bin2nb doesn't work for me (My device is a Samsung Player Addict)
Thank,
McCoy.
it doesn't support diamond NB files.... anyway, thanks
Hi mates, does anyone know, where is the operator screen located in the phone ?
By Operator Screen, i mean the wallpaper of the vendor like O2, Vodafone, i-Mate, T-mobile etc. whose ROM, you have installed in your device.
It comes before the Windows Mobile splash screen, after reboot.
I have searched my entire /Windows/ folder, couldn't get hold of it.
if it is before welcome96 than i doubt you can change it without cooking your own rom...
http://wiki.xda-developers.com/uploads/Custom Splash Screens.zip
Complete Guide & Tools To Create Custom Splash Screens - Compiled by Bennec83 from wiki
is this available for any wm5/6 device?
fuzzvirus said:
http://wiki.xda-developers.com/uploads/Custom Splash Screens.zip
Complete Guide & Tools To Create Custom Splash Screens - Compiled by Bennec83 from wiki
Click to expand...
Click to collapse
can you post the link for this thread ?
I hope we are not talkin' about the windows splash screen aka "welcomehead.192"
this what I am talking about
From the read me file inside the zip.
This Can ONLY Be Done On XP (nb_image_converter.exe dont like vista!!)
Firstly create your splashscreens using your favourite picture editor (PSP, Photoshop etc...), both these files MUST be 240x320 and saved as 24bit bitmaps:
Name of Image Size Type Description
* MainSplash.bmp 240x320 .bmp the first splashscreen you see
* SubSplash.bmp 240x320 .bmp the second splashscreen you see
* welcomehead.96.png 320x320 .png the WM splashscreen
Save mainsplash & sudsplash into Custom Splash
Save welcomehead.96.png and paste it into the /windows folder on your device (overwriting the current windows splashscreen).
Copy files "nb_image_converter.exe" & "padding.nb" into Custom Splash. Now run "nb_image_converter.exe" load both images, save them as Main.nb & Sub.nb.
Next open a command window, and place Custom Splash Folder in Root of C:
In the command window type the following:
cd c:\custom_splash (enter)
copy /b Main.nb+padding.nb MainSplash.nb (enter)
copy /b Sub.nb+padding.nb SubSplash.nb (enter)
dir (enter)
The final command (dir) will list the contents of the directory, the filesize of MainSplash.nb and SubSplash.nb MUST be exactly 262144 bytes
or you should NOT continue (would produce possibly FATAL results for the device)
We now need to repackage the two .nb files into a single nbh image so we can flash them, s
1) Start duttys good nbh tool:
2) click the "NB to NBH"
3) Click the First Splash and select the MainSplash.nb file, click the second splash and select the SubSplash.nb.
4) MAKE SURE that Device = HERM200, CID Type = SuperCID and Signature Size = 128
5) Now click the "Generate NBH File" button, save it on your desktop.
The next stage is to flash to the device using CustomRUU, simply place the custom ruu exe file in the same folder as the NBH file we just created and run it.
Select 'autodetect' and flash as normal.
Thanx a lot mate, can i use this on my Universal ? It's resolution is 640 by 480.
Is there any way, i can extract the operator splash screen i.e Main splash, from my current ROM ?
well I won't be able to help here as I have a hermes and I can tell about that. Hoping someone else might help you.
Hi there,
i would like to try to make a hybrid rom with an omnia rom.
Can anyone explain how to extract the exe file.
I downloaded the rom from kaiser rom dev section.
Its the normal update file from Samsung
Thanks in advance
C'mon guys, no one around here knows how to get the rom out of that file?
JeckyllHavok said:
C'mon guys, no one around here knows how to get the rom out of that file?
Click to expand...
Click to collapse
Get winrar or something, right click on the exe and click extract here?
veyka said:
Get winrar or something, right click on the exe and click extract here?
Click to expand...
Click to collapse
thats not the way for Omnia's ROM
the procedure is as follows:
1. check out this post.
2. after step 5, download this and use viewbin.exe to find out the start offset and length of imgfs.
3. use cvrtbin -r -a (start offset, don't use '0x' prefix) -l (length of imgfs, don't use '0x' prefix) -w 32 xxx.bin
4. after this u will get an nb0 file. use nbsplit with -kaiser switch on the nb0 to get xx.nb0.payload
5. use prepare_imgfs.exe xxx.nb0.payload -nosplit
6. use view_imgfs.exe or imgfstodump.exe to get the 'dump' folder.
thats not the way for Omnia's ROM
Click to expand...
Click to collapse
Yes, you can't open the file with winrar or zip.
Its not just a self extractin file.
It doesn't create temp files, too.
JeckyllHavok said:
Yes, you can't open the file with winrar or zip.
Its not just a self extractin file.
It doesn't create temp files, too.
Click to expand...
Click to collapse
check out my post above for the procedure
PS: i didn't learn this procedure myself, so i don't take the credit.
Hey man,
thanks for your answer, but i can't find B000F in the file.
I use WinHex
JeckyllHavok said:
Hey man,
thanks for your answer, but i can't find B000F in the file.
I use WinHex
Click to expand...
Click to collapse
B000FF is in ASCII (text). search again, it must be there 3 times
OK now i found it but i don't understand part 3 of the manual.
The string 0x060000EA3B is in Hex 30 78 30 36 30 30 30 30 45 41 33 42, right?
But i can't find it.
htctouchp said:
thats not the way for Omnia's ROM
the procedure is as follows:
1. check out this post.
2. after step 5, download this and use viewbin.exe to find out the start offset and length of imgfs.
3. use cvrtbin -r -a (start offset, don't use '0x' prefix) -l (length of imgfs, don't use '0x' prefix) -w 32 xxx.bin
4. after this u will get an nb0 file. use nbsplit with -kaiser switch on the nb0 to get xx.nb0.payload
5. use prepare_imgfs.exe xxx.nb0.payload -nosplit
6. use view_imgfs.exe or imgfstodump.exe to get the 'dump' folder.
Click to expand...
Click to collapse
Great! it works for me. In my case I had an img file (I presume that some one extracted from exe). If you run GrandPrix flahs utility and load this .img file you get a _xip0.nb0 that can be used as xxx.bin as stated above.
btw, how can we extract xip? Failed to extract with dumprom/rommaster the payload file generated in step 5...
hey guys,
no luck with the above procedure.
i Made a bin file starting at B000FF and finish after the 12 "00" before
060000EA3B .
But cvrtbin gives the error "Could not allocate memory for raw data"
Please Help
g77 said:
Great! it works for me. In my case I had an img file (I presume that some one extracted from exe). If you run GrandPrix flahs utility and load this .img file you get a _xip0.nb0 that can be used as xxx.bin as stated above.
btw, how can we extract xip? Failed to extract with dumprom/rommaster the payload file generated in step 5...
Click to expand...
Click to collapse
sorry, i didn't work on extrating xip.bin from the 'exe', didn't get time to.
JeckyllHavok said:
hey guys,
no luck with the above procedure.
i Made a bin file starting at B000FF and finish after the 12 "00" before
060000EA3B .
But cvrtbin gives the error "Could not allocate memory for raw data"
Please Help
Click to expand...
Click to collapse
thats the only procedure which should work for u. just follow/read everything carefully and also make sure u downloaded the cvrtbin.exe from the link that i gave (msvcr80.dll should also be there).
Thanks for your answer, i made the mistake that i just cut the unneeded lines and save it as an other filename. When i copy the lines in a new file it workes
JeckyllHavok said:
Thanks for your answer, i made the mistake that i just cut the unneeded lines and save it as an other filename. When i copy the lines in a new file it workes
Click to expand...
Click to collapse
could you zip that .bin up and upload it please?
i'm having a ton of trouble with this
anybody?
sorry to be a nag
There's a thread in modaco.com where they are extracting the ROM with a P535 kitchen. You can join in the funs there
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!