Database Users

[DEV-UTIL][19.03.2009]DriverWiz - Make signed CABs from driver DLLs that work

Intro
Lately I've seen a lot of posts by people who are trying to replace WM internal or driver DLLs, either for hacking/testing or to release. Aside from the possibility they are just doing something that won't work in the first place, I've seen failure a lot of times because files aren't properly signed, or if they are, the certificate in question not being in the right certificate stores for it to have any effect. On some ROMs it will still work due to patched NK.EXE, on others it won't, its just not very reliable.
So, I present you with the correct way of doing this by means of a small tool that will do this for you: DriverWiz. It will take care of most of the stuff, and leave you room for additions. You will however still need some basic knowledge of the command line, if you don't have that, you have no business doing anything like this anyways.
Background
I use this technique myself all the time. When just hacking away, replacing system DLLs to trace calls, etc. It's also the same method used for the HTC-CA drivers and the ICS installer. This method works on most stock ROMs as well, though not on all of them (in rare cases some security policies are set that will prevent CAB installation)
Usage
It's fairly simple to use. Just extract the attached zip file somewhere, open the command promt, and change directory to where the zip was extracted. That's the installation part.
Now when you actually want to build a CAB file from a DLL, you use the DriverWiz.bat file.
DriverWiz v1.0 by Chainfire
Usage:
DriverWiz.bat "Description" "CAB-name" "DLL-name-1" ["DLL-name-2" ...]
Examples:
DriverWiz.bat "New DDI" "ddi.cab" "ddi.dll"
DriverWiz.bat "Two DDIs" "ddi.cab" "ddi.dll" "ddiaux.dll"
Click to expand...
Click to collapse
DriverWiz will take care of signing the DLLs, inserting the certificate, etc, and you will end up with a proper CAB file for this kind of thing. Just copy it to your device and run it to install.
#1. You need to put the DLL files in the same folder as DriverWiz. Do NOT include paths in your DLL names
#2. Include the quotes in the command like in the examples!
#3. The first time you install a CAB made by DriverWiz, your phone may still give you a certificate warning. This is normal, don't worry about it.
Caveats
While this method has never failed me yet, it is possible that some files cannot be replaced this way. Just a disclaimer
Modifying
DriverWiz bases the inf file it will create to build a CAB from on DriverWiz.tpl. If you need to add registry entries to your CAB file, modify DriverWiz.tpl before you run the batch file. You can make other modifications too, add files, etc. Just take care that you don't break it
You can use your own certificates as well, instead of the supplied "Dummy" certificate that comes with DriverWiz. The files you will want to modify/replace are DriverWiz.pfx (used for signing) and DriverWiz.xml (used for injecting the certificate). I'll see about finding a reference for how to do that online and posting the URL here (someday). Creating a new certificate from scratch can be a frustrating effort - make sure you got openssl handy
Changelog
19.03.2009 - 1.1 - Added some file exists checks and attribute changes
Download

Temporary PlaceHolder for more Info.

Whoo this is hot from the plate, looks very promising!
Driver testing withoud cooking! joohie

Well if you replace the wrong files you're still going to need to hard-reset to boot. I advise KITL before you do

Works flawless. You tha man.

Didn't work for me trying to cab up No2Chems Fast Charge battery divers.

ruskiyab said:
Didn't work for me trying to cab up No2Chems Fast Charge battery divers.
Click to expand...
Click to collapse
What exactly happened? Attach the files and such

It made the cab and all, but when I went to install it, the unsigned error message popped up just like when I tried it with WinCE cab manager.

That is perfectly normal behavior. The first time you install a CAB with this certificate it will not know the certificate. However, once you install it, the certificate will be injected in the right place, and the files signed with the certificate (the driver files in the CAB) will be allowed to be run.
It won't happen the second time you try it

So if I try to install it again, it'll work fine? is there aa soft reset required in between? I can replace these drivers manually by renaming the old ones and copying them over, the whole reason I want a cab in the first place is to facilitate the UC process when I flash a different rom

ruskiyab said:
So if I try to install it again, it'll work fine? is there aa soft reset required in between? I can replace these drivers manually by renaming the old ones and copying them over, the whole reason I want a cab in the first place is to facilitate the UC process when I flash a different rom
Click to expand...
Click to collapse
Actually it should just work the first time. Just click OK when the certificate error appears.

Nice nice nice work!

error message
I got error messages when creating a cab from a rilphone.dll. Does it mean anything, or are these errors okay? I guess I'm specifically wondering about the SignTool error. If its okay, then my cab should be good.
EDIT: I think I found the problem. I didn't have UAC disabled in Windows 7. I tried it again, after disabling it, and it works fine now. Thanks for the easy to use tool!

syntax for registry entries?
I was experimenting with creating a cab for the Rogers folks who need a specific rilphone for their Caller ID to work. There are some registry entries associated with this feature, so I was wondering what the correct syntax is for putting the registry entries into the .tpl file. I've tried a few different ways, and I've either a gotten a 'Registry section is empty' message, or a 'Registry has an unsupported registry root key' error. I'm sure its something really simple I'm missing, so any help you can offer is appreciated.
It just seems that since we now have this easy method to sign these dlls, so that they can be used in any ROM, that the Rogers people shouldn't have to jump through so many hoops to get it to work.
EDIT: Nevermind. I'm an idiot that didn't do a little bit of research. All is well now.

