Hey guys
Here are the tools used for the new root by Bumble-Bee & me!
https://github.com/AndroidRoot/BlobTools
The tools can unpack and repack blobs. Since the blob header is still not fully understood, repacking requires the original header from an existing blob file!
It is able to pack any number of partitions in a single blob (given it fits in the staging partition of course..around 500MB is the limit). The tool should be selfexplanatory from the output it gives if run without parameters, but I'll be happy to elaborate if needed.
Enjoy!
-RaYmAn
I'm trying to use this tool, but i need instruction
Fab985 said:
I'm trying to use this tool, but i need instruction
Click to expand...
Click to collapse
heh. Fair enough
First compile the tool (obviously)
[TO UNPACK]
Code:
./blobunpack /path/to/blob
This creates a number of files, in particular a blobname.HEADER file which contains the header of the blob (As mentioned in previous post). The remaining files are named the same as the partitions on the device, e.g. blob.LNX (boot.img) or blob.SOS (Recovery) or even blob.APP (system.img)
[TO PACK]
You need the blobname.HEADER file from the unpack step at this point.
If you want to make a blob with e.g. just boot.img you do the following:
Code:
./blobpack blobname.HEADER outputfile LNX boot.img
The above commands places the boot.img in the LNX partition using the previously extracted HEADER and creates a blob in "outputfile" ready to flash =P
If you wanted to create a blob with boot.img and recovery, you'd do
Code:
./blobpack blobname.HEADER outputfile LNX boot.img SOS recovery.img
I hope this helps
Thanks!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Nice work, thank you for the instructions
i've successfully unpacked the rom now
It kinda just makes unexplained files, can we have any sort of tutorial as to how we might go about extracting them?
kevcube said:
It kinda just makes unexplained files, can we have any sort of tutorial as to how we might go about extracting them?
Click to expand...
Click to collapse
I guess you suck at reading more than 1 post.
kevcube said:
It kinda just makes unexplained files, can we have any sort of tutorial as to how we might go about extracting them?
Click to expand...
Click to collapse
blob.HEADER - Header stuff (ignore it)
blob.APP - system.img
blob.LNX - boot.img
blob.SOS - recovery.img (e.g. regular boot.img)
blob.EBT - bootloader.bin (ignore)
The system.img is ext4 and can be mounted as a loop fs in linux.
The rest of the files..well..If you don't know how to extract them, you have no use of these blob tools (*hint* http://github.com/AndroidRoot/BootTools)
Well that was kinda embarassing. I didn't feel like booting into ubuntu so I compiled and ran those tools in cygwin, and I didn't read the entirety of your explanation post.
To think I'm one of those people who gets really angry when I see others make that mistake..
Edit - just so you know I wasn't asking what to do with the source code, or how to get a blob. I just needed to know that whole ext4 image thing, and how it related to the blob.APP stuff.
Great thanks for the utility! I've just moved from TW SKU to US flashing LNX and APP from clockworkmod/adb.
So it seems the header (at least by terms of mdsum, not hex) changed for the 3.1 update.. Also 'unblobs' and has a blob.PT file, as in.. partition table..
LNX, EBT, SOS, APP, GP1, USP, MSC, CAC, PER, YTU, UDA, GPT, PT, BAK,
they also have some HSPA+ additions for their 3G/GSM model
Blades said:
So it seems the header (at least by terms of mdsum, not hex) changed for the 3.1 update.. Also 'unblobs' and has a blob.PT file, as in.. partition table..
LNX, EBT, SOS, APP, GP1, USP, MSC, CAC, PER, YTU, UDA, GPT, PT, BAK,
they also have some HSPA+ additions for their 3G/GSM model
Click to expand...
Click to collapse
So when you say the header has changed, you simply mean it's md5sum has changed? That's expected as the header is not neccessarily static. As long as the *format* of the header is the same, everything is good =P
The previous (full) updates also had a blob.PT containing all those partitions. Most of them are generated/maintained automatically by the bootloader however...
Thank you rayman84 your tools are as useful as their code is beautiful
Looks like an update is needed for the tf201 'blob'.
How do you get the boot.img and other .img files out of blob ?
use the unpack blob script as described on the first page.
SoCmodder said:
use the unpack blob script as described on the first page.
Click to expand...
Click to collapse
I get the LNX files, how do I get it out of them ?
StDevious said:
I get the LNX files, how do I get it out of them ?
Click to expand...
Click to collapse
the blob.LNX file is your boot.img. You can just rename it if that will make you feel better.
If you need to extract its contents, look for bootunpack.
daoist said:
the blob.LNX file is your boot.img. You can just rename it if that will make you feel better.
If you need to extract its contents, look for bootunpack.
Click to expand...
Click to collapse
I see, Thank you. I also have an .EBT file, what's that supposed to be ?
StDevious said:
I see, Thank you. I also have an .EBT file, what's that supposed to be ?
Click to expand...
Click to collapse
The .EBT file is a bootloader file. You can ignore that. You shouldn't need to do anything with it.
daoist said:
the blob.LNX file is your boot.img. You can just rename it if that will make you feel better.
If you need to extract its contents, look for bootunpack.
Click to expand...
Click to collapse
If using Linux, you can search for "unyaffs" it seems to work great for me.
Or just clone the git for BootUnpack. It works as well.
Dear All,
I have been building some custom Android ROMS for the past few years, and my latest toy is a Flytouch 3 I wanted to share some of my findings and methods here, perhaps other newbies like me will find it useful.
1. FT3 ROM contents:
FT3 ROMs will be in RAR or ZIP format and have 2 or 3 files in them as explained below. Just unzip or unrar the package to use them:
firmware2 - flash tool which burns the firmware ( I guess...lol)
bootloader-discovery - 7zip file which contains the bootloader
IMPORTANT! Do not flash a wrong bootloader to your device or it will be bricked! Actually this is the only way you can brick the thing, it's pretty sturdy in that sense. If you are not sure, do not copy bootloader-recovery to your sdcard when flashing, it will boot with your existing bootloader anyway.
firmware-discovery - 7zip file which contains the firmware and it's the main file you want to edit.
2. firmware-discovery contents:
This is the easy part! Modifying this file will let you modify system and data partitions. You can also use different ramdisks and kernels compatible with your device. It's a 7zip file and you can unpack and repack easily with the 7-zip file manager (http://www.7-zip.org/).
I use 7-zip on Windows although I use Ubuntu Linux as my main OS. There is something wrong with my 7-zip installation most probably, but I was too lazy to check it If you are on Windows anyway, you are good, just download and use 7-zip from the URL above. I advise that you do all your firmware-discovery editing within 7-zip file manager. That way, you won't have to worry about re-packing with the correct 7-zip settings. At least, that's how I do it and had no problems.
firmware-discovery will have these files in the 7zip package:
uImage - kernel
Very important Your kernel will make the difference between having and not having certain functionality, even if your hardware supports it.
uImage_recovery - recovery file - I beleive this is what runs when you push menu+power.
ramdisk.img - ramdisk
This is one of the interesting files you might want to play with. Ramdisk is a simple file system with some crucial files, mainly init.rc that lets you control the boot process. You can also stick a initlogo.rle image here to display a splash image in initial boot. More details below at title 4.
data.tar - /data partition - tar archive
All user data is stored here, including apps and user definable settings. This is what gets wiped when you do a recovery by pushing menu+power.
system.tar - /system partition - tar archive
System data, drivers and apps, including Android OS itself (except kernel). Certainly the most interesting part for the average modder
3. Editing system.tar and data.tar:
This might be the bulk of your modding, and most probably what will be most visible to the end user.
I very strongly suggest that you use a Linux system to edit these files. If you use Windows, file permissions will not be saved! If Windows is your main OS, simply install a VM host such as VirtualBox and install your fav Linux distro inside it. Most of them will have an Archive Manager with a GUI and will certainly support TAR. Even without a GUI, you can use "tar" and "untar" commands from a terminal to unpack and repack these files. When you are on Linux, TAR files will preserve file ownership and file permissions. This can be very crucial in your modding.
For modders who are new to Linux, I can recommend Ubuntu. It's very user friendly and easy to use in my opinion.
When you are done editing system.tar and data.tar copy them to your Windows box and drop and them to firmware-recovery file within 7-zip file manager.
4. Unpack, Edit and Repack ramdisk.img:
Now we are on to more serious stuff ramdisk.img consists of a 64 byte U-Boot header, followed by a gzip compressed ramdisk cpio image. So we need to strip the first 64 bytes, and use gunzip to extract it to a folder. After making the changes in the folder, we need apply cpio+gzip compression to the folder and add the 64 byte u-boot header again. You will need to use Linux and install the mkimage tool for these operations.
Here's the command to install mkimage tool in Ubuntu:
Code:
sudo apt-get install uboot-mkimage
It sounds complicated, but no worries, I have some shell scripts that can do all that for you! Thanks to leeh33 from Techknow for the scripts below:
unpack_ramdisk.sh
Code:
mkdir ramdisk
cd ramdisk
dd if=../ramdisk.img bs=64 skip=1 of=ramdisk.gz
gzip -dc ramdisk.gz | cpio -idmv
rm ramdisk.gz
repack_ramdisk.sh
Code:
cd ramdisk
find . | cpio -o -H newc -C 512 | gzip -n > ../ramdisk.cpio.gz
cd ..
mkimage -A ARM -O Linux -T ramdisk -C none -a 0x41000000 -e 0x41000000 -n hRamdisk -d ramdisk.cpio.gz ramdisk.img
rm ramdisk.cpio.gz
Create the scripts above using a text editor or download the attachment to this post and put the scripts together with your ramdisk.img file in a new folder. Executing unpack_ramdisk.sh will create a folder named ramdisk and extract the ramdisk contents here. You can edit e.g. init.rc in this folder, or add a static bootlogo. To add a custom bootlogo create a initlogo.rle image file by following this guide: http://www.androidtablets.net/forum/android-tablet-hacking/438-how-setup-static-bootlogo-before-animated-boot-animation.html Then place the resulting initlogo.rle file directly in the ramdisk directory.
After you are done editing the ramdisk folder, simply run repack_ramdisk.sh and your new ramdisk.img will be created, replacing the old one. Copy the ramdisk.img file to your Windows box again and drop it to firmware-recovery file within 7-zip file manager.
That's it, you have a custom ROM now! Please feel free to ask questions or correct me if you think I have any errors in the info above.
Happy Modding!!!
Tolga
Big problem about my device...
Thank you for this useful post!
I have seen a good knowledge about these devices(flytouch 3) and decided to post my question here:
I have a big problem! I used IUW Burning tool to flash my device. my device is:
SuperPad III (As box says)
Model: ANDR P1001
I decided to try tim's custom rom. It doesn't work. After restarting the device, screen become black (There was no connection
with screen, it was not turned on). The device had vibration when I pressed power button. It continued vibrating periodically(like it was restarting).
After that I flashed my device using IUW with most likely firmware, but during the process I FORGOT TO CHOOSE userdata.img FILE!
Now the device can't even communicate with pc.
OTG method is not working. The device no more vibrates at start up! At motherboard led is lighting when pressing power button.So IS MY DEVICE DEAD? Or is there any solution in this situation(Alternative communication, or whatever...)
I have bricked my kyobo ereader (gingerbread 2.3.5) but still have fastboot and limited adb (no shell commands since there is no valid system) access on the device.
I have various update.zips for the device but unfortunately these are installable only on a working system (via settings->privacy->updates) and I know of no way of installing the update.zip since there does not appear to be any custom recovery for this ebook reader and booting into recovery does not install the update.zip on the sdcard.
The update.zip for the Kyobo ereader contains boot.img, recovery.img and a system folder containing files and directories for the system partition (an example of an official update.zip is available from m.kyobobook.co.kr/mirasol/update.zip )
I have extracted the system folder on a ubuntu system and need to prepare a system.img file which may be flashed using fastboot. I have also changed owner of the extracted files to root:root and chmod 777 on all the executables in the extracted system folders. A complication is that I only have the windows qualcomm hsusb drivers for fastboot or adb to connect to a pc, so I must use a windows 7 notebook to flash the device (possibly precluding pushing the system folder files to the device since they don't have permission and owner settings in windows)
I have tried various tools to make a system.img including the native linux mkcramfs and tools suggested by various google searches such as mkfs.yaffs2.x86 and make_ext4fs. All these tools could prepare a system.img but unfortunately they have different sizes and I am not sure which img is the correct one. I have tried to flash the various system.img using both fastboot flash system system.img and also by adding the system.img to the update.zip (together with placeholders for the required android-info.txt but in all cases they do not any files onto the sytem partition (although fastboot does send the system.img successfully to the device and writes the 120~180MB img files in about 50-70seconds. I have tried using both the official boot.img and the rooted boot.img. I noticed that the device reboots twice after such flashing which may be because there is some protection from the official recovery.img which checks the system partition an erases it if it does not match.
My first 2 questions are general and the third is specific to my situation:
1. What is the correct tool to generate an android system.img file from the extracted update.zip's system folder on a linux system?
2. Any suggestions on how to flash an update.zip using fastboot or adb?
3. Are there any generic recovery.img which I could try to flash over the official recovery partition on the kyobo mirasol ereader?
Any suggestions anyone?
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!
HOW, in detail, step by step, can I take stock firmware in the Samsung 4 file format tar.md5, and somehow, with minimal extra steps, create a flashable zip file with it?
If you're on a Windows computer, use 7Zip tool to untar & zip an archive
More info here:
https://allthings.how/how-to-use-7-zip-in-windows-11/
BTW:
You can untar a .TAR via Windows command prompt, too:
Code:
tar -xf <TAR-FILE>
jwoegerbauer said:
If you're on a Windows computer, use 7Zip tool to untar & zip an archive
More info here:
https://allthings.how/how-to-use-7-zip-in-windows-11/
BTW:
You can untar a .TAR via Windows command prompt, too:
Code:
tar -xf <TAR-FILE>
Click to expand...
Click to collapse
So it is that easy? No special hand coded files to direct things or anything like that? So when people say a "flashable zip", it's no different internally than the tarballs are? Just decompress one and compress into the other? I had a suspicion it might be that way, but everyone has been so cryptic with other users, and just refusing to answer, I thought it must be more complicated than that. Thank you very much for the straight answer, I am very grateful.
So i state this as overtly as possible for posterity: nothing signifies a flashable zip as different than an ordinary zip other than the contents, which are identical to the contents of a tar archive. Easy.