[KITCHEN][06.05.2010]Manila CMD Kitchen Environment - Windows Mobile Software Development
When I first started on this project, this kitchen existed of 5 script each containing few lines of code, only able to handle one LUA script at a time. I had just helped out on the first ever manila 2.0 VGA port and I could see the use of a kitchen that did most of the manual labour automatically. At that time my understanding of what needed to be done to successfully edit script was limited. As I tried to add more features to the script I learned more about LUA, the handling and decompiling of the scripts. I chose to make the kitchen do as much for you on first run. The kitchen got more mature after I met hilaireg who knew a lot more about batch scripting than I did and who's perfectionist style made the kitchen what it is today.
After we teamed up we started a little manila group and got into contact with co0kiemonster. He's the one who created\updated most of the tools on which the script relies, and so not only optimizing manila handling but also pushing it's boundaries. We put in the applications that best handle manila files and connected these via the script. Since our last update co0kie kept developing the tools and they became a lot better. A batch script isn't really the way to handle this but until we get a real manila GUI, we decided to give the script one last update. Since this will likely be the last big project hilaireg will be presenting here, this last version is dedicated to him.
Workstation/System Requirements:
The Manila Kitchen environment can run on a Windows XP, Windows Vista, and Windows 7 platform providing the following requirements are met:
Microsoft .NET 3.5 SP1 (M9Editor)
Elevated priviledges
Windows XP/Vista/Seven
Kitchen Contents:
ROOT
MANILATOOL.CMD by hilaireg & 12aon
Manila Kitchen Guide
Revision History
_SOURCE folder
_TOOLS folder
Shortcuts to tools
TOOLS
LUATOOL.EXE by Co0kiemonster
M9EXT.EXE by Co0kiemonster
MANILANAMES.EXE by Co0kiemonster
M9EDITOR.EXE by 6Fg8
CFC_GUI.EXE by Chainfire
NOTEPAD2.EXE by Florian Balmer, Compiled by Co0kiemonster
MANILAHASH.EXE by NisseDILLIGAF
XVI32.EXE by Christiaan Maas
RAPICOPY.EXE, RAPIPROC.EXE, RAPISTART.EXE by Scott Seliman
GREP.EXE by Tim Charron
Current Version (Attached Files)
Manila Kitchen 5.05.06, 4.7 MB (06/05/2010)
Previous Versions
Manila Kitchen 5.04.23, 4.7 MB (23/04/2010)
Manila Kitchen 5.03.04, 4.1 MB (04/03/2010)
Manila Kitchen 4.10.16, 9.3 MB (16/10/2009)
Manila Kitchen 4.10.02, 7.7 MB (02/10/2009)
Credits:
Special thanks to the following folks for sharing their knowledge and expertise. If I missed someone, it's purely accidental – send me a note and I will add your name to the list.
6fg8
chainfire
co0kiemonster
sztupy
Overview
The Manila Kitchen is an automated environment that includes tools (utilities) to perform decompilation, editing, and recompilation of HTC Manila OEM files.
Instructions are passed to the MANILATOOL command script which in turn, initiates various executables to perform the necessary actions required on the HTC Manila OEM files.
Some of the tools used by MANILATOOL were written by 6fg8, chainfire, co0kiemonster, and sztupy. As such, some of these tools are not compatible with excessively long path names or paths that contain spaces or brackets. To avoid issues, place the Manila Kitchen in a relatively short path that does not contain spaces or brackets such as: C:\XDA\Manila_Kitchen
The Manila Kitchen provides the following benefits:
Consolidated Tools
All of the tools required to perform Manila related activities have been incorporated. These include decompilation, comparison, recompilation, .CAB creation, direct deployment to mobile devices, updating Mode9 Editor reference index, and backing up. The executables are initiated with the appropriate command parameters and in the correct sequence by MANILATOOL thus eliminating the "guess work" typically required.
Improved Resiliency
The activities required to manage HTC Manila OEM files are complex in nature. In some cases, a Manila file may fail to be decompiled or cause one of the initiated executables to generate and error as a result of an unexpected condition. The MANILATOOL command script will attempt to recover from such errors when possible so as to complete the command that was initiated.
Command Line Help and Version Information
Wondering what command parameters are available in the MANILATOOL command script? Simply append -HLP to the end of the MANILATOOL command script to display a summary of parameters available. To determine the version of the MANILATOOL command script in use, append -VER to the end of the MANILATOOL command script.
Enhanced File Recovery
Accidentally changed a file and need the previous version? The MANILATOOL command script performs a backup before any critical operation making it easier to retrieve a previous version of a file.
Enhanced Script Diagnostics
Although a significant of amount effort has gone into the development of the Manila Kitchen, it is possible that a script logic error may occur. To assist in troubleshooting such errors, the MANILATOOL command script includes a comprehensive logging debugger.
Topic Index
Preparing the Kitchen Environment ....... 3
Initializing the KitchenDecompiling Manila OEM Files ............ 4
LUA Editing
Mode9 Editing
General Editing
Updating 'm9editor.names.txt'
Updating the RepositoryWorking with Manila Files ............... 5
Initializing the KitchenRecompiling Manila OEM Files ............ 6
RecompilationTesting the Manila OEM File Changes ..... 7
Installer .CAB Method
Direct to Device MethodReference Web Links ..................... 8
Frequently Asked Questions (FAQ) ........ 9
Preparing the Kitchen Environment
The Manila Kitchen environment must be initialized prior to initial use. During the initialization phase, all MANILATOOL command script parameters are enabled and the contents of following folders, sub-folders, and files are removed and recreated:
_backup
_queue
Decompiled
Release
Repository
Workspace
The following configuration files will be reset to their initial settings:
m9editor.cfg .\_TOOLS\M9Editor
notepad2.ini .\_TOOLS\Notepad2
xvi32.ini .\_TOOLS\XVI32
The following applications shortcuts will be reset to their initial settings:
CFC_GUI.lnk
M9Editor.lnk
manilaHASH.lnk
Notepad2.lnk
HexEdit32.lnk
The following Manila Mode9 reference index will be reset to their initial settings:
m9editor.names.orig.txt .\_TOOLS
mnf_m9paths.orig.txt .\_TOOLS
m9editor.names.orig.txt .\_TOOLS\M9Editor
Initializing The Kitchen
The following procedure will initiate the Manila Kitchen initialization process. All HTC Manila OEM files found in the .\_SOURCE folder will be copied to the .\_queue folder.
Currently, there are two versions of Manila reference index names; one for pre-Manila 2.5 and one for post-Manila 2.5. It is possible to set the initial Manila reference version during the kitchen initialization procedure. For example, if the .\_SOURCE folder contains a specific version of HTC Manila OEM files, specify the Manila version as part of the parameter. If the kitchen will contain a mix of pre-Manila 2.5 and post-Manila 2.5 files, an incomplete set of Manila files, or an unknown Manila file, specify 0.0 as the kitchen version.
The following procedure will initiate the Manila Kitchen initialization process.
► To initiate a Manila Kitchen reset and specify Manila version 1.3
Place a copy of the original (untouched) HTC Manila OEM files or packages in the .\_SOURCE folder.
Double-click (launch) the Command Prompt shortcut found in the root of the kichen folder.
At the prompt, type the following command: manilatool.cmd -oem:1.3
Press ENTER.
► To initiate a Manila Kitchen reset and specify Manila version 2.5
At the prompt, type the following command: manilatool.cmd -oem:2.5
Press ENTER.
► To initiate a Manila Kitchen reset and specify a mix, small set, or unknown Manila files
At the prompt, type the following command: manilatool.cmd -oem:0.0
Press ENTER.
Decompiling Manila OEM Files
HTC Manila OEM files must be decompiled before changes can be made to them. The decompilation of HTC Manila OEM files occurs on files that are found in the .\_queue folder. Use the Manila Kitchen initialization process to copy the HTC Manila OEM files from the .\_SOURCE folder to the .\_queue folder before attempting to decompile files.
As files are processed, they are removed from the .\_queue folder and placed in a .\Processed folder. Once completed, decompilation mode will be disabled so as to prevent accidental loss of work to decompiled Manila files. The Manila Kitchen must be initialized in order to enable decompilation mode.
Decompilation
The decompilation process passes each manila file found in the .\_queue folder to the LUA processor (luatool.exe) tool. During the decompilation process, the LUA processor (luatool.exe) tool validates the decompilation and produces additional output files if the decompilation was not successful.
Additionally, the decompilation process will extract a copy of embedded Manila (Mode 9) scripts, initiate the LUA processor (luatool.exe) tool to decompile the extracted script, and validate that the decompilation occurred successfully.
Upon completion, a decompiled version of the Manila file will be found in one of the following folders - which are determined by the results of the decompilation process:
Completed: .\Workspace\_lua (successfully decompiled)
Incomplete: .\Workspace\_lua (partially decompiled)
Error: .\Workspace\_lua (failed decompilation)
InternetPortal: .\Workspace (XML files)
Manilapages: .\Workspace (XML files)
Mode9: .\Workspace (Mode9 files)
PNG: .\Workspace (Image files)
QTC: .\Workspace (Image files; in Graphics folder)
SQLite: .\Workspace (Database files)
TTF: .\Workspace (True Type Font files; in Graphics folder)
XML: .\Workspace (XML files)
Unknown: .\Workspace (Unknown files)
The following procedure will initiate the Manila Kitchen decompilation process.
► To initiate HTC Manila OEM file decompilation
Ensure desired HTC Manila OEM files are present in the .\_queue folder once the kitchen initialization has completed.
Double-click (launch) the Command Prompt shortcut found in the root of the kichen folder.
At the prompt, type the following command: manilatool.cmd -dec
Press ENTER.
Working with Manila Files
Once the HTC Manila OEM files have been decompiled, changes may be made as required. The Manila Kitchen provides a single work area for Manila file editing; this is:
Workspace
Workspace
This workspace contains all of the decompiled Mode9 files, graphics, and other Non-LUA files that are typically manipulated using the M9Editor, Notepad2, and/or CFC_GUI.
Workspace\_lua
This area of the workspace contains all of the decompiled LUA files. Use a standard UTF-8 compatible editor such as Notepad2 to make changes to the files.
LUA Editing
Files that have failed to decompile during the initial decompilation process typically need to be manually edited so as to address the cause of the failure. Editable *.lua Manila files reside in the .\Workspace\_lua folder and may be change with a text editor such as Notepad2.
Once the Manila file has been fixed, initiate the the LUA Comparison (luatool.exe) tool to validate that the changes made to the file are correct.
The LUA Comparison process will compare the changes made to the decompiled Manila file against the original Manila file. If successful, the Manila file will be moved from the .\Incomplete or .\Error folder to the
.\Completed folder.
The following procedure will initiate the comparison process.
► To initiate Manila file comparison
At the prompt, type the following command: manilatool.cmd -cmp
Press ENTER.
Mode9 Editing (Mode 9, Graphics, PNG)
M9Editor is a tool for editing Manila files; nearly all aspects of a Mode9 LUA file can be viewed, changed, and saved. Mode 9 LUA Manila files are stored in the .\Workspace\Mode 9 folder and are changed with from within the M9Editor.
Additionally, the M9Editor tool provides graphics import/export capabilities as well as Chainfire File Compression (CFC) support. Lastly, the M9Editor tool includes a folder (directory) viewer which displays information specific to Manila files.
Although it is possible to decompile Manila files with the M9Editor tool, the current version (3.0.03) utilizes a deprecated version of the LUA Decompiler (luadec.exe) which is not supported by this Manila Kitchen.
► To initiate the M9Editor tool
Navigate to the Manila Kitchen folder.
Double-click the M9Editor shortcut.
General Editing (InternetPortal, Manilapages, QTC, PNG, SQLite, TTF, XML)
Some of the Manila files found in the .\Workspace folder may also be changed by other tools such as Notepad2 and CFC_GUI.
► To use an other tool to edit certain Manila files
Launch the desired tool (ex: Notepad2, CFC_GUI, etc.)
Select the Open file option from within the tool.
Navigate to the .\Workspace folder.
Select the Manila file to change.
Updating 'm9editor.names.txt'
From time to time, HTC adds new Manila files or updates the names of existing ones. To update the M9Editor Reference Index file, initiate the Manila name scan process using the MANILATOOL command script. The Manila Name Finder (mnf.exe) tool will iterate through the HTC Manila OEM files found in the .\_SOURCE folder and obtain the new names.
Updating the m9editor.names.txt reference index file ensures that the M9Editor tool is able to display the friendly Manila file name making it easier to work with Manila files - instead of the compiled Hash name used by HTC. Currently, there are two versions of Manila reference index names; one for pre-Manila 2.5 and one for post-Manila 2.5.
The Manila name scan process supports the following Manila versions: 2.5, 2.2, 2.1, 2.0, 1.3, 1.2, 1.1, and 1.0. Specifying a Manila version other than 2.5 will initiate the Manila Name Finder (mnf.exe) tool in pre-Manila 2.5 scan mode. The MANILATOOL command script determines which scan mode to use by first querying the 'kitchen-ver' file - if the value is 0.0; the mode specified in the command parameter is utilized.
Use one of the following procedures to initiate the appropriate M9Editor reference index update process.
► To initiate a pre-Manila 2.5 reference index update
At the prompt, type the following command: manilatool.cmd -mnf:2.1
Press ENTER.
► To initiate a Manila 2.5 reference index update
At the prompt, type the following command: manilatool.cmd -mnf:2.5
Press ENTER.
Updating the Repository
Updating the .\Repository folder ensures that a recent backup copy is available in the event that a change to *.lua must be reversed. During the repository update, decompiled *.lua files found in the .\Workspace\_lua folder are copied to the .\Repository\_lua and a hierarchy (by unhashed names) is created in the .\Repository\windows folder.
The .\Repository\windows folder hierachy displays shortcut links to the Manila files that correspond to a Manila feature. For example, navigate the hierarchy and double-click the shortcut link that corresponds to the file that requires modification - the appropriate tool will be launched.
The following procedure will initiate the repository update process.
► To initiate a repository update
At the prompt, type the following command: manilatool.cmd -lib
Press ENTER.
Frequently Asked Questions (FAQ)
What types of files can be placed in the '.\_SOURCE' folder?
Any type of file may be placed in the .\_SOURCE folder. The MANILATOOL command script will only copy files that contain the word "manila" in them to the .\_queue folder.
I accidentally specified the wrong version of Manila files during the kitchen initialization; is there a way to change it without initializing the kitchen again?
The default Manila file version is stored in the kitchen-ver file. Use a standard text editor such as Notepad2 to edit file. The file must contain a three characters equivalent to the version - valid versions are: 2.5, 2.2, 2.1, 2.0, 1.3, 1.2, 1.1, 1.0, and 0.0 (Unknown/Custom)
What is the '._BACKUP' folder used for?
Before most operations occur, a backup of files that will be changed or removed from/in a given folder is performed. This ensures that previous functional files remain available in the event that a "rollback" is required.
What is the difference between the "Incomplete", "Error", and "Completed" (successful) LUA folders?
Manila files that are successfully decompiled are will appear in the "completed" folder - 100% comparison result. Manila files that are decompiled but do not pass the comparison validation (less than 100%) are placed in the "incomplete" folder. Manila files that report a 0% decompilation result are placed in the "error" folder.
What is the difference between the files in the '.\Release\_lua', '.\Release\_error', '.\Release\CAB', and '.\Release\DEVICE' folders?
The .\Release_error folder will only appear when unexpected errors were encountered during Manila LUA file recompilation. The folder will contain logs detailing the problem that was encountered with a Manila LUA file. The folder is removed and recreated at each recompilation.
The .\Release\_lua folder contains the recompiled versions of the Manila LUA files that are found in the .\Workspace\_lua folder. These are the files can be distributed directly to a device or via CAB file.
The .\Release\CAB folder contains the recompiled versions of the files found in the .\Release\_lua folder. These are the files can be installed via ActiveSync or a Storage Card.
The .\Release\DEVICE folder contains the recompiled versions of the files found in the .\Release\_lua folder. These are the files can be installed via ActiveSync or a Storage Card.
What is the difference between the files in the '.\Processed', '.\Workspace', and '.\Repository' folders?
The .\Processed folder contains the HTC OEM Manila files that were copied to the .\_queue during the Manila Kitchen initialization process. During the decompilation process, the files are moved from the .\_queue folder to the appropriate folder - which is determined by the LUA Comparison tool results.
The .\Workspace\_lua folder contains decompiled versions of the HTC OEM Manila files - these are the files that are typically modified and recompiled. The remainder of the folders in the .\Workspace folder contain various non-LUA files.
The .\Repository\_lua folder contains a duplicate copy of the decompiled Manila files. The repository serves a form of backup.
What are the extra .TXT files that appear in the partially decompiled LUA script folders?
The *.error.txt file contains the STDOUT error that was generated by the LUA Decompiler. When this file appears, there is a logical error in there script, which makes it impossible to run the script. The file will usually contain the approximate (line number) location where the problem was encountered.
The *.log.txt file contains the compared disassembly output from the orignal Manila file and the decompiled LUA version - which appears in the folder. When this file appears, it is an indication that the script will function but it does not match the original Manila file.
The *.dis.txt file contains the raw (full) disassembly of the original Manila file and may be used to resolve the decompilation issue.
The *.status.txt file contains the decompilation result - 0% to 100%.
Visit the following website to obtain more information in troubleshooting a failed decompilation:
http://winmo.sztupy.hu
Is the disassembly output always correct?
Yes. Even though the some of the events may be not be displayed in the disassembly output, the correct sequence of events will be provided.
The M9Editor tool provides a built-in decompiler, why not just use that?
The internal LUA Decompiler (luadec.exe) provided with the M9Editor tool is an earlier version. This internal version does not provide the extra files required to resolved decompilation errors.
The M9Editor should be used when editing Mode9 files and attach extracted embedded LUA script back to their original Mode9 files.
There are strange errors such as '.\documents and settings\<profilename>\eee' errors, what is the solution? (Only in older versions)
One of the Manila Kitchen tools is in an unknown state or temporary files are locked and cannot be freed. Note the path location of the .\eee folder, restart the workstation, and manually delete the folder, sub-folders, and files.
An error message is displayed when attempting to delete a file or folder, what is the solution?
A running process is preventing the file or folder from being removed. Restart the workstation and manually delete the file or folder.
Can Error Reporting be disabled so as to not have to click the Close button every time the LUA Decompiler and/or LUA Comparison tool generate an application error?(Only in older versions)
As previously noted, some Manila files cause the LUA Decompiler (luadec.exe) and/or LUA Comparison (compare.exe) tool to generate an application error. Visit the following website(s) for more information on how to suppress the Error Reporting message box.
Windows XP
http://www.windowsnetworking.com/articles_tutorials/Disable-Error-Reporting-Windows-XP-Server-2003.html
Windows Vista/Seven
http://thehiddenguide.com/how-to-disable-error-reporting-in-windows-vista
Recompiling Manila OEM Files
Once editing is complete, the Manila files must be recompiled before they may be used on a mobile device.
Should an error be encountered during recompilation, the MANILATOOL command script will create a Manila LUA error log file in the .\Release\_error folder and continue recompiling Manila LUA files. In the event of a "hard" recompilation error, the contents of .\Release\_lua folder will be removed and the previous successful recompilation will be restored.
Recompilation
The recompilation process occurs on files that found in the .\Workspace\_lua\Completed folder. Once completed, the files are ready for deployment to a mobile device that is directly connected to a workstation or via an installer .CAB file.
The following procedure will initiate the recompilation process.
► To initiate Manila file recompilation
At the prompt, type the following command: manilatool.cmd -rec
Press ENTER.
Testing the Manila OEM File Changes
The Manila Kitchen environment provides additional tools for testing a final work product. Manila files can be distributed to mobile devices using one of the following methods:
Installed .CAB
Direct to Device
The quickest method of distributing recompiled Manila files is via an installer .CAB file. The direct to device method of distributing recompiled Manila files is via ActiveSync over a USB/Serial connection - this method is
quickest during development activities.
Installer .CAB Method
The MANILATOOL command script provides a parameter to automatically create a redistributable .CAB file. The installer .CAB can be copied to the mobile device and launched using the device File Explorer. Alternatively, the installer .CAB file may be installed via ActiveSync. Should an installer .CAB fail to install on a device, it is likely that policy restrictions are in effect.
The following procedure will initiate the .CAB creation process.
► To initiate the CAB Wizard tool
At the prompt, type the following command: manilatool.cmd -cab
Press ENTER.
Direct to Device Method
The MANILATOOL command script includes a parameter to automatically stop the mobile device Manila executable (manila.exe), transfer a copy of the Manila files, and restart the mobile device Manila executable.
The copy operation may fail on a device where policy restrictions are in effect. Additionally, the Manila executable may not restart in such cases.
The following procedure will initiate the comparison process.
► To initiate RAPI Copy tool
At the prompt, type the following command: manilatool.cmd -dep
Press ENTER.
Reference Web Links
Manila 3D Kitchen
http://winmo.sztupy.hu/manilakitchen.html
http://forum.xda-developers.com/showthread.php?t=487331
Manila Tutorial
http://forum.xda-developers.com/showthread.php?t=399212
LUA Decompiler
http://forum.xda-developers.com/showthread.php?t=568281
LUA 5.1 Decompiler
http://winmo.sztupy.hu/luadec.html
http://forum.xda-developers.com/member.php?u=1433290
http://forum.xda-developers.com/showthread.php?t=479910
LUA Decompiling Tutorial
http://winmo.sztupy.hu
http://winmo.sztupy.hu/manilakitchen/rhodium2_manila_wvga_src.zip
TF3D Manila Mode9 Editor
http://forum.xda-developers.com/showthread.php?t=464984
MNF - Manila Name Finder
http://forum.xda-developers.com/showthread.php?t=546820
CFC - The Manila/TF3D Image Editor
http://forum.xda-developers.com/showthread.php?t=437777
TouchFLO/Manila/SenseUI
http://forum.xda-developers.com/group.php?groupid=131
Co0kie's Beta Testing and Development
http://forum.xda-developers.com/group.php?groupid=192
Max Sense Testers
http://forum.xda-developers.com/group.php?groupid=185
GT7 Sense 2.1 Theme Beta Testers
http://forum.xda-developers.com/group.php?groupid=202
Leaked Full EXT/Manila 2.5 Packages-latest official sprint tp2
http://forum.xda-developers.com/showthread.php?t=642817
Enabling the Logging Debugger
Although a significant of amount effort has gone into the development of the Manila Kitchen, it is possible that a script logic error may occur. To assist in troubleshooting such errors, the MANILATOOL command script includes a comprehensive logging debugger.
The logging debugger can provide basic, expanded, or verbose (full) logging. To enable the logging debugger, append -DEB:[1-5] to the end of the MANILATOOL command script. For example, to set the logging debugger level to 1, type the following command at the Command Prompt:
manilatool.cmd -hlp -deb:1
Processing activities are displayed in the Command Prompt window and are recorded in the ManilaTool_Log_#.##.##.txt file. The log file will include the version of MANILATOOL command script and the command parameters that was requested. The following logging debugger levels are available:
Level 0: Default. The MANILATOOL command script typically operates at this level.
Level 1: Provides slightly more details on the script processing activities. Specifiy this logging level to view the results of actions performed on a Manila file.
Level 2: Provides comprehensive details on the processing activities performed on a Manila file. Specify this logging level when trying to determine why a Manila file may have failed to be processed. Choosing this logging level on a large number of Manila files will increase the time it takes to complete Manila file processing.
Level 3: Developer verbose level 1. Specify this logging level to view the script routine names that are invoked during operation as well as the variables that are dynamically set. Choosing this logging level on a large number of Manila files will greatly increase the time it takes to complete Manila file processing.
Level 4: Developer verbose level 2. Specify this logging level to view the script routine names that are invoked during operation as well as the dynamic and common variables that are set. Choosing this logging level on a large number of Manila files will drastically increase the time it takes to complete Manila file processing.
Level 5: Developer verbose level 3. Specify this logging level to view the script routine names that are invoked during operation, display all script variables. Additionally, this logging level will create a .\_debug folder which will contain a copy of the files that are normally removed during a script routine operation. Choosing this logging level on a large number of Manila files will significantly increase the time it takes to complete Manila file processing.
The following log files are generated during MANILATOOL command script processing:
ManilaTool_Log_#.##.##.txt
ManilaTool_FileCopyLog_#.##.##.txt
ManilaTool_LUAFilesLog_#.##.##.txt
ManilaTool_MNFLog_#.##.##.txt
ManilaTool_Mode9Log_#.##.##.txt
ManilaTool_NonLUAFilesLog_#.##.##.txt
Very nice work as always 12
Very nice work on this, I am around now, So I can start to help out more, haha
Forgive me for being an utter dumbass.
I've got your kitchen and was trying it out. However, what files do I need to drop into folder 01_manila? I've tried dropping just the manila file into it, the extracted *.luac scripts but I keep getting errors saying no files found.
Kindly point me in the right direction?
Thanks.
KF
kinnyfaifai said:
Forgive me for being an utter dumbass.
I've got your kitchen and was trying it out. However, what files do I need to drop into folder 01_manila? I've tried dropping just the manila file into it, the extracted *.luac scripts but I keep getting errors saying no files found.
Kindly point me in the right direction?
Thanks.
KF
Click to expand...
Click to collapse
Yes sure, That's the reason I included the m9editor as well, for it's abilty todifferentiate between different kinds of manila files. Copy only the Lua files (unchanged) to the 01_manila folder. There is a checkbox in the m9editor and if you will check it, it allows copying of multiple files. After that you are good to go and you can run the 01_Decompile.bat, 12
12aon said:
That's whats up!
@MRFERRARI23
What I think that going wrong with you is that your files are not called xxxxxxxx_manila make sure they are name that way or the cab creation script won't recognize them.
One other thing I noticed is that the path to the kitchen contains names with spaces like "mr vizziato". This can throw the kitchen off. To test this put the kitchen directly in you C:\ folder or in any rate not in the folder with spaces in in their names, and check back with me, 12
Click to expand...
Click to collapse
the 2 files I have in there now just look like this 18c01b6d_manila and 72ac571f_manila so I think they are in there right
as for running the program im doing so right from my desktop screen cause when I try to run it from c drive an I go to name the cab It doesnt give me that black pop screen it goes to this white page with info that doesnt allow me to do anything!
EDIT: how do I eliminate that space between mr vizziato?? I cleared the space by going to the start menu an going to my name but idk still nothing
12aon, Please, help me. I can`t decompilled file from manila 2.1 "53cc1e4f_manila",
if you can do this - help me please.
View attachment 53cc1e4f_manila.zip
Hey man, I am currently on a trip in the USA and I do not have the means to help you decompile at the moment. If you want it decompiled right away you can check out stupy's threads and tutorials (I have links in my first post) but I warn you this is kinda hard, good luck, 12
12aon said:
Hey man, I am currently on a trip in the USA and I do not have the means to help you decompile at the moment. If you want it decompiled right away you can check out stupy's threads and tutorials (I have links in my first post) but I warn you this is kinda hard, good luck, 12
Click to expand...
Click to collapse
Ok, I will wait )))), and when you will be able to do this?
Thanks, really useful that you did!
Man, this is seriously awesome
Extremely helpful tool, thank you very much
Related
Tutorial for ipaq hx2000 series rom cooking
Rom cooking tutorial for hx2000 series We will need: mamaich's tools:http://mamaich.uni.cc/wm_re/imgfs_tools.rar hx2000_tool: http://rapidshare.com/files/7435199/hx2000_Tool.rar.html PEID: http://rapidshare.com/files/10292835/PEiD.rar.html 1. Open the program hx2000_tool.exe 2. There are two buttons: unpack & pack. Push unpack and select the nbf file of your rom. From extraction we take the nk.nba in the same folder as the nbf file is. put this file in mamaich tools folder 3. Now we will use mamaich tools. Open a command prompt window and go to mamaich tools folder. Then run: prepare_imgfs nk.nba viewimgfs imgfs_raw_data.bin And now we have the Dump folder with the extracted rom's files. 4. With this commands: addfile(filename) delfile(filename) we can add or remove files. When we finish all changes that we want to do we use the command: buildimgfs 5. After run the command: make_imgfs.exe nk.nba 6. We execute again hx2000_tool.exe to pack the new rom.This time we select pack(we must move the nk.nba back to the folder of the nbf), we check the option Pool size and we select from the list the pool size. 7 Correct the crc For this we use the PEID program. Run PEID and select your rom's nbf file. Push the arrow on the lower right corner and select plugins -> crc32. Appears a small window.Enter the crc of our rom(for sp33752 the crc is E7A8B309) in collumn New crc. Check the "Overwrite mode" and press Fix. 8. The rom is ready for flash to the device. Note: These are translated from 4pda.ru( thanks to russian developers) and I haven't more information for you. More you can find in 4pda.ru
great Great!! I think this is instruction of how to delete and add files from and to a ROM. Dump a ROM out then delete/add files then pack it back... Great work translator and the Russ. Dancer69 and others... can you find me the info how to flash my hx2190b ? I keep getting mismatch SKU when I tried to flash ROM WM6 from Rom version 1.00.00H Thank you and waiting for your answers
I don't know if you already tried this but I read in 4pda.ru(from what I understand cause I don't know russian and I use wordlingo for translation and its not good) that someone with 2190b succeed to flash with this way: He run the ruu utility from sp33003 and when pass the check he replace the EPAKROM.nbf with the nbf from wm6(first rename it).
XIP extraction Additional information to your cooking tutorial : How-to extract XIP for HP2xxx RomMaster 2.3 is needed (with -b option) http://rapidshare.com/files/84961371/XIP_Tools.rar You need nk.nba (from step 2 of dancer_69's tutorial): > Rommaster.exe nk.nba -w 5 -b 0x00280000 -x -o xip.bin Create an empty directory named XIP (aka : > mkdir XIP) > Dumprom.exe xip.bin -5 -d XIP You wil found the XIP in XIP directory!
WM 6.5 rom cooking newbie Ok...I am trying to remove as much unneccesary stuff off the wm6.5 rom for my iPAQ hx2410 as possible like bubble breaker,etc. I dont really know what else I can remove witout hurting the whole system so I am wondering what else I can remove that can make it lighter...also I want to replace windows media player with core player but I only have the cab file for core player and when I try to build it, there is an error...How can I add new programs without these errors??? Also, I followed all the necessary steps posted above except the last part with the peid file i was supposed to download...It says it was a virus so I found an updated Peid but i didnt see the option to finish that last step..I am very very new at cooking so anything u can advise me about doing so would be helpful..THANK YOU IN ADVANCE!!!
Is there a semi-specific list of files which are safe to remove? I followed the steps and I have a dumped ROM, but now that I can play with the files, I don't know what to remove without destroying dependencies or killing the functionality.
The Windows Mobile Image Update System - Updating your ROM without losing data!
***THIS POST IS NOT COMPLETE, I WILL UPDATE MORE LATER*** First, an introduction: The Image Update system allows the OEM (us! ) to issue updates to a "Live" filesystem - without disrupting user data. This allows, for example, a buggy driver to be updated after the phone has been shipped, or a software package to be updated to the latest version, with minimal knowledge on the user's part. The system validates all updates against an internal list of certificates, and refuses the update if a match is not obtained. This system can also be used to deploy entirely new software to the device (such as support for another locale, input method editor, application support for a new feature the carrier is rolling out, etc.) Potential usage scenarios for this system A central server could be maintained for all SYS/OEM updates - each ROM Chef would need to maintain a list of original packages, any updated package(s), and download URL's for each updated package. The user would then receive these updates through the built-in AutoUpdate facility in Windows Mobile, which can check periodically, or on-demand. Each Chef could maintain seperate download servers from the update server to minimize server load. Alternatively, a chef could provide .cab.pkg updates in his or her ROM thread, on their own web site, etc., and the user could download these and install them at will. These packages can optionally be authenticated to be coming from the Chef, if the Chef wants to ensure updates are coming from him only. A public certificate could also be used to allow users to issue updates as well. The more technical Summary Image Update allows an OEM to issue updates to the OEM's, XIP, SYS, (possibly) Radio, or any combination of these. The update can be pushed to the user via a specially formatted SMS or by manual execution. There are at least 2 levels of certificate checking involved in the process, I believe against \SYS\Metadata\DefaultCerts.dat. The system reboots into the ULDR to apply the update, because the filesystem cannot be modified while actively mounted. The ULDR provides a minimal operating enviornment to facilitate this. How does a Chef need to prepare a ROM for Image Updating? The Chef would need to use a ROM Kitchen that leaves the .dsm and .rgu file structure intact (i.e. an "unprotected" ROM) - All .dsm's in this ROM would need to be properly formatted with Package Name, versioning info, etc. during the cooking process, in order to facilitate version checking, etc. Each .dsm would need to be signed with a certificate the Chef would use to validate the update as coming from him or her. (Alternatively a public certificate could be used like SDKCerts if the Chef chooses not to maintain direct control over updates, and allow other users to create updates as well) The Chef also needs to ensure not to Reduce the ULDR partition or remove it; this would cripple the Update Loader and prevent the Image Update system from functioning. The .cab.pkg format At the root of a package, the .dsm defines the Package structure (all files, registry entries, etc.) It contains version info, certificates, and other data. A ROM consists of a number of these packages, in an area of flash memory that is not user-writable. When someone wants to issue an update using the ImageUpdate system, they create a matching .dsm, same guid, with a newer version number, same internal package name, same processor ID, os version, etc., there is also a flag that can be marked as an update package or a new package - in this .dsm they define the files that will make up the new, updated package. Here they can add or remove files. One of the files defined by the package is optionally an .rgu, and this defines the registry entries associated with the package. Also optionally included is a provxml to facilitate file operations (copy/replace/delete/rename/etc.) and further registry or metabase operations. This collection of files is rolled up into a ".cab.pkg" archive by a program like cabarc. Once in a pkg.cab format, the package is signed. A .cab.pkg is referred to as a "Canonical Package" and multiple Canonical Packages can be rolled up into a single "Super Package" to facilitate updating multiple Packages at the same time. Inside this .cab.pkg is where the "MNGE" file format comes in to play. Essentially, this format is Microsoft's way of storing an XIP Module in the filesystem. (Their equivalent of our imageinfo.bin + s000, s001, etc.) - The "MNGE" format is simply a 4-byte MNGE header, followed by the imageinfo.bin, followed by the s00x sections attached to the end. When the Image Update system processes a file in this MNGE format, it is added to the IMGFS as an XIP Module. Deploying a .cab.pkg to a device Now there are several ways to deploy this package to the device, the primary way is an OMA-DM SMS message, which triggers the Image Update system to initiate a download from a server defined in the SMS message. The server can be either a normal HTTP server or a secure HTTPS server. The Image Update system will prompt the user to plug in the usb cable to download over the users home connection if the user has not already authorized the Auto Update system to utilize their GPRS data connection. Another way for a .cab.pkg update to be pushed to the system is simply through a file copy operation, be it ActiveSync, SD Card, Bluetooth, or otherwise. Once on the device, the .cab.pkg is executed by the user the same way a .cab would be. The Update Agent Initiated by either a completed download from push SMS, or user-executed, the "Update Agent" program (which is part of the \SYS\FWUPDATE Package) attempts to validate the Certificates, Package dependancies, and other info contained in the .cab.pkg and .dsm. Once validated, the "Update Agent" sets a flag that the bootloader reads, the flag is a boolean, off = boot into normal OS, on = boot into ULDR - so then the system reboots, the flag is read, and you load into... The Update Loader The "Update Loader" or "ULDR" which is a minimal kernel configuration, that provides just enough driver support to display info on screen, respond to user input, and read/write from the internal flash (NAND or NOR) From here the ULDR does further validation on the .cab.pkg, and applies it to the filesystem. If there are any modules in the package it dynamically relocates the memory map to make sure there are no overlaps. This is why it's important that reloc's not be removed from your ROM - ULDR will fail in this case. The End Result Once the ULDR has completed updating, the device is again rebooted, back into the full system, where the now-updated packages are now a part of the IMGFS, any updated files are processed (.rgu, .provxml, etc.) - The package is now a full part of the ROM. The new .dsm replaces the old .dsm (along with the other files in the package) and now a future update will be checked against this new package. If the update was pushed via OMA-DM SMS, or AutoUpdate, the device Pushes a notification to the OMA-DM server notifying it of the update status. What's missing right now to implent the ImageUpdate system? We need a Kitchen that's properly configured to allow us to create versioning info, proper package names, and insert this along with a certificate (or multiple certificates) into the .dsm's. We also need the Kitchen to be able to modify \SYS\Metadata\DefaultCerts.dat with the certificates used, so that it passes authentication. Alternatively the authentication checking could be patched out. (this one is easily doable at build-time) We need a program that can convert from a standard file to an MNGE format, so we can implement modules in our .cab.pkg's. (done it seems, thanks ervius!) We (optionally) need a properly configured web server that supports HTTP/HTTPS, can communicate the proper xml configuration data, and can be updated with new packages by Chefs. (this one's a ways off) We (optionally) need a program to convert from MNGE format to a standard file to facilitate extracting modules from .cab.pkg's. (working hard on that)
I've attached a .cab.pkg for NetCF2. Open up mscoree.dll in a hex editor, and check out the MNGE header. This file becomes a module once processed by the ImageUpdate system. Note that all the executables (.exe/.dll/.mui) that become modules contain this MNGE header. All executables that are inserted into ROM as files keep their normal MZ file header. The first major step here will be in being able to convert between MZ<-->MNGE freely NetCF2 is a well known package that can be found in any stock ROM, so with this we have a good baseline to work with. http://rapidshare.com/files/238295848/netcf.cab.pkg
--Reserved--
More Technical Specifications The basic ImageUpdate Layout consists of: [IPL] -- [MBR] -- [ULDR] -- [NK] -- [IMGFS] -- [TFAT] [IPL] is the "Initial Program Loader" that handles basic init functions and determines if control should be handed over to ULDR, or NK through a flag set by UpdateBin.exe - the IPL is not contained within a partition. The IPL is copied entirely to RAM and executed from there. IPL loads NK into RAM, and also handles any decompression of NK if it's required - some SmartPhone's ive seen use SRPX compression for the NK partition. Once NK is copied to RAM it is then executed. The IPL is handled seperately from the other parts of the operating system, and is not flashed during a normal update. [MBR] is the "Master Boot Record" and contains partition tables for the below components - it points to NK so when IPL loads the MBR, control is handed over to NK. The MBR contains information on where each partition is located on the flash (memory address), the size of the partition(s), and the type of each partition. The MBR is referenced from many components on the device such as IPL and ULDR in order to facilitate handoff of control between ULDR and NK. The MBR also serves as a boundry between the IPL which is not part of the regular partition structure, and the rest of the flash, which is part of the partitioning structure. [ULDR] is the "Update Loader" and provides a basic WinMo system so that file operations can be done on the IMGFS partition while it's unmounted. The Update Loader is even able to update itself - during operation it is loaded entirely to RAM. On development workstations the ULDR supports a KITL connection, that can be used to load updates directly from the "Release" folder. It seems it may be possible through this method to flash a new image to the device, possibly opening up the ability to flash to devices that have not yet been flashed with "HardSPL" [NK] is the "Kernel Partition" - or what we know as xip.bin - This component is updatable by ImageUpdate, and has a pre-defined "free space buffer" with room to grow, which defaults to 512KB. This partition holds only the kernel and drivers necessary to bring up the rest of the filesystem, from which the rest of WinMo is loaded. The Kernel Partition uses the same "Package" format as the IMGFS and is updatable in the same manner. [IMGFS] is the "System Partition" - running the Image Update filesystem. This component is updatable by ImageUpdate, and has a pre-defined "free space buffer" with room to grow, which defaults to 9.5MB. The IMGFS uses the "Package" format to further split its components. [TFAT] is the "Transaction Safe FAT File System" which is where all user-writable data goes. In most Device Designs, there's a single NOR or NAND chip used for flash. This is important as due to the typical layout above, both NK and IMGFS must have a pre-defined amount of free space - because TFAT is the last partition on the drive, and cannot be shifted once flashed to the device. It's possible for the partition layout to be setup differently (Partitions in different order) to help alleviate that problem. The ImageUpdate system would really shine on a device with 2 flash chips, a NOR chip dedicated to the ImageUpdate partition and a NAND chip dedicated to the TFAT, but no OEM has created such a design yet. Packages Package Types There are 3 different types of packages, Canonical, Update, and Super. Canonical contains the entire contents of the package. It is used for a first-time package install, and if there are any major updates to be issued that would require the complete package. The file extension is .cab.pkg Update contains a binary delta between a package already on the device, and the updated version of that package. In this manner the limited space is conserved (i.e. if a package change was a simple registry entry - no need to replace the 5mb of .dll and .exe in that package, just alter the .rgu with the new data. These packages are also referred to as "Delta" packages. The concept is similar to the unix implementation of Diff/Patch. The file extension is .cab.pku Super contains a collection of update and/or canonical packages. This is very useful when you are attempting to bring in a new package that has dependencies on other packages - rather than reboot into ULDR for each individual package in the proper dependency order, they can all be introduced at once. Every package contained inside a super package is validated, and if one fails, the remaining valid updates may still be applied, as dependencies allow. A super package is simply an un-compressed .cab containing other packages, renamed to .cab.pks The package layout itself is quite basic, it consists of a .dsm which contains all versioning info, association info, and dependency info. It also contains a list of all modules and files inside the package, and a certificate store of all approved certificates that will be allowed to update that package. Alongside the .dsm is an optional .rgu, which defines the registry settings associated with that package. Also optional is a .provxml file, which can be: mxip_[packagename]_[version].provxml, mxipcold_[packagename]_[version].provxml, or mxipupdate_[packagename]_[version].provxml. mxip and mxipcold are effectively treated the same, executed only on a cold boot. mxipupdate_ provxml's will be executed any time that package is updated, in addition to a cold boot - so if you are adding new .cab.pkgs and wish the .provxml to be executed immediately, it would need to be mxipupdate. This may not be desirable in some cases, such as when the provxml might override a user preference - in that case you would only want it to run on a cold boot, in order to avoid "strange" behavior on the user's side of things. There is a "shadow order" defined in the .dsm as well - this controls what "priority" .rgu's are compiled together into the device registry hive - a package that shadows another package will override any .rgu entries that shadowed package may contain. This is important to consider when utilizing .cab.pkgs in order to obtain your desired end registry. This shadow order also applies to provxmls inside the package - a package that shadows another package will override its provxml settings as well. The user registry hive is always top-most in the shadow order (except in the case of an mxipupdate_ provxml) - so any changes to .rgu registry settings will not override a user-changed registry setting. (example: You had foobar set to 5 in your initial deployment. At some point after flashing to his/her device, the user modified the registry, changing the value of foobar to 6. Your new .cab.pkg contains an .rgu changing foobar to 7 - on device, foobar will remain set to 6, as the user registry is higher in the shadow order than the .rgu) - in the case of an mxipupdate_ provxml these will override user settings.
So theoretically if we get this working we can apply updates to ANY portion of a rom via the .cab.pkg system. To XIP,SYS,or OEM without flashing a new rom. Essentially with this system working we would never need to flash again unless a major corruption occured? Ive always been confused as to why autoupdate was included in roms still. I guess this sheds some light on it. I know that several individuals have toyed with OTA updates in the past. This could make that and a whole lot more a reality.
It seems to me silly that we aren't exploiting the MS autoupdate feature already... I have no idea how to get it to work, but I'd love to have it working!
Yes, the .cab.pkg is the key to this whole thing, I already know how to redirect the Windows Mobile Auto Update client to look at another server, and i've studied the connection, it's a simple HTTPS connection, WinMo sends the server a manifest of all the .dsm's contained within your ROM, with version info, then the server checks against it's internal list of packages, if it finds an update, it pushes a URL to the device, which then triggers a download (it requests you to plug in the activesync cable if you've not checked the box to 'use my data connection for updates') - once the .cab.pkg is downloaded, it's checked against the signatures on the system, once verified the system reboots into the ULDR, and the update is applied. I've attached a NetCF2 package to my first post, I can't get it to deploy on my ROM (fails during validation step) but it contains the modules in MNGE format, if we can decipher that format there's a whole bunch of goodies that will become available... Also these packages can even be used to update the radio rom, it seems. So essentially everything but the Bootloader/ULDR can be updated with .cab.pkgs. It even looks like we can resize existing packages (i.e. remove files or modules from the ROM entirely) - this is something we can't do at all right now without a flash!
Da_G said: Yes, the .cab.pkg is the key to this whole thing, I already know how to redirect the Windows Mobile Auto Update client to look at another server, and i've studied the connection, it's a simple HTTPS connection, WinMo sends the server a manifest of all the .dsm's contained within your ROM, with version info, then the server checks against it's internal list of packages, if it finds an update, it pushes a URL to the device, which then triggers a download (it requests you to plug in the activesync cable if you've not checked the box to 'use my data connection for updates') - once the .cab.pkg is downloaded, it's checked against the signatures on the system, once verified the system reboots into the ULDR, and the update is applied. I've attached a NetCF2 package to my first post, I can't get it to deploy on my ROM (fails during validation step) but it contains the modules in MNGE format, if we can decipher that format there's a whole bunch of goodies that will become available... Click to expand... Click to collapse So in theory, there could be a central place for SYS/XIP packages, where as and when new XIP/SYS updates come out, they can be uploaded and pushed to every device? Have you worked out how to create the cab.pkg files, or is the one you've attached one taken from platform builder? Just a thought: Could the MNGE headered files not be replaced by files from a converted module, thus getting around the problem of what the hell the MNGE format does? Sure, we lose the ability to have modules instead of files, but it does bring more immediate benefits to your findings... EDIT: The MNGE headered files are smaller than the MZ equivalents... Are they simply a compressed version?
Yep, not pushed though as that needs to be triggered via an OMA-DM SMS message, and it's not practical for someone to maintain a database of all our numbers for such a purpose.. but easily though settings - autoupdate I am able to extract files from .cab.pkg with winrar and 7zip, not able to create them just yet.. working on that. This one came from a blue birdy. The MNGE headered files could indeed be replaced by a converted module, but in this case, there's a different reason for needing to convert from MNGE -> MZ, It appears to me as though the file size difference had to do with the PE executable headers that are missing..
Da_G said: Yep, not pushed though as that needs to be triggered via an OMA-DM SMS message, and it's not practical for someone to maintain a database of all our numbers for such a purpose.. but easily though settings - autoupdate I am able to extract files from .cab.pkg with winrar and 7zip, not able to create them just yet.. working on that. This one came from a blue birdy. The MNGE headered files could indeed be replaced by a converted module, but in this case, there's a different reason for needing to convert from MNGE -> MZ, It appears to me as though the file size difference had to do with the PE executable headers that are missing.. Click to expand... Click to collapse Oh right. It's not hard to just check for updates every so often. I just ran Cab2OEM on the cab.pkg files, and it extracts fine. So cab.pkg files are just cab files in terms of compression. Is that because there are more up to date MNGE file versions than the MZ equivalents? Is it just a case of replacing the file headers? *opens up hex edit*
Yep. the compression is your typical cab compression. That's why winrar and 7zip can open 'em and extract, but they don't support adding (i imagine cabarc would... Yes, there are more up to date MNGE file versions than the MZ equivalents. Unfortunately it doesn't look quite as simple as a simple hex copypasta, not terribly much more difficult though.
Da_G said: Yep. the compression is your typical cab compression. That's why winrar and 7zip can open 'em and extract, but they don't support adding (i imagine cabarc would... Yes, there are more up to date MNGE file versions than the MZ equivalents. Unfortunately it doesn't look quite as simple as a simple hex copypasta, not terribly much more difficult though. Click to expand... Click to collapse Where are you getting your MNGE files from? Or does your blue birdy wish to remain anonymous? EDIT: Looking at the hex, apart from the file header, the main difference seems to be that the whitespace has been removed in the MNGE version...
l3v5y said: Where are you getting your MNGE files from? Or does your blue birdy wish to remain anonymous? Click to expand... Click to collapse Do you know what a "hint" is ? I'd say quit asking... If he wanted to say who the birdy was, he would. Thank you!
Da_G said: Yep. the compression is your typical cab compression. That's why winrar and 7zip can open 'em and extract, but they don't support adding (i imagine cabarc would... Yes, there are more up to date MNGE file versions than the MZ equivalents. Unfortunately it doesn't look quite as simple as a simple hex copypasta, not terribly much more difficult though. Click to expand... Click to collapse put cabarc.exe intoa folder, then create a new subfolder called "package", put inside all files you need for package (dsm and rgu also!) open in cabarc.exe root folder a dos prompt and write: cabarc.exe N new_pack.cab. pkg package\*.* some seconds and you'll have the .pkg file ready, but nothing I know on how to install by the rom!
Thanks for the input ervius! Installing into the ROM is simple, .cab.pkg is treated similar to a .cab by Windows Mobile, simply copying to device and clicking on it in file explorer allows you to install - device will authenticate signature, then do some further checking (i think checking on current packages in device by .dsm) - then once validated reboot into ULDR to apply update.
ervius said: put cabarc.exe intoa folder, then create a new subfolder called "package", put inside all files you need for package (dsm and rgu also!) open in cabarc.exe root folder a dos prompt and write: cabarc.exe N new_pack.cab. pkg package\*.* some seconds and you'll have the .pkg file ready, but nothing I know on how to install by the rom! Click to expand... Click to collapse for posted netcf example, the optimum is: cabarc.exe - 20 N new_pack.cab. pkg package\*.* so, header (-s 20 reserve space for sign!), is same size, but how and with , sign it, I don't know! Da_G said: Thanks for the input ervius! Installing into the ROM is simple, .cab.pkg is treated similar to a .cab by Windows Mobile, simply copying to device and clicking on it in file explorer allows you to install - device will authenticate signature, then do some further checking (i think checking on current packages in device by .dsm) - then once validated reboot into ULDR to apply update. Click to expand... Click to collapse shure, but now maybe we have to fight against right sign code!?!? bye!
Yes, I think the ROM will need be cooked with additional certs, in \SYS\Metadata\DefaultCerts.dat - these appear to be the certs that are being checked against. So we can replace with SDKCerts, sign .cab.pkgs with that, should be good!
Da_G said: Yes, I think the ROM will need be cooked with additional certs, in \SYS\Metadata\DefaultCerts.dat - these appear to be the certs that are being checked against. So we can replace with SDKCerts, sign .cab.pkgs with that, should be good! Click to expand... Click to collapse ok, go to work then, I ', yet thiniing about oldstyle buildos with this all new features of visualkitchen without platformrebuilder if someone wants use oldstyle (maybe I'm at my goal!)
ervius said: ok, go to work then, I ', yet thiniing about oldstyle buildos with this all new features of visualkitchen without platformrebuilder if someone wants use oldstyle (maybe I'm at my goal!) Click to expand... Click to collapse Can we not look at removing the signing check the same way cmonex did for the kernel? Or is that the same signing check? Just so I am getting this right? I could cook a ROM with a custom DaveShaw https update server IP and then provide automatic updates to my ROM, bug fixes, new build release, normal CABs, etc. all using Windows Update from my website?? That would be damn useful, no more re-flashes Dave
probably to create MNGE from module folder we just need copy /b imageinfo.bin + S000 + S001 + ... module.dll and add MNGE header to the beginning of the file. but maybe i am wrong and this will not work in all cases. at least when i converted in this way dll module from 21725 to MNGE and compared it to the same file which was originally in MNGE format, there were 0 differences.
built in htc [FM TRANSMITTER] dev needed.
this is an older tutorial i found for the evo way back. it needs to be updated.. this could possibly work on other android htc phones to that have the fm transmit capability.... the evos Broadcom chip has a built in fm receiver and also a transmitter. according to some threads and diagrams ive seen the transmitter does have a power source, it just doesnt have and software code to actually work. like hdmi the hardware was there but there was no code set up, therefore we didnt have full hdmi out. it had to be built from scratch. the hardware for the fm transmitter is there we just need some one to build the code for it. some one please take this on!! This tutorial was originally posted in > android development and hacking > android software development. i am reposting it here in the evo forums for guidelines its a nice tutorial but its old. i think it was for android 2.0 ive followed the tutorial but i couldnt get it working, and i by no means have the experience to switch things up and get it working. [TUTORIAL] Reverse engineering HTC FM Radio for noobs (on EVO 4G) Okay, I'm writing this because I want to help any other newbies trying to learn how to reverse engineer. The technical details involved in this are extremely daunting, so the purpose of this tutorial is to first explain in layman terms exactly what you're trying to accomplish and what to expect. Then we'll go over the details. That way you're not completely blind going into this. I'm fairly new to the scene, so I'm not as knowledgeable as everyone else. If you see any errors in my post, let me know so I can change. I'm going to assume you know a little bit of Java, can find your way around a computer, and know nothing about Android. The techniques used should work with other Android phones. For this tutorial I'm using Windows 7, Cygwin, and my stock (not rooted) EVO 4G mobile phone. The FM tuner for the Evo is run by a Broadcom chip: BCM4329. This chip is pretty amazing in that it does wireless, bluetooth, and it has an FM receiver/transmitter. We're interested in the FM receiver / transmitter. Now, all android phones are based on a Linux kernel. Basically they're Linux running computers. The Android operating system is then installed onto the linux system. Every app is then run off of Android. Android is based on Java but it is not a Java system. It uses a virtual machine called Dalvik. Google did this to get around licensing issues with Sun Microsystems. So they pretty much invented their own machine language (called byte code) for the Java language. This makes things complicated for the reverse engineer because from what I've read, once Java is converted into this machine language or byte code, it can't be converted back. So let's rehash. If you were programming strictly in Java, you would see these extensions: Java source code = .java Compiled Java source code = Java byte code = .class Compressed file to package your program = .jar (Java Archive) But since you're programming in Android and Dalvik, you will see these: Java source code = .java Compiled Java source code = Dalvik byte code = .dex Compressed file to package your program = .apk (I haven't mentioned this, but HTC further Optimizes their .dex code) Optimized Dalvik byte code = .odex I'm writing all of these down because it's very easy to get confused with all of the extensions. (for me at least!). remember how I said once you go dex, you can't go back to java? That's where JesusFreke comes in. He's a senior member of XDA, and he created "baksmali" and "smali", two programs that can convert the Dalvik code back into a human readable format. These files have extensions of .smali Decompiled Dalvik byte code = .smali But what can you do with .smali files? That's where this other senior member, brut.all comes in: He developed apktool. apktool takes JesusFreke's work to the next level. This program in conjunction with NetBeans, actually lets you trace through any program using the .smali code taken from JesusFreke's programs! apktool does this by converting those .smali files into "fake" .java files that can be used by the NetBeans (program that compiles and makes java programs) IDE. I say "fake" because apktool embeds the .smali code into java files as comments. However, once you attach a debugger to NetBeans, you'll see that the debugger will follow line by line every execution statement found in the smali code! So...... you can take the program you want, plug it into Net Beans using a debugger (using the default ddms command provided by Android SDK), and you can trace everything you do in the program. I have it connected to my phone, so whenever I push a button while running my HTC FMRadio app or unplug my headphones,I see the corresponding response to the HTCFMRadio code I have loaded in NetBeans. I can now see in real-time how the program operates from my own interactions... JAM. Technical Aspects: How to get from ground zero to tracing HTCFMRadio? 1.) Download Android SDK - Go to google development site and follow instructions: Make sure to download the latest Java JDK. Once that is installed, download NetBeans 6.8. Unfortunately, smali debugging does not work with the lastest versions of NetBeans. Download the "Java SE" version for minimal space http://netbeans.org/downloads/6.8/index.html You can follow the rest of Google walkthrough and download Eclipse and ADT plugin, but it's not pertinent to this. You're going to be using adb and ddms from the android SDK extensively, so make sure the path for </android SDK/tools> is included in the PATH variable in your ENVIRONMENT SETTINGS. To get here, right click My computer, click properties, Advanced Settings, ENVIRONMENT SETTINGS. 2.) Search for 7z and download it. It is an awesome and free compression tool that will be extremely useful. It can be used to "unzip" .jar, .apk, and other compressed formats. 3.) Get the Radio app. You can do this by going to "shipped-roms" website, downloading the latest Supersonic image, and following the directions in the unlockr tutorial for HTC kitchens at the unlockr website... (once you have extracted the files from the image, you can look in the system/app and system/framework directories to get the files listed below) or: you can pull the following files from your phone: Using the command prompt type (and with phone plugged in, and with USB debugging enabled on phone): adb pull /system/app/HtcFMRadio.odex adb pull /system/app/HtcFMRadio.apk adb pull /system/framework ./framework This will put HtcFMRadio.odex and HtcFMRadio.apk in the current directory and create a framework directory with more files. A couple of the files in the framework are needed for the HtcFMRadio app, but for simplicity, we're just going to pull the whole directory. Now that we have the files, we have to make a few changes to make the app installable and to be viewable by the debugger. To do this we have to decompile the .odex format into a human readable format we can edit. That brings us to: 3.) Download baksmali and smali from Project Hosting on Google Code (google search smali). Usually an Android application is made up of one file, an apk file. Inside the apk file is an AndroidManifest.xml file, a classes.dex file (compiled Java code for the program), and other folders. The other folders contain either graphics or other .xml files that tell the program how it should look to the user. We don't have to worry about those for now. This is important because APKTOOL only opens programs set up this way. But wait up? We didn't download one .apk file, we downloaded an .apk file and an .odex file! What gives? Well, if you right click the apk file and open it (using 7z), you'll see that it's missing the classes.dex file. The dex file for the app is actually the HtcFMRadio.odex file we downloaded. So, to make this system app more like a nominal app, we have to find a way to convert the HtcFMRadio.odex to a classes.dex file. That's easy with baksmali and smali! Once you download goto command prompt and type: java -jar baksmali-<version>.jar -d framework -x HtcFMRadio.odex (Remember to match baksmali-<version>.jar with the filename of baksmali you downloaded) If done correctly, you should see a newly created \out directory This creates an out\com\htc\fm directory with many .smali files. Now let's reverse the process and put it back as a dex file. Type at command prompt: java -jar smali-<version>.jar out -o classes.dex If done correctly you'll see a newly created classes.dex. now, right click on HtcFMRadio.apk (select 7z and open). Drag classes.dex into the file. Say yes to the prompt. Now you have a normal apk file APKTOOL can read! 4.) Download APKTOOL from Project Hosting on Google Code and the helper apps for your OS. (If you're extracting files for windows OS you should have apktool.bat and aapt.exe). Extract (again using 7z, don't you love this program?) apktool.jar (keep it as a jar file, don't extract the stuff inside of it), apktool.bat, and aapt.exe to the directory you're working on. To make things neat, you can also delete HtcFMRadio.odex (you don't need it anymore) and classes.dex (make sure you put it in the HtcFMRadio.apk file first!) If this is the first time you're using apktool, then you have to install the htc framework so apktool can baksmali the Radio app. You only have to do this once: apktool if ./framework/com.htc.resources.apk Alright, at the command prompt: apktool d -d HtcFMRadio.apk This extracts the contents of HtcFMRadio.apk and places them in the HtcFMRadio directory. However, there are two major differences between this content and the content created in step 3. If you go into the smali directory you'll see that instead of .smali files, you'll see .java files. And if you go back and edit the AndroidManifest.xml file, you will also see that it's in text! Android applications convert their xml files to binary format. Now that APKTOOL has converted everything to an IDE friendly format, we can use NetBeans to edit everything. The first thing we're going to do is edit AndroidManifest.xml (using notepad) and add the following: android:debuggable="true" to the Application tag. IT should now look like this: <application android:theme="@android:style/Theme.Black.NoTitleBar" android:label="@string/fm_app_name" android:icon="@drawable/fm_radio" android:taskAffinity="android.task.fmradio" android:description="@string/htc_corp" android:allowTaskReparenting="true" android:debuggable="true"> This permission lets the debugger watch the program while it's running on the phone. We are going to run into two problems if we try to install this program. One is that Android doesn't let you install more than one copy of a system app. The second issue is that if we change the signature of our system app, then we'll have to change the signatures of our other system apps as well! Ahh.... So, to get around that, we're going to trick Android into thinking we have a completely new program. We're going to do that by renaming the com.htc.fm class to com.htc.modradio class. Next step: 5.) Cygwin (or Linux virtual machine) The easiest way that I can think of to replace strings in multiple files is by using linux. You can most definitely do it in WIndows, but I dont know how. If you let me know how, I can put it in this tutorial. (update: you can use Notepad++ to easily find/replace strings in multiple files for Windows. You still, however, want to download Cygwin if you're going to develop with Android-NDK.) For now, just search for Cygwin (Cygwin is a program that lets you run Linux commands from a command prompt using your Windows directories), and install it. Make sure to have the Perl option selected. You'll need Perl to make the following commands work. Once you get Cygwin up and running cd <to your HtcFMRadio directory> in my case it's cd /cygdrive/c/Users/Jerry/Desktop/HtcFMRadio now type the following commands in this order: this command changes all occurances of htc/fm to htc/modradio in your xml and .java files. find ./ -type f | xargs perl -pi -e 's/htc\/fm/htc\/modradio/g' this command changes all occurances of htc.fm to htc.modradio find ./ -type f | xargs perl -pi -e 's/htc.fm/htc.modradio/g' If you don't follow this order, your source code will get messed up. If using cygwin, a bunch of .bak files will be created. Using windows search, find all .bak files in your HtcFMRadio directory, then select them all and delete them (Make sure they are only files with .bak!) Now just rename the fm directory to modradio. It is located in HtcFMRadio/smali/com/htc Now go to your windows command prompt and type: apktool b -d .\HtcFMRadio modradio.apk Now sign and install modradio.apk on your phone. adb install modradio.apk If you have never signed before, then you need to use keytool and jarsigner. These two files are in your JDK directory, so make sure you include your JDK directory in the PATH variable of your ENVIRONMENT SETTINGS. (To get here, right click on My Computer, click Properties, Advanced Settings, Environment Variables. Once you make change, open up a new COMMAND prompt to see changes). cd to the directory which has modradio.apk now type: keytool -genkeypair Answer all questions, then use the same password for all password prompts. Next type: jarsigner -verbose modradio.apk mykey Type in the password you created in the above step. Your apk should now be signed. Next install: adb install modradio.apk Success! 6.) Testing the app on phone Go to your phone and you'll now see a new FMRadio icon next to your first. Click on it and watch it open. It should now be able to play music. Keep it open. 7.) Using Netbeans Go into HtcFMRadio and delete the build directory created by APKTOOL. Now open up Net Beans and click on File, New Project, Select Java Project with Existing Sources, click on Next Select HtcFMRadio directory for Project Folder, rename Project Name to whatever you want. Let's type in ModRadio. click on Next Next to "Source Package Folders" click on "Add Folder" and select the smali directory. Click Finish. For a quick tutorial by Brut.all, search APKTOOL in youtube and click on: Apktool Demo 2 - Smali improvements Right click on Libraries. Click on "Add Jar / Folder". You want to add Android.Jar. Since I have Android 2.1 loaded I went to /platforms/android-7 located in my android SDK directory. Your project is now ready for editting! 8.) Running the Debugger to trace through program. Next go back to Windows command prompt and type ddms. This runs the Dalvik Debug Monitor. A window should open up. In the left hand side you should see com.htc.modradio. That's our app! To the right you're going to see 2 numbers, you're interested in the one to the right, 4 cells away from com.htc.modradio. This number is a port number, and you're going to use it to communicate with NetBeans. (In my case it is 8603) Go back to NetBeans and click on Debug, Attach Debugger. In the host field type: localhost In the Port field: type in the second number you saw. (8603) If everything is working you'll see a bug appear next to com.htc.modradio in the Dalvik Debug Monitor. Look at the bottom bar of NetBeans for feedback. If you get errors make sure the numbers match, or try port 8700 and make sure you select com.htc.modradio in the Dalvik Debug Monitor. Port 8700 is the default port used for whatever program you select in Dalvik Debug Monitor. 9.) Setting a breakpoint I'm making this a seperate step because it is completely arbitrary. When creating a break point be sure to follow this rule: You must select line with some instruction, you can't set breakpoint on lines starting with ".", ":" or "#". Rather than looking for a spot to breakpoint, though, I'll tell you where to put one so you can quickly see how the debugger traces through the code. You aren't "REQUIRED" to do the next step, but if you want to trace you have to put a breakpoint somewhere. In Net Beans click on the Project tab, click on Source Packages, com.htc.modradio, and then doubleclick on BroadcomFMTuner.java We're going to insert a breakpoint. Scroll down to line 3226 and on your keyboard press: CTRL-SHIFT-F8, select line in dropdown box and hit ok. (To keep it simple, I usually look for "invoke" instructions to set breakpoints at) Now go to your phone and click on the physical "back" button on your phone. This will clear the radio,(you should still be able to listen to music). Drag your status bar down. You should see a radio icon. Click on it again. The radio backgroudn will appear, but you wont' see any text or anything. Now go back to your netbeans application. You should now see debug options highlighted! Click on Step Over (F8) to step through! { "lightbox_close": "Close", "lightbox_next": "Next", "lightbox_previous": "Previous", "lightbox_error": "The requested content cannot be loaded. Please try again later.", "lightbox_start_slideshow": "Start slideshow", "lightbox_stop_slideshow": "Stop slideshow", "lightbox_full_screen": "Full screen", "lightbox_thumbnails": "Thumbnails", "lightbox_download": "Download", "lightbox_share": "Share", "lightbox_zoom": "Zoom", "lightbox_new_window": "New window", "lightbox_toggle_sidebar": "Toggle sidebar" } i found a few things. http://pdf.eccn.com/pdfs/Datasheets/Broadcom/BCM4329.pdf http://www.broadcom.com/products/Bluetooth/Bluetooth-RF-Silicon-and-Software-Solutions/BCM4329
Mad tutorial man! You have just opened up my world even more to Android. Thank you heaps. BTW your freakin signature got me good damn you! I thought someone had hacked my PC LOL
Any chance that this will work with JB?. Can you post app?. Thanks.
Make Your Own Custom Keyboard Layout [For Noobs]
READ THIS ENTIRE GUIDE BEFORE ASKING QUESTIONS. READ THIS ENTIRE GUIDE BEFORE ATTEMPTING ANYTHING. READ THIS ENTIRE GUIDE FOR ALL THE HELPFUL INFORMATION CONTAINED IN IT. READ THIS ENTIRE GUIDE EVEN IF YOU KNOW WHAT YOU ARE DOING. This guide is for anyone that would like to build their own custom keyboard with a customized layout with customized keys (hit one keyboard button and your entire email is filled in for you automatically). This method of hacking should work with other .apk files for similar endeavors. With this guide you should be able to create a custom keyboard based on the gingerbread keyboard. Read this entire guide before asking any questions. I have added information on the many things that have personally caused me errors. If you have problems with the program itself, post here asking for help, ask on the android developers's IRC channel, or read the FAQs posted about the different programs that must be used. this is a windows 7 based guide; the only differences between W7 and other OS's is minor path changes and downloads (I don't think that android commander is available on Mac OSX) Things that are required: very basic commandline experience APKtool Signapk android SDK installed and working (install all available packages if you do not know how to set up an emulator) android commander -or- knowledge of how to install a custom .apk on your device notepad -or- your favorite code editor lots of debugging time, patience an ability to navigate the above programs **Common Commands** 1. apktool b <NAME OF DECOMPILED KEYBOARD FOLDER> <PATH LEADING TO YOUR FOLDER CONTAINING SIGNAPK (NAME THE FILE), READY TO COMPILE FOLDER> 2. java -jar signapk.jar testkey.x509.pem testkey.pk8 <NAMEOFFILE FROM ABOVE> <PATH TO YOUR ANDROID SDK TOOLS FOLDER> 3. adb install testsign.apk #Protip: in Windows 7 (Vista?) hold the shift button as you right click in a folder to open a commandprompt in that directory Command 1. is to be run from the directory holding your apk folder (do not go inside the decompiled apk folder; if you can see Android Manifest you've gone too far). The command will place the compiled apk folder into your signapk folder assuming you have set up the above commands correctly. As a side note, the compiled apk will be called "test.apk". If you want to decompile (go from an apk to "undone" folder just use "apktool d <NAME OF APK> <OUTPUT FOLDER NAME INCLUDING ITS DESIRED DIRECTORY {EX: c:\android-sdk\keyboard\gingerbredkeyboard}> Command 2. will sign the apk file called "test.apk" and save the result in your tools folder inside your android sdk folder. Command 3. will install the apk into your running emulator. This is optional since you can from here install the file onto your device to test things out. However, I highly recommend using the emulator because it is easier to deal with. This command will fail if your emulator has been left alone for a little while. Just do some sort of action in your emulated device to "wake it up" so that the command will find the running emulator. After you install the apk, you may need to delete the old apk before you install a newer version that you have created. ----- Keyboard stuff When you decompile the keyboard file, you'll see a bunch of folders, the main folders that you'll want to focus on are inside res\xml and res\values (res\drawable-Xdpi if you want to make a complete theme with new images). From here the xml files governing the keyboard layout should be readable by any xml editor (notepad). Some of my notes will be written below so you can use what I've discovered to generate your own code. As a quick note, the cases of letters count, you must be perfect in your xml code. The xml files are all named with self explanatory names, just look down the list at the names and you should find what you're looking for. values and xml folders with letters after it mean that those are aspects that are only going to work for a specific language; if you want to make global commands for any language on the keyboard use the xml files that do not have a suffix. From here you can be creative and hijack a language that you won't normally use and use it as your own personal keyboard with special keys and whatnot (a keyboard just for accented letters? personal word shortcuts?) code examples: android:keyLabel="Hi" this line is what will show up on the keyboard key in question, as above, "Hi" will be printed on this key androidopupCharacters="★" this line is what will show up when you hold down the key in question, you will get options for ★ with this code; do not use commas to separate symbols/letters, each individual character will be it's own separate key android:keyOutputText=";] " self explanitory, anything contained inside the quotes will be printed when the key is pressed, leave a space like I did after smilies so that you dont' have to hit the spacebar after using this key; see exceptions below droid:keyEdgeFlags="left" is used in the <key> entry of anything on the left "edge" of a <row> droid:keyEdgeFlags="right" same as above, but used on the rightmost key EXCEPTIONS: Certain characters are used in coding, if you don't enter them a special way, you will receive errors in your code when compiling or the key will simply not work. In order to use commands that "print" text with exceptions in them, prefix the exception with a "\". For example: android:keyOutputText="\@" will print the character "@". A list of known exceptions are listed below, there may be others. Special, special exceptions also exist where even prefixing it causes coding problems, in these cases, use its "name" in place of its actual character. For example: the ampersand character '&", you must use the code associated with it; see the "popup_punctuation.xml" file for some of these exceptions. There may be more exceptions that I have not come across. If you're having problems with your keyboard and cannot figure out why your key is not showing up correctly, try to treat it as an exception. Characters that are exceptions: # @ ? " IMPORTANT EXCEPTION: I couldn't get the popup_comma.xml file to work with the above exceptions rule or with the keyoutputtext code Putting it all together: <Key android:keyLabel="\@G!" android:keyOutputText="cheval.de.jeanvaljean\@gmail.com" android:keyEdgeFlags="left"/> The above will draw a key that's labeled "@G!" that yields "[email protected]" that is also the leftmost tag in a given row. Personally, I have added similar code to the above so that I have keys for the handles "@gmail.com" and "@yahoo.com" (along with my personal email so I never have to type it out all the way ever again) to the period key on the keyboard (in xml "popup_punctuation.xml"). I have also tweaked the smilies on the enter key to my own personal smilies. Assuming you've read the above and have some minimal xml experience you can figure out the rest for yourself. There are many other things that I have left out code-wise that I found to be extremely easy to figure out just by browsing the source code. As a personal tip to you, I recommend highly that you use the emulator as it is far easier than pushing files to your phone, deleting them, blah blah blah. --- Have fun and good luck =]
[XAP] Any application launcher
There is simple, but usefull tool, able to launch any application, script, or other shell directive, by own tile icon tapping. Using: 1. Rename UniLaunch7.xap to YourOwnName.zip 2. Edit zipped WMAppManifest.xml file: - replace all occurences of string "UniLaunch7" by "YourOwnName" - replace line "\Windows\calc7.exe" by your wanted exe, batch, or Mortscript full filepath (see my other threads about console and Mortscript). 3. If you want, replace ApplicationIcon.png by your own icon picture. 4. Repack zip and rename YourOwnName.zip to YourOwnName.xap 5. Deploy it to device Notes: Using batch with LaunUri.exe calling you can simply make any "undocumented" system CPL shortcut as internet sharing (LaunchUri app://5B04B775-356B-4AA0-AAF8-6491FFEA5629/_default), GPS enabling (LaunchUri app://5b04b775-356b-4aa0-aaf8-6491ffea5642/_default) etc. Examples are in attached zip (enable scripting first by HaRET Console 7 or another batch interpreter enabling tool e.g. PocketCMD7 registered to batch as cmd /C CALL "%1" ). Using batch with registry changing you can make simply native installator or profile changer. For example simple scripts RingingOffVibrateOn.bat, RingingOffVibrateOff.bat and RingingOnVibrateOn.bat is tiled in my device. You can see differences between UniLaunch7.xap and KeyboardCPL.xap (unzip booth) to understand tutorial. First one launches Calcullator, second launches Keyboard CLP. I will prepare authomatical on-device launchers creator, probably as feature of Phone Commander.
More information on the benefits and advantages. Or do explained in video