Excellent stuff, Microsoft may rant about this way of distributing signtool and cabwiz though.
Chainfire said:
You can use your own certificates as well, instead of the supplied "Dummy" certificate that comes with DriverWiz. The files you will want to modify/replace are DriverWiz.pfx (used for signing) and DriverWiz.xml (used for injecting the certificate). I'll see about finding a reference for how to do that online and posting the URL here (someday). Creating a new certificate from scratch can be a frustrating effort - make sure you got openssl handy
Click to expand...
Click to collapse
Here's an intro to cert stores for WM:
http://msdn.microsoft.com/en-us/library/aa458010.aspx
pfx generation is a 2-liner with openssl:
# Generate a CA certificate
openssl req -new -nodes -x509 -days 9999 -newkey rsa:1024 -md5 -keyout cert.key -out cert.cer -subj "/CN=DriverWiz"
# Convert to pkcs12/PFX format
openssl pkcs12 -export -in cert.cer -out cert.pfx -inkey cert.key

got error messages under vista sp2, any ideas?

I also get an error saying that the latest version of CAPICOM.dll is missing. The ones I can find for download from the internet are version 2.0.0, and the tool requires 2.1.0.1 or later.
Does anyone have the needed version of the dll?
EDIT: Found it, 2.1.0.2 version of the dll is in the attachment.

Time Saver !
Many thanks; DriverWiz /w the CAPICOM.DLL saved me about an hour of troubleshooting.
Cheers,

Thanks for the capicom.dll Even after disabling UAC in W7Rc1 it wouldn't go, so great to have it posted to.
Chainfire, which format should the Reg's be added?
I tried the default .reg formating just under:
[Registry]
[HKEY_CURRENT_USER\ControlPanel\Profiles]
@=""
"ActiveProfile"="Normal"
?
Scrap that i found the .inf format
[AddRegistry]
HKCU,"New Key","",0x00010001,1
Many thanks for this, i'll try to Point Driver replacing Sinners from now on to here.

Well INF files are a regular female dog.
If you rather use WinCE CAB Manager, the trick is easily done as well. I do not have it handy right here (I'm not at dev box), but it goes like this.
Put the DLL's and EXE's that need to go in the CAB into the same folder as DriverWiz
Execute the following command from the command prompt in the DriverWiz folder: signtool sign /f DriverWiz.pfx *.exe *.dll
Open your WCM/CAB with CM
Somewhere is an option for "Pre XML" (main screen IIRC).. click to add/edit, and load the DriverWiz.xml file
Save
signtool sign /f DriverWiz.pfx *.cab
Et voila. I should really make an update to DriverWiz to include CAPICOM and write a proper guide on how to do all this manually (including making your own certificates and such). It's easy if you know how
If you could insert another empty post for me at the top, that'd be great.

Creating Kitchen from Dumped ROM

This started out as a pm between hilaireg and me. i'm reposting the conversation here in order to benefit the rest of Chef Central.
I have a NEON400 which has recently been SPLed...finally.
However, there are no ROMs out there for the device and one guy who tried failed miserably. Mostly due to the fact that he doesn't own a device and can't test it.
what I'm looking for is a tutorial or some way to turn the dumped OEM ROMs we have into usable clean ROMs or upgraded to 6.5. Obviously there is no way that you can help me without having a device but is there any generic tutorial out there so I can get started learning how to do this?
Thanks for your help if you can... I appreciate anything you can do for us lowly NEON400 users.
thanks!!!

FROM: hilaireg
I'm not sure as to how much help I can be; that said ...
1) NEON Specs
I had a look at the NEON specs on the WIKI to get an idea of what is possible with the device.
From the specs, the unit is 128MB of ROM which may necessitate RECMOD'ing of module in order to achieve a bootable ROM. SLOT0 is generally the issue with WinMO 6.1 as SLOT0 should remain free of modules for the final ROM compilation. Here's some supporting information on Virtual Memory that will better explain what I am referencing:
Virtual Memory as it applies to the Windows CE 5.2 Kernel
http://forum.xda-developers.com/showpost.php?p=4268137&postcount=2
2) ROM's
I haven't conducted a search to see if an update ROM has been released for the NEON (either through BELL or HTC); I'm going to describe two possible scenarios.
Scenario 1: No update ROM
The best approach here would be to determine how to dump the ROM from an existing device. Once a device is "dumped", the dumped content could serve as the starting point for building a custom ROM. Dumping a device ROM requires a few procedures ... I recommend a forum search with these keywords:
dump device rom
The threads that will appear will not be NEON specific, you'll have a bit of reading on your hands, but may provide some insights at what may be required.
Scenario 2: Update ROM available via BELL/HTC
If an update ROM has been made available for download, it should be possible to perform a dump via a kitchen such as Ervius Visual Kitchen (EVK). Here's a link to a tutorial I put together that walks aspiring chefs through the process of dumping an official updated HTC ROM using EVK for the Raphael - but is essentially the same for any device. Once a ROM is dumped using EVK, this would serve as your starting point for building a custom ROM.
[TUT] Sous-Chef's Guide to XIP Porting in Ervius Visual Kitchen 9.7
http://forum.xda-developers.com/showthread.php?t=526610
3) Custom ROM
Once you have a starting point ROM, you can use it to create a net new kitchen. A net new kitchen could be a matter of copy/pasting the dumped kitchen from #2 (above). Things to keep in mind:
ROM: OEMXIPKernel is device specific and usually doesn't change until a NEON update ROM is release by BELL/HTC
ROM: MSXIPKernel is MS specific, this usually gets updated when a new O/S release is issued (ex: 6.1.21054, 6.1.21056, 6.5.23541, 6.5.23549, etc.)
OEM: this is device specific package which often are device drivers, carrier (operator) configuration, device functions, etc. and usually doesn't change until a NEON update ROM is release by BELL/HTC
SYS: this is MS specific and usually gets updated when a new O/S release is issued (ex: 6.1.21054, 6.1.21056, 6.5.23541, 6.5.23549, etc.) the MSXIPKernel & SYS should always match.
I would suggest starting with 6.1 and once you have a working build, you could look to move to 6.5. What's is important to keep in mind is:
you may need to RECMOD modules
closely review the .RGU (.REG), INITFLASHFILES.*, and .PROVXML files for any carrier (operator) specific lock downs
you will need to Cert Patch the ROM, possibly reduce the ULDR, possibly adjust the PagingPool - all selectable features in the newest version of EVK
Lastly, don't hesitate to ask questions in Chef Central ... some senior chefs may have some pointers that could help.
Chef Central: Windows Mobile/Windows Phone
http://forum.xda-developers.com/forumdisplay.php?f=612
HTH

