Related
There is very little technical information on PIT files , so this thread is an attempt to find out some real details about PIT files, and perhaps eventually be able to create our own PIT files (by modifying Samsung ones, probably).
First, what we think we know PIT files do:
- PIT files only affect the 'STL' devices. That is, it affects the OneNAND and not the MoviNAND.
- PIT files appear to control the sizing (and maybe number) of STL devices that appear in Linux.
- PIT files appear to be used by Odin to map filenames inside .tar archives to STL partitions.
STL files are quite small, at under 2KB in size. Most of the file is made up of 0s. I have tried to compare the differences between the 512 513 and 803 PIT files we have available.
All the PIT files start with 76 98 34 12 0D - probably a signature to show it is a PIT file.
[Unimportant]
The 803 PIT file then has 00s all the way to the next common point. The 512 and 513 both have common data till the next common point - but this can't be too important as the 803 just has 00s.
The next common bit seems to read the following:
"oft IBL+PBL Server\90\To boot.bin inn; C:\Program Files\ESTsof
This probably indicates something to Odin. Strange that it has C:\Program Files\ - build path for the PIT file?
Next we have some 0s with common 1s inside them, followed by the word PIT, then more 0s, and then ries.pit. All common from here on with the words 'EFS' and 'efs.rfs'. Probably telling odin to map the efs.rfs file to the 'EFS' token. Tokens probably defined either in the kernel, or in the closed source STL library. More of the same of this, with 'SBL' 'sbl.bin', 'SBL2' 'sbl.bin' -- Both SBL and SBL2 map to the same sbl.bin file?
'PARAM' to 'param.lfs'
'KERNEL' to 'zImage'
'RECOVERY' to 'zImage' (this one is interesting - could we have seperate zImage and recovery? Could save some RAM here!)
[/Unimportant]
And now we'r onto the actual changes between the PIT files. 'FACTORYFS' maps to 'factoryfs.rfs'. However, before the FACTORYFS token, there are some bytes that likely control the partition sizes.
FACTORYFS
803 : A2 04 : 41476
512 : 7A 04 : 31236
513 : CA 04 : 51716
DBDATA
803 : F0 01 : 61441
512 : 18 02 : 6146
513 : C8 01 : 51201
CACHE
803 : 8C
512 : 8C
513 : 8C
MODEM
803 : 32
512 : 32
513 : 32
So there we have it. The only real changes between the PIT files are some seemingly garbage header information in 512/513 that is missing from 803, and FACTORYFS and DBDATA have different numbers -- probably sizes.
So assuming FACTORYFS maps onto /system, we can see that the only differences in the PIT files is moving space back and forwards between /dbdata and /system. The numbers themselves don't mean anything to me - can anybody work it out?
The numbers are little-endian, so you need to read them backwards per bytes. So instead of A12 it's actually 120A, etc. If you do so, you can see that the difference between 803 and 512 are actually minor, 40 "units" are shifted between probably DBDATA and SYSTEM.
Btw: doesn't the heimdal project klnow something about the pit files?
Nice, that gives us
FACTORYFS
803 : 04 A2 : 1186
512 : 04 7A : 1146
513 : 04 CA : 1226
DBDATA
803 : 01 F0 : 496
512 : 02 18 : 536
513 : 01 C8 : 456
1186+496=1682
1146+536=1682
1226+456=1682
So we have a match.
Now to work out why the fat.format can work with 536, but not with 496
EDIT: Also, need to determine why some roms require certain PIT files. Only possibility I can see is that junk in the header - could be some type of allow list for firmwares. The 803 PIT should therefore work on all firmwares, since it just has 00s. Maybe.
In 803.pit (compared to the .512 one) the system partition size has been increased by 10MB, while DBDATA partition size has been decreased the same amount (10MB).
PS: Dump the BML2 partition. The dump contains current partition mapping.
Hope this helps
RyanZA said:
Nice, that gives us
FACTORYFS
803 : 04 A2 : 1186
512 : 04 7A : 1146
513 : 04 CA : 1226
DBDATA
803 : 01 F0 : 496
512 : 02 18 : 536
513 : 01 C8 : 456
1186+496=1682
1146+536=1682
1226+456=1682
So we have a match.
Now to work out why the fat.format can work with 536, but not with 496
EDIT: Also, need to determine why some roms require certain PIT files. Only possibility I can see is that junk in the header - could be some type of allow list for firmwares. The 803 PIT should therefore work on all firmwares, since it just has 00s. Maybe.
Click to expand...
Click to collapse
I think the main cause is that some firmwares simply don't fit in the space reserved for them. Some of the m have larger system, some of them have larger dbdata partitions. Only a guess though, I think I start flashing pit files just for fun...
RazvanG said:
In 803.pit (compared to the .512 one) the system partition size has been increased by 10MB, while DBDATA partition size has been decreased the same amount (10MB).
Hope this helps
Click to expand...
Click to collapse
10MB = 40 units... That would give us 1 unit = 256kbyte. Nice.
So this means:
BOOT (bml01) = 01 = 1 = 0.25 MB (bootloader)
PIT (bml02) = 01 = 1 = 0,25 MB (the partition table)
EFS (bml03) = 28 = 40 = 10 MB (imei data and such)
SBL (bml04) = 05 = 5 = 1,25 MB (secondary bootloader)
SBL2 (bml05) = 05 = 5 = 1,25 MB (secondary bootloader backup)
PARAM (bml06) = 14 = 20 = 5 MB (the images shown when something is wrong)
KERNEL (bml07) = 1E = 30 = 7,5 MB (kernel image)
RECOVERY (bml08) = 1E = 30 = 7,5 MB (kernel image backup)
FACTORYFS (bml09) = 47A = 1146 = 286,5 MB (/system)
DBDATA (bml10) = 218 = 536 = 134 MB (/dbdata)
CACHE (bml11) = 8C = 140 = 35 MB (/cache)
MODEM (bml12) = 32 = 50 = 12,5 MB (software for wireless)
total: 501 MB
sztupy said:
I think the main cause is that some firmwares simply don't fit in the space reserved for them. Some of the m have larger system, some of them have larger dbdata partitions. Only a guess though, I think I start flashing pit files just for fun...
Click to expand...
Click to collapse
Not sure how true this can be -- Take 512 vs 513 for example. Newer Eclair roms stopped working on 513, and required 512. However, 513 has a smaller dbdata and larger system than 512. Since we know that a clean rom when flashed has a /dbdata of around 2mb, or 1% or so of available space, it can't be space related.
Must be more to than simple space allocations.
EDIT: And 501MB means we have space left over. Where is it hiding?
RyanZA said:
Not sure how true this can be -- Take 512 vs 513 for example. Newer Eclair roms stopped working on 513, and required 512. However, 513 has a smaller dbdata and larger system than 512. Since we know that a clean rom when flashed has a /dbdata of around 2mb, or 1% or so of available space, it can't be space related.
Must be more to than simple space allocations.
EDIT: And 501MB means we have space left over. Where is it hiding?
Click to expand...
Click to collapse
Yes, but the flashed dbdata.rfs was probably actually a large partition, that didn't fit into the allocated space.
Yes, the missing 11MB is strange, unless there is a 1MB "safety" gap between two partition (12 partitions = 11 gaps), or some other data.
EDIT: No, dumped BML0, it's only 501MB in length. The missing part might still be some space needed for the BML and STL to work.
Hi. I'm sorry for hijacking this thread but I need professional help from some geniuses (genii) and apparently you guys are firmware gurus.
Once you guys figure out how PIT files work, can you please help me figure out how to force flash Korean firmware onto an international phone without bricking it? The reason why I would like to do this, is because the Korean version has some really nice features for example native call recording (3rd party call recorders have bad quality). I made a thread for it here
Thanks a lot, köszönöm szépen!
Galaxy S I9000 PIT structure:
512.pit
PBL: 256KB (Primitive Bootloader)
PIT: 256KB
EFS: 10240KB (Non Volatile Memory)
SBL(1): 1280KB (Primary)
SBL(2): 1280KB (Backup)
PARAM: 5120KB
KERNEL(1): 7680KB (Primary)
KERNEL(2): 7680KB (Backup)
FACTORYFS: 293376KB
DBDATAFS: 137216KB
CACHE: 35840KB
MODEM: 12800KB
Total: 513024KB
513.pit
PBL: 256KB
PIT: 256KB
EFS: 10240KB
SBL(1): 1280KB
SBL(2): 1280KB
PARAM: 5120KB
KERNEL(1): 7680KB
KERNEL(2): 7680KB
FACTORYFS: 313856KB
DBDATAFS: 116736KB
CACHE: 35840KB
MODEM: 12800KB
Total: 513024KB
803.pit
PBL: 256KB
PIT: 256KB
EFS: 10240KB
SBL(1): 1280KB
SBL(2): 1280KB
PARAM: 5120KB
KERNEL(1): 7680KB
KERNEL(2): 7680KB
FACTORYFS: 303616KB
DBDATAFS: 126976KB
CACHE: 35840KB
MODEM: 12800KB
Total: 513024KB
In case there is backup blocks (e.g SBL and Kernel, Odin flashes them both while executing the flashing process).
dillovic said:
Hi. I'm sorry for hijacking this thread but I need professional help from some geniuses (genii) and apparently you guys are firmware gurus.
Once you guys figure out how PIT files work, can you please help me figure out how to force flash Korean firmware onto an international phone without bricking it? The reason why I would like to do this, is because the Korean version has some really nice features for example native call recording (3rd party call recorders have bad quality). I made a thread for it here
Thanks a lot, köszönöm szépen!
Click to expand...
Click to collapse
Galaxy S M110S is completely different hardware.
All other I9000 variants use Infineon X-Gold 616 baseband (Modem), while M110S uses Qualcomm baseband chip.
Made a try modifying the PIT file, to add more space to /dbdata and take away space from /system. I added around 25MB extra space to /dbdata.
Wasn't that hard actually, and I didn't encounter many problems (except the fact that the values are for the bare bml device, from which the stl has an extra 4-10% overhead so instead of the originally planed 35MB I could only spare 25).
If anyone's interested I can upload the modified pit and rom files.
Some remarks / questions:
- If we use the bare BML device instead of the STL I know we lose wear leveling (at least according to the rfs docs from samsung), but can't we use yaffs or similar on those devices? Or what if we (can we?) use cramfs for the /system on the BML, to gain even more space we could use for the /dbdata partition?
- The overhead the STL has seems a bit random to me. /system and /dbdata has a 4% overhead, while /cache a 10% one.
I'd be careful about resizing the partitions manually. Samsung should have aligned the partitions for best performance.
I'm not sure if its a placebo, but PIT 512 seems faster to me than PIT 803.
hardcore said:
I'd be careful about resizing the partitions manually. Samsung should have aligned the partitions for best performance.
I'm not sure if its a placebo, but PIT 512 seems faster to me than PIT 803.
Click to expand...
Click to collapse
Aligning should not be terribly hard -- we already specify using 256kb pieces instead of raw bytes. The alignment therefore is somewhere between 256kb and 4mb. If we align for 4mb, we align for everything smaller too. So as long as the numbers used are cleanly divisible by 4*4=16, it will be correctly aligned.
Flashing a PIT file with repartition checked seems to (according to docs) reset the wear leveling (the current record of what was written where, I guess), so you should not tick repartition if you are flashing many times in a row. (Many times is probably some very big number.)
I can't see why we couldn't use YAFFS or similar filesystem. Might work really well. I've got no experience setting up YAFFS though, and I don't believe it is trivial.
RyanZA said:
Aligning should not be terribly hard -- we already specify using 256kb pieces instead of raw bytes. The alignment therefore is somewhere between 256kb and 4mb. If we align for 4mb, we align for everything smaller too. So as long as the numbers used are cleanly divisible by 4*4=16, it will be correctly aligned.
Flashing a PIT file with repartition checked seems to (according to docs) reset the wear leveling (the current record of what was written where, I guess), so you should not tick repartition if you are flashing many times in a row. (Many times is probably some very big number.)
I can't see why we couldn't use YAFFS or similar filesystem. Might work really well. I've got no experience setting up YAFFS though, and I don't believe it is trivial.
Click to expand...
Click to collapse
I wonder if it is possible to make very small /system partition, and move it to mmcblk0 - since it is read only, performance will be ok. And make large dbdata partition, and keep /data/data there. That may be the ultimate lag fix
Sent from my GT-I9000 using XDA App
vitalij said:
I wonder if it is possible to make very small /system partition, and move it to mmcblk0 - since it is read only, performance will be ok. And make large dbdata partition, and keep /data/data there. That may be the ultimate lag fix
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
It is possible, but how would you flash a firmware then?
We are quickly approaching the 'throw it all away, and start from scratch with our own tools and bootloader.
RyanZA said:
It is possible, but how would you flash a firmware then?
We are quickly approaching the 'throw it all away, and start from scratch with our own tools and bootloader.
Click to expand...
Click to collapse
So are u guys planning to release the new galaxy s series phone??
You should rename it to galaxy-xda
So, from the info you have gathered, is there any point in using a PIT file when repartition is not checked?
huxflux2003 said:
So, from the info you have gathered, is there any point in using a PIT file when repartition is not checked?
Click to expand...
Click to collapse
I don't really see much point, but than again PIT file will tell odin (if your flashing pda) explicitly where the kernel should be flashed.
Also, I noticed that kernel partition is only 7.5-6 mb. Doest it mean that we cant use larger kernels (cos I think voodoo might me larger - hence the screen tear on boot).
http://code.google.com/p/badadroid/downloads/detail?name=bTerm_v0.13.zip&can=2&q=
sample bada terminal application. Connected device is detected automatically.
Available commands:
open - open the COM port
close - close the COM port
dump <address> <length> - dump NAND area
dumpram <address> <length> - dump RAM area
run <path_to_file> - execute the code from file
exit - terminate program
Keep in mind reading from invalid address cause Data Abort exception occurs.
Click to expand...
Click to collapse
Thank you very much b.kubica
As my brain is too small to try/understand all things.
Maybe others have tried?
Thanx in advance.
Best Regards
I am too stupid to read RAM...
http://forum.xda-developers.com/showthread.php?t=1093565
Maybe we can find in RAM uncompressed bada 2.0 stuff or for instance content of *.rbm files...
Maybe someone can please help me.
Thanx in advance.
Best Regards
bTerm works (for now) only in download mode. though implementation via AT command should be possible
Run executable
Hello, is run file implemented?
I tried to run programs on GT8500 (FW 1.2), and always get error like this:
>run Solitaires.exe
term_send: only sent 0 bytes of 8210
term_receive: ReadFile returned error!
OK - 0
>run LyricLegend.exe
term_send: only sent 0 bytes of 8209
term_receive: ReadFile returned error!
OK - 0
I needs a way for running console programs on device for unit testing. Is bTerm suitable for this task?
RealGred said:
I needs a way for running console programs on device for unit testing. Is bTerm suitable for this task?
Click to expand...
Click to collapse
Damn. No! It is not. And no, it is not possible in any other way.
http://code.google.com/p/badadroid/downloads/detail?name=bTerm_v0.15.zip&can=2&q=
New Version v0.15
Thank you.
Still unsolved problem because toooo small brain... which area to enter for RAM?
Best Regards
both 0x40000000 and 0x20000000 are valid start addresses
Any idea how to patch apps_compressed.bin of S8500BUKI1 to try this on bada 2.0
I know how to decyrept and encyrept with wave remaker
Also i have a little knowledge in using hex-editior
I can flash back XXJEE bootloader for its security hole
I just need address and data to write
Best Regards
follow these posts
http://forum.xda-developers.com/showpost.php?p=17872425&postcount=383
http://forum.xda-developers.com/showpost.php?p=17876128&postcount=385
I have only bada_term.fota from v0.11
Results...
In v0.13
Code:
>dumpram 20000000 100000
dumping 1.0 MB at 0x20000000: 14%
Error receiving packet (8192 bytes at 0x20026000). Received 0 bytes only.
>dumpram 40000000 100000
dumping 1.0 MB at 0x40000000: 16%
Error receiving packet (8192 bytes at 0x4002A000). Received 0 bytes only.
>dumpram 41000000 100000
dumping 1.0 MB at 0x41000000: 16%
Error receiving packet (8192 bytes at 0x4102A000). Received 0 bytes only.
>dumpram 42000000 100000
dumping 1.0 MB at 0x42000000: 16%
Error receiving packet (8192 bytes at 0x4202A000). Received 0 bytes only.
>dumpram 43000000 100000
dumping 1.0 MB at 0x43000000: 16%
Error receiving packet (8192 bytes at 0x4302A000). Received 0 bytes only.
>dumpram 44000000 100000
dumping 1.0 MB at 0x44000000: 16%
Error receiving packet (8192 bytes at 0x4402A000). Received 0 bytes only.
I can't read more then 177 KB...
I can see such text like:
is_dirty
is_syncing
.
.
.
With v0.15 seems no successfully connection possible.
close report success, but check false and commands also...
Code:
>open
COM5 port opened with success
>check
Phone response FAIL
My PC is XP powered.
Firmware is JE7... old T-Mobile bada 1.x...
Thanx.
Best Regards
u need to compile fota from sources - it is frequently updated so there is no sense to put assembled one in badadroid downloads
u need to compile fota from sources
Click to expand...
Click to collapse
Sorry, I'm an user. Not an Coder or user with Coding skills.
So my head explode before compiling something successfully.
There is enough space to upload FOTA + corresponding bTerm Version.
Maybe FOTA here as attachment.
Please.
Thanx.
Best Regards
fair enough
http://badadroid.googlecode.com/files/bada_term.zip
>open
COM5 port opened with success
>check
Phone response OK
Click to expand...
Click to collapse
Thank you very much, now v0.15 works on my XP with the new FOTA.
First success
Code:
>dumpram 20000000 8000000
dumping 128.0 MB at 0x20000000: 100%
Seems the 128 MB unit as bigger range interrupt...
I'll try now at 0x40000000
Best Regards
Edit 1.
Result:
Code:
>dumpram 40000000 10000000
dumping 256.0 MB at 0x40000000: 59%
Connection failed!
Abandoning dump with total received 0x0997C000 bytes.
Size is now around 157 MB...
Anyway...
I have some files for study.
Big thanx.
maybe I set to small timer intervals. I will increase it in next release
btw, u can start now dump from 0x4997C000 and then combine it with previous one
b.kubica said:
maybe I set to small timer intervals. I will increase it in next release
btw, u can start now dump from 0x4997C000 and then combine it with previous one
Click to expand...
Click to collapse
Working on S8530 ?
yes if you have correct fota assembled
b.kubica said:
yes if you have correct fota assembled
Click to expand...
Click to collapse
Its seem's my Xp have some PATH problem cant find COM says COM0, tested in another comp Win7 worked, Thank you.
its not path problem - looks like you have not installed samsung drivers
could you check something for me? connect phone in download mode, open regedit and go to HKLM\HARDWARE\DEVICEMAP\SERIALCOMM and send me all values stored in this key
b.kubica said:
its not path problem - looks like you have not installed samsung drivers
could you check something for me? connect phone in download mode, open regedit and go to HKLM\HARDWARE\DEVICEMAP\SERIALCOMM and send me all values stored in this key
Click to expand...
Click to collapse
Reinstalled driver properly now works but check fail
Compiled bada_term.asm on BADA2.01
Flashin bada_term.fota
DLMODE
i tried also CHARGING 0 same
; FOTA_SHADOWING equ 1
CHARGING_CONTROL equ 1
include 'S8530JPKA1.inc'
include 'macros.inc'
include 'vars.inc'
include 'functions.inc'
Maybe i need other firmeware ?
Im on original Orange firmware bada 1.2
As you know, we were unable to extract ext4 from Sony ICS firmwares. I took a look at the problem and found out that Sony changed the way sin are generated.
I wrote a quick and (very) dirty command line tool to extract sin properly, it's now possible to extract a working system.ext4.
Usage:
sin2raw <sin file> <output file> [size[K|M|G]]
Usage examples:
sin2raw system.sin system.ext4
sin2raw userdata.sin userdata.ext4
sin2raw kernel.sin kernel.elf
Note:
For linux, there are two versions, sin2raw for 64 bits and sin2raw32 for 32 bits. I strongly recommend using the 64 bits one, 2 gig+ ext4 files are safer with this one.
Release history:
v 0.2:
new: partition size is extracted to generate file, specifying file size is not needed anymore.
new: loader.sin is detected and handled properly.
fix: block header sizes are int, not short.
fix: win32 compatibility.
fix: various size fixes for 32 bits cpu.
code cleanup.
v 0.1 :
Initial release
FAQ
*obsolete* What is size param / 1G ?
When extracting ext4, you have to specify the original partition size on phone. For instance, on xperia S, system is exactly 1 gig, so you have to add 1G. Userdata partition is almost 2 gig, you have to add 2097120K instead of 1G
(Ugly) source code is there, pre-built binaries for windows and linux are attached to this post.
More details to come soon on sin format in second post.
Background:
So, here is the deal: basically, new ext4 sins are using something that was in sin format but that we didn't dig into.
Sin is like this:
Code:
-----------------------
| Sin Header (15 bytes) |
-----------------------
| Block descriptors |
-----------------------
| File Header |
-----------------------
| File Data |
-----------------------
Block descriptors are like this:
Code:
---------------
| target_offset |
---------------
| block_count |
---------------
| block_length |
---------------
| payload_size |
---------------
| payload |
---------------
I presume payload is block signature. A block descriptor is working like this: takes "block_length" bytes from sin "data" and put them at "target_offset" on target device/file.
Up to ics, all block target_offsets were contiguous and that's why sin2img was working. With ics, they are not, explaining why sin2img doesn't work anymore.
History:
2012/08/16 18:00: new analysis, used in 0.2
2012/08/16 11:00: pdfs with more detailed information
it works, thx.
but with only this option 1G added.
Code:
sin2raw system.sin system.ext4 1G
:good:Great job! Thank you very much, i just got extract problem on new *.sin files.
Let me test this tool,I will give some feedback soon.
---------- Post added at 01:50 PM ---------- Previous post was at 01:44 PM ----------
DearTanker said:
:good:Great job! Thank you very much, i just got extract problem on new *.sin files.
Let me test this tool,I will give some feedback soon.
Click to expand...
Click to collapse
It works now,:laugh:,but what is "1G" means?
It seems output file system.ext4 size is 1G?
sorry for my pool english.
---------- Post added at 02:00 PM ---------- Previous post was at 01:50 PM ----------
can extract userdata.sin too,but when extract userdata.sin it will run out space of disk..
Thanks for the info..I will try it.
1G is output file size, 1 gigabyte, you can also use 1024M.
When extracting ext4, you have to specify the phone system partition size if you want to be able to mount it. System partition is 1 gig on Xperia S, I don't know about the other xperias.
If you extract other files like kernel.sin, you don't need to specify output file size.
can extract userdata.sin too,but when extract userdata.sin it will run out space of disk..
Click to expand...
Click to collapse
userdata.sin is almost 2GB, use this:
sin2raw userdata.sin userdata.ext4 2097120K
it will mount properly.
letama said:
userdata.sin is almost 2GB, use this:
sin2raw userdata.sin userdata.ext4 2097120K
it will mount properly.
Click to expand...
Click to collapse
thx, it works on userdata now
but why 2G does not work?
matchung said:
thx, it works on userdata now
but why 2G does not work?
Click to expand...
Click to collapse
Because partition is not exactly 2gig, more 1.999
Why is the system folder not available after converting sin to ext4?
Sharaz22, what do you mean by not available after converting ? This tool extracts a .ext4 image file, you have to mount it to see files. For instance:
mkdir system
sudo mount -o loop -t ext4 system.ext4 system
On windows, I don't know, I know there are some options but never looked at them.
I have mounted the system.ext4 image but there is no system folder in there all the other folder are available e.g. apps xbin etc.
Ah, got it. Well, system.ext4 is the system folder content. In android, system directory is coming from a partition that is mounted to an empty system directory. This is exactly this partition you have there.
Just want to confirm that this tool works fine. I can create pre-rooted image much easier. Don't need to create it from Nandroid anymore. Thanks
Sent from my LT26i using xda premium
Thanks for the feedback!
I'm working on a new release, 0.1 has issues with kernel extracts and hopefully I should be able to compute ext4 size automatically.
And a special thanks to Androxyde for his help!
Thanks,
It's work fine!
New version 0.2 is out, extract is much better now (previous one has few bugs) and size parameter is not needed anymore.
Check first post for details.
its working very fast and without bugs, thats nice, thanks!
I'm using Windows 7 Ultimate 32bit. About sin2raw, how do I open & use it You know, when I left-clicked on "sin2raw.exe", a command windows did appear in just one second, then it disappeared...
banking.amateur said:
I'm using Windows 7 Ultimate 32bit. About sin2raw, how do I open & use it You know, when I left-clicked on "sin2raw.exe", a command windows did appear in just one second, then it disappeared...
Click to expand...
Click to collapse
Sin2raw is a command line tool. You have to use it in a cmd.exe window. Or you could use last FlashTool as Androxyde added the same algorithm in his tool.
Huawei Update Extractor
After messing around a bit with the perl tools available for extracting Huawei update.app files,
i got the idea to create an own (windows) tool.
Requirements
(All versions <= v0.9.9.3 need .Net Framework 3.5)
Latest version uses .Net Framework 4.6.1
Install
Extract the content of the zip to a folder somewhere on your system.
Execute HuaweiUpdateExtractor.exe
I'm planning to create an installer sometime.
Usage
Press the browse (...) button and select an update.app file. Select a device or unknown and press on the open button.
You'll see the content of the update.app file in the listview.
Select one or more files and right click. Choose Extract selected from the context menu.
Choose the ouput folder and press ok.
Or just right click on the list and select Extract all, choose the output folder again and press ok.
Press close on the extract window.
You can sort the list on sequence, filename and size. Just press on the desired column header.
Command line:
HuaweiUpdateExtractor extract input output [profile]
HuaweiUpdateExtractor repack input output profile
Profile
The profiles.xml file is used to identify the files in the update.app file. Every file in the update.app has a sequence or type, which is also
shown in the list. Those sequences or types are used to identify the file/device partition.
Example:
Code:
<?xml version="1.0"?>
<Profiles>
<Profile name="Unknown" author="worstenbrood">
<Files/>
</Profile>
<Profile name="Huawei G510-0100" author="worstenbrood">
<Files>
<File sequence="00000000" partition="/dev/block/mmcblk0p17">system.img</File>
<File sequence="40000000" partition="/dev/block/mmcblk0p13">recovery.img</File>
<File sequence="80000000" partition="/dev/block/mmcblk0p03">baseband.img</File>
<File sequence="EC000000">version.txt</File>
<File sequence="E4000000">splash.raw565</File>
<File sequence="FC000000" partition="/dev/block/mmcblk0p12">boot.img</File>
<File sequence="70000000" partition="/dev/block/mmcblk0p16">cust.img</File>
<File sequence="30000000" partition="/dev/block/mmcblk0p18">userdata.img</File>
<File sequence="FE000000" filetype="signature">signature</File>
<File sequence="FF000000" filetype="checksum">crc</File>
</Files>
</Profile>
<Profile name="Huawei P6" author="worstenbrood">
<Files>
<File type="system" partition="/dev/block/mmcblk0p16">system.img</File>
<File type="cache" partition="/dev/block/mmcblk0p17">cache.img</File>
<File type="cust" partition="/dev/block/mmcblk0p18">cust.img</File>
<File type="userdata" partition="/dev/block/mmcblk0p19">userdata.img</File>
<File type="modemimage" partition="/dev/block/mmcblk0p13">modemimage.img</File>
<File type="boot" partition="/dev/block/mmcblk0p12">boot.img</File>
<File type="recovery" partition="/dev/block/mmcblk0p11">recovery.img</File>
<File type="md5rsa" filetype="signature">signature</File>
<File type="crc" filetype="checksum">crc</File>
</Files>
</Profile>
</Profiles>
<Profiles>
- Root tag of the xml file.
<Profile>
- Identifies a device
- attribute name: name of the device
- attribute author: author of the device
<Files>
- File root tag
<File>
- Identifies a file
- attribute sequence: sequence of the file in update.app
- attribute type: type of the file in the update.app
- attribute partition: destination partition on the device
- attribute filetype: can be one of the following values:
* signature: used to identify the signature file
* checksum: used to identify the checksum file
- value: file name
You can add or edit devices. If you want them to integrate in newer version, pm 'em to me.
I'm gonna make some auto update for the device file somewhere in the future
To add your devices profile you'll have to identify your device partitions and map them against the files inside the update.app.
Thread about identifying partitions: http://forum.xda-developers.com/showthread.php?t=1959445
Roadmap
- You tell me ...
Credits
ZeBadger ([email protected]) for figuring out the file headers
S34Qu4K3 for the P6 partition layout
ngamyarthar for adding ALOT of devices!
Changelog
v0.9.1.0
- Create update zip works now, this requires to have a PERFECT device entry in the devices file. The sequence is used to identify the file AND partition. Only files that have these two will be included in the zip. USE WITH CAUTION, MAKE SURE THE PARTITION IS CORRECT OR YOU'LL END UP FLASHING THE WRONG IMAGES TO THE WRONG PARTITION !! I'M NOT RESPONSABLE FOR BRICKING YOUR DEVICE! IF YOU DON'T KNOW WHAT YOU'RE DOING, THEN DON'T USE IT!
v0.9.1.1
- Added Type to the filelist (shows INPUT for g510 roms, but shows some useful info on P6 roms)
v0.9.2.0
- Files now can also be identified by the type attribute in devices.xml
- Added P6 device
v0.9.3.0
- Crc check during extract
- Crc check during creating flashable zip
- Added row to see file is flashable
v0.9.5.0
- Added repack
- Added icons and tooltip
- Added settings
- Experimental, no signing on repack, crc file gets generated
- Alot of stuff i forgot
v0.9.6.0
- Added command line options
v0.9.7.0
- Added G300 profile (thx ZeBadger)
- Added detailed info about the file (libmagic) in the tooltip on the extract list. This way it is easier to identify files inside the update.
(see screenshot). It will detect ext/fat/... partitions.
v0.9.7.1
- Alot of devices added in profiles (Credits to ngamyarthar, thanks alot dude!)
- Added android boot/recovery image recognition in magic.mgc
v0.9.7.2
- Made setup
-v0.9.7.4
- App will now remember last used profile.
- Fixed bug in repack code (remainder writing)
- Added signing options (During repack, once set, it will use the selected keyfile (PEM format) and algorithm to create the signature file. If there is no file selected or the file doesn't exist, it will use the existing signature file.)
Example of keyfile content:
Code:
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDU9GF9tdk59edEXWX4MEJNjMqGce/CqqGZSDBwnAzHITZYBm+y
ZEVkaOGGdPY7rmmWO6w3P/+nPVHO0kxA1/J+FY+sbUF7uz0kzVDxuW6t5KDc9Qr4
NRAE1ZzX0eB0aYpLImlqI7yigih6ds+Yp83mTbF+BiaFTLLtMVdWS7wQiwIDAQAB
AoGBAMok2E4+Sl9sfwU0K1E2bhmzJaQNj2wYEKGyFtkuKCr16eIQ6gJKkFxJ+ppp
eDsaynujVUx04bbczEUo9t0un603s5HAGq6USO5flERco0TlNw7xnTornPPrNxfU
sXOtIGzb0FlRuC129JqZJ9QsfvOyt3KIWwmJqc0R/k0xB8uRAkEA9+v1ohNXB8CL
plhQOtq0ueWrf9CCCeiqhf6ijg7UEegMLGKZ2gFMvMNwuojz/pbQmHdWTU9eC0k1
3yiAwHtcLQJBANvkvjXdzCYHO6nWOH1vf8DRLwCnwEteyxJ2qnrqKLS3fxCjWN4h
4vSNqgC9uoLEb/6T/72XTdG9gS8GsuoAupcCQBZ4eIb8IcM+HGozTvJGqGLBAk5P
Y7nqMKp8bddaWLZWxeOv/CnaPE5PmIQPra3BlZ58EoJnUyrKs+tKDIFlrPECQQC9
Ie0cxc4e81+0/+WMtkdq4EGOTbsO2NTP57NQj3E9pwqqk+UPApSEBgkwJAB1E2LE
1CVGvAoaGeYwPZHLxZ63AkEAugR+cC+5/BtTeMeXEcijnU0qkgkwLCMgTB1DIoMm
X0/wRGPPmZpGmMStHd+87ZxQSOiq5nAyZ4riFXLziUNOlA==
-----END RSA PRIVATE KEY-----
-v0.9.7.5
- Default sorting on filename
- Small changes in structure of profiles.xml
-v0.9.7.6
- Added progress for signing and checksum generation
- Extract/CreateZip order by offset
- Repack order by Signature, Checksum, Files
-v0.9.7.7
- Doubleclick on item in extract files listview copies tooltip text to clipboard
- Added detailed android boot/recovery image detection to magic.mgc
- Added SecVRL header (the 2048 byte header in front of fastboot/boot/recovery image) detection
-v0.9.7.8
- Added timestamp options in settings
- Added tooltips in settings
- Some ui changes (which hopefully fix the missing "..." button issue)
-v0.9.7.9
- Some small ui fixes
- When saved location of the app is on a monitor that isn't attached anymore, app location is restored to center of primary screen.
-v0.9.8.0
- Some small ui changes
- Sort profiles by name
- Remember last used directory
- Added profile for Huawei G526 (Credits Roman Dmitriev)
-v0.9.9.0
- Added compatibility for wine/mono
- Fixed bug in settings (Verify header checksum)
- Made the app localizable (Download the Resources_EN example, if you make a translation, make sure that your assembly start with "Resources_" and ends with the TwoLetterISOLanguageName (eg. EN for english) of your culture and put the assembly in the same directory as the application)
- Added profile for Huawei Ascend Mate 7 (Thanks to sketchykingy)
-v0.9.9.1
- Added missing translatable resources (updated Resources_EN)
- Added profile for Huawei MediaPad X1 7.0 (7D-503L) (Credits ElectroMyStyle)
-v0.9.9.2
- Fixed int overflow (extracting big files)
-v0.9.9.3
- Added drag/drop for files and folders.
-v0.9.9.5 - 12/12/2016
- Upgraded to .Net Framework 4.6.1
- Fixed libmagic calling convention
- Huawei Mediapad M2 8.0 (M2-802L) profile by @beast.in.black
- Huawei Ascend P8 (GRA-L09) profile by @nexolight
- Huawei Mate S profile by @philipp900
- Huawei P8 lite profile by @linus2014
- Huawei Honor 5x (Kiwi-L2X) profile by @deadman96385
26122015
Created an opensource c# library to work with update.app files:
https://github.com/worstenbrood/HuaweiUpdateLibrary
Enjoy
Download
- v0.9.9.3: Setup - Zip
- v0.9.9.5: Zip
Mirror
Donate if you like my work.
Is it possible to repack update.app?
If so, could you implemet such feature?
xan said:
Is it possible to repack update.app?
If so, could you implemet such feature?
Click to expand...
Click to collapse
Since i almost finished update zip creation (new version tomorrow), i have put it on the roadmap (already thought about it anyway )
The problem is sign the app, not repack it
Sent from my HUAWEI P6-U06 using xda app-developers app
S34Qu4K3 said:
The problem is sign the app, not repack it
Sent from my HUAWEI P6-U06 using xda app-developers app
Click to expand...
Click to collapse
I dont think its signed, but it has a per file per block checksum which should be correct...
worstenbrood said:
I dont think its signed, but it has a per file per block checksum which should be correct...
Click to expand...
Click to collapse
So, repack is useless, i tried it, you need to resign the app to make the new checksums match or it will give you an error when you flash it via default recovery.
Don't missunderstand me, is a great tool, and simplifies the unpack/repack for more unexperienced users, but without the sign, you can't flash it, that's what i say that is a bit useless (like the other scripts to unpack and repack)
S34Qu4K3 said:
So, repack is useless, i tried it, you need to resign the app to make the new checksums match or it will give you an error when you flash it via default recovery.
Don't missunderstand me, is a great tool, and simplifies the unpack/repack for more unexperienced users, but without the sign, you can't flash it, that's what i say that is a bit useless (like the other scripts to unpack and repack)
Click to expand...
Click to collapse
I'll investigate some more when i have the time. Also the signing part is why i actually made a function to create a flashable zip from it, this way you CAN flash it with a custom recovery (ok you need an unlocked bootloader, but why would'nt you do that anyway )
worstenbrood said:
I'll investigate some more when i have the time. Also the signing part is why i actually made a function to create a flashable zip from it, this way you CAN flash it with a custom recovery (ok you need an unlocked bootloader, but why would'nt you do that anyway )
Click to expand...
Click to collapse
That's great
Huawei Update Extractor
v0.9.2.0
- Files now can also be identified by the type attribute in devices.xml
- Added P6 device
Click to expand...
Click to collapse
Please add Ascend P2
Thanks
Carlos Varella said:
Please add Ascend P2
Thanks
Click to expand...
Click to collapse
S34Qu4K3 made a nice post on how to identify the partitions on your phone, after identifying them you have to map them to the files inside the update.app. Since i don't have access to an P2 i'm counting on you guys to complete the devices.xml file.
http://forum.xda-developers.com/showthread.php?t=2398404
Excellent work Worstenbrood! :good:
The tool is very good. I've tried with several Update.app and all OK.
It would be very interesting to get to repack the file Update.app because still do not have a custom recovery bootable. With the current cwm recovery can not extract files. Img a partition.
May you work on the file repack Update.app
The author Genokolar the custom recovery of Honor 2 miui port and a large majority of Huawei moblies have to pack and repack the file Update.app (over 4 months ago):
https://github.com/genokolar/unpacker_huawei/blob/master/unpack.php
That really says there that forked from tewilove / unpacker_huawei
Best Regards
Next version will have a repack function included, i'm adjusting the UI but most of the repacking code is already written.
worstenbrood said:
Next version will have a repack function included, i'm adjusting the UI but most of the repacking code is already written.
Click to expand...
Click to collapse
Excellent news!
Update to v0.9.5.0, added repack function, it only repacks the file + recalculates all checksums and the checksum file. No signing is done yet ! Since i have no access to a huawei device atm it would be nice to see some results (i'm wondering if the order of the files inside the update.app is important)
Thank you for the update. BTW, the Huawei Ascend Mate has the same partition information as the P6 so should be easy to add to the tool. I've been using it to unpack Mate updates with success.
flibblesan said:
Thank you for the update. BTW, the Huawei Ascend Mate has the same partition information as the P6 so should be easy to add to the tool. I've been using it to unpack Mate updates with success.
Click to expand...
Click to collapse
Then it is just a matter of cloning the P6 profile inside the profiles.xml and changing the Name attribute or changing the name so that it suits both...
Any updates may be sent to me
worstenbrood said:
Then it is just a matter of cloning the P6 profile inside the profiles.xml and changing the Name attribute or changing the name so that it suits both...
Any updates may be sent to me
Click to expand...
Click to collapse
Confirm, it work too with D1QXL
Amazing, I found anywhere and none of them work. Great Tool
My I ask one feature? pack/unpack *.img
In my device, Ascend D1 Quad XL, every image has additional 2048 header before ANDROID magic word.
To extract boot.img/recovery.img, dsixda's Android Kitchen remove the 2048 header, save as new boot.img then extract it. Repack it.
But then, the repack image have no 2048 header. So I can't flash it manually to device.
Would yo learn/track this 2048 header
Thank's
twins.7 said:
Confirm, it work too with D1QXL
Amazing, I found anywhere and none of them work. Great Tool
My I ask one feature? pack/unpack *.img
In my device, Ascend D1 Quad XL, every image has additional 2048 header before ANDROID magic word.
To extract boot.img/recovery.img, dsixda's Android Kitchen remove the 2048 header, save as new boot.img then extract it. Repack it.
But then, the repack image have no 2048 header. So I can't flash it manually to device.
Would yo learn/track this 2048 header
Thank's
Click to expand...
Click to collapse
Thanks.
I want to keep the app as generic as possible, you can easily write a bat file that does that
worstenbrood said:
Thanks.
I want to keep the app as generic as possible, you can easily write a bat file that does that
Click to expand...
Click to collapse
No, I mean this 2048 header are unique. That's why I need your help to determine contain of header.
without that header I can't flash img to device. Each change in img, the header must change too.
twins.7 said:
Confirm, it work too with D1QXL
Amazing, I found anywhere and none of them work. Great Tool
My I ask one feature? pack/unpack *.img
In my device, Ascend D1 Quad XL, every image has additional 2048 header before ANDROID magic word.
To extract boot.img/recovery.img, dsixda's Android Kitchen remove the 2048 header, save as new boot.img then extract it. Repack it.
But then, the repack image have no 2048 header. So I can't flash it manually to device.
Would yo learn/track this 2048 header
Thank's
Click to expand...
Click to collapse
twins.7 said:
No, I mean this 2048 header are unique. That's why I need your help to determine contain of header.
without that header I can't flash img to device. Each change in img, the header must change too.
Click to expand...
Click to collapse
Share an image with me (with the header included) and i'll take a look when i have some time.
Download for Official
info:
KINZIE_RETLA_DS_7.0_NPKS25.200-12-9_cid12_subsidy-DEFAULT_CFC.xml.zip
Size: 1593961437 bytes
MD5: F82F782C664FC6F239A27E0BC887E08C
SHA1: 94112F27AE85BFDF8F8C648AB1B17A3E1E22784F
CRC32: 5B2EB7FE
access denied...I'm looking for RETMX 7.0 can you help me?
alternative link:
https://androidfilehost.com/?fid=745849072291694796