Related
Special Thanks
Abusalza (for the most initial start off guide)
Cmonex (for the “MOST” important finishing touches)
!Aman! (for all the testing and Hex edit helping)
Noonski (for being the inspiration to keep going )
Ervius (for developing the kitchen tool to perform all the operations)
In this forum there are many many tools from experts and likes for porting XIP, rebuilding dumped ROMs etc. This threads aims at showing or sharing what goes in the background of these automated tools and also aims at answering all the many unanswered questions about various factors of ROM cooking / editing I have come across in this forum
Suggestions / comments always welcome to make these tutorials even better
Index of Tutorials
Manual XIP Porting Guide: CLICK HERE
XIP Porting Updates from members: CLICK HERE
XIP Porting for Himalaya devices & others (Nokser): CLICK HERE
Misc XIP Updates: CLICK HERE
PagePool Changing Guide (for Diamond & Raphael): CLICK HERE
Gain More Storage Memory (Increase imgfs size) Guide: CLICK HERE
ULDR Partition Size Reduction Guide: CLICK HERE
MBR and MSFLSH50 Regions Screenshots: CLICK HERE
Gain More Storage Memory (compress imgfs) with LZX algorithm: CLICK HERE
Get High File System Index (!Aman!): CLICK HERE
Ervius's GUI kitchen thread to perform all operations, Noonski's amazing RunCC & AutoRun & SDAutorun tutorial thread
Ervius's post on patching nk.exe to change the EndRam address for more available RAM in device (original credits to cmonex )
Da_G's amazing new initiative to utilise the ULDR partition to upgrade ROM without re-flash
All the above guides and updates are compiled in pdf file also for offline reading, attached in this post as All Guides.zip
The imgfs Gain.zip is actually the 5th guide with pictorial seperatly put up for members who would want to refer only to that process
The Pictorial.zip is the 7th picture reference for offline reading
Donations for this hard work and research are much appreciated. Below are the links whom you may choose to provide those to
Donation to Abusalza, Donation to Cmonex, Donation to !Aman!, Donation to Ameet
Index of Threads (Manila related)
Ameet's Mode9 script editing ideas thread
l3v5y's tutorial thread for editing Manila files
NisseDILLIGAF's Manila Hash tool
Manual Full XIP Porting
Tools you need: (attached the tools in this thread for easy access)
HEX Calculator (recommended – HEX workshop (Not Free)), suggested Windows Calculator
XIPPort.exe
M’Reloc.exe
NBMerge.exe
Insert.exe
OS.nb.payload from 19965 build (shipped ROM)
Cup of nice strong Coffee (A Must)
Brief:
There are many different ways to port the XIP. Few mention of using the 723*.dsm for the build number, few others mention of using the coredll.dll module to have the latest build numbers. As my friends, Noonski and !Aman! always say “Only numbers are just eye wash, core system is what matters the most” Based on this as inspiration, I am posting this guide for manual XIP porting. A few places you may find colors in this guide, these are to visually link the data for easy understanding
The only files removed from the ported XIP are (these are removed to keep the new XIP within the original size):
osaxst0.dll + osaxst0.dll.imageinfo.txt
hd.dll + hd.dll.imageinfo.txt
bmui.nb0 + bmui.nb0.imageinfo.txt
Process:
Prepare OEMXip base
Dump your original XIP.bin (from 19965 build) with XIPPort.exe, and click “write maps” to get MAP.txt in the OUT folder
Open the MAP.txt and go through what you will need to achieve for a full port. I advice to keep this MAP.txt as a backup, just in case
Click “make pkgs” to get “OEMXipKernel” and “MSXipKernel” folders inside \Files and \Modules
Delete MSXipKernel folders from \Files and \Modules both
Now our base OUT folder is ready with OEMXipKernel
Prepare MSXip donor
Dump your donor XIP.bin (from 20758 build) with XIPPort.exe, and click “make pkgs” to get “MSXipKernel” folder inside \Files and \Modules
Delete osaxst0.dll + osaxst0.dll.imageinfo.txt, hd.dll + hd.dll.imageinfo.txt and bmui.nb0 + bmui.nb0.imageinfo.txt to get the new XIP within the original RAM size. If you don’t wish to delete these files, then you will need to increase the “physlast” in ROMHDR.txt. Process of which is not covered under this guide
Copy the MSXipKernel folders from \Files and \Modules both to the \Files and \Modules in the base OUT folder
Now our OUT folder is ready to be ported with the OEMXipKernel and MSXipKernel
Now to proceed with the reallocing you need to re open the packages which have been created. Open XIPPort.exe and click "undo" then click “realloc P” to re calculate the reallocation addresses. Then click “write maps” to get the new MAP.txt file
Open this MAP.txt and look in the o32_realaddr and e32_vbase addresses. Busenum.dll must be the last entry in both tables. Here you may find overlaps of the modules in a few or most places (seen as !!!!!!!!!!!!!!!!!!)
These are the overlaps which need to be taken care of by reallocating the modules in Initialized Data and Virtual Base addresses
You need to work our way up from the bottom of the list since the busenum.dll is reallocated at the last address of the memory
For example:
03f4c000 03fe3000 L00097000 Virtual base address of coredll.dll
03fe2000 03fe3000 L00001000 !!!!!!!!!!!!!!!!!!
03fe2000 03ff0000 L0000e000 Virtual base address of certmod.dll
03ff0000 03ffb000 L0000b000 Virtual base address of cachefilt.dll
03ffa000 03ffb000 L00001000 !!!!!!!!!!!!!!!!!!
03ffa000 04000000 L00006000 Virtual base address of busenum.dll
Meaning, e32_vbase address of cachefilt.dll is overlapping that of busenum.dll by 1000 (L00001000) Similarly e32_vbase address of coredll.dll is overlapping that of certmod.dll by 1000 (L00001000)
I recommend you use M’Reloc.exe for reallocating the addresses in imageinfo.bin and Notepad to reallocate the addresses in the corresponding imageinfo.txt files. Since the binaries (S000, S001...) must actually be relocated using M'Reloc, it is not enough to just adjust the values in the imageinfo.txt files
To calculate the revised addresses (in below example, the e32_vbase) of the overlapping module, open Hex Calculator. To do that you will need to know the e32_vsize of the overlapped module. To find that out open overlapped module (for e.g. cachefilt.dll) in M’Reloc.exe and see the e32_vsize (0000B000)
Now to correct the e32_vbase of cachefilt.dll, follow this calculation as a base (e32_vbase busenum.dll - e32_vsize cachefilt.dll = e32_vbase cachefilt.dll)
Meaning, (03FFA000 – B000 = 03FEF000) hence the correct e32_vbase address is 03FEF000
03ff0000 03ffb000 L0000b000 Virtual base address of cachefilt.dll
03ffa000 03ffb000 L00001000 !!!!!!!!!!!!!!!!!!
03ffa000 04000000 L00006000 Virtual base address of busenum.dll
Now since the cachefilt.dll is reallocated using the above calculation, the modules next in line above that will also have to be reallocated. Namely, certmod.dll (although not overlapping yet above the cachefilt.dll). To calculate the e32_vbase of certmod.dll you will need the revised e32_vbase address of cachefilt.dll which you got just now
I recommend writing down the e32_vbase, e32_vsize, o32_realaddr and o32_vsize of each module so it will be easier to calculate the correct addresses for reallocation)
Remember, you need to work our way up from the bottom of the list since the busenum.dll is reallocated at the last address of the memory
To reallocate the addresses for o32_realaddr, follow the above calculation, only this time replace the e32_vbase busenum.dll with o32_realaddr and e32_vsize with o32_vsize
Now open the corresponding imageinfo.txt file for each module and change the e32_vbase and o32_realaddr address values in the txt file of the values mentioned with V= and D=, seen for e.g. like this
Module name: cachefilt.dll
e32_vbase: V=03FEF000
o32[1].o32_realaddr: D=01FFE000
You will notice that the FLASHDRV.DLL module has the realaddr at 2 regions. Although I have not found a way to calculate the difference between both regions but I change the values as per Abusalza’s MAP.txt
o32[1].o32_realaddr: D=01FCC000
o32[3].o32_realaddr: D=01FD4000
Since the OEMXipKernel modules never change, I only correct values of the ported MSXipKernel modules
This is helpful if the MSXipKernel modules ported from donor ROMs are similar in the sizes. If not then you will need to do the calculation and correction of values
Once through with the address reallocation, open XIPPort.exe and click “realloc P” to re calculate the addresses for writing maps. It will show you errors regarding some regions, ignore those and click “write maps”. Open the new MAP.txt and recheck for (!!!!!!!!!!!!!!!!!!) If none found that means the XIP has been ported well
Now click “build xip_out.bin” to create the resulting XIP to be inserted into the ROM .payload file. Use this command for inserting the xip_out.bin into the .payload (presuming you already have the shipped OS.nb.payload file in the same working folder
insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00320000 -s 0x004C0000
Check these values with your device imgfs since in Diamond the XIP starts at 0x00320000 and the imgfs starts at 0x007A0000, but for some reason the imgfs signature in Diamond is at 0x007E0000
Build OS.nb for use in the ROM folder from the .payload you just updated with the new XIP. Please note these commands are for Diamond device. Please check with your device on the same before building
nbmerge.exe –kaiser OS.nb
Now put this OS.nb file in the ROM, put the boot.rgu from 19965 (shipped ROM) into the \ROM\XIP folder and do not include any of the OEMXipKernel or MSXipKernel folders in OEM & SYS folder while cooking. I observed for some reason, WinCeNls_WWE folder cannot be taken out of XIP and included in SYS. Device wont boot, so keep that in XIP (found a working solution by spocky12: Here (last quote)
Please note the insertion of xip_out.bin can also be done through XIPPort.exe directly
Before clicking “write xip_out.bin to:” replace the name “nk.nb” with “OS.nb.payload” and the address to “00320000” all without quotes
IMP: There may be chances that although the XIP is working fine, but the windows are seen as QVGA versions. The solution to that is either of the below
XIP & SYS of the same builds or
XIP and the OS\Gwes.exe from same build
Cook the new ROM with your favorite kitchen (whichever doesn’t do anything with the XIP) and use this OS.nb file as base template for the ROM with the new XIP
With this note, I hope this guide will serve many as a guiding light and answer many questions on manual full XIP porting. Happy porting
Members Porting Updates
This is where we showcase the updates on XIP porting provided by our kind forum members
Original quote - Cmonex
Code:
[COLOR=royalblue][B]Quote=ababrekar[/B] - Busenum.dll must be the last entry in both tables[/COLOR]
Actually the values are arbitary, even though Microsoft decided to place coredll.dll as the last entry, i.e. at the highest memory address, it doesn't really matter. So, the values are arbitrary, but of course only within limits: the addresses must be divisible by 0x1000 (pagesize of the platform), and they must be inside the memory range reserved for XIP. part of that is the dllfirst and dlllast values in ROMHDR.txt. The other part (the higher addresses, 0x03xxxxxx) are determined by the following way: IMGFS .VM tells you the limits for IMGFS memory range, and XIP is beyond that range. So, if your OS doesn't want to boot, you can check if IMGFS .VM is overlapping with XIP memory range as per your MAP.txt for xip and dump_memorymap.txt (or .VM folder, etc) for IMGFS.
For example if IMGFS ends at 0x03DE0000, then the higher part of your XIP must start later than 0x03DE0000. You can of course modify this to make more space for XIP
If xipport crashes on writing maps it means you definitely have some overlaps left in. So yes, best to work with the maps from the original XIPs and only use the final XIP map to verify you got everything right
[COLOR=red]Btw, XIPPort's insertion function was found buggy on one device once, but cannot remember the details. It wasn't my device, so just posting this as a possible warning[/COLOR]
Oh, same applies to ROMMaster.exe, it is buggy when you try to use that to extract the XIP some ROMs
[COLOR=royalblue][B]Quote=ababrekar[/B] - Few mention of using the 723*.dsm for the build number, few others mention of using the coredll.dll module to have the latest build numbers[/COLOR]
Btw, coredll.dll replacement only works for that pre-WM6.1
And a last tip for [B]debugging [/B]if your OS doesn't want to boot: if you already checked that the maps are all ok and IMGFS doesn't overlap, etc., then if you have a new enough HTC device (for example HTC Athena and later is new enough), then go to SPL using mtty or putty or qmat and there the "task 37" command (without the quotes) will show KITL log, with lots of debug messages, that can be very helpful. (first you must issue "task 32", for "task 37" to work) - this doesn't appear to work on some Raphaels
Original quote - cruzzmz
Code:
If porting for [B][COLOR=teal]Zinc[/COLOR][/B]. After finish with all the MReloc, you need to Hex the S000 of nk.exe in the MODULES folder. The value can be found in MAP.TXT under the Modules
[COLOR=royalblue][B]Quote=ababrekar[/B] - 802FAA9C - 802faaf0 L00000054 rom_00 header: dlls=01f901fd-02000000 phys=80180000-803dc4fa, 24 modules, 10 files, 2 copyentries ext=8018265c ram=803dd000-83c00000 cputype=000001c2[/COLOR]
Open S000 in ur fav hex editor, then go to [B]Offset 1658[/B]
Change the original value i.e: [COLOR=red][B]802FAA9C [/B][/COLOR]and Hex edit it to [COLOR=blue][B]9CAA2F80[/B][/COLOR]
Original quote - DupinBJK
Code:
The addresses on the 80xxxxxx range should be on a [B]WORD [/B]boundary - Divisible by [B]4[/B]
Original quote - spocky12 (how to move wincenls to IMGF from XIP)
Code:
This is related to BootPhase key in boot.rgu. [URL="http://msdn.microsoft.com/en-us/library/ms885267.aspx"]According to Microsoft[/URL]
If this value is 0, then related filesystem is loaded prior to initialization of locale. But for this to work, the filesystem has to be loaded in Autoload key, like this :
[B][COLOR=red][HKEY_LOCAL_MACHINE\System\StorageManager\AutoLoad\FLASHDRV][/COLOR][/B]
[B][COLOR=red] "DriverPath"="Drivers\\BuiltIn\\FLASHDRV"[/COLOR][/B]
[B][COLOR=red] "LoadFlags"=dword:1[/COLOR][/B]
[B][COLOR=red] "Order"=dword:0[/COLOR][/B]
[B][COLOR=red] "MountAsRoot"=dword:1[/COLOR][/B]
[B][COLOR=red] "MountAsBootable"=dword:1[/COLOR][/B]
[B][COLOR=red] "BootPhase"=dword:0[/COLOR][/B]
With this, autoload will regsiter access to the imgfs filesystem before wince.nls is loaded. Then, when it'll be required, if it's not present in xip, it should be found in imgfs
Here is where we showcase miscellanous updates on XIP porting / MBR / MSFLSH50 which doesnt fall under the above categories. These are the updates which are not harming the system in any ways if left as is. Yet just a know how or just in case
Removing modules from XIP: Original quote - Cmonex
Code:
You can always remove osaxst0.dll, osaxst1.dll, hd.dll, kd.dll, and also bmui.nb0 - the latter is just a SplashScreen saying your OS can't boot and reflash or something (I forget the exact text)
The other files are Kernel debuggers and similar, best to remove them, because it just takes up space and can also cause problems if you somehow manage to use the wrong versions of them. They are mapped directly to the Kernel memory space, and if your device uses a different range (i.e. you didn't keep your original debugger dlls), it will prevent the rom from booting
Also I found it's ok to remove (m)encfilt.dll and cachefilt (put them in IMGFS if you want them)
[I][B]Physlast [/B][/I]can be changed up to [I]ulramstart [/I]value without problems (of course not if you don't have enough space in the flash, but that's not really a real life possibility). Of course that also assumes we are not talking about some older devices that have the xip mapped to a different memory range than [I]ulramstart[/I]
You can move [I]ulramstart/ulramfree [/I]too if you relocate nk.exe data section (usually S002) with M'Reloc-nk. Also relocation is needed for any other modules (such as giisr.dll, on some non HTC devices) that have mappings similar to nk.exe (so they have a data section in the map that points into [I]ulramstart/ulramfree [/I]range). on HTC devices I didn't really see such modules so not a real problem usually
Increasing the free RAM (Part 1): Detailed explanation here by DupinBJK
Simple explaination for easy understanding: (the below values are from a sample MAP.txt and dump_memoryMaps.txt (View attachment Examples.zip)) for trying to explain what comes from where and the actual values may differ from your files
Code:
8019e9a4 - 8019e9f8 L00000054 rom_00 header: dlls=[COLOR=red]01f801fc[/COLOR]-[COLOR=black]02000000[/COLOR] phys=[COLOR=black]80000000[/COLOR]-[COLOR=blue]8030c7b3[/COLOR], 28 modules, 10 files, 1 copyentries ext=80002b4c ram=8030d000-83000000 cputype=000001c2
[COLOR=blue]8030c7b3 [/COLOR]- 8030c7b3 L00000000 End: highest physical address
The blue value that mentioned is the physlast value. In the dump_memoryMaps.txt, you will find:
Code:
01F7F000 - 01F7FFFF (4095 bytes): bthasplugin.dll
after which the dllfirst starts in MAP.txt with a difference of 1FD length and
Code:
03D66000 - 03D6FFFF (40959 bytes): bthasplugin.dll
after which the e32_vbase starts (03dcb000 - 03dd4000 L00009000 Virtual base address of wce_rex.DLL) in MAP.txt with a difference of 5B001 length
Increasing the free RAM (Part 2): by Ameet
Changed the size of ROM in G'Reloc from 83000000 to 83400000 and increased the ulRAMEnd to the same value (83400000) getting free RAM space of L0306C000 (I dont know how to translate this into the actual size in % or in bytes) but with the original of 83000000 the RAM space was L02C6C000
Having done this, I get about 62% free memory without TF3D and approx 54% free memory with TF3D at system start
Extracting the XIP from any ROM: Detailed explanation here by boggsie
More explaination about XIP processes & editing OS version on 1st splash screen: by FormerPalmOS
Code:
[B][COLOR=red]1) [/COLOR][/B]The Initial Program Loader copies the XIP partition from the FLASH to SRAM - in Diamond and Touch Pro there is a custom Samsung chip that includes both NAND FLASH and SRAM. The overall physical RAM space where this is loaded is also hard-coded - see below. The amount of RAM used is variable - this info comes from a header in the XIP section - basically how much RAM does the XIP need? What's left is what you get for program memory.
[B][COLOR=red]2) [/COLOR][/B]IPL executes a jump to a hard-coded address within the SRAM - this should be busenum.dll, which is why busenum.dll has to be at a specific physical and virtual memory location.
[COLOR=red][B]3) [/B][/COLOR]busenum.dll does its thing (not sure entirely what) but eventually calls nk.exe. nk.exe is the kernel. nk.exe loads the other modules, initializes the hardware (that's why nk.exe is device-specific), and initializes the filesystem and basic device drivers (again why those are device-specific).
[COLOR=red][B]4) [/B][/COLOR]Once this process has completed, the filesystem proceeds to load the imgfs filesystem and turn control over to the full OS.
The virtual memory map for WM consists of a number of slots. The memory management unit in the CPU translates virtual memory references into physical memory addresses. Every loaded dll or exe must occupy a portion of virtual memory for its code and will likely also use some of the available RAM for its data. The location within virtual memory where the code for a dll or exe is loaded is determined at load time unless the dll or exe is a module (everything in the XIP is a module) in which case the virtual memory location is specified during cooking. In the XIP, the location of the RAM used is also specified - the process of relocating a module in the XIP specifies the virtual memory location for the code and and data in the case of nk.exe, the physical RAM location.
There are four VM sections we care about (note - I'm taking some liberty here - these don't exactly correspond with what Microsoft refers to as a VM slot). Slot 0 runs from 0x00000000 to 0x01FC0000 (in the CDMA Touch Pro). The end of slot 0 is a function of the number of and size of the data regions for the DLL modules in the XIP. This number plus 0x1FC is stored in the ROM header (and can be examined in ROMHRD.txt) - it is referred to as dllfirst. This is also the slot 0 you see when you do G'Reloc.exe (the value in G'Reloc.exe is the last address of slot 0 plus one). These two must match!!! What the XIP uses must not overlap with what your ROM uses.
The next slot is the XIP DLL initialized data. This runs from dllfirst to dlllast. dlllast is fixed (in the Touch pro) at 0x02000000. The XIP DLL data sections are loaded starting at 0x02000000 and working backwards.
The next slot is again available for the OS and runs from dlllast to wherever the code in the XIP starts. You can see this in your XIP memory map - this again must match (the end of slot 1 in G'reloc.exe must match the first DLL virtual base address in your XIP - in mine this is 0x03DC0000). The XIP DLL and EXE code occupies from this virtual memory address to 0x03FFFFFF.
The OS will load DLLs and EXEs (other than XIP) into this slot starting at 0x03DC0000 and working backwards, then will move to the slot below 0x01FC0000. Recall, I'm using my numbers here. Any modules in the ROM will have their virtual memory slot and address pre-assigned. Any non-module DLL or EXE will be relocated to an available slot and VM address at load (this is why modules load quicker).
So in summary, my VM map looks like this:
0x00000000 - 0x01FC0000 - OS available (G'Reloc.exe slot 0)
0x01FC0000 - 0x01FFFFFF - XIP data
0x02000000 - 0x03DC0000 - OS available (G'Reloc.exe slot 1)
0x03DC0000 - 0x3FFFFFFF - XIP modules code
The actual physical XIP RAM address starts at 0x80000000 in the Touch Pro (this is physfirst in the ROMHDR.txt) and ends at 0x83400000 (in the Verizon Touch Pro - this is ulRAMEnd). The XIP is copied from the NAND flash starting here with the ROM header occupying 0x80000000 - 0x80001000. Then come the various XIP components, hopefully none of which overlap. The XIP should end at or before a ROMHDR.txt value called physlast. Thus physlast - physfirst is the size your XIP has to fit into.
Following physlast comes ulRAMStart - this is where the RAM required for nk.exe is located. This RAM ends at ulRAMFree. What remains after ulRAMFree until ulRAMEnd is available for your OS. Shrinking your XIP and relocating nk.exe will allow you to recover wasted space and give you more program memory, but it buys you nothing to move a module out of the XIP if it is required by the system. Only things that aren't required (like debuggers and hard drive drivers) should be removed.
Also, the least significant 16 bits must be zero (lower four hex digits) of the end of vm slot 0 and slot 1 in G'reloc.exe and in your ROMHDR.txt. The least significant 14 bits must be zero (the lower four digits can only be 0000, 4000, 8000 or C000) of the RAM address (ulRAMStart and ulRAMFree).
Code:
Hex edit the S000 file in the nk.exe module folder and search for the revision string. You can find it by doing a search for the unicode string "[B][COLOR=red]Kernel Built[/COLOR][/B]" (Hex String [B][COLOR=red]4B 00 65 00 72 00 6E 00 65 00 6C 00 20 00 42 00 75 00 69 00 6C 00 74 00[/COLOR][/B]). Shortly after that will be the revision that is displayed on the phase 1 boot screen (small red letters in the lower right corner of the device on CDMA Touch Pro). Change that (make sure to overwrite, not to insert, and limit it to 12 characters in unicode format.
When you rebuild your xip.bin and cook with it, you should see this value on the screen during phase 1 boot. The only other way would be to insert a marker into the boot registry
Change PagePool through Hex editing (for Diamond & Raphael)
I'm putting this up here so to answer one more unanswered question about this especially for Diamond & Raphael ROMs
To change PP of Diamond ROMs:
Open the OS.nb in Hex editing software
1. Go to offset 0x37AD68 to find 03 25 A0 E3 03 15 A0 E3 00 20 83 E5 hex string (If this string is not found at the 37AD68 offset, then search for this hex string)
Replace the string with 20 83 E5 with 00 A0 E1
This will make the string NOP (No Operation) meaning, the ROM wont set the PP to default 12MB but will allow the change in below offset
2. Now go to offset 0x3A7F94 to find E0 E2 04 80 00 00 60 00 hex string
again, if this hex string not found at the 3A7F94 offset, then search for the hex string. Just as a hint, this string is after the second NKKD8 (search for text string)
60 is the size of PP that you can now modify to suit your liking
e.g. I made mine 00 to get 0MB PP. Or change it to 80 to get 8MB PP, so forth and so on
With changing the first hex string and making the Kernel NOP, you can also use the tool to change PagePool and it does work
Also to make it a permanent change you can hex edit the first mentioned string in S000 of nk.exe module in XIP and then modify the PP with the program or by hex on OS.nb
To change PP of Raphael ROMs:
Search for hex string: 03 15 A0 03 02 15 A0 13 00 10 82 E5 and change the last 4 bytes to 03 15 A0 03 02 15 A0 13 00 00 A0 E1 then the normal PP Changer tool will work
This is the 2nd string, ignore the 1st one coz that's in ULDR
Gain more Storage Memory (increase imgfs size)
There are 4 partitions in Diamond ROMs
part00 – ULDR
part01 – XIP
part02 – IMGFS
part03 – FAT (This partition exists only on few devices)
We all port XIP from different devices to exclude few modules to gain space and to upgrade the kernel and make the XIP partition smaller in size. Although the new XIP is smaller in size but because of the insertion addresses of XIP & imgfs, there is a gap of wasted space filled with FF between end of XIP & start of imgfs. Although there is no way we can include this space into XIP as free RAM but make use of this space in imgfs and gain whatever storage space we can
Files used as example for this tutorial
xip_out.bin: My own ported XIP of size (30CA12 in Hex, 3195154 in bytes)
os.nb.payload: My own cooked payload (since I also wanted the final ROM to be a cleaner ROM)
imgfs start: in my payload at 0x7A0000 (unedited)
XIP start: in my payload at 0x320000 (unedited)
Before we move into hex editing, let me give an overall outlook of the MBR & MSFLSH regions of the ROM
MBR is the Master Boot Record of the ROM (512 bytes) from 0x0 to 0x1FF. The infomation of partitions types Flags in hex offsets are called from the registry entry mentioned in boot.rgu below
The starting block (LBA) and number of sectors for each partition are defined as shown below
part00. 1C6 – 1C9 (starting block) 1CA – 1CD (number of sectors)
part01. 1D6 – 1D9 (starting block) 1DA – 1DD (number of sectors)
part02. 1E6 – 1E9 (starting block) 1EA – 1ED (number of sectors)
part03. 1F6 – 1F9 (starting block) 1FA – 1FD (number of sectors)
[HKEY_LOCAL_MACHINE\System\StorageManager\PartitionTable]
"04"="FATFS" ; (hex: 1F2)
"20"="BOOT" ; (hex: 1C2)
"23"="RAWFS" ; (hex: 1D2)
"25"="IMGFS" ; (hex: 1E2)
MSFLSH50 is the Flash region of imgfs from 0x800 (see post #8 for screenshots, shown here is for Diamond) to 0xFFF. The starting block of imgfs is located in MSFLSH at 81C
e.g. if your device ROM's sector size is 200 then the MSFLSH50 region will starts at 0x200 and so on
Moving into the hex editing mode for making use of the wasted space between the actual XIP end & start of imgfs partitions
The new xip_out.bin is 30CA12 in total size (check your actual xip_out.bin size, shown here is just example) starting at 0x320000 (check you device XIP start, shown here is for Diamond) and ideally should end at 62CA12. But since the starting block of imgfs must be divisible by 20000 (see post #8 for screenshots, shown here is for Diamond) the imgfs needs to start at 640000. So the new XIP will have to be inserted into the payload at 0x320000 till 0x640000 with XIP size of 320000 and reduced wastage of 135EE bytes
The imgfs can also start at 630000 since this is directly after the XIP and also divisible by 20000, used here is 640000 as expansion for future xip_out.bin
Open the existing os.nb.payload in hex editor. Delete everything from 0x640000 till 0x79FFFF. This will move the imgfs from 0x7A0000 to 0x640000. Since we are now moving the imgfs partition next to new XIP, the number of sectors in new XIP and new LBA of imgfs needs to be edited to the revised value in the MBR region
To calculate the new starting block of imgfs partition we need the number of sectors in new XIP. To calculate that, use the following method
In Hex calc
Number of sectors = size of partition / sector size
e.g. (new XIP) 320000 (shown above) / 800 (see post #8 for screenshots, shown here is for Diamond) = 0640
since the coding is in little endian, we have to reverse these values to 40 06 00 00
Go to offset 0x1DA and change the values to 40 06 till 1DB and then 00 00
Now realloc the LBA of imgfs since we revised the number of sectors in XIP and to calculate that, use this method
In Hex calc
Logical Block Address (LBA) = Previous Partition LBA + Previous Partition number of sectors
e.g. (XIP LBA) 0640 + (XIP no of sectors) 0640 = 0C80
since the coding is in little endian, we have to reverse these values to 80 0C 00 00
Go to offset 0x1E6 and change the values to 80 0C till 1E7 and then 00 00
Logical Block Address (LBA) should be equal to (Previous Partition LBA + Previous Partition number of sectors * Sector Size)
e.g. (XIP LBA) 0640 + (XIP no of sectors) 0640 * 800 (see post #8 for screenshots, shown here is for Diamond) = 640000 (size of imgfs partition)
Similarly to imgfs calculate and change the LBA of FAT at 1F6 and 1F7 using the default imgfs no of sectors (use these since the cooking tools will change these as per actual size)
We have changed the LBA and number of sectors in MBR, but the OS needs to know the block address of imgfs in MSFLSH50 region
To calculate that, use this method
In Hex calc
MSFLSH50 Block Address = imgfs partition starting address / 20000 (see post #8 for screenshots, shown here is for Diamond)
e.g. (imgfs starting address) 640000 (shown above) / 20000 = 32
Go to offset 0x81C and change the value to 32
Save and close the os.nb.payload file in hex editor. Insert the new XIP into this file using this command
“insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00320000 -s 0x00320000” (check your insert start address, shown here is for Diamond)
To calculate the size of XIP from MBR, use this method
In Hex calc
Size of XIP = Number of Sectors * Sector Size
e.g. (if the no of sectors in little endian) 0640 (shown above) * 800 (see post #8 for screenshots, shown here is for Diamond) = 320000 (sector size for diamonds)
This value shall be the "-s" while using insert.exe tool and to calculate the start of the XIP, use this method
In Hex calc
XIP Start = imgfs Start + "-s"
Reduce ULDR Partition Size
“ULDR” stands for “Update Loader”, and is part of the Image Update system. This system allows deployed devices to be updated with new software after they ship. The Update Loader reads a configuration stored in persistent memory and downloads and installs new versions of operating system or OEM files
Also known as part00 in the ROM, is something we all wish to get rid of and use the space as additional storage memory. This tutorial currently aims at reducing the size of this partition by 3.0 MB
Tools you need
NBSplit.exe
NBMerge.exe
Hex editor
Ervius's Payload Reducer
IMPORTANT NOTES
The template OS.nb used is the same OS.nb in which the XIP is inserted at 320000 and of size 320000
For best results use Ervius's Payload Reducer to reduce the size of payload from shipped ROM use nbmerge.exe to cook OS.nb as template for further cooking
This ROM is assumed to be from Diamond and check your device values as per the guide below
The hex offsets of (L)ogical (B)lock (A)ddress and number of sectors and imgfs block address are mentioned in tutorial above or in the post #8 below
Process
Extract OS.nb.payload from the OS.nb (nbsplit.exe –kaiser (check your device) OS.nb)
Run the OS.nb.payload through Ervius's Payload Reducer tool to remove all files from the imgfs and keep only the partition headers
Open this OS.nb.payload in your hex editor. We need to change LBA values of the partitions and number of sectors of ULDR partition since we are reducing the size
In the MBR region (partition Flag 20) LBA of ULDR partition remains same since we are not moving it anywhere. The existing number of sectors of ULDR is 3E 06 from little endian it will be 063E. We are removing 0600 sectors from this partition (0600 * 800 (size of sector, see post #8 for screenshots) = 300000) so, 063E – 0600 = 00 3E. Write it in little endian at hex offset 1CA and 1CB to 3E 00
To physically reduce the partition, remove all data between hex offsets 0x20000 till 0x31FFFF. This will make the XIP start from hex offset 0x20000 till 0x33FFFF and the imgfs partition start at 0x340000
Now since we have reduced the size of ULDR partition, the LBA values of XIP and imgfs partitions will have to be changed in the MBR region
Now change the LBA of XIP. To calculate that, use this method
In Hex calc
Logical Block Address (LBA) = Previous Partition LBA + Previous Partition number of sectors
e.g. (ULDR LBA) 00 00 00 02 + (ULDR no of sectors) 00 00 00 3E = 00 00 00 40
since the coding is in little endian, we have to reverse these values to 40 00 00 00
Go to offset 0x1D6 and change the values to 40 00 00 00 till 1D9
Now change the LBA of imgfs. To calculate that, use this method
In Hex calc
Logical Block Address (LBA) = Previous Partition LBA + Previous Partition number of sectors
e.g. (XIP LBA) 00 00 00 40 + (XIP no of sectors) 00 00 06 40 = 00 00 06 80
since the coding is in little endian, we have to reverse these values to 80 06 00 00
Go to offset 0x1E6 and change the values to 80 06 00 00 till 1E9
We have changed the LBA and number of sectors in MBR, but the OS needs to know the block address of imgfs in MSFLSH50 region
To calculate that, use this method
In Hex calc
MSFLSH50 Block Address = imgfs partition starting address / 20000 (see post #8 for screenshots, shown here is for Diamond)
e.g. (imgfs starting address) 340000 (shown above) / 20000 = 1A
Go to offset 0x81C and change the value to 1A
Save and close the os.nb.payload file in hex editor. Insert the new XIP into this file using this command
“insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00020000 -s 0x00320000” (check your insert start address, shown here is for Diamond) (ignore this if the XIP is already inserted and shifted to this location with this size)
The value (02) seen at hex offset 0x1BF should not be changed or touched since that value tells the OS that first partition starts from the third Sector of the ROM (0x800 (sector size) + 0x800 = hex offset 0x1000) Currently the reduced ULDR partition starts from third sector
Now create the OS.nb from the edited OS.nb.payload to be used as template for cooking using this command
“nbmerge.exe –kaiser (check your device) OS.nb” (without -conservative switch)
NOTE
For best results directly use the OS.nb.payload as template for cooking without merging it into OS.nb. For this you will need to edit the CreateROM.bat
Note the change in red and delete the blue lines from this bat file
copy ROM\OS.nb.payload temp\OS.nb.payload
..\TOOLS\NBSplit -kaiser OS.nb
Rem rename os.nb.extra os-new.nb.extra
!Aman!'s awesome tutorial on removing ULDR partition from devices which don't have the FAT partition (part03) can be refered here: http://forum.xda-developers.com/showthread.php?t=446506
Screenshots of MBR and MSFLSH50 Regions
MBR Region
{
"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"
}
MSFLSH50 Region
Attached these images in Pictorial.zip with post #1 for offline reference
Gain more Storage Space with LZX compression
Thanks to:
spocky12 for cecompr_nt.dll (attached)
ivanmmj for cecompr.dll (attached) This module supports LZX compression as well as the default XPR algorithm
Replace the cecompr.dll found in the OEMXipKernel (or whichever folder you have your XIP modules) with the attached cecompr.dll module that supports LZX compression
The LZX compression takes a load of your RAM while cooking which makes the continuing IMGFSFromDump tool crash. To avoid that replace the attached cecompr_nt.dll file found in “Tools/IMGFS” folder of your kitchen
Pause your kitchen process right after it extracts the IMGFS.bin and before it inserts the files into it. (A simple “PAUSE” in the batch file will suffice). Then open up your IMGFS.bin in hex editor of your choice and search for the string "XPR". Replace the FIRST one, FIRST & ONLY ONE with "LZX". Close the hex editor, save the file and let your kitchen continue with the cooking
After flashing the ROM cooked with this module should give you approx. 10MB more space in the storage memory
Original Posts:
ivanmmj: http://forum.xda-developers.com/showpost.php?p=3678382&postcount=877
spocky12: http://forum.xda-developers.com/showpost.php?p=3690996&postcount=904
Space for Donors
High value real estate space for donors for all my work on XDA
Special Thanks
Piranha1 $5
Vippie $5
Steven Ellis $10
Guitarguy $5
Ckpv5 $5
Letama $10
!Aman! $5
LoriInWa $10
Noonski $15
Kevin $5
Dogmale $1
Nazaliyah $1
Miscellanous uploads related to XIP porting
Kitchen Files
I use "DiamondKitchen_v0.4" kitchen to cook Diamond ROMs. The XIPInsert file is something that I made to automate the insertion and nbmerge process (well, something automatic is better than complete manual )
If you select to use the XIPInsert batch file then you must have DiamondKitchen_v0.4\XIP\xip_out.bin and DiamondKitchen_v0.4\XIP\OS.nb.payload to use this option, else the existing OS.nb file in \ROM folder will get deleted
Note: The insert values used in the batch file is for Diamond ROMs. Please check and edit these as per your devices
Code:
[B][U][I]!COOK.cmd[/I][/U][/B]
Modified to provide options to include the below batch file or to continue without it
Also included necessary warning
Code:
[B][U][I]8a.XIPInsert.bat[/I][/U][/B]
@echo off
cd [COLOR=green]XIP[/COLOR]
..\TOOLS\insert.exe -i [COLOR=green]xip_out.bin[/COLOR] -o [COLOR=green]OS.nb.payload[/COLOR] -d 0x00320000 -s 0x004C0000
..\TOOLS\nbmerge -kaiser OS.nb
copy OS.nb ..\ROM\OS.nb
del OS.nb
del *.payload
del *out.bin
exit
Deprotecting ROMs: My friend, Ervius has made a small tool to "deprotect" a protected ROM , here: http://forum.xda-developers.com/showthread.php?t=465642
First to say THANKS
Cheers
and second to say this is real hard work...but u have done it bro..
congrats
another amazing work by the XIP Master
Thanks for sharing the info, ababrekar! I'm sure this will help out many people (myself included ).
Bite Down and Don't Give Up.
Sounds like someone i know from.... hey, it is you!
Good Job,
ababrekar said:
Use this command for inserting the xip_out.bin into the .payload (presuming you already have the shipped OS.nb.payload file in the same working folder
insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00320000 -s 0x004C0000
Check these values with your device imgfs since in Diamond the XIP starts at 0x00320000 and the imgfs starts at 0x007A0000, but for some reason the imgfs signature in Diamond is at 0x007E0000
Click to expand...
Click to collapse
just to make it more clear, the value for "-s"= (starting offset of imgfs - starting offset of XIP)
PS: wonderful job writing this guide brother
Ouch - too much like work, but it is nice to know how to do it.
Thanks for your effort!
Best regards,
-boggsie
So, how does one get hooked into the flow of new releases?
Perhaps would be a good idea to use one of your reserved posts as a repository of good XIP.BIN files with versions and info about the ROM extracted, so all we can use in our ROMs... only a tought...
jcespi2005 said:
Perhaps would be a good idea to use one of your reserved posts as a repository of good XIP.BIN files with versions and info about the ROM extracted, so all we can use in our ROMs... only a tought...
Click to expand...
Click to collapse
That is a good idea but I'll do that for posting the unedited XIP.bin files from dumped ROMs since the xip_out.bin I build would be for my device. People wont want to ruin their ROMs with someone else's ported XIP, right?
hi guys I'm doing some research on samsung's firmware files...
is there any good disassembler in here?
We need to know how is the checksum at the end of FFS // APP files calculated!
That's very important...
is there anyone who can help?
im sorry im not but maybe a frined of mine...
why is so important?
its hard to do?
if you give a link with a tutorial may be in some days i will be able to help...
i have programmed in c in the past...
cheers
I am a C programmer (university student) but we need disassemblers here, no programmers atm
Guys I don't know if you understand that the solution to this problem is CRUCIAL for the realization of custom firmwares!!
Trust me! Find some windows (desktop) disassembler as soon as possible!!
thanks
Type : Unofficial Version
Number : 41
Builder : HP05
Host : SCMHP05
Date : 2010/05/28
Time : 21:49:29
Size : 81790332 bytes
CheckSum : 0x259b3fc5
View
Click to expand...
Click to collapse
Hmmm. Whole file is smaller... 50.856.960...
apps_compressed.bin
Decrypted with PSAS... but I can't decompress...
Anyway.
CRC32 (32 bit) could be used...
The Question could be, where the content starts and ends correct to fit size to make crc32...
Best Regards
wait u're talking about the apps_compressed...
while I'm talking about the ffs/app files...which have a 16byte checksum in the footer!
Sorry. I'm thinking loud. As I thought they used for all files same CRC or Hash...
I compared for instance Rsrc2_S8500(Mid).rc2 and Rsrc2_S8500(Low).rc2.
As 1 Byte at Start leads to 16 Byte change at end of file... So maybe MD5 too used by Multiloader.
Again. I'm thinking loud.
Best Regards
No progress. But few Screenshots for better understanding...
If we manipulate *.FFS we can't flash. (ALL other files protected too...)
Test 1.
I changed 1 useless Byte...
Somewhere blabla.jad in blabla.jam
Multiloader 5.64 accept to choose my file. But Error message if I press Download.
Test 2.
I add 1 Byte at the end of file. To check if some crap or if whole file is checked...
Result:
Multiloader 5.64 not allow to choose this file.
Both files tested also via Multiloader 5.62. And this Versions not allow both files to choose.
See Screenshots for Error messages.
Ideas...
Maybe disable CRC Check in Multiloader...
Or find other way to flash and check if Wave self checks Manipulation of files. Or only Multiloader is the bottleneck.
Maybe it is more complex... as I found via Internal menu the Info I've posted above... in Wave self. If Wave have selfcheck...
Best Regards
hi,
I'm not sure if you're hear about fmtBADA plugin for TriX - I wrote it few days ago (it is very simple but quite usefull). It parse any bada firmware file (*ffs, amss, ShpApp etc), so we can easly manipulate with it. After all program recalculate checksum, update all needed values so we can put file back to phone using multiuploader
b.kubica said:
hi,
I'm not sure if you're hear about fmtBADA plugin for TriX - I wrote it few days ago (it is very simple but quite usefull). It parse any bada firmware file (*ffs, amss, ShpApp etc), so we can easly manipulate with it. After all program recalculate checksum, update all needed values so we can put file back to phone using multiuploader
Click to expand...
Click to collapse
what u talking about?
let us know more...
I made lots of research on ffs and app files...
I put some files at NokiX site (check my homepage), so you can play with firmware files quite easily. GUI is qt based so you need to download Qt libraries for the first time. Two packages you will find in bada subdir - program and scripts.
Start program, at General tab select input and output file (e.g. FFS PFS ShpApp,amss). Go to the Scripts tab and load scripts you want to fire up.
For the first time I reccomend you to try fs_shell script - it is simly command line script to edit filesystem images (ffs,pfs,shpapp). You can list, dump delete rename files, adding is not supported yet (but can be easy implemented - scripts are written in pure C).
Before asking just play with it
br,
Bartek
ok then I don't need it already made more
thanks to a russian friend, I probably solved the checksum problem
good news will come the next days
Nice. I have extracted *.FFS and ShpApp.app files.
I'm blind to find the Button where Rename or Delete is stored to output file.
How to save my changes to file?
Best Regards
Edit:
Maybe my fault...
I have bada_scripts_20110104.zip.
Will look into bada_20110106.zip
kubica no reason to make a new script, I'll post something in the next days if it's ok to you, take care about the amss
if you want to do it for personal reason, no problem of course
nevermind, script was already done
you're working on some kind of file system tool, right? We're lucky guys FS images have very simply structure (as you know), only one md5 checksum on it, kewl
One of TriX most advantage is work on stages ( e.g. amss is parsed to elf, elf is parsed to memory segments, than we can edit them and TriX roll back to amss again).
adfree, yes I uploaded today latest version (can be found in repository also). As I said it is only text version (command line), more like programmer preview, and it was not designed as end user tool.
faenil, you asked about dissasembler - have you tried IDA? ( quite expensive though ). I tried in trix hack amss (resize memory segments, add own routines), all works fine, now it's time to investigate functions (some of them can be located with locate script).
Another question - ok, it's sad bootloader is crypted with RSA, but I guess is stored in flash decoded. What if we try to access nand directly using Flash_Read/Write? I can't find flash access routines in amss but i did't look
deeply...
b.kubica said:
nevermind, script was already done
you're working on some kind of file system tool, right? We're lucky guys FS images have very simply structure (as you know), only one md5 checksum on it, kewl
One of TriX most advantage is work on stages ( e.g. amss is parsed to elf, elf is parsed to memory segments, than we can edit them and TriX roll back to amss again).
adfree, yes I uploaded today latest version (can be found in repository also). As I said it is only text version (command line), more like programmer preview, and it was not designed as end user tool.
faenil, you asked about dissasembler - have you tried IDA? ( quite expensive though ). I tried in trix hack amss (resize memory segments, add own routines), all works fine, now it's time to investigate functions (some of them can be located with locate script).
Another question - ok, it's sad bootloader is crypted with RSA, but I guess is stored in flash decoded. What if we try to access nand directly using Flash_Read/Write? I can't find flash access routines in amss but i did't look
deeply...
Click to expand...
Click to collapse
I'm not that experienced unfortunately I needed a disassembler (person) not a disassembler (software)
btw I needed it to discover that it was md5 and on which bytes it was computed and I discovered this yesterday evening
So now we know everything about ffs and app
Still have to understand the new values in pfs header...if you already know that raise your hand
Btw, yes I'm working on something like that I won't have time now to do the GUI, so I'll probably leave it as an "experienced users only" for the moment...
I've got lots to study for university, and some programming projects to end (for uni too) so my spare time is almost finished and I still have to release a custom firmware for i8910 and a software for that firmware for Symbian...
damn I'm full of things to do xD
I'll send u a pm though, if you want to chat a lil
all file footer looks the same
typedef struct s_bada_footer // last 1024 bytes
{
unsigned int magic; // always 0xABCDABCD
unsigned int addr; // nand(?) address
unsigned int unk0; // SBZ (=Should Be Zero)
char name[32]; // e.g. S8500
char ext[8]; // e.g. mbn, ffs
unsigned int unk1[5]; // some flags, values, to be checked later
t_cert_info info; // crypto data ( zeroed if file is not crypted )
char md5sum[16]; // MD5 sum of image ( without footer )
char padd[424]; // padding bytes, SBZ
} t_bada_priv;
typedef struct t_cert_info // 512 bytes
{
unsigned int magic; // 0x79461379
char cert0[324]; // ...
unsigned int magic; // 0x79461379
unsigned int length; // crypted length ( without footer )
char cert1[16]; // exist in image also at ( length - 0x10 ) position
char publickey[64]; // ?
char name[64]; // e.g. S8500+XX+JEE
char tool[32]; // TkToolVer famous string
}
headers are different. boot_loader, Apps, Rsrc1, Rsrc2, fota and CSC don't have header.
dbl and Amss have 0x200 bytes header.
ShpApp, Factory FS, Partial FS have 0x60 bytes header
Code:
typedef struct s_bada_object
{
unsigned int offset;
unsigned int length;
char name[24];
} t_bada_object;
typedef struct s_bada_hdr200
{
unsigned int magic; // 0x12345678
unsigned int count; // count of objects below
char padd[24]; // padding bytes
t_bada_object[15]; // not used SBZ
} t_bada_hdr200;
typedef struct s_bada_hdr60
{
wchar_t name[16]; // UCS-2 name
unsigned int unk0[14]; // unknown
char padd[8]; // FF FF FF
} t_bada_hdr200;
from my observations, unk0 fields in FS system header are not *SO* important - I just preserve original values, removed files I want from factory FS, and put file back to phone
all file footer looks the same
Code:
typedef struct s_bada_footer // last 1024 bytes
{
unsigned int magic; // always 0xABCDABCD
unsigned int addr; // nand(?) address
unsigned int unk0; // SBZ (=Should Be Zero)
char name[32]; // e.g. S8500
char ext[8]; // e.g. mbn, ffs
unsigned int unk1[5]; // some flags, values, to be checked later
t_cert_info info; // crypto data ( zeroed if file is not crypted )
char md5sum[16]; // MD5 sum of image ( without footer )
char padd[424]; // padding bytes, SBZ
} t_bada_priv;
typedef struct t_cert_info // 512 bytes
{
unsigned int magic; // 0x79461379
char cert0[324]; // ...
unsigned int magic; // 0x79461379
unsigned int length; // crypted length ( without footer )
char cert1[16]; // exist in image also at ( length - 0x10 ) position
char publickey[64]; // ?
char name[64]; // e.g. S8500+XX+JEE
char tool[32]; // TkToolVer famous string ;)
}
headers are different. boot_loader, Apps, Rsrc1, Rsrc2, fota and CSC don't have header.
dbl and Amss have 0x200 bytes header.
ShpApp, Factory FS, Partial FS have 0x60 bytes header
Code:
typedef struct s_bada_object
{
unsigned int offset;
unsigned int length;
char name[24];
} t_bada_object;
typedef struct s_bada_hdr200
{
unsigned int magic; // 0x12345678
unsigned int count; // count of objects below
char padd[24]; // padding bytes
t_bada_object[15]; // not used SBZ
} t_bada_hdr200;
typedef struct s_bada_hdr60
{
wchar_t name[16]; // UCS-2 name
unsigned int unk0[14]; // unknown
char padd[8]; // FF FF FF
} t_bada_hdr200;
from my observations, unk0 fields in FS system header are not *SO* important - I just preserve original values, removed files I want from factory FS, and put file back to phone
CSC has got its header, it's just that there are more files into 1
after about half the file, we come back to the same plain structure
very simple ( 2KB ) partial file system in attachment, all values from header preserved
Code:
FileSystem Shell
---------------------------
<1.> List Files
<2.> Get File
<3.> Put File
<4.> Delete File
<5.> Rename File
<6.> Dump all files
<0.> Quit
Type Size Flags Name
DIR 0x00000000 0x00000000 /Arggh
FILE 0x00000000 0x00000000 /Arggh/it_works.txt
Index
Edify or Updater-Script tutorial in 1st Post
Device specific fixes for vision in first post
Build.prop tweaks in 1st Post
MIUI Porting Guide In 1st Post
Sense 4.0/3.5 prting Guide in 2nd Post
Icecoldsandwich port | LewaOS Port | AOKP Port in 3rd Post
Hi,
First of all this thread is a compilation of all possible resources I am able to find from all possible sources.
Big credits to proxuser for his general MIUI rom porting guide, thanks to cjward for helping me out fix the Autorotation issue, Autobrightness Levels and for adding additional symbols to the "sym" key and big thanks to dekky to help me fix the "libandroid.runtime.so" error.
I've tried to cover all the basic aspects of ROM porting and modding including using smali/backsmali and modding apks with the help of apktool. I hope it will help those who are wiling to learn.
I request all the devs around there to take a look and suggest what else I can add there to make it more friendly.
Ok so there it is:
Here is the Updater-Script tutorial : Credits to Edify scripting from E. Pete Karelis and Free your android for original guides from where I learnt this.
Code:
[B]Function Name: mount[/B]
Function Syntax: mount(fs_type, partition_type, location, mount_point)
Parameter Details:
fs_type = "yaffs2" | "ext4"
partition_type="MTD" | "EMMC"
location = partition | device
mount_point = target folder to mount FS.
Action: Mounts a filesystem to the defined mount point
Returns: The mount point if successful, null if failed
[B]Function Name: is_mounted[/B]
Function Syntax: is_mounted(mount_point)
Parameter Details: mount_point = string, mount point to check if is mounted
Action: Checks if a filesystem is mounted.
Returns: The mount point if mounted, otherwise, returns null
[B]Function Name: unmount[/B]
Function Syntax: unmount(mount_point)
Parameter Details: mount_point = string, mount point to unmount
Action: Unmounts the filesystem
Returns: The mount point that was dismounted if successful, otherwise it returns null
[B]Function Name: format[/B]
Function Syntax: format(fs_type, partition_type, location)
Parameter Details:
fs_type = string,"yaffs2" | "ext4"
partition_type= string, "MTD" | "EMMC"
location = string, partition | device
Action: Formats a filesystem as specified
[B]Function Name: delete[/B]
Function Syntax: delete(file1, file2, ..., fileN)
Parameter Details: string, file to delete
Action: Deletes a file. Must specify at least one file; multiple files can be specified as multiple arguments
[B]Function Name: delete_recursive[/B]
Function Syntax: delete_recursive(dir1, dir2,...,dirN)
Parameter Details: string, directory to recursively delete
Action: Deletes a folder and all of its contents. At least 1 directory must be specified; multiple directories can be specified as additional arguments.
[B]Function Name: show_progress[/B]
Function Syntax: show_progress(frac, sec)
Parameter Details:
frac = fraction of progress completed
sec = total seconds
Action: Displays flashing progress in the recovery system
[B]Function Name: set_progress[/B]
Function Syntax: set_prograss(frac)
Parameter Details: frac=fraction of progress
[B]Function Name: package_extract_dir[/B]
Function Syntax: package_extract_dir(package_path, destination_path)
Parameter Details:
package_path = string, directory in package to extract
destination_path = string, target point to extract files to
Action: Extract the all of the files in a directory in the package to the target specified.
[B]Function Name: package_extract_file[/B]
Function Syntax:
package_extract_file(package_path)
or
package_extract_file(package_path, destination_path)
Parameter Details:
package_path = string, file in the package you want to extract
destination_path, target folder to extract the file to.
Action: Extracts a single file from your update package to the target specified
[B]
Function Name: file_getprop[/B]
Function Syntax: file_getprop(file, key)
Parameter Details:
file = string, filename to check
key = string, key in file to return the value of
Action: Checks for a value in a file?
[B]Function Name: symlink[/B]
Function Syntax: symlink(target, src1, src2, ..., srcN)
Parameter Details:
target = string, the target of the symbolic link
srcX = the symbolic link to create that points to the target
Action: Unlinks any existing symbolic links before creating the new symbolic links.
[B]
Function Name: set_perm[/B]
Function Syntax: set_perm(uid, gid, mode, file1, file2, ..., fileN)
Parameter Details:
uid = user id
gid = group id
mode = permission mode
fileX = file to set permission on
Action: Sets permissions of a file or set of files specified. At least one file must be specified (the first four parameters are required)
[B]Function Name: set_perm_recursive[/B]
Function Syntax: set_perm_recursive(uid, gid, dirmode, filemode, dir1, dir2, ...dirN)
Parameter Details:
uid = user id
gid = group id
dirmode = permission to set to directories contained within the specified directory
filemode = permission to set to files contained within the specified directory
dirX = directory to set permission on
Action: Set permissions of a directory or set of directories and all files and folders within them. At least one directory must be specified (The first 5 parameters are required)
[B]Function Name: getprop[/B]
Function Syntax: getprop(key)
Parameter Details: key = string, the property you want the system to return
Action: This function returns the value of the property specified. This is used to query platform information from the build.props file.
[B]Function Name: write_raw_image[/B]
Function Syntax: write_raw_image(file, partition)
Parameter Details:
file - string, the source .img file to be read from
partition - string, the destination partition to write the .img file to
Description: This function writes an img file to a partition.
[B]Function Name: apply_patch[/B]
Function Syntax: apply_patch(srcfile, tgtfile, tgtsha1, tgtsize, sha1_1, patch_1, ..., sha1_x, patch1_x)
Parameter Details:
srcfile - string, source file to be patched (file to read in)
tgtfile - string, destination file to write the patched file to
tgtsha1 - string, sha1 hash of the target file as it should hash out after the patches apply properly
sha1_x - string, sha1 hash of the patch data that's to be written to the target file
patch1_x- string, actual patch to apply to the target file
Action: This function is used to apply patches to a file.
[B]Function Name: apply_patch_check[/B]
Function Syntax: apply_patch_check(file, sha1_1, ..., sha1_x)
Parameter Details:
file - string, file to check
sha1_x - hash to check for?
Action: Either checks if a file has been properly patched, or checks if a file can be patched. Need to check the source code of the "applypatch_check" function that is called from here.
[B]Function Name: apply_patch_space[/B]
Function Syntax: apply_patch_space(bytes)
Parameter Details: bytes = number of bytes to check for
Action: Checks the cache to verify that there is enough space to write the patched files to it and returns something. Need to test this function to verify.
[B]Function Name: read_file[/B]
Function Syntax: read_file(filename)
Parameter Details: filename - string, the filename to read the contents of
Action: This function returns the contents of a file.
[B]Function Name: sha1_check[/B]
Function Syntax:
sha1_check(data)
or
sha1_check(data, sha1_hex, ..., sha1_hexN)
Parameter Details:
data - the contents of file to calculate the sha1 hash of - must be in the read_file format
sha1_hexN - A particular sha1_hex string that you want the file data to match
Action: If only data is specified, then the function returns the sha1_hex string of the data. The optional parameters are used if you want to verify that the file you are checking for is one of a list of hashes. It reutrns the hash it matches, or returns nothing if it doesn't match any of the mentioned hashses.
[B]Function Name: ui_print[/B]
Function Syntax: ui_print(msg1, ..., msgN)
Example : ui_print("===============================================");
to print ===============================================
Parameter Details: msg - String, message to be outputted to the user during the patch process
Action: This function prints/echos a message to the console while the script is running. At least 1 parameter needs to be specified, you can specify additional msg parameters and they will be concatenated to the output.
Function Name: run_program
Function Syntax: run_program(prog, arg1, .., argN)
Parameter Details:
prog - string, program to execute
argN - string, arguments for the program that is being executed
Description: Executes a program with the arguments specified. Returns a string, I assume it is the buffer of the stdout of the program executed, need to test.
[B]Function Name: ifelse[/B]
Function Syntax: ifelse(condition, truecondition, falsecondition)
Parameter Details:
condition - an expression to evaluate
truecondition - Edify script block to execute if true
falsecodnition - Edify script block to execute if false
Description: This is the if-then construct of the Edify scripting language. The truecondition or falsecondition arguments can be a single edify command or a script block. Script blocks can be formed by enclosing the parameter with parenthesis, and seperating the commands with semicolons\
[B]Function Name: abort[/B]
Function Syntax: abort()
Parameter Details: no paremeters
Description: Aborts script execution.
[B]Function Name: assert[/B]
Function Syntax: assert(condition)
Parameter Details: condition - boolean
Description: If condition evaluates to false, stops script execution, otherwise continues processing.
Here is some device specific instructions :
mmcblk0p25 refers to system partition of the device
mmcblk0p26 refers to data partition of the device
mmcblk0p27 refers to cache partition of the device
Refer to following if you get error during flashing in recovery :
Error 6 : The updater-script is not in proper unix format (Happens when you edit file in windows)
More to come
Keyboard Fix:
Since Desire Z has a keyboard, we need to modify the android.policy.jar to tell it the lid open state.
Here's what you need to do (thanks cjward):
FIX KEYBOARD ROTATION AND AUTO ROTATE :
Go into android.policy.jar\smali\com\android\internal\poli cy\impl\PhoneWindowManager.smali
Code:
ORIGINAL
.line 1094
const/4 v1, 0x1
CHANGE TO
.line 1094
const/4 v1, 0x0
ORIGINAL
.line 1096
const/4 v1, 0x0
CHANGE TO
.line 1096
const/4 v1, 0x1
These line number need not be same, but what you need to notice is that these states will differ with a value of 2 and it should have a comment :
<------------ mLidOpen .....
To search this line, hit "ctrl + f" and type "const/4 v1, 0x1", probably in one or two hits, you will get to this.
If it doesn't gets fixed by this then you need to make one more modification:
(thanks NeverGone\RU for pointing this out)
Change the following line in framework-res/res/values/bools.xml:
<bool name="config_forceDisableHardwareKeyboard">true</bool>
Setting this value to false fixed the keyboard issue completely.
Trackpad Wake : (big thanks to lms24 for pointing this out):
Open libinput.so with a hex editor and search for these 4 numbers: A1 F5 88 72. Change the 88 to 89 and save it.
Decompile android.policy.jar. open keyguardviewmediator.smali and fo down to method "isWakeKeyWhenKeyguardShowing(IZ)Z"
You need to modify the 0x18 and 0x19 values to enable tp wake.
If you want volume rocker wake also then just delete the lines of 0x18 and 0x19.
I haven't been able to figure out exactly what you need to do to enable only tp wake and not the volume rocker, so for time being just swap the above listed method from a rom which has got working tp-wake, like Sabsa bliss by lms24 for sense 3.6 and Gen.Y R3 for Sense 4 roms.
The method should look like this:
Code:
.method public isWakeKeyWhenKeyguardShowing(IZ)Z
.locals 3
.parameter "keyCode"
.parameter "isDocked"
.prologue
const/4 v2, 0x0
iget-object v0, p0, Lcom/android/internal/policy/impl/KeyguardViewMediator;->mContext:Landroid/content/Context;
invoke-virtual {v0}, Landroid/content/Context;->getContentResolver()Landroid/content/ContentResolver;
move-result-object v0
const-string v1, "tweaks_lockscreen_volumekey"
invoke-static {v0, v1, v2}, Landroid/provider/Settings$System;->getInt(Landroid/content/ContentResolver;Ljava/lang/String;I)I
move-result v0
if-nez v0, :cond_0
.line 1242
sparse-switch p1, :sswitch_data_0
goto :goto_0
.line 1273
:cond_0
sparse-switch p1, :sswitch_data_1
:goto_0
const/4 v0, 0x1
move p2, v0
.line 1269
.end local p2
:goto_1
:sswitch_0
return p2
.line 1265
.restart local p2
:sswitch_1
sget-short v1, Lcom/htc/htcjavaflag/HtcBuildFlag;->Htc_DEVICE_flag:S
const/16 v2, 0x1c
if-eq v1, v2, :cond_1
sget-short v1, Lcom/htc/htcjavaflag/HtcBuildFlag;->Htc_DEVICE_flag:S
const/16 v2, 0x89
if-ne v1, v2, :cond_2
.line 1269
:cond_1
move p2, v0
.line 1263
goto :goto_1
.line 1265
:cond_2
const/4 p2, 0x0
goto :goto_1
.line 1238
nop
.line 1242
:sswitch_data_0
.sparse-switch
0x18 -> :sswitch_0
0x19 -> :sswitch_0
0x1b -> :sswitch_1
0x4f -> :sswitch_1
0x55 -> :sswitch_1
0x56 -> :sswitch_1
0x57 -> :sswitch_1
0x58 -> :sswitch_1
0x59 -> :sswitch_1
0x5a -> :sswitch_1
0x5b -> :sswitch_1
0x7e -> :sswitch_1
0x7f -> :sswitch_1
0x82 -> :sswitch_1
0xa4 -> :sswitch_0
0xe4 -> :sswitch_1
.end sparse-switch
.end method
Build.prop Common Tweaks : Credits blindnumb
Code:
# Fast Reboot
persist.sys.purgeable_assets=1
# Increasing The Video Recording Quality
ro.media.enc.hprof.vid.bps=8000000
# Screen Rotate To 270 degree
windowsmgr.support_rotation_270=true;
# Increase VM Heap Size(resolve some fc's)
dalvik.vm.heapsize=64m
# Render UI With GPU
debug.sf.hw=1
# Increasing It Will Make Mobile Smoother
windowsmgr.max_events_per_sec=150
# Video Acceleration Enabled
video.accelerate.hw=1
# Increase Performance
debug.performance.tuning=1
# Disable Sending Usage Data
ro.config.nocheckin=1
# Deeper Sleep/Better battery life
ro.ril.disable.power.collapse=1
pm.sleep_mode=1
# Ringing Will Start Immediately
ro.telephony.call_ring.delay=0
# Disable Error Checking
ro.kernel.android.checkjni=0
# Increase Quality Of MediaStreaming
media.stagefright.enable-meta=true
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
media.stagefright.enable-record=false
# Disable BootAnimation
debug.sf.nobootanimation=1
#Force To Remain Launcher In Memory
ro.HOME_APP_ADJ=1
# Disable Waking Up Of Phone By Volume Buttons
ro.config.hwfeature_wakeupkey=0
# Off The Proximity Quiclky After Call
mot.proximity.delay=25
# Signal Tweaks
ro.ril.hsxpa=2
ro.ril.gprsclass=10
ro.ril.hep=1
ro.ril.enable.dtm=1
ro.ril.hsdpa.category=10
ro.ril.enable.a53=1
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=5
# NetSpeed Tweaks
net.tcp.buffersize.default=4096,87380,256960,4096, 16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,163 84,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,163 84,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,163 84,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,163 84,256960
# Google DNS Tweak
net.rmnet0.dns1=8.8.8.8
net.rmnet0.dns2=8.8.4.4
net.dns1=8.8.8.8
net.dns2=8.8.4.4
# Photo And Video Quality
ro.media.dec.jpeg.memcap=8000000
ro.media.enc.hprof.vid.bps=8000000
ro.media.enc.jpeg.quality=100
# Touch Responsiveness
debug.performance.tuning=1
video.accelerate.hw=1
# Scrolling Responsiveness
windowsmgr.max_events_per_sec=500
# Power Save Tweaks
ro.ril.disable.power.collapse=1
pm.sleep_mode=1
# Disables Debug Icon On Status Bar
persist.adb.notify=0
For a more complete list, Visit his website, click here.
Its a huge collection of resources and tutorials so do visit it.
Step 1:
You need to choose you base and the rom you want to port. Prefer to choose a rom which shares the same brand or if possible shares the same chipset as HTC Vision. So, choose any MIUI v4 rom from "Desire HD" if possible and If you are not able to get one, Choose one from "Desire S" or "Nexus One" or "Desire".
I would recommend MIUI-Au, since I found their english translations are best but it is not getting updated regularly, so you are free to choose your base rom.
Here is the link to some MIUI ICS roms which you could port:
MIUI-Au for HTC Desire
Dekky's MIUI ICS for Desire HD
MIUI-us ICS for Desire HD
MIUI-us ICS for Nexus One
Choose any cm9 or ics AOSP or AOKP rom as your base for the port here are a few roms you could use as your base are :
Andromadus Audacity Beta 2
Virtuous Quattro RC3
Virtuous Quattro RC4 leak
So, you grabbed some or all of these roms, lets get to the next step.
Step 2 :
Replace complete folders (those noted below) of your base rom with the MIUI one :
system/app
system/framework
Step 3:
Go to /system/lib :
copy "libandroid_runtime.so" lib from miui 4 (rom you port). without this file rom will not boot. if you get bootloop, try with base "libandroid_runtime.so" file.
If it still doesn't boot, then look at the end of the post, you need to add some modifications to your framework.jar which i'll take at the end of the post.
copy "liblbesec.so" from miui 4 to /system/lib and open the updater-script of your base rom with "notepad++" on windows or with "gedit" on linux and add the following line to it :
set_perm(0, 0, 0755, "/system/lib/liblbesec.so");
(for superuser app from miui work)
copy "content-types.properties" file to /system/lib
Step 4:
replace /system/media folder with base rom (that themes, wallpaper, audio from miui work)
Step 5:
copy "telocation.db" and "yellowpage.db" to /system/etc folder.
Step 6:
copy "invoke-as" from miui4 rom to /system/xbin and give it permissions on updater-script
set_perm(0, 0, 06755, "/system/xbin/invoke-as");
(for backup & themes app work)
Step 7:
change values from build.prop (edit with notepad ++)
ro.build.id=MIUI
ro.build.display.id=MIUI
ro.build.version.incremental=2.x.x (version number)
ro.config.ringtone=MI.ogg
ro.config.notification_sound=FadeIn.ogg
ro.config.alarm_alert=GoodMorning.ogg
ro.config.sms_received_sound=FadeIn.ogg
ro.config.sms_delivered_sound=MessageComplete.ogg
Step 8 :
SInce Desire Z has a keyboard, we need to modify the android.policy.jar to tell it the lid open state.
Here's what you need to do (thanks cjward):
FIX KEYBOARD ROTATION AND AUTO ROTATE :
Go into android.policy.jar\smali\com\android\internal\poli cy\impl\PhoneWindowManager.smali
Code:
ORIGINAL
.line 1094
const/4 v1, 0x1
CHANGE TO
.line 1094
const/4 v1, 0x0
ORIGINAL
.line 1096
const/4 v1, 0x0
CHANGE TO
.line 1096
const/4 v1, 0x1
These line number need not be same, but what you need to notice is that these states will differ with a value of 2 and it should have a comment :
<------------ mLidOpen .....
To search this line, hit "ctrl + f" and type "const/4 v1, 0x1", probably in one or two hits, you will get to this.
If you have no idea what I'm talking about then read carefully.
You need to extract android.policy.jar from MIUI rom and decompile it using backsmali.
Go here and download "smali-1.3.2.jar" and "backsmali-1.3.2.jar".
Put them in the same folder you put your extracted android.policy.jar. Then open cmd.exe and browse to that folder and hit the command:
Code:
java -jar baksmali.jar -a 15 -x android.policy.jar -o classout
It'll give you a folder named "classout" once it has finished decompiling. Now open that folder and browse to the file mentioned above.
Edit the values and then return back to your command windows and hit the command:
Code:
java -Xmx512M -jar smali.jar -a 15 classout -o classes.dex
It'll give you a file named classes.dex.
Now open "android.policy.jar" with 7zip:
Right click on the file --> hit 7zip --> Open archive.
Then drag the classes.dex you created into the window which appeared.
It'll replace the old classes.dex in android.policy.jar
Now use this file for your port.
Step 9:
Now we need to add some modifications to "framework.jar" to add more symbols to the "sym" key and to get the rom boot in case it gets into bootloop with all the available "libandroid.runtime.so" from both MIUI roms and the base rom.
EXTRA SYMBOLS ON "SYM" KEY
Again as explained above, decompile framework.jar and browse to the file mentioned below:
framework.jar\smali\android\text\method\QwertyKeyListener.smali
Code:
ORIGINAL
const-string/jumbo v2, "\u2026\u00a5\u2022\u00ae\u00a9\u00b1[]{}\\|"
CHANGE TO
const-string/jumbo v2, "$\u00a5\u2022\u00ae\u00a9\u00b1[]{}<>`^\\|"
This will add some extra symbols on the "sym" key.
Now to get the rom boot in case it is not booting with available "libandroid.runtime.so".
Use the "libandroid.runtime.so" from the base rom and do the following modifications:
decompile you base rom "framework.jar" and MIUI "framework.jar" and do the following:
swap Power.smali, Paint.smali, MediaRecorder.smali, GLES20Canvas.smali, PowerManager*.smali... from base framework.jar to MIUI framework.jar
Then recompile it as mentioned above how to recompile jar files and use it in your port. (If it's still not booting then get a logcat to know the error)
Step 10 :
Now to fix the autobrightness values to the correct level, you need to do the following:
Obtain framework-res.apk from the MIUI rom and decompile it using apktool. If you don't know how to do that then read below or skip to next section.
Here is the link to different apktools:
apktool used by cjward : Click here
apktool used by lyapota : Click here
I use a different technique to get things done (thanks to galaxynexusforums):
Download the package of different apktools from here.
Extract these files and the apk you want to mod in the same folder.
Open cmd.exe and browse to that folder.
Install the latest android sdk and grab the latest "aapt.exe" from it. For me, the folder is : C:\Android\android-sdk\platform-tools
Now hit the follow command :
Code:
java -jar apktool_1_4_2.jar if framework-res.apk
(you need to rename apktool.jar.1.4.2 to apktool_1_4_2.jar and similarily apktool.jar.1.4.3 to apktool_1_4_3.jar)
Code:
java -jar apktool_1_4_2.jar d framework-res.apk
Now do the modding as stated below:
AUTO BRIGHTNES AND KEYBOARD LIGHTS FIX:
browse to the file "framework-res.apk\res\values\arrays.xml"
Code:
ORIGINAL
<integer-array name="config_autoBrightnessLevels">
<item>200</item>
<item>400</item>
<item>1000</item>
<item>3000</item>
CHANGE TO
<integer-array name="config_autoBrightnessLevels">
<item>11</item>
<item>41</item>
<item>91</item>
<item>161</item>
<item>226</item>
<item>321</item>
<item>641</item>
<item>1281</item>
<item>2601</item>
ORIGINAL
<integer-array name="config_autoBrightnessLcdBacklightValues">
<item>35</item>
<item>55</item>
<item>70</item>
<item>70</item>
<item>250</item>
CHANGE TO
<integer-array name="config_autoBrightnessLcdBacklightValues">
<item>89</item>
<item>89</item>
<item>126</item>
<item>164</item>
<item>164</item>
<item>164</item>
<item>187</item>
<item>210</item>
<item>233</item>
<item>255</item>
ORIGINAL
<integer-array name="config_autoBrightnessButtonBacklightValues">
<item>255</item>
<item>255</item>
CHANGE TO
<integer-array name="config_autoBrightnessButtonBacklightValues">
<item>30</item>
<item>30</item>
<item>30</item>
<item>30</item>
<item>0</item>
<item>0</item>
<item>0</item>
ORIGINAL
<integer-array name="config_autoBrightnessKeyboardBacklightValues ">
<item>0</item>
<item>0</item>
<item>0</item>
<item>0</item>
<item>0</item>
CHANGE TO
<integer-array name="config_autoBrightnessKeyboardBacklightValues ">
<item>255</item>
<item>255</item>
<item>255</item>
<item>255</item>
<item>0</item>
<item>0</item>
<item>0</item>
<item>0</item>
<item>0</item>
<item>0</item>
After changing these values, hit the following command in the command window:
Code:
java -jar apktool_1_4_3.jar b framework-res
It'll take a while to complete. If it gives you error, try with different versions of apktool.
Once you are done:
Go to "framework-res\dist" and right click on the framework-res.apk you find there.
Now ---> 7zip ---- > Open archive
Now copy the resource.arsc from there to your desktop.
Open you original framework-res.apk via 7zip in the same manner as stated above and replace the default resource.arsc file with the once from your desktop.
Use this modded framework-res.apk in your port.
Step 11:
Now you have completed you port. Now zip the file and sign it with the help of dsixda kitchen.
If you don't know how to do so, go there.
If you don't want to get you hands dirty with dsixda kitchen, then just open your base rom with "winrar" or "7zip" and swap the files and mods stated above.
Your ROM is now ready to be flashed.
Credits :
proxuser
cjward
dekkyy
galaxynexusforums
lyapota for his apktool
Sense 4.0 and 3.5 Porting Guide
Use this guide written by proxuser to Port Sense 4.0 roms :
http://forum.xda-developers.com/showpost.php?p=24021776&postcount=3
and this guide for porting Sense 3.5 roms :
http://forum.xda-developers.com/showpost.php?p=24021769&postcount=2
If you are porting a rom from Desire HD, all the files which need to be swapped can be found at:
http://elektro-instal.com/napior/3.5 port tools.zip
This will give you unity kernel.
Use IceZSense or IceSenseWich for device files.
The following device specific changes are needed:
Use android.policy.jar from IceZSense or IceSenseWich for now as a base for Sense 4.0. I'll add directions on how to mod it manually later.
Instead of choosing gps.saga.so use gps.vision.so
lights.saga.so --> lights.vision.so
sensors.saga.so ----> sensors.vision.so
Swap modules folder from IceZSense or IceSenseWich.
Follow the guide and instead of saga files, copy vision files from IceZSense or IceSenseWich.
I'll add any further device specific changes if needed later.
Till then If you get stuck, ask in the thread and I'll try to answer it.
Similar steps are needed for porting Sense 3.5 too.
I recommend following roms to port, since they look good to me but you are free to choose yours.
CoolDroid 3.0
Primo-S 3.4
Credits :
proxuser
cjward
blk_jack for keymap fix (Will soon add my own fix for sense roms as soon as my exams get over)
Icecoldsandwich port | LewaOS Port | AOKP Port
First of all use cyanogenmod 9 RC 0 as base because andromadus is cause bootloops.
IceColdSandwich Port:
Take CM9 as base..
Remove app , media and framework folder from base rom..
Copy above folders from IceColdSnadwich to base ROM
Now Tough Thing !!
Sit Patiently and see what lib modules(*****.so) files are missing from base rom..
Copy all missing libraries to base ROM from IceColdSnadwich.
You need to make similar changes to android.policy.jar as suggested above for MIUI rom to fix autorotation.
If you can't get it to work. Then first get the rom booting then post the android.policy.jar you are using in your port, I'll make the required changes for you.
Similar steps are needed for LewaOS and AOKP project.
You can use the following roms to port:
IceColdSandwich
BlindLewa
AOKP (BlindIce)
If the above process doesn't works for you, try the following :
Code:
extract icecold sandwich content with kitchen.
Now swap these files :
Overwrite /system/etc with that from cm9 one
now look for files which are not in cm9 and add them manually from Icecold sandwich.
Swap /system/bin from cm9 one
Swap /system/lib
swap boot.img
swap /system/usr
chnage the following lines in build.prop:
ro.product.model=
ro.product.brand=
ro.product.name=
ro.product.device=
ro.product.board=
ro.product.cpu.abi=
ro.product.cpu.abi2=
ro.product.manufacturer=
ro.product.locale.language=
wifi.interface=
debug.sf.hw=1 (ALWAYS =1)
windowsmgr.max_events_per_sec=
with vision one.
In init.d folder delete all files except sysctl and 00banner...
Credits :
Blindnumb for helping port BlindIce
vampire36 for helping port IcecoldSandwich
Is this to port audacity as well?
Sent from my HTC Vision using XDA
jspina said:
Is this to port audacity as well?
Sent from my HTC Vision using XDA
Click to expand...
Click to collapse
I've tested till audacity beta 1, don't know about beta 2. Test and see, if you get stuck in bootloop, try to get a logcat.
ajhavery said:
I've tested till audacity beta 1, don't know about beta 2. Test and see, if you get stuck in bootloop, try to get a logcat.
Click to expand...
Click to collapse
Ok. Thanks I tried it with proxusers guide which is basically this without getting into any jar files or anything like that. I will try tonight and let you know but I wouldn't post the Rom if it works because I think you are working on it.
Sent from my HTC Vision using XDA
studying ,thank you. ^_^
YESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYESYES!!
<3 ajhavery
Wow. Thank you for the guide! This is more what I imagine XDA being like: a public forum for sharing knowledge, not keeping arcane secrets. Not pointing any fingers, of course. Our device has always had great and helpful devs.
This will not only help many aspiring devs to learn much about porting, but it also gives the users great perspective on the work involved in getting stuff working.
Awesome.
Sent from my HTC Vision using XDA
jspina said:
Ok. Thanks I tried it with proxusers guide which is basically this without getting into any jar files or anything like that. I will try tonight and let you know but I wouldn't post the Rom if it works because I think you are working on it.
Sent from my HTC Vision using XDA
Click to expand...
Click to collapse
I have written this guide to let someone take the development for the time being because I'm having my exams from monday till may 1st, after that I'm going on vacation for a week with my friends and after that I've to go for my summer internship. So, due to extremely busy schedule of mine, I would love to see any work from you.
I have got the rom booting with audacity beta 1, my last port is based on that, so I would recommend working on audacity beta 2 and If it is very hard then you can use files from my last release of MIUI-Au port, to get the rom booting.
It you get stuck, try to get a logcat so that I could help you.
Soon, when I find time, I'll try to add a sense rom porting guide for those who want to learn.
A suggestion : Look into development forums to learn more about porting.
Those who seriously want to learn should go through this link and read everything at least twice:
http://www.kandroid.org/online-pdk/guide/index.html
ajhavery said:
I have written this guide to let someone take the development for the time being because I'm having my exams from monday till may 1st, after that I'm going on vacation for a week with my friends and after that I've to go for my summer internship. So, due to extremely busy schedule of mine, I would love to see any work from you.
I have got the rom booting with audacity beta 1, my last port is based on that, so I would recommend working on audacity beta 2 and If it is very hard then you can use files from my last release of MIUI-Au port, to get the rom booting.
It you get stuck, try to get a logcat so that I could help you.
Click to expand...
Click to collapse
OK Thanks! I may look into it but I forgot I have to draw a card for my brothers 7th birthday tomorrow(It is a tradition in my family of 5 kids to draw birthday cards), so I wont be able to look into it until way late tonight or night time tomorrow.
I really appreciate that and would love any help as I am not that great with all of this. But I will try my best
Thanks for the great guide. I already started porting MIUIv4 with proxusers guide and figured out that I need to modify the jars to get it to work. Now this will save me a lot of time to fix some bugs that I still had. This guide comes perfectly timed for the weekend.
I would really appreciate a guide to port a sense rom as I'd like to learn more about this whole thing. Thanks again and good luck for your exam.
So long
Ciddy
i hope one of u guys gets a rom ported for us soon. i miss miui and my attempt at porting it failed
Once we get a more stable ICS base, me and a friend of mine will try porting MIUI. I'm not sure which MIUI v4 port to choose from though.
magic_android said:
Once we get a more stable ICS base, me and a friend of mine will try porting MIUI. I'm not sure which MIUI v4 port to choose from though.
Click to expand...
Click to collapse
I'm in for porting but i've exams too .... can't wait till my summer vactions start on may 15th
strawmetal said:
I'm in for porting but i've exams too .... can't wait till my summer vactions start on may 15th
Click to expand...
Click to collapse
Well, i'm going to have to try and make the port before my exams in june/july. It'll be my first port but i'm pretty interested in trying it out. If i think it's daily driver material and is worth releasing, i'm gonna go for it.
---------- Post added at 04:41 PM ---------- Previous post was at 03:45 PM ----------
Well, i realised i had some free time today, so i started trying to port thishttp://forum.xda-developers.com/showthread.php?t=1512565 to our phones.
I got up to step 8 and then ended up with a whole bunch of values that i couldn't find or match in the way that the guide instructed. I have no prior experience in porting or developing, but i am willing to learn. So if anyone knows how to help me, feel free to PM me. Btw, i managed to decompile the android.policy.jar file but from that point, when i went to edit PhoneWindowManager.smali, i couldn't find any matching values between what was listed in the guide and what i was seeing on my screen in notepad++, so i didn't know what to change in there.
magic_android said:
Well, i'm going to have to try and make the port before my exams in june/july. It'll be my first port but i'm pretty interested in trying it out. If i think it's daily driver material and is worth releasing, i'm gonna go for it.
---------- Post added at 04:41 PM ---------- Previous post was at 03:45 PM ----------
Well, i realised i had some free time today, so i started trying to port thishttp://forum.xda-developers.com/showthread.php?t=1512565 to our phones.
I got up to step 8 and then ended up with a whole bunch of values that i couldn't find or match in the way that the guide instructed. I have no prior experience in porting or developing, but i am willing to learn. So if anyone knows how to help me, feel free to PM me. Btw, i managed to decompile the android.policy.jar file but from that point, when i went to edit PhoneWindowManager.smali, i couldn't find any matching values between what was listed in the guide and what i was seeing on my screen in notepad++, so i didn't know what to change in there.
Click to expand...
Click to collapse
That is what I have been porting unsuccessfully. Did you get it booting?
magic_android said:
Well, i'm going to have to try and make the port before my exams in june/july. It'll be my first port but i'm pretty interested in trying it out. If i think it's daily driver material and is worth releasing, i'm gonna go for it.
---------- Post added at 04:41 PM ---------- Previous post was at 03:45 PM ----------
Well, i realised i had some free time today, so i started trying to port thishttp://forum.xda-developers.com/showthread.php?t=1512565 to our phones.
I got up to step 8 and then ended up with a whole bunch of values that i couldn't find or match in the way that the guide instructed. I have no prior experience in porting or developing, but i am willing to learn. So if anyone knows how to help me, feel free to PM me. Btw, i managed to decompile the android.policy.jar file but from that point, when i went to edit PhoneWindowManager.smali, i couldn't find any matching values between what was listed in the guide and what i was seeing on my screen in notepad++, so i didn't know what to change in there.
Click to expand...
Click to collapse
Editing android.policy.jar is not responsible to get the rom booting though. In PhoneWindowManager.smali search for the term I've told you : const v.....
and look at the results you get.
The one you need has its counterpart after 2 line number what I mean is that, if you find const/4 v1, 0x1 at .line 1097, then you should look for its counterpart const/4 v1, 0x0 after two line numbers, i.e. at .line 1099.
If you have found it, the it is the value you need to change.
Also it should have a comment including work mLidOpen.
It's easy if you look thoroughly 2-3 line above and below it. It'll let you know if you are at correct position or not.
@jspina: Just a thought, try using the base framework.jar smali instead of MIUI one, I've never tried it but might be worth a try to get the rom booting. I mean first try using base framework.jar file in your port, if you don't find success, If you don't find success, use search in classout directory of MIUI and swap everything with media or power in its filename by their base rom framework.jar counterparts.
Post if you get stuck.
ajhavery said:
Editing android.policy.jar is not responsible to get the rom booting though. In PhoneWindowManager.smali search for the term I've told you : const v.....
and look at the results you get.
The one you need has its counterpart after 2 line number what I mean is that, if you find const/4 v1, 0x1 at .line 1097, then you should look for its counterpart const/4 v1, 0x0 after two line numbers, i.e. at .line 1099.
If you have found it, the it is the value you need to change.
Also it should have a comment including work mLidOpen.
It's easy if you look thoroughly 2-3 line above and below it. It'll let you know if you are at correct position or not.
@jspina: Just a thought, try using the base framework.jar smali instead of MIUI one, I've never tried it but might be worth a try to get the rom booting. I mean first try using base framework.jar file in your port, if you don't find success, If you don't find success, use search in classout directory of MIUI and swap everything with media or power in its filename by their base rom framework.jar counterparts.
Post if you get stuck.
Click to expand...
Click to collapse
got stuck.
should I post a log? Although I think that it just wont work. I dont really know what they did or what I am doing wrong but I dont think audacity b2 will work as a base unless I were to actually update each file individually...
Hi all.
This thread only for developers! Only! No questions - when?!!!!!!!
This is my attempt to porting android on S8600.
I wrote custom bootloader - emmcboot, based on codeaurora LK-bootloader.
Bootloader is successfully start, work and trying to load android kernel from internal
microsd card.
Now is unsuccessfully,after type message "Uncompressing Linux... done, booting the kernel." device rebooted or stopped.
[370] Panel is power on
[370] Display initialized
[370] Display logo
[370] Waiting for modem+++
[370] Waiting for modem: Done
[370] smem ram ptable found: ver: 0 len: 6
[370] scratch: 0x8000000
[370] Starting in SD mode!
[370] SD_DETECT pin : 0x0
[380] Initializing MMC host data structure and clock!
[380] Error No. 2: Failure Initializing MMC Card!
[400] Decoded CID fields:
[400] Manufacturer ID: 27
[400] OEM ID: 0x5048
[400] Product Name: SD16G
[400] Product revision: 3.0
[400] Product serial number: 7C88FF04
[400] Manufacturing date: 2 2012
[410] Serial number -[410] serial number:
[410] partition misc doesn't exist
[410] error in emmc_recovery_init
[580]
kernel @ 208000 (4132528 bytes)
[580] ramdisk @ 1200000 (175204 bytes)
[580] cmdline = 'console=null androidboot.hardware=qcom user_debug=31'
[580]
Booting Linux
[580] smem ram ptable found: ver: 0 len: 6
[580] booting linux @ 0x208000, ramdisk @ 0x1200000 (175204)
[590] cmdline: console=null androidboot.hardware=qcom user_debug=31
Uncompressing Linux... done, booting the kernel.
source code for lk-bootloader for S8600:
https://github.com/Oleg-k/LK_BOOT_S8600
To build for S8600, type: "make -j4 s8600 EMMC_BOOT=1"
Also, i got memory dump, stage - after load oemsbl and before loading my bootloader.
as we see, oemsbl decompress and load apps_compressed.bin into memory,
starting at 0x200000.
https://www.dropbox.com/s/5wf6dp5gfgudkdc/MEM_DUMP_128MB.rar
And for for understanding boot process on MSM7x30, read this:
http://tjworld.net/wiki/Android/HTC/Vision/BootProcess#BootProcess
Welcome back my friend ))
If you able to port,I 100% will buy S8600
Good Luck
I was actually going to ask you what happened to the wave 3 port. Anyway Welcome back . But a question why don't you help rebellos and volk in the wave and wave II porting ? So the porting can be a bit more better. Just my question. :good:
Sounds interesting.
1.
You found ELF files for S8600 Boot ?
2.
You found way without JTAG, or JTAG is needed to write your Boot?
Thanx in advance.
Best Regards
CONFIG_DEBUG_LL
and
CONFIG_EARLY_PRINTK
plx <3
it's my current config for my kernel:
adfree said:
Sounds interesting.
1.
You found ELF files for S8600 Boot ?
2.
You found way without JTAG, or JTAG is needed to write your Boot?
Thanx in advance.
Best Regards
Click to expand...
Click to collapse
No, don't ELF files for S8600, i wrote new bootloader for boot linux kernel.
Now i use JTAG, but if we find a way to cript my bootloader,like appsboot.mbn,we will use regular multiloader
So cool!
http://forum.xda-developers.com/showthread.php?t=1443575
Blowfish encryption
Click to expand...
Click to collapse
Maybe PlatformDownloader_S8600_KI5.exe maybe have unsecured Boot...
But I can't flash nor I have connected my S8600 with RIFF...
TPs seems to small for my big Fingers...
Best Regards
oleg_k said:
it's my current config for my kernel:
Click to expand...
Click to collapse
Thanks. I'd check debug macros and debug uart configuration. There's few UART ports in it, and maybe kernel is printing to the wrong one... though this wouldn't explain why kernel unpacker is printing something (Uncompressing and booting comes already from zImage) - this would indicate that debug port number is correct. Are you sure that kernel and ATAGs location is correct, and RAM is set up properly by LK? Maybe something bad happens when kernel proceeds to enabling MMU and caches... I'm pretty clueless. :<
I collected some links I found useful in this article: http://xda-university.com/as-a-developer/porting-android-to-non-android-devices
Especially interesting for you might be last link in "Custom bootloader" section.
No, don't ELF files for S8600, i wrote new bootloader for boot linux kernel.
Now i use JTAG, but if we find a way to cript my bootloader,like appsboot.mbn,we will use regular multiloader
Click to expand...
Click to collapse
For S8500 I found way to write direct into OneNAND at:
Code:
0x0010 0001
No need to encrypt something...
With Multiloader... choose ETC.
http://forum.xda-developers.com/showpost.php?p=37229969&postcount=37
S8600 not tested...
This is far far away from perfect... but maybe helpfull.
Need someone who is able to remove restriction from ML to use lower adresses then 0x10000...
I was only able to change text strings... in ML...
Best Regards
On first page i posted bootloader source and memory dump, stage - after load oemsbl and before loading my bootloader.
To Adfree,
S8600 don't use OneNAND, used EMMC flash memory (like sd-card).
Today I've found S8600XXKI9.zip
I have forgotten this Firmware... but I have now short compared with Bootfiles from XXKJC... BIG differences... So I think this should be nearly identical with PlatformDownloader_S8600_KI5.exe
Still unsolved to decrypt or extract content of:
PlatformDownloader_S8600_KI5.exe
and
PlatformDownloader_S8600_KJ7.exe
Best Regards
Not my S8600... but user tried PlatformDownloader_S8600_KJ7.exe
It seems it was wrong Partition Table aka partition.bin...
Code:
Boot Binary Download Start Ch[0]
Appsboot 338.7KB OK[1.1s]
OemSbl 1757.7KB OK[1.8s]
ERR : NAK_FLASH_ERROR 0
Error : [B]partition Write[/B] [0.2s]
ERR : NAK_FLASH_ERROR 0
Download Start Ch[0]
Amss 16654.3KB OK[15.6s]
Apps 29622.3KB OK[54.1s]
_Open_Europe_Common 40370.2KB OK[73.5s]
(Low) 2980.3KB OK[1.9s]
ERR : NAK_INVALID_CONTENT 0
ERR : _Open_Europe_Common Erase
Now S8600 ask for QHSUSB_DLOAD
My first idea is Qualcomm QPST now...
Or maybe if Driver used, then Multiloader will work again... for second attempt..
Found only 64 Bit Driver yet... not tested nor Thread... only attachment...
http://forum.xda-developers.com/attachment.php?attachmentid=631288&d=1308601930
Will check also QPST to check what is needed...
Best Regards
Edit 1.
More Driver...
http://forum.xda-developers.com/showpost.php?p=21911621&postcount=2
Okay...
It seems for QPST fsbl.mbn is missing...
I can remember from old MSM6250 handsets it is mandatory to have all files for QPST... because otherwise you need JTAG...
Important...
Qualcomm not use Encryption for QPST files...
This is Samsung thingie + "end.bin" last 1024 Byte...
So decrypt all Bootfiles and cut last 1024 Byte...
For fsbl.mbn I will check JTAG dump from S8600...
Best Regards
Edit 1.
http://forum.xda-developers.com/showthread.php?t=1367055
downgrade_WM6_boot.zip contain fsbl.mbn ... maybe as example...
http://forum.gsmhosting.com/vbb/f634/htc-desire-s-qhsusb_dload-driver-1436354/
Found this...
Here is also fsbl.mbn maybe not available... or...
But maybe if we can attach such S8600 we can see few infos...
Best Regards
Edit 1.
About QPST Version contain this eMMC...
Code:
4. RELEASE NOTES
...
10/27/11 QPST [B]2.7.378[/B]
1) Add support for QSC11x5 CDMA only (4073) and CDMA+GSM (4074).
2) Fix problem with eMMC Software Download not correctly patching addresses > 8 GB.
10/13/11 QPST 2.7.377
1) Fix crash when QPSTServer.config are NULs (bad format).
2) Add model ID 4072 = "APQ8064". Apps processor only, no service programming.
3) Change flash programmer name from nprg9615.hex to nprg9x15.hex.
4) Add emergency download support for user partitions.
5) Fix case where user partition download fails if the flash programmer is on a file share.
6) Fix error case when add port is used but no port is specified.
7) Fix case where restoring an EFS file doesn't work if the file was modified by QXDM.
8) In Service Programming BC SMS fix case where if user enters 32 as the service type it get written to NV as 4096.
9) Fix case where a phone will stay in "no phone" state if the phone takes > 20 seconds to reboot.
10) Take care of cases in eMMC Software Download where we try to lock the disk volume but the drive letter isn't available.
11) Fix "server busy" issue when a device connects but it's modem isn't running.
12) Insert more status message in Memory Debug app so that we can see why fast unframed dump failed.
8/17/11 QPST 2.7.375
1) Add support for MDM9615 (model 4070). Rename model 4068 to 7627A-ANDROID from SURF7627A.
Add model 4071 (7627A-WinMob). Add 1x/UMTS service programming to 4068 and 4071.
2) eMMC Software Download: Don't try to lock volume if drive letter not present.
Devices that use GPT will not mount and get a drive letter assigned.
7/22/11 QPST 2.7.374
1) Added missing file to installer to fix Service Programming problem in 2.7.373.
2) For eMMC Software Download, abort the download if a sparse="true" directive is present.
Sparse files cannot be downloaded with QPST, only with fastboot.
3) Began the process of moving QPST application and server settings from registry to
configuration files.
4) Added more error checking to EFS Explorer file drop code.
7/5/11 QPST 2.7.373
1) Add support for SURF8960 model ID 4069.
2) Fix issue with Port Enable/Disable for IP Ports.
3) NAND Software Download: Correct flash programmer descriptions for 7225A, 7625A, 7227A, and 7627A.
4) Roaming List Editor: Added two new bands LTE 24 and LTE 25.
5) eMMC Software Download:
- Fix problem where some file names print as "(null)".
- Add support for Meta Build contents.xml file ("Build Contents"). The contents file will provide the path for the
rawprogram and patch files, extra search paths, and names of flash programmer and boot image files.
- Ignore unexpected elements in schema.
- Support zeroout directive to zero parts of partitions.
- Allow usage by app of "orderly" as well as surprise removal storage devices.
- Add support for computations in the <patch> (CRC32 for GPT support), <program>, and <zeroout> directives.
6) EfsExplorer:
- Enable reset button in Efs Explorer even if target not in offline mode.
- More text description in Mode column for Efs Explorer
- Modify the list context menu of Efs-Explorer.
- If the proposed item file size copy is > 2048 bytes, warn the user and bail out.
...
Adfree,
link pls for founded S8600XXKI9.zip
link pls for founded S8600XXKI9.zip
Click to expand...
Click to collapse
http://hotfile.com/dl/145796951/79ecec6/S8600XXKI9.zip.html?lang=de
Try this. If not then I search again...
About fsbl.mbn...
I have searched for fsbl_hw.c string in 4 GB JTAG dump SAMSUNG_GTS8600_FullFlash.bin...
Can not find so I think fsbl is not or in other area...
About your Memory Dump FROM_MEM_0_128MB.bin
I am not 100 % sure but maybe read problems...
Short tried to extract Cert, but string Qualcomm is not written correct...
Q5alcomm1
qualcoem.com
Click to expand...
Click to collapse
Best Regards
I try to read again memory dump )
thanks for links...
Also,
i find,what samsung used OKL4 Microkernel 3.0 (maybe 4.0)
http://wiki.ok-labs.com/Release/3.0
About ver 4.0 --
The OKL4 Microvisor is designed from the ground up as a high-performance mobile virtualization platform. It is a microkernel-based embedded hypervisor - called a Microvisor, with a small footprint and the right combination of performance and hardware support to target mobile telephony use. The OKL4 Microvisor 4.0 is distinguished by supporting mobile virtualization, componentization, and security, enabling a new generation of applications and capabilities with impact across the mobile ecosystem.
OKL4(with Qualcomm RTOS) also used in modem AMSS
http://forum.xda-developers.com/showthread.php?t=1829915
Need overview/list with Firmware packages with Bootfiles included...
Here this is what I have...
Later I will compare if difference...
Code:
XXKI9
XXKJC
S8600BOKJ1_TPLKJ1.rar
S8600BOKK6_S8500TPLKK7_T-Mobile.rar
S8600JPKK2_S8500OJPKK2_OJP.rar
S8600ZCLA1.7z
S8600NAKL1_S8600EPLKL1
Best Regards
Hello everyone. I read this forum for quite a while now and i got here some precious informations that helped me developing a new linux-based solution for qualcomm-chipped devices that are *totally* bricked.
I bricked my HTC One (m7) while trying to tweak it a few days ago and i was quite desperate since i only had it working for 1 day... My phone was consistently disconnecting from network and as a software developer, i thought it was a software problem of course. Once bricked i saw a small piece of paper stuck in the simcard slot when i opened it... Too late
Ok, that's all for the story. Once "dead", my phone started to show the infamous "DLOAD 9006" mode and i found some interesting pieces of software designed to fix that. But, no luck, that phone seems stuck in some kind of "bastard" mode, telling 9006 mode but refusing to act like a usb storage disk. Lots and lots of errors looking at the kernel log with dmesg.
Tried several kernels, 2.6, 3.16 & 4.4 & macintosh too, but really no luck.
And then i came with an idea : making my own stuff to unbrick that sh*t.
I found lots of informations on Qualcomm-based machines, including some info on iPhones and routers. Impossible to get a hold on the official Qualcomm DLOAD documentation, but some others seem to have better luck, and by reading engouh source code, i merged everything i found and made my own project on github.
So here it is, the "dloadtool" : github.com/jnaulet/dloadtool
Sorry i can't post links as i'm a newbie here, you'll have to copy it in your browser by yourself
Don't expect any documentation yet, don't expect binaries, i started to work on this on the 10th of march.
But i can tell you about the main syntax :
# dloadtool [ -F device] command [args...]
By default, the device is /dev/ttyUSB0, but you can change that with the F flag.
Commands are the following (for now) :
- reset (resets the Qualcomm, can be *really* useful)
- magic (sends a magic number) -> as i understood, will only work if chip is correctly loaded
- info (displays some info about the device)
- send XXXX... (sends hexadecimal values directly to the phone, useful for testing, no 0x prefix equired)
- loadhex file.hex (loads a .hex file in memory)
- loadbin file.mn (loads a .mbn file in memory and executes it)
- execute XXXX (executes code at XXX hex address, no 0x prefix required)
Now, you'll need an extra library called libcintelhex to build this program. Here's the source : github.com/martin-helmich/libcintelhex (same problem as above). This lib is required to load intel32 hex files (the MPRGXXX.hex files).
If, like me, you have no luck, your phone will be stuck in a undocumented 9006 mode. That's why you'll need to build the qcserial module i put in my project and patched for the HTC One M7. Just use the build.sh script and everything should go right. Then you'll probably need to type something like that :
# modprobe usb_wwan
# insmod qcserial.ko
So now's the deal. I successfully put my phone from "bad' 9006 mode to clean 9008 mode by using :
# ./dloadtool reset
Then, i could successfully load a piece of code typing
# ./dloadtool loadhex MPRG8064.hex
But program refuses to execute and seems to crash the Qualcomm. I need to unplug & re-plug it, reset it again.
I found lots of MPRGXXX.hex & .mbn files in the UFIBox.com software (if you're looking for them) but none seems to make a difference. Some don't load cause of a different memory map, some crash. :crying:
Maybe, as the chip is a 8064T (Krait 300 core), 8064 (Krait 200) code is not working, i don't know. If you got any kind of information that could help me, please, share ! Thank you. :fingers-crossed:
Some news
Here are some news...
I could finally get a hold a some Qualcomm documentation thanks to this forum, especially the 80-39912-1-E_DMSS_Download_Protocol.pdf on a thread i lost since (sorry).
I made some major updates to my source code, adding lots & lots of commands, some useless, some not so.
So here are the commands i designed :
Code:
#./dloadtool info -> Displays some basic info
#./dloadtool reset -> Hard reset
#./dloadtool magic -> Send magic (Streaming DLOAD protocol, useless for the moment)
#./dloadtool send <hex value> -> Send raw hex values (for testing purposes)
#./dloadtool loadhex <hexfile> [address] -> Loads a .hex file into RAM (IMEM for Snapdragon 600)
#./dloadtool loadmbn <mbnfile> [address] -> loads a .mbn file into RAM
#./dloadtool loadbin <binfile> [address] -> load a raw binary file into memory
#./dloadtool execute <address> -> Executes code at address (More info on this)
#./dloadtool infombn <mbnfile> -> Displays info about the mbn file (reads header)
#./dloadtool signhex <hexfile> <signaturefile> -> experimental. Concatenates hexfile & signature in a .mbn file & modifies header accordingly. Useless at the moment
#./dloadtool signmbn <mbnfile> <signaturefile> -> Same as above
#./dloadtool read <address> <length> -> Reads length bytes at address. Doesn't work in my PBL (only SBL)
#./dloadtool erase <address> <length> -> Erases length bytes at address. Warning: addresses are 20bits segment:offset calculations so probably useless on modern phones (probably used only in old qualcomm NOR flash stuff)
Now let's talk a little more about the HTC One i'm trying to unbrick with this tool.
Here are some info :
Code:
# ./dloadtool -F /dev/ttyUSB2 info
Software Version: PBL_DloadVER2.0
Protocol Version: 0x8
Min Protocol Version: 0x1
Max Write Size: 0x600
Model: 0x90
Device Size: 0x0
Device Type: 0x0
According to the documentation i have, protocol version 8 means the corresponding sheet is 80-39912-1-E_DMSS_Download_Protocol.pdf. Ok, i have it. And if i look inside, Min Protocol Version 1 means non-secure implementation :fingers-crossed: (no need for UNLOCK command at least). Device size & type are no relevant information.
I can load a hex file : :good:
Code:
#dloadtool -F /dev/ttyUSB2 loadhex MSM8064/MPRG8064.hex
< Software Version: PBL_DloadVER2.0
< Protocol Version: 0x8
Min Protocol Version: 0x1
Max Write Size: 0x600
Model: 0x90
Device Size: 0x0
Device Type: 0x0
Loading file MSM8064/MPRG8064.hex...
File size is 53658 bytes
Load address is 0x2a000000
< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< .< . Done
But i still can't run any file i have, CPU crashes.
So i tried something... Typing every command that's in the spec... And when i typed
Code:
#./dloadtool -F /dev/ttyUSB2 send 18
< 18 01 00 ba 21 02 da 99 c9 24 05 8c 75 8f a9 f4 | ....!....$..u...
25 08 47 c9 2c ab de 17 fd ce f0 1d 4d af f8 df | %.G.,.......M...
5d 67 53
0x18 command stands from "Public Key Hash Request". So there's a public key security system even in this little PBL emergency downloader... Very bad news... :crying::crying::crying:
According to ARM's documentation (didn't re-read Qualcomm's docs yet), this means it's highly possible that even this small primary boot loader needs to check a certificate & signature to allow the "go/exec" commmand.
Unlock command is probably obsolete (only 64 bits), now welcome to RSA encryption secured bootloaders !
This could explain why the MPRG8084.hex file is in fact an intel32-formatted version of a small .mbn file. If i show you the headers of a .mbn file, you'll probably understand what i mean :
Code:
#./dloadtool -F /dev/null infombn MSM8064/8064_msimage.mbn
Read successful
codeword : 0x844bdcd1
magic : 0x73d71034
Image type : SBL1
Load address : 0x2a000000
Body length : 83072
Code length : 83072
Signature address : 0x2a014480
Signature length : 0
Certificate address : 0x2a014480
Certificate length : 0
If i use a .hex file i converted, here's the result
Code:
#./dloadtool -D /dev/null mbninfo mprg8064.mbn
Read successful
codeword : 0x844bdcd1
magic : 0x73d71034
Image type : eHostDl
Load address : 0x2a000050
Body length : 53572
Code length : 53572
Signature address : 0x2a00d194
Signature length : 0
Certificate address : 0x2a00d194
Certificate length : 0
Now, my hypothesis is the CPU refuses to exec cause he wants to check the certificate & signature of the files i upload. But i don't have any of this, only Qualcomm & HTC own these files & they keep them no matter what, cause it's a source of profit for their customer services. :crying:
After two weeks of hard work, unbricking this phone not using JTAG seems hopeless and i'm very frustrated , i'm really mad at Qualcomm & HTC for not letting educated people take total control of a device they bought at a considerable price . Ok, mine was a bargain (before it crashed...), but that's not the point.
I will try to make contact with HTC to see if they can provide my some stuff, but i don't think they will cooperate.
To be continued ?
Some news again
Hello,
Here are the news i got... I made some research and i don't have any good news. :crying:
I started to look at some specs and found information about "the root of trust", part of a security system by ARM called "TrustZone".
Briefly, it's a certificate-based system, put once and for all in the SoC's ROM. Its goal is to ensure no "untrusted" code can be executed. By untrusted, they mean, not signed by the "correct" authority (whose public key hash is available by using the 0x18 command).
More info here : www dot embedded.com/design/safety-and-security/4438300/Securing-the-IoT--Part-2---Secure-boot-as-root-of-trust- AND here : www dot arm.com/products/processors/technologies/trustzone/
I'm no security specialist, but i can tell it will be really difficult to create a certificate that has the same 256 bits hash to sign any code. Collisions may exist in SHA-1 and MD5, but SHA256 is still considered solid.
So I asked Qualcomm about the files i needed to unlock my HTC One phone and here's their answer :
Any information other than what is listed on our website (URL listed below for your reference) is Proprietary to Licensees.
Unfortunately we are unable to assist with your inquiry. We recommend you follow-up with a vendor that carries this product and seek their feedback on your technical questions.
Please note, Qualcomm is the technology provider, not a manufacturer of consumer products and therefore we are unable to answer your product specific question. We hope this direction helps.
Thank you for your inquiry,
Qualcomm Technologies Inc.
Click to expand...
Click to collapse
In short, "ask HTC".
That's what i did and i have little hope. No answer at the moment. :fingers-crossed:
So now's the moment i complain about this exaggerated use of security. This is ridiculous. Exploits exist in Android itself, no need to access the service ports for that, so what's the point ? It seems really unlikely that anyone would install a trojan using the 9008 mode, counting on a user's mistake is a much safer bet.
Boot loaders have become a real pain in the *ss because of this technology. There's a primary boot loader (which requires certification), a secondary boot loader (same thing), a third boot loader (idem) and then android's boot loader (signed too). Is that a phone or a safe ?
For my last words, i recommend that we stay away from the manufacturers that use these technologies to make more and more profit, treating their customers as prisoners.
Stay safe, stay away from this sh*t !
I am looking at this thread here for the first time and thanks for your contribution. Do your tools only work on linux kernels, what about Solaris? I have both is why I ask...
I too am having an issue finding the right programmers...I noticed when using windows based tools to send binaries in 9008 mode that my phone would reset or lose the ability to do the handshaking process. I am going to mark your site on github and take a deeper look at this. This tool may be what I am looking for or at least another option. Thanks!
nate0 said:
I am looking at this thread here for the first time and thanks for your contribution. Do your tools only work on linux kernels, what about Solaris? I have both is why I ask...
I too am having an issue finding the right programmers...I noticed when using windows based tools to send binaries in 9008 mode that my phone would reset or lose the ability to do the handshaking process. I am going to mark your site on github and take a deeper look at this. This tool may be what I am looking for or at least another option. Thanks!
Click to expand...
Click to collapse
As long as you device is recognized as /dev/<something>, this should work in either system, using the -F option to select the right device, if needed. The kernel patch is for linux only and should not be required at all (unless your phone shows as 9006 mode but is in fact 9008, like mine was).
As i'm a linux user, i got some more info by using dmesg (to know if a driver was loaded correctly) and lsusb (to get the phone's mode). I don't know if these tools are available on Solaris. But there are probably alternative commands, though.
Beware, using this tool, i was able to reset & load files into the phone's memory, but not to run any code. I hope you're lucky enough to have a phone that's not "secure boot"-protected.
I tried a hex file labelled GPP8064.mbn and I believe it executed on my Nexus 7.
Dmesg was flooded with 14 devices that looped but could not connect successfully.
Perhaps this information would help you further?
Sent from my ONE A2005 using Tapatalk
when I launch your program (dloadtool) I got
./dloadtool -F /dev/ttyUSB0 info
< Invalid CRC!!!
Error receiving software version!!
< Invalid CRC!!!
Errore di segmentazione
marte3707 said:
when I launch your program (dloadtool) I got
./dloadtool -F /dev/ttyUSB0 info
< Invalid CRC!!!
Error receiving software version!!
< Invalid CRC!!!
Errore di segmentazione
Click to expand...
Click to collapse
Same here, trying to use it on a US s8+ (sd835)
can anyone supply me the download link please