HOWTO: Get callstack for the threads in system calls - utilites - Windows Mobile Development and Hacking General

Hi!
There is utils for dump all threads call stack in application and for analyse it.
Dghsdb.exe – dump ulit. Use executable file name (name.exe) for command line parameter.
DumpParser.exe – run this util on desctop. Before it copy this util to directory with your winmobile app.
3 parameters:
1. Executable file name (name.exe or “name_part1 name_part2.exe”)
2. Dump file full path
3. Pdb file path (without file name).
DumpParser.exe name.exe c:\dump_file.txt D:\MyProject\Debug
See console for result

Related

Build Cab File of an app

Hey Guys!
How can i Build a cab for my programs in vs2005 or have i to use another tool to do this?
thanks SciLor
WinCe cab manager does the job.
its not free though.
but its worth it
isnt there another tool i can use?
look in the Visual studio's help file on making an installer..i cant remember now but i did create a cab once..btw which version of VS do u use
This is from My VS 2008 Pro Documentation
This section describes creating CAB files for distributing ATL and MFC controls over the Internet. If you need more information about CAB files, see the Cabinet File Reference in the Windows SDK documentation (in MSDN Library/Setup and System Administration/Setup/Setup API/Overview/Cabinet Files).
To create a CAB file:
Create an INF file.
Run the CABARC utility.
Creating an INF File
The INF file is a text file that specifies the files (such as DLLs or other OCXs) that need to be present or downloaded for your control to run. An INF file allows you to bundle all the needed files in one compressed CAB file. By default, files with the same version numbers as existing files on the user's hard disk will not be downloaded. For more information about INF files and their options, including how to create platform-independent INF files, see About INF Files and Using INF Files in the Windows SDK documentation (in MSDN Library/Setup and System Administration/Setup/Setup API/Overview/Setup Applications).
As an example, the following INF will be used to create a CAB file for the ATL Polygon control. You can build POLYGON.DLL by downloading the ATL POLYGON sample files from the Visual C++ CD and building a MinSize version. If you build a MinSize version of the Polygon control, you need one additional DLL, ATL.DLL. Since ATL.DLL needs to be registered before POLYGON.DLL, put the ATL.DLL first in the INF file:
Copy Code
; Sample INF file for POLYGON.DLL
[version]
; version signature (same for both NT and Win95) do not remove
signature="$CHICAGO$"
AdvancedINF=2.0
[Add.Code]
polygon.dll=polygon.dll
atl.dll=atl.dll
; needed DLL
[atl.dll]
file-win32-x86=thiscab
FileVersion=2,00,0,7024
DestDir=11
RegisterServer=yes
[polygon.dll]
file-win32-x86=thiscab
clsid={4CBBC676-507F-11D0-B98B-000000000000}
FileVersion=1,0,0,1
RegisterServer=yes
; end of INF file
This INF specifies that ATL.DLL with the given version needs to be installed on the system. If ATL.DLL doesn't exist already on the system, it will be downloaded from the CAB file created with this INF. "thiscab" is a keyword meaning the CAB containing this INF. You can also download a needed DLL from an HTTP location by specifying an absolute or relative path, for example:
Copy Code
file-win32-x86=http://example.microsoft.com/mydir/NEEDED.DLL
The keyword "file-win32-x86" identifies the platform as x86 specific.
You can get the version number of a file by clicking the right mouse button on the file in Windows Explorer. Select Properties from the list that appears, then select the Version tab on the dialog box that appears. You will sometimes need to insert an extra 0 in the file version. For example, the version number for the ATL.DLL is shown as 2.00.7024 in the dialog box. This becomes 2, 00, 0, 7024 in the INF file.
The "DestDir" is where the directory where the file will be loaded: 11 specifies the system directory WINDOWS/SYSTEM or WINNT/SYSTEM32; 10 specifies the windows directory, WINDOWS or WINNT. If no DestDir is specified (typical case), code is installed in the fixed OCCACHE directory.
The "clsid" is the CLSID of the control to be installed.
Once you have created an INF file, run the CABARC utility (available in the Mssdk\Bin directory) to create the CAB file. You should run CABARC in the directory that contains your source files. On the command line, put the source files in the order they appear in the INF and the INF file last. For example, to make a CAB file for the Polygon control from the INF above, use the following command:
Copy Code
C:\MSSDK\BIN\CABARC -s 6144 POLYGON.CAB ATL.DLL POLYGON.DLL POLYGON.INF
The POLYGON.CAB file contains a compressed version of ATL.DLL and POLYGON.DLL along with the information needed to extract them in the POLYGON.INF file.
For an example of how to parse and extract component files from CAB files, see the CabView sample in the MSDN Online Code Center at http://msdn.microsoft.com/visualc/downloads/samples.asp (select the CabView link).
The DLL files you need to include with an MFC control are MSVCRT.DLL, MFC42.DLL, and OLEPRO32.DLL.
Running the CABARC Utility
The CABARC utility is available in the Mssdk\Bin directory. For example:
Copy Code
C:\MSSDK\BIN\CABARC -s 6144 n MYCTL.CAB NEEDED1.DLL NEEDED2.DLL MYCTL.OCX MYCTL.INF
CABARC creates a CAB file called MYCTL.CAB.
You should run CABARC in the directory that contains your source files (the INF, OCX, and DLL files). The files to be archived in the CAB file should be listed on the command line in the same order they are listed in the INF file. In the example above, the INF file should list NEEDED1.DLL first, then NEEDED2.DLL, and then MYCTL.OCX.
The -s option reserves space in the cabinet for code signing. The n command specifies that you want to create a CAB file. For a list of CABARC commands and options, type CABARC alone on the command line:
Copy Code
C:\MSSDK\BIN\CABARC
Click to expand...
Click to collapse
I found an older version of this online:
http://www.aperitto.com/content/view/14/159/
I have version 2.0 and it works great without registering the copy. Look into it
I can't find the original setup I used... sorry, I will keep looking... but I've heard good things about SPB's installatation creator
http://www.spbsoftwarehouse.com/products/ezsetup/index.html?en
It is easy with VS 2008 there you can create a CAB Builder