OMG, this is so much info. you are awesome.
Okay...to get some stuff out of the way:
1.) No update ROM was ever released from Telus or Bell (the phone was released by both)
2.) the OEM ROMs have already been dumped.
1. you may need to RECMOD modules
2. closely review the .RGU (.REG), INITFLASHFILES.*, and .PROVXML files for any carrier (operator) specific lock downs
3. you will need to Cert Patch the ROM, possibly reduce the ULDR, possibly adjust the PagingPool - all selectable features in the newest version of EVK
Click to expand...
Click to collapse
This went entirely over my head.
RECMODding? How do I do this? It looks like No2Chem released some sort of EXE for this.
What am I looking for in the carrier specific files?
I don't think I can use EVK because I don't have an upgrade ROM, or can I?

FROM: hilaireg
Okay...to get some stuff out of the way:
1.) No update ROM was ever released from Telus or Bell (the phone was released by both)
2.) the OEM ROMs have already been dumped.
Click to expand...
Click to collapse
Haven't downloaded the file; ideally the download should either be an *.NBH or *.NB file. If it is, you should be able to use it in EVK.
The question to ask yourself is, has someone gone through the trouble of ... dumping the entire ROM from the phone? Or, only dumping the OEM portion?
If it's fully extracted, is there a ROM, SYS, OEM, (PACKAGES\EXT) folder structure? If so, then you should be able to use it in EVK. If there is a PACKAGES folder, they likely used the PkgBuildOS (oldstyle) kitchen to dump the ROM; Ervius released a tool to convert an oldstyle PACKAGES folder to a newstyle EXT folder.
1. you may need to RECMOD module.
Click to expand...
Click to collapse
Recoded Modules usually appear like this:
<filenameasfolder.dll>
imageinfo.txt
imageinfo.bin
S0001
S0002
S0003
...​
Included in the TOOLS folder of the EVK is a RECMOD.EXE, when you drag the <filenameasfolder.dll> folder (and contents) onto the EXE, it creates the compiled .DLL - ex: filenameasfolder.dll.
2. closely review the .RGU (.REG), INITFLASHFILES.*, and .PROVXML files for any carrier (operator) specific lock downs.
This went entirely over my head.
RECMODding? How do I do this? It looks like No2Chem released some sort of EXE for this.
What am I looking for in the carrier specific files?
Click to expand...
Click to collapse
Since WinCE is really a mobile version of Windows - being simplistic here - there are some things that are similar.
Registry changes are typically kept in .RGU/.REG files.
INITFLASHFILES.* are usually used for file copy operations on the device.
CONFIG_*.txt are usually used to launch .CAB files, copy operations, etc.
.PROVXML are usually used to configure MS and Carrier (Operator) specific settings. They can also be used for copy operations, registry changes, etc.
3. you will need to Cert Patch the ROM, possibly reduce the ULDR, possibly adjust the PagingPool - all selectable features in the newest version of EVK
Click to expand...
Click to collapse
As you are cooking a custom ROM, you need to disable the security certificate checking or the custom ROM may not boot. The reason for this is that MS/Carrier (Operator) don't want people doing what we're doing ... it's similar to HardSPL, it tells the device that "it's ok to use this ROM".
I don't think I can use EVK because I don't have an upgrade ROM, or can I?
Click to expand...
Click to collapse
Shouldn't be an issue. As long as you can obtain the ROM (OEMXIPKernel & MSXIPKernel), OEM, and SYS, you should be able to build a working custom ROM.
Have a look at my kitchen thread:
http://forum.xda-developers.com/showthread.php?t=471288
Download the kitchen and have a look through it to get a sense of what the final product should look like. The change logs will give you a sense of what had to be removed/changed/added to produce a custom ROM.
And once again, don't hesitate to ask questions in Chef Central ... that's why it was created; to help aspiring chefs learn.
Cheers,

All right, I downloaded v1.8.1 of EVK and used it to load the dumped .NBH. This seemed to work flawlessly and I now have a folder called 'dump' that contains the following folders. (I manually entered the Device name NEON400 when EVK prompted for it):
EXT
MyTools
OEM
RELEASE_NEON400
ROM
SYS
Tools
I'm guessing I've successfully extracted the ROM image.
i would like, for ease and simplicity, to just make this into a clean 6.1 version. I don't REALLY want to tackle 6.5 quite yet.
Is there a simple way to clean out the garbage? How do I know what's what?
I really appreciate your help, you've gotten me this far. I hope you don't get too exasperated with my noobness.

