First the disclaimer:
I am not responsible for what you do to your phone. Following these directions could cause you to brick, locust plague, or end of times. You assume ALL responsibility for what you do with this information.
Now, on to the fun stuff. I take *NO* credit for this information at all. I am a student of people far more knowledgeable about these things. However, I've managed to take what I've learned and apply it in really fun ways. For example, I have a script that takes an OTA and builds a new full ODIN image from it...with all partitions fully signed except system. Many people have asked me to "repackage it" with various requests. This tutorial is going to show how to do that.
Requirements:
o) You will need to install Cygwin. A default installation should suffice for this exercise.
o) You will need one of the ODIN TAR Full Rooted Restore images. They are gzipped to make them smaller.
Process:
o) You need to unpack the files stored inside the gzip. 7 Zip is a handy program for doing that. We need the individual partition files extracted to a work directory that can be accessed from a Cygwin command prompt. I create a C:\Android\S4_GPE directory for my own image creation tasks.
o) Once the individual files are unpacked, we need to repack them. Open a Cygwin command prompt and navigate to the directory you extracted the files to. In my case, that would be cd c:/Android/S4_GPE
Follow the directions below to repack the files as needed. I give a few examples here to show you the basics of how it's done. Basically you run each command in your Cygwin command prompt. Or you can add them to an SH script and run it that way. Whatever you feel most comfortable with.
The output of these commands is an ODIN flashable file that will install what you choose.
BOOT
filename=boot
tar -H ustar -c boot.img > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
RECOVERY
filename=recovery
tar -H ustar -c recovery.img > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
MODEM
filename=modem
tar -H ustar -c NON-HLOS.bin modem.bin > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
FULL ODIN IMAGE
filename=I9505GUEUB_FULL_ROOTED
tar -H ustar -c boot.img recovery.img NON-HLOS.bin modem.bin system.img.ext4 > $filename.tar
md5sum -t $filename.tar >> $filename.tar
mv $filename.tar $filename.tar.md5
gzip $filename.tar.md5
Those are some of the common ones. What if I wanted a "semi-full rooted image"? For instance, without the modems? You just modify this line:
tar -H ustar -c boot.img recovery.img NON-HLOS.bin modem.bin system.img.ext4 > $filename.tar
so that it becomes:
tar -H ustar -c boot.img recovery.img system.img.ext4 > $filename.tar
Of if you don't want recovery, either, and just want boot and system:
tar -H ustar -c boot.img system.img.ext4 > $filename.tar
And the rest stays the same. I really hope this helps people. I will update this post to clarify anything that's confusing and will try to help people in this thread to create whatever they need. Again, you take responsibility for anything you create using these instructions and flash to your phone.
whats the command to create a system dump to an odin compatible system.img file? been a while. i forget
This is how I do it in my script:
adb shell "su -c 'cd /sdcard; dd if=/dev/block/platform/msm_sdcc.1/by-name/system of=/sdcard/system.img.ext4'"
adb pull /sdcard/system.img.ext4
adb shell rm /sdcard/system.img.ext4
SamuriHL said:
This is how I do it in my script:
adb shell "su -c 'cd /sdcard; dd if=/dev/block/platform/msm_sdcc.1/by-name/system of=/sdcard/system.img.ext4'"
adb pull /sdcard/system.img.ext4
adb shell rm /sdcard/system.img.ext4
Click to expand...
Click to collapse
I'm a relative noob and just learning as much as I can and this is alot of great info. I am able to pull system dump and pull recovery.img from my but when I create an odin flashable recovery image (for back-up purposes) it fails auth. Is there a way to pull a signed recovery image from system? Thanks.
No. When you dd extract a partition it adds padding to it which messes with the signature. I create a signed recovery img file by patching the boot img with the recovery-from-boot.p in the OTA update. That's a lot more involved than what's in this tutorial, however.
SamuriHL said:
No. When you dd extract a partition it adds padding to it which messes with the signature. I create a signed recovery img file by patching the boot img with the recovery-from-boot.p in the OTA update. That's a lot more involved than what's in this tutorial, however.
Click to expand...
Click to collapse
Got it, thank you. I found the thread on hexediting the partition file. I will see if that works.
muniz_ri said:
Got it, thank you. I found the thread on hexediting the partition file. I will see if that works.
Click to expand...
Click to collapse
My initial results weren't very conclusive on that. I tried it with the NON-HLOS.bin file just to see if I could make it consistent with the one I create by patching, and the results were not good. There's no way to know exactly how long to make the cut. It seems like all you do is remove the trailing 00's when hexediting, but, I can tell you that's not enough to make it match. I've got more research to do on this as it would be extremely useful to be able to edit the dd extracted files to make them match the signed files. So far, that doesn't seem possible.
SamuriHL said:
My initial results weren't very conclusive on that. I tried it with the NON-HLOS.bin file just to see if I could make it consistent with the one I create by patching, and the results were not good. There's no way to know exactly how long to make the cut. It seems like all you do is remove the trailing 00's when hexediting, but, I can tell you that's not enough to make it match. I've got more research to do on this as it would be extremely useful to be able to edit the dd extracted files to make them match the signed files. So far, that doesn't seem possible.
Click to expand...
Click to collapse
That's too bad, I was also hoping removing the trailing zeros would work. Can you point me to a tutorial, etc where i can learn how to patch using the OTA files? thanks again.
muniz_ri said:
That's too bad, I was also hoping removing the trailing zeros would work. Can you point me to a tutorial, etc where i can learn how to patch using the OTA files? thanks again.
Click to expand...
Click to collapse
It's not quite as simple as that. There isn't a tutorial on it. I learned what I know from Matt Groff. It started with a thread here:
http://forum.xda-developers.com/showthread.php?t=1702233
But that thread isn't going to teach nearly enough to learn how to do this. It involves parsing the update scripts from the OTA to find the command they use to patch the actual partition and then converting that to a command to patch the file. So if you look at this command from install-recovery.sh:
applypatch EMMC:/dev/block/platform/msm_sdcc.1/by-name/boot:8036608:1ad324cf48a6e19fd402603477cd0ed8472ed863 EMMC:/dev/block/platform/msm_sdcc.1/by-name/recovery f4579fa7099942ec2f214cff81014b8e8b1a550f 8632576 1ad324cf48a6e19fd402603477cd0ed8472ed863:/system/recovery-from-boot.p
What that's doing is taking 8036608 bytes from the boot partition, ensuring it has a sha1 hash of 1ad324cf48a6e19fd402603477cd0ed8472ed863, patching it with the contents of the recovery-from-boot.p file, and then writing it to the recovery partition.
Each time an OTA comes out for our phones, I create signed recovery, modem, and non-hlos files using this process. Then I use the process outlined in this tutorial to create the ODIN tar md5 files that I post.
SamuriHL said:
It's not quite as simple as that. There isn't a tutorial on it. I learned what I know from Matt Groff. It started with a thread here:
http://forum.xda-developers.com/showthread.php?t=1702233
But that thread isn't going to teach nearly enough to learn how to do this. It involves parsing the update scripts from the OTA to find the command they use to patch the actual partition and then converting that to a command to patch the file. So if you look at this command from install-recovery.sh:
applypatch EMMC:/dev/block/platform/msm_sdcc.1/by-name/boot:8036608:1ad324cf48a6e19fd402603477cd0ed8472ed863 EMMC:/dev/block/platform/msm_sdcc.1/by-name/recovery f4579fa7099942ec2f214cff81014b8e8b1a550f 8632576 1ad324cf48a6e19fd402603477cd0ed8472ed863:/system/recovery-from-boot.p
What that's doing is taking 8036608 bytes from the boot partition, ensuring it has a sha1 hash of 1ad324cf48a6e19fd402603477cd0ed8472ed863, patching it with the contents of the recovery-from-boot.p file, and then writing it to the recovery partition.
Each time an OTA comes out for our phones, I create signed recovery, modem, and non-hlos files using this process. Then I use the process outlined in this tutorial to create the ODIN tar md5 files that I post.
Click to expand...
Click to collapse
Success! Thanks so much, just created my first signed odin image!
Theres two more ways the get signed images. One is using dd if=of with the right bs and count. For example, I extracted the stock signed PIT file for the S4 using
Code:
su
dd if=/dev/block/mmcblk0 of=/sdcard/sch1545.pit bs=8 count=580 skip=2176
you can see the thread and md5 comparisonhere The other method is hexediting but it was easier on 4.2.2 but still very doable on 4.3. You have to know what signatures look like though. Hexediting can also be useful for manually extracting the zimage and ramdisk from a boot.img
Sent from my SCH-I545 using XDA Premium 4 mobile app
Surge1223 said:
Theres two more ways the get signed images. One is using dd if=of with the right bs and count. For example, I extracted the stock signed PIT file for the S4 using
Code:
su
dd if=/dev/block/mmcblk0 of=/sdcard/sch1545.pit bs=8 count=580 skip=2176
you can see the thread and md5 comparisonhere The other method is hexediting but it was easier on 4.2.2 but still very doable on 4.3. You have to know what signatures look like though. Hexediting can also be useful for manually extracting the zimage and ramdisk from a boot.img
Sent from my SCH-I545 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I'm also going to play around more with hexediting, if it will work it seems much more straightforward. Thanks again for all of the good info!
SamuriHL said:
My initial results weren't very conclusive on that. I tried it with the NON-HLOS.bin file just to see if I could make it consistent with the one I create by patching, and the results were not good. There's no way to know exactly how long to make the cut. It seems like all you do is remove the trailing 00's when hexediting, but, I can tell you that's not enough to make it match. I've got more research to do on this as it would be extremely useful to be able to edit the dd extracted files to make them match the signed files. So far, that doesn't seem possible.
Click to expand...
Click to collapse
Sam, id be glad to try hexediting the NON-HLOS.bin file and then send you the md5.
Sent from my SCH-I545 using XDA Premium 4 mobile app
Surge1223 said:
Sam, id be glad to try hexediting the NON-HLOS.bin file and then send you the md5.
Sent from my SCH-I545 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
I'll pm one to you tomorrow. I definitely am curious if you're able to md5 hash it correctly.
Pm sent. Good luck.
Sent from my SM-P600 using Tapatalk 4
SamuriHL said:
Pm sent. Good luck.
Sent from my SM-P600 using Tapatalk 4
Click to expand...
Click to collapse
How do you limit the number of bytes extracted for the mdm.bin to match the updater script's parameters? Thank you.
muniz_ri said:
How do you limit the number of bytes extracted for the mdm.bin to match the updater script's parameters? Thank you.
Click to expand...
Click to collapse
I didn't. The first signed modem bin I made was done by looking at the size in the updater script and using cygwin to copy that many bytes to a new file. From then on I just patched the previous version's modem bin and NON-HLOS bin files.
Sent from my SM-P600 using Tapatalk 4
SamuriHL said:
I didn't. The first signed modem bin I made was done by looking at the size in the updater script and using cygwin to copy that many bytes to a new file. From then on I just patched the previous version's modem bin and NON-HLOS bin files.
Sent from my SM-P600 using Tapatalk 4
Click to expand...
Click to collapse
First time quickly hexediting it I got
md5: 9616e85b765e0365e8ccd57550a715b8
Surge1223 said:
First time quickly hexediting it I got
md5: 9616e85b765e0365e8ccd57550a715b8
Click to expand...
Click to collapse
Which doesn't match the digital signature. This is what I was afraid of and what I was running into.
Sent from my SM-P600 using Tapatalk 4
SamuriHL said:
Which doesn't match the digital signature. This is what I was afraid of and what I was running into.
Sent from my SM-P600 using Tapatalk 4
Click to expand...
Click to collapse
what are you comparing the sig to?
Sent from my SCH-I545 using XDA Premium 4 mobile app
Related
I'm sure several people will be wanting this information, so I figured I would post it here for everyone. This will allow you to backup your system and create custom Odin images for restore purposes. For anyone unfamiliar with the Samsung system, they use Odin to flash things to the device, much like HTC has RUU and Moto has SBF. Odin files are either .tar files, or .tar.md5 files.
The .tar.md5 files are .tar files with the md5 checksum added to the end of the file. If you attempt to flash a .tar.md5 file, Odin will automatically check that the contents are what they should be before flashing and proceed with the flash if the md5 is valid, otherwise it will stop.
In Odin, you should use the PDA button for all flashing. The PIT button may be used as well, if we can get a valid .pit file for the device, but for now, PIT won't be used either. Other than PDA, Start/Reset are the only other buttons you need to worry about.
Now, on to creating the backup files. First, you will need your device to be rooted (perm or temp root will work), and you also need to have access to terminal on the phone, either via an emulator or adb shell access. To create the backup files, you won't need a Linux/UNIX system, but you will if you want to create a flashable Odin package. The following will output the files on the root of the SDCard, adjust the "of=" path if you want them somewhere else. It will also create the files for the proper filename for Odin as well. So to create the files, here are the commands you will use from root shell (#):
System:
Code:
dd if=/dev/block/stl10 of=/sdcard/factoryfs.rfs bs=4096
Kernel:
Code:
dd if=/dev/block/bml8 of=/sdcard/zImage bs=4096
Recovery:
Code:
dd if=/dev/block/bml9 of=/sdcard/recovery.bin bs=4096
DO NOT INCLUDE THE FOLLOWING IN ANYTHING BUT A PERSONAL BACKUP
Cache:
Code:
dd if=/dev/block/mmcblk0p3 of=/sdcard/cache.rfs bs=4096
DBData:
Code:
dd if=/dev/block/stl11 of=/sdcard/dbdata.rfs bs=4096
Data:
Code:
dd if=/dev/block/mmcblk0p1 of=/sdcard/movinand.bin bs=4096
The last three files (cache, dbdata, data) may contain personal information, so do not include these 3 files in anything but a personal backup/recovery package.
To create a flashable Odin package, you need to pull all of the files off of the phone/sdcard and onto your computer. From there, you use the following to create the package:
Code:
tar -H ustar -c factoryfs.rfs recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
If you want to include cache/dbdata/data in the above for personal use, just add them after the "-c" and before the ">".
There are other files that may be in Odin packages, but they are protected by Samsung and cannot be dumped properly. The files are the bootloader, secondary bootloader, modems, and .lfs partitions. The files would be boot.bin, Sbl.bin, modem.bin (not sure what it would be for the CDMA/LTE dual modem here), and param.lfs. It however isn't that big of an issue that these can't be dumped as the can't really be altered by normal flashing of the device, and are usually only altered via OTA updates.
Thanks for this info imnuts! I unfortunately updated to the new update and would like to go back to rooted but cant until I downgrade.
Thanks!
Thanks for posting this. I'm going to attempt to make a personal backup and then I can factory reset the phone and make a stock version for people to use. I'm haven't installed the update yet either, so I'm hoping this will let people get back to ED1. I've also been playing around with theming using the fascinate community rom theme and ninjamorph to swap files. It'll take a while, but it's currently the only way I feel safe messing with framework-res.
wynalazca said:
Thanks for posting this. I'm going to attempt to make a personal backup and then I can factory reset the phone and make a stock version for people to use. I'm haven't installed the update yet either, so I'm hoping this will let people get back to ED1. I've also been playing around with theming using the fascinate community rom theme and ninjamorph to swap files. It'll take a while, but it's currently the only way I feel safe messing with framework-res.
Click to expand...
Click to collapse
I'm definitely looking forward to having a downgrade ROM image to get back to ED1!
So how do you add the last personal 3 i just got the droid charge and i am not very familiar with samsung files i had a droid x and a thunderbolt very shortly and am familiar with ruu and sbf but how do you add cache dbdata and the other one. I meab like the actual command not the instruction to put it after c
rami98 said:
So how do you add the last personal 3 i just got the droid charge and i am not very familiar with samsung files i had a droid x and a thunderbolt very shortly and am familiar with ruu and sbf but how do you add cache dbdata and the other one. I meab like the actual command not the instruction to put it after c
Click to expand...
Click to collapse
The only thing that would change would be the tar command. If you want to include the other files, it would be:
Code:
tar -H ustar -c cache.rfs dbdata.rfs factoryfs.rfs movinand.bin recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
You just need to pull the files from your phone and have them in the same directory that you're in in terminal, and have them named appropriately. It also doesn't matter what order they are in (that I know of), I just have them in alphabetical order for ease of reading.
So im going to try and do the voodoo lagfix for the first time ever but I wanted to make a backup. Im on ED2 and NOT rooted so how would I go about making these backups?
imnuts said:
The only thing that would change would be the tar command. If you want to include the other files, it would be:
Code:
tar -H ustar -c cache.rfs dbdata.rfs factoryfs.rfs movinand.bin recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
You just need to pull the files from your phone and have them in the same directory that you're in in terminal, and have them named appropriately. It also doesn't matter what order they are in (that I know of), I just have them in alphabetical order for ease of reading.
Click to expand...
Click to collapse
I tried the above and I keep getting this error message in the command prompt:
'tar' is not recognized as an internal or external command, operable program or batch file.
(I'm trying this on windows 7 professional)
Any help would be appreciated, thanks!
mypantsaretorn said:
I tried the above and I keep getting this error message in the command prompt:
'tar' is not recognized as an internal or external command, operable program or batch file.
(I'm trying this on windows 7 professional)
Any help would be appreciated, thanks!
Click to expand...
Click to collapse
You wouldn't by any chance be trying the "tar" command at a windows command prompt, would you?
imnuts said:
To create the backup files, you won't need a Linux/UNIX system, but you will if you want to create a flashable Odin package.
To create a flashable Odin package, you need to pull all of the files off of the phone/sdcard and onto your computer. From there, you use the following to create the package:
Code:
tar -H ustar -c factoryfs.rfs recovery.bin zImage > package_name.tar
md5sum -t package_name.tar >> package_name.tar
mv package_name.tar package_name.tar.md5
If you want to include cache/dbdata/data in the above for personal use, just add them after the "-c" and before the ">".
Click to expand...
Click to collapse
Course you might be running Linux in a vmware or Hyper-V environment....hint?
HTH
Damn! I didn't pay attention to the second part of that sentence! Lol
Thanks for the "hint"..
Sent from my SCH-I510 using XDA App
The other option would be using Cygwin, but I've never tried it, so it may or may not work.
imnuts said:
The other option would be using Cygwin, but I've never tried it, so it may or may not work.
Click to expand...
Click to collapse
cygwin works!
Edit: Here is how:
1. Search google for cygwin - download
2. Run - you will be prompted to get packages - I assumed "archive" was a good place to start - not sure if you need this or not...
3. When complete you will see a new icon on your desktop - double-click
4. Be patient as it loads
5. Copy the files output'ed from first post to same folder on PC
6. Back in cygwin:
a. cd x: (where x: is the drive letter of the drive that has the folder with the files)
b. tar -H ustar -c cache.rfs dbdata.rfs movinand.bin factoryfs.rfs recovery.bin zImage > package_name.tar
c: md5sum -t package_name.tar >> package_name.tar
d: mv package_name.tar package_name.tar.md5
Complete output of commands:
These files are for the users to personalise their cygwin experience.
They will never be overwritten nor automatically updated.
`./.bashrc' -> `/home/UWINKET//.bashrc'
`./.bash_profile' -> `/home/UWINKET//.bash_profile'
`./.inputrc' -> `/home/UWINKET//.inputrc'
`./.profile' -> `/home/UWINKET//.profile'
Your group is currently "mkgroup". This indicates that neither
your gid nor your pgsid (primary group associated with your SID)
is in /etc/group.
The /etc/group (and possibly /etc/passwd) files should be rebuilt.
See the man pages for mkpasswd and mkgroup then, for example, run
mkpasswd -l [-d] > /etc/passwd
mkgroup -l [-d] > /etc/group
Note that the -d switch is necessary for domain users.
[email protected] ~
$ cd h:
System Volume Information
[email protected] /cygdrive/h
$ cd downloads
[email protected] /cygdrive/h/downloads
$ cd charge
[email protected] /cygdrive/h/downloads/charge
$ cd tarbackup/
[email protected] /cygdrive/h/downloads/charge/tarbackup
$ tar -H ustar -c cache.rfs dbdata.rfs movinand.bin factoryfs.rfs recovery.bin
zImage > package_name.tar
[email protected] /cygdrive/h/downloads/charge/tarbackup
$ md5sum -t package_name.tar >> package_name.tar
[email protected] /cygdrive/h/downloads/charge/tarbackup
$ mv package_name.tar package_name.tar.md5
[email protected] /cygdrive/h/downloads/charge/tarbackup
$
Hmm flash did not work with my personal data in it - got an error. Created a new .tar file with just factoryfs.rfs recovery.bin and zImage and was able to flash that. TG for TiBu!
jism31 said:
Thanks for this info imnuts! I unfortunately updated to the new update and would like to go back to rooted but cant until I downgrade.
Click to expand...
Click to collapse
How do you start doing this. How do I get to root shell (#)... Thanks
AD
I plan to get rooted on ED1 so I can get a stock image backed up, and have a clean base to work from. Still getting my head around the odin stuff first.
RaptorMD said:
I plan to get rooted on ED1 so I can get a stock image backed up, and have a clean base to work from. Still getting my head around the odin stuff first.
Click to expand...
Click to collapse
you dont have to do that its already done
http://forum.xda-developers.com/showthread.php?t=1085190
Well, I successfully followed all the instructions and have created my first ODIN flashable file, I have not tried to flash it yet. I'm just curious, I pull all the different .rfs, .bin, and zImage on this file and noticed it's about 1.8gb file. Is this normal?
Also, before I try to flash this. Should I have dissable voodoo lagfix and converted back to rfs before I dumped the files?
Thanks for all the help!
JKChad said:
Well, I successfully followed all the instructions and have created my first ODIN flashable file, I have not tried to flash it yet. I'm just curious, I pull all the different .rfs, .bin, and zImage on this file and noticed it's about 1.8gb file. Is this normal?
Also, before I try to flash this. Should I have dissable voodoo lagfix and converted back to rfs before I dumped the files?
Thanks for all the help!
Click to expand...
Click to collapse
Yes, that's normal for it to be so large as dd will dump the partition, including empty space. If you were to compress it with zip or lzma, it'd drop down considerably.
Not sure about the voodoo part as I've never dumped files from an ext4 partition. I don't see any reason why it wouldn't work, but I'd flash with caution and have another working image ready just in case.
imnuts said:
Not sure about the voodoo part as I've never dumped files from an ext4 partition. I don't see any reason why it wouldn't work, but I'd flash with caution and have another working image ready just in case.
Click to expand...
Click to collapse
Shouldn't be an issue as long as he keeps the voodoo kernel.
Sent from my SCH-I510 using Tapatalk
Anybody try this with voodoo yet ?
So i just wanted to share this info as it has been very helpful to me in my development process. When making custom recoveries you often end up with a recovery.img and with Samsung devices there isn't really a good way to flash those. The best way to flash these is to run the following on a linux box:
$ tar -H ustar -c recovery.img > recovery.tar
$ md5sum -t recovery.tar >> recovery.tar
$ mv recovery.tar recovery.tar.md5
Now you can flash that recovery.tar.md5 through Odin in the PDA tab. Im guessing you can use the same process on any .img file (userdata.img, etc.) you create but i havent tested that. Ive only tested this on recovery.img and it works great.
Sorry if this is old information but i couldn't find any posts in the Skyrocket section and just wanted to share this.
Thanks
Easiest way I've found to flash a recovery img on skyrocket is to rename recovery file to recovery.img and place it on internal SD. (This won't work if your soft bricked and a tar file will be necessary )
Then type: dd if=/sdcard/recovery.img of=/dev/block/mmcblk022 in adb shell or terminal emulator.
That should work for any of our recovery images as long as you rename it to recovery.img and put it in your internal SD. I suppose you could replace /sdcard/ with /external_sd/ if you wanted to flash from external SD. Oh and don't be supprised if you catch a little heat for posting this in dev section.
Sent from my SAMSUNG-SGH-I727 using xda premium
Noob question.... Is there a way to do this on windows vs linux?
cdshepherd said:
Easiest way I've found to flash a recovery img on skyrocket is to rename recovery file to recovery.img and place it on internal SD. (This won't work if your soft bricked and a tar file will be necessary )
Then type: dd if=/sdcard/recovery.img of=/dev/block/mmcblk022 in adb shell or terminal emulator.
That should work for any of our recovery images as long as you rename it to recovery.img and put it in your internal SD. I suppose you could replace /sdcard/ with /external_sd/ if you wanted to flash from external SD. Oh and don't be supprised if you catch a little heat for posting this in dev section.
Sent from my SAMSUNG-SGH-I727 using xda premium
Click to expand...
Click to collapse
dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p22 bs=4096
And not sure if there is a windows way. Try googling for Windows tar and md5sum. There most likely is a way.
Sent from my SAMSUNG-SGH-I727 using XDA App
Thank you
I used your method to flash the clockworkmod touch recovery. It worked flawlessly
Sk8er, I used your method today. Its flawless dude. Thanks
Sent from my SAMSUNG-SGH-I727 using xda premium
kamgrn said:
Noob question.... Is there a way to do this on windows vs linux?
Click to expand...
Click to collapse
funny... nobody bothered to answer this.
The way to do this in Windows as I know:
1. Ensure the fastboot drivers for your device is installed.
2. Acquire the fastboot binary (this is fastboot.exe).
3. Test if fastboot can see your device. Open DOS Command prompt, go to the fastboot binary folder and run "fastboot devices" command.
Example: C:\FASTBOOT\fastboot devices ---> The output should be some sort of serial number.
4. Flash the img file you have via command "fastboot flash boot <image_filename>"
Example: C:\FASTBOOT\fastboot flash boot boot.img
jtdc said:
funny... nobody bothered to answer this.
The way to do this in Windows as I know:
1. Ensure the fastboot drivers for your device is installed.
2. Acquire the fastboot binary (this is fastboot.exe).
3. Test if fastboot can see your device. Open DOS Command prompt, go to the fastboot binary folder and run "fastboot devices" command.
Example: C:\FASTBOOT\fastboot devices ---> The output should be some sort of serial number.
4. Flash the img file you have via command "fastboot flash boot <image_filename>"
Example: C:\FASTBOOT\fastboot flash boot boot.img
Click to expand...
Click to collapse
What if this is for the note, where there is no fastboot? I can get to odin mode, or to recovery mode, but no fastboot...unless i'm missing something..??
Thanks
Thank you for the post. I used your method but to flash TWRP as follows:
1. Downloaded recovery file (openrecovery-twrp-2.2.0-skyrocket.img) for Samsung Skyrocket from TWRP website on Linux.
2. Renamed file to recovery.img
3. Ran the following commands to covert IMG file to a TAR file:
tar -H ustar -c recovery.img > openrecovery-twrp-2.2.0-skyrocket.tar
md5sum -t openrecovery-twrp-2.2.0-skyrocket.tar >> openrecovery-twrp-2.2.0-skyrocket.tar
mv openrecovery-twrp-2.2.0-skyrocket.tar openrecovery-twrp-2.2.0-skyrocket.tar.md5
4. Flashed recovery using ODIN as customary.
It worked flawlessly with no issues. I highly recommend TWRP over CWM Touch Recovery. TWRP wipes things cleanly. You DO NOT have to wipe 3x which will reduce the wear and tear on your device.
ebaul said:
What if this is for the note, where there is no fastboot? I can get to odin mode, or to recovery mode, but no fastboot...unless i'm missing something..??
Thanks
Click to expand...
Click to collapse
use samsung tool kit v2.3. i had same issue as u and this page only sort of helped me and i guessed my way to tool kit. you only need to install it and place the recovery you need to transform in its input folder, where ever you installed it. then run it and just follow the instructions its pretty easy.
Thanks for the Pakistanian guy above me for reviving this vital topic ...
this method is great :
dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p22 bs=4096
BUT to be sure no leftovers are there :
dd if=/dev/zero of=/dev/block/mmcblk0p22
dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p22 bs=4096
Can be done inside Android if you're rooted , and a terminal emulator app is installed ...
nice commands to keep in mind.
mahanddeem said:
Thanks for the Pakistanian guy above me for reviving this vital topic ...
this method is great :
dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p22 bs=4096
BUT to be sure no leftovers are there :
dd if=/dev/zero of=/dev/block/mmcblk0p22
dd if=/sdcard/recovery.img of=/dev/block/mmcblk0p22 bs=4096
Can be done inside Android if you're rooted , and a terminal emulator app is installed ...
Click to expand...
Click to collapse
Lol
its pakistani
btw great the other method worked for you
sk8erwitskil said:
So i just wanted to share this info as it has been very helpful to me in my development process. When making custom recoveries you often end up with a recovery.img and with Samsung devices there isn't really a good way to flash those. The best way to flash these is to run the following on a linux box:
$ tar -H ustar -c recovery.img > recovery.tar
$ md5sum -t recovery.tar >> recovery.tar
$ mv recovery.tar recovery.tar.md5
Now you can flash that recovery.tar.md5 through Odin in the PDA tab. Im guessing you can use the same process on any .img file (userdata.img, etc.) you create but i havent tested that. Ive only tested this on recovery.img and it works great.
Sorry if this is old information but i couldn't find any posts in the Skyrocket section and just wanted to share this.
Thanks
Click to expand...
Click to collapse
Would it be the same approach whilst with custom zImage? and load into PDA tab? or are they any other settings to flash custom kernel with odin... I tried flashing with heimdall v.1.3.1 and 1.3.2 both version results "fail to initialise protocol". could please provide any pointes on how to flash custom built kernel image on S2 lte.
I think I finally find it!!
thank you man +1
mrbeers said:
Anyone have a CWD backup for the Repp? I am both newb & noob to the rooting scene and deleted my backup when I factory reset my phone. Any help will be appreciated. I'm gonna spam this message until I get my 10 posts then I'll post a new thread. Sorry mods! My family is without a phone until I fix this!
Click to expand...
Click to collapse
I don't recommend that if you want help
Sent from my SGH-I727 using Tapatalk 2
Huge thanks !
sk8erwitskil said:
So i just wanted to share this info as it has been very helpful to me in my development process. When making custom recoveries you often end up with a recovery.img and with Samsung devices there isn't really a good way to flash those. The best way to flash these is to run the following on a linux box:
$ tar -H ustar -c recovery.img > recovery.tar
$ md5sum -t recovery.tar >> recovery.tar
$ mv recovery.tar recovery.tar.md5
Now you can flash that recovery.tar.md5 through Odin in the PDA tab. Im guessing you can use the same process on any .img file (userdata.img, etc.) you create but i havent tested that. Ive only tested this on recovery.img and it works great.
Sorry if this is old information but i couldn't find any posts in the Skyrocket section and just wanted to share this.
Thanks
Click to expand...
Click to collapse
Hi! First of all, thx a lot really was trying to find this out for a long time. One Question i have tough. I Only used the first command and left it as a simple tar file, flashed it with odin and all was well. So what do you actally do by adding md5sum and then renaming it? Is it better to add the md5sum or does it make no difference?
again huge thanks! I always used mskip toolkit, but i like to not depend on additional software
I believe ODIN will verify the md5 sum of the .img if the .md5 file is in the tar. Just in case your .img in the tar gets corrupted. If that happens ODIN will abort the flash and report something like md5 mismatch
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
---------- Post added at 12:21 PM ---------- Previous post was at 12:20 PM ----------
So its not necessary but a good practice.
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
sk8erwitskil said:
So i just wanted to share this info as it has been very helpful to me in my development process. When making custom recoveries you often end up with a recovery.img and with Samsung devices there isn't really a good way to flash those. The best way to flash these is to run the following on a linux box:
$ tar -H ustar -c recovery.img > recovery.tar
$ md5sum -t recovery.tar >> recovery.tar
$ mv recovery.tar recovery.tar.md5
Now you can flash that recovery.tar.md5 through Odin in the PDA tab. Im guessing you can use the same process on any .img file (userdata.img, etc.) you create but i havent tested that. Ive only tested this on recovery.img and it works great.
Sorry if this is old information but i couldn't find any posts in the Skyrocket section and just wanted to share this.
Thanks
Click to expand...
Click to collapse
very helpful... thx mate
That's strange but command from first post don't work for me. Tablet says about incorrect file (.img, not .img.md5). So I've modified commands to make them work with Galaxy Tab 8.9 and Odin 1.8.5:
Code:
cp recovery.img recovery.img.md5
md5sum -t recovery.img.md5 >> recovery.img.md5
tar -H ustar -c recovery.img.md5 > recovery.tar
md5sum -t recovery.tar >> recovery.tar
mv recovery.tar recovery.tar.md5
I have not seen this posted anywhere, so I thought I would post it here. This is NOT purely my work, and I do not take credit for it as such.
Included in the attached ZIP are the following files:
boot_info - prints information about the boot.img passed to it, including the base address and ramdisk address. This tool prints out everything needed to repack the boot.img correctly.
split_boot - More commonly known as split_bootimg.pl, this rips apart the boot.img to extract the ramdisk and zImage. It has been modified by me to split the boot.img into a separate folder (specified by the file name of the boot.img passed to it) and to extract the ramdisk into a sub-folder as well (extracts the cpio from the gz and then extracts the actual files from the cpio archive)
unpack_ramdisk - unpacks the given ramdisk file.
Code:
Usage: unpack_ramdisk <ramdiskFile>
repack_ramdisk - repacks the ramdisk from the given directory (found online and modified slightly to take a directory)
Code:
Usage: repack_ramdisk <ramdiskDirectory> [outputFile]
mkbootimg - mkbootimg binary that creates a boot.img file from the given ramdisk and zImage. Updated to a version compiled by me to support the --ramdiskaddr option (ramdisk address) so that even nonstandard boot.img's can be repacked correctly (Use with boot_info for best results).
umkbootimg - included for convenience. Not made by me. Original thread here.
unpack - wrapper script made by me for the umkbootimg binary^ to unpack the boot.img into a separate directory and then unpack the ramdisk into a sub-directory.
Note: These tools were made for Linux. They may also work on Cygwin, but I have not personally tested them.
ANYONE is free to use / modify / kang these files as they see fit. No need to ever ask or do anything more than download.
Enjoy.
UPDATE: If you downloaded, please redownload. There was an error with my repack_ramdisk script, but it's fixed now.
Updated tools with a new boot_info script, also added my own mkbootimg binary compiled with the ramdisk address option.
Boot_info now displays the following information:
Commandline
Pagesize
Base address
Ramdisk address.
Which is everything you need to make a functional boot.img, even when the original boot.img is packed with a non-standard mkbootimg (ie, the ramdisk offset is different than the normal offset).
How exactly do we use these files to unpack and repack?
I've tried running the scripts with chmod at 755 but it doesn't work.
I am i missing something?
All the scripts must be in a folder in your path (~/bin for example)
Then it should work, because they call on each other. I keep all of them in my ~/bin folder, but they can be anywhere in your PATH
Sent from my buttered S3
if Android Magic Word not found at offset 0, it fail.
twins.7 said:
if Android Magic Word not found at offset 0, it fail.
Click to expand...
Click to collapse
No, if you use unmkbootimg instead split_boot, it also finds embedded images.
CNexus said:
No, if you use unmkbootimg instead split_boot, it also finds embedded images.
Click to expand...
Click to collapse
OK, it work. But .... sorry to much complain
My boot.img has magic word in offset 2048. so it mean, there is additional header in first 2048 byte.
umkbootimg succesfully extract embedded boot.img, but in repacking, I lost the first 2048 byte, because magic header placed in offset 0.
Actually, what is the additional header for? really asking...
I fail to fastboot flash if the image have no additional header.
And it will fail to verify, if the additional header is wrong. or is it called signed boot.img?
If I change the content of boot.img, I can't flash it to device. It always said verify fail. I though, the additional header has CRC or hash or anything.
If you have spare time and want to help me, I'll post my image
Thanks for this tools
Send from my AMOI N828 using Xda Premium
twins.7 said:
OK, it work. But .... sorry to much complain
My boot.img has magic word in offset 2048. so it mean, there is additional header in first 2048 byte.
umkbootimg succesfully extract embedded boot.img, but in repacking, I lost the first 2048 byte, because magic header placed in offset 0.
Actually, what is the additional header for? really asking...
I fail to fastboot flash if the image have no additional header.
And it will fail to verify, if the additional header is wrong. or is it called signed boot.img?
If I change the content of boot.img, I can't flash it to device. It always said verify fail. I though, the additional header has CRC or hash or anything.
If you have spare time and want to help me, I'll post my image
Click to expand...
Click to collapse
I'm not sure. No tool will work for all devices, and since I've never had a device that has this special packing, it would be best if you asked one of your kernel devs for help unpacking/repacking
CNexus said:
I'm not sure. No tool will work for all devices, and since I've never had a device that has this special packing, it would be best if you asked one of your kernel devs for help unpacking/repacking
Click to expand...
Click to collapse
ok thank's
CNexus said:
I have not seen this posted anywhere, so I thought I would post it here. This is NOT purely my work, and I do not take credit for it as such.
Included in the attached ZIP are the following files:
boot_info - prints information about the boot.img passed to it, including the base address and ramdisk address. This tool prints out everything needed to repack the boot.img correctly.
split_boot - More commonly known as split_bootimg.pl, this rips apart the boot.img to extract the ramdisk and zImage. It has been modified by me to split the boot.img into a separate folder (specified by the file name of the boot.img passed to it) and to extract the ramdisk into a sub-folder as well (extracts the cpio from the gz and then extracts the actual files from the cpio archive)
unpack_ramdisk - unpacks the given ramdisk file.
Code:
Usage: unpack_ramdisk <ramdiskFile>
repack_ramdisk - repacks the ramdisk from the given directory (found online and modified slightly to take a directory)
Code:
Usage: repack_ramdisk <ramdiskDirectory> [outputFile]
mkbootimg - mkbootimg binary that creates a boot.img file from the given ramdisk and zImage. Updated to a version compiled by me to support the --ramdiskaddr option (ramdisk address) so that even nonstandard boot.img's can be repacked correctly (Use with boot_info for best results).
umkbootimg - included for convenience. Not made by me. Original thread here.
unpack - wrapper script made by me for the umkbootimg binary^ to unpack the boot.img into a separate directory and then unpack the ramdisk into a sub-directory.
Note: These tools were made for Linux. They may also work on Cygwin, but I have not personally tested them.
ANYONE is free to use / modify / kang these files as they see fit. No need to ever ask or do anything more than download.
Enjoy.
Click to expand...
Click to collapse
is it possible to make these run on the device?
i have tried
adb root
adb remount
adb push * /sdcard/tmp/
adb push * /system/xbin/
adb push * /system/bin/
adb shell
cd /sdcard/tmp/
for f in $(ls)
do
chmod 755 /system/bin/$f
chmod 775 /system/xbin/$f
done
cd /
rm -r /sdcard/tmp
cd /sdcard/working
split_bootimg.pl boot.img
returns "Permission denied"
hmmmmm???????? what could be the problem????????
ricky310711 said:
is it possible to make these run on the device?
i have tried
adb root
adb remount
adb push * /sdcard/tmp/
adb push * /system/xbin/
adb push * /system/bin/
adb shell
cd /sdcard/tmp/
for f in $(ls)
do
chmod 755 /system/bin/$f
chmod 775 /system/xbin/$f
done
cd /
rm -r /sdcard/tmp
cd /sdcard/working
split_bootimg.pl boot.img
returns "Permission denied"
hmmmmm???????? what could be the problem????????
Click to expand...
Click to collapse
The Perl script should work if you have Perl (compiled for ARM x86) on your device.
The binaries will not work as they are not compiled for ARM. The scripts (at least some of them) should work if you change all instances of "#!/bin/bash" and "#!/usr/bin/env bash" to "#!/system/bin/sh".
CNexus said:
The Perl script should work if you have Perl (compiled for ARM x86) on your device.
The binaries will not work as they are not compiled for ARM. The scripts (at least some of them) should work if you change all instances of "#!/bin/bash" and "#!/usr/bin/env bash" to "#!/system/bin/sh".
Click to expand...
Click to collapse
will see if i can get it working tonight! this could be pretty good if i can get it to unpack on device!
ricky310711 said:
will see if i can get it working tonight! this could be pretty good if i can get it to unpack on device!
Click to expand...
Click to collapse
No need...download this zip and extract http://www12.zippyshare.com/v/37266634/file.html
It already contains an unmkbootimg binary compiled for ARM. Then you would just need to unpack the ramdisk to finish it off.
CNexus said:
No need...download this zip and extract http://www12.zippyshare.com/v/37266634/file.html
It already contains an unmkbootimg binary compiled for ARM. Then you would just need to unpack the ramdisk to finish it off.
Click to expand...
Click to collapse
no way, ive been looking for something like this for ages, who is the author?
ricky310711 said:
no way, ive been looking for something like this for ages, who is the author?
Click to expand...
Click to collapse
I don't know who originally compiled that unmkbootimg binary for ARM.
CNexus said:
I don't know who originally compiled that unmkbootimg binary for ARM.
Click to expand...
Click to collapse
hmm, gotta findout! i wanna use it in my tool!
Is this boot.img tool compatible with Microsoft windows as well?
Sent from my SPH-L710 using XDA Premium 4 mobile app
shakim24 said:
Is this boot.img tool compatible with Microsoft windows as well?
Sent from my SPH-L710 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Read the OP.
@BrateloSlava @bataya @xpirt @awidawad @old.splatterhand (and anyone else who can assist - thanks in advance)
Ok people, something doesn't feel right to me so I need confirmation... When you split the boot.img and then unpack the ramdisk, how many blocks should there be? I am getting 1851 when unpacking the ramdisk in to the ramdisk folder. See picture below to view what I am talking about.
I just feel like something is missing or isn't being unpacked properly.
Sent from my K2_CL using Tapatalk
Now I don't remember exactly but from what I see in picture seems all files are there.. You can use also unpackbootimg to unpack it, if you have linux.
xpirt
xpirt said:
Now I don't remember exactly but from what I see in picture seems all files are there.. You can use also unpackbootimg to unpack it, if you have linux.
xpirt
Click to expand...
Click to collapse
Don't have my pc with me so having to do this on my device. Just needed to confirm because I have changed ro.secure=1 to 0. When I repack the ramdisk and then the new ramdisk with the zimage to create the new modded boot.img I get a bootloop. Must be an error on my part then lol.
Sent from my K2_CL using Tapatalk
@simonsimons34 @BrateloSlava @bataya @xpirt @awidawad @old.splatterhand
(and anyone else who can assist)
Hmmm, ok...
Code:
unpackbootimg -i /system/Folder/boot.img -o /system/Folder/
I get the zImage and boot.img-ramdisk.gz.
I then do the following:
Code:
mkdir /system/Folder/ramdisk
cp /system/Folder/boot.img-ramdisk.gz /system/Folder/ramdisk
At this point I have created a folder named ramdisk and have copied the boot.img-ramdisk.gz over in to the ramdisk folder.
Next I do as followed:
Code:
cd /system/Folder/ramdisk
gunzip -cd ../boot.img-ramdisk.gz | cpio -i
I delete the ramdisk.gz file in the ramdisk folder because it is not needed there anymore after the extraction. I edit the default.prop file. Then I do as followed:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Ok, so now I have a new ramdisk that has been modded and repacked. I then run mkbootimg to join together the newramdisk.cpio.gz and zImage to form the modded boot.img. As followed:
Code:
mkbootimg --kernel /system/Folder/boot.img-zImage --ramdisk /system/Folder/newramdisk.cpio.gz --base 0x80400000 --pagesize 2048 --ramdiskaddr 0x81808000 --cmdline 'console=ttyHSL0,115200,n8 user_debug=31' -o /system/Folder/bootmod_4_1_2.img
Now I have the new boot.img running at a size of 5.93 MB.
I place the boot image in a zip with the android-info.txt and place it on the external sdcard. Boot in to bootloader, follow instructions, reboot. Then stuck on splash screen with red text.
Apparently I am doing something wrong with either unpacking or packing the boot.img.
And I am becoming pretty annoyed with it lol.
Sent from my K2_CL using Tapatalk
I should add, that I open up the original boot.img with a hex editor and remove everything before ANDROID! then save so when I run unpackbootimg it reads the android magic value properly.
Sent from my K2_CL using Tapatalk
Inside the ramdisk folder...
Sent from my K2_CL using Tapatalk
And a picture showing the original ramdisk, new ramdisk, original boot, and new boot....
Sent from my K2_CL using Tapatalk
Nobody huh? Lol
Sent from my K2_CL using Tapatalk
Well, manage to repack the boot.img while holding up to 16 mb then wrote the img to the device. Making progress I guess, as it now will boot, stick on splash screen, then reboot in to TWRP recovery lol. Will keep at it until I resolve this one way or the other
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
Nobody huh? Lol
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Sorry, but i never worked on boot.img/kernels. So in this case i'm not the right one to help.
old.splatterhand said:
Sorry, but i never worked on boot.img/kernels. So in this case i'm not the right one to help.
Click to expand...
Click to collapse
No worries, just tagging people on here who I know are a little more experience then others. For those I did not tag (take no offense - you were under the radar).
Anyways, I went ahead and just unpacked then repacked everything without making any edits and still the same results. Not sure what is going on now. Has something to do with repackaging the boot.img I'm sure but can't seem to pin point the problem.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
No worries, just tagging people on here who I know are a little more experience then others. For those I did not tag (take no offense - you were under the radar).
Anyways, I went ahead and just unpacked then repacked everything without making any edits and still the same results. Not sure what is going on now. Has something to do with repackaging the boot.img I'm sure but can't seem to pin point the problem.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Removed. Saw you packed it fine.. The problem is not when you pack the kernel and ramdisk but I think when you pack the ramdisk, try without unpacking it.
xpirt
For unpack kernel and pack ramdisk I'm use cygwin and View attachment tools_for_cygwin.7z.
From cygwin console:
Kernel built from parts I perform under Ubuntu:
Code:
~/boot_tools/mkbootimg --kernel ~/Kernel_output/zImage --ramdisk ~/Kernel_output/ramdisk.gz --base 0x80400000 --pagesize 2048 --ramdiskaddr 0x81808000 --cmdline ~/Kernel_output/cmdline.txt -o boot-new.img
In the example, I have post the commands for compiling a new kernel 4.1.2
I think he is using the phone, with computer it's more simple.
xpirt
@xpirt @BrateloSlava
I am using my phone. And with mkbootimg I am using just as BrateloSlava demonstrated. However, you are using a text file which holds your cmdline... Maybe I should try that lol.
Sent from my K2_CL using Tapatalk
I also noticed in @BrateloSlava picture when he goes to unpack the ramdisk in to the ramdisk folder it counts up to 1944 blocks while for me I am only getting 1851. Assuming this is the case, then that is where my problem is. I am missing stuff lol.
Sent from my K2_CL using Tapatalk
old.splatterhand said:
Sorry, but i never worked on boot.img/kernels. So in this case i'm not the right one to help.
Click to expand...
Click to collapse
+1, but I think that problem is phone. You should try do it on pc.
bataya said:
+1, but I think that problem is phone. You should try do it on pc.
Click to expand...
Click to collapse
Will be doing that today and comparing results from both the pc and phone version with a hex editor to determine what the problem is. Something isn't adding up because I've edited boot images before. This is just the first time I've done it on a phone lol.
Sent from my K2_CL using Tapatalk
Update: been reviewing the open source code from dsixda kitchen in regards to the boot.img. Rebuilding the sources for arm devices. Seems the current build I have from another source is lacking stuff which isn't building the boot.img properly after careful analysis between the modboot.img on my device and the modboot.img on my PC.
After the rebuilt is successful then my problem will be resolved and I will change the title to (solved).
Sent from my K2_CL using Tapatalk
Thread title updated. Compiled source code was successful. Managed to unpack, edit, repack, and use dd to write the boot.img straight to the partition then reboot. All of this on my device without a PC. Everything went well.
Pat on the back lol.
Sent from my K2_CL using Tapatalk
Hi,
when I still hadn't the device, I wanted to know exactly what's included in stock ROMs to have a better idea of what to expect. I hence downloaded a stock firmare and the stock system.img (see below for the steps).
Ok, so what? Well, when KK was released I decided to do the same (I was still waiting for the device), but I couldn't. Unlike before, I didn't find a single system.img, but multiple files (3 to be exact, maybe it's too big to be flashed at once with fastboot, I don't know, I'm new to this) and couldn't understand how the original image was splitted to generate those files.
Did anyone see something similar already and sucesfully merged splitted filesystems?
I know I could simply ask for a system dump (or wait for KK), but now I'm curious to know on how to do this. I tried few things but I couldn't find any way to do it. Maybe I could see how fastboot treat these files, but I wonder if anyone already knows the answer.
Anyway, here the steps to mount the system.img of our stock JB firmwares. Maybe there's an easier way, I honestly don't know. As far as I know, converting the sparge image should be enough, but I had to do more:
Code:
#Convert sparse image with simg2img
simg2img system.img system.img.raw.tmp
#UTF8 may slow down grep, switch to C
export LANG=C
#Look for the ext4 magic and calculate its position
magic=`grep -aobP -m1 '\x53\xEF' system.img.raw.tmp | head -1 | cut -d":" -f1`
offset=$(($magic-1080))
#Remove extra header with dd
dd if=system.img.raw.tmp of=system.img.raw ibs=$offset skip=1
#Remove temp file
rm system.img.raw.tmp
Now you can mount system.img.raw as a normal ext4 filesystem.
Just concatenate the three chunks together like so:
Code:
cat system.img_sparsechunk1 system.img_sparsechunk2 system.img_sparsechunk3 > system.img
Then apply the steps from the OP and voilà!
Edit: Scratch that: the image is accessible, some files are visible but others are missing. To be continued...
Darkshado said:
Just concatenate the three chunks together like so:
Code:
cat system.img_sparsechunk1 system.img_sparsechunk2 system.img_sparsechunk3 > system.img
Then apply the steps from the OP and voilà!
Edit: Scratch that: the image is accessible, some files are visible but others are missing. To be continued...
Click to expand...
Click to collapse
As you have found that doesn't work, remember that each file will have metadata headers so that may be one reason you can't just cat them together.
To OP - can't you just mount each img as a filesystem and copy all the files from each mounted filesystem to another entirely separate directory. At least that way you have all the files in one place, eg copy
/sparsechunk1/system/file1 to /newdir/system/file1
And so on.
scott_doyland said:
As you have found that doesn't work, remember that each file will have metadata headers so that may be one reason you can't just cat them together.
To OP - can't you just mount each img as a filesystem and copy all the files from each mounted filesystem to another entirely separate directory. At least that way you have all the files in one place, eg copy
/sparsechunk1/system/file1 to /newdir/system/file1
And so on.
Click to expand...
Click to collapse
Only the first chunk can be mounted, the other two are not recognized as filesystem and there's no way to mount them.
It's not as if /system was divided in three parts and then an image for each one was created, so that you can treat them as separate files (what you said would work in this case).
One image is created and then it's splitted in three in some unknown way. The first image is the one that holds the informations to access the files, the other two just pieces of files that can't be accessed without the informations in the first chunk.
mfastboot knows how to correctly copy the data from the separate images with the right offsets inside the phone so that in the end all the files can be accessed. Concatenating the files using dd using the correct offsets could maybe work, but after a few attempts I gave up.
There is method to extract files under Windows
Al936 said:
There is method to extract files under Windows
Click to expand...
Click to collapse
Any change you happen to be willing to share the contents of or principles behind `sparse2img.exe`?
HolySid said:
Any change you happen to be willing to share the contents of or principles behind `sparse2img.exe`?
Click to expand...
Click to collapse
What kind of principles you expect from me? I just posted the link to one of the method to extract all files and folders from stock firmware's system partition. The tools were not developed by me - I just informed XDA community about it. As you can see from the tread several persons already confirmed that it works.
Al936 said:
What kind of principles you expect from me? I just posted the link to one of the method to extract all files and folders from stock firmware's system partition. The tools were not developed by me - I just informed XDA community about it. As you can see from the tread several persons already confirmed that it works.
Click to expand...
Click to collapse
Oh, I'm sorry, I thought it was your work. I just want to know how to merge the system files. I know the exe is working, but I'm running Linux, so my question it is both out of curiosity and simply because I cannot run the code.
Try running it with wine or in virtual machine.
sent via tapatalk
Thanks, I managed it by using another laptop. But still, I'd rather know what happened
Sent from my XT1032 using xda app-developers app
Darkshado said:
Just concatenate the three chunks together like so:
Code:
cat system.img_sparsechunk1 system.img_sparsechunk2 system.img_sparsechunk3 > system.img
Then apply the steps from the OP and voilà!
Edit: Scratch that: the image is accessible, some files are visible but others are missing. To be continued...
Click to expand...
Click to collapse
I just replaced the first line in the OP's instructions with this to join the system.img_sparsechunk files:
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
And then the rest worked fine. Here were the exact steps I took (I shortened it a tiny bit, but it's the same concept):
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
offset=`LANG=C grep -aobP -m1 '\x53\xEF' system.img.raw.tmp | head -1 | awk '{print $1 - 1080}'`
dd if=system.img.raw.tmp of=system.img.raw ibs=$offset skip=1
sudo mkdir /mnt/system
sudo mount system.img.raw /mnt/system
SenorChang said:
I just replaced the first line in the OP's instructions with this to join the system.img_sparsechunk files:
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
And then the rest worked fine. Here were the exact steps I took (I shortened it a tiny bit, but it's the same concept):
Code:
simg2img system.img_sparsechunk.* system.img.raw.tmp
offset=`LANG=C grep -aobP -m1 '\x53\xEF' system.img.raw.tmp | head -1 | awk '{print $1 - 1080}'`
dd if=system.img.raw.tmp of=system.img.raw ibs=$offset skip=1
sudo mkdir /mnt/system
sudo mount system.img.raw /mnt/system
Click to expand...
Click to collapse
It worked. Thank you!