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.
Here is the theory I want.
Given a mobile phone that has a lock on it wether pin code, pattern or password, If the mobile's bootloader was unlocked I can install a custom recovery and then boot to that recovery in which I can run the adb and have access to the data in the phone. If my hypothesis is correct then how I can build a recovery.img ??
I have been reading for the recover.img for 2 weeks and almost understood how it works and most of the files in it. However, I couldn't find a tutorial of how can I build my own recovery.img
What I decided to do it to modify on the CWM recovery.img.
So I downloaded the CWM and then I unpack it to see the kernel and the initrd. After decompressing the initrd, I found many files. I made a simple test which is to run a script from the init.rc. Inside the init.rc I added two lines. The first one to mount the /data partition and then I just echoed "test" to a file called text.txt then I rebooted my device to normal boot connected to adb and checked the /data partition, but unfortunately I didn't find anything.
I would like to know what I am missing and if my theory is correct or not and how can I build my OWN recovery and have something like adb running from the start.
Thank you
From now on, Android rom can be easy to pack. You don't need to worry about the permissions of the files or the symlinks anymore.
What does this package do:
1. Automatically find and recognize the img with patterned name in the same folder of this package.
2. Automatically wipe and flash the system partition when system.img is found.
3. Automatically flash the addon pack without wiping the system partition when addon.*.img is found.
4. Automatically backup efs and efs_gsm partition, on Samsung Duo sim card phones.
5. Be able to flash the unmountable partitions like boot, recovery, modem, etc.
How to pack:
1. Make you rom on on the Phone or Linux. On the Phone? Yes, you can test your patches on your phone.
2. No matter on the Phone or on Linux, cd /system/ or cd <your system folder>, check the permissions and symlinks. Usually I don't check cause I modify directly on a system I dumped from my phone. Yes a dump of system partition is a good idea.
3. You have two optitions: 1. Use the modified dumped system partition dump as system.img. This usually generate a big img to flash, but will flash faster. 2. If you use extracted folder or want to use small files, cd to the system folder in shell and make the folder to a tarball with the command: 'tar --lzma -cf <your tar file> * .[!.]*'. Why use * .[!.]*? This will put the .* files and folders in the tarball.
4. Then rename the dumped image or the tarball to system.img and put it in the same folder of the FLASHER.
5. Want to make an addon? Just make the name like addon.<your name>.img. Don't for get the permissions and ownership of the files and folders.
Future plan:
1. Make a packer/dumper for the system partition.
Github:
https://github.com/maxfu/universal_android_flasher
I will edit this post and post some pictures later.
FIRST OFF - THIS IS HIGHLY TECHINICAL AND NOT FOR NON-TECH INCLINED PEOPLE. YOU CAN REALLY MESS UP YOUR PHONE IF YOU DO IT WRONG. SO PAY ATTENTION OR FIND SOMEONE SMARTER THAN YOU WITH THIS ANDROID / LINUX STUFF. YOU DO THIS ON YOUR OWN - NO WARRANTIES EXPRESSED OR IMPLIED. IT'S FOR PEOPLE THAT DON'T WANT TO WAIT FOR THEIR VENDOR TO POST A FULL ROM AND UPDATE RIGHT WHEN AN OTA COMES.
So I wanted to update my rooted Op8T OOS version, and you CAN'T (haha) do it if you're rooted. That's kind of a misconception. I knew there had to be a way... so I found a dead repo out there that used to work on Incremental OTAs. And I read the issues - did not actually work. Why? Because you need to extract the prior firmware (full ROM) first with a Payload extraction tool (most are in Python, and most are Linux-only). Well, they got stuck because the original ROM has one signature (encryption), and the OTA update has another signature, so the program would break when they didn't match. So what did I do??? Well I have to give credit to the dev I forked this from, because he mentioned - of course the signatures don't match, they are different releases! So I did something kind of... well... let's put it this way, you aren't verifying any signatures anymore. So if you screw up and put the wrong ROM base (prior full ROM) and Payload extract the payload.bin, then apply the Incremental OTA, well, you're in for trouble. BE POSITIVE YOU ARE USING THE VERSION OF THE ROM THE OTA IS INTENTED TO INCREMENTALLY UPDATE!!!!
In this case, it was quite clear. I was trying to update an A11 Op8T from OnePlus. It was on 11.0.8.3 ROM and an OTA was posted that was for 11.0.9.9. SO I used a Windows tool to extract the first set of files (the full ROM is huge BTW). The incremental update came as a 150mb file zipped up, but it modified the BIG files. Once it finished, I found that system and system_ext are not flashable (grew in size, can't resize super on active slot, not updated), the rest are. And you MUST flash from fastbootd - this is kind of a mysterious new place with modern AB devices. It can be a pain to actually get there. The standard steps if you're on stock recovery are to enable developer options, USB debugging, install the Latest ADB and Fastboot https://github.com/fawazahmed0/Latest-adb-fastboot-installer-for-windows/releases/tag/v1.7 (this script will update it for you). Ignore the God references it's a batch file you can just modify it, and I don't judge. It will pull the latest versions (Minimal ADB and Fastboot are super outdated). Next steps...
Now, getting an incremental update off a rooted phone is not easy. 1) you have to flash a stock boot.img and recovery.img. 2) you have to basically uninstall Magisk, or at least the images 3) then you MAY be able to download with Oxygen Updater or the system app. It won't install though because root is fully exposed. Once it's downloaded, it appears in some very strange location with a random character string.zip I believe. So now you have to reinstall Magisk (to get adb shell SU access). So after I confirmed it downloaded (but wouldn't flash), I had to hook my phone up to the USB cable, go to the PC and Latest ADB and Fastboot folder, adb shell, su, then cd /; find . -name *.zip > /dev/null 2>&1; to cut out some of the garbage output and scroll until I found a logical zip stored somewhere (a folder than sounded like a OnePlus update folder). Then I did a: cp [random characters.zip] /sdcard/Download/OTA_Update.zip, which I could then transfer from my phone to PC with a USB cable. Developer options / default mode USB File Transfer FYI.
Okay that was one of the hard parts. Now next to more hard parts. You need a Linux environment (I used WSL2 Debian Buster). The easiest setup (after spending hours attempting to get the correct packages loaded) was to install the personal version of Anaconda Python x64 for AMD64 processors for Linux. Then I could use conda install [package name] for missing dependencies as the program would throw errors. Yes you have to read the errors or you won't be able to figure out what is actually not installed. Anyhow, the modded forked repo of python files is here: git clone the repo: git clone https://github.com/mrslezak/update_payload_extractor.git - now if git isn't setup on your Linux box, well, you're in for some trouble.
So once it's installed, you need to actually use python3 commands for each step - so anywhere you see "python" put "python3" instead as most machines have both 2.7 and 3.X installed. I used Python 3.8 something, so ignore the 3.6 it's not required. So here I took a payload.bin extracted with a Windows.exe file (available somewhere on XDA, there are severel, one is Go based) and copied them once extracted from the original ROM to the WSL instance on my Win10 PC. Now there come issues here. They need to go into an "old" directory you must create (in update_payload_extractor directory), and copying from Windows will make them root access only, so a: sudo chown user:user old/ is required to get it writable. I believe the program will make the rest of the files on its own. They will end up in "output." You just need to extract the payload.bin and payload.properties files from the incremental update you extracted and place them in the update_payload_extractor directory.
Now there is some strange stuff going on, this was always beta, and never working. So I took the note of the issues and blocked a Google certificate validation routine (just commented it out) so it doesn't verify anything. I say it again BE EXTREMELY CAREFUL THAT YOUR PRIOR FULL ROM AND OTA UPDATE ARE MEANT TO BE USED TOGETHER. Anyhow, run what it says if your system is setup:
Incremental OTA
Copy original images (from full OTA or dumped from devices) to old folder (with part name without file extension, ex: boot, system) - I put an .sh script here if your files are .img called remove_img_extension_old.sh - note that GitHub sometimes loses the execute permission so you may have to type: sudo chmod +x remove_img_extension_old.sh. It is meant to be run from the root of the project. ./remove_img_extension_old.sh
LD_LIBRARY_PATH=./lib64/ ./extract.py --output_dir output/ --old_dir old/ payload.bin
The above line will start the extract and combine process the OTA usually does on your phone, and output the files to the output directory. Once those are generated, then you can run another helper script I wrote to add back .img to each file called add_img_extension_output.sh again meant to be run from the root folder. Now you need to copy these output files (no guarantee all are updated, it will have all of them - on Op8T system and system_ext couldn't be flashed because they grew in size, and I don't know how to expand the super partition space to enable them to flash, so they aren't in the linked file - it still updates). The files on Op8T ending in lp5 are RAM files for the newest devices that are running LPDDR5 memory, the flash.bat script will need to be modified if you have one of these (2 flashes). The way I made the file will work in 98% of devices.
Okay I run the rest from Windows, so now it gets a little tricky. You need to get into Fastbootd, which means flash boot.img (you just extracted it), flash recovery image (same), using fastboot flash boot boot.img, fastboot flash recovery recovery.img. Now getting to fastbootd can be quite perplexing. You may just have your phone on, type adb reboot bootloader, then type fastboot reboot fastboot, and be in fastbootd (it will look like stock recovery but say fastbootd on top). The other way is to boot to recovery (developer options extended boot menu makes this much easier), then select Fastboot. Sometimes you get Fastboot and sometimes Fastbootd. It seems quite random. DON'T START THE FLASH_ALL.BAT UNTIL YOU KNOW YOU ARE IN FASTBOOTD!!!!
The fastboot command to tell you if you are in fastbootd (it will report yes if so: fastboot getvar is-userspace
Otherwise, those files will NOT be allowed to flash to your device, and you will end up with some random combination of prior and updated files. That could end badly. Once you DO get to Fastbootd, run the flash_all.bat, and DON'T SWITCH SLOTS. Yes, this is an OTA, but you already patched the files. Upon successful flashing, you can reboot to fastboot and flash a patched kernel with Magisk already enabled such as my forked Radioactive here: https://github.com/mrslezak/Radioactive_kernel_oneplus8/releases/tag/v2.2.5-MOD - the .img file is a Magisk patched custom kernel, you can also flash the twrp alpha (that seems to work in my experience, it's just slow, on OOS works fine despite warnings it doesn't). https://forum.xda-developers.com/t/recovery-11-alpha-teamwin-recovery-project-8t-kebab.4302449/ fastboot commands for the kernel: fastboot flash boot image_name.img; recovery fastboot flash recovery twrp_name.img.
I successfully updated while rooted from the prior ROM version. I'm sure it will work on many phones. Best of luck to you!!! I did find out how to install "the full ROM" unreleased on a rooted phone, there is some undocument fastboot stuff I had to figure out (temp system-cow and system_ext-cow files that use up all the space in the super partition) so I added them to my batch file. Now install for whatever device you have, and watch out for those weird temp files that aren't documented anywhere that I could find. Took literally hours to get it working, but it does now!!!
BTW if anyone knows how to resize the super partition, that would complete this project. I.e. you could flash the patched system and system_ext on an Op8T.
Your phone may have no issue or no super partition, then you don't care, it's not needed. I can't recall when dynamic (resizable) partitions came out but I think in Android 10 some devices started to use them. They are developer hell in my opinion.
Some TWRP versions allow you to just resize the partition on the fly, while on my phone, it's not an added feature yet. I'm also not sure if the resize does an auto-wipe either then you could also find yourself in trouble if you couldn't immediately get to Fastbootd. Some ROMs will boot to "Device is corrupt" if things like this change, just a warning, which I tried by switching A/B slots, but I had luckily installed TWRP on the other partition and was able to switch slots there and go back to booting.
UPDATE: I was able to eventually locate why the Super partition was getting full - there are temp files created as dynamic partitions when trying to install an OTA - I had to delete any logical partitions with the extension "-cow" which existed for system and system_ext (on the Op8T I was using), I was on slot A, so they were called system_a-cow and system_ext-cow, I deleted them like this:
fastboot delete-logical-partition system_a-cow
fastboot delete-logical-partition system_ext_a-cow
To see if you have any temp files present, you type:
fastboot getvar-all
And scroll through them and see if any of these mystery -cow files are present.
(bootloader) is-logical:system_a-cow:yes
(bootloader) is-logical:system_ext_a-cow:yes
Whew! That was a pain. But no more waiting for incremental updates to become full ROMs anymore on a rooted phone!
Oh, and I put the update for OOS here: https://forum.xda-developers.com/t/...install-from-fastbootd.4316147/#post-85441161
Dear Experts
Or, at least those more experienced that me,
I've been looking into flashing the ROM of
an Android phone to Lineage OS.
The scant documents that I've looked at
Install LineageOS on lake | LineageOS Wiki
wiki.lineageos.org
Say to first load the .img file,
fastboot flash boot <recovery_filename>.img
Then later:
adb sideload Lineage.zip
What is the difference between the
.img file, and the .zip file?
Is the .img file a prereq for the .zip?
...
Why run both files?
Instead of the 2 stage process,
why not just flash the .zip file?
Thanks
The .IMG file extension is used for disk dumps, whereas .ZIP file extension is used for any content what got compressed.
Fastboot requires disk dumps ( .IMG ), whereas ADB requires archives ( .ZIP ) passed in.
@xXx yYy
More explanations, great.
So, can you go directly to ADB, and
sideload the .zip?
Or, is it always a two (or more) stage process,
fastboot .img file, then
adb sideload .zip?
Thanks