88fingerslukee said:
All right, I downloaded v1.8.1 of EVK and used it to load the dumped .NBH. This seemed to work flawlessly and I now have a folder called 'dump' that contains the following folders. (I manually entered the Device name NEON400 when EVK prompted for it):
EXT
MyTools
OEM
RELEASE_NEON400
ROM
SYS
Tools
I'm guessing I've successfully extracted the ROM image.
Click to expand...
Click to collapse
Looks like it; now take contents from the 'dump' folder and move it to the top of your kitchen folder. For example:
Move NEON400_Kitchen\dump to NEON400_Kitchen\ - Yes To All.
This was one of the steps in my Raphael Tutorial:
[TUT] Sous-Chef's Guide to XIP Porting in Ervius Visual Kitchen 9.7
http://forum.xda-developers.com/showthread.php?t=526610
Afterwards, make a copy of the kitchen as this copy ("backup") will serve as your source/baseline which you can always refer back against ... how you got started. You should never make changes to this copy; what I typically do is .RAR the copy and store it in a safe place along with the source file (ex: the download RRU from HTC, etc.)
i would like, for ease and simplicity, to just make this into a clean 6.1 version. I don't REALLY want to tackle 6.5 quite yet.
Is there a simple way to clean out the garbage? How do I know what's what?
I really appreciate your help, you've gotten me this far. I hope you don't get too exasperated with my noobness.
Click to expand...
Click to collapse
There's no quick or easy way; now comes the steep part of the climb.
If you haven't obtained a file comparison tool yet, that should be your next stop. You really should get a good one that allows binary comparisons and such ... I use BeyondCompare; it's not free but it's worth it. Once you obtain the file comparison tool, you can use it to compare an existing folder against another - such as comparing two kitchens. As an exercise, you could compare your kitchen against my last Raphael kitchen to give you an idea as to areas typically require additions/removals/changes.
WinMO6.1.21056 Raphael Kitchen
http://forum.xda-developers.com/showthread.php?t=471288
Also download the .TXT files attached to the kitchen thread as I noted all of the edits I made to the OEM, SYS, and ROM folders in those files. Examine those areas of your kitchen. Pay special attention to operator packages, '.PROVXML', and 'CONFIG_' files in the OEM folder. This is where you will usually where you will find many Carrier/Operator specific changes or lockdowns. I usually move most of this content to a 'profile' package in the EXT folder; I never use the profile directly, I copy/paste the to a 'custom profile' and use the custom profile ... this way, I can eliminate underised "Carrier/Operator" features and only apply those features that are absolutely necessary. Additionally, extra components (themes, cabs, etc.) are often installed via a series 'CONFIG_' packages; these will likely require alteration.
A few last things to remember along this part of the climb ...
stop for breaks
drink lots of coffee
have fun
and don't forget to yodel

may i ask a small Q....regardingthe OEM....
if i want to put an app in my cooke ROM i know that i can covert the app from cab--to---ext..however i can do cab--to--OME and OEM --to-- EXT...what are the different and which is better ??? really need help to understnad this

An OEM package is essentially a kitchen package. The term OEM came about partly because the ROM extraction tools - essentially, the tools extract the content of an OEM .NBH/.NB file. An OEM package usually consists of files, files as modules, <guid>.dsm, <guid>.rgu, shortcuts, *.provxml, *.txt, and *.dat.
When chefs refer to OEM packages, they are generally speaking about the folders that appear in .\OEM, .\SYS, and the .\PACKAGES (or .\EXT) folder. Here is some background for Ervius Package Builder (PkgBuildOS) & Ervius Visual Kitchen (EVK).
PkgToolsBuildOS
In the older PkgBuildOS kitchen, the OEM package had a relatively flat structure. Most OEM packages were prefixed with 'PACKAGE_' - chefs would see these folders in .\OEM and .\SYS. It was also preferable to move such folders into a '.\PACKAGES' folder structure making it easier to choose which packages to include during the ROM compilation. Ideally, chefs would only keep essential (critical) packages in the .\OEM and .\SYS. The structure of the OEM package would look similar to the following:
Code:
[B][COLOR="Blue"]<PACKAGE_oem_packagename>[/COLOR][/B]
[INDENT]<guid1>.rgu [COLOR="Purple"][I](<guid1>.rgu + <guid2>.rgu)[/I][/COLOR]
<guid1>.dsm
[COLOR="Purple"]<guid2>.dsm [I](removed)[/I][/COLOR]
files
*.provxml
shortcuts
*.txt
*.dat
option.xml
[B][COLOR="Blue"]<modulefoldername>.[[COLOR="Green"]ext[/COLOR]][/COLOR][/B] ([COLOR="green"][B]ext [/B][/COLOR]= dll, cpl, ocx, etc.)
[INDENT]imageinfo.bin
imageinfo.txt
S0001
S0002
S0003
...
[/INDENT]
[/INDENT]
Visual Kitchen
When Ervius created the Visual Kitchen, he also created a tool to convert old PkgBuildOS OEM packages into the new kitchen format. During the conversion process, the tool would read the .DSM filename information and rename the folder accordingly - sometimes a folder would be prefixed with 'PACKAGE_' and in other cases not; it depended on the internal .DSM name. The new format of the package was such that it divided the language-specific files into a sub-folder within the EVK OEM package.
Additionally, the tool would copy the OEM packages to the .\EXT folder as once again, it is preferable to have OEM packages in the '.\EXT' folder structure as it makes it easier to choose which packages to include during the ROM compilation. Ideally, chefs would only keep essential (critical) packages in the .\OEM and .\SYS. The structure of the OEM package would look similar to the following:
Code:
[B][COLOR="blue"]<oem_packagename>[/COLOR][/B][INDENT]<guid>.rgu
<guid>.dsm
app.reg
app.dat
_skip
[B][COLOR="blue"]Files[/COLOR][/B][INDENT]*.provxml
shortcuts
*.txt
*.dat
[B][COLOR="Blue"]<modulefoldername>.[[COLOR="Green"]ext[/COLOR]][/COLOR][/B] ([B][COLOR="green"]ext [/COLOR][/B]= dll, cpl, ocx, etc.)[INDENT]imageinfo.bin
imageinfo.txt
S0001
S0002
S0003
...
[/INDENT]
[/INDENT]
[B][COLOR="red"]<LANG> [/COLOR] ([COLOR="red"][B]LANG[/B][/COLOR] = 0409, 040C, etc.)[/B][INDENT]<guid2>.rgu
<guid2>.dsm
app.reg
app.dat
_skip
[B][COLOR="blue"]Files[/COLOR][/B][INDENT]*.provxml
shortcuts
*.txt
*.dat
[B][COLOR="Blue"]<modulefoldername>.[[COLOR="Green"]ext[/COLOR]][/COLOR][/B] ([B][COLOR="green"]ext [/COLOR][/B]= dll, cpl, ocx, etc.)[INDENT]imageinfo.bin
imageinfo.txt
S0001
S0002
S0003
...
[/INDENT]
[/INDENT]
[/INDENT]
[/INDENT]
The tutorials I put together for the Visual Kitchen (EVK) and Package Builder (PkgToolsBuildOS) provide some additional details about the folder structure of the kitchen so I won't get into more details about it here.
HTH,

