Database Info

[GUIDE] Howto create an insecure boot image for asus tf101

NOTE: I started few days ago working with the boot image.
I'm not an Android expert. If you find an error in this post, let me know.
Use this information at your own risk. If you brick your tablet, don't blame on me.
Nothing of the tools used here are written by me. I'm not taking credit for another's work.
I have rooted my tf101 with the instructions from the mashi's thread. (http://forum.xda-developers.com/showthread.php?t=1125714)
I was curious about the root process of our beloved tablet.
For add root at the stock firmware you need the su packages and a proper boot image.
I've worked for years on linux machines, so I know that you need the "su" command to become root.
But what about the boot image? What does it need for?
I've googled and found some information that I'd like to share with you:
For using adb as superuser, and push the su package, you need to flash a so called "insecure boot" on your tablet/phone.
The process is easy:
NOTE: Even if I'm on a Windows machine, I prefer to do this work in linux. The entire process has been done in an Ubuntu 11.04 virtual machine.
What you need:
- a PC running linux
- BootTools and BlobTools from Rayman84 (http://androidroot.mobi/)
- mkbootimg (mkbootfs is optional) from the android repository
I assume that you have all the above tools in your $PATH variable.
First of all you need a stock boot image; you can extract one from your tablet (with nvflash) or from the latest stock firmware (US-VERSION - WW-VERSION)
We're going for the official packages from the ASUS website. Download it on your home directory (or wherever you want).
Let's start:
Code:
mkdir stock_firmware
cd stock_firmware
unzip ../UpdateLauncher_WW_epaduser_84411.zip
unzip ASUS/Update/WW_epad-user-8.4.4.11.zip
blobunpack blob
bootunpack blob.LNX
Now we have a lot of "strange" files:
Code:
ASUS
blob
blob.APP
blob.EBT
blob.HEADER
blob.LNX
blob.LNX-config
blob.LNX-kernel.gz
blob.LNX-ramdisk.cpio.gz
blob.PT
blob.SOS
META-INF
For our work, we just need blob.LNX-ramdisk.cpio.gz
Code:
mkdir boot_img
cd boot_img
gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i
vi default.prop (or "gedit default.prop" if you want a GUI)
Here you have to change the line "ro.secure=1" in "ro.secure=0"
The final file should appears as this:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=0
Almost done. Let's repack:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
or alternatively:
Code:
mkbootfs ./ | gzip > ../newramdisk.cpio.gz
Finally make the boot.img:
Code:
cd ..
mkbootimg --kernel blob.LNX-kernel.gz --ramdisk newramdisk.cpio.gz -o boot.img
Now you have your boot.img, ready to be flashed with nvflash.
For information on what to do with this file, please refer to the mashi or brk threads.
Again, I've taken this information from google.
All the credits and many thanks to:
Rayman for the BlobTools and the BootTools - http://androidroot.mobi/
Mashi for his thread on rooting the stock kernel - http://forum.xda-developers.com/showthread.php?t=1125714
Brk for his batch script - http://forum.xda-developers.com/showthread.php?t=1185104
If you found this guide useful, hit the "Thanks" button.
For your convenience, you can find the tools used attached in this post (compiled on Ubuntu 11.04).
UPDATE: I have written a script (thanks gnufabio for the idea) that automatically modify a stock boot.img into an insecure one.
ex:
Code:
./insecure.sh boot.img
when the script finishes you will find a file called my_boot.img ready to be flashed with nvflash.
Bootunpack and mkbootimg should be in your $PATH.
This script doesn't do much error checking, so keep your eyes open.
HF

hey thanks very nice guide

Excellent. I've been looking around trying to work out how to package up a kernel build, this helps a great deal.
I'm assuming that I just replace the blob.LNX-kernel.gz with my built zImage?

SammyC said:
Excellent. I've been looking around trying to work out how to package up a kernel build, this helps a great deal.
I'm assuming that I just replace the blob.LNX-kernel.gz with my built zImage?
Click to expand...
Click to collapse
I haven't try but i guess yes.
If you really want to recompile/repackage the kernel, you can refer to this http://www.droidforums.net/forum/rescue-squad-guides/31452-how-compile-your-own-kernel.html ; it's about the Motorola Droid, but some concepts are universal for all the android devices.
HF

Good work, btw give a look to this script i made: mcpio
Unpacking and repacking the ramdisk will be easier:
Code:
mcpio -c ramdisk-folder/
mcpio -e ramdis-archive.cpio.gz

Thanks - Very useful to have this in this section. I tried the example, and it all worked fine on an old Ubuntu dist.

gnufabio said:
Good work, btw give a look to this script i made: mcpio
Unpacking and repacking the ramdisk will be easier:
Code:
mcpio -c ramdisk-folder/
mcpio -e ramdis-archive.cpio.gz
Click to expand...
Click to collapse
Well, that's a lot easier...
I didn't know your script, thanks for sharing.

Updated the first post with a bash script to automate the entire process.
Yesterday I've succesfully recompiled the stock kernel and I'm thinking on write another guide like this one on the subject.
The process is a little complicate, i'm looking for an easy way to explain but it's hard.
Anyway I'm working on it in my spare time.

That would be great if you could.

ASUS haven't (yet) released the source for the kernel in their latest 3.2 build. If you've updated to 3.2, you can still root and repackage using this method. Just use nvflash to save off the kernel from your running device as per the backup/restore thread, then use bootunpack on that and follow the rest of the instructions

raypou said:
ASUS haven't (yet) released the source for the kernel in their latest 3.2 build. If you've updated to 3.2, you can still root and repackage using this method. Just use nvflash to save off the kernel from your running device as per the backup/restore thread, then use bootunpack on that and follow the rest of the instructions
Click to expand...
Click to collapse
it's exactly the method used here: http://forum.xda-developers.com/showthread.php?t=1198303

If anyone interested, here're win32 binaries of BlobTools and BootTools
Just compiled from git repo.

I unpacked a rom with a kernelblob in the root directory, and edited init.rc. Which command should I use to repackage it? If I follow the guide (instead of boot.img I used kernelblob, no extension) I get the EEE Pad logo then scrambled, colored lines all over.
If I, however, install the base rom, then the one where I changed something in the kernelblob, it boots up.

theMIROn said:
If anyone interested, here're win32 binaries of BlobTools and BootTools
Just compiled from git repo.
Click to expand...
Click to collapse
Hi, makebootimg.exe doesn't work. It gives error saying: error: could not load kernel 'blob.LNX-kernel.gz'
Tried same files in linux and worked fine.
Can you try to fix this?
EDIT: tried to compile myself but got the same issue. I think is related with the need to change source code to make this run on windows.

Working boottools for windows available here: http://forum.xda-developers.com/showpost.php?p=17237701&postcount=443

brk said:
Hi, makebootimg.exe doesn't work. It gives error saying: error: could not load kernel 'blob.LNX-kernel.gz'
Tried same files in linux and worked fine.
Can you try to fix this?
Click to expand...
Click to collapse
yep, it's code issue
attached BootTools-Win32.zip with fixed mkbootimg.exe

is there this guide for tf201?
BR
Maframan

maframan said:
is there this guide for tf201?
BR
Maframan
Click to expand...
Click to collapse
You should probably check the TF201 forum.

Could this method be used to pack a new Splash Screen? (I want to change that annoying ASUS logo to something better) Would I go about the Flash_Image method to flash the image after compiled? (I do Not have NvFlash, but I am rooted with Cwm)
Which blobs would I modify as well, just the EBT?

rebound821 said:
NOTE: I started few days ago working with the boot image.
I'm not an Android expert. If you find an error in this post, let me know.
Use this information at your own risk. If you brick your tablet, don't blame on me.
Nothing of the tools used here are written by me. I'm not taking credit for another's work.
I have rooted my tf101 with the instructions from the mashi's thread. (http://forum.xda-developers.com/showthread.php?t=1125714)
I was curious about the root process of our beloved tablet.
For add root at the stock firmware you need the su packages and a proper boot image.
I've worked for years on linux machines, so I know that you need the "su" command to become root.
But what about the boot image? What does it need for?
I've googled and found some information that I'd like to share with you:
For using adb as superuser, and push the su package, you need to flash a so called "insecure boot" on your tablet/phone.
The process is easy:
NOTE: Even if I'm on a Windows machine, I prefer to do this work in linux. The entire process has been done in an Ubuntu 11.04 virtual machine.
What you need:
- a PC running linux
- BootTools and BlobTools from Rayman84 (http://androidroot.mobi/)
- mkbootimg (mkbootfs is optional) from the android repository
I assume that you have all the above tools in your $PATH variable.
First of all you need a stock boot image; you can extract one from your tablet (with nvflash) or from the latest stock firmware (US-VERSION - WW-VERSION)
We're going for the official packages from the ASUS website. Download it on your home directory (or wherever you want).
Let's start:
Code:
mkdir stock_firmware
cd stock_firmware
unzip ../UpdateLauncher_WW_epaduser_84411.zip
unzip ASUS/Update/WW_epad-user-8.4.4.11.zip
blobunpack blob
bootunpack blob.LNX
Now we have a lot of "strange" files:
Code:
ASUS
blob
blob.APP
blob.EBT
blob.HEADER
blob.LNX
blob.LNX-config
blob.LNX-kernel.gz
blob.LNX-ramdisk.cpio.gz
blob.PT
blob.SOS
META-INF
For our work, we just need blob.LNX-ramdisk.cpio.gz
Code:
mkdir boot_img
cd boot_img
gunzip -dc ../blob.LNX-ramdisk.cpio.gz | cpio -i
vi default.prop (or "gedit default.prop" if you want a GUI)
Here you have to change the line "ro.secure=1" in "ro.secure=0"
The final file should appears as this:
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=0
Almost done. Let's repack:
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
or alternatively:
Code:
mkbootfs ./ | gzip > ../newramdisk.cpio.gz
Finally make the boot.img:
Code:
cd ..
mkbootimg --kernel blob.LNX-kernel.gz --ramdisk newramdisk.cpio.gz -o boot.img
Now you have your boot.img, ready to be flashed with nvflash.
For information on what to do with this file, please refer to the mashi or brk threads.
Again, I've taken this information from google.
All the credits and many thanks to:
Rayman for the BlobTools and the BootTools - http://androidroot.mobi/
Mashi for his thread on rooting the stock kernel - http://forum.xda-developers.com/showthread.php?t=1125714
Brk for his batch script - http://forum.xda-developers.com/showthread.php?t=1185104
If you found this guide useful, hit the "Thanks" button.
For your convenience, you can find the tools used attached in this post (compiled on Ubuntu 11.04).
UPDATE: I have written a script (thanks gnufabio for the idea) that automatically modify a stock boot.img into an insecure one.
ex:
Code:
./insecure.sh boot.img
when the script finishes you will find a file called my_boot.img ready to be flashed with nvflash.
Bootunpack and mkbootimg should be in your $PATH.
This script doesn't do much error checking, so keep your eyes open.
HF
Click to expand...
Click to collapse
Hi Sir,
First of all thankyou for you guide because I did follow you guide and created the insecure boot.image succesfully. I still have one problem, after flashing the boot.image, I still could not root the android device. Why is that? Do I need to change something else in the boot.img?

[Q] how to flash and backup kernel?

I following the instructions found from here:
Building Kernels
and download the kernel from here:
INDEX of ROMS/RECOVERY/ROOT/GUIDES/FIRMWARE/KERNEL/VIDEOS/etc..
I am using TF300TG, so I just followed the link to my tablet kernel source from the thread. I have successfully built the kernel by using the config.gz found in the tablet /proc/config.gz (is great that Asus is providing such info). I also enable a kernel module for my old USB ethernet dongle and able to use it to get online. :victory:
After poking around the kernel configuration, and reading the thread TF300T kernel source repository, I am curious about enabling OC and possible other features. I had downloaded the update.zip from the thread, and trying to understand the whole process of how to flash kernel to the tablet. My idea is to modify the update.zip to make use of it to update my tablet. But before I start doing something serious, I have questions...
I found the following kernel file: kernel.blob in update.zip. Is this the same file as 'zImage' in arch/arm/boot/ after built successful?
The next question is on how to backup my existing kernel? I notice from the update-script, the kernel is flash using the following command:
run_program("/sbin/busybox", "dd", "if=/tmp/kernel.blob", "of=/dev/block/mmcblk0p4");
Click to expand...
Click to collapse
Does this mean, I can run the same command in reverse to keep a copy of my current kernel?
I had done kernel compiling before, but those were in PC/x86 platform. ARM platform seems to be different from what I used to.

I found the following kernel file: kernel.blob in update.zip. Is this the same file as 'zImage' in arch/arm/boot/ after built successful?
Click to expand...
Click to collapse
Not exactly...
A blob file is a sort of archive that can contain several files.
For example, the kernel.blob you mention above contains the actual kernel (zImage) but also a ram disk.
As far as I understand a blob file is the only type of file that can be flashed to different partitions of your TF300T(G) using fastboot method.
To flash using CWM or TWRP you will need to pack blob file(s) into a special kind of zip package.
Below I have shared my script that I use to create a TWRP flashable zip package including a custom built kernel.
Hopefully it may shed some light in the steps required to go from zImage to blob file and TWRP flashable zip package.
The script takes the root path to your kernel source directory as first (and only) argument.
In same directory as script I have unpacked update.zip (from untermensch's kernel repository thread) as parts of this zip file are re-used.
---
#!/bin/sh
KERNEL_HOME=$1
KERNEL_NAME=my_kernel_$$
# Repack new kernel and old ram disk into blob file
cp ${KERNEL_HOME}/arch/arm/boot/zImage boot.blob.lnx-kernel.gz
repack-bootimg.pl boot.blob.lnx-kernel.gz boot.blob.lnx-ramdisk out.blob.lnx
blobpack out.blob LNX out.blob.lnx
# Prepend magic header
cat signblob_magic out.blob > kernel.blob
# Add kernel modules to ensure kernel and modules always match.
# If mismatch e.g WiFi might not work.
find ${KERNEL_HOME} -name "*.ko" -exec cp {} system/lib/modules \;
# Save kernel config in case it needs to be rebuilt some day.
cp ${KERNEL_HOME}/.config kernel_config
# Zip everything
zip -9 -r ${KERNEL_NAME}.zip kernel_config kernel.blob system/ META-INF/
# Sign zip using SignApk
java -Xmx1024m -jar signapk.jar -w testkey.x509.pem testkey.pk8 ${KERNEL_NAME}.zip ${KERNEL_NAME}-signed.zip
---
The next question is on how to backup my existing kernel? I notice from the update-script, the kernel is flash using the following command:
Does this mean, I can run the same command in reverse to keep a copy of my current kernel?
Click to expand...
Click to collapse
In theory this should work but if not mistaken mmcblk0p4 is just a sort of staging partition.
During bootup whatever is in mmcblk0p4 is copied to another partition (mmcblk0p0?).
(I guess this is the blue bar you can observe when flashing custom roms/kernels)
Someone more familiar with the details please correct me.
Instead of trying to backup your current kernel I would suggest to try to get the original
kernel by unpacking the official update packages from ASUS support web page.
I had done kernel compiling before, but those were in PC/x86 platform. ARM platform seems to be different from what I used to.
Click to expand...
Click to collapse
Not that much different really, just need to search the google.com and XDA forums and you shall find answers...

gaze57 said:
Not exactly...
A blob file is a sort of archive that can contain several files.
For example, the kernel.blob you mention above contains the actual kernel (zImage) but also a ram disk.
As far as I understand a blob file is the only type of file that can be flashed to different partitions of your TF300T(G) using fastboot method.
To flash using CWM or TWRP you will need to pack blob file(s) into a special kind of zip package.
Below I have shared my script that I use to create a TWRP flashable zip package including a custom built kernel.
Hopefully it may shed some light in the steps required to go from zImage to blob file and TWRP flashable zip package.
The script takes the root path to your kernel source directory as first (and only) argument.
In same directory as script I have unpacked update.zip (from untermensch's kernel repository thread) as parts of this zip file are re-used.
---
#!/bin/sh
KERNEL_HOME=$1
KERNEL_NAME=my_kernel_$$
# Repack new kernel and old ram disk into blob file
cp ${KERNEL_HOME}/arch/arm/boot/zImage boot.blob.lnx-kernel.gz
repack-bootimg.pl boot.blob.lnx-kernel.gz boot.blob.lnx-ramdisk out.blob.lnx
blobpack out.blob LNX out.blob.lnx
# Prepend magic header
cat signblob_magic out.blob > kernel.blob
# Add kernel modules to ensure kernel and modules always match.
# If mismatch e.g WiFi might not work.
find ${KERNEL_HOME} -name "*.ko" -exec cp {} system/lib/modules \;
# Save kernel config in case it needs to be rebuilt some day.
cp ${KERNEL_HOME}/.config kernel_config
# Zip everything
zip -9 -r ${KERNEL_NAME}.zip kernel_config kernel.blob system/ META-INF/
# Sign zip using SignApk
java -Xmx1024m -jar signapk.jar -w testkey.x509.pem testkey.pk8 ${KERNEL_NAME}.zip ${KERNEL_NAME}-signed.zip
---
In theory this should work but if not mistaken mmcblk0p4 is just a sort of staging partition.
During bootup whatever is in mmcblk0p4 is copied to another partition (mmcblk0p0?).
(I guess this is the blue bar you can observe when flashing custom roms/kernels)
Someone more familiar with the details please correct me.
Instead of trying to backup your current kernel I would suggest to try to get the original
kernel by unpacking the official update packages from ASUS support web page.
Not that much different really, just need to search the google.com and XDA forums and you shall find answers...
Click to expand...
Click to collapse
Whoa... Thanks for the info. I go read up more on this.

RE-Odex ROM (Flashable Zip in CWM)

Original thread (zman0900) : http://forum.xda-developers.com/showthread.php?t=1441293
I just slightly modified.
ROM, Google Apps, MODs .... Now for the daily drive? Just Flash this zip in CWM. (Don't flash in TWRP. Not working with that)
The attached files are just examples. If you're running that ROM, flash that zip matches the name. That's all.
Otherwise, you can modify odex.sh in zip.
1) Red
BOOTCLASSPATH found in init.rc on your device's root. Or extract boot.img then you can find that in the ramdisk.
2) Blue
Looking above add or remove
e.g. CM10.1
Code:
#!/tmp/busybox sh
export PATH=/tmp:$PATH
export BOOTCLASSPATH=[COLOR="Red"]/system/framework/core.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/telephony-common.jar:/system/framework/mms-common.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/apache-xml.jar[/COLOR]
# Order matters here, up to BOOTCLASSPATH
FRAMEWORK="[COLOR="Blue"]/system/framework/core.jar
/system/framework/core-junit.jar
/system/framework/bouncycastle.jar
/system/framework/ext.jar
/system/framework/framework.jar
/system/framework/telephony-common.jar
/system/framework/mms-common.jar
/system/framework/android.policy.jar
/system/framework/services.jar
/system/framework/apache-xml.jar[/COLOR]"
# Odex Framework Rest
REST="/system/framework/*.jar"
# Odex apps
APPS="/system/app/*.apk"
# Set up busybox symlinks
for i in $(busybox --list)
do
ln -s busybox /tmp/$i
done
# Framework
for i in $FRAMEWORK
do
odex=`echo $i | sed -e 's/.jar/.odex/g'`
dexopt-wrapper $i $odex
zip -d $i classes.dex
done
# Framework Rest
for i in $REST
do
odex=`echo $i | sed -e 's/.jar/.odex/g'`
dexopt-wrapper $i $odex
zip -d $i classes.dex
done
# System apps
for i in $APPS
do
odex=`echo $i | sed -e 's/.apk/.odex/g'`
dexopt-wrapper $i $odex
zip -d $i classes.dex
done
# wipe Dalvik-cache
rm -rf /data/dalvik-cache
rm -rf /cache/dalvik-cache

As for TWRP
Dees_Troy said:
The copy of dexopt-wrapper that you have included in the zip is dynamically linked. This means that the binary is using libraries from /system/lib in order to run. You may run into problems with this binary working on some ROMs as variances in libraries may fail to link properly with your binary. The reason it doesn't work with TWRP is because TWRP is dynamically linked and TWRP is usually set up to prevent linking to libraries in /system. The best practice would be to build your own dexopt-wrapper binary that is statically linked so that it doesn't need any outside libraries to run.
Click to expand...
Click to collapse

can work this script for nexus 4?

misha84 said:
can work this script for nexus 4?
Click to expand...
Click to collapse
On any device and Android version, this can work
Before flashing, check your init.rc

For aokp 4.2.2 I assume is cm10.1 zip? BTW, I just flashed it on a cm10.1 based ROM, I thought /system/app should have odex files? I only see core.odex in /system/framework.
Sent from my GT-P7500 using XDA Premium HD app

eushaun99 said:
For aokp 4.2.2 I assume is cm10.1 zip? BTW, I just flashed it on a cm10.1 based ROM, I thought /system/app should have odex files? I only see core.odex in /system/framework.
Sent from my GT-P7500 using XDA Premium HD app
Click to expand...
Click to collapse
BOOTCLASSPATH may be diffrent. Check your init.rc

What's the benefit of having framework being odex-ed?
Will this work on SlimROM which is AOSP & CM based?
Thanks

rmsinaga said:
What's the benefit of having framework being odex-ed?...
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?p=20281743
http://forum.xda-developers.com/showthread.php?t=1423118
http://forum.xda-developers.com/showthread.php?t=2200349
http://forum.xda-developers.com/showthread.php?t=1443957
rmsinaga said:
...
Will this work on SlimROM which is AOSP & CM based?
...
Click to expand...
Click to collapse
On any device and Android version, this can work
Before flashing, check your init.rc. If different, edit odex.sh in zip.

I've tried this to SlimROM v6.5. It works. Thank you.

I get status 0. CWM 5.0.28

Kevinjoa said:
I get status 0. CWM 5.0.28
Click to expand...
Click to collapse
I'm not sure, try another CWM version. As for me, I'm using CWM v6.0.1.0
Or try the attached in this post, just repacked

Kevinjoa said:
I get status 0. CWM 5.0.28
Click to expand...
Click to collapse
Replace the update-binary in the zip with one that works for you.
Sent from my GT-P7500 using XDA Premium HD app

work very well with purity rom (source CM 10.1) & nexus 4
thanks!

this looks really nice!
i was thinking, system apps don't need there libs anymore there are saved in /system/lib. could the script be extended to remove the lib just like the dex file?

Thanks! Finally Odexed my CM9... Using LG Optimus L3... Works smoothly!

Works perfect with TWRP 2.6.0.1 on the N7100 with Carbon (CM 10.1 base)...

Need odex for my stock ROM. Please dev.
Sent from my iris504Q using xda app-developers app

violin.siva said:
Need odex for my stock ROM. Please dev.
Sent from my iris504Q using xda app-developers app
Click to expand...
Click to collapse
Stock ROM is odexed...
Sent from my GT-P7500 using Tapatalk HD

Just FYI,
Don't run these on CM 10.2. They don't work.

The zip for CM10.2 (Android 4.3) added in OP

[TUTORIAL] How to repackage ODIN files

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

[SOLVED] Boot.img needing assistance

@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