Hey everyone
I've been working on learning C++, so I can refresh some of the existing tools, add some nice features, make them adhere more to the standards, etc.
This is the first fruits of my labor, this program analyzes an .dio, .fat, .nbh, .nb, .nb0, or .payload, reads out partition info to the screen, and dumps the uldr.bin, xip.bin, and imgfs.bin partitions. It should be compatible with any HTC ROM, and any other ROM that does not need to be run through nbsplit.
It does so without generating an intermediate .extra or .payload like the mamaich/tadzio toolset, and i've tried to keep an eye on speed, so it should be pretty fast.
Usage is "nbimagetool.exe -c filename.nb" - alternatively you can run the program with no parameters for some help output.
-c switch is optional, it strips the leading free space from imgfs.bin, so that it is compatible with imgfstodump (most IMGFS partitions have free space at the beginning, and the imgfsfromnb tool strips this automatically)
The idea for this tool is mostly to be used in a Kitchen, during the dumping process, for a nice fast dump Please let me know any errors you might run into!
UPDATED! Added .dio and .fat support
.5pre3 here, new support for asus roms
DONE:
* Added .nbh support
* Added .dio support
TODO:
* Add support for .bin
* Fix whatever bugs you might find
CHANGELOG:
.1 Initial Release - supports .nb .payload .nb0
.2 Added .nbh support
.3 Added output of .nbh info when dumping
.4 Added support for .dio and .fat, fixed a bug that might trigger in rare circumstances
Please no feature requests at this time, thanks
Visual example of program usage:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Sample .nbh output:
Thanks Da_G for this new thread
Thanks for the tool da_g.
Does it works for our old is gold wizard too?
Thanks Da_G
Very nice, except, that we DO need nbsplit in most cases (nbsplit -kaiser) -> kaiser, diamond, topaz, blackstone, raphael etc...
Thanks for the tool da_g.
@CRACING:
You tell me!
@adwinp:
I think you misunderstand, when I say it doesn't need nbsplit I mean as a seperate program, it has algorithms to handle the 'nbsplit' process internally, without generating intermediate files and, it automatically detects the 'extra' data so you don't need to feed it parameters like -kaiser, -hermes, etc.
Thanks Da_G... good you are ...
Posted a screenshot that should give a clearer explanation
Congratulations bro
Nice works as always !
Tom
Thanks my friend, nice tool, everything works fine
It's work!!, I have already try with my modified MBR from old Eten M600 ROM payload.
Compatibility Mode: ACTIVE
os.fat opened for reading, size 45914624 bytes.
MBR Signature is a match! Valid .nb
Size of Data Chunk: 512 bytes
Size of Extra Chunk: 0 bytes
Partition 1: BootInd : 0
Partition 1: FirstHead : 2
Partition 1: FirstSector : 1
Partition 1: FirstTrack : 0
Partition 1: FileSystem : 32 (ULDR)
Partition 1: LastHead : 31
Partition 1: LastSector : 1
Partition 1: LastTrack : 71
Partition 1: StartSector(L) : 2
Partition 1: TotalSectors(L): 2302 (1178624 bytes)
Partition 2: BootInd : 0
Partition 2: FirstHead : 0
Partition 2: FirstSector : 1
Partition 2: FirstTrack : 72
Partition 2: FileSystem : 35 (XIP RAMIMAGE)
Partition 2: LastHead : 31
Partition 2: LastSector : 1
Partition 2: LastTrack : 159
Partition 2: StartSector(L) : 2304
Partition 2: TotalSectors(L): 2816 (1441792 bytes)
Partition 3: BootInd : 0
Partition 3: FirstHead : 0
Partition 3: FirstSector : 1
Partition 3: FirstTrack : 160
Partition 3: FileSystem : 37 (IMGFS)
Partition 3: LastHead : 31
Partition 3: LastSector : 129
Partition 3: LastTrack : 39
Partition 3: StartSector(L) : 5120
Partition 3: TotalSectors(L): 78080 (39976960 bytes)
Partition 4: BootInd : 0
Partition 4: FirstHead : 0
Partition 4: FirstSector : 129
Partition 4: FirstTrack : 40
Partition 4: FileSystem : 4 (MS-DOS 16-bit FAT)
Partition 4: LastHead : 31
Partition 4: LastSector : 1
Partition 4: LastTrack : 127
Partition 4: StartSector(L) : 83200
Partition 4: TotalSectors(L): 412416 (211156992 bytes)
Total Number of Logical Sectors: 495614
Total Size of Image in bytes: 253754368
Writing uldr.bin
Writing xip.bin
Writing imgfs.bin
Thanks Da_G for all your hard work.
Great work nice addition to the tools.
Da_G said:
@adwinp:
I think you misunderstand, when I say it doesn't need nbsplit I mean as a seperate program, it has algorithms to handle the 'nbsplit' process internally, without generating intermediate files and, it automatically detects the 'extra' data so you don't need to feed it parameters like -kaiser, -hermes, etc.
Click to expand...
Click to collapse
Yes I did.
Just tested. Very nice piece of work. Except that xip size doesn't match.
Dumps fine, but is bigger than original.
I might've screwed my partition signature.
Anyways, the natural path to follow would be to write
uldr+ xip + imgfs header + imgfs (+extra) --> nb?
Apart from nbh support, you might want to ADD the code into the nbimagetool instead of coding a separate tool.
Why 2 tools when we can have 1?
Everything can be managed via switches, for example
nbimagetool -o outfile.nb(h) -x xip.bin -u uldr.bin -i imgfs.bin ...
;]
If you're really bored, you can also add other sections, like radio, splash.
It's basically the same code, except for different offsets (0x600)
What was the difference in xip.bin's? (Aside from the size) - was it just free space at the end (FF's evenly divisble by sector size) - if so, the existing toolset strips free space from things. I can make the -c switch strip it from xip.bin as well if necessary (although xipport.exe dumps fine with free space left at the end...)
Re: .nbh/.bin support, yeah, I plan to add it into the tool rather than a seperate tool
Da_G said:
What was the difference in xip.bin's? (Aside from the size) - was it just free space at the end (FF's evenly divisble by sector size) - if so, the existing toolset strips free space from things. I can make the -c switch strip it from xip.bin as well if necessary (although xipport.exe dumps fine with free space left at the end...)
Re: .nbh/.bin support, yeah, I plan to add it into the tool rather than a seperate tool
Click to expand...
Click to collapse
Yes, it's just free space.
I've checked every file's hash and it's consistent, so no worries.
I try to use this tool with OS.nb
OS.nb from X1i official rom
Code:
nbImageTool.exe OS.nb
CreateFileMapping() error: 5
Press the enter key to exit.
Da_G said:
@CRACING:
You tell me!
Click to expand...
Click to collapse
Works perfect for Wizard's official OS.nb ( Extracted both imgfs.bin and XIP.bin ) but as of protected OS.nb, only the XIP.bin will be useful.
Extraction of imgfs.bin worked fine using ELF(in) Hybrid Kitchen ( My Fav ).
Extraction of XIP.bin worked fine using bepe's XIP dumping tool.
Thanks....
Best Regards
X1iser:
Are you running in vista/windows 7 with UAC on? It sounds like the OS isn't allowing my app access to the file in the location you have it in. Try running it in administrator mode
It work in administrator mode thanks
Simple question: do you planning to create a multidevice kitchen ?
Related
Edit: New version available! Compatible with Kaiser, Titan, Artemis, Hermes etc.
New version 2.1rc2! This is a major upgrade to version 2.0 (and a bugfix to 2.1rc1). The ImgfsTools now support generating ROMs for Kaiser, Hermes, Titan, Artemis and probably quite some more. All Hermes-specific code was replaced with code working for all devices
The new version is attached to this post.
These are the screenshots of the original version. Have a look:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This is a completely unmodified LVSW edition WM6. It usually has 47 MByte Storage....
What happened? Well, the IMGFS partition (a.k.a. OS.nb) has 8 MByte free space. Until now it was not possible to shrink the IMGFS partiton and enlarge Storage in return, so that space was wasted.
This has changed - now also on the Kaiser!
I modified mamaich's ImgfsTools so that they now create the smallest possible OS.nb from a 'dump' directory, and also write the partition table and MSFLSH header matching the new size. The result is what you see above.
This is an excerpt from the ReadMe file from the new version 2.1rc2:
ImgFS Tools Version 2
================================================================
(Current version: 2.1rc2)
What it is
==========
These little programs help you with cooking your own ROM. They allow you to unpack an OS.nb file into individual files as you'd find them on your device, and to re-pack them into a new OS.nb which you can flash to your device. Of course, betweem unpacking and re-packing, you'll want to add/modify/remove some of them.
The tools are enhanced versions of mamaich's imgfs_tools - a huge Thank You goes to mamaich for creating them, and also for releasing the source code!
The most significant enhancement is that the IMGFS inside the generated OS.nb is no longer of fixed size, but is as small as possible. This means: the more of the unpacked files you remove before re-packing, the smaller it'll get and consequently the bigger your Storage memory will become. Also, the tools are no longer device-specific and should also work other devices than the Hermes.
*** WARNING: ***
Before you flash a ROM created with these tools, make sure you know how to recover from a non-booting ROM! For Hermes and Kaiser, you should install a HardSPL before you use these tools! I accept no responsibility for bricked devices!
Supported devices
=================
These tools have been tested on HTC devices only, and are known to work on Hermes, Kaiser, Titan and Artemis. Other devices were not tested and may or may not work.
If you want to try, I will gladly support you. However, I cannot accept responsibility for bricked devices!
How it works
============
On a high level, this is the chain of actions needed to unpack OS.nb:
RUU-signed.nbh ---(*NBHExtract)---> OS.nb ---(NBSplit)---> OS.nb.payload -->
--(ImgfsFromNb)---> imgfs.bin ---(ImgfsToDump)---> 'dump' directory
At that stage, you will want to edit the 'dump' directory. I recommend using bepe's excellent *Package Tool for this.
The reverse process is:
'dump' directory ---(ImgfsFromDump)---> imgfs-new.bin ---(ImgfsToNb)--->
OS-new.nb.payload ---(NBMerge)---> OS-new.nb ---(*NBHGen)--->
RUU-signed-new.nbh
(The tools marked with '*' are not part of the ImgfsTools, but are also available for free from xda-developers.com. There is also one additional tool, NBInfo, in this package.)
Version History
===============
2007-10-17 2.1rc2
ROMs generated by 2.1RC1 would not boot if created with a certain combination of parameters. Fixed.
2007-10-14 2.1RC1
Major overhaul:
- All Hermes-specific assumptions (like the sector size being always 0x200) are now gone.
- "conservative" mode added to ImgfsToNb and NBMerge
- on devices that have only two MSFLSH flash regions, ImgfsToNb overwrote a few bytes in the XIP section, causing unpredictable results. This was fixed.
- Removed "-emu" support from NBSplit and NBMerge, as this didn't work with WM6 emulator images.
2007-03-18 2.0 RC 2
All tools now linked statically to the MS runtime library, no longer needs DLL. No other changes.
2007-03-18 2.0 RC 1
Initial Release. Starting with version 2 to not collide with mamaich's version numbers.
===================
Enjoy!
Cheers
tadzio
Great job tadzio,
Looking forward to this new tool.
tadzio said:
Have a look:
This is a completely unmodified LVSW edition WM6. It usually has 47 MByte Storage....
What happened? Well, the IMGFS partition (a.k.a. OS.nb) has 8 MByte free space. Until now it was not possible to shrink the IMGFS partiton and enlarge Storage in return, so that space was wasted.
This has just changed!
I modified mamaich's ImgfsTools so that they now create the smallest possible OS.nb from a 'dump' directory, and also write the partition table and MSFLSH header matching the new size. The result is what you see above.
This currently runs on my TyTN with boot loader 1.10 OliPro. I haven't had a chance to test it with other configurations, but I see no reason why it shouldn't work.
I do not plan to offer any cooked ROMs myself, as there are many excellent chefs in this forum already. But I would think a new approach to ROM cooking may emerge: make a ROM as small as at all possible, removing anything that users may not want, and turn every removed feature into a .cab that users can install to Storage (bepe's excellent Package Tool makes this very simple!). This will give maximum flexibility without wasting any memory.
Give me one more day to write up the documentation, and then I'll upload the new Imgs Tools version.
Cheers
Daniel
Click to expand...
Click to collapse
sounds great man,
once your instructions are posted I will use this technique for Black version 1.2.
Well Done,
Cheers,
Well done man
Waiting for your great work....
tadzio said:
Have a look:
This is a completely unmodified LVSW edition WM6. It usually has 47 MByte Storage....
What happened? Well, the IMGFS partition (a.k.a. OS.nb) has 8 MByte free space. Until now it was not possible to shrink the IMGFS partiton and enlarge Storage in return, so that space was wasted.
This has just changed!
I modified mamaich's ImgfsTools so that they now create the smallest possible OS.nb from a 'dump' directory, and also write the partition table and MSFLSH header matching the new size. The result is what you see above.
This currently runs on my TyTN with boot loader 1.10 OliPro. I haven't had a chance to test it with other configurations, but I see no reason why it shouldn't work.
I do not plan to offer any cooked ROMs myself, as there are many excellent chefs in this forum already. But I would think a new approach to ROM cooking may emerge: make a ROM as small as at all possible, removing anything that users may not want, and turn every removed feature into a .cab that users can install to Storage (bepe's excellent Package Tool makes this very simple!). This will give maximum flexibility without wasting any memory.
Give me one more day to write up the documentation, and then I'll upload the new Imgs Tools version.
Cheers
Daniel
Click to expand...
Click to collapse
Brilliant! Truly BRILLIANT!
good job!!!!
That would be great findings for upcoming roms. For curiosity sake, are there any initials for increasing phone storage from extended rom. Cheers.
That's just great... We're all going to run for the smallest ROM possible ! Even maybe strip out Windows Media Player (We all use other players...) and some of the useless aplications (Who uses Solitaire or Bubble Breaker ?)
who uses Solitaire or Bubble Breaker
Hey. Don't knock it till you've tried it!
But I still wouldn't mind if it was in a .cab
Good job buddy... Looking for your good news.
I just added ImgfsTools2.zip to the first post of this thread.
Disclaimer: I only tested this with my Hermes. Please be careful if you use it with other devices. Oh, and it can't hurt to be careful even with a Hermes!
Feedback welcome! If you run into any problems with these tools, please post in this thread!
Enjoy!
Daniel
Am I right that embedding things into the ROM makes them run slightly faster? Some things that everyone will use would be better off kept into the ROM in that case, which would bring in the disagreement of what everyone thinks should be included. It would be very intresting to see if someone can build a completely pure OS though.
Percz said:
Am I right that embedding things into the ROM makes them run slightly faster?
Click to expand...
Click to collapse
Glad you asked.
If by "things" you mean applications, the opposite is true.
As code cannot be executed directly from NAND flash, everything has to be copied to RAM before execution (the term XIP - eXecute In Place - is misleading here. There is no true XIP in a Hermes). Some executables and DLLs are stored as "modules" in ROM, i.e. already prepared to be copied "as is" to RAM. Moving these from ROM modules to normal files in Storage will indeed make them load slower, although once loaded execution will be the same speed.
However, applications are not stored as modules. Even in ROM they are normal files, and speed-wise it makes absolutely no difference if they are loaded from ROM or Storage into RAM.
But there is one more important aspect: the size of the Windows directory. Even Microsoft admits that having 1800 files in one directory slows the device down significantly. And unfortunately, all files in IMGFS are in the Windows directory (with initflashfiles.dat, you can only copy them elsewhere, not move them).
So, if we manage to remove as many files and apps as possible from the ROM (and hence the Windows directory), and package them into .cabs in a way that they get installed into directories other than Windows, I would think we would see some increase in speed, since accessing the Windows directory would be quite a bit faster - and I guess the OS accesses that directory rather often.
At the moment, this is only theory. I haven't tried to prove it yet.
Cheers
Daniel
Great work, i'm looking forward to new roms being cooked with more storage.
sounds like this is what the chefs need
kjs30 said:
Great work, i'm looking forward to new roms being cooked with more storage.
sounds like this is what the chefs need
Click to expand...
Click to collapse
this chef has strapped this carving knife to his waist.
Alcibiade said:
That's just great... We're all going to run for the smallest ROM possible ! Even maybe strip out Windows Media Player (We all use other players...) and some of the useless aplications (Who uses Solitaire or Bubble Breaker ?)
Click to expand...
Click to collapse
Leave few things in there. whats the point of having all that memory with nothing in it. I love bubble breaker.
Also as mentioned it would be great if we can merge ExtRom into main memory.
Nice work!
I'm happy your modified OS.nb boots for everyone
piopawlu said:
I'm happy your modified OS.nb boots for everyone
Click to expand...
Click to collapse
And thanks again for pointing me to the right place (the partition table). Without your help it'd probably have taken me a lot longer!
Cheers
Daniel
rv1nd said:
Leave few things in there. whats the point of having all that memory with nothing in it. I love bubble breaker.
Click to expand...
Click to collapse
The point is that you can decide what you want to put in there without having to cook your own ROM.
Also as mentioned it would be great if we can merge ExtRom into main memory.
Nice work!
Click to expand...
Click to collapse
I'm thinking about that. Should be do-able.
Cheers
Daniel
htc rom tool: new software to deal with ROMs (NEW RELEASE 1.1.4)
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
--------------------------
htc rom tool version 1.1.4
by Dark Simpson
--------------------------
DISCLAIMER: I WILL NOT BE RESPONSIBLE IF YOU BRICK YOUR DEVICE USING THIS TOOL
This small application makes process of working with ROM's for some new HTC devices are bit more comfortable. htc rom tool will contain several instruments to deal with ROMs or it's parts.
Now, these instruments are implemented:
1. ROM builder. With this tool you can build a ROM (*.nbh) from a rom parts (*.nb) in a comfortable interface.
The built ROM is correctly signed (with my own cert), checked for errors and is ready to download into device. The device MUST be CERTIFICATE CHECKING unlocked for this (you need to use HACKED SPL for your device), or you will get an error while flashing (it is not fatal for your device I think, but keep attention on this fact!).
There is a possibility to add new devices to build ROM for by editing program's configuration file. This is described inside the "htcrt.ini" configuration file.
In the next versions these tools will be added:
- ROM extractor (to extract all *.nbh file or only a several needed parts from it)
- Splash tool (to deal with all kinds of ROM splash screens in a comfortable manner).
- ExtRom tool (to extract and rebuild "extended ROMs")
- System tool (to extract and rebuild an OS part and, maybe, to edit some contents inside unpacked system like initial registry and so on...)
---------------
Version history
---------------
1.1.3
Now and later you can get it here:
http://www.real-radio.ru/htcrt/
1.1.0
There is a new, rewritten, fully customizable dynamic engine that allows to add support for almost any of new HTC devices
+ Updating devices list automatically through your internet connection
+ Checking of blocks file sizes to meet specified criteria for device
+ Possibility to pad smaller blocks with 0x00's to the specified size
+ Coloring of block with respect to it's status
+ New checks and configurable warnings to protect from user mistake when building
+ Saving and loading projects
+ Command line support
+ Other additions
You can see other infos in the about - information of the program.
PLEASE HELP TO IMPROVE DEVICES CONFIG FILE: If you have knowledge about internals of htc devices rom files you can help me to improve, test and check different configurations for htc devices or to add new devices into program. If you want to participate please contact me. Firstly, you can check and validate existing config file's entries for different devices. If you want to add new one - I need to know all identifiers and names of all blocks and the default sizes of different blocks (as in the original firmware) if this is applicable to prevent user mistake in future And of course if you want to cooperate with me you woud like to understand syntax of the htcrt devices config ini file
!!! Now I have a big lack of time, and I think that I will be able to start working on devices config file only with second half of January 2008 Now you can start to collect infos, make corrections and additions to config and to debug them without my participation...
1.0.1
- ! Fixed bug with filepaths with spaces in ROM builder
- Added user warning when flashin IPLs or SPL in ROM builder
- Added new devices
1.0
- The initial release
Thanx a lot
Hey guys, I need to know your opinions about this
Write down all found bugs and your wishes here, please...
I'm waiting til you add the extractor and bits (as I havent got any nbh files etc to play with)
But looks very nice and cool
looks nice, could develop into a great tool
Can this tool sign the ROMs properly or the build ROMs r to b used with SSPL?
Yes, this tool signs resulting ROM file with my own certificate and if SSPL is not validating block hashes to be signed with OEM or HTC certificate while flashing (it may check blocks to be signed properly, but not to validate), than it can be used with SSPL. Of course, the CID checking must be eliminated in loader too, or you will need to type in the utility a valid CID.
Note, that with Artemis USPL this utility works without problems.
will the HTC StarTrek support in future?
Yes, soon I will release new config with the following devices:
Artemis
Trinity
Herald
Hermes
Athena
Breeze
Gene
Love
Startrek
So it does not support older htc models like Universal?
Edit: I see the config file only Artemis & Trinity.
If the format of ROM files for devices like Universal is different than of devices I posted in previous topic, then yes, my tool will not support these models...
great job Dark Simpson
Thanks again..!
Dark Simpson said:
...or you will need to type in the utility a valid CID.
Click to expand...
Click to collapse
I could enter in boot mode on my Artemis device and I got follow info:
ARTE1000 HTCE
It's means that my CID key is HTCE?
Thanks !!
Thank u ^^;
Pocha, I think if you can flash ROM signed not by HTC in your apparatus, then you probably:
1. Have bought IMEICHECK unlock
2. Using new shiny USPL
In both cases you can leave CID for 11111111... Else (if your device have standard unmodified SPL) you can't flash ANYTHING except original HTC's (or operator's) ROM and in this case htc rom tool will not help you...
Unfortunatly for me, I bricked my Artemis when I tried to upgrade to WM6 two weeks ago, my Artemis is SIM Unlock and Cid Locked, I bought it with no carrier, and I can't use ROMs in other languages..., when my Artemis is back I will upgrade SPL and I will try your program
Thanks !!
Then try this tool and confirm the results..if u could flash then this is the BIG moment for all of us here.gr8 job simpson
Thanks for this great tool
Attached htcrt.ini with support for the following devices:
Hermes
Trinity
Artemis
Love
Herald
Athena
Kaiser
Elf
Cheetah
Breeze
Excalibur
Oxygen
Startrek
StarTrek log:
ROM build process started...
Ceating temporary unsigned ROM file...
Writing ROM header...
Writing ROM contents:
cWindows.nb: 100%
Preparing destination...
Preparing ROM signer...
Signing ROM and copying it to destination...
ERROR: Signing process is not successful. Signer service
output:
ImageHash version 1.0
ImageHash Error: Invalid value for max packet size.
[there is going usage]
An error ocurred during signing ...
I used the original OS.nb from Dopod P800W shipped ROM (= HTC Artemis) to test your program but found following error:
ROM build process started...
Ceating temporary unsigned ROM file...
Writing ROM header...
Writing ROM contents:
OS.nb: 100%
Preparing destination...
Preparing ROM signer...
Signing ROM and copying it to destination...
ERROR: Signing process is not successful. Signer service
output:
ImageHash version 1.0
ImageHash Error: Invalid value for max packet size.
What happened? Any hint?
[How to] cook LG KS20 or MS25 Roms for dummies
Disclaimer; I take no responsibility and will not be held liable for any problems you encounter with your device before and after following this guide … flashing a ROM is done at your own risk. If you encounter errors in this guide, send me your comments for inclusion in the tutorial.
Special thanks : Spocky,Farahbolsey, Majorasshole, Raykisi, MisterJp, CopsFrance, Bepe, Ervius, No2Chem, Da_G, Ameet
Description of the kitchen
Note: read Kitchen use for more details on the Spocky kitchen.
This is the Spocky kitchen root preview in Windows Explorer:
1. BaseROM
BaseROM folder contains the extraction of DZ (after Dump fonction of LG Kitchen 2.0)
2. BuiltRom
Contains the extraction of Flash.bin (BuiltRom\KS20\temp)
and new Flash.bin after kitchen Build Rom
3. EXT Folder
The External packages (EXT) folder is divided into Device Specific folders and a Shared folder:
Device Specific folders are used for packages files that should only be applied to a specific type of the device.
Each Device Specific folder is further divided into Operating System Build Version Specific folders and a Common folder.
4. OEM Folder
The OEM folder can contain multiple Device Specific folders.
5. ROM Folder
The ROM folder is divided into Device Specific folders and a Shared folder.
The Shared folder is used for kernel system files that are compatible amongst devices. (MSXIPKERNEL folder)
Device Specific folders are used for kernel system files that should only be applied to a specific type of the device . (OEMXIPKERNEL folder)
Each Device Specific folder is further divided into Operating System Build Version Specific folders.
6. SYS Folder
The system (SYS) folder is divided into Operating System Build Version Specific folders.
The Build Version Specific folders will often contain files (packages) specific to the device DPI (96 Dot Per Inch for KS20) and Horizontal/Vertical display size (240*320 for KS20) and langage. For example, 0409 (English).
UPDATING VISUAL KITCHEN WITH NEW BUILD
A. EXT
No need to modify this Folder. Change this directory only if you want to add a package.
B. OEM
No need to modify this Folder.
C. ROM
1. In the ROM\KS20 Folder, create a new folder with the name of the build (example 23620). Copy the OEMXipKernel folder from ROM\KS20\23xxx or 28xxx into this folder as shown below:
2. in the ROM\Shared Folder, create a new folder with the name of the build (example 23620). Copy the MSXipKernel folder (23620_MSXIPKernel_SYS_QVGA_WQVGA_VGA_WVGA_0409\XIP) from New Build into this folder as shown above .
Note: MSXIPKernelLTK folder contains only DSM files, there is no need to portage.
C. SYS
1.In 23620_MSXIPKernel_SYS_QVGA_WQVGA_VGA_WVGA_0409\SYS: Keep only DPI 96, 240x320 resolution and SHARED folder.
2.In the SYS Folder, create a new folder with the name of the build (example 23620). Copy the SYS from the new Build into this folder as shown below:
3.In SYS\New Build (exemple 23620)\SHARED\COMMON Delete(if they exist) folder: .VM, Bluetooth, WinCENLS_WWE
4. Now copy the folder: .VM, Bluetooth, WinCENLS_WWE for the KS20
Note : If the .ROM folder are not in the new build (23620) also copy the .ROM (I'm not sure what is required for Ervius kitchen ...)
5. Optionnal: Recmod module.
I use the script RecModCommon.bat with RecModCommon
Recmod.exe to convert a module (S000,. Bin etc) to file (DLL, EXE ...). RecMode modules provides a breakdown of these modules in the space between the memory slots, including slot 0 which has less space. In fact, the KS20 has no native NK.EXE 6.5 and has 2 memory slots (slot 0 and slot 1) cons 4 for native NK.EXE 6.5.
D. TOOLS
Go to [LG] kitchen_2.0\TOOLS\XIPPORT to Xip porting. After Kitchen "l" (step 9) launch erviuskitchen.exe
E. Erviuskitchen use
1. Choose KS20 device, XIP Build, SYS Build, EXT Build
2. Select your SYS package (Package Description)
Select your EXT Package
OK that is all, you ready to click the "Create ROM" Button.
If you want to change the PagePool, launch PagePoolChanger ([LG] kitchen_2.0 \ TOOLS) and open the new flash.bin ([LG] kitchen_2.0 \ BuiltRom \ KS20). Choose the new PP, then "Change To".
Good flash!
By Rickou (or Arthemus !)
PORTING ROM (xip.bin)
So the steps.
1. Rename xip_NewBuild.bin in xip.bin and place it in the same directory as Xipport.
2. On Xipport, click "dump xip.bin" folder and wait until "OUT" appear, then click "make pkgs" close the XIPPort.exe.
3. Now, it renames the file out in out_NewBuild
4. In [LG] kitchen_2.0 \ TOOLS \ XIPPORT one copy Ref_XIP.KS20_10F-SPA in "out"
5. In this out, in the folder file/module, deletes MSXIPKernel and MSXIPKernelLTK files.
6. We copy the MSXIPKernel and MSXIPKernelLTK of out_NewBuild for them.
7. In Xipport, click on Undo
8. Execute Kitchen "k"
and when a message tells you so, click "realloc p", "write maps", "build xip_out.bin". And finally, hit a key on the dos prompt to finish this step (DO NOT HIT A KEY BEFORE BUILDING XIP WITH XIPPORT ELSE IT WON'T WORK).
And finally, hit a key on the DOS prompt to complete this step
9. Execute Kitchen "l" to use this xip.
10. Launch Erviuskitchen.exe
PORTING ROM (MSXIPKernel)
When not available xip_newbuild.bin a second method required!
1. Execute "UPDATING VISUAL KITCHEN WITH NEW BUILD"
2. When flash.bin is created, copy [LG] kitchen_2.0 \ temp \ xip.bin in C: \ [LG] kitchen_2.0 \ TOOLS \ XIPPORT
3. On Xipport, click "dump xip.bin" folder and wait until "OUT" appear, delete PARTHDR.txt and ROMHDR.txt in out folder
4. In OUT\MODULES delete nk.exe folder and nk.exe.txt
5. In Ref_XIP.KS20_10F-SPA Copy PARTHDR.txt, ROMHDR.txt, nk.exe folder and nk.exe.txt. Paste in out folder (OUT and OUT\MODULES)
6. Perform steps 7 / 8 / 9 / 10 and previous
Change Language localisation
Da_G said:
* Porting languages in Ervius Visual Kitchen using the posted language packs
First, a quick overview of the relevant file structure in VK:
Code:
\[LG] kitchen_2.0\OEM\[i]%DEVICENAME%[/i]\[i]%LOCALE_ID%[/i]\OEM_Lang_[i]%LOCALE_ID%[/i]
\[LG] kitchen_2.0\ROM\[i]%DEVICENAME%[/i]\[i]%BUILDNUMBER%[/i]\OEMXIPKernel
\[LG] kitchen_2.0\SYS\[i]%BUILDNUMBER%[/i]\DPI_[i]%DPI%[/i]\[i]%LOCALE_ID%[/i]
\[LG] kitchen_2.0\SYS\[i]%BUILDNUMBER%[/i]\DPI_[i]%DPI%[/i]_resh_[i]%RESH%[/i]_resv_[i]%RESV%[/i]\[i]%LOCALE_ID%[/i]
\[LG] kitchen_2.0\SYS\[i]%BUILDNUMBER%[/i]\SHARED\[i]%LOCALE_ID%[/i]
Code:
Possible values for the [i]%VARIABLES%[/i] above:
[i]%DEVICENAME%[/i]: Name of your device (KS20)
[i]%LOCALE_ID%[/i]: The 4 digit number matching your locale (list of supported id's found in first post) - a full list can be found [url=http://msdn.microsoft.com/en-us/goglobal/bb964664.aspx]here.[/url] It is possible to port WM to a language that is not supported, you would have to use a PE Resource editing program to translate all the various strings found in the [b].mui[/b] (Multilingual User Interface) files. Note that these change periodically as the builds get updated so you would also need to update your altered .mui's.
[i]%BUILDNUMBER%[/i]: The build version in use (23620 for example)
[i]%DPI%[/i]: DPI of the device (96)
[i]%RESH%[/i]: Horizontal resolution of the device, in pixels (portrait) -> 240
[i]%RESV%[/i]: Vertical resolution of the device, in pixels (portrait) _> 320
* Porting \SYS
The first thing you would want to do is grab the language pack matching your language. Extract it and you'll have several folders inside. Essentially what you want to do, is grab the folders that match your target device for the variables above, and copy those into the kitchen, in their respective folders.
As an example, if you were porting to Italian, on a 96 DPI, 240 by 320 device, and you had the following folder:
Base_Lang_%LOCALE_ID%_DPI_%DPI%_RESH_%RESH%_RESV_%RESV%
Base_Lang_0410_DPI_96_RESH_240_RESV_320
and place it in:
\[LG] kitchen_2.0\SYS\%BUILDNUMBER%\DPI_%DPI%_resh_%RESH%_resv_%RESV%\%LOCALE_ID%
\[LG] kitchen_2.0\SYS\23620\DPI_96_resh_240_resv_320\0410
Go through each of the folders in the language pack and match it up with a destination folder this way. Compare to the existing 0409 layout to help with the structure. Note that there will be some files you are not going to use (you won't use 96 or 128 dpi files on a 192 dpi device, for example)
Once you have completed matching up each applicable folder in the language pack to a destination in \SYS this way, you're complete with that folder.
* Porting \ROM
The relevant folder here is \[LG] kitchen_2.0\ROM\%DEVICENAME%\%BUILDNUMBER%\OEMXipKernel - inside you want to edit boot.rgu. The relevant keys to edit are:
Code:
[HKEY_LOCAL_MACHINE\MUI]
"SysLang"=dword:[i]%LOCALE_ID%[/i]
[HKEY_CURRENT_USER\MUI]
"CurLang"=dword:[i]%LOCALE_ID%[/i]
NOTE: For anyone not using Ervius VK, you will need to compile boot.rgu to boot.hv when done. Use the HV Tools.zip attached to this thread for that. For anyone using Ervius VK, this is automatically compiled into boot.hv during cooking, and no further action is required.
* Porting \OEM
The relevant folder here is \[LG] kitchen_2.0\OEM\%DEVICENAME%\%LOCALE_ID%\OEM_Lang_%LOCALE_ID% - you need an initflashfiles.dat that matches your language. All the folder names inside here will need to be translated to your language. I will try and make translated initflashfiles.dat for each language available soon.
You will also need to translate any other language-specific packages in \OEM and \EXT. If you don't want to bother translating the 3rd party apps, you can simply rename their .mui files to match your %LOCALE_ID%. The programs will work, but remain in their original language. You can translate these with a PE Resource editing program if you cannot find programs in your local language.
Click to expand...
Click to collapse
DUMP KS20 LG ROM
0409 USA English United States
040C FRA French France
0c0a ESN Spanish España
Flash.bin Moding
Read this tutorial for more information
MBR
Open Flash.bin in Hex éditor. MBR starts @20227 by 00E9FDFF and ends with 55AA
ULDR , XIP , IMFGS , FAT
Equations for calculating
ervius said:
some news on uldr removing/payload resizing/imgfs moveing on xip inserting size!
to automate process, attach the implantxip (for help execute it without parameters by a dos prompt!)
Click to expand...
Click to collapse
A1=00 (start !) , A2=0A , A3=2B , A4=35 ,
B1=09 , B2=2A , B3=34 , B4=FA
C1=0002 , C2=0280 , C3=0AC0 , C4=8D40
D1=027E , D2=0840 , D3=8280 , D4=3180
A1=00, B1=A2-1->09 OK,
A2=(C1*800+D1*800)/20000 -> 0A=(02*800+027E*800)/20000 -> OK
B3=A4-1 -> 35-1=34 OK, B4=A5-1 -> ?
A3=(C2*800+D2*800)/20000 -> 2B=(0280*800+0840*800)/20000 ->OK
A4=(C3*800+D3*800)/20000 -> 35=(0AC0*800+8280*800)/20000 ->OK (2)35
So if the exchange IMGFS correcting A4 and B3 (A4-1)
MSFLSH50
MSFLSH50 starts @20A2B by FDFFFB
beginning of the IMGFS, FAT
Possible result
increasing the number of sectors of FAT
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
By submitting a file flash.bin I cooked (since build 23092) in the [LG] kitchen_2.0 \ BaseRom \ KS20, you will automatically result.
By Arthemus.
Download Links
.VM, Bluetooth, WinCENLS_WWE for the KS20
KS20_BaseRom_Ref
KS20_OEM_Ref
KS20_ROM_Ref
KS20_XIP_Ref
KS20_EXT
Full Kitchen Farahbolsey Part1 Part2
CAB2OEM2NEWKITCHEN
Build 23620 for exemple (thank's asusmobile.ru)
[SYS WM6.5] Latest Releases By DA_G
Latest Releases By asusmobile.ru
Useful Links
LG Kitchen 2.0 by Spocky
Porting, Tutorials, Tools, VM, etc. By DA_G
Manual Full XIP Porting (& MANY MORE TUTORIALS) by Ameet's
F.A.Q / Registry tips
GSM reload: delete key
[HKEY_CURRENT_USER \ ControlPanel \ Phone]
"EventSoundCache" = dword: 1
Reserved for future
Hi Rickou
What an impressive work you did. For sure this will help people become great KS20 cook chiefs.
Franck
Thank you Rickou, it is a wonderful guide!
Thank you Fara and ibanezman192,
For those who still hesitate, I will table the Xip.bin ported 23620. You need to file in [LG] kitchen_2.0 \ BuiltRom \ KS20 \ temp.
By.
Very good work
First of all thanks i've been waiting for it for year(s)
And thanks finally I have my ks20 wm 6.5 in spanish
btw could you explain how to convert cab to oem package?
Thanks in advance
hi,
Use CAB2OEM2NEWKITCHEN link #6.
By.
rickou26 said:
Change Language localisation
Click to expand...
Click to collapse
How i change the language? I have to change the Initflashfiles.dat file to my language?
Hi,
I updated the post.
@ +
thanks you very much!!
help
rickou26 -
why does not do RUS of sewing???I zdelal all on instruction and for me after vspishki telephone of not zapuskaet'sya that I do not so????
Hi,
Sorry but I have a little trouble understanding your question. Can you write in Russian I do a direct translation into French
By.
rickou26 said:
Hi,
Sorry but I have a little trouble understanding your question. Can you write in Russian I do a direct translation into French
By.
Click to expand...
Click to collapse
Я зделал все как написано в инструкции,выполнил в кухне(cпоки-2 кухня) пункт b потом c ,потом портировал новый XIP,Потом создал папки SYS и OEM(взял из первой руской прошивки,потом зашол в кухню нажал на создание прошивки!и у меня создался файл bin 71mb,прошил телефон,а телефон не запускаеться что я делаю не так?????????
ВЫ можете зделать рускою( rus) прошивку ks20 wm6.5.3 ce os 5.2.23518????????????
или МНЕ помоч!!!!в создание rus прошивки для ks20 построеной на второй кухне СПОКИ
Give me please ALL FILES!!! OEM ROM SYS(Ks20 Wm6.5.3 CE OS 5.2.23518) Дайте мне пожалйста все файлы!!!!!! ROM OEM SYS на руском языке и инструкцею!подробно как все правильно делать в второй кухне споки
Hi,
This is completely new EXT rebuilder made by myself. It’s again (just like all of my stuff I made xD) made in .NET so you need .NET framework on your PC (Vista and 7 already have it integrated). It works just as previous OEM -> EXT rebuild, but with few enhancements .
First, it can rebuild both whole OEM or just single package (it could do probably the old one too).
Second, it works by WILDCARD, so you want convert eg only packages starting with PACKAGE_ so you do: extRebuild.exe /wildcard=“PACKAGE_*“ (btw, the PACKAGE_* is default)
Also, there is another nifty thing. You can specify, what to do with other packages (usually these are OEMDrivers etc), which do not apply to the wildcard. There are several options as another flag:
• /ext - (the default one) – the all matching packages are moved into EXT folder after finished reEXTing and the others are left in OEM
• /keep – both OEM and EXT will stay in the same directory, but the OEM pkgs won’t be converted to EXT
• /move – moves the non-apply-wildcard folders to directory REALOEM
• /move=“somedir“ – the same as ^, but you specify which folder to move the OEM to
• /dele – delete the non-matching packages
• /nodelete - doesn't delete empty OEM packages (like X0, X1, L0, L1 etc)
Well, for classic use, just drop your OEM folder or single package on the extRebuild.exe and it will rebuild that all new EXT is moved to EXT folder and remaining OEM stays on its place .
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
That’s probably all you need to know.
Thanks for watching and start using . (Mine extRebuild ofc .) Your OndraSter
great tool
Very nice tool working perfect, thanks!
Very nice tool works perfectly
nice work ontraster even if it is in .net
Good work, maybe this tool, rebuild my OEM from WM STD
OK, new version comming in few mins to first post...
Highlits:
- [FIX] Now fixed that if you have packages with similar name like ExtNewPhoneSetting and PhoneSetting, it doesn't crash (weird it was happening only to me, not to twopumpchump)
- [FIX] Using more "Safe Move" and "Safe Delete" which doesn't crash when deleting/moving is blocked
- [FIX] Some more internal fixings
- [ADD] Now it also deletes empty OEM like X1, X2, L0, L1 etc (checks for count of modules+files except dsm and if == 0 => deletes whole package in OEM), can be disabled by /nodelete flag
Nice Work here
Doesn't work for me, i dumped a rom and theres lots of files in "OEMAPPS" folder, and i want to make packages for them, and i only get only get one massive package. I want to get individual packages, like adobe, zip, camera, ect. This is a 6.1 rom dump.
no you can't, the tool cannot generate what doesn't exist like missing packages dsm's.
Oh ok thnxs
OndraSter said:
Hi,
This is completely new EXT rebuilder made by myself. It’s again (just like all of my stuff I made xD) made in .NET so you need .NET framework on your PC (Vista and 7 already have it integrated). It works just as previous OEM -> EXT rebuild, but with few enhancements .
First, it can rebuild both whole OEM or just single package (it could do probably the old one too).
Second, it works by WILDCARD, so you want convert eg only packages starting with PACKAGE_ so you do: extRebuild.exe /wildcard=“PACKAGE_*“ (btw, the PACKAGE_* is default)
Also, there is another nifty thing. You can specify, what to do with other packages (usually these are OEMDrivers etc), which do not apply to the wildcard. There are several options as another flag:
• /ext - (the default one) – the all matching packages are moved into EXT folder after finished reEXTing and the others are left in OEM
• /keep – both OEM and EXT will stay in the same directory, but the OEM pkgs won’t be converted to EXT
• /move – moves the non-apply-wildcard folders to directory REALOEM
• /move=“somedir“ – the same as ^, but you specify which folder to move the OEM to
• /dele – delete the non-matching packages
• /nodelete - doesn't delete empty OEM packages (like X0, X1, L0, L1 etc)
Well, for classic use, just drop your OEM folder or single package on the extRebuild.exe and it will rebuild that all new EXT is moved to EXT folder and remaining OEM stays on its place .
That’s probably all you need to know.
Thanks for watching and start using . (Mine extRebuild ofc .) Your OndraSter
Click to expand...
Click to collapse
Hi there,
- Nice work. It worked like a charm for me on XP machine.
- Just a suggestion : I think the OEM path does not handle the space in between the folder names.
- E.g. : Usually I have all my stuff in "C:\My Folder". So if I set OEM path as "C:\My Folder\..." then the exe throws a .NET exception and forces to close.
- However, If I set the OEM path as "C:\Folder" then exe runs fine and all the EXTs are generated properly.
Is it possible to handle this space issue easily (I know this might sound little too much, but still thought of sharing)?
chota_shivaji said:
Hi there,
- Nice work. It worked like a charm for me on XP machine.
- Just a suggestion : I think the OEM path does not handle the space in between the folder names.
- E.g. : Usually I have all my stuff in "C:\My Folder". So if I set OEM path as "C:\My Folder\..." then the exe throws a .NET exception and forces to close.
- However, If I set the OEM path as "C:\Folder" then exe runs fine and all the EXTs are generated properly.
Is it possible to handle this space issue easily (I know this might sound little too much, but still thought of sharing)?
Click to expand...
Click to collapse
Apologies for below post. I forgot to add the path in "" when it has a space in it. This is Windows.
Superb!!!!!
It is great.....
Tried ver 1.1...
The /nodelete flag doing the reverse work.
It is deleting all the folders from OEM except the ones converted to EXT...
instead I expected it to retain all the non-wildcard packages+empty packages in the OEM folder and move wildcard ones to EXT folder.
Hi Bro
Thanks for this
Cheers
c_shekhar said:
Tried ver 1.1...
The /nodelete flag doing the reverse work.
It is deleting all the folders from OEM except the ones converted to EXT...
instead I expected it to retain all the non-wildcard packages+empty packages in the OEM folder and move wildcard ones to EXT folder.
Click to expand...
Click to collapse
Oh it is bug in documentation in think, in default, it keeps OEM in OEM and then EXT moves to EXT so no need to use that flag
OndraSter said:
Oh it is bug in documentation in think, in default, it keeps OEM in OEM and then EXT moves to EXT so no need to use that flag
Click to expand...
Click to collapse
I think you could not get me correctly.
in default it does following:-
1. delete empty packages
2. keep the non-wildcard packages in OEM
3. move wildcard packages to ext folder
right?
I dont want to delete empty packages and thats why I am using the flag /nodelete. I am using following command:-
Code:
extrebuild.exe %1 /nodelete
and it is deleting all the non-wildcard packages from OEM.
Ohh, bug in app, I'll fix it when I get some time (if there was no IE7 problems with rendering, I would do it now). Thank to MS for that
of EXT to OEM
OndraSter said:
Ohh, bug in app, I'll fix it when I get some time (if there was no IE7 problems with rendering, I would do it now). Thank to MS for that
Click to expand...
Click to collapse
and can EXT OEM package thanks.
usage:
NBHImageTool -build|-dump param1 param2 param3
What is NBHImageTool?
NBHImageTool is a command line application to handle dumping and re-creation of .NBH files, which are data containers designed by HTC to be read by their SPL. The .nbh file contains a number of data partitions identified by their ItemID. NBHImageTool uses just a small subset of libnb, which is a library designed to handle Windows Mobile firmware images, and is in development. New! Support for WP7 unsigned NBH dumping and rebuilding
How do I use NBHImageTool?
Included in the archive are 2 batch files which demonstrate the usage of NBHImageTool, one will dump the .nbh to its .nb components, and an xml configuration file which defines the parameters to rebuild it. The other will build an .nbh from its .nb components and an .xml. Note that ImageHash.exe and TEST.pvk must be in the same folder as libnb.dll or it will fail to sign the output NBH. These files are not required if your output NBH is not signed.
What is the output from NBHImageTool?
It will generate an RUU_Unsigned.nbh and an RUU_Signed.nbh. The RUU_Signed.nbh is signed with the TEST.pvk certificate contained in the archive, and the RUU_Unsigned.nbh is unsigned.
What are the .nb files generated with unknown in the name?
These are some binary data that i'm not sure about. If you know what they are (and optionally how to manipulate them) let me know!
What can I change in the xml configuration and still obtain a valid .nbh to flash to my device?
Code:
Defaults for the following parameters are all generated by the dump function.
<NBHFile>
The Signed attribute tells NBHImageTool if it should sign your output .NBH with TEST.pvk.
The ModelID attribute must match your device ModelID. An asterisk (*) can be used to match any character.
The CID attribute must match your device CID if you are running the stock bootloader. If you are running HardSPL the CID can be any value.
The Version attribute can be any value.
The Language attribute can be any value.
The DataChunkSize attribute should match the original dumped value from your .NBH. This value defines the maximum size of data to be allocated inbetween signature chunks written by ImageHash.exe.
<Item>
The IncludedInNBH attribute determines if the program should look for this item in the input folder. The remaining attributes will be skipped if this is not set to 1.
The ItemID attribute defines the Item's type. 0x400 defines an os.nb, which contains most of the relevant Windows Mobile files. This is the only ItemID which defaults to be included in the final NBH. ItemID and FileName will only be read if IncludedInNBH is set to 1.
The FileName attribute defines the filename for NBHImageTool to grab from the input directory ([b]param1[/b]). ItemID and FileName will only be read if IncludedInNBH is set to 1.
Are there any other things I can do with NBHImageTool?
RUU_Signed.nbh and RUU_Unsigned.nbh are both generated in the output folder. You could change "TEST.pvk" in the .\tools folder to a .pvk of your choosing to sign the resulting .nbh with that certificate. Or you could use the RUU_Unsigned.nbh raw image to be processed in some other way (signed using a 3rd party tool, etc.)
What are the "unknown" .nb files generated by NBHImageTool?
These are data partitions that unknown to me! If you know what one is, please drop me a PM and let me know, I will update the library with this information.
What's this "param1", "param2" nonsense?
The parameters take different values, depending if you are running -dump or -build. The values are:
-dump:
param1: Path to the .nbh to dump. This Path must end in the filename (eg. RUU_Signed.nbh)
param2: Path to the folder to extract to. This Path must end in a folder name (eg. C:\Kitchen\dumpfolder)
param3: Path to an .xml to create with configuration data to rebuild the .nbh. This path must end in an .xml file name (eg. C:\Kitchen\xml\raphael.xml)
-build:
param1: Path to the folder to take .nb files from to build resulting .nbh. This path must end in a folder name (eg. C:\Kitchen\dumpfolder)
param2: Path to the folder to build the .nbh files in. This path must end in a folder name (eg. C:\Kitchen\buildfolder)
param3: Path to an .xml to read with configuration data to rebuild the .nbh. This path must end in an .xml file name (eg. C:\Kitchen\xml\raphael.xml)
I've run into some bug with NBHImageTool, or found an .nbh that causes odd behavior!
Please drop me a PM to let me know, I will look into it ASAP!
I'm a programmer, and libnb sounds like a .dll I might be interested in.
Please contact me via PM! I'd like to support libnb.dll and all its functions for anyone interested in using it for their own program (not for commercial use)
This program is written in VS2010/C++ Native Code.
The Visual C++ 2010 (x86 or x64, depending which version you use) Runtime is required to run it.
Thanks to everyone who helped me to understand the .NBH format, the SPL, and what parameters it finds tasteful. Cmonex, Olipro, Bepe, and Ervius and many others!
Release History:
v1.0: Initial release
v1.1: Fixed a bug when the last NBH Item is smaller than DataChunkSize resulting in a crash on dumping, changed help text and error output to reflect the need for ImageHash.exe and TEST.pvk in launch folder
v1.2: Optimizations, x64 version added, WP7 Unsigned NBH format now supported for dumping, new "Signed" variable added to XML. Path issues with imagehash.exe addressed (keep it and test.pvk in the same folder with libnb.dll)
This should be good enough, But everyone knows that if there are any errors b00n can find them, No idea how they come up wiht half the stuff they do.
This is a decent tool, that will do a lot more for everyone.
Spent the afternoon, trying everything I could think of to try and make it crash, and most of the issues have been fixed, I could not get anything else to go wrong with it, so we will have to see how it all works in the end.
Thanks Da_G - but I get an error on my Windows 7 x64 system - what am I missing??
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I installed the x64 runtime files from here
DT
edit: had to install the x86 version
Hi d_train!
Sorry, I put that in my post, but it's pretty small. I'll make it bigger, to be more clear! VS2010 is a recent release and so these files are installed on almost no machines right now
Well done Da_G,
This is a great tool and here is my report of using it.
Original used NBH : Raphael O2 UK 5.12.206.1 ROM
First I tried to dump it via "1dump_nbh" and it worked without any errors and in ~1 second. 4 NB files created successfully: OS, Radio, SPL, Splash.
Here is the output XML:
Code:
<?xml version="1.0" encoding="utf-16"?>
<!--This document describes the contents of your NBH file. The IncludedInNBH attribute can be used to include (1) or exclude (0) that item from your final NBH-->
<NBHFile ModelID="RAPH12000" CID="O2___001" Version="5.12.206.1" Language="USA" DataChunkSize="64">
<ItemList>
<Item IncludedInNBH="0" ItemID="0x301" FileName="radio.nb" />
<Item IncludedInNBH="0" ItemID="0x200" FileName="spl.nb" />
<Item IncludedInNBH="0" ItemID="0x600" FileName="splash.nb" />
<Item IncludedInNBH="1" ItemID="0x400" FileName="os.nb" />
</ItemList>
</NBHFile>
Then, I tried to rebuild them via "2build_nbh". Yes, It worked great again and 2 NBH files are created in ~4 seconds. (included OS.NB only). And finally, I tried to edit XML to include all NB files and process completed successfully in ~10 seconds. (writing NBH and signing took ~3-4 seconds).
Tested in Windows 7 x86 (32bit) without installing any libraries and runtimes. (I'm using VS2010 and I think they were installed before.)
Regards
Da_G said:
Hi d_train!
Sorry, I put that in my post, but it's pretty small. I'll make it bigger, to be more clear! VS2010 is a recent release and so these files are installed on almost no machines right now
Click to expand...
Click to collapse
lol now I see it
thanks for this great tool
DT
Here is the XML from a Leo ROM
Code:
<?xml version="1.0" encoding="utf-16"?>
<!--This document describes the contents of your NBH file. The IncludedInNBH attribute can be used to include (1) or exclude (0) that item from your final NBH-->
<NBHFile ModelID="PB8110000" CID="CSL__001" Version="1.72.831.1" Language="USA" DataChunkSize="64">
<ItemList>
<Item IncludedInNBH="0" ItemID="0x301" FileName="radio.nb" />
<Item IncludedInNBH="0" ItemID="0x380" FileName="radiocust.nb" />
<Item IncludedInNBH="0" ItemID="0x200" FileName="spl.nb" />
<Item IncludedInNBH="0" ItemID="0x600" FileName="splash.nb" />
<Item IncludedInNBH="1" ItemID="0x400" FileName="os.nb" />
<Item IncludedInNBH="0" ItemID="0x920" FileName="conf.nb" />
<Item IncludedInNBH="0" ItemID="0x900" FileName="extrom.nb" />
<Item IncludedInNBH="0" ItemID="0x610" FileName="unknownsplash1.nb" />
<Item IncludedInNBH="0" ItemID="0x611" FileName="unknownsplash2.nb" />
</ItemList>
</NBHFile>
So do I assume that if I wanted to replace the splash screens I enable 0x600, 0x610 and 0x611?
Is there a utility that allows me to view and or convert WVGA splashscreen nb files?
Thanks again Da_G
DT
Yes, if you wanted to replace the splash screens you would enable the IncludedInNBH attribute for those items.
You would need to dump these .nb splash files to an editable format (such as .bmp) to work with them, and then re-create the .nb file to feed into the build function, in order to replace them in the final .nbh.
I will soon look at incorporating an automatic .nb HTC Splash Image Converter, to aid with replacing these splash images easily. I think the tool "nbimg" by pof may be able to work with them, for the time being. It accepts manual parameters for the width and height of the image. If it doesn't work, please let me know if you find or know of a tool that does, and I will update the first post until I can program a function for this tool to handle it. Thanks
Da_G said:
Yes, if you wanted to replace the splash screens you would enable the IncludedInNBH attribute for those items.
You would need to dump these .nb splash files to an editable format (such as .bmp) to work with them, and then re-create the .nb file to feed into the build function, in order to replace them in the final .nbh.
I will soon look at incorporating an automatic .nb HTC Splash Image Converter, to aid with replacing these splash images easily. I think the tool "nbimg" by pof may be able to work with them, for the time being. It accepts manual parameters for the width and height of the image. If it doesn't work, please let me know if you find or know of a tool that does, and I will update the first post until I can program a function for this tool to handle it. Thanks
Click to expand...
Click to collapse
Thanks Da_G - found the nbimg tool and it was able to convert the splash.nb file to bmp, but not the unknownsplash1.nb and unknownsplash2.nb files
Thanks again for your ongoing contribution to these forums
DT
Hi Da_G
Maybe you create Tool for file *.tsw - You build good and faster tools!
Thanks
Great
Great tool Da_G, will be testing it in a bit. looking forward to developers incorporating this into new Kitchens
Thanks Da_G, works like a charm on my XP Pro machine.
I send you some beer money so you can order La Chouffe from Holland.
Congrats
nbimg tool for Leo
nbimg tool by pof for splash works for my Leo but needs recalculating of the padding.Works with the following parameters:
nbimg -p 18400 -w 480 -h 800 -F nameofphoto.bmp -T 0x601 -S 64 -D PB8110000
http://forum.xda-developers.com/showthread.php?t=668862
Would be very nice if you could automate the process.
Congrats for your perfect tool!!
Hi,
Which are the advantages os this utility compared to nbhutil from olipro?
Thanks
good job Da_G! gonna try it later.
thanks
mac_es said:
Hi,
Which are the advantages os this utility compared to nbhutil from olipro?
Thanks
Click to expand...
Click to collapse
NBHUtil and HTCRT need configuration files provided by other users that often lack support for new devices and are incomplete/inaccurate. This utility instead can make its own building configuration file from the NBH itself so you can rebuild any NBH without having to desperately search for the correct configuration file that supports your device.
Thank you for this Da_g your work is always appreciated
Excellent tool works flawlessly
Transaction ID: 5LV66560PR5951831
@mac_es:
As airxtreme already stated, one of the bigger drawbacks of previous tools is that you had to come up with a configuration file somewhere. This one will automatically generate one from any ROM for your device. This has the advantage of picking up on any ItemIDs that we hadn't previously seen in a ROM or didn't exist until recently (like radiocust, radioconf)
I'm working with l3v5y to add another nice feature, automatic dumping of a splash screen .nb to .bmp, and then automatic rebuilding of the splash screen .nb from the .bmp (i'll probably add a flag to the xml for that auto rebuild from bmp) - this way you can work directly on the .bmp and avoid unneccessary conversions every time you make an edit to it.
I'm looking at making a routine to pull the radio.nb version out too, and store it in the xml, just for informational purposes.
Very nice work Da_G. Really appreciate the time and effort you put into doing this stuff for us.
Just one question, now that we have this tool for getting the .nbh, what is a good option for us at the moment to get the packages extracted from the .nbh?
xidump from Bepe is a fine tool for this, it can work directly with the os.nb, and output directly from it.
Unfortunately it has no build support yet, that is my next target, to replace NBImageTool with a new version that handles dumping and building