The guy who failed miserably to cook a wm 6.5 rom,ultimately cooked the first ever wm 6.5 rom for Neon 400
http://forum.xda-developers.com/showthread.php?t=650446

damn... nothing to say just.......
if this guy wants to learn how to cook for his device... just leave him to learn, BTW why you dont leave intact the rom links?

Can ervius Visual Kitchen be used with Extreloc?

I'm trying to get an "old-style" 6.5 ROM built using EVK, and while using wmreloc builds the ROM successfully, it never boots. I've read about Extreloc in a few places, and apparently it's supposed to a better job of relocating modules. So does anyone know how to integrate Extreloc into EVK to cook a bootable, dumpable (possibly even Image Update-Ready) ROM?

Bepe specifically designed platformrebuilder to delete dsm files and the final s00x file in modules more or less to save space (he compared it to removing the ULDR in XIP) and improve module loading speed so unless you can make prb NOT do that then I doubt it. Although it sounds really interesting, I too wish we could try another reloc.

Psyki said:
Bepe specifically designed platformrebuilder to delete dsm files and the final s00x file in modules more or less to save space (he compared it to removing the ULDR in XIP) and improve module loading speed so unless you can make prb NOT do that then I doubt it. Although it sounds really interesting, I too wish we could try another reloc.
Click to expand...
Click to collapse
But I think the "old-style" option in Visual Kitchen actually adds the DSMs back in (or re-creates them) - have you tried it?

Extreloc
Speaking of Extreloc - does anyone know where I can find it (along with, perhaps, some instructions on the parameters to use with it)?

Captain_Throwback said:
Speaking of Extreloc - does anyone know where I can find it (along with, perhaps, some instructions on the parameters to use with it)?
Click to expand...
Click to collapse
Here are some links but not in English!!!
http://4pda.ru/forum/index.php?showtopic=137276
http://3ppc.net/forum/showpost.php?p=282398&postcount=45
Good luck!

kokotas said:
Here are some links but not in English!!!
http://4pda.ru/forum/index.php?showtopic=137276
http://3ppc.net/forum/showpost.php?p=282398&postcount=45
Good luck!
Click to expand...
Click to collapse
Thanks for these links!!
I did find a downloadable Extreloc, and the one link had a good manual (thanks to Google Translate). Of course, I still can't cook an old style ROM with EVK, because, even though the OEM & SYS work okay, DSM Editor doesn't have the information to create DSMs for the EXT packages, apparently, which is where the issue lies. I wonder if I can create DSMs for all of the EXT packages, put them in the packages, and see if I can dump the ROM?

Captain_Throwback said:
Thanks for these links!!
I did find a downloadable Extreloc, and the one link had a good manual (thanks to Google Translate). Of course, I still can't cook an old style ROM with EVK, because, even though the OEM & SYS work okay, DSM Editor doesn't have the information to create DSMs for the EXT packages, apparently, which is where the issue lies. I wonder if I can create DSMs for all of the EXT packages, put them in the packages, and see if I can dump the ROM?
Click to expand...
Click to collapse
i havent tried cooking old style rom in a long time, but doesnt evk place dsm/rgu in ext pkgs when you dump a stock rom? thats one reason i stopped using evk to dump stock roms and rebuild, now i use extrebuild its so much cleaner

twopumpchump said:
i havent tried cooking old style rom in a long time, but doesnt evk place dsm/rgu in ext pkgs when you dump a stock rom? thats one reason i stopped using evk to dump stock roms and rebuild, now i use extrebuild its so much cleaner
Click to expand...
Click to collapse
It puts them in the folder with the EXT packages, yes, but not in a place where they get cooked into the ROM (if cooking a new-style ROM, that is). It also creates a package.ini file that details the dependency information for each package, based on the info in the DSM. It only keeps them there for cooking an "old-style" ROM, which is what would make this work as I would like it; except it doesn't work properly, and for user-made packages that don't include DSMs, DSM Editor doesn't seem to create them properly when cooking an old style ROM.

i cooked an image update rom for kaiser back last year, and i just used build OS old style kitchen to cook the rom and it worked i cant wait to be able to start using image updater, but its a real pita to cook a rom that it will work on now...and like you said its really hard to put in custom pkgs, with kaiser i basically re-cooked a stripped down stock rom. Da_G is getting closer to having his new kitchen tools done, then we should be able to build roms easily that will work with the updater

@captain
I am also looking for the exactly the same. I too want to cook in old style. But, not able to find any rebasing tool equivalent of the one in platformrebuilder.exe. Extreloc, though, is claimed to work well but for me it does not give very dependable results.
I am also interested in this kind of solution Pl update us here in case you manage to find any...

