Introduction:
The SPro uses DA80 images along with the DA80 Download tool to factory fix/flash SPros.
It's the analog of using QDLtool for the S5/V and the equvilent of NVflash payloads for the S7/S10.
Unlike qdltool or nvflash payloads, DA80 images are not their consitutant files.
In file archiving teminology it's a solid archive with no compression.
File layout:
Code:
DA80 image layout
0x0 - 0x39 empty space
0x40 - 0x7f header
0x80 - 0xbf entry1
0x192 - 0xff entry2
...
0x40+64n - 0x7f+64n entryn
...
0x7f+64n+1 - <file 1 offset>-1 file1
<file 1 offset> - <file 2 offset>-1 file2
...
<file n offset> - <file n offset>-1 filen
entry layout
0x0 - 0x31 filename
0x32 - 0x63 size of file (offset) [in bytes (little-endian)]
(My math in the explanation might be wrong, but it's explaination below is definitely correct)
Explaniation:
20 bytes of empty space at beginning of file
header
Filename equvilent: DA80_android
Filesize equvilent: 0x13 bytes
file entries
File name
Size of file (ie it's offset), in bytes, in little-endian
Actual files
There's no padding at all, each file immediately ends and the next one begins.
There's no absolute addresses for any of the files, it's merely
file1+offset = file2
file2+offset = file3
until the end.
Conclusion:
Overall it's a simple file format with no error checking, encryption, or obfuscation.
As a note: the ext4 files inside DA80 images are actual ext4 sparse files.
They must be run though a tool such as sgs2toext4.jar to be read by some ext4 file readers (such as ext2explore)
Related
As I've heard some people have problems with working with XIP sections of some ROMs... as for example Asus P525 or other devices, here's a little tiny tutorial about this issue. What's the problem with them? It's their XIP sections are compressed with SRPX algorithm.
In some Asus kitchens in the ROM directory you have a ROM.TPL file. How to use it?
1. Get the OSNBTool from the attachement (it's a fantastic tool from Weisun of PDAclan.com).
2. Do:
Code:
>osnbtool -d rom.tpl 1 xip.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Deompress processing...
Successfully decompressed to xip.bin
3. Run XIPPort and click "dump xip.bin".
4. Do your work with a XIP section.
5. After you're finished, issue "realloc P" and "build xip_out.bin" in XIPPort.
6. Do:
Code:
>osnbtool -c rom.tpl 1 xip_out.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Source OS image:
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Source Part-1 Size: 1AC400
--------------------------------------
Compress processing...
NEW Uncompressed size: 2D5000
NEW Compressed size: 1A6BF6
New Part Size: 1A71E6
Successfully compressed xip_out.bin into rom.tpl.NEW
7. You're done!
It turns out that a dumprom.exe and buildxip.exe tools handle those XIPs really well, too - and even better, as they do better reallocation of modules.
So, it can go as this:
Code:
>dumprom rom.tpl
IMGFS guidBootSignature: F8 AC 2C 9D E3 D4 2B 4D BD 30 91 6E D8 4F 31 DC
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 0000001E
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
Address: 00000200, dwBlockSignature: 2F5314CE
dwNextHeaderBlock: 00000000 (size: FFFFFE00)
Header type: FFFFFFFF, Addr: 00000208
Empty header
Header type: FFFFFFFF, Addr: 0000023C
Empty header
Header type: FFFFFFFF, Addr: 00000270
Empty header
Header type: FFFFFFFF, Addr: 000002A4
Empty header
Header type: FFFFFFFF, Addr: 000002D8
Empty header
Header type: FFFFFFFF, Addr: 0000030C
Empty header
Header type: FFFFFFFF, Addr: 00000340
Empty header
Header type: FFFFFFFF, Addr: 00000374
Empty header
Header type: FFFFFFFF, Addr: 000003A8
Empty header
Now you have new files: boot.bin, msflsh.bin and romhdr.bin, and a new folder XIP. Edit your XIP folder as you want.
Now, in ..\temp\dump folder put your .VM and .ROM folders and issue:
Code:
>buildxip
BUILDXIP 0.54 Copyright (c) 2007-2008 bepe 30 Jan 2008
Slot 0 Boundary: 0x01fa0000
Slot 1 Boundary: 0x03e18000
RAMStart: 0x88868000
RAMFree: 0x888c6000 - 0x8c000000 L0373a000
KernelFlags: 0x00000000
FSRamPercent: 0x00000004
Done!
In the end put your new created out.bin file into your tpl file:
Code:
>osnbtool -c rom.tpl 1 out.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
Extra data bytes : 0x00000000
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Source OS image:
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Source Part-1 Size: 1AC400
--------------------------------------
Compress processing...
New part size larger than old part in source OS image!
Rebuilding partition structure...
NEW Uncompressed size: 2E7000
NEW Compressed size: 1B1664
New Part Size: 1B1C78
Successfully compressed out.bin into rom.tpl.NEW
and you're done!
Hello utak3r.
This info is really important for me as I have an Eten device. Although, I've tried several times to build a XIP using "buildxip" (with or without -b flag - I don't know exactly what it does) but my rom doesn't boot.
I didn't even tried to change anything in XIP folder. Only dumped the XIP using "dumprom" and then build again to test it. Was I supposed to do something in the middle? Any idea?
bgcngm said:
with or without -b flag - I don't know exactly what it does
Click to expand...
Click to collapse
This flag tells if it should take another, external boot.rgu file, or the included one. So, you should do it without this flag.
bgcngm said:
but my rom doesn't boot.
Click to expand...
Click to collapse
The problem may be not in the building it, but in inserting it back. Some devices don't like changing the partition's size, for instance...
Check, what was the original xip.bin size and try to fill your new one with 0xFFs to this size - maybe it will help...
Another thing: give here full outputs from all the steps.
utak3r said:
The problem may be not in the building it, but in inserting it back. Some devices don't like changing the partition's size, for instance...
Click to expand...
Click to collapse
I already thought that the problem was XIP insertion, but then I found XIPKitchen.
With a XIP created by XIPKitchen, I can successfully create a bootable rom, even with a different XIP partition size. I'm happy because those XIP's are working, however XIPKitchen doesn't integrates nicely in a rom kitchen. The user has to manually input the files and select some options in the program and I wanted to build the new XIP silently which is what buildxip does.
Do you know what could be the problem? I might be missing something... like rellocating the modules... But as I said before, I tried to build the XIP without touching it, simply by dumping and then rebuilding it. In that case there was no need to rellocate the modules, right?
utak3r, don't you know what could be the problem?
Hi bro
In some Asus kitchens in the ROM directory you have a ROM.TPL file
Click to expand...
Click to collapse
use tool NB0 KITCHEN mrtoto which extracting&inserting partition xip in file out.bin in to NewROM.tpl
extracting out.bin use XipKitchen or buildrom bepe,ren xip_out_new.bin to out.bin ,move to directory Rom.tpl end push button "Build Template" in NB0 KITCHEN mrtoto
THANKS A LOT !!
Awesome tool, had troubles extracting one of the xip files since a LONG time, this just did the trick and it's nifty features like putting romhdr, o32, e32 headers nicely were also helpful.
It seems that there is about 100 MB Missing... I just guess is EXTROM
It could very easy to test that - different EXTROM but same Flash.bin.
The total free ROM space unchanged, even your EXTROM just used a few MB
If the EXTROM could be used, then it could be great help for cooking
The files may relate to FLASH.Header and partition.mbn. could anyone have a good try?
But...
pdocread.exe -l
411.25M (0x19b40000) DSK1:
| 1.87M (0x1df000) Part00 BOOT SECTION image
| 5.00M (0x500000) Part01 XIP RAM Image
| 84.25M (0x5440000) Part02 IMGFS file system
| 320.13M (0x14020000) Part03 legit DOS partition
handle#1 ef638fc6 320.13M (0x14020000)
handle#2 ef6adea6 84.25M (0x5440000)
handle#3 2f6ade82 5.00M (0x500000)
handle#4 4f6ade3a 1.87M (0x1df000)
Total is just 411.25, about 100MB (0x064C0000) seems missing....
For Part02, I could know is imgfs, and Part00 seems EXTROM, but where is disappear 100M?
partition table:
Code:
Partition-Info :
------------------
MIBIB
---------------------------------------------------------
Page: 0x6
Size: 0x4
Address: 0x000C0000 - 0x00140000
Block: 0x00000180 - 0x00000280
Flash: 0xFEFFFFFF
SIM_SECURE
---------------------------------------------------------
Page: 0x4
Size: 0x2
Address: 0x00080000 - 0x000C0000
Block: 0x00000100 - 0x00000180
Flash: 0xFEFFFFFF
FSBL
---------------------------------------------------------
Page: 0x180
Size: 0x1E
Address: 0x03000000 - 0x033C0000
Block: 0x00006000 - 0x00006780
Flash: 0xFFFFFFFF
OSBL
---------------------------------------------------------
Page: 0x180
Size: 0x1E
Address: 0x03000000 - 0x033C0000
Block: 0x00006000 - 0x00006780
Flash: 0xFFFFFFFF
AMSS
---------------------------------------------------------
Page: 0x4650
Size: 0x708
Address: 0x8CA00000 - 0x9AB00000
Block: 0x00119400 - 0x00135600
Flash: 0xFFFFFFFF
EFS2
---------------------------------------------------------
Page: 0x1F40
Size: 0xC8
Address: 0x3E800000 - 0x40100000
Block: 0x0007D000 - 0x00080200
Flash: 0xFFFFFF01
DSP1
---------------------------------------------------------
Page: 0x3E80
Size: 0x258
Address: 0x7D000000 - 0x81B00000
Block: 0x000FA000 - 0x00103600
Flash: 0xFFFFFFFF
FOTA
---------------------------------------------------------
Page: 0x80
Size: 0x64
Address: 0x01000000 - 0x01C80000
Block: 0x00002000 - 0x00003900
Flash: 0xFFFFFFFF
EXTROM
---------------------------------------------------------
Page: 0xC350
Size: 0x7D0
Address: 0x86A00000 - 0x96400000
Block: 0x0010D400 - 0x0012C800
Flash: 0xFFFFFFFF
APPSBL
---------------------------------------------------------
Page: 0x300
Size: 0x32
Address: 0x06000000 - 0x06640000
Block: 0x0000C000 - 0x0000CC80
Flash: 0xFFFFFFFF
APPS
---------------------------------------------------------
Page: 0x80
Size: 0xC
Address: 0x01000000 - 0x01180000
Block: 0x00002000 - 0x00002300
Flash: 0xFFFFFFFF
EFS2APPS
---------------------------------------------------------
Page: 0xFFFFFFFF
Size: 0xFFFF
Address: 0xFFFE0000 - 0xFFFC0000
Block: 0x001FFFC0 - 0x001FFF80
Flash: 0xFFFF02FF
good investigation ! I hope you can find a Way to reduce the allocated space, sadly I can't help you with this...keep the research !
Arto said:
good investigation ! I hope you can find a Way to reduce the allocated space, sadly I can't help you with this...keep the research !
Click to expand...
Click to collapse
Thank you also
The difficult problem is that, I'm not much understanding NAND Flash...
But, it seems that, after flashing ROM with new partition.mbn, the size of ExtRom could be changed.
At this moment, I'm not sure that the Hex files should be also changed or not ...
Code:
EXTROM
---------------------------------------------------------
[COLOR="Red"] Page: 0xC350
Size: 0x7D0[/COLOR]
Address: 0x86A00000 - 0x96400000
Block: 0x0010D400 - 0x0012C800
[COLOR="Red"] Flash: 0xFFFFFFFF[/COLOR]
Form Page (seems like format pagepool), the maximum ExtROM could be 50MB, that's the limit for a cook to modify ExtROM.
Of cause, if we could modify ExtROM size, then we could include more module in to Image
Moreover, including ExtROM, the boot system could used up to 93.674MB
my extrom take 7mb...so if the extrom allocated space can be changed it would be reallocated to application space? Qazer found a way to change page pool size, maybe it can help you on this !
edit, what is NAND flash?
Arto said:
my extrom take 7mb...so if the extrom allocated space can be changed it would be reallocated to application space? Qazer found a way to change page pool size, maybe it can help you on this !
edit, what is NAND flash?
Click to expand...
Click to collapse
After rearranged the partition table, it could be like this:
Code:
offset size
SIM_SECURE 0x4 0x2
MIBIB 0x6 0x4
FOTA 0x80 0x64
APPS 0x80 0xC
FSBL 0x180 0x1E
OSBL 0x180 0x1E
APPSBL 0x300 0x32
EFS2 0x1F40 0xC8
DSP1 0x3E80 0x258
AMSS 0x4650 0x708
EXTROM 0xC350 0x7D0
EFS2APPS 0xFFFFFFFF 0xFFFF
It could be much strange that some 'partitions' are overlapping!
Emmm, I forgot the order flashing these programs (.mbn), however, the ExtROM could be the last one to flash in the phone...
If somebody could tell me the order, then it could be much clear the process
Seems changed size could be OK, but I just wonder that what about ImageFS...
BTW, for term 'NAND flash', just wikipedia it
the best thing we can do is to reallocate this space in a virtual ram driver, and dont use the extrom space anymore. I noticed that the extrom files (cabs,tsk..) are in the windows folder of the device when you explore the windows folder.
So Is there a virtual ram driver or is there a way to do that, we don't need space, we need ram alternative.
anyway, don't know if it is possible to do such a thing on winmo devices...
( a kind of swap space....)
ocman said:
the best thing we can do is to reallocate this space in a virtual ram driver, and dont use the extrom space anymore. I noticed that the extrom files (cabs,tsk..) are in the windows folder of the device when you explore the windows folder.
So Is there a virtual ram driver or is there a way to do that, we don't need space, we need ram alternative.
anyway, don't know if it is possible to do such a thing on winmo devices...
( a kind of swap space....)
Click to expand...
Click to collapse
I think we should hardmod to add more RAM instead of using NAND flash, to avoid damaging it faster
Emmm, at this time I could not be sooooooo brave to flash my only phone
I just only change 0x7D0 (D0 07 00 00) to 0x3E8 (E8 03 00 00)....
If I try to flash with new partition.mbn,the phone turn into FTM Mode
But I just put partition.mbn, extrom.bin and two hex files only to the flash tool...
It sounds like I should put all files in that...
Then, finally these two hex files ENPRG8650.hex and NPRG8650.hex should be also modified.
Before:
XIP.BIN Target Size: 00435B00 AdjSize: 0043FFFF
ULRD in Payload Start:00000400 Size:0001F3FF End:0001F7FF
XIP in Payload Start:0001F800 Size:0046DFFF End:0048D7FF
IMG in Payload Start:0048D800 Size:04D267FF End:051B3FFF
FAT in Payload Start:00000000 Size:00000000 End:00000000
After:
XIP.BIN Target Size: 00435B00 AdjSize: 0046DFFF
ULRD in Payload Start:00000400 Size:0001F3FF End:0001F7FF
XIP in Payload Start:0001F800 Size:0046DFFF End:0048D7FF
IMG in Payload Start:0048D800 Size:04D267FF End:051B3FFF
FAT in Payload Start:00000000 Size:00000000 End:00000000
XIP PagePool Sign not Found!
XIP PagePool from: 16 Mb, to: 20 Mb
Payload resized and XIP Inserted into: OS-new.nb.payload
ERROR! (errorlevel: -1073741819)
ERROR executing: kitchen_build_rom.bat
ERROR!!!
Wait some seconds...
No ''SVN'' folders present...
Restored Original config.txt...
Temp config.txt Deleted!!!
...?
I need the retail edition Note 3 boot.img from any of the retail Odin tars. It must be from an Odin tar and I dont wan't to download an entire Odin tar.md5 if I don't have to. Im trying to confirm the base address to the Dev kernel that I manually made by hexediting the dev boot.img (by finding 1F 8B, and manually spliting the ramdisk from the zimage etc. etc.) However when I recompile it its only 9.9 mb, but the base address looks much more believable, as shown below. Thanks!
After Manually editing:
Kernel Size : 8525824 bytes
Kernel Base Address : 0x10000000
Ramdisk Size : 1359586 bytes
Ramdisk Load Address : 0x11000000
Second Stage Size : 0 bytes
Second Stage Load Address : 0x10f00000
Page Size : 2048 bytes
ASCIIZ Product Name : (None)
Command Line: "console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F"
Click to expand...
Click to collapse
Before Manually editing:
Kernel Size : 8523552 bytes
Kernel Base Address : 0x00000000
Ramdisk Size : 1353370 bytes
Ramdisk Load Address : 0x02000000
Second Stage Size : 0 bytes
Second Stage Load Address : 0x00f00000
Page Size : 2048 bytes
ASCIIZ Product Name : "SERPHLUV001"
Command Line: "console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F"
Click to expand...
Click to collapse
Surge1223 said:
I need the retail edition Note 3 boot.img from any of the retail Odin tars. It must be from an Odin tar and I dont wan't to download an entire Odin tar.md5 if I don't have to. Im trying to confirm the base address to the Dev kernel that I manually made by hexediting the dev boot.img (by finding 1F 8B, and manually spliting the ramdisk from the zimage etc. etc.) However when I recompile it its only 9.9 mb, but the base address looks much more believable, as shown below. Thanks!
After Manually editing:
Before Manually editing:
Click to expand...
Click to collapse
Verizon N3 MJE Retail boot.img
Greetings to all.
I have a Samsung SM-G531M Galaxy Grand Prime. Android 5.1
By mistake delete a system binary (linker) and now the phone does not start. And every time I try to start it in recovery (loop) mode but I have the FRP lock. Only the downlad mode works for me.
Can you copy the binary linker by odin? Ie edit the stock rom and put only the linker (delete all, just leave / system / bin / linker).
If so, I have tried modifying the stock rom, but I can not extract a file from boot.img (file_contexts from the boot.img \ ramdisk) that it is essential to package the new modified system(using program Auto Tool v3.0 x64).
-My system is windows 7.
-CarlivImageKitchen_x64
Your image: boot.img
Create the boot folder.
*Printing information for "boot.img"
*Unpack image utility by carliv @ xda
*Header:
**Magic: ANDROID!
**Magic offset: 0
**Page size: 50331648 (0x03000000)
**Base address: 0x10000000
**Kernel address: 0x10008000
**Kernel size: 6294484 (0x00600bd4)
**Kernel offset: 0x00008000
*>> kernel written to 'boot / boot.img-kernel' (6294484 bytes)
**Ramdisk address: 0x11000000
**Ramdisk size: 1532010 (0x0017606a)
**Ramdisk offset: 0x01000000
*>> ramdisk written to 'boot / boot.img-ramdisk.unknown' (1532010 bytes)
**Second address: 0x10f00000
**Tags address: 0x0001f800
**Tags offset: 0xf001f800
**Dt size: 268435712 (0x10000100)
*>> device_tree written to 'boot / boot.img-dt' (268435712 bytes)
Compression used: unknown
Unpacking the ramdisk ....
The system can not find the specified batch label: unknown
And the ramdisk folder appears empty.
Thanks in advance.