Database Info

Please Mod's Delete this thread!

There's nothing here to see // Regards

Unpacking and packing the blobs is the easy part- I did this just yesterday when I was fooling around with my TF. The hard part is getting them to flash. On an unrooted TF, the staging partition is read only and the stock recovery won't flash it if the crypto signature is wrong.
In fact, I think this was one of the early root exploits- use gingerbreak to gain root access, then send a blob to the staging partition. This will flash on reboot and install clockworkmod. Unfortunately, gingerbreak only works on the earlier firmware.

Maybe i have missed something...
The firmware of honeycomb is downloadable from the asus website.
You can extract it with blobunpack by Rayman, edit it, add/remove things, put the sudo and superuser packages etc...
If your device isn't already rooted, you can't flash it back

gee one said:
Unpacking and packing the blobs is the easy part- I did this just yesterday when I was fooling around with my TF. The hard part is getting them to flash. On an unrooted TF, the staging partition is read only and the stock recovery won't flash it if the crypto signature is wrong.
In fact, I think this was one of the early root exploits- use gingerbreak to gain root access, then send a blob to the staging partition. This will flash on reboot and install clockworkmod. Unfortunately, gingerbreak only works on the earlier firmware.
Click to expand...
Click to collapse
got it: blob.APP how to extract this
rebound821 said:
Maybe i have missed something...
The firmware of honeycomb is downloadable from the asus website.
You can extract it with blobunpack by Rayman, edit it, add/remove things, put the sudo and superuser packages etc...
If your device isn't already rooted, you can't flash it back
Click to expand...
Click to collapse
as i told you, this can work if we do it correctly, (as i need to extract blob.app "wich has almost all stuffs in it, as its 512 mb, but i cant open it l0l)

The blob.APP is a ext4 file system. You can view it with
Code:
mount -o loop blob.APP system/
This assumes you have an empty directory named system and you are on a linux machine. Just to be safe, you could also use loop,ro to mount it read-only.
That's all fun stuff in there, but the real magic happens in blob.LNX and blob.SOS. You can extract them with the boot tools (not blob) that rayman has also posted in his github. Modding these files will allow you to keep root. rebound posted a thread in the dev section about an insecure boot- good stuff. Keep in mind that this still doesn't get you past nvflash or the stock recovery.

gee one said:
The blob.APP is a ext4 file system. You can view it with
Code:
mount -o loop blob.APP system/
This assumes you have an empty directory named system and you are on a linux machine. Just to be safe, you could also use loop,ro to mount it read-only.
That's all fun stuff in there, but the real magic happens in blob.LNX and blob.SOS. You can extract them with the boot tools (not blob) that rayman has also posted in his github. Modding these files will allow you to keep root. rebound posted a thread in the dev section about an insecure boot- good stuff. Keep in mind that this still doesn't get you past nvflash or the stock recovery.
Click to expand...
Click to collapse
ah, thanks a heap! but after recompile, how to "update the firmware"

Well, if you are rooted, you can flash the blob via the staging partition. If you are not rooted, the staging partition is read only. Aye, there's the rub!
I'm not saying it's not possible, but you'd have to know some clever tricks. Have a look at the gingerbreak exploit and how it was used to flash a blob.
sent from my cyanogen(mod) vision

exciting...waiting for good news from you.
hope its will successfully Root on B80, and a complete method to do it.
thanks~

would be nice have a B70 and its locked

evangelism said:
exciting...waiting for good news from you.
hope its will successfully Root on B80, and a complete method to do it.
thanks~
Click to expand...
Click to collapse
it will root, (but recovery will be same, if i dont change it, as its inside some of the blob files,
so its possible, but hard ) and a damn lot of workaround,

Arctiik said:
would be nice have a B70 and its locked
Click to expand...
Click to collapse
this is the latest WW, so it would also be working on B70 aswell

the recovery is blob.SOS - use bootunpack blob.SOS
There's a little android! magic in there too. The kernel is the same, but you can mod the ramdisk. Download roaches version of CWM and unzip, blobunpack, and bootunpack. Then use his ramdisk and pack it all back together into the blob.
Then you will have rooted firmware. Now get to work on getting it to flash! We need an exploit like gingerbreak to make it work.

gee one said:
the recovery is blob.SOS - use bootunpack blob.SOS
There's a little android! magic in there too. The kernel is the same, but you can mod the ramdisk. Download roaches version of CWM and unzip, blobunpack, and bootunpack. Then use his ramdisk and pack it all back together into the blob.
Then you will have rooted firmware. Now get to work on getting it to flash! We need an exploit like gingerbreak to make it work.
Click to expand...
Click to collapse
took the recovery-ramdisk -> renamed so it replaces old file, now to pack this +__+
folder looks like this "see pic"

this was already discussed here in the forum. The only thing new would be a way to flash unsigned updates, and in this mater there are no news (yet...)

brk said:
this as already been discussed here. The only thing new would be a way to flash unsigned updates, and in this mater there are no news (yet...)
Click to expand...
Click to collapse
this is what we are trying to do here
added blob.SOS and LNX in this zip file (help with make it to blob.SOS
http://www.multiupload.com/BKCX9Y7CB8
totaly lost on how to pack blob files,

Try typing "blobpack" or "blobpack --help" one of them will show you the syntax.
sent from my cyanogen(mod) vision

gee one said:
Try typing "blobpack" or "blobpack --help" one of them will show you the syntax.
sent from my cyanogen(mod) vision
Click to expand...
Click to collapse
Usage: blobpack <headerfile> <outfile> <partitionname> <partitionfile> ...
i don't know what is header, and partition file of this +__?

Follow the capital letters- blob.HEADER is the header file. blob.SOS is the SOS partition ,etc.
Experiment a little, you won't break your ubuntu box if you pack up the wrong blob. You can unpack it to see if it worked. There are also instructions on raymans blob where you got the link for the tools.
The header has to be correct, so essentially you have to pack up the same number of parts if you re-use the header. Unpack a few blobs and see what is different with them. They don't always have the parts. Some have EBTs, some have SOSs, some have peaches and candy.
sent from my cyanogen(mod) vision

did you already check the universal root script for linux? There you can find the tools to mod blob.SOS (RAM disk for CWM) and blob.LNX (insecure flag change).
But this is the easy part. To be able to flash a modded update file you need to know the encryptation key from ASUS, or find a bug in android that you can exploit to flash the modded update.

brk said:
did you already check the universal root script for linux? There you can find the tools to mod blob.SOS (RAM disk for CWM) and blob.LNX (insecure flag change).
But this is the easy part. To be able to flash a modded update file you need to know the encryptation key from ASUS, or find a bug in android that you can exploit to flash the modded update.
Click to expand...
Click to collapse
only need to repack all, and thats the stuff i dont know lmao

[Q] Help with Blob tools?

I'm confused on how to extract blob files using blob tools. I am running Windows XP and 7 and this is my first port
If anyone could guide me through the steps with appropriate commands in command prompt, that would be great.

Blob tools is nice and simple to use
To extract a blob:
1. Download the ROM.zip or other multiple partition blob file and extract the file called 'blob' (Or 'recoveryblob' or whatever..) out of it.
2. Place the 'blob' in the same folder as 'blobunpack.exe' (You can rename it if you have multiple blobs and need to distinguish them)
3. Open up cmd.
4.
Code:
cd C:\directory\of\blob
blobunpack blob (Or the name of the blob, no extension required)
[I]Let it do it's thing for a moment...[/I]
exit
5. You will now have many blobs with different file extensions, each of these file extensions is a different partition of the TF.
EBT is the bootloader
SOS is the recovery
APP is the os, and etc...
Good luck.

I can't speak for Windows, but in linux, it's pretty easy. The commands would be
blobunpack <insert blob here>
you'll get some or a bunch of files like blob.APP, blob.LNX, blob.SOS, blob.EBT. It depends on what is packed in the blob. A proper blob will start with MSM RADIO UPDATE or something like that. If not, it's not a packed blob, but probably just blob parts.
EBT is the bootloader.
APP is an ext4 filesystem that you can loop mount in linux. Don't ask about windows.
SOS and LNX are boot images/Android! magic files that you can unpack wiht the boot tools (bootunpack). Rebound has a thread in the dev section about making an insecure boot image- it sounds unrelated, but it has all the information about boot.img's.
As far as getting the tools, I think there might be some windows binaries floating around, but again, I can't speak from experience. If you have linux, you can just compile them from source and go to town. Grab the boot tools while you are at it and save yourself some time.

[Q] Need some help with grabbing system.img

Hello !
I'm trying to set up a dual boot with Ubuntu and Android on my TF101.
I'm using Frank's Tool to do so.
I know i must have the boot.img the recovery.img and the system.img files, and that is the problem : i can't manage to dump my current ROM in img format. I tried with several Recoveries, but i just can't...
All i have in the best scenario is the following :
boot.img
recovery.img
system.ext4.dup
or :
boot.img
recovery.img
system.ext4.tar.a (400+ mb) and system.ext4.tar (0 kb)
Is there any way to grab the system.img from my current ROM, of am i forced to use the one provided in OLiFE Prime (which is fully stock... :crying: )
Many thanks in advance.

What file formats are the .img files? Linux doesn't care about the extension at the end like windows does. You could name the file dog_food.blah and linux is just as happy.
If you just need dumps of the partition, then the dd command will work for system. These will probably be ext4 filesystems.
What are the file types of the olife files that you want to change? From the linux command line, you can just type "file <some system.img here>" and it will tell you. I'm guessing it will say ext4 filesystem. Those tar files you have can probably be converted to what you need.
Disclaimer, I haven't dual booted my tablet and I don't know a thing about Frank's tools.
EDIT: I spent 30 seconds looking at Frank's tools, which appear to be an nvflash interface for windows. I suppose this means you want everything in an nvflash-able format. boot.img and recovery.img will be ANDROID! packed files, while system.img will be an ext4 filesystem.
To be sure, boot.img and recovery.img will start with ANDROID! There are also some boot tools by Rayman and other sources if you want to manipulate these. I think you can grab the system with "dd if=/dev/block/mmcblk0p1 of=/Removable/MicroSD/system.img" It will take a while and will be a large file, maybe 500MB. Depending on where your sdcard is, you might have to change that bit around.
If any of this doesn't make sense, then feel free to google or ask. Good luck!

[TOOL] Boot.img tools [unpack, repack, ramdisk]

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.

[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