Maybe this helps?
I don't know where I have it from anymore, if I remember good it was Conflipper who shared that maybe at Mobile Underground , haha I'm realy not sure.
LoL
But I think it's something you can use.

Laurentius26 said:
Maybe this helps?
I don't know where I have it from anymore, if I remember good it was Conflipper who shared that maybe at Mobile Underground , haha I'm realy not sure.
LoL
But I think it's something you can use.
Click to expand...
Click to collapse
Thanks Leo, but EVK comes with this version of WMReloc. I've tried using it to cook a 6.5 "old-style" ROM, and while the ROM compiles successfully, it won't boot. I'm thinking it could be related to module overlaps due to WMReloc's not handling the 6.5 modules properly (even though I know it's supposed to). In fact that may not be the case, but I thought EXTReloc was supposed to a better job of this. I think the real issue (and I may have already stated this) is that the DSMs from the EXT packages aren't being properly re-created during the build process by DSM Editor (perhaps that's outside the realm of what it can do?). In most cases, my EXT packages have been dumped from official ROMs, and as such have the DSM/RGU's outside of the "files" folder. They should be easily re-integrated during cooking, but I don't think that step is taking place. Perhaps it's as simple as adding a command into the batch file to copy those files into the "dump" folder for each package (I'm not really sure the best way to do that, though)? And what about packages that happen to be missing that information? Is there a way to re-create those on the fly, or would that need to be done manually? I assume for custom packages (like graphics, etc.), dependency information isn't really needed, but when dumping the ROM, those files won't have a home, I suppose .

Here's a quote from Da_G, maybe you need to use Misar's G'Reloc?
Btw I'm just a nOOb with all these tools and batch files, I know a little but just trying to help you.
Maybe a little about batches... and I read a lot.
Da_G said:
WinMo 6.5 improves on this by opening up Slots 60 and 61 to Modules - yielding an extra 64mb of potential Virtual Memory space. (the allocation order is now 1, 61, 60, 0 for modules, 60, 61, 0 for files) - In order for the Kernel to recognize these new Slots as being mappable for Modules, it must be updated to the 6.5 codebase. This is where the 6.5 nk.exe comes in, and why it's so important.
Profiling Virtual Memory is an important job for an OEM - the less available in Slot 0, the sooner a device will kick back out of memory errors (even if it's not truly out of memory) - and the worse the user experience will be. Some ROM's I have seen have less than 20MB available in slot 0 (and the user experience is as bad as you might imagine) - There are many more intricacies to the whole process - like balancing the load between services.exe and device.exe to best utilize the 32mb VM space available to each, and storing all resource-only dlls as modules so they can be allocated to Slot 63, etc.
This is also why it's important that the re-alloc tools be updated to support the new slots - g'reloc will not ever try to allocate modules to slot 60/61 because as far as it's aware, this is not possible. For the moment I know of 2 tools that will realloc to slot 60/61, wmreloc 2.0, and bepe's Platform Rebuilder (used by ervius vk)
What's the take-home message about VM?
Keep Slot 0 as free as possible. WM 6.5 NK allows you to use more modules without taking up SLOT 0 space, so allows more flexibility to use modules (which are faster to load)
Click to expand...
Click to collapse
Captain_Throwback said:
Thanks Leo, but EVK comes with this version of WMReloc. I've tried using it to cook a 6.5 "old-style" ROM, and while the ROM compiles successfully, it won't boot. I'm thinking it could be related to module overlaps due to WMReloc's not handling the 6.5 modules properly (even though I know it's supposed to). In fact that may not be the case, but I thought EXTReloc was supposed to a better job of this. I think the real issue (and I may have already stated this) is that the DSMs from the EXT packages aren't being properly re-created during the build process by DSM Editor (perhaps that's outside the realm of what it can do?). In most cases, my EXT packages have been dumped from official ROMs, and as such have the DSM/RGU's outside of the "files" folder. They should be easily re-integrated during cooking, but I don't think that step is taking place. Perhaps it's as simple as adding a command into the batch file to copy those files into the "dump" folder for each package (I'm not really sure the best way to do that, though)? And what about packages that happen to be missing that information? Is there a way to re-create those on the fly, or would that need to be done manually? I assume for custom packages (like graphics, etc.), dependency information isn't really needed, but when dumping the ROM, those files won't have a home, I suppose .
Click to expand...
Click to collapse

Just as an aside info..... the evk dont uses DSMs i mean they are useless at this point for the kitchen... maybe next generation kitchens will tell you... "Hey if you need to cook this Module for this App you need to add this and this and this due to dependencies"

Hi All
How to apply All_packages_to_one after Extreloc?
Any ideas?

[Q] Kitchen for HD mini

Dear developers,
can somebody answer which kitchen we can use for HD mini?????

Yup...EVK will be a good one for that...

Get the EVK kichen... find a stock HD MIni ROM... dump it using the EVK and get cooking!

Interesting.... i just want to say that you need to be carefull cause the HQVGA is an unussual size in new builds hopefully the rollup comes more often

+ Que PPC said:
Interesting.... i just want to say that you need to be carefull cause the HQVGA is an unussual size in new builds hopefully the rollup comes more often
Click to expand...
Click to collapse
com3.2 aka 231xx should come HVGA since thats the normal branch for the phone.

Johan Kraczmar said:
Dear developers,
can somebody answer which kitchen we can use for HD mini?????
Click to expand...
Click to collapse
OSKitchen should be able to dump and rebuild the ROM for that phone without any issue even if it's not in the list as long as you know how to rename the EXT packages to give them the right order (that's an issue you will also have with EVK but on EVK you'll probably have many more unless you use an adapted version for your phone with the right packages already recmodded inside).
BTW I'm working right now on a way to finally apply the DSM building order that all other kitchens seem to ignore to rebuild the latest phone ROMs 100% correctly.

airxtreme said:
OSKitchen should be able to dump and rebuild the ROM for that phone without any issue even if it's not in the list as long as you know how to rename the EXT packages to give them the right order (that's an issue you will also have with EVK but on EVK you'll probably have many more unless you use an adapted version for your phone with the right packages already recmodded inside).
BTW I'm working right now on a way to finally apply the DSM building order that all other kitchens seem to ignore to rebuild the latest phone ROMs 100% correctly.
Click to expand...
Click to collapse
Thank you for answer.
Can you help me with setting in htcrt_devices.ini ????

Johan Kraczmar said:
Thank you for answer.
Can you help me with setting in htcrt_devices.ini ????
Click to expand...
Click to collapse
osKitchen doesn't need that file because it automatically detects the NBH structure trough libNB; that's why I told you it should work even if the device is not on the supported list. As long as platformrebuilder doesn't cause some trouble (EVK is platformrebuilder-based too) oskitchen can work with any ROM as long as it can import and build the format (and NBH of course is supported).

Everything is clear.THX

airxtreme said:
BTW I'm working right now on a way to finally apply the DSM building order that all other kitchens seem to ignore to rebuild the latest phone ROMs 100% correctly.
Click to expand...
Click to collapse
Just a small correction here: Barin's OSBuilder does not ignore that issue. In fact there in a tool in his kitchen to modify packages.sof, so that you can even modify the build order. This is important when adding new packages which have .dsm not in stock roms, to ensure that they are build in the preferred order (ie: tweaks last).
@ OP, if you do use EVK to dump and build, be sure to clean the dump of duplicate files inside modules after dump, which is an issue with EVK's dump process. Also, with EVK (and likely OSKithcne) you need to recmod NTFConfig.dll to get a bootable rom. This is also not an issue with Barin's OSBuilder, which I highly recommend to every chef. I find this kitchen to be a superb tool compared to any kitchen to date.

mmmm interesting kitchen... lets try something new... cause the winmo times are getting bored this days

indagroove said:
Just a small correction here: Barin's OSBuilder does not ignore that issue. In fact there in a tool in his kitchen to modify packages.sof, so that you can even modify the build order. This is important when adding new packages which have .dsm not in stock roms, to ensure that they are build in the preferred order (ie: tweaks last).
Click to expand...
Click to collapse
I've never tried that kitchen however I can tell you that how I've implemented shadow ordering support is pure bliss. For example as you probably know HTC ROMs rely on many virtual packages (Project Default and others) to guarantee the building order and if you delete one of them (some of these packages are completely empty) everything breaks and that the shadow dependencies are often done on localized packages so changing language could also cause havoc.
In my kitchen I normalize all the packages dependencies during import so that all the dependencies on LCID folders and on those virtual folders are gone (so those can be safely deleted), I have a package property tab to set the shadow order of any package (if the DSM is not there it will be created), it has detailed checks for short circuits (infinite dependencies loop), etc. It's really, really well done.
indagroove said:
@ OP, if you do use EVK to dump and build, be sure to clean the dump of duplicate files inside modules after dump, which is an issue with EVK's dump process. Also, with EVK (and likely OSKithcne) you need to recmod NTFConfig.dll to get a bootable rom. This is also not an issue with Barin's OSBuilder, which I highly recommend to every chef. I find this kitchen to be a superb tool compared to any kitchen to date.
Click to expand...
Click to collapse
Well the two kitchens are in two completely different leagues: OSBuilder seems to be aimed to rebuild the ROM as best as possible following the microsoft standards (for example only flat packages, no EXT) while mine is aimed at offering the most complete and easy solution indeed the autoimport, (there is no informations associated to the device names in the import list, the kitchen finds everything out by itself to rebuild the NBH/BIN/TSW for that device), batch multi-language ROMs generation, easily structured UI and also all the warnings to limit user mistakes to minimum, from an easy automatically recmodding of packages that prb dislikes to much crazier extents like checking the Radio/splash files signatures are OK or making sure the user doesn't try to import packages from the wrong folder (like C:\) destroying his filesystem. Just because my kitchen is (sadly) still platformrebuilder-based it doesn't mean it has to be trashed though: as you may know Da_G is rewriting all the tools properly (100% compliant to the original standards) and I'm adapting his LibNB functions to the kitchen as soon as those became available hence the actual ability of dump/rebuild any NBH correctly without even knowing what device it is and hopefully soon internal XIP porting so that the kitchen will be already able (with extreloc for the IMGFS) to build its own ROMs for any device without any of the platformrebuilder limitations.

[Q] [PROBLEM][HERMES-TYTN]Default.hv cooked ROM

Hi,
I have a really strange problem.
I have two HTC HERMES, one good that I use and a second that I use only fot test purposes because it's not in good conditions.
I cook ROMs with "ROMDonalds Kitchen" and I have neved had any problem.
Since yesterday, every new ROM I cook, I have this problem:
if I don't edit "default.hv" the cooked ROM goes well in both my HERMES, but if I edit it, the ROM can only be loaded on the second HERMES (the one not in good conditions).
In the other HERMES after flashing, when I make the reset or even the hard-reset, the ROM begins to boot but then stops after the first splash-screen and the screen becames white.
I always flash from SD (hermimg.nbh).
What can be the problem?
Can be a problem of the good HERMES of the two I have?
Can be a difference in hardware between the good HERMES, even if they are identical from outside?
Many thanks !

Hi,
I don't understand why you need to edit default.hv but probably you have your reason.
It's better to leave it untouched to my opinion.
To edit the registry you can edit the .rgu in the specific package or create
a new package with the new registry overwriting the first package registry.
The second suggestion you can keep your tweaks in every rom you cook and switch the stock packages more easy.
What you are writing is indeed weird but this way you avoid errors in the .hv files.
Edit; btw, because Hermes is a pretty old device I'm asuming the kitchen you use is still using .rgu instead of .reg in the packages, latest kitchens mostly use .reg
.rgu and .reg files are same and containing the registry.
Grtz,
Laurentius26

yeah its true, what do you change in the d.hv? maybe you can tell us, what about to use another kitchen? or do your changes in app.reg ext pkgs or in oem packages to void edit it

I edit .hv files when I add or remove programs from the ROM.
I've tried also Ervius kitchen but when I try to dump my ROMs It gives me some errors...the only kitchen I was able to use is RomDonald's..
Can You suggest me another good one?
Thanks

Airxtreme's Oskitchen or Barin's OSbuilder, they are both in Chef Central here.
You don't need to edit .hv files as when you remove the package all registry of that package will be gone too.
eryunt said:
I edit .hv files when I add or remove programs from the ROM.
I've tried also Ervius kitchen but when I try to dump my ROMs It gives me some errors...the only kitchen I was able to use is RomDonald's..
Can You suggest me another good one?
Thanks
Click to expand...
Click to collapse

I dont think ROMDonalds processes rgu files. If I remember correct, you have edit the hive files to use that kitchen.

Wow, that's gotta be a huge pain in the butt.

ai6908 said:
I dont think ROMDonalds processes rgu files. If I remember correct, you have edit the hive files to use that kitchen.
Click to expand...
Click to collapse
Yes, It is correct.
But the strange thing is that only one of the two Hermes I have, accepts the ROM after I edit the .hv files...
The question is:
Is there a separate memory where the hive is stored, and can this memory be faulty in one of my Hermes?

eryunt said:
...Is there a separate memory where the hive is stored, and can this memory be faulty in one of my Hermes?...
Click to expand...
Click to collapse
If you mean the fixed address - the answer is No. *.hv are files and files do not have the fixed address.

I've tried also Ervius Visual Kichen, but when I dump my ROM It gives me these two errors:
1- "Xipkernel's DSM not found! I'll create new...Maybe protected XIP (not portable !!!)"
2- "Boo.rgu in xip not found!Create new...But maybe ROM will be NON BOOTABLE !!!)"
What's wrong?
Thanks for all the answers You provide !
XDA, really a great Community !!!

Hi,
I don't know what you are doing to setup Ervius?
Are you importing a new stock rom into the kitchen?
The errors you can check:
Ervius kitchen/Rom/Shared/'Sys build'/MSXipkernel/
boot.rgu and the .dsm should be there.
Without boot.rgu and the dsm the rom won't boot.
Are all your desktop system files unhidden and vissible?
eryunt said:
I've tried also Ervius Visual Kichen, but when I dump my ROM It gives me these two errors:
1- "Xipkernel's DSM not found! I'll create new...Maybe protected XIP (not portable !!!)"
2- "Boo.rgu in xip not found!Create new...But maybe ROM will be NON BOOTABLE !!!)"
What's wrong?
Thanks for all the answers You provide !
XDA, really a great Community !!!
Click to expand...
Click to collapse

The visualization of hidden files is active in my PC, and I am trying to import a NON STOCK ROM to add or remove packages.
Ervius kithchen gives me the errors I described, and also OSKitchen gives me errors..
Can these kitchens import only STOCK ROMs?
I used ROMDonald's kitchen because It was able to edit a ROM that was already cooked...but the editing of .hv files is wrong...

I advise you to use a stock rom as you can test if everything is working ok.
After this you can do your modifications.
I know it's a bit of work but the advantage is to use a new kitchen which is much more configurable.
Editing .hv files isn't that good, but we talked about that already.
Another tip, I always zip my kitchen after I know a configuration is working and I flashed the rom succsesvol, before I continue to the next step.
eryunt said:
The visualization of hidden files is active in my PC, and I am trying to import a NON STOCK ROM to add or remove packages.
Ervius kithchen gives me the errors I described, and also OSKitchen gives me errors..
Can these kitchens import only STOCK ROMs?
I used ROMDonald's kitchen because It was able to edit a ROM that was already cooked...but the editing of .hv files is wrong...
Click to expand...
Click to collapse

eryunt said:
Yes, It is correct.
But the strange thing is that only one of the two Hermes I have, accepts the ROM after I edit the .hv files...
The question is:
Is there a separate memory where the hive is stored, and can this memory be faulty in one of my Hermes?
Click to expand...
Click to collapse
It doesnt make sense why one device would run it, and the other one dont! Are you sure the hive files do not have any errors?
Try to flash a stock ROM first, then flash the cooked one. I know hermes has ext storage, and that can through errors...

ai6908 said:
It doesnt make sense why one device would run it, and the other one dont! Are you sure the hive files do not have any errors?
Try to flash a stock ROM first, then flash the cooked one. I know hermes has ext storage, and that can through errors...
Click to expand...
Click to collapse
That's the point...It's a nonsense..
I've already tried to flash stock ROM on both devices before flashing the cooked ROM, but It's always the same nonsense, one loads the ROM, the other doesn't...
At this point only a malfunction or a difference in hardware between my two devices could explain this strange behaviour
Don't know how to solve...

are you trying to recook my roms? hahaha just kiddin
everybody knows that we don thave bootable and full dumped roms from customized ones, due to DSMsif you want to make a roms looks like or be something like a... i recommend to ask for the kitchen many retired chefs on Legacy devices can share it to you or just dump the rom and xtract the things you want
but make your own Stock OEM an set good your Native Kernel