Related
two roms, I dump using imgfs tools
dump_MemoryMap_1.txt -- rom1
01130000 - 01133FFF ( 16383 bytes): HTCcamera.dll
dump_MemoryMap_2.txt -- rom2
011A0000 - 011A3FFF ( 16383 bytes): HTCcamera.dll
I hope to replace htccamera.dll in rom1, so i copy htccamer.dll directory from
rom2\dump to rom1\dump, and then change e32_vbase, o32[?].o32_realaddr into 01130000 in imageinfo.txt and imageinfo.bin.
and then build the rom, flash it to machine, but it don't work,
what's wrong with my operation?
Hi,
I would appriciate if somebody could help me with the following.
Currently I'm trying to build my own wm6 rom and conversion off roms is no problem for me anymore.
Next step is changing and comparing registry hives but I'm stuck a little!
The registry hives I'm talking about are:
-default.hv
-user.hv
I downloaded RGUCOMP and also have the Registry workshop.
What I'm trying to figure out is how can I convert *.hv files to files to working registry string so that I can edit and compare them with the Registry workshop.
I do know this but don't understand:
dump default.hv:
1. SET _FLATRELEASEDIR=.
2. RGUCOMP -o default.hv -nologo > default.txt
3. Add 'REGEDIT4' (first line)
4. Last line MUST be empty
5. Save as UNICODE
... edit the txt file ...
build default.hv:
1. rename default.txt to boot.rgu (same folder as RGUCOMP.exe)
2. SET _FLATRELEASEDIR=.
3. RGUCOMP -b
4. rename boot.hv to default.hv
Enter this: "RGUCOMP -o default.hv -nologo > default.txt
", 'you should not see the reg entries, because "> default.txt" redirects the output to default.txt '.
Is there no solution to convert a *.hv file to a working registry string *.reg?
Or maybe there is a solution to export the registry from my device and convert it to a *.hv
I'm new to this and any help would be higly appriciated!
Greetings, Leo
after :
RGUCOMP -o default.hv -nologo > default.txt
you'll see default.txt contain all the regkey.
since default.txt doesn't contain the first line 'REGEDIT4',
so you need to add it.
it's same in user.hv
Won't get it
Hi Leies,
Thank you for your reply,
still don't understand, do I have to name the file REGEDIT4 .txt after created, or the first line in the opend textfile must be REGEDIT4, and what about the empty line, do I tab twice [ENTER] to have that and save the textfile in unicode? Sorry I'm stupid, but I just don't get it, it stays blank, weird? Can you send me a sample so I can see please?
Greetings Leo
Leies said:
after :
RGUCOMP -o default.hv -nologo > default.txt
you'll see default.txt contain all the regkey.
since default.txt doesn't contain the first line 'REGEDIT4',
so you need to add it.
it's same in user.hv
Click to expand...
Click to collapse
one more question
Can I create a subdirectory for this c:\hv files\.. and place the boot.hv and user.hv together with rgucomp files in here, or should it be in c:\..
Thanks,
Leo
not name the file, it's add at the first line..
did you got the dump folder already ?
default.hv and user.hv are in dump folder after you have extracted imgfs_raw_data.bin by viewimgfs.exe . (maybe different when you use other tool)
rgucomp -o dump\default.hv -nologo > default.rgu (or default.txt as you like)
then, default.rgu will stored in rgucomp.exe same folder, not at dump folder.
It may help, just try for dumping default.hv:
1. SET _FLATRELEASEDIR=.
1b. echo REGEDIT4 > default.txt
2. RGUCOMP -o default.hv -nologo >> default.txt
Click to expand...
Click to collapse
No need the 3rd original step and you should be able to open default.txt with notepad
Hi,
Thanks for your answer.
Still don't work, this is the error:
wmain: (RGUComp) !ERROR release directory ".echo REGEDIT4 " does not exist
What am I doing wrong?
Please, please, help.
Leo
naboleo said:
It may help, just try for dumping default.hv:
No need the 3rd original step and you should be able to open default.txt with notepad
Click to expand...
Click to collapse
*.hv
Hi thanks again
Will try tomorrow, today I'm having my birthday party
Greetings, Leo
Leies said:
not name the file, it's add at the first line..
did you got the dump folder already ?
default.hv and user.hv are in dump folder after you have extracted imgfs_raw_data.bin by viewimgfs.exe . (maybe different when you use other tool)
rgucomp -o dump\default.hv -nologo > default.rgu (or default.txt as you like)
then, default.rgu will stored in rgucomp.exe same folder, not at dump folder.
Click to expand...
Click to collapse
Did a bat command sample file. Just rename it *.bat instead os *.bat.txt and run it. It should create both user and defaut registry and open them directly in notepad.
Btw : happy birthday !
Found it
Hi,
Thank you Naboleo and Leies
1. set _flatreleasedir=c:\dump
2. RGUCOMP -o default.hv -nologo > default.txt
3. RGUCOMP -o user.hv -nologo > user.txt
Both added first line REGEDIT4, last line empty and saved as unicode!
Done
I'm sooooo happy
Greetings Leo
Again another question
Hi,
I'm making you grazy I know but this is realy important for me, Im almost there building the rom.
Currently I'm busy with RGUCOMP, I converted user.hv to a user.txt file and edited the strings (just some ringtones to delete), now I'm trying to convert back but it doesn't work, it gives some errors.
build user.hv
1. rename user.txt to boot.rgu
2. SET _Flatreleasedir=c:\dumphv (this is my dir)
3. RGUCOMP -b
4. rename boot.hv to user.hv
The errors:
Buildboothive: <RGUCOMP> !ERROR unable to find required source file "Boot.rgu"
ERROR C:\MacB\private\winceos\COREOS\filesys\reg\reghive \.hive c line 877: FS: Registry Exception Handler
wmain: <RGUCOMP> !ERROR failed building BOOT hive
It makes me grazy haha...
Any ideas
Thanks again,
Leo
Laurentius26 said:
Hi,
build user.hv
1. rename user.txt to boot.rgu
2. SET _Flatreleasedir=c:\dumphv (this is my dir)
3. RGUCOMP -b
4. rename boot.hv to user.hv
The errors:
Buildboothive: <RGUCOMP> !ERROR unable to find required source file "Boot.rgu"
ERROR C:\MacB\private\winceos\COREOS\filesys\reg\reghive \.hive c line 877: FS: Registry Exception Handler
wmain: <RGUCOMP> !ERROR failed building BOOT hive
It makes me grazy haha...
Any ideas
Thanks again,
Leo
Click to expand...
Click to collapse
did your rgucomp.exe and boot.rgu in c:\dumphv ?
if yes , just type :
set _FLATRELEASEDIR=.
rgucomp -b
it could be done .
since i'm lazy than u, so i have wrote a *.bat tfile to do extract and repack process .
* remember boot.rgu , you need to rename it to default.hv and copy to "dump" fiolder .
* if you can't directly copy in ( show error ), you may try this command :
attrib -s -r -h dump\default.hv
and then del it .
PS : Happy Birthday Man !
Converting back
@Leies
Thank you for your quick reply's
I love a vampire like you
It doesn't work yet
Two files I've I copied from the dump directory to compile:
-default.hv
-user.hv
Converted them to:
-default.txt
-user.txt
They are in c:\dumphv together with the tools:
-boot.rgu
-cereg400.dll
-make_boot_hv.bat
-rgucomp.exe
How to do this?
default.txt => default.hv
user.txt => user.hv
After that I can copy them back to the dump and start build_imgfs, would be great
I'm enjoying my birthday
Cheers, Leo
Hihi, i seen your post in universal , so i guess that you're cooking a uni rom and using helmi_c method , since i had cooked many for my uni , but not using helmi_c 's method , so maybe something differents ...
ok , let's go ,
when you use "rgucom -b" , the file name of default.hv should rename to boot.rgu , after rgucom success , it'll create a file "boot.hv" and copy it to dump\ and rename to default.hv ,
same as user.hv , should rename to boot.rgu when "rgucom -b" , after rgucom, it'll create a file "boot.hv" and copy it to dump\ and rename to user.hv ,
maybe you can use this to create a bat file and it will auto finish for you .
you can add "pause" if you like to see some information when batch runs.
cd\
cd temp
copy default.rgu boot.rgu
set _FLATRELEASEDIR=.
rgucomp -b
PAUSE
attrib -s -r -h dump\default.hv
del dump\default.hv
copy boot.hv dump\default.hv
del boot.hv
del boot.rgu
copy user.hv boot.rgu
set _FLATRELEASEDIR=.
rgucomp -b
attrib -s -r -h dump\user.hv
del dump\user.hv
copy boot.hv dump\user.hv
del boot.hv
del boot.rgu
PAUSE
BuildImgfs
PAUSE
make_imgfs nk.fat -nosplit
Your so helpful
I'm starting to love you.
That's dangerous isn't?
Anyway, thank you, thank you, thank you
Will let you know how rom is progressing if you like?
Leo
Leies said:
Hihi, i seen your post in universal , so i guess that you're cooking a uni rom and using helmi_c method , since i had cooked many for my uni , but not using helmi_c 's method , so maybe something differents ...
ok , let's go ,
when you use "rgucom -b" , the file name of default.hv should rename to boot.rgu , after rgucom success , it'll create a file "boot.hv" and copy it to dump\ and rename to default.hv ,
same as user.hv , should rename to boot.rgu when "rgucom -b" , after rgucom, it'll create a file "boot.hv" and copy it to dump\ and rename to user.hv ,
maybe you can use this to create a bat file and it will auto finish for you .
you can add "pause" if you like to see some information when batch runs.
cd\
cd temp
copy default.rgu boot.rgu
set _FLATRELEASEDIR=.
rgucomp -b
PAUSE
attrib -s -r -h dump\default.hv
del dump\default.hv
copy boot.hv dump\default.hv
del boot.hv
del boot.rgu
copy user.hv boot.rgu
set _FLATRELEASEDIR=.
rgucomp -b
attrib -s -r -h dump\user.hv
del dump\user.hv
copy boot.hv dump\user.hv
del boot.hv
del boot.rgu
PAUSE
BuildImgfs
PAUSE
make_imgfs nk.fat -nosplit
Click to expand...
Click to collapse
Last one
Hi Leies,
Must be something else!
Here's my story if you want to read.
My device: Universal
The rom I'm trying to build is WM6
I'm using a nk.nba ('Rom' folder) out of Helmi_C's kitchen.
The only thing I want to do is to take some ringtones out there!
So here it is:
cd\
cd\dump
prepare_imgfs nk.nba -nosplit
viewimgfs imgfs_raw_data.bin
dump directory created.
Take the ringtones out.
Maybe here I'm going wrong, I need to edit User.hv and default.hv to take the registry values out, wright ?
It works ok if I leave User and default.hv beside but when i look in my phone under ringtone settings the values are there but when I select them as ringtone the ringtones don't exist's, so that's uckly.
Yes, and I also edited the initflashfiles.dat in the responsable OEM
Next I copy to the dump directory:
boot.rgu
cereg400.dll
make_boot_hv.bat
rgucomp.exe
cd dump
set _flatreleasedir=c:\dump
RGUCOMP -o user.hv -nologo > user.txt
I edit the text and save it as unicode textfile.
Still in dump directory.
RGUCOMP -b
So know user.txt is in boot.rgu
I change the name to user.hv
Same for default.hv
batchfile's are coming later, I'm not so fast as you
Both I copy back to my dumped 'rom' (from here I took them in the first way, so I overwrite them with the new ones)
build_imgfs imgfs_raw_data.bin
make_imgfs nk.nba
Done, ready to use for kitchen. (but not when I edit the *.hv?)
Cheers, Leo
b.t.w. You builded some Roms before for the Universal isn't?
I need to no this please, because I've got the feeling that I'm close to rombuilding, this is the last key that has to suite.
I have a dell axim X50 and I would like to customize my rom image (WM5 or WM2003 SE, but perferably WM5). I have been searching the forums and have found no solutions (that I know of). The axim uses .nb0 files to flash a rom image, but I have only found rom kitchens that produce .nbf files or some other format. I have no idea on how to use Mamaich's rom tools properly for the axim. I have already dumped the rom image of my axim using the 128mb grab_it tool found on this site. Can someone please head me in the right direction and help me get started?
bump - i too am interested in this
Try Aximsite.com
I got a upgrade for my old x5 ce to wm2003 from there.
heh the axims were years ahead at there time.. I still use it today for fun, with a $20 wifi compact flash card. It's better than my hermes for media playback webbrowsing etc. Must be over 5 years old. has a bigger screen, longer battery life, faster cpu, 2 memory slots sd & flash. enhanced infrared, so I can actually use it as a remote controll. Shame no phone.. & it needs those crappy watch batterys.
Hmm infact playing with it as I write this.. Its soo much more responseive than my hermes !!.. Bring back 2002. I took it to siggraph then, people from movie/games/technology were all wtf thats amazing.. never got that from newer phones, execpt when showing dirty vids to me m8s down the pub.
Post back if you get lucky on newer roms.. I fear however the day of the axim is gone. And from what I understand unfortunatly there is too much crazy hard code/schematics needed from the original devs for home brewers to have a bash.
Good luck
Steven855 said:
I have a dell axim X50 and I would like to customize my rom image (WM5 or WM2003 SE, but perferably WM5). I have been searching the forums and have found no solutions (that I know of). The axim uses .nb0 files to flash a rom image, but I have only found rom kitchens that produce .nbf files or some other format. I have no idea on how to use Mamaich's rom tools properly for the axim. I have already dumped the rom image of my axim using the 128mb grab_it tool found on this site. Can someone please head me in the right direction and help me get started?
Click to expand...
Click to collapse
1, welcome to xda-dev
2, http://forum.xda-developers.com/showthread.php?p=1430712
Menneisyys said:
1, welcome to xda-dev
2, http://forum.xda-developers.com/showthread.php?p=1430712
Click to expand...
Click to collapse
This doesn't help me at all. There is no reference to any tools used or any instructions used to modify roms. On almost every thread I have seen, a noob has always deffered by someone who said that there are other threads that cover modifying roms. I have searched and searched and found no instructions for modifying a dell axim's rom. I have found tools for almost every other device referenced on this site. Can someone give me clear instructions for modifying the rom image for a dell axim X50 (mid)?
Steven855 said:
This doesn't help me at all. There is no reference to any tools used or any instructions used to modify roms. On almost every thread I have seen, a noob has always deffered by someone who said that there are other threads that cover modifying roms. I have searched and searched and found no instructions for modifying a dell axim's rom. I have found tools for almost every other device referenced on this site. Can someone give me clear instructions for modifying the rom image for a dell axim X50 (mid)?
Click to expand...
Click to collapse
Ask Football for help in the linked thread (or in the original Russian one) - he will prolly help you with Axim-specific issues.
Steps for X51v Rom
maybe the same for x50 (for detail instruction, search my old post for Asus P525 customization thread as reference), U can put this as DOS batch file for automation.
prepare_imgfs.exe DiAd_K_AximX51v_WM6_A01EN.nb0 -nosplit
viewimgfs.exe imgfs_raw_data.bin
SET _FLATRELEASEDIR=.
rgucomp -o dump\default.hv -nologo > default.txt
rgucomp -o dump\user.hv -nologo > user.txt
REM ***** Edit the rom by using Addfile/Delfile or play around w/ the dump directory
SET _FLATRELEASEDIR=.
copy /y default.txt boot.rgu
RGUCOMP -b
copy /y boot.hv dump\default.hv
copy /y user.txt boot.rgu
RGUCOMP -b
copy /y boot.hv dump\user.hv
REM ----------------------
REM *** Configure the folder ****
Delfile.exe initflashfiles.dat
Addfile.exe initflashfiles.dat
REM *** Registry ****
Delfile.exe default.hv
SET _FLATRELEASEDIR=.
copy /y default.txt boot.rgu
RGUCOMP -b
copy /y boot.hv default.hv
Addfile.exe default.hv
Delfile.exe user.hv
copy /y user.txt boot.rgu
RGUCOMP -b
copy /y boot.hv user.hv
Addfile.exe user.hv
rem **BuildImgfs.exe
make_imgfs.exe DiAd_K_AximX51v_WM6_A01EN.nb0 -nosplit
copy /y DiAd_K_AximX51v_WM6_A01EN.nb0 f:
copy /y DiAd_K_AximX51v_WM6_A01EN.nb0.crc f:
jackleung said:
maybe the same for x50 (for detail instruction, search my old post for Asus P525 customization thread as reference), U can put this as DOS batch file for automation.
prepare_imgfs.exe DiAd_K_AximX51v_WM6_A01EN.nb0 -nosplit
viewimgfs.exe imgfs_raw_data.bin
SET _FLATRELEASEDIR=.
rgucomp -o dump\default.hv -nologo > default.txt
rgucomp -o dump\user.hv -nologo > user.txt
REM ***** Edit the rom by using Addfile/Delfile or play around w/ the dump directory
SET _FLATRELEASEDIR=.
copy /y default.txt boot.rgu
RGUCOMP -b
copy /y boot.hv dump\default.hv
copy /y user.txt boot.rgu
RGUCOMP -b
copy /y boot.hv dump\user.hv
REM ----------------------
REM *** Configure the folder ****
Delfile.exe initflashfiles.dat
Addfile.exe initflashfiles.dat
REM *** Registry ****
Delfile.exe default.hv
SET _FLATRELEASEDIR=.
copy /y default.txt boot.rgu
RGUCOMP -b
copy /y boot.hv default.hv
Addfile.exe default.hv
Delfile.exe user.hv
copy /y user.txt boot.rgu
RGUCOMP -b
copy /y boot.hv user.hv
Addfile.exe user.hv
rem **BuildImgfs.exe
make_imgfs.exe DiAd_K_AximX51v_WM6_A01EN.nb0 -nosplit
copy /y DiAd_K_AximX51v_WM6_A01EN.nb0 f:
copy /y DiAd_K_AximX51v_WM6_A01EN.nb0.crc f:
Click to expand...
Click to collapse
Can someone please verify that that this works for the dell axim X50?
Here is one small file that creates Option.xml files in Sys, OEM and Packages folders.
Valid comands are:
OE.exe /Sys - for parsing folders in Sys directory
OE.exe /Oem - for parsing folders in OEM directory
OE.exe /Packages - for parsing folders in Packages directory
OE.exe /All - for parsing folders in Sys, OEM and Packages directories
OE.exe /C your_dir - for parsing custom directory
OE.exe /C your_dir /R - for parsing custom directory and all subdirectories
Copy OE.exe to yourKitchen\tools directory and edit yourKitchen.CMD file so that contains o option for running the program. In zip you can find example for XperiaKitchen.CMD and copy changes from it.
When you extract rom on the main menu you will find shortcut O that creates Option.xml files with /All parameter
You need to have .net framework 3.5 installed on your pc for this to work, although it is needed for whole kitchen to work I think.
Change log:
V 1.1
- bugfix for creating one Option.xml file for main package and it subpackages instead of creating one Option.xml file for every folder
- added custom directory with or without recursive scan
V 1.0
- initial release
- basic file creation through Sys, Oem and packages directories
Great app, haven't tried it out yet, but will the next time I build a rom, can you modify it to take a directory instead of hardcoded to SYS/OEM/Packages and then have an option to either recursively do all sub directories or just the single directory you passed it?
Thanks,
Geoff
Hi,
you app create this option.xml for a example Adobe PDF:
PACKAGE_BlackStone_AdobePDF
Code:
<?xml version="1.0" encoding="UTF-16" standalone="yes" ?>
<Items>
<Item name="PACKAGE_BlackStone_AdobePDF" group="OEM" checked="true">
<Tip>"PACKAGE_BlackStone_AdobePDF"</Tip>
<Guid type="p">459c6490-3483-43e2-a3b0-47c3a8e51657</Guid>
</Item>
</Items>
PACKAGE_BlackStone_AdobePDF_0409
Code:
<?xml version="1.0" encoding="UTF-16" standalone="yes" ?>
<Items>
<Item name="PACKAGE_BlackStone_AdobePDF_0409" group="OEM" checked="true">
<Tip>"PACKAGE_BlackStone_AdobePDF_0409"</Tip>
<Guid type="p">d2a41d55-c07d-4b40-940c-62822da9f23f</Guid>
</Item>
</Items>
this is the correct option.xml for Adobe PDF package:
Code:
<?xml version="1.0" encoding="UTF-16" standalone="yes"?>
<Items>
<Item name="Adobe PDF 2.5.1.0.360303.00" group="Office" checked="true">
<Tip></Tip>
<Guid type="p">459c6490-3483-43e2-a3b0-47c3a8e51657</Guid>
<Guid type="i">20280efc-ad2f-495e-9562-af84c9b0c24f</Guid>
</Item>
</Items>
the differences:
two dsm numbers in one option.xml
first dsm number for PACKAGE_BlackStone_AdobePDF
second for PACKAGE_BlackStone_AdobePDF_0409
Two folder, one package and one option.xml in first folder.
There are packages with three or four folders,
then contains the Option.xml three or four dsm numbers.
example:
Entertainment Package (SYS folder) folder list:
Entertainment
Entertainment_DPI_192
Entertainment_Lang_0409
Entertainment_Lang_0409_DPI_192
Option.xml for Entertainment Package:
Code:
<?xml version="1.0" encoding="UTF-16" standalone="yes"?>
<Items>
<Item name="Solitare and Bubble Breaker" group="Games" checked="true">
<Tip></Tip>
<Guid type="p">0cfc3dc0-5fbc-4153-9ce9-72df4d8c2922</Guid>
<Guid type="i">1f037daf-1ebb-49ff-b6b8-9e3bda1bcbb7</Guid>
<Guid type="i">65e649ac-6009-434b-965b-f1a90bee5d5f</Guid>
<Guid type="i">a8fa2e24-3062-41f9-8d78-321382db9528</Guid>
</Item>
</Items>
wfg
starbase64
ok, that's something that I didn't know and I will fix that during the day
tnx starbase64 for explanation
gzub said:
Great app, haven't tried it out yet, but will the next time I build a rom, can you modify it to take a directory instead of hardcoded to SYS/OEM/Packages and then have an option to either recursively do all sub directories or just the single directory you passed it?
Thanks,
Geoff
Click to expand...
Click to collapse
good idea
I will implement that too in next version
kulla said:
good idea
I will implement that too in next version
Click to expand...
Click to collapse
so new version is up, please test and give me some feedback
Love it
Looks great for a newb chef like me, I'll run it tonight
Hi,
now it works.
wfg
starbase64
joshkoss said:
Looks great for a newb chef like me, I'll run it tonight
Click to expand...
Click to collapse
I'm newbie too in this so I'm trying to simplify everything as much as I can
@starbase64 I'm glad it works for you
Hi,
Found a bug. When the oc.exe is placed in outter folder (e.g. ..\tools\oc.exe /all) or current folder (e.g. oc.exe /all) it won't work.
ahlok_hk said:
Hi,
Found a bug. When the oc.exe is placed in outter folder (e.g. ..\tools\oc.exe /all) or current folder (e.g. oc.exe /all) it won't work.
Click to expand...
Click to collapse
well it's not a bug acctualy because it is ment to be placed in tools folder, for parsing folders with oc.exe outside tools directory use /C dir_where_your_files are and optionaly /R if there are subdirectories in it and you want to parse them too
Version: 15/06/2009
Intro
Welcome; I wanted to offer a little "something" back to the XDA community in the hopes that will benefit others and to show my appreciation to the folks that make XDA the great community that it is. Hopefully, this guide will help you work your way up the ranks to Chef … let’s begin!
So here you are; in the heat of the kitchen, adding your favourite ROM ingredients ... pinch of this, sprinkle of that. Like all good chefs, you decide to take a taste of your preparation before serving to others – so you try it ... wait! you say, something is not right; you're positive you added the ingredients but it's not right. You carefully review all of the portions; seem right; so you decide to look at the ingredients and you realize … you need to change suppliers.
This guide is intended to help you learn how to port the Execute-In-Place (XIP) region from a new (donor) device for use in your kitchen; it will walk you through the process of extracting the contents of an Official ROM, obtaining the new (donor) device XIP, and porting the new (donor) device XIP into your kitchen.
Obtaining Execute-In-Place (XIP) Files
The Execute-In-Place (XIP) region is an area where an application can execute code directly from ROM rather than loading it from RAM. It is possible to use the xip.bin contents from a newer version of a ROM from a different device or a newer operating system. This is typically done by chefs who are looking for the most recent versions of system files from a specific device or version of an operating system.
The process of porting the Execute-In-Place (XIP) requires that you have a reduced copy of your current os.nb.payload from which the xip.bin will be extracted.
Additionally, the process requires that you obtain the newer xip.bin (extracted from the reduced os.nb.payload) and the corresponding .\SYS folder from the desired device .NBH package. Although it is possible to obtain a pre-extracted xip.bin and corresponding .\SYS folder, it is always preferable to perform the extraction activities yourself when possible – this ensures that you have a complete .\SYS folder, the reduced os.nb.payload file, and the extracted xip.bin to work with.
Outro
The sections are intended to be followed in sequence as the last section should provide you with a final product that can be used in your kitchen – so you may want to read this guide once over before going through the motions … who am I kidding? You’re going to follow along aren’t you?
The guide does not cover the steps required to inject the changes from a new .\SYS folder to your existing kitchen .\SYS folder or the comparison (verification) of the boot.rgu and supporting .RGU files typically found in the new (donor) device.
Now for the disclaimer bit; 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 spot mistakes or inaccuracies in the guide however, please let me know so that I may correct them. Now, read on if you still feel it necessary to change suppliers
Oh, one last thing ... special thanks to the following folks for sharing their knowledge with the rest of us ... thank you!
Aruppenthal
Ameet
Bepe
Calkulin
Cmonex
Da_G
Ervius
Olipro
If I missed someone, it's purely accidental – send me a note and I will add your name to the list.
[TUT] Sous-Chef's Guide to Aruppenthal's XIP Porting Kitchen 5.3 ... continued
Preparing Your Facility
Before you can begin to port an Execute-In-Place (XIP) region, you need to equip your facility with some Kitchen utensils. Your Kitchen is going to require a good Unicode & UTF-8 text editor; I personally use ConTEXT & Notepad. Another handy utensil to have is a hexadecimal file/binary editor; I use XVI32. Some other utensils that you're going to require are: cmonex AutoPatcher and om-by Page Pool Changer/Resizer. You will also need an archive extraction utensil; I use IZArc, WinRAR, and WinZIP. You’ll also need a good Hexadecimal calculator; I use Windows Calculator (Scientific Mode).
It's also a good idea to ensure that your Kitchen remains "pest" free; common pest control services include AVG, McAfee, and Symantec anti-Virus. You may need to temporarily disable your Anti-Virus Rootkit scanner while performing binary editing and porting activities.
To assist you in your apprenticeship, I have included a link to Aruppenthal’s XIP Porting Kitchen that I used to prepare this guide – the kitchen also includes a .DOC and .PDF format of this guide. The procedures were tested against a GSM Raphael device. I can’t confirm that these procedures will work on CDMA device ROM’s. Additionally, some device XIP’s may not be compatible with the Raphael device.
XIP Porting Kitchen, 7 MB (mirror)
For the purpose of this guide, I will assume that you have added the C:\XDA\ folder, sub-folder, and files to your anti-virus exclusion list. You will additionally require the Generic Simple Kitchen from the Sous-Chef's Guide to Da_G's Simple ROM Kitchen tutorial (http://forum.xda-developers.com/showthread.php?t=490787) and the XIP Porting Kitchen used in this guide – extracted to the following folder.
C:\XDA\MY_XIP_KITCHEN
The guide is divided into the following sections:
Extracting the RUU_SIGNED.NBH Contents .............. 3
Reducing the .PAYLOAD File .......................... 4
Extracting the Donor XIP.BIN Contents ............... 5
Extracting the Base XIP.BIN Contents ................ 6
Extracting the Donor MSXIPKernel .................... 7
Validating the XIP_OUT.BIN File ..................... 8
Table 1.1: Good ............................... 9
Table 1.2: Fail ............................... 10
Table 1.3: Overlap ............................ 11
Table 1.4: Gap ................................ 12Preparing the New OS.NB.PAYLOAD File ................ 13
Reducing the Update Loader (ULDR) ............. 14
No Update Loader (ULDR) Reduction ............. 15Unlocking and Sizing the Paging Pool ................ 16
Disabling Certificate Checking ...................... 17
I will attempt to provide an overview, the list of tools required, and the process to follow in each section. As you become more comfortable (and familiar) with the activities, you will find that you can consolidate (or skip) certain outlined steps. Incidentally, you'll probably want to keep these web links open in case you need to lookup some of the terms or concepts in the guide.
Acronyms
http://wiki.xda-developers.com/index.php?pagename=Acronyms
Glossary
http://wiki.xda-developers.com/index.php?pagename=Glossary
Development Resources for Windows Mobile
http://forum.xda-developers.com/showthread.php?t=445396
Extracting the RUU_SIGNED.NBH Contents
An .NBH is a signed group of modules or packages; they are typically comprised of .NB files. An .NBH can contain any combination of .NB files. An .NB file is a block of code that can be a Radio ROM, Operating System packages (XIP and IMGFS), Startup Splash Screen (or SPL).
Upon completion of the extraction process, we will be working with is the OS.NB file; it contains the ULDR, XIP, and IMGFS (OEM, SYS). To extract the contents of an .NBH file, copy the .NBH file to the .\BaseROM folder of a new (clean, unused) kitchen.
You will need to extract the Generic Simple Kitchen to two different folders; one folder for the .NBH file currently in use in your current (base) kitchen, and one folder for the new (donor) device .NBH file.
C:\XDA\BASE_NBH_KITCHEN
C:\XDA\DONOR_NBH_KITCHEN
Procedure
The following procedure initiates the ROM Extraction (NBH, IMGFS, and XIP) activity via a script that is included in the Generic Simple Kitchen. You will need to repeat this procedure for each .NBH file. The extraction process can take a significant amount of time to complete.
Copy the RUU_SIGNED.NBH file to the .\BaseROM\ folder.
Navigate to the folder.
Launch RaphaelKitchen.cmd.
Select E, press ENTER.
Select A, press ENTER.
At the Done! message, allow the process to resume – do not close command prompt!
At the Now Start Cooking Your ROM! Press Any Key To Continue message, press ENTER.
Select X, press ENTER.
References
Tutorial: Sous-Chef's Guide to Da_G's Simple ROM Kitchen 5.3
http://forum.xda-developers.com/showthread.php?t=490787
Reducing the .PAYLOAD File
At this point, we need to remove the contents of the IMGFS (OEM, SYS) from the .PAYLOAD file in preparation for our changes to the ULDR and XIP. Removing the IMGFS (OEM, SYS) contents from the .PAYLOAD file will reduce the size of the .PAYLOAD file making it easier to work with.
To reduce the .PAYLOAD file, we essentially need to cook a new version of the .PAYLOAD file with an empty IMGFS partition – one which only contains the .VM and .ROM folder contents. For the purposes of this guide, we will use the Ervius Payload Reducer script to perform this process.
You will need to reduce the os.nb.payload for each extracted .NBH file; once for the .NBH contents currently in use in your (base) kitchen, and once for the new (donor) device .NBH file.
Procedure
The following procedure initiates the .PAYLOAD file reduction activity via a script that is included in the Generic Simple Kitchen. The reduced os.nb.payload file will be required when we update the xip.bin file.
Copy the os.nb.payload file from the kitchen .\Temp\ folder to the kitchen .\Tools\ReducePayload\ folder.
Navigate to the .\Tools\ReducePayload\ folder.
Launch reduce_payload.bat.
At the OS.NB.PAYLOAD Successfully Reduced. Press Any Key To Continue ... message, press ENTER.
References
Tutorial: Sous-Chef's Guide to Da_G's Simple ROM Kitchen 5.3
http://forum.xda-developers.com/showthread.php?t=490787
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Extracting the Donor XIP.BIN Contents
Now that we have two reduced os.nb.payload files; one for the current (base) kitchen and one for the new (donor) device, we must now extract the xip.bin from the reduced os.nb.payload file of the new (donor) device.
We don’t need to extract the xip.bin from the current (base) kitchen os.nb.payload file at this time.
Tools Required
The following tools are required for the xip.bin file extraction activities.
XIPPorterEx
Procedure
The following procedure will extract the contents of the xip.bin from the os.nb.payload file.
Copy the os.nb.payload file from the C:\XDA\DONOR_NBH_Kitchen\Tools\ReducePayload\ folder to the C:\XDA\DONOR_NBH_Kitchen\Tools\XIPPorterEx\MyTools\os_nb.payload\ folder.
Navigate to the C:\XDA\DONOR_NBH_Kitchen\Tools\XIPPorterEx\ folder.
Launch XIPPORTEREX.EXE.
Click the (Extract From .Payload) button.
At the XIP.BIN Successful Extraction From OS.NB.PAYLOAD message, click OK.
At the XIP.BIN Successful Written Into: "\xip.bin_old" Folder message, click OK.
Exit XIPPORTEREX.EXE.
Copy the extracted xip.bin file from the C:\XDA\DONOR_NBH_Kitchen\Tools\XIPPorterEx\MyTools\xip.bin_old\ folder to the C:\XDA\My_XIP_kitchen\MyTools\xip.bin_new\ folder.
References
Kernel Overview
http://msdn.microsoft.com/en-us/library/aa909237.aspx
Extracting the Base XIP.BIN Contents
At this point, we have extracted the xip.bin from the new (donor) device os.nb.payload file and copied it to the XIP Porting Kitchen.
We must now extract the xip.bin from the reduced os.nb.payload for the current (base) kitchen.
Tools Required
The following tools are required for the xip.bin file extraction activities.
XIPPorterEx
Procedure
The following procedure will extract the contents of the xip.bin from the current (base) kitchen os.nb.payload file.
Copy the os.nb.payload file from the C:\XDA\BASE_NBH_Kitchen\Tools\ReducePayload\ folder to the C:\XDA\BASE_NBH_Kitchen\Tools\XIPPorterEx\MyTools\os_nb.payload\ folder.
Navigate to the C:\XDA\BASE_NBH_Kitchen\Tools\XIPPorterEx\ folder.
Launch XIPPORTEREX.EXE.
Click the (Extract From .Payload) button.
At the XIP.BIN Successful Extraction From OS.NB.PAYLOAD message, click OK.
At the XIP.BIN Successful Written Into: "\xip.bin_old" Folder message, click OK.
Exit XIPPORTEREX.EXE.
Copy the extracted xip.bin file from the C:\XDA\DONOR_NBH_Kitchen\Tools\XIPPorterEx\MyTools\xip.bin_old\ folder to the C:\XDA\My_XIP_kitchen\MyTools\xip.bin_new\ folder.
References
Kernel Overview
http://msdn.microsoft.com/en-us/library/aa909237.aspx
Extracting the Donor MSXIPKernel
The Execute-In-Place (XIP) region is comprised of two significant regions – the MSXIPKernel, and the OEMXIPKernel. The OEMXIPKernel typically contains system drivers that are specific to your device. On very rare occasions, these drivers can be changed for newer ones.
The MSXIPKernel however, usually contains drivers that are specific to the version of Windows Mobile that you are using – in our case, Windows Mobile 6.1. There are many different methods for porting the MSXIPKernel drivers; each method may yield different build numbers. For example, some chefs use the 723*.DSM for the build number, others use the COREDLL.DLL module to obtain the latest build numbers.
For the purpose of this guide however, we will leave the OEMXIPKernel drivers as-is and use a simpler method of porting the MSXIPKernel drivers from a new (donor) device for use in your kitchen – and not concern ourselves with the build number.
Once the MSXIPKernel is extracted from the new (donor) device xip.bin, the OEMXIPKernel will be extracted from the current (base) kitchen. Both contents will be merged into a new xip.bin file. Additionally, the certificate store verification will have been disabled.
Tools Required
The following tools are required for the new (donor) device MSXIPKernel extraction activities.
XIPPorterEx
Procedure
The following procedure will extract the contents of the MSXIPKernel from the xip.bin of the new (donor) device, the OEMXIPKernel from the current (base) kitchen, and merge them into a new xip_out.bin file.
Navigate to the C:\XDA\My_XIP_Kitchen\ folder.
Launch XIPPORTEREX.EXE.
Clear the following check boxes:
Execute PP Patcher
Delete CACHEFILT.DLL
Delete MENCFILT.DLL
Delete ENCFILT.DLL
Change PP To MB
Don't Copy Xip Dsm
DEBUG Save Temp .BIN Files
Select the following check boxes:
Execute Cert Patcher
Port Only MSXipkernel
Create OEM Package From Unused Xip Modules/Files
Click the PORT IT! button.
At the Cert Patcher: Successfully Nocert Patched! message, click OK.
At the ALL DONE! Now Write New XIP.BIN Into Payload message, click OK.
Exit XIPPORTEREX.EXE.
References
Kernel Overview
http://msdn.microsoft.com/en-us/library/aa909237.aspx
Validating the XIP_OUT.BIN File
At this stage, we have a new xip.bin – currently named xip_out.bin. To ensure that the porting process occurred correctly, we will perform a quick validation of the xip_out.bin file.
If all is well, we will proceed to inject this new xip_out.bin file into our current (base) kitchen os.nb.payload file. In cases where the validation reveals problems, you will need to perform advanced XIP porting procedures – which are beyond the scope of this guide.
Tools Required
The following tools are required for the xip_out.bin validation activities.
XIPPort
Text Editor
Procedure
The following procedure will extract the contents of the newly formed xip_out.bin for validation purposes.
Copy the xip_out.bin file from the C:\XDA\My_XIP_kitchen\MyTools\XIP_new_ported\ folder to the C:\XDA\My_XIP_kitchen\MyTools\ folder.
Rename C:\XDA\My_XIP_kitchen\MyTools\xip_out.bin to C:\XDA\My_XIP_kitchen\MyTools\xip.bin.
Navigate to the C:\XDA\My_XIP_Kitchen\MyTools\ folder.
Launch XIPPORT.EXE.
Click the Dump XIP.BIN button.
Click the Write Maps button.
Exit XIPPORT.EXE.
Launch a text editor.
Select File, Open.
Navigate to the C:\XDA\My_XIP_Kitchen\MyTools\OUT\ folder.
Select the MAP.TXT file.
Compare the beginning (top) portion of the file to against the following tables.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Table 1.1: Validating the XIP_OUT.BIN File
The example below is of a favourable output, no overlaps or gaps.
Code:
00000000 - 01f801fc L01f801fc NUL
01f801fc - 01f801fc L00000000 Start: first DLL address
01f801fc - 01fc8000 L00047e04 NUL
01fc8000 - 01fca000 L00002000 initialized data of region_1 wce_rex.DLL
01fca000 - 01fcb000 L00001000 initialized data of region_1 smem.dll
01fcb000 - 01fcc000 L00001000 initialized data of region_1 MMMAP.dll
01fcc000 - 01fcd000 L00001000 initialized data of region_1 GxDMA.dll
01fcd000 - 01fd4000 L00007000 initialized data of region_1 FLASHDRV.DLL
01fd4000 - 01fd5000 L00001000 initialized data of region_3 FLASHDRV.DLL
01fd5000 - 01fed000 L00018000 initialized data of region_2 DDI.dll
01fed000 - 01fee000 L00001000 initialized data of region_1 ceddk.dll
01fee000 - 01fef000 L00001000 initialized data of region_1 cecompr.dll
01fef000 - 01ff0000 L00001000 initialized data of region_1 regenum.dll
01ff0000 - 01ff1000 L00001000 initialized data of region_1 pm.dll
01ff1000 - 01ff2000 L00001000 initialized data of region_1 mspart.dll
01ff2000 - 01ff3000 L00001000 initialized data of region_1 mencfilt.dll
01ff3000 - 01ff4000 L00001000 initialized data of region_1 imgfs.dll
01ff4000 - 01ff5000 L00001000 initialized data of region_1 fsreplxfilt.dll
01ff5000 - 01ff6000 L00001000 initialized data of region_1 fsdmgr.dll
01ff6000 - 01ff7000 L00001000 initialized data of region_1 fatutil.dll
01ff7000 - 01ff8000 L00001000 initialized data of region_1 fatfsd.dll
01ff8000 - 01ff9000 L00001000 initialized data of region_1 diskcache.dll
01ff9000 - 01ffa000 L00001000 initialized data of region_1 devmgr.dll
01ffa000 - 01ffc000 L00002000 initialized data of region_1 crypt32.dll
01ffc000 - 01ffd000 L00001000 initialized data of region_1 coredll.dll
01ffd000 - 01ffe000 L00001000 initialized data of region_1 certmod.dll
01ffe000 - 01fff000 L00001000 initialized data of region_1 cachefilt.dll
01fff000 - 02000000 L00001000 initialized data of region_1 busenum.dll
02000000 - 02000000 L00000000 End: last DLL address
[B]...[/B]
Table 1.2: Validating the XIP_OUT.BIN File
The example below indicates possible problems with the imageinfo.bin or imageinfo.txt files found in the C:\XDA\My_XIP_Kitchen\MyTools\SYS\.VM\ and/or C:\XDA\My_XIP_Kitchen\MyTools\SYS\.ROM\ folders of the XIP Porting Kitchen.
Code:
00000000 - 01f801fc L01f801fc NUL
01f801fc - 01f801fc L00000000 Start: first DLL address
01f801fc - 01fc8000 L00047e04 NUL
02000000 - 02000000 L00000000 End: last DLL address
[B]...[/B]
The following procedure may resolve the issue.
Remove the following files
C:\XDA\My_XIP_Kitchen\MyTools\xip.bin
C:\XDA\My_XIP_Kitchen\MyTools\XIP_new_ported\xip_out.bin
Remove the contents in the following folders – do not remove the folder:
C:\XDA\My_XIP_Kitchen\MyTools\OEMXIP_Package\*.*
C:\XDA\My_XIP_Kitchen\MyTools\Dump\*.*
C:\XDA\My_XIP_Kitchen\MyTools\OUT\*.*
C:\XDA\My_XIP_Kitchen\MyTools\SYS\Dump\*.*
Copy the contents of C:\XDA\My_XIP_Kitchen\Templates\SYS\ folder (sub-folder and files) to the C:\XDA\My_XIP_Kitchen\MyTools\ folder.
Repeat the donor MSXIPKernel extraction and validation procedures.
If the problem presists, you will need to perform advanced XIP porting procedures – which are beyond the scope of this guide.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Table 1.3: Validating the XIP_OUT.BIN File
The example below indicates an overlap problem; you will need to perform advanced XIP porting procedures – which are beyond the scope of this guide.
Code:
00000000 - 01f801fc L01f801fc NUL
01f801fc - 01f801fc L00000000 Start: first DLL address
01f801fc - 01fc8000 L00047e04 NUL
01fc8000 - 01fca000 L00002000 initialized data of region_1 wce_rex.DLL
01fca000 - 01fcb000 L00001000 initialized data of region_1 smem.dll
01fcb000 - 01fcc000 L00001000 initialized data of region_1 MMMAP.dll
[B]...[/B]
02000000 - 02000000 L00000000 End: last DLL address
02000000 - 03dbe000 L01dbe000 NUL
03dbe000 - 03dc7000 L00009000 Virtual base address of wce_rex.DLL
[COLOR="Blue"]03dc7000 - 03dce000 L00007000 Virtual base address of smem.dll[/COLOR]
[COLOR="Red"]03dc7000 - 03dce000 L00001000 !!!!!!!!!!!!!!!!!![/COLOR]
03dce000 - 03dd3000 L00005000 Virtual base address of MMMAP.dll
[B]...[/B]
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Table 1.4: Validating the XIP_OUT.BIN File
The example below indicates a gap problem; you will need to perform advanced XIP porting procedures – which are beyond the scope of this guide.
Code:
00000000 - 01f801fc L01f801fc NUL
01f801fc - 01f801fc L00000000 Start: first DLL address
01f801fc - 01fc8000 L00047e04 NUL
01fc8000 - 01fca000 L00002000 initialized data of region_1 wce_rex.DLL
01fca000 - 01fcb000 L00001000 initialized data of region_1 smem.dll
01fcb000 - 01fcc000 L00001000 initialized data of region_1 MMMAP.dll
[B]...[/B]
02000000 - 02000000 L00000000 End: last DLL address
02000000 - 03dbe000 L01dbe000 NUL
03dbe000 - 03dc7000 L00009000 Virtual base address of wce_rex.DLL
03dc7000 - [U][COLOR="Blue"]03dce000[/COLOR][/U] L00007000 Virtual base address of smem.dll
[U][COLOR="blue"]03dcf000[/COLOR][/U] - 03dd3100 L00005000 Virtual base address of MMMAP.dll
[B]...[/B]
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Preparing the New OS.NB.PAYLOAD File
As we have already disabled Certificate checking, we will not select Execute Cert Patcher; additionally, we will not apply the Execute PP Patcher and Change PP To MB options. As the Execute-In-Place (XIP) region for the Raphael is sufficient in size, we do not need to remove the cachefilt.dll, mencfilt.dll, and encfilt.dll drivers.
Tools Required
The following tools are required to perform the os.nb.payload file update activities.
XIPPorterEx
Procedure
The following procedure will create a new os.nb.payload file which will be used when cooking our ROM.
Navigate to the C:\XDA\MY_XIP_KITCHEN\ folder.
Launch XIPPORTEREX.EXE.
Clear the following check boxes:
Execute Cert Patcher
Execute PP Patcher
Port Only MSXipkernel
Delete CACHEFILT.DLL
Delete MENCFILT.DLL
Delete ENCFILT.DLL
Change PP To MB
Create OEM Package From Unused Xip Modules/Files
Don't Copy Xip Dsm
DEBUG Save Temp .BIN Files
Click the Find Start XIP Offset button; the offset value should indicate: 00320000.
At this stage, the os.nb.payload file has not been reduced; you can select one of the following procedures:
Reducing the Update Loader (ULDR) Partition and Updating the OS.NB.PAYLOAD File.
Updating the OS.NB.PAYLOAD File with No Update Loader (ULDR) Reduction.
Reducing the Update Loader (ULDR) Partition and Updating the OS.NB.PAYLOAD File
The boot loader can accommodate multiple execute-in-place (XIP) regions where individual modules can be updated after the initial operating system image file has been written to the device – the ULDR is an example of this use. The Update Loader (ULDR) provides Flash-Over-The-Air (FOTA) capabilities permitting your carrier to issue changes such as Hotfixes over the cellular network – generally, most carriers avoid this practice.
We will use the ROM Tools feature of the XIPPorterEx tool to adjust the ULDR and remove the debugging system library files. We will commit our changes which will replace the current (base) kitchen xip.bin contents with the new xip_out.bin contents resulting in a final os.nb.payload file – which we will use when cooking our kitchen.
Procedure
Click the ROM Tools button.
Clear the following check boxes:
Conservative Mode
Write NEW Xip Size Into MBR
Select the DEBUG Delete Temp .BIN Files check box.
Click the Give From Your XIP_OUT.BIN button.
Click the Write button.
At the os.nb.payload Was Successfully Reduced... message, click OK.
Click the Done button.
Move the os.nb.payload from C:\XDA\MY_XIP_KITCHEN\XIPPorterEx\MyTools\os.nb.payload_Reduced\ folder to the C:\XDA\MY_XIP_KITCHEN\XIPPorterEx\MyTools\os_nb.payload\ folder –overwriting the older version of the file.
Click the Find Start XIP Offset button; the offset value should indicate: 00020000.
Click the Write It button.
At the NEW os.nb.payload Was Updated Successfully... message, click OK.
Click the ROM Tools button.
Clear the following check boxes:
Conservative Mode
Write NEW Xip Size Into MBR
Select the DEBUG Delete Temp .BIN Files check box.
Click the Write button.
At the os.nb.payload Was Successfully Reduced... message, click OK.
Click the Done button.
Exit XIPPORTEREX.EXE.
Copy the os.nb.payload file from the C:\XDA\MY_XIP_KITCHEN\MyTools\ os.nb.payload_Reduced\ folder to your kitchen .\ROM\ folder.
Note
New (donor) devices are being released with updated resource strings in the NK.EXE module. As a result, you must not attempt to change the Date and/or ROM Version – doing so will corrupt your xip.bin file.
Updating the OS.NB.PAYLOAD File with No Update Loader (ULDR) Reduction
We will commit our changes which will replace the current (base) kitchen xip.bin contents with the new xip_out,bin contents resulting in a final os.nb.payload file – which we will use when cooking our kitchen.
Procedure
Click the Write button.
At the os.nb.payload Was Successfully Reduced... message, click OK.
Click the Done button.
Exit XIPPORTEREX.EXE.
Copy the os.nb.payload file from the C:\XDA\MY_XIP_KITCHEN\MyTools\os.nb.payload\ folder to your kitchen .\ROM\ folder.
Note
New (donor) devices are being released with updated resource strings in the NK.EXE module. As a result, you must not attempt to change the Date and/or ROM Version – doing so will corrupt your xip.bin file.
Unlocking and Resizing the Paging Pool
The Paging Pool serves as a limit on the amount of memory that can be consumed by pageable data. It includes an algorithm for choosing the order in which to remove pageable data from memory. Pool behaviour is typically determined by the OEM – Microsoft sets a default value for the paging pool, but the OEM can change that value. Applications do not have the ability to set the behaviour for their own executables or memory-mapped files.
For the purposes of this guide, we are going to apply a change to the os.nb.payload file which will permit us to change the Paging Pool size (initially set to 6MB) to other sizes using the PagePool Changer tool.
Tools Required
The following tools are required for the Paging Pool unlock activities.
Hexadecimal Editor
Procedure
The following procedure will change the os.nb.payload file to permit adjustments to the Paging Pool size via the PagePool Changer tool.
Navigate to the C:\XDA\MY_XIP_KITCHEN\Editors\xvi32\ folder.
Launch XVI32.EXE.
Select File, Open.
Navigate to your kitchen .\ROM\ folder.
Select All File (*.*) from the Files Of Type list.
Select the os.nb.payload file.
Select Search, Find.
In the Hex String box, type:
03 15 A0 03 02 15 A0 13
Click OK.
Change the following 4 bytes after the 03 15 A0 03 02 15 A0 13 string;
FROM: 00 10 82 E5
TO: 00 00 A0 E1
Select File, Save.
Select File, Exit.
Tip
Make a backup copy of the os.nb.payload file before editing; delete the backup file when done.
References
Paging Pool
http://msdn.microsoft.com/en-us/library/aa915364.aspx
Paging and the Windows CE Paging Pool
http://blogs.msdn.com/ce_base/archive/2008/01/19/Paging-and-the-Windows-CE-Paging-Pool.aspx
Change PagePool Through Hex Editing (For Diamond & Raphael)
http://forum.xda-developers.com/showpost.php?p=2903704&postcount=5
Disabling Certificate Checking
During the startup process of your device, the operating system verifies that each system file against an internal certificate store to ensure that each file is signed with a trusted certificate; if the system file is not signed, the file is ignored.
To allow execution of non-signed system files, we need to disable the internal certificate store verification. Once disabled, the operating system will trust all code installed regardless of its signature. This provides more control over the code that gets installed on the device – you no longer need to load and manually sign additional certificates such as those from the sdkcerts.cab into the device root certificate store.
If you accidentally forgot to disable the certificate store verification during the XIP porting process, you can use the following procedure to apply a change to the os.nb.payload file.
Tools Required
The following tools are required to disable the internal certificate store verification.
AutoPatcher01
Procedure
The following procedure will disable the internal certificate store verification.
Navigate to the C:\XDA\MY_XIP_KITCHEN\Editors\AutoPatcher\ folder.
Launch AUTOPATCHER01.EXE.
Click the Cert Patch button.
Select All File (*.*) from the Files Of Type list.
Navigate to your kitchen .\ROM\ folder.
Select the os.nb.payload binary file.
At the Successfully Patched... message, click OK.
Exit AUTOPATCHER01.EXE.
Tip
Make a backup copy of the os.nb.payload file before editing; delete the backup file when done.
References
[RES] RILPHONE.DLL And "How To" With A Radio
http://forum.xda-developers.com/showthread.php?t=481026
13/02/2010: Tutorial Statistics
Views: 1,390
Guide Downloads: 45
Kitchen Downloads: 72
Well, great article! No offence, but why do you need 19 reserved posts? Even largest projects have less than half of that
My Disclaimer
I take no credit for the kitchen. I just edited and recompiled several tools provided by many users.
Calkulin at PPCgeeks laid the base idea for the XIP kitchen. Ervius Bepe and several others did the real work creating the tools. I consider my role very minute at best. Hilaireg took the time to write everything down. I think everyone should be appreciative of the extreme amount of time put into this.
Alot of the information was built upon all of Ameets hard work as well as the many contributors to the Manual xip porting thread made much of this possible.
I urge everyone that intends to cook to take the time to learn how to port a xip. There is much to be gained by knowing how things work behind all the fancy tools we have these days.