Hello guys. I have a simple question. I am trying to modify ROM for xiaomi a2. I have official .iso images. For test i trying to remove "grep" binary file. I mount system.img, change it, unmount, pack and flash using fastboot. But the file is still is visble using adb.
When i try TWRP file manager, the file is absent. How is it possible?
Then i try to change one file directly in .iso using hex editor, but the changes is not visible. But when i install magisk, all changes became visible. Can android store copy of system.img somewhere else?
Not sure what you have done or what you mean with "official .iso images" but consider three possibilities:
Magisk is systemless-root method, it provides overlay for modifying /system content without modifying system partition
A/B devices have two slots, system_a and system_b partition
dm-verity provides FEC feature to correct modifications on file system
Related
Usually, for modifying boot images, I unpack boot images (either extracted from rooted phone, or from full system image) using Android Image Kitchen, make my changes in the ramdisk directory, repack and flash (using fastboot flash boot <image_new.img>).
However, this doesn't work for Pixel or Pixel XL. I could simply create a new file in the ramdisk directory, but it doesn't reflect in the phone's root directory. I suspect this has something to do with the partitioning changes for this device, although I haven't been able to find a good complete write up about what are the exact changes. I have noticed a few new partitions (like hosd.img, bootlocker.img, hyp.img, keymaster.img, etc) but I am not entirely sure what they are for.
Any ideas how I can make some simple changes to the boot image? I want to make changes to the rc files and add a few shell scripts (for some init.rc services), and make some changes to default.prop.
Edit: I have read a bit more online, and I figured out that the boot image's ramdisk is only used in recovery, and initramfs of the system image is used as the init and the root during the normal phone boot up. So I will be able to do what I want by modifying the system image? I tried going through Chainfire's boot image too, and I am not exactly sure how he manages to modify the content of the system using the boot image.
Hi, I'm a Galaxy S7 user and I've been trying to make sparse system.img from firmware tar file into a twrp-flashable zip file but I'm not sure which is the best way.
All operations are performed on latest linux mint and I'm not going to use any kitchen. All binaries used to convert images are compiled from latest AOSP sources.
Here are some of the methods I've tried.
a) Extract everything from system.img and set metadata infos in updater-script, just like any other "rom"s. (e.g. SuperMan Rom)
Probably one of the simplest ways, and system files inside the zip can be modified easily - extract, edit, recompress.
But this method has a potential of destroying unique permissions/owner infos, such as those of symlinks.
I'd like to flash the system.img "as-is," without making a mess with whatever's inside the image.
b) Extract raw system.img directly to /dev/block/platform/155a0000.ufs/by-name/SYSTEM.
Not so bad. Raw system.img can be easily generated with simg2img. But turns out to take too much time to flash and doesn't get along well with DualBoot patcher.
c) Sparse dat, like the ones used in most AOSP-based roms
Probably the most ideal one. But when I took the following steps to make it, I found out that system partition size gets kinda damaged or something.
- Convert system.img to raw system.img with simg2img.
- Convert the raw system.img to sparse image again with ext2simg, to make img2sdat.py work properly.
- Convert the sparse image to sparse dat with xpirt's img2sdat.py.
- Finally, convert the generated sparse dat to raw system image with sdat2img.py to check if partition size matches.
Then I get the following results.
- Size of original raw system.img : 4404019200
- Size of raw system.img generated in last step : about ~100MB smaller
I know I can loop mount system.img and then make a new sparse image with make_ext4fs,
but it also breaks some permissions and make_ext4fs won't recognize file_contexts.bin from nougat firmware whereas it worked well with marshmallow's.
If anyone's got a better method or a solution for method c please leave a reply. Thanks in advance.
kykint said:
Hi, I'm a Galaxy S7 user and I've been trying to make sparse system.img from firmware tar file into a twrp-flashable zip file but I'm not sure which is the best way.
All operations are performed on latest linux mint and I'm not going to use any kitchen. All binaries used to convert images are compiled from latest AOSP sources.
Here are some of the methods I've tried.
a) Extract everything from system.img and set metadata infos in updater-script, just like any other "rom"s. (e.g. SuperMan Rom)
Probably one of the simplest ways, and system files inside the zip can be modified easily - extract, edit, recompress.
But this method has a potential of destroying unique permissions/owner infos, such as those of symlinks.
I'd like to flash the system.img "as-is," without making a mess with whatever's inside the image.
b) Extract raw system.img and directly to /dev/block/platform/155a0000.ufs/by-name/SYSTEM.
Not so bad. Raw system.img can be easily generated with simg2img. But turns out to take too much time to flash and doesn't get along well with DualBoot patcher.
c) Sparse dat, like the ones used in most AOSP-based roms
Probably the most ideal one. But when I took the following steps to make it, I found out that system partition size gets kinda damaged or something.
- Convert system.img to raw system.img with simg2img.
- Convert the raw system.img to sparse image again with ext2simg, to make img2sdat.py work properly.
- Convert the sparse image to sparse dat with xpirt's img2sdat.py.
- Finally, convert the generated sparse dat to raw system image with sdat2img.py to check if partition size matches.
Then I get the following results.
- Size of original raw system.img : 4404019200
- Size of raw system.img generated in last step : about ~100MB smaller
I know I can loop mount system.img and then make a new sparse image with make_ext4fs,
but it also breaks some permissions and make_ext4fs won't recognize file_contexts.bin from nougat firmware whereas it worked well with marshmallow's.
If anyone's got a better method or a solution for method c please leave a reply. Thanks in advance.
Click to expand...
Click to collapse
What you're doing is quite complicated if you don't use kitchen. Simplify it for yourself and use kitchen.
Sent from my SM-S903VL using Tapatalk
Droidriven said:
What you're doing is quite complicated if you don't use kitchen. Simplify it for yourself and use kitchen.
Sent from my SM-S903VL using Tapatalk
Click to expand...
Click to collapse
I know that kitchens can do that for me, but they also don't flash system.img as-is.
Maybe I should just take a more look into the sparse dat method and see what breaks the partition size.
I'm trying to make a flashable zip for TWRP to install a Lenovo Z6 Pro stock ROM. I create the .zip file with Boot, System and Vendor (I'd add the rest of the firmware later). Boot and Vendor are installed but system.img is not installed. I know that I could use .dat files but I'm specially interested on using the image files.
I took as template another ROM which uses .IMG files too with the function 'package_extract_file'. I just replaced the .IMG files making sure that the names are exactly the same, and also I'm sure that my system.img is raw. When I try to install the flashable zip from recovery it prompts the uiprint "Patching system unconditionally" but nothing is installed and skips directly to patch the vendor partitions which is successfully patched.
Any help or clue will be much appreciated. Thanks in advance.
The device is a Sam Gal A11W.
I want to change one text file in the /system partition.
In order to do that, I want to start from the stock firmware I already downloaded, make the change then flash the whole modified firmware.
There are 5 .tar.md5 files (4 if we consider only one of CSC_ and HOME_CSC_) in this firmware, which can be flashed just fine in their original form.
What I want to do is to:
1 - unpack the AP_***.tar file (contains meta-data/fota.zip, boot.img.lz4, carrier.img.lz4, dtbo.img.lz4, metadata.img.lz4, recovery.img.lz4, super.img.lz4, userdata.img.lz4, vbmeta.img.lz4)
2 - unlz4 the super.img.lz4,
3 - unsparse the super.img to super.ext4.img (using simg2img)
4 - lpunpack the super.ext4.img into individual dynamic partitions (there are only 4: odm.img, product.img, system.img, vendor.img - this is NOT an A/B device !!)
5 - modify the text file on system.img
6 - lpmake the super.ext4.img back from odm.img, product.img, system.img, vendor.img
7 - re-sparse the super.ext4.img back into super.img (using img2simg)
8 - lz4 the super.img back into super.img.lz4
9 - Re-TAR the super.img.lz4 file plus all the rest of the original .img.lz4 files back into the AP_***.tar file
10 - Flash the AP_***.tar file to this mother****ing piece of Samsung crap without errors, and that is WITHOUT UNLOCKED BOOTLOADER, because the scumbags eliminated the OEM Unlock option from the Dev Options.
What I already know is:
- How to do the whole process without preserving any signatures.
This is already explained in this thread:
Editing system.img inside super.img and flashing our modifications
I'm trying to modify my system.img (/system/build.prop) to include support for multi users. After struggling a lot, I've succeeded following your guide (that's an awesome work btw) to unpack, mount, modify, umount and repack super.img. Then...
forum.xda-developers.com
but the author assumes the bootloader can be unlocked and therefore doesn't deal with any signatures / security-crypto-baloney checks.
What I (still) need to know is:
1 - How many crypto-security-baloney-whatever-signatures are there on all these files ?
2 - How can I restore them during repackaging so the flashing process does not get screwed up by the locked phone ?
If anyone here knows the answer to these 2 things ... well I guess they must be the Android Godfather Almighty !!
have you figured this out?
FugkGoocle said:
The device is a Sam Gal A11W.
I want to change one text file in the /system partition.
In order to do that, I want to start from the stock firmware I already downloaded, make the change then flash the whole modified firmware.
There are 5 .tar.md5 files (4 if we consider only one of CSC_ and HOME_CSC_) in this firmware, which can be flashed just fine in their original form.
What I want to do is to:
1 - unpack the AP_***.tar file (contains meta-data/fota.zip, boot.img.lz4, carrier.img.lz4, dtbo.img.lz4, metadata.img.lz4, recovery.img.lz4, super.img.lz4, userdata.img.lz4, vbmeta.img.lz4)
2 - unlz4 the super.img.lz4,
3 - unsparse the super.img to super.ext4.img (using simg2img)
4 - lpunpack the super.ext4.img into individual dynamic partitions (there are only 4: odm.img, product.img, system.img, vendor.img - this is NOT an A/B device !!)
5 - modify the text file on system.img
6 - lpmake the super.ext4.img back from odm.img, product.img, system.img, vendor.img
7 - re-sparse the super.ext4.img back into super.img (using img2simg)
8 - lz4 the super.img back into super.img.lz4
9 - Re-TAR the super.img.lz4 file plus all the rest of the original .img.lz4 files back into the AP_***.tar file
10 - Flash the AP_***.tar file to this mother****ing piece of Samsung crap without errors, and that is WITHOUT UNLOCKED BOOTLOADER, because the scumbags eliminated the OEM Unlock option from the Dev Options.
What I already know is:
- How to do the whole process without preserving any signatures.
This is already explained in this thread:
Editing system.img inside super.img and flashing our modifications
I'm trying to modify my system.img (/system/build.prop) to include support for multi users. After struggling a lot, I've succeeded following your guide (that's an awesome work btw) to unpack, mount, modify, umount and repack super.img. Then...
forum.xda-developers.com
but the author assumes the bootloader can be unlocked and therefore doesn't deal with any signatures / security-crypto-baloney checks.
What I (still) need to know is:
1 - How many crypto-security-baloney-whatever-signatures are there on all these files ?
2 - How can I restore them during repackaging so the flashing process does not get screwed up by the locked phone ?
If anyone here knows the answer to these 2 things ... well I guess they must be the Android Godfather Almighty !!
Click to expand...
Click to collapse
Try using modified/patched Odin. As for trying to bypass unlocking the bootloader to flash the modified firmware or trying to "mimic" or "fake" the original signature, that isn't going to work. Samsung's proprietary signature is an enigma that can't be cracked. Though you might be able to match the MD5 by adding a dummy file to the file you are modifying and filing it bit/byte by bit/byte, one step at a time, the goal is to add characters to the file until it is large enough to make your modified file match the original file's MD5. That is if your modified file is smaller than the original file, if your modified file is larger than the original file, you can delete unimportant files from the modified MD5 file until it is smaller than the original MD5 and then create the dummy file filled with dummy characters until it exactly matches the original MD5 bit for bit. Then try flashing your MD5 file once you gets it's MD5 code matching bit for bit. Try the patched version of Odin to flash your modified file. No guarantees that it will work but part of the security checks during flashing checks the MD5 for a match/mismatch.
Rab_DaJew said:
have you figured this out?
Click to expand...
Click to collapse
SYSTEM INFO
- Device: Blu C5L Max
- Android Version: 11
- File Manager: Root Browser (Both Classic and New)
------------------
I've been trying to change the boot animation on my phone but have been having some problems. The main problem that happened was i could not replace or delete the bootanimation.zip file. Every time i tried to delete it either gave me an error or it adds the file again. I saw that i need to delete the file in oem but the oem folder is empty.
Any help would be great.
DingDroid said:
SYSTEM INFO
- Device: Blu C5L Max
- Android Version: 11
- File Manager: Root Browser (Both Classic and New)
------------------
I've been trying to change the boot animation on my phone but have been having some problems. The main problem that happened was i could not replace or delete the bootanimation.zip file. Every time i tried to delete it either gave me an error or it adds the file again. I saw that i need to delete the file in oem but the oem folder is empty.
Any help would be great.
Click to expand...
Click to collapse
I realize this is an older post, but I wanted to chime in to maybe benefit other users facing similar issues. Like other devices running on Android 11, the BLU C5L Max integrates dynamic partitioning, whereas there is no logical /system partition. With the dynamic scheme, /system, /product and /vendor make up one larger dynamic partition called /super. So, in order to make system changes, such as the bootanimation.zip, the /super partition often needs tp be dumped as super.img (on rooted devices in which the logical /system partition cannot be mounted as r/w). The system.img, product.img and vendor.img can be extracted from the super.img. The logical /system partition can then be mounted and modified. Then, the super.img is rebuilt and flashed to the /super partition. This process enables changes to /system to persist on devices which, although rooted, are unable to attain r/w access to /system.