MSCEInf version 2.1 (Update)

MSCEINf update is only for those who want to use the program in Command Mode for making batch tasks.
Contributions of version 2.1
· MSCEInf Version 2.1 adds ability to extract in command mode CAB files in a folder preserving subfolders names.
Syntax is a bit rigid with a keyword extract (separed by a space) after CAB name. This keyword allows creation of INF file and files extraction (with correct names) while preserving subfolders names.
A second parameter optional is folder name where to extract files. If omitted, folder name will be :
"c:\ExtractDir".
Program creates the folder if it does not exist.
For example write like here (do not forget to separe each parameters by a space and put path in double quotes) :
msceinf "C:\Users\Benoit\Documents\a.cab" extract​and files are extracted in folder "c:\ExtractDir".
or give folder name where to extract :
msceinf "C:\Users\Benoit\Documents\a.cab" extract "C:\Users\Benoit\Documents\My extracted files"​and files are extracted in folder "C:\Users\Benoit\Documents\My extracted files".
Link to the 6 localized versions (include english) : http://www.codeppc.com/telechargements/msceinf/msceinf.htm
.
WOW...great work benthon..it will become handy in making OEMS while cooking

[TUT] Sous-Chef's Guide to Da_G's Simple ROM Kitchen 5.3

Version: 26/04/2009
Intro
Welcome; I wanted to offer a little "something" back to the XDA community in the hopes that it 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!
There are many chefs that provide quality ROM's for you to use. However, if you've gotten excited about the idea of cooking your own ROM's, you've probably felt overwhelmed by the volume of Forum Threads and Wiki pages at your disposal to learn how to do this.
The sections are intended to be followed in sequence as the last section should provide you with a final product that can be flashed to your device – 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?
In case you're wondering ... I chose Sous-Chef because Commis or Chef De Partie just didn't have the same appeal
Applying Original/Cooked ROM's
You probably won't be able to apply an Original or Cooked ROM to your device as your Cellular Carrier has most certainly locked your device. You'll need to unlock your device before venturing into the world of ROM installation. These activities are beyond the scope of this guide; you can however, go to this Wiki page to learn more.
HTC Raphael
http://wiki.xda-developers.com/index.php?pagename=HTC_Raphael
Original VS Cooked ROM's
HTC periodically releases Official Generic ROM's that you can apply to your device. You can find a list of Original Shipped WM6.1 ROM's at this Wiki page.
Original Shipped WM6.1 ROMS
http://wiki.xda-developers.com/index.php?pagename=HTC_Raphael_WM6.1_ROMs
There are essentially two types of Cooked ROM's; those that another Chef makes available for you to use, and those that you cook yourself. You can find a list of Available Cooked WM6.1 ROM's at this Wiki page.
Available Cooked WM6.1 ROMS
http://wiki.xda-developers.com/index.php?pagename=HTC_Raphael_Cooked_WM6.1_ROMs
Outro
Lastly, this guide only covers the ROM cooking process; changing your device Startup Splash Screen and Radio or flashing a HardSPL are beyond the scope of this guide; you can however, go to these Wiki and/or Forum pages to learn more.
Radio
http://wiki.xda-developers.com/index.php?pagename=Raphael_ExtractedRadioRoms
http://forum.xda-developers.com/showthread.php?t=439566
Startup Splash Screen
http://forum.xda-developers.com/showthread.php?t=431161
Hard SPL
http://wiki.xda-developers.com/index.php?pagename=Raphael_HardSPL
This guide is intended to help you learn how to cook your own ROM's; it will walk you through the process of extracting the contents of an Official ROM, adjusting the Page Pool, changing the Data Cache Size, and Patching the ROM to remove Certificate verification. The guide does not cover the steps required to add/remove ROM packages or port an XIP from a different ROM version or device ... not yet anyway
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 that this is your choice career path
Oh, one last thing ... to the following folks for sharing their knowledge with the rest of us ... thank you!
Da_G
Ameet
Bepe
Cmonex
Ervius
JCEspi2005
JugglerLKR
mskip
Olipro
Aruppenthal
NRGZ28
Noonski
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 Da_G's Simple Kitchen 5.3 ... continued
Location, Location, Location
There are many fine Kitchens out there to use; Visual Kitchens (Ervius), Automated Kitchens (Bepe), and Semi-Automated Kitchens (Raphael, Da_G). This guide uses Da_G's Simple Kitchen to assist you in learning the basics of operating a Kitchen; which ultimately, allows you to produce your own ROM.
References
Da_G....: http://forum.xda-developers.com/showthread.php?t=471288
Raphael.: http://forum.xda-developers.com/showthread.php?p=2453788
Bepe....: http://forum.xda-developers.com/showthread.php?t=467488
Ervius..: http://forum.xda-developers.com/showthread.php?t=469420
Preparing Your Facility
Before you can begin to cook your own ROM, 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 comparison utility for date/file/binary comparisons; I use WinDiff & BeyondCompare. Some other utensils that you're going to require are: Microsoft ActiveSync, .NET Framework 2.x/3.x. 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'll need to add the CustomRUU Updater tool to your list of anti-virus exclusions as it will be detected as a "Generic Dropper (Trojan)".
References
CustomRUU for Raphael
http://forum.xda-developers.com/showthread.php?t=410761
To assist you in your apprenticeship, I have included a link to the Generic Simple 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, other device ROM’s may not be compatible with this kitchen format. Make sure to review the _README.TXT before you begin.
Generic Simple Kitchen, 17 MB
You’re going to need a RUU_SIGNED.NBH file; I used the following HTC Official Generic ROM – you’ll need to extract the contents of the .EXE and .RAR/.ZIP using an archive utensil.
[ROM] [WWE] Raphael HTC 5.05.405.1 Radio Signed (52.58.25.3 0,1.11.25.01)
http://rapidshare.com/files/1939660...igned_Raphael_52.58.25.30_1.11.25.01_Ship.rar
http://www.megaupload.com/?d=0F50UM5K
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 – at the very least CustomRUU Updater.EXE – and that the contents of the Generic Simple Kitchen were extracted to the following folder.
C:\XDA\MY_KITCHEN
The guide is divided into the following sections:
Extracting the RUU_SIGNED.NBH Contents ... 3
Consolidating .RGU Files to BOOT.RGU ..... 4
Increasing the Data Cache ................ 5
Reducing the .PAYLOAD File ............... 6
Extracting the XIP.BIN Contents .......... 7
Unlocking the Paging Pool ................ 8
Disabling Certificate Checking ........... 9
Updating the XIP.BIN Contents ............ 10
Updating the .PAYLOAD file ............... 11
Changing the Unsigned CAB Policies ....... 12
Changing the Unsigned Themes Policies .... 13
Changing the Remote API (RAPI) Policies .. 14
Compiling the New RUU_SIGNED.NBH File .... 15
Flashing the RUU_SIGNED.NBH File ......... 16
Advanced Topic: XIP Porting .............. 17
Sous-Chef's TIPs ......................... 18
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
Extracting the 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).
The file 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, we issue the following command.
NBHextract.exe RUU_signed.nbh
Upon completion, the following files will have been extracted: Unknown.nb, 01_SPL.nb, 02_MainSplash.bmp, 02_MainSplash.nb, and 03_OS.NB. For the purposes of this guide, the 03_OS.NB file is the file we will be working with; it will be renamed to OS.NB.
Splitting the OS.NB File
In any ROM, the OS.NB is padded with extra data that is split into packets for the flashing process. This ensures that incorrectly transmitted packets can be re-transmitted to a device without having to resend from the beginning. Packets are usually groups of bytes and vary between devices - a packet will typically contain of data followed by padding.
For the Raphael, the data packets are 800 bytes in size and padded with 8 bytes. For the purposes of this guide, this padded portion is not required and therefore, we strip it from the OS.NB using with the NBSPLIT tool by issuing the following command.
nbsplit -kaiser os.nb
The -kaiser option instructs the NBSPLIT tool to process 0x800 (2048 decimal) hexadecimal bytes of data and that 8 bytes of padding will follow each 800 bytes. Upon completion, the following will have been extracted: os.nb.payload, os.nb.extra. For the purposes of this guide, the os.nb.extra is not required.
At this point, we need to extract the contents of the ULDR, XIP, IMGFS (OEM, SYS) from the .PAYLOAD file as we will be changing the ULDR and XIP. Most of the .PAYLOAD file content is the IMGFS; this is the portion that makes up content of the OEM and SYS folders. Most chefs add/remove OEM packages in these folders during their cooking process - you'll eventually do the same.
Tools Required
The following tools are required for the RUU_SIGNED.NBH extraction activities.
NBHextract
NBSplit
ImgfsFromNb
ImgfsToDump
RomMaster
DumpROM
PKGTool
Procedure
The following procedure initiates the ROM Extraction (NBH, IMGFS, and XIP) activity via a script that is included in the Generic Simple Kitchen. The extraction process can take a significant amount of time to complete.
Copy the RUU_SIGNED.NBH file to the C:\XDA\My_Kitchen\BaseROM\ folder.
Navigate to the C:\XDA\My_Kitchen\Tools\ 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
NBHextract: Extract Contents From NBH Files
http://forum.xda-developers.com/showthread.php?t=289830
[TUT] ROM For Everyone (Video Tutorial To Cook The ROM)
http://forum.xda-developers.com/showthread.php?t=413782
[REF] Cooking Class Class of 2008/09 [ONLINE]
http://forum.xda-developers.com/showthread.php?t=335631
Consolidating .RGU Files to BOOT.RGU
The boot hive contains system settings that are applied only during boot. The boot hive is read out of ROM and used to start drivers and file systems needed to reach the system hive file. Once the system hive is mounted, the boot hive is discarded. Changes made to the registry during the boot process are copied into the system hive once it is available. The boot hive in ROM remains unchanged.
The boot.hv registry hive, which contains the contents of all .RGU files in the XIP, provides the initial basic registry hive that is referenced during the loading of the kernel and any necessary drivers to mount the root file system. Once the file system is mounted the default.hv and user.hv registry hives are mounted and used. Most chefs add/remove/change entries from the BOOT.RGU file during their cooking process – you'll eventually do the same.
For the purposes of this guide, we will consolidate the contents of all .RGU files found in the Dump_XIP folder into the BOOT.RGU file. Consolidating the contents of the .RGU files found in the Dump_XIP folder to the BOOT.RGU file ensures that all necessary registry entries will be added during the ROM compilation activities.
Tools Required
The following tools are required to edit .RGU files.
Unicode Text Editor
Procedure
The following procedure will consolidate all of the .RGU files found in the Dump_XIP folder into the BOOT.RGU file.
Navigate to C:\XDA\MY_KITCHEN\Temp\Dump_XIP\ folder.
Launch a text editor and open the BOOT.RGU file.
Launch a text editor and open the next .RGU file that appears in the C:\XDA\MY_KITCHEN\Temp\Dump_XIP\ folder.
Select and copy all of the file contents.
Switch to the BOOT.RGU file and paste the content to end of this file.
Repeat steps 3 to 5 until the content of each .RGU file has been appended to the BOOT.RGU file.
Save the expanded copy of the BOOT.RGU file in the C:\XDA\MY_KITCHEN\ROM\XIP\ folder.
Tip
Make a backup copy of the BOOT.RGU file before editing; delete the backup file when done.
Observe the line formatting and spacing in the BOOT.RGU file and make certain to have an empty line as the last line of the file.
Comment lines, which usually begin with a semi-colon [;], can be omitted.
Registry removal lines usually begin with a minus [-] after the open square bracket.
References
Windows Mobile
http://msdn.microsoft.com/en-us/library/ms885472.aspx
Increasing the Data Cache
File caching improves performance and also improves power management; when an application accesses physical storage, the storage device uses much more power. The less often physical storage is accessed, the longer storage devices spend in a low-power state.
By increasing the DataCacheSize registry value, you effectively improve the performance of applications that are file system intensive such as database and mapping applications – which results in lower physical storage access requirements. Drastically increasing the DataCacheSize however, may have adverse effects and slow the device down as a result of longer auto-compaction processing.
For the purposes of this guide, we are going to increase the current DataCacheSize value from 4MB to 8MB.
Tools Required
The following tools are required to adjust the DataCacheSize value.
Unicode Text Editor
Hexadecimal Calculator
Procedure
The following procedure will change the current DataCacheSize value of 4MB to 8MB.
Navigate to the C:\XDA\MY_KITCHEN\ROM\XIP\ folder.
Launch a text editor and open the BOOT.RGU file.
Search for the following registry key entry:
[HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\FLASHDRV\FATFS]
Locate the following registry value underneath the key:
"DataCacheSize"=dword:00000800 ;2048 sectors(2048*2048=4MB)
Change the registry value to the following:
"DataCacheSize"=dword:00001000 ;4096 sectors(4096*2048=8MB)
Save the BOOT.RGU file.
Exit the text editor.
Tip
Make a backup copy of the BOOT.RGU file before editing; delete the backup file when done.
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.
Tools Required
The following tools are required for the .PAYLOAD file reduction activities.
ImgfsFromNb
ImgfsFromDump
ImgfsToNb
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 ReducePayload folder (and contents) from the C:\XDA\MY_KITCHEN\Tools\ folder to the C:\XDA\MY_KITCHEN\Temp\ folder.
Copy the OS.NB.PAYLOAD file from the C:\XDA\MY_KITCHEN\Temp\ folder to the C:\XDA\MY_KITCHEN\Temp\ReducePayload\ folder.
Navigate to the C:\XDA\MY_KITCHEN\Temp\ReducePayload\ folder.
Launch reduce_payload.bat.
At the OS.NB.PAYLOAD Successfully Reduced. Press Any Key To Continue ... message, press ENTER.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Extracting the XIP.BIN Contents
The Execute-in-place (XIP) region is an area where an application can execute code directly from ROM rather than loading it from RAM. Before we can proceed to make changes such as unlocking the Page Pool and disabling Certificate checking, we need to extract the contents of the XIP.BIN file.
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 – you'll eventually do the same.
For the purposes of this guide, we will be using the same version of the system files.
Tools Required
The following tools are required for the XIP.BIN file extraction activities.
XIPPort
Procedure
The following procedure will extract the contents of the XIP.BIN file. The extracted contents of XIP.BIN file will be required when we unlock the page pool and disable certificate checking.
1. Copy the XIPPort folder (and contents) from the C:\XDA\MY_KITCHEN\Tools\ folder to the C:\XDA\MY_KITCHEN\Temp\ folder.
2. Copy the XIP.BIN file from the C:\XDA\MY_KITCHEN\Temp\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder.
3. Navigate to the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder.
4. Launch XIPPORT.EXE.
5. Click the Dump XIP.BIN button.
6. Exit XIPPORT.EXE.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
XIP Porting Guide
http://forum.xda-developers.com/showthread.php?t=379598
Unlocking 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 kernel binary 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 kernel binary file to permit adjustments to the Paging Pool size via the PagePool Changer tool.
Navigate to the C:\XDA\MY_KITCHEN\Tools\xvi32\ folder.
Launch XVI32.EXE.
Select File, Open.
Navigate to C:\XDA\MY_KITCHEN\Temp\XIPPort\OUT\MODULES\nk.exe\ folder.
Select the S000 binary 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 S000 file before editing; delete the backup file when done.
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.
For the purposes of this guide, we are going to apply a change to the kernel binary file which will disable the internal certificate store verification.
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_KITCHEN\cmonex_AutoPatcher\ folder.
Launch AUTOPATCHER01.EXE.
Click the Cert Patch button.
Select All File (*.*) from the Files Of Type list.
Navigate to C:\XDA\MY_KITCHEN\TempXIPPort\OUT\MODULES\nk.exe\ folder.
Select the S000 binary file.
At the Successfully Patched... message, click OK.
Exit AUTOPATCHER01.EXE.
Tip
Make a backup copy of the S000 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
Kernel Overview
http://msdn.microsoft.com/en-us/library/aa909237.aspx
Updating the XIP.BIN Contents
The Execute-in-place (XIP) region is an area where an application can execute code directly from ROM rather than loading it from RAM. Now that we have unlocked the Page Pool and disabled Certificate checking, we need to assemble the extracted XIP.BIN contents back into a XIP.BIN file that includes our changes.
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 – you'll eventually do the same.
For the purposes of this guide, we will be using the same version of the system files.
Tools Required
The following tools are required for the XIP_OUT.BIN file creation activities.
XIPPort
Procedure
The following procedure will compile the contents of the XIP.BIN file. To eliminate some confusion, the new .BIN file will be called XIP_OUT.BIN – the XIPPort tool creates the new .BIN file and renames it to XIP_OUT.BIN.
Navigate to the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder.
Launch XIPPORT.EXE.
Click the Build XIP_OUT.BIN button.
Exit XIPPORT.EXE.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
XIP Porting Guide
http://forum.xda-developers.com/showthread.php?t=379598
Updating the .PAYLOAD file
The Update Loader (ULDR) Partition
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.
As this is generally undesirable in a cooked ROM, since we are making modifications that a carrier Hotfix might roll back, we will reduce the partition. This will cause the device to report insufficient ULDR space to the carrier FOTA request … and the freed up space becomes available for our uses. Lastly, we will remove some debugging system libraries from the XIP_OUT.BIN file – effectively providing approximately 3 MB of space.
Adjusting the ULDR and Updating the .PAYLOAD file
We will use the ROM Tools feature of the XIPPorterEx tool to adjust the ULDR, remove the debugging system library files. We will commit our changes which will replace the current XIP.BIN contents with our new XIP_OUT.BIN contents resulting in the final OS.NB.PAYLOAD file – which we will use when cooking our new ROM.
The new OS.NB.PAYLOAD file will be placed in the following folder – effectively replacing any existing OS.NB.PAYLOAD file.
.\XIPPorterEx\MyTools\os_nb.payload\
As we have already unlocked the Paging Pool and disabled Certificate checking, we will not use the Execute Cert Patcher, Execute PP Patcher, Change PP To MB features. As we will be using the same version of the system files, we do not need to port the MSXIPKernel or remove cachefilt.dll, mencfilt.dll, and encfilt.dll.
Tools Required
The following tools are required to perform the OS.NB.PAYLOAD file update activities.
XIPPorterEx
G’Reloc
ImgfsFromDump
ViewImgfs
XIPPort
Procedure
The following procedure will create a new OS.NB.PAYLOAD file which will be used when cooking our ROM.
Copy the XIPPorterEx folder (and contents) from the C:\XDA\MY_KITCHEN\Tools\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\ folder.
Copy the .ROM folder (and contents) from the C:\XDA\MY_KITCHEN\SYS\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\sys\ folder.
Copy the .VM folder (and contents) from the C:\XDA\MY_KITCHEN\SYS\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\sys\ folder.
Copy the OS.NB.PAYLOAD file from the C:\XDA\MY_KITCHEN\Temp\ReducePayload\ folder to the C:\XDA\MY_KITCHEN\XIPPorterEx\MyTools\os_nb.payload\ folder.
Copy the XIP.BIN file from the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\xip.bin_old\ folder.
Copy the XIP.BIN file from the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\xip.bin_new\ folder.
Copy the XIP_OUT.BIN file from the C:\XDA\MY_KITCHEN\Temp\XIPPort\ folder to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\xip_new_ported\ folder.
Navigate to the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\ 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 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.
Copy the OS.NB.PAYLOAD from C:\XDA\MY_KITCHEN\XIPPorterEx\MyTools\os.nb.payload_Reduced\ folder to the C:\XDA\MY_KITCHEN\XIPPorterEx\MyTools\os_nb.payload\ folder – overwriting the older version of the file.
Click the Find Start XIP Offset button.
Click the Write It button.
At the NEW OS.NB.PAYLOAD Was Updated Successfully... message, click OK.
Exit XIPPORTEREX.EXE.
Copy the OS.NB.PAYLOAD file from the C:\XDA\MY_KITCHEN\Temp\XIPPorterEx\MyTools\os_nb.payload\ folder to the C:\XDA\MY_KITCHEN\ROM\ folder.
Delete the OS.NB file from the C:\XDA\MY_KITCHEN\ROM\ folder.
Tip
You can change the ROM Date/Version in the Ervius PkGToolsBuildOs Kitchen 6.X-5.3 tool.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Reduce ULDR Partition Size
http://forum.xda-developers.com/showpost.php?p=2916649&postcount=7
[TUT] ULDR Removal for Elf/Elfins
http://forum.xda-developers.com/showthread.php?t=446506
[Walkthrough] How to Port a ROM [XIP and SYS]
http://forum.xda-developers.com/showthread.php?t=389772
[14 NOV] M-Amine 2.0 Kitchens + Tutorials
http://forum.xda-developers.com/showthread.php?t=437898
[Full Guide Thread] TNT.Kitchen for Wizard, Auto XIP Porting and Modules Relocating
http://forum.xda-developers.com/showthread.php?t=388666
Changing the Unsigned CAB Policies
Security policies are used for configuring security settings that are then enforced with the help of security roles and certificates. They provide the flexibility to control the level of security on the device. The policies are defined globally and enforced locally in their respective components. The security policy is set during boot by executing a .provxml configuration file. This provisioning file is in ROM and contains the default setting specified by the OEM. The provisioning document is an Extensible Markup Language (XML) file that is assigns security settings to the device.
Typically, the mxipupdate_oemoperators_100.provxml file contains the default security policies that will be applied to the device. To allow execution of unsigned .CAB files, we need to change the default security policy settings that pertain to .CAB files.
For the purposes of this guide, we will add or change the following unsigned policy setting ID’s:
ID 4101: Unsigned CABS Policy = 8
ID 4102: Unsigned Applications Policy = 1
ID 4122: Unsigned Prompt Policy = 1
* IMPORTANT *
Policy settings may appear in other files. You may wish to perform a search through .TXT, .RGU, and other .PROVXML files using the keywords such as: security, policies, policy.
Tools Required
The following tools are required to edit .PROVXML files.
UTF-8 Text Editor
Procedure
The following procedure will add/change the unsigned policy settings to permit the installation of unsigned .CAB files.
Navigate to the C:\XDA\MY_KITCHEN\OEM\OperatorPkg\ folder.
Verify that the mxipupdate_oemoperators_100.provxml is not set as Read Only.
Launch your UTF-8 Text Editor.
Use the Search feature to find the following section:
<!--337.01_SecurityPolicy-->
Ensure that the following lines are present in the section:
<!--337.01_SecurityPolicy-->
<characteristic type="SecurityPolicy">
...
<parm name="4101" value="8" />
<parm name="4102" value="1" />
<parm name="4122" value="1" />
...​</characteristic>
Save the changes to the mxipupdate_oemoperators_100.provxml; ensure that the file is saved in UTF-8 format.
Exit your UTF-8 Text Editor.
Verify that the mxipupdate_oemoperators_100.provxml is set to Read Only.
Tip
Make a backup copy of the mxipupdate_oemoperators_100.provxml file before editing; delete the backup file when done.
Observe the line formatting and spacing in the mxipupdate_oemoperators_100.provxml file.
When saving the file, select the Save As menu option and put quotes ["] around the file name so as to avoid additional file extensions.
References
Security Policy Settings for Windows 6.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/bb416355.aspx
Security Policy Settings for Windows 5.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/ms889564.aspx
What Do The SmartPhone Policy ID's Mean
http://www.xs4all.nl/~itsme/projects/xda/smartphone-policies.html
Changing the Unsigned Themes Policies
Security policies are used for configuring security settings that are then enforced with the help of security roles and certificates. They provide the flexibility to control the level of security on the device. The policies are defined globally and enforced locally in their respective components. The security policy is set during boot by executing a .provxml configuration file. This provisioning file is in ROM and contains the default setting specified by the OEM. The provisioning document is an Extensible Markup Language (XML) file that is assigns security settings to the device.
Typically, the mxipupdate_oemoperators_100.provxml file contains the default security policies that will be applied to the device. If a signed theme file does not have a matching root certificate in the Software Publisher Certificate (SPC) store, the file is unsigned and is therefore not executed. To allow execution of unsigned Theme files, we need to change the default security policy settings that pertain to Theme files.
For the purposes of this guide, we will add or change the following unsigned policy setting ID’s:
ID 4103: Unsigned CABS Policy = 16
* IMPORTANT *
Policy settings may appear in other files. You may wish to perform a search through .TXT, .RGU, and other .PROVXML files using the keywords such as: security, policies, policy.
Tools Required
The following tools are required to edit .PROVXML files.
UTF-8 Text Editor
Procedure
The following procedure will add/change the unsigned policy settings to permit the installation of unsigned .CAB files.
Navigate to the C:\XDA\MY_KITCHEN\OEM\OperatorPkg\ folder.
Verify that the mxipupdate_oemoperators_100.provxml is not set as Read Only.
Launch your UTF-8 Text Editor.
Use the Search feature to find the following section:
<!--337.01_SecurityPolicy-->
Ensure that the following lines are present in the section:
<!--337.01_SecurityPolicy-->
<characteristic type="SecurityPolicy">
...
<parm name="4103" value="16" />
...​</characteristic>
Save the changes to the mxipupdate_oemoperators_100.provxml; ensure that the file is saved in UTF-8 format.
Exit your UTF-8 Text Editor.
Verify that the mxipupdate_oemoperators_100.provxml is set to Read Only.
Tip
Make a backup copy of the mxipupdate_oemoperators_100.provxml file before editing; delete the backup file when done.
Observe the line formatting and spacing in the mxipupdate_oemoperators_100.provxml file.
When saving the file, select the Save As menu option and put quotes ["] around the file name so as to avoid additional file extensions.
References
Security Policy Settings for Windows 6.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/bb416355.aspx
Security Policy Settings for Windows 5.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/ms889564.aspx
What Do The SmartPhone Policy ID's Mean
http://www.xs4all.nl/~itsme/projects/xda/smartphone-policies.html
Customizing the User Interface of Windows Mobile Powered Devices
http://msdn.microsoft.com/en-us/library/bb416487.aspx
Changing the Remote API (RAPI) Policies
Security policies are used for configuring security settings that are then enforced with the help of security roles and certificates. They provide the flexibility to control the level of security on the device. The policies are defined globally and enforced locally in their respective components. The security policy is set during boot by executing a .provxml configuration file. This provisioning file is in ROM and contains the default setting specified by the OEM. The provisioning document is an Extensible Markup Language (XML) file that is assigns security settings to the device.
The Remote API (RAPI) enables applications that run on a desktop to perform actions on a remote Windows Embedded CE-based device. This includes the ability to manipulate the file system on the remote device, including the creation and deletion of files and directories. Additionally, the Remote API (RAPI) functions can be used to create and modify databases, either in the device's object store or in mounted database volumes. The Remote API (RAPI) applications can also query and modify registry keys as well as launch applications and invoke methods on the remote device.
Typically, the mxipupdate_oemoperators_100.provxml file contains the default security policies that will be applied to the device. To allow unrestricted access by remote applications to implement ActiveSync operations on Windows Mobile powered devices, we need to change the default security policy settings that pertain to the Remote API (RAPI).
For the purposes of this guide, we will add or change the following unsigned policy setting ID’s:
ID 4097: Unsigned Prompt Policy = 1
* IMPORTANT *
Policy settings may appear in other files. You may wish to perform a search through .TXT, .RGU, and other .PROVXML files using the keywords such as: security, policies, policy.
Tools Required
The following tools are required to edit .PROVXML files.
UTF-8 Text Editor
Procedure
The following procedure will add/change the unsigned policy settings to permit the installation of unsigned .CAB files.
Navigate to the C:\XDA\MY_KITCHEN\OEM\OperatorPkg\ folder.
Verify that the mxipupdate_oemoperators_100.provxml is not set as Read Only.
Launch your UTF-8 Text Editor.
Use the Search feature to find the following section:
<!--337.01_SecurityPolicy-->
Ensure that the following lines are present in the section:
<!--337.01_SecurityPolicy-->
<characteristic type="SecurityPolicy">
...
<parm name="4097" value="1" />
...​</characteristic>
Save the changes to the mxipupdate_oemoperators_100.provxml; ensure that the file is saved in UTF-8 format.
Exit your UTF-8 Text Editor.
Verify that the mxipupdate_oemoperators_100.provxml is set to Read Only.
Tip
Make a backup copy of the mxipupdate_oemoperators_100.provxml file before editing; delete the backup file when done.
Observe the line formatting and spacing in the mxipupdate_oemoperators_100.provxml file.
When saving the file, select the Save As menu option and put quotes ["] around the file name so as to avoid additional file extensions.
References
Security Policy Settings for Windows 6.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/bb416355.aspx
Security Policy Settings for Windows 5.x Mobile-Based Devices
http://msdn.microsoft.com/en-us/library/ms889564.aspx
What Do The SmartPhone Policy ID's Mean
http://www.xs4all.nl/~itsme/projects/xda/smartphone-policies.html
Remote API (RAPI)
http://msdn.microsoft.com/en-us/library/aa920177.aspx
Compiling the New RUU_SIGNED.NBH File
Brief Review
At this point, we have consolidated the contents of various .RGU files found in the Dump_XIP folder to the BOOT.RGU file to ensure that all necessary registry entries will be added during the ROM compilation activities. We have increased the Data Cache size, unlocked the Paging Pool, disabled Certificate checking, reduced the ULDR, changed the Unsigned .CAB policy, changed the Theme policy, changed the Remote API (RAPI) policy, and reduced the .PAYLOAD file.
This guide did not go into details about adding, changing, or removing ROM packages to/from the OEM and SYS folders. Additionally, the guide did not cover the steps required to port an XIP from a different ROM version or device – you'll eventually want to learn how to do these types of activities.
Compiling the ROM
We now need to assemble all of these changes into a new RUU_SIGNED.NBH file – this process if often referred to as ROM compilation. We are going to use the Ervius PkgToolsBuildOS-5.3 tool to perform this process – there are newer versions of the Ervius PkgToolsBuildOS available.
Tools Required
The following tools are required for the RUU_SIGNED.NBH file creation activities.
PkgToolsBuildOS-5.3
ImgfsFromDump
NBMerge
Procedure
The following procedure initiates the ROM creation activity via a script that is included in the Generic Simple Kitchen. The creation process can take a significant amount of time to complete and requires user interaction at various stages.
Navigate to the C:\XDA\MY_KITCHEN\ folder.
Launch RaphaelKitchen.cmd.
Select C, press ENTER.
The Ervius PkgToolsBuildOs application will be launched.
Click the BuildOS tab.
Click the Load ROM button.
Select the All Packages In One check box.
In the Name box, type in the title: All Packages In One ROM
Select the Create_ROM_***.bat check box.
In the ROM Date Updater boxes, enter the desired date. Alternatively, click the Today button.
Click the Update Date button.
At the ROM Date On Flash Updated Successfully... message, click OK.
Click the Go button; allow the process to complete.
Wait for the Done message to appear in the Top Status bar.
Exit the Ervius PkgToolsBuildOs application to allow the process to continue.
The HTC ROM TOOL Process Log will appear.
Click the OK button on the Process Log window or allow it to auto exit.
At the Press Any Key To Continue... message, press ENTER.
Select X, press ENTER.
Copy the RaphaelCustomRUU.exe file from the C:\XDA\MY_KITCHEN\Tools\ folder to the C:\XDA\MY_KITCHEN\RUU\ folder.
Move the RUU_SIGNED.NBH file from the C:\XDA\MY_KITCHEN\ folder to the C:\XDA\MY_KITCHEN\RUU\ folder.
Tip
If the compilation is successful, the last three (3) lines in the Report window of the Ervius PkgToolsBuildOs application will display: Checking os-new.nb for bad NAND block marker. Checked 0x### sectors successfully! Done.
References
Ervius: Visual Multilang Kitchen For Last Bepe ROM-Tools
http://forum.xda-developers.com/showthread.php?t=469420
Flashing the RUU_SIGNED.NBH File
If you are reading this, you must have successfully compiled your RUU_SIGNED.NBH file and are now ready to flash it to your device … congratulations! 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.
Also keep in mind that you'll need to unlock your device before venturing into the world of ROM flashing. If you haven’t unlocked your device and applied the Hard SPL, you need to complete these tasks before you can proceed.
The ROM Flashing process is relatively straight forward. You need to ensure that you can connect to your device via the ActiveSync application. Once you have connected to the device, launch the RaphaelCustomRUU tool to flash your cooked ROM to your device – I suggest temporarily disabling your anti-virus software to avoid unforeseen problems.
Tools Required
The following tools are required to flash the RUU_SIGNED.NBH file to your device.
RaphaelCustomRUU
Procedure
The following procedure initiates the ROM Flashing activity. The flashing process can take a significant amount of time to complete and requires user interaction at various stages.
Navigate to the C:\XDA\MY_KITCHEN\RUU\ folder.
Launch RaphaelCustomRUU.exe.
At the Welcome To The ROM Update Utility window, select the I Understand The Caution Indicated check box.
Click the Next button.
At the Follow The Instructions Below window, select the I Completed The Steps Indicated Above check box.
Click the Next button.
At the Current Information About Your PDA Phone window, click the Update button.
At the Verify That You Want To Update The ROM Version window, click the Next button.
At the You Are Now Ready To Update Your ROM Image window, click the Next button - allow the flashing process to complete.
Click the Finish button.
Tip
The current version of the PDA Phone ROM Update Utility 3.27.4.3 we are using has been modified to not format the device when only flashing a Radio, Startup Screen, or Operating System.
Your anti-virus will warn you that the RaphaelCustomRUU.exe contains the "Generic Dropper (Trojan)" – this is a false-positive indication; the .EXE is safe to use.
You can usually recover from a failed flash by copying a known "working" .NBH file to a MicroSD Card and starting your device in the Tricolour bootloader.
References
CustomRUU for Raphael
http://forum.xda-developers.com/showthread.php?t=410761
[Resources] Flashing your First GSM Raphael Rom (For Noobs)
http://forum.xda-developers.com/showthread.php?t=448008
Advanced Topic: XIP Porting
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.
[TUT] Sous-Chef's Guide to Aruppenthal’s XIP Porting Kitchen
http://forum.xda-developers.com/showthread.php?t=526804
Sous-Chef's TIPs
Tips and techniques passed down from the senior chefs in the business.
Love .PROVXML's? Hate Not Knowing If It Worked?
http://forum.xda-developers.com/showthread.php?t=519548
[WinXP Script] Extend Search Companion
http://forum.xda-developers.com/showthread.php?t=490216
[Guide] How to create .LNK files and use parameters
http://forum.xda-developers.com/showthread.php?t=490447
13/02/2010: Tutorial Statistics
Views: 8,744
Guide Downloads: 96
Kitchen Downloads: 118
Thank you very much for putting this together this will help newbs like me cook my own ROM instead of rely on others. Very great contribution.

Customize the Rom Update Utility (RUU)

Recently, I played with the HTC Rom Update Utility and collected some knowledge about it that I thought was worthwhile to share. Maybe you can use it as some guidelines & tips to customize the RUU for your own roms.
------------------------------------------
As you all know the HTC Rom Update Utility contains the following files:
Code:
EnterBootloader.exe ErrorBattery.fig ErrorUSB.fig ModelID.fig rapitool.exe ROMUpdateUtility.exe RUUGetInfo.exe RUUResource.dll
Modifying the dialog boxes
The dialogs that are displayed when launching the ruu are part of the RUUResource.dll. These dialog windows are fairly easy to modify with a resource editor, like for example Resource Tuner.
With a resource editor you can modify the text of the dialog windows. This can be very handy when you want to provide some extra info about your roms. Besides this you can change some controls like buttons, checkboxes etc. For example, for your own sake you can change the user interface to speed up the update proces by hiding the checkboxes and enable the next buttons by default. (see the attached RUUResource.dll)
Modifying the image displayed on the dialogs
The picture of the device showed on the lefthand side of the dialogs is contained in the file ModelID.fig . This picture has a height of 332 pixels and a width of 214 pixels.
To create your own image use your favorite image-editor. Save the created 332 x 214 image as a gif, bmp, jpg or png file and convert it to the "fig" format using the attached img2img tool (or download it from here) To convert for example the file x.bmp to x.fig run the following comand at the comand prompt:
Code:
img2img x.bmp x.fig
Creating a self-extracting CustomRUU.exe
All the RUU files can be packed together in a self-extracting exe using the SFX scripting facilities of WinRar. To do so: select the files that have to be packed together (see the listing at the top of this post). Right click and select "add to archive". Select "Create SFX archive" and go to the Advanced tap. Select "SFX Options..." and set the following parameters:
Code:
Tab general
Path to extract: current folder
Setup program: "setup.vbs" (explained later)
Tab modes
Silent mode: Hide all
Tab Text and Icon
Load SFX icon from file: enter your favorite icon (I attached a HD2 icon to this post to experiment with - [B]HD2_ico.zip[/B])
Because you want the self-extracting exe to clean up the files after the RomUpdateUtility has run, an extra batch file has to be created in which all files are deleted after the ruu is called. (I attached this batchfile as setup_bat.zip) Because Windows opens a comand window when a batch file is run, i've created a vb script for the Windows Scripting Host (part of the OS of Windows 98 and later) in which the batch file is called in a "hidden" window. (script attached as setup_vbs.zip). It is this script that is called by the SFX script.
Of course the setup files have to be deleted also (this is done in setup.bat)
Great tut.... nice!
Thanx!!
oh, this is what i was looking for! thanks for sharing
Good job man !
Thanks alot Now rom customization can go even further
Checkout 7-ZIP SFX Maker, perfect if your looking for a free / smaller option to WinRAR

[SCRIPT]Signapk batch file [WINDOWS]

So something very simple. Just a little batch file I made but I thought is useful.
NOTE: The point of this batch file is to be able to sign apk's and zips from anywhere in any of your directories, without needing to have the signapk.jar and key files in the same directory. It will not perform any magic and sign system apps with the system signature, or non-system apps with the system signature.
This will sign whatever you give to it...just put it somewhere that is in your path and edit the line that says this:
Code:
set signdir=[U][B]C:\eclipse-adt\cmdtools[/B][/U]
Change C:\eclipse-adt\cmdtools to the path of wherever your signapk.jar file is (your keys should be in that same folder, named publickey.x509.pem and privatekey.pk8).
Example:
Code:
set signdir=[U][B]C:\bill\android\signing-tools[/B][/U]
Anyway, usage for the batch file is as follows (also tells you usage if you pass no parameters to the batch file, e.g. just call signapk).
Code:
Signapk.bat: Sign files from anywhere
Usage: signapk inFile [outfile]
Examples:
signapk mod1.zip [implicit 2nd parameter of mod1-signed.zip]
signapk mod1.zip finalMod.zip
signapk frameworkTW.apk softkeyHack.apk
First example will output a mod1-signed.zip as the signed version of mod1.zip.
Second example will output finalMod.zip as the signed version of mod1.zip.
Third example will output fsoftkeyHack.apk as the signed version of frameworkTW.apk.
Note that if you only pass ONE parameter to the batch file (e.g. the file to sign), then the output file will ALWAYS be named <fileName>-signed.<extension>, as mod1.zip created a mod1-signed.zip output in the example above.
So yeah. Very simple, but I was getting tired of copying my files to my signapk directory and then copying back...so just thought I should share.
If you don't feel like downloading the file, you can create it yourself by copying the content from here: pastebin.com/u6Zj3rsH and pasting it into a file named "<FILE_NAME_HERE>.bat".
Download:
Code:
e1d7016e1b56aa32824974125a424869 *signapk.zip

Categories

Resources