EFS2 format in flash - General Questions and Answers

I have dumped the NAND flash chip from a Qualcomm modem and have a large partition labelled EFS2.
Does anyone have any details of the EFS2 format so I can recreate the filesystem from this RAW flash dump.
I have already corrected the ECC errors and removed spare bytes so I can see chunks of file content, just want to recreate the directory structure and content of all files.

Related

TF700T complete flash layout

I spent some time in analyzing of flash layout. The comprehensive description below attempts to map each byte of the flash and describes way to extract it.
I would be glad if somebody could provide more detailed info about bootloader, signatures, DRM etc.
Patches are welcome.
Code:
mmcblk0 layout
All dumps were done on Asus Eee Pad Transformer Infinity TF700T, 64GB version, firmware 9.4.5.26, locked
mmcblk0 off-partition section
Offset: 0 (0x0)
Size: 38273024 (0x2480000)
Read command: busybox dd if=/dev/block/mmcblk0 of=/mnt/sdcard/mmcblk0pre1.img bs=524288 count=73
Offset: 0 (0x0)
Size: 3670016 (0x380000)
Contains: Zeroes
Purpose: Unknown
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s1.img bs=3670016 count=1
Process command: tr -d '\0' <mmcblk0pre1s1.img >mmcblk0pre1s1nz.img # mmcblk0pre1s1nz.img must be empty file
Offset: 3670016 (0x380000)
Contains: Recovery kernel image followed by zeroes
Size: 8388608 (0x800000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s2.img bs=524288 skip=7 count=16
Process commands:
perl split_bootimg.pl mmcblk0pre1s2.img
mkdir mmcblk0pre1s2.img-ramdisk
cd mmcblk0pre1s2.img-ramdisk
zcat ../mmcblk0pre1s2.img-ramdisk.gz | cpio -i
cd ..
# end Process commands
Offset: 12058624 (0xb80000)
Contains: Regular boot kernel image followed by zeroes
Size: 8388608 (0x800000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s3.img bs=524288 skip=23 count=16
Process commands:
perl split_bootimg.pl mmcblk0pre1s3.img
mkdir mmcblk0pre1s3.img-ramdisk
cd mmcblk0pre1s3.img-ramdisk
zcat ../mmcblk0pre1s3.img-ramdisk.gz | cpio -i
cd ..
# end Process commands
Offset: 20447232 (0x1380000)
Contains: Block of 16 bytes followed by 0x2de0 hexadecimal numbers followed by FF
Size: 12288 (0x3000)
Extract command: dd if=mmcblk0pre1.img of=mmcblk0pre1s4.img bs=524288 skip=39
Vital data:
Extract command: dd if=mmcblk0pre1s4.img of=mmcblk0pre1s4ss2.img bs=4096 skip=3
Binary part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch1.img bs=16 count=1
Hexadecimal part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch2.img bs=16 count=734 skip=1
Process command: unhex <mmcblk0pre1s4ss1ch2.img >mmcblk0pre1s4ss1ch2bin.img
FF part of vital data:
Extract command: dd if=mmcblk0pre1s4ss1.img of=mmcblk0pre1s4ss1ch3.img bs=16 skip=735
Process command: tr -d '\377' <mmcblk0pre1s4ss1ch3.img >mmcblk0pre1s4ss1ch3nff.img # mmcblk0pre1s4ss1ch3nff.img must be empty file
Zeroes:
Extract command: dd if=mmcblk0pre1s4.img of=mmcblk0pre1s4ss1.img bs=4096 count=3
Process command: tr -d '\0' <mmcblk0pre1s4ss2.img >mmcblk0pre1s4ss2nz.img # mmcblk0pre1s4ss2nz.img must be empty file
Purpose: Probably encrypted bootloader
mmcblk0p1
Offset: 38273024 (0x2480000)
Size: 805306368 (0x30000000)
File system size: 196608 * 4096 = 805306368 (fully occupies partition)
Format: Linux ext4 filesystem
Mounted at: /system
Mount options: read only, extended attributes, ACL
Permissions: only root can manipulate
Contains: Base system and embedded applications
Purpose: Base system
mmcblk0p2
Offset: 843579392 (0x32480000)
Size: 448790528 (0x1ac00000)
File system size: 109568 * 4096 = 448790528 (fully occupies partition)
Format: Linux ext4 filesystem
Mounted at: /cache
Mount options: read/write, no SUID, no device nodes, no atime
Permissions: only root can manipulate, UID system and GID cache can read and write
Contains: Cache
Purpose: Application cache
Note: The volume has the same UUID as mmcblk0p1
mmcblk0p3
Offset: 1292369920 (0x4d080000)
Size: 2097152 (0x200000)
File system size: 512 * 4096 = 2097152 (fully occupies partition)
Linux rev 1.0 ext3 filesystem
Not mounted
Permissions: GID system can manipulate
Contains: Empty file system
Purpose: Recovery /misc
Referenced by: /system/lib/libandroid_runtime.so recovery ramdisk: /etc/recovery.fstab
Note: File system is referenced in recovery as emmc, not ext3!
mmcblk0p4
Offset: 1294467072 (0x4d280000)
Size: 855638016 (0x33000000)
File system size: 208896 * 4096 = 855638016
Linux rev 1.0 ext3 filesystem
Not mounted
Permissions: GID system can manipulate
Contains: Empty file system
Purpose: Recovery /staging
Referenced by: recovery ramdisk: init.rc /etc/recovery.fstab
mmcblk0p5
Offset: 2150105088 (0x80280000)
Size: 5242880 (0x500000)
File system size: 5092 * 1024 = 5147488
Format: FAT32 file system, no partition table, MS-DOS "Non-system disk" boot block
Not mounted
Permissions: only root can manipulate
Contains: File system with files:
Serial numbers (ISN, PPID, SSN, UUID)
Calibration data (AL3010 light sensor, AMI304 magnetic sensor, KXTF9 motion sensor)
Purpose: Device specific unique system data, mounted as /btmac during Android boot
Referenced by: /system/bin/wifimacwriter /system/bin/brcm_patchram_plus /system/bin/sensors-config /system/bin/sixpair ramdisk: /init recovery ramdisk: /etc/recovery.fstab /init
mmcblk0p5 off file-system area
Offset in section: 5147488 (0x4e8b60)
Size: 28672 (0x7000)
Read command: busybox dd if=/dev/block/mmcblk0p5 of=/mnt/sdcard/mmcblk0p5s2.img bs=1024 skip=5092
Process command: tr -d '\0' <mmcblk0p5s2.img >mmcblk0p5s2nz.img # mmcblk0p5s2nz.img must be empty file
mmcblk0p6
Offset: 2155347968 (0x80780000)
Size: 524288 (0x80000)
Format: binary data
Permissions: UID drm can manipulate
Contains: 208 bytes of binary data, the rest are zeroes
Purpose: DRM, probably contains encrypted DRM key
Referenced by: /system/bin/wvdrmserver /system/vendor/lib/drm/libdrmwvmplugin.so
mmcblk0p7
Offset: 2155872256 (0x80800000)
Size: 5242880 (0x500000)
Format: empty
Contains: Zeroes
Purpose: Unknown
mmcblk0p8
Offset: 2161115136 (0x80d00000)
Size: 61415620608 (0xe4ca80000)
File system size: 14994040 * 4096 = 61415587840
Format: Linux ext4 filesystem
Mounted at: /data
Mount options: read/write, no SUID, no device nodes, no atime
Permissions: only root can manipulate, read and write are directory specific
Contains: User applications, user data, and virtual internal SD card
Note: /data/media is mounted via UID/GID stripping FUSE as /mnt/sdcard
mmcblk0p8 off file-system area
Offset in section: 61415587840 (0xe4ca78000)
Size: 32768 (0x8000)
Read command: busybox dd if=/dev/block/mmcblk0p8 of=/mnt/sdcard/mmcblk0p8s2.img bs=4096 skip=14994040
mmcblk0 off-partition section
Offset: 63576735744 (0xecd780000)
Size: 524288 (0x80000)
Read command: busybox dd if=/dev/block/mmcblk0 of=/mnt/sdcard/mmcblk0post8.img bs=524288 skip=121263
Process command: tr -d '\0' <mmcblk0p8s2.img >mmcblk0p8s2nz.img # mmcblk0p8s2nz.img must be empty file
Offset: 63576735744 (0xecd780000)
Offset in section: 0 (0x0)
Size: 507392 (0x7be00)
Contains: Zeroes
Purpose: Unknown
Extract command: dd if=mmcblk0post8.img of=mmcblk0post8s1.img bs=507392 count=1
Process command: tr -d '\0' <mmcblk0post8s1.img >mmcblk0post8s1nz.img # mmcblk0post8s1nz.img must be empty file
Offset: 63577243136 (0xecd7fbe00)
Offset in section: 507392 (0x7be00)
Size: 16896 (0x4200)
Contains: EFI Partition table (partition names: APP, CAC, MSC, USP, PER, YTU, CRA, UDA)
Extract command: dd if=mmcblk0post8.img of=mmcblk0post8s2.img bs=512 skip=991
Purpose: Partition table
Total size of mmcblk0: 63577260032 (0xecd800000)
Notes:
can manipulate = can read, write partition vital data, only root can mount
can read, write = can read, write partition file system contents
Read commands are ran on the Transformer
Extract and process commands are run anywhere, with pre-read image file in the current directory.
You need dd with large files support. Vanilla dd on TF700T does not support large files. Busybox dd does.
Dropbox link to Asus_Transformer_Infinity_TF700T/flash_layout.txt
Wow, thanks for this detailed analysis - much more detailed than mine.
So what can I add to your research?
Tegra-based systems have another partition table, which has a proprietary layout and an unknown purpose (maybe just important for NVFlash and for flashing blobs?). Looking at the flash.cfg in the NVFlash package from AndroidRoot.mobi, we can get the Tegra partition layout and partition names:
Partition number 1 is missing in the list, maybe it contains the extremely well-hidden APX mode recovery code or even the answer to life, the universe and everything.
The following 3 partitions are located at the beginning of mmcblk0 and their contents are apparently encrypted with a device-specific key. For some reason, with ICS-based ROMs it reads as all zeros; in JB-based ROMs additional mmcblk0boot0 and mmcblk0boot1 partitions appear which together cover this area. The "bricksafe.img" in the nvflash guide covers these 3 partitions.
2 BCT: Tegra Boot Configuration Table - 3145728 bytes
3 PT: Tegra Partition Table - 524288 bytes
4 EBT: Bootloader - 8388608 bytes
You already know the following 2:
5 SOS: Recovery kernel - 8388608 bytes
6 LNX: Linux kernel - 8388608 bytes
Then some more funny ones:
7 CER: I think this stands for "Certificate" and contains the bootloader unlock token. - 8388608 bytes. If I calculated correctly, this is at 0x1380000 into mmcblk0. Saved as "unlock-token.img" in the nvflash guide.
8 IMG: no idea what this is for - 8388608 bytes
9 GP1: space for a GPT partition table, maybe unused - 1048576 bytes
Now the regular partitions follow (p1 to p8):
10 APP: p1 = /system (Android OS)
11 CAC: p2 = /cache (for communication between Android and recovery)
12 MSC: p3 ="misc", whatever that is. On the TF101 it was used for bootloader commands.
13 USP: p4 = The update staging partition. Update blobs are copied here and flashed to the correct partition by the bootloader.
14 PER: p5 = device-specific config in a FAT filesystem
15 YTU: p6 = Apparently the DRM key. Confirmed to be overwritten with 0 by the unlocking process.
16 CRA: p7 = unknown (reserved for crash dumps?)
17 UDA: p8 = /data (Android user data)
And finally:
18 GPT: the EFI partition table that is actually used by the kernel
Well, it seems, that something (ICS stock kernel, hardware) hides contents of the first (at most) 0x380000 bytes of flash.
I am locked, and I have some token at 0x1380000 as well.
I am still thinking about a way to unlock, keep access to nvflash, and upgrade to JB keeping DRM working, even at cost of using stock system. That is why I wanted to backup and analyze everything and find all keys and signatures.
It would be also nice to know, whether there are areas of flash with hardware or kernel write lock.
utx said:
Well, it seems, that something (ICS stock kernel, hardware) hides contents of the first (at most) 0x380000 bytes of flash.
I am locked, and I have some token at 0x1380000 as well.
Click to expand...
Click to collapse
Yes, before unlocking I had something very similar to you there - a 16 byte header followed by some hexdump. I don't know what it was. It was overwritten by the unlock process with a 4 byte data block prefixed with a "-SIGNED-BY-SIGNBLOB-" header and followed by 256 bytes of what looks like a digital signature, very similar to the signed update blobs.
utx said:
I am still thinking about a way to unlock, keep access to nvflash, and upgrade to JB keeping DRM working, even at cost of using stock system. That is why I wanted to backup and analyze everything and find all keys and signatures.
Click to expand...
Click to collapse
Definitely back up the YTU partition before unlocking (p6) and then make the nvflash backups - but maybe the key must match something that is broken by the unlocking process, or it is renewed periodically, etc., so it might not help. Maybe try using DRM before unlocking and watch if the content of the partition changes over time.
utx said:
It would be also nice to know, whether there are areas of flash with hardware or kernel write lock.
Click to expand...
Click to collapse
Never tried to write directly to the block device - too scared to break something.
---------- Post added at 09:32 PM ---------- Previous post was at 09:28 PM ----------
Another small addition:
Note: /data/media is mounted via UID/GID stripping FUSE as /mnt/sdcard
Click to expand...
Click to collapse
This FUSE trick also makes /mnt/sdcard case-insensitive.
I just thought of something. What if you launched a data recovery process and recovered the DRM keys for the device?
ostar2 said:
I just thought of something. What if you launched a data recovery process and recovered the DRM keys for the device?
Click to expand...
Click to collapse
How do you define "data recovery process"? You cannot recover data that has been overwritten.
_that said:
How do you define "data recovery process"? You cannot recover data that has been overwritten.
Click to expand...
Click to collapse
Well, if the DRM partition is write enabled, it may be possible to restore its contents, if you backed it up before unlock (it is probably per-device unique). But it could be insufficient. Locked bootloader can be different than unlocked bootloader, and may drop cipher needed for DRM decihering. It is just a theory. Somebody could proof it or falsify, if:
1) Backed all accessible data before unlock.
2) Unlocked (and to be safe, also made brickproof image).
3) Recovered the data creates in step 1.
Will DRM work then? Or did we need the contents of (currently inaccessible) locked stock data of the first megabytes?
But I see no way, how to back-up first megabytes of locked device (on ICS; JB is not as interesting for us, once you upgrade to JB, you cannot create brickproof image for nvflash).
I even don't know, which part of the subsystem causes these megabytes being reported as zeroes. Is it stock Asus ICS kernel? Is it bootloader? Is it a hardware lock on the flash device?
Good idea, but what I meant by "Data Recovey". Is restoring the deleted data from that filesystem/partition.
ostar2 said:
Good idea, but what I meant by "Data Recovey". Is restoring the deleted data from that filesystem/partition.
Click to expand...
Click to collapse
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
_that said:
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Click to expand...
Click to collapse
To install AndroidRoot bootloader and by that getting nvflash blobs, you have to unlock first... The order of your steps is therefore wrong.
firetech said:
To install AndroidRoot bootloader and by that getting nvflash blobs, you have to unlock first... The order of your steps is therefore wrong.
Click to expand...
Click to collapse
Oops, thanks for noticing. I edited my post.
what if we were to read from the NAND externally (RAW)....xbox 360 style...wouldn't that be the same as nvflash....
except that the three partitions in question are encrypted with a key that is probably unique per Tegra...
2 BCT: Tegra Boot Configuration Table - 3145728 bytes
3 PT: Tegra Partition Table - 524288 bytes
4 EBT: Bootloader - 8388608 bytes
but I would suppose it wouldn't be a problem since a raw flash would restore everything back to normal...even if we can't read it..the CPU can..and that's all that matters.
---------- Post added at 11:21 AM ---------- Previous post was at 11:13 AM ----------
never mind...its a BGA
_that said:
I see, so I assume you assume you had a backup before.
Somebody (maybe you?) could try roughly the following sequence:
- get new TF700
- update to 9.4.5.26. if it's already newer, forget nvflash, but the rest could still work.
- root it using debugfs
- make a backup of /dev/block/mmcblk0p6
- do some DRM-dependent stuff and check that it works
- after some days, make another backup of /dev/block/mmcblk0p6 and compare if anything has changed. If the key is static, maybe restoring after unlocking could work. If not, chances are high that it doesn't work.
- unlock (this erases mmcblk06 and voids warranty)
- optional, but very useful: install AndroidRoot hacked bootloader to make blobs for nvflash, then use nvflash to backup all partitions
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Click to expand...
Click to collapse
Correct order maybe.
- get new TF700
- update to 9.4.5.26.
- root it using debugfs
- make a backup of /dev/block/*.*
- unlock (this erases mmcblk06 and voids warranty)
- install AndroidRoot hacked bootloader to make blobs for nvflash
- restore backup of /dev/block/mmcblk0p6
- try if DRM still works
Q1:If i backed up 9.4.5.26 all block image.After i updated 9.4.5.30 can i get the nvflash blob from backed up images?No way to dig out the blob key from the backup?
W3ber said:
Q1:If i backed up 9.4.5.26 all block image.After i updated 9.4.5.30 can i get the nvflash blob from backed up images?No way to dig out the blob key from the backup?
Click to expand...
Click to collapse
No way - the BCT, bootloader, etc. is not visible to the kernel at all (so it's not included in your images), and I don't know which kind of magic the blob creation tool uses, but I assume it's more than reading stuff from the nand.

Question about flashing nandroid backups

I want to know that when we flash specific partition images (say system.img, data.img, cache.img, etc.), then how does the software know where exactly to put those partition bytes? For example, if I flash system.img, which CHS/LBA sector will it consider as beginning of that block? If it is based on the MBR/EBR1 tables, what will happen if I'm flashing the MBR/EBR1 too?
The reason I'm asking is that I want to change the partitioning in EBR1 slightly, so that more space is allocated to /data partition instead of /sdcard. I've got an old but good conditioned MediaTek (MTK-6577) based smart-phone called Karbonn-A30 which is great in build quality and almost every other aspect, but it only has 500MB of Internal Storage (/data partition in Linux lingo) which is not good enough for apps. Presently, the MBR and EBR1 partitions are thus:
$disktype MBR
--- MBR
Regular file, size 512 bytes
DOS/MBR partition map
Partition 1: 2.000 TiB (2199023255040 bytes, 4294967295 sectors from 1024)
Type 0x05 (Extended)
Partition 2: 10 MiB (10485760 bytes, 20480 sectors from 18432)
Type 0x83 (Linux)
Partition 3: 10 MiB (10485760 bytes, 20480 sectors from 38912)
Type 0x83 (Linux)
Partition 4: 650 MiB (681574400 bytes, 1331200 sectors from 113152)
Type 0x83 (Linux)
$disktype EBR1
--- EBR1
Regular file, size 512 bytes
DOS/MBR partition map
Partition 1: 376 MiB (394264576 bytes, 770048 sectors from 1443328)
Type 0x83 (Linux)
Partition 2: 1.293 GiB (1388314624 bytes, 2711552 sectors from 2213376)
Type 0x83 (Linux)
Partition 3: 1.998 TiB (2196501691904 bytes, 4290042367 sectors from 4924928)
Type 0x83 (Linux)
Click to expand...
Click to collapse
Why this last partition which corresponds to /sdcard is left so large (1.998 TiB) is beyond my understanding! Since there is a good 2.5GB of space available on my actual /sdcard partition, I was thinking if I can alter the EBS1 and change the LBA addressing so that the third partition starts from 2097152 additional sectors (which comes to 1024MB or 1GB which is good enough for me), will it automatically increase my /data partition by 1GB and decrease the /sdcard by 1GB correspondingly? On XDA and other forums, I've read that people have successfully done this mod and achieved the change in partition sizes, but I first want to understand how it happens.

How to unbrick L29 and AL10 stuck on Fastboot with bootloop (L/UL Bootloader

After hours of research over the internet and a couple of nights in front of my computer, I finally found a method who can help resurrect any Mate 8 variant which is stuck on bootloop.
You will need 3 things:
- DC Phoenix New Account (it costs 15 euros for 15 credits to use for 72h after initial flash (small price to pay compared to sending to repair shop or having a useless brick) -
- An UPDATE.APP at your choice for your phone (AL10 or L29, both are interchangeable) -
- This file with partition rework and factory firmware - DOWNLOAD -​
Steps:
1. Make sure you have at least 30% of battery.
2. Open DC Phoenix and login with your credentials.
3. Put your phone in fastboot mode (Vol. - + Power).
4. Select «fastboot mode» in DC Phoenix and then go to the «IMG FILES» tab.
5. Select the «NXT-AL10_M00A102_Factory_firmware_Global_Nonspecific_Android_6.0_EMUI_4.0» file and hit Open.
6. Click on «Update» and be patient. This should take 10 minutes.
7. Follow the log on the left. When it says «writing success», reboot your phone (Vol. - and Power until display goes off). The phone should normally boot into a Chinese-like ROM.
8. Put your phone back in fastboot mode and select the «APP FILES» tab in DC Phoenix.
9. Select your UPDATE.APP file and hit Update. Be patient. This may take up to 20 minutes.
10. Again, look at the log for «writing success» line and then reboot your phone.
Enjoy!
You can unlock your bootloader if it is not locked and install TWRP.
WOOOT This worked but HOW!?! And what is this backdoor hack to load the image (see log ) ? LOL!
ps: the downloaded file has a different name: NXT-AL10_M00A102_Factory_firmware_Global_Nonspecific_Android_6.0_EMUI_4.0.dgtks
in the here above filename is wrong/different: NXT-L29_NV_partitions_backup.dgtks (Corrected by TS)
Corrected: ps I checked the MEGA download file with the DC-Unlocker download ( https://files.dc-unlocker.com/user.html?v=files/57694006a60d7 )
they are the same:
K:\>fc /b NXT-AL10_M00A102_Factory_firmware_Global_Nonspecific_Android_6.0_EMUI_4.0_DC_UNL.dgtks NXT-AL10_M00A102_Factory_firmware_Global_Nonspecific_Android_6.0_EMUI_4.0_Mega.dgtks
Comparing files NXT-AL10_M00A102_Factory_firmware_Global_Nonspecific_Android_6.0_EMUI_4.0_DC_UNL.dgtks and NXT-AL10_M00A102_FACTORY_FIRMWARE_GLOBAL_NONSPECIFIC_ANDROID_6.0_EMUI_4.0_MEGA.DGTKS
FC: no differences encountered
anyway
i loaded up the downloaded NXT-AL10_M00A102_Factory_firmware_Global_Nonspecific_Android_6.0_EMUI_4.0.dgtks from MEGA ( see download link from djmitza222)
into DC 0.0.35 and this happened ( see log )
options:
Force upgrade OFF
not erase NV ON
Not Erase oeminfo ON
after this the Phone boots ands is all OK and i have C900B320
ps: My phone was bootloader unlocked and FRP Locked
i dont have installed some sort of virus / backdoor ?!
and can somebody explain why i spend days with tools and stuff but this actually worked ( for 15 euro ok ) ??
########################DC LOG #################### #
The file was loaded successfully
Device found: QHC021******9247
IMEI: 86840*********23
Build number: :NRD90M test-keys
Product model: NXT-L29
Erasing nvme partition
ERASE partition nvme ...FAILED
Cannot get FBlock info from device
Activating backdoor: DONE
Erasing nvme partition
Partition nvme erased
Erasing cust partition
Partition cust erased
Erasing misc partition
Partition misc erased
Writing xloader partition with file fastbootimage/sec_xloader.img
xloader partition UPDATE ...OK
Writing ptable partition with file fastbootimage/ptable.img
ptable partition UPDATE ...OK
Writing fastboot partition with file fastbootimage/sec_fastboot.img
fastboot partition UPDATE ...OK
Writing dts partition with file fastbootimage/sec_dt.img
dts partition UPDATE ...OK
Writing fw_lpm3 partition with file fastbootimage/sec_lpm3.img
fw_lpm3 partition UPDATE ...OK
Writing sensorhub partition with file fastbootimage/sec_sensorhub.img
sensorhub partition UPDATE ...OK
Writing fw_hifi partition with file fastbootimage/sec_hifi.img
fw_hifi partition UPDATE ...OK
Writing teeos partition with file fastbootimage/sec_trustedcore.img
teeos partition UPDATE ...OK
Writing recovery partition with file fastbootimage/sec_recovery.img
recovery partition UPDATE ...OK
Writing recovery2 partition with file fastbootimage/sec_erecovery.img
recovery2 partition UPDATE ...OK
Erasing cache partition
Partition cache erased
Writing cache partition with file fastbootimage/cache.img
cache partition UPDATE ...OK
Writing boot partition with file fastbootimage/sec_boot.img
boot partition UPDATE ...OK
Writing nvme partition with file fastbootimage/nvme.img
nvme partition UPDATE ...OK
Writing trustfirmware partition with file fastbootimage/sec_bl31.bin
trustfirmware partition UPDATE ...OK
Writing modem partition with file fastbootimage/sec_balong_modem.bin
modem partition UPDATE ...OK
Writing modem_dtb partition with file fastbootimage/sec_modem_dt.img
modem_dtb partition UPDATE ...OK
Writing modemnvm_update partition with file fastbootimage/nv.bin
modemnvm_update partition UPDATE ...OK
Writing modem_dsp partition with file fastbootimage/sec_lphy.bin
modem_dsp partition UPDATE ...OK
Writing modem_om partition with file fastbootimage/modem_fs.img
modem_om partition UPDATE ...OK
Writing modemnvm_img partition with file fastbootimage/modem_nv.img
modemnvm_img partition UPDATE ...OK
Writing 3rdmodem partition with file fastbootimage/3rdmodem.img
3rdmodem partition UPDATE ...OK
Writing 3rdmodemnvm partition with file fastbootimage/3rdmodemnvm.img
3rdmodemnvm partition UPDATE ...OK
Writing 3rdmodemnvmbkp partition with file fastbootimage/3rdmodemnvmbkp.img
3rdmodemnvmbkp partition UPDATE ...OK
Erasing userdata partition
Partition userdata erased
Writing userdata partition with file fastbootimage/userdata.img
userdata partition UPDATE ...OK
Writing system partition with file fastbootimage/system.img
system partition UPDATE ...OK
Writing splash2 partition with file fastbootimage/splash2.img
splash2 partition UPDATE ...OK
Writing frp partition with file fastbootimage/frp.img
frp partition UPDATE ...OK
Erasing cust partition
Partition cust erased
Writing cust partition with file fastbootimage/cust_factory.img
cust partition UPDATE ...OK
Writing secure_storage partition with file fastbootimage/secure_storage.img
secure_storage partition UPDATE ...OK
Software written
5/1/2017 9:28:59 PM Writing device finished OK
Current version: NextL09C999B100EMUI41
Extracting partitions
Cannot create extract directory: K:\DC_Phoenix\tmp\20170501_213206_UPDATE\
Extract files to directory: K:\DC_Phoenix\
Extracting partition: XLOADER OK
Extracting partition: FW_LPM3 OK
Extracting partition: FASTBOOT OK
Extracting partition: MODEMNVM_UPDATE OK
Extracting partition: TEEOS OK
Extracting partition: TRUSTFIRMWARE OK
Extracting partition: SENSORHUB OK
Extracting partition: FW_HIFI OK
Extracting partition: BOOT OK
Extracting partition: RECOVERY OK
Extracting partition: RECOVERY2 OK
Extracting partition: DTS OK
Extracting partition: MODEM OK
Extracting partition: MODEM_DSP OK
Extracting partition: 3RDMODEM OK
Extracting partition: SYSTEM OK
Extracting partition: CUST OK
Extracting partition: MODEM_DTB OK
Device found: 012345*********BCDEF
IMEI: 868*******692123
Build number: HLNXTAL10BM00A102
Product model: HUAWEI
Writing XLOADER partition with file K:\DC_Phoenix\XLOADER.img
XLOADER partition UPDATE ...OK
Writing FW_LPM3 partition with file K:\DC_Phoenix\FW_LPM3.img
FW_LPM3 partition UPDATE ...OK
Writing FASTBOOT partition with file K:\DC_Phoenix\FASTBOOT.img
FASTBOOT partition UPDATE ...OK
Writing MODEMNVM_UPDATE partition with file K:\DC_Phoenix\MODEMNVM_UPDATE.img
MODEMNVM_UPDATE partition UPDATE ...OK
Writing TEEOS partition with file K:\DC_Phoenix\TEEOS.img
TEEOS partition UPDATE ...OK
Writing TRUSTFIRMWARE partition with file K:\DC_Phoenix\TRUSTFIRMWARE.img
TRUSTFIRMWARE partition UPDATE ...OK
Writing SENSORHUB partition with file K:\DC_Phoenix\SENSORHUB.img
SENSORHUB partition UPDATE ...OK
Writing FW_HIFI partition with file K:\DC_Phoenix\FW_HIFI.img
FW_HIFI partition UPDATE ...OK
Writing BOOT partition with file K:\DC_Phoenix\BOOT.img
BOOT partition UPDATE ...OK
Writing RECOVERY partition with file K:\DC_Phoenix\RECOVERY.img
RECOVERY partition UPDATE ...OK
Writing RECOVERY2 partition with file K:\DC_Phoenix\RECOVERY2.img
RECOVERY2 partition UPDATE ...OK
Writing DTS partition with file K:\DC_Phoenix\DTS.img
DTS partition UPDATE ...OK
Writing MODEM partition with file K:\DC_Phoenix\MODEM.img
MODEM partition UPDATE ...OK
Writing MODEM_DSP partition with file K:\DC_Phoenix\MODEM_DSP.img
MODEM_DSP partition UPDATE ...OK
Writing 3RDMODEM partition with file K:\DC_Phoenix\3RDMODEM.img
3RDMODEM partition UPDATE ...OK
Writing SYSTEM partition with file K:\DC_Phoenix\SYSTEM.img
SYSTEM partition UPDATE ...OK
Erasing CUST partition
Partition CUST erased
Writing CUST partition with file K:\DC_Phoenix\CUST.img
CUST partition UPDATE ...OK
Writing MODEM_DTB partition with file K:\DC_Phoenix\MODEM_DTB.img
MODEM_DTB partition UPDATE ...OK
Software written
5/1/2017 9:34:22 PM Writing device finished OK
Thank you for your remark! I edited the post with the correct filename.
Concerning the flash method, I think it's based on some sort of exploit. If you looked into the about section of factory firmware, you may notice that it's Android 4.3. This method is awesome because it restores the partition layout back. So if you screw something up, you have a rescue.
flashing the device 2 times 1-factory firmware 2-update.app should cost me 15 or 30 ?
No, it will cost you only 15 € / device. Lifetime. You can flash it as many times you want.
my phone back to work thanks
confirmed
phone is back to work
this is the only solution that i didn't try to avoid pay the 15 euro
but after downloading all the Failes from the internet i give this one a shot and its works
my phone was stack on boot loop and cant boot recovery twrp
phonw unlocked
Fr unlocked
to those how have same problem this is the only way don't waste your Time
thanks again
I have a huawei mate 8 al10 version, can I use the l29 firmware for unbrick and then I also get the international firmware on my phone?
Hi,
this tool really unbricked my Mate 8.
But one thing is that my serialnumber is not correct (0123456789ABCDEF). >> There is the HCU Client to fix this, I haven´t checked yet.
The other thing is, the Internet Connection does not work good. The phone is connected with wifi or mobile LTE
but it always says "no Connection to the Internet".
Do These two things stuck together or are These sepaerate Problems ??
What can I do with Internet failure ?
Greez Rainer
The internet its a common problem for B320 and B330 software versions. You cannot fix them only by flashing a different modem firmware.
Concerning thr serial, you should restore your OEMInfo backup. If you don't have it, then you should fix it via HCU Client and generate your new bootloader unlock code.
Thanks for your answer. But how can I fix the Internet Problem ?
djmitza222 said:
Thank you for your remark! I edited the post with the correct filename.
Concerning the flash method, I think it's based on some sort of exploit. If you looked into the about section of factory firmware, you may notice that it's Android 4.3. This method is awesome because it restores the partition layout back. So if you screw something up, you have a rescue.
Click to expand...
Click to collapse
So that file linked to post #3 will set the phone back to an android 4.3 base? Would it be possible do you think, to flash that through DC, and then be able to put an EMUI 4 rom like B211 on to try to get better battery life back?
Thanks for this guide, at least my phone is working again at all! :good:
But I'm facing some problems flashing a new TWRP (regardless of which version). Maybe you have a hint for me?
I am no longer have this device so I cannot assist you more than this. It's a very good device but with very poor support from developers.
djmitza222 said:
I am no longer have this device so I cannot assist you more than this. It's a very good device but with very poor support from developers.
Click to expand...
Click to collapse
Fair enough! I don't think I'll try it - juuuuust in case
djmitza222 said:
I am no longer have this device so I cannot assist you more than this. It's a very good device but with very poor support from developers.
Click to expand...
Click to collapse
Ok, still thanks for the reply. However it'll turn out, this guide was a HUGE step forward and absolutely worth the 15 bucks. :good:
question??
Patneu said:
Thanks for this guide, at least my phone is working again at all! :good:
But I'm facing some problems flashing a new TWRP (regardless of which version). Maybe you have a hint for me?
Click to expand...
Click to collapse
man ve u unbricked a mate 8 with this program?? i need to know becuase i don t want to waste 15 euro :laugh: (sry for bad english i m italian xD)
DangerousKai said:
man ve u unbricked a mate 8 with this program?? i need to know becuase i don t want to waste 15 euro :laugh: (sry for bad english i m italian xD)
Click to expand...
Click to collapse
Yes, here's what worked for me. Also, note my little update here. Hope it works out for you, too.
Patneu said:
Yes, here's what worked for me. Also, note my little update here. Hope it works out for you, too.
Click to expand...
Click to collapse
Man ty i ve unbricked my mate 8 only one questio, i ve installed my ROM stock b192 . i can update to b560 with ota autoupdate?
My stock build is L29C652B101 (demo firmware)
Is it possible to restore an update.app from L29C432B330 (european build)?
When I tray to enter in fastboot the screen is black and the PC can't see the phone

Permanently Remove TWRP 0mb Error By editing fstab.

#########Concept########
When phone data is encrypted so twrp can't decrypt it and ask for password.
So We need to find a "fstab" named file in "etc" folder and change its "encrypt" word to "decrypt"
This Fstab file is located inside "System" OR "Vendor folder".
Click to expand...
Click to collapse
For TWRP Recovery Users ( who don't have root)
PHP:
Open recovery mode and tap on "Advance>file manager" and go to this path
For Root Users Use any "Root File Manager".
PHP:
Go to "System/etc" path
OR
PHP:
go to "system_root/system/etc
If Fstab isn't available inside "system" then search it in *vendors* folder
PHP:
go to "vendor/etc"
find ("fstab") named file in etc folder.
maybe more than 1 fstab file will be there.
In that condition.
You need to check which one fstab file has partition blocks names like ("system, vendor, userdata) etc.
so just copy this Fstab file to SD card Or anywhere you like, for editing.
###Editing####
Download"Quick Edit Apk" from store.
Open This fstab file using this Quick edit tool and find line which has word like "data" or "userdata".
Something like these two lines.
PHP:
"dev/block/bootdevice/by-name/userdata"
OR
PHP:
"dev/block/bootdevice/by-name/data"
Something like these above lines.
Click to expand...
Click to collapse
Now Find word similar to "Encrypt" in this line.
Change "encrypt" word to "decrypt" of this userdata line.
You will find one of these like words .
Hint
PHP:
"forceencrypt" >>>>>>>>>>>>>>change it to "forcedecrypt"
PHP:
"encryptable" >>>>>>>>>>>>>>>>>change it to "decryptable"
PHP:
"encrypt" >>>>>>>>>>>>>>>>>>>>change it to "decrypt"
PHP:
"encryption" >>>>>>>>>>>>>>>>>>change it to "decryption"
See I Just Change "en" to "de"
Mean ”En”crypt to ”de”crypt
For example on my phone fstab the line was this.
PHP:
/dev/block/platform/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,noflush_merge wait,check,quota,reservedsize=128M,formattable,resize,forceencrypt=/dev/block/platform/bootdevice/by-name/metadata,
You can see, for me the word was "forcedecrypt".
Click to expand...
Click to collapse
After (by-name) the word was "Userdata" .
Click to expand...
Click to collapse
Now I founded both "userdata" and "forceencrypt" and i changed it according to my need.
("Root Users, You have done eding" Now reset you device and enjoy")
### TWRP Users you can continue ###
go back to recovery and copy this edited fstab to
"it's original location (where you found it).
(For me it was founded in vendor/etc path and i pasted this edited fstab there)
after pasting done, then again go to it's original location (Pasted location)(For me it was vendor/etc)
And tap on this edited "fstab" and select on "chmod" option And set permission to 0644 of this file.
wipe your data, internal storage and dalvik-cable.
Reboot
now error is completely gone
Watch this video of you're still confused.
I think this would cause error, if we ever want to re encrypt the device. Just change forceencrypt to encryptable and perform a factory reset. You will have a unencrypted device with encryption option available.
Please Correct me if I am wrong.
Yes, after your device is decrypted then you can again encrypt it by just changing the word from decrypt>>> to "encrypt" and do a factory reset.
The important part is to find the right "fstab" file from (etc) folder located inside system OR vendor directory's.
And change the encrypt word to decrypt and do a factory reset.
Wrong,
Force-encrypt to decrypt.
Riight
Force-encrypt to force-decrypt.
The number of words should be same after changed.
Like "forceencrypt" (12 words) and i changed it to "forcedecrypt" (12 words).
You just need to change en to de.
Understand.
That's a Common sense.
Abdulrehman130 said:
Yes, after your device is decrypted then you can again encrypt it by just changing the word from decrypt>>> to "encrypt" and do a factory reset.
The important part is to find the right "fstab" file from (etc) folder located inside system OR vendor directory's.
And change the encrypt word to decrypt and do a factory reset.
Wrong,
Force-encrypt to decrypt.
Riight
Force-encrypt to force-decrypt.
The number of words should be same age changed.
You just need to change en to de.
Understand.
That's a Common sense.
Click to expand...
Click to collapse
Wouldn't it be easy just to re-encrypt from setting menu instead of everyone we have to encrypt or decrypt, changing the fstab file. While your way is working, it would be best to make device encrypt-decrypt from setting. Also a plus side we don't need to perform factory reset after we encrypt and decrypt it again.
Cheers!
SHAH RUKH 45 said:
Wouldn't it be easy just to re-encrypt from setting menu instead of everyone we have to encrypt or decrypt, changing the fstab file. While your way is working, it would be best to make device encrypt-decrypt from setting. Also a plus side we don't need to perform factory reset after we encrypt and decrypt it again.
Cheers!
Click to expand...
Click to collapse
But Every device doesn't have encryption and decryption option available in settings.
Sometimes this process failed and phone OS said that we need a factor reset.
Abdulrehman130 said:
But Every device doesn't have encryption and decryption option available in settings.
Sometimes this process failed and phone OS said that we need a factor reset.
Click to expand...
Click to collapse
I have never seen a device without a encryption option.
SHAH RUKH 45 said:
I have never seen a device without a encryption option.
Click to expand...
Click to collapse
Yes, true.
But sometimes encryption needs to be disabled to fix 0mb/ unable to mount /data partition error.
My edition here, looking reasonable and feeling good? My device is Samsung A125F
Code:
# /system/etc/recovery.fstab
rootfs / ext4 rw,barrier=1 wait,logical,first_stage_mounst
system /system ext4 rw,barrier=1 wait,logical,first_stage_mount
system /system_root ext4 rw,barrier=1 wait,logical,first_stage_mount
vendor /vendor ext4 rw,barrier=1 wait,logical,first_stage_mount
product /product ext4 rw,barrier=1 wait,logical,first_stage_mount
odm /odm ext4 rw,barrier=1 wait,logical,first_stage_mount
/dev/block/platform/bootdevice/by-name/md_udc /metadata ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic,sync wait,check,formattable,first_stage_mount
/dev/block/platform/bootdevice/by-name/userdata /data ext2 rw,noatime,nosuid,nodev,discard,usrquota,grpquota,fsync_mode=nobarrier,reserve_root=32768,resgid=5678,inlinecrypt latemount,wait,check,quota,reservedsize=128M,forcedecrypt=/dev/block/platform/bootdevice/by-name/metadata
/dev/block/platform/bootdevice/by-name/cache /cache ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check,formattable
/dev/block/platform/bootdevice/by-name/protect1 /mnt/vendor/protect_f ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check,formattable
/dev/block/platform/bootdevice/by-name/protect2 /mnt/vendor/protect_s ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check,formattable
/dev/block/platform/bootdevice/by-name/nvdata /mnt/vendor/nvdata ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check,formattable
/dev/block/platform/bootdevice/by-name/nvcfg /mnt/vendor/nvcfg ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check,formattable
/dev/block/platform/bootdevice/by-name/prism /prism ext4 ro,barrier=1 nofail,avb,first_stage_mount
/dev/block/platform/bootdevice/by-name/optics /optics ext4 ro,barrier=1 nofail,avb,first_stage_mount
/dev/block/platform/bootdevice/by-name/efs /efs ext2 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic wait,check,formattable
/dev/block/platform/bootdevice/by-name/keydata /keydata ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic,inlinecrypt wait,check,formattable,fileencryption=aes-256-xts,nofail
/dev/block/platform/bootdevice/by-name/keyrefuge /keyrefuge ext4 noatime,nosuid,nodev,noauto_da_alloc,discard,journal_checksum,data=ordered,errors=panic,inlinecrypt wait,check,formattable,fileencryption=aes-256-xts,nofail
/dev/block/platform/bootdevice/by-name/frp /persistent emmc defaults defaults
/dev/block/platform/bootdevice/by-name/nvram /nvram emmc defaults defaults
/dev/block/platform/bootdevice/by-name/proinfo /proinfo emmc defaults defaults
/dev/block/platform/bootdevice/by-name/lk /bootloader emmc defaults defaults
/dev/block/platform/bootdevice/by-name/lk2 /bootloader2 emmc defaults defaults
/dev/block/platform/bootdevice/by-name/para /para emmc defaults defaults
/dev/block/platform/bootdevice/by-name/misc /misc emmc defaults defaults,first_stage_mount
/dev/block/platform/bootdevice/by-name/boot /boot emmc defaults first_stage_mount,nofail,
/dev/block/platform/bootdevice/by-name/recovery /recovery emmc defaults first_stage_mount,nofail,
/dev/block/platform/bootdevice/by-name/logo /logo emmc defaults defaults
/dev/block/platform/bootdevice/by-name/expdb /expdb emmc defaults defaults
/dev/block/platform/bootdevice/by-name/seccfg /seccfg emmc defaults defaults
/dev/block/platform/bootdevice/by-name/tee1 /tee1 emmc defaults defaults
/dev/block/platform/bootdevice/by-name/tee2 /tee2 emmc defaults defaults
/dev/block/platform/bootdevice/by-name/scp1 /scp1 emmc defaults defaults
/dev/block/platform/bootdevice/by-name/scp2 /scp2 emmc defaults defaults
/dev/block/platform/bootdevice/by-name/sspm_1 /sspm_1 emmc defaults defaults
/dev/block/platform/bootdevice/by-name/sspm_2 /sspm_2 emmc defaults defaults
/dev/block/platform/bootdevice/by-name/efuse /efuse emmc defaults defaults
/dev/block/platform/bootdevice/by-name/md1img /md1img emmc defaults defaults
/dev/block/platform/bootdevice/by-name/md1dsp /md1dsp emmc defaults defaults
/dev/block/platform/bootdevice/by-name/md1arm7 /md1arm7 emmc defaults defaults
/dev/block/platform/bootdevice/by-name/md3img /md3img emmc defaults defaults
/dev/block/platform/bootdevice/by-name/gz1 /gz1 emmc defaults defaults
/dev/block/platform/bootdevice/by-name/gz2 /gz2 emmc defaults defaults
/dev/block/platform/bootdevice/by-name/spmfw /spmfw emmc defaults defaults
/dev/block/platform/bootdevice/by-name/boot_para /boot_para emmc defaults defaults
/dev/block/platform/bootdevice/by-name/odmdtbo /odmdtbo emmc defaults defaults
/dev/block/platform/bootdevice/by-name/dtbo /dtbo emmc defaults defaults
/dev/block/platform/bootdevice/by-name/vbmeta /vbmeta emmc defaults defaults
/dev/block/platform/bootdevice/by-name/uh /uh emmc defaults defaults
Abdulrehman130 said:
#########Concept########
For TWRP Recovery Users ( who don't have root)
PHP:
Open recovery mode and tap on "Advance>file manager" and go to this path
For Root Users Use any "Root File Manager".
PHP:
Go to "System/etc" path
OR
PHP:
go to "system_root/system/etc
If Fstab isn't available inside "system" then search it in *vendors* folder
PHP:
go to "vendor/etc"
find ("fstab") named file in etc folder.
maybe more than 1 fstab file will be there.
In that condition.
You need to check which one fstab file has partition blocks names like ("system, vendor, userdata) etc.
so just copy this Fstab file to SD card Or anywhere you like, for editing.
###Editing####
Download"Quick Edit Apk" from store.
Open This fstab file using this Quick edit tool and find line which has word like "data" or "userdata".
Something like these two lines.
PHP:
"dev/block/bootdevice/by-name/userdata"
OR
PHP:
"dev/block/bootdevice/by-name/data"
Now Find word similar to "Encrypt" in this line.
Change "encrypt" word to "decrypt" of this userdata line.
You will find one of these like words .
Hint
PHP:
"forceencrypt" >>>>>>>>>>>>>>change it to "forcedecrypt"
PHP:
"encryptable" >>>>>>>>>>>>>>>>>change it to "decryptable"
PHP:
"encrypt" >>>>>>>>>>>>>>>>>>>>change it to "decrypt"
PHP:
"encryption" >>>>>>>>>>>>>>>>>>change it to "decryption"
See I Just Change "en" to "de"
Mean ”En”crypt to ”de”crypt
For example on my phone fstab the line was this.
PHP:
/dev/block/platform/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,noflush_merge wait,check,quota,reservedsize=128M,formattable,resize,forceencrypt=/dev/block/platform/bootdevice/by-name/metadata,
Now I founded both "userdata" and "forceencrypt" and i changed it according to my need.
("Root Users, You have done eding" Now reset you device and enjoy")
### TWRP Users you can continue ###
go back to recovery and copy this edited fstab to
"it's original location (where you found it).
(For me it was founded in vendor/etc path and i pasted this edited fstab there)
after pasting done, then again go to it's original location (Pasted location)(For me it was vendor/etc)
And tap on this edited "fstab" and select on "chmod" option And set permission to 0644 of this file.
wipe your data, internal storage and dalvik-cable.
Reboot
now error is completely gone
Watch this video of you're still confused.
Click to expand...
Click to collapse

Editing system.img inside super.img and flashing our modifications

Hello and welcome to my first post.
today I will talk about editing super.img and modifying system.img inside of it.
In android 10 and bigger, sometimes there is no system.img in ROM it because google starting use Dynamic Partitions for more flexible images size - more details here
instead of system.img we will see super.img that include few partition inside.
So In this case, in order to do our modifications in the rom we should unpack the super.img and after that to unpack the system.img and then build it again.
requirements:
1) I will use ubuntu in vbox so you need a linux machine.
2) some super.img for editing.
steps:
1) unpacking super.img
2) resizing system.img in order to insert our MODS to the rom
3) mounting system.img
4) do our modifications
5) umounting system
6) shrink edited system.img to the minimal size
7) generating new super.img
8) flashing it to our device
Let's Start!
1) unpacking super image:
First of all the super.img file might be in sparse format so we need to make it raw image
open termianl in super.img directory and type:
Code:
simg2img super.img super.ext4.img
now we got new file named super.ext4.img: we are working with this file.
There are multiple ways to unpack super.img:
for example: using imjtool or using lpunpack
If you use imjtool follow this
Open terminal in imjtool path and super.img path and type
Code:
./imjtool.ELF64 super.img extract
if you got and error run it as superuser by
Code:
sudo ./imjtool.ELF64 super.img extract
I will use lpunpck tool (Official tool from google)
locate lpunpack and super.ext4.img and open terminal in this folder.
Then type:
Code:
./lpunpack super.ext4.img
wait for it it may take couple of minutes.
now our folder looks like this:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
2)resizing system.img in order to make enough space for modifications
turn back into your terminal and type:
Code:
fallocate -l 2G system.img
This command allocates more space for system.img (Changing to 2GB)
After that type:
Code:
resize2fs system.img 2G
This command increases the file system size of the partition to 2G
3) mounting system.img
Create new folder and mount:
Code:
mkdir system
Code:
sudo mount -t ext4 -o loop system.img system
Now system dir contains all system.img files.
4)edit it as you want
***IMPORTANT***
In order to make changes you should use superuser:
when you typing a command while you modifying use sudo prefix.
you can use the file explorer with superuser permissions by typing:
Code:
sudo nautilus
5) umount system
*)make sure the terminal is not in system directory or some sub dir of it
if Yes just type
Code:
cd ..
to go up in the directories tree (do it many times until you will be in the same directory like the image in the top)
type:
Code:
sudo umount system
Code:
e2fsck -yf system.img
(fixes file system errors)
6) shrink the edit system.img into the minimum possible size
by:
Code:
resize2fs -M system.img
fix the file system again:
Code:
e2fsck -yf system.img
7) generating new super.img
as you can see at the image above, in my case the super.ext4.img contaings 3 partitions:
1)system.img(that we worked with)
2)vendor.img
3)product.img
in you case it may be different so follow the logic of the following command and not copy paste it.
another tool from google that called lpmake using for packing super.img.
How this tool works
it creates empty super.img with all headers stuff and pushing partitions into it
so let's start with generating:
this is the documentation of the tool: link
at first we should get each partitions file size
we can do it by:
Code:
stat -c '%n %s' system.img
do it for all partitions files
And this is tricky and critical step:
***DO NOT COPY!!***
Code:
./lpmake --metadata-size 65536 --super-name super --metadata-slots 1 --device super:4294967296 --group main:3139354624 --partition system:readonly:1434726400:main --image system=./system.img --partition vendor:readonly:330866688:main --image vendor=./vendor.img --partition product:readonly:1373761536:main --image product=./product.img --sparse --output ./super.new.img
explanation:
1) --metadata-size: The maximum size that partition metadata may consume. A partition entry uses 64 bytes and an extent entry uses 16 bytes. I think 65536 should work in most cases.
2) --metadata-slots - The number of slots available for storing metadata. This should match the number of update slots on the device, 2 for A/B devices and 1 for non-A/B.
3)--device super: The size of the “super” partition on the device. It must match exactly, and it must be evenly divisible by the sector size (512 bytes).
4) --group main:4293513600: sum of all partitions files sizes
5) --partition system:readonly:1577095168:main --image system=./system.img : Every parition file size with permissions(readonly) and input img file
good work we got new custom rom!
credit to(for repacking step):
XDA Post: https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70
8) flashing the new rom to a physical device
First of all we should unlock the boot loader without unlocking we may brick the phone
It can be done by allowing oem unlock in developers options and rebooting into bootloader and type:
Code:
fastboot flashing unlock
But it may not work - it depends on your device so check in google.
After you unlocked the bootloader flash the new rom by:
Code:
fastboot flash super super.new.img
If your devices alert for unlocked bootloader(orange state)
you can remove this annoying alert
just search on google.
if you have mediatek check this link:
https://forum.hovatek.com/thread-31664.html
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, after flashing the new super.img, nothing changes on the phone. I've tried adding and removing files to the system.img before reflashing, and after flashing, i've verified using adb shell. It seem that the image flashed do not contains my modifications. In other words, I succeed to repack a modified super.img, but flashing the new super.img do not modify the phone itself. Any clues? Can you help me?
Phone is Umidigi A7 Pro 64GB
saga1900 said:
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, after flashing the new super.img, nothing changes on the phone. I've tried adding and removing files to the system.img before reflashing, and after flashing, i've verified using adb shell. It seem that the image flashed do not contains my modifications. In other words, I succeed to repack a modified super.img, but flashing the new super.img do not modify the phone itself. Any clues? Can you help me?
Phone is Umidigi A7 Pro 64GB
Click to expand...
Click to collapse
Hey dear thank you for the compliment, please tell me more about how did you flash the new image.
hey dear did you flash it by using sp flash tool? did you unlocked the bootloader? did you see orange state warning when the device booted after flashing?
Brepro1 said:
Hey dear thank you for the compliment, please tell me more about how did you flash the new image.
hey dear did you flash it by using sp flash tool? did you unlocked the bootloader? did you see orange state warning when the device booted after flashing?
Click to expand...
Click to collapse
Hi, thx for your reply!
I've unlocked the bootloader as you oriented, and after that, I'm seeing the orange warning!I tried flashing using two methods. Using SP Flash Tool, and using flashboot.
Using SP Flash Tool was straight forward. Just selected the Scatter File, then picked the new super.img. Successfully flashed, but no changes on the phone.
Using flashboot: ./flashboot flash super super.modified.img
What a did, in short, was:
1.) simg2img super.img super.raw
2.) imjtool super.raw extract (also tried using lpunpack as you oriented)
3.) mount -t ext4 -o loop system.img /mount/point
4.) edit everything needed
5.) umount /mount/point
6.) repacked super.img using lpmake
7.) flashed the new super.img using SPFT or flashboot. Boths succeeds, but none really modifies the phone
To double check that the new super.img is correct, I've extracted it again, and double checked my changes. and they are there.
Vary strange, I don't have an idea, sorry
Brepro1 said:
Vary strange, I don't have an idea, sorry
Click to expand...
Click to collapse
NP, thanks anyway. I'm reading about a few things like disabling vbmeta verity and other things. Also, I did not mentioned, but I've downloaded and modified a stock rom, and my phone is not rooted. If i found anything that worths mention here, I'll update this thread
i cant mounr system.img . Cant you help me
#sudo mount -t ext4 -o loop system.img system
mount: /home/nam/system: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error
NguyenNhutNam said:
i cant mounr system.img . Cant you help me
#sudo mount -t ext4 -o loop system.img system
mount: /home/nam/system: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error
Click to expand...
Click to collapse
what does the command
file path://system.img
show up?
Anyone can help how to repack an unpacked super.img?
Try to delete an app in the product and system.img and post the instructions to repack everything into a super.img again.
My goal is to remove most of the preinstalled Google apps.
Here is the firmware link
UMIDIGI_A9_PRO_128GB_V1-0_20210127
MediaFire is a simple to use free service that lets you put all your photos, documents, music, and video in a single place so you can access them anywhere and share them everywhere.
www.mediafire.com
How do you get this size, from the scatter file super partition size?
3)--device super: The size of the “super” partition on the device. It must match exactly, and it must be evenly divisible by the sector size (512 bytes).
After repacking I also get this error, is it normal?
'Invalid sparse file format at header magic'
Brepro1 said:
Hello and welcome to my first post.
today I will talk about editing super.img and modifying system.img inside of it.
In android 10 and bigger, sometimes there is no system.img in ROM it because google starting use Dynamic Partitions for more flexible images size - more details here
instead of system.img we will see super.img that include few partition inside.
So In this case, in order to do our modifications in the rom we should unpack the super.img and after that to unpack the system.img and then build it again.
requirements:
1) I will use ubuntu in vbox so you need a linux machine.
2) some super.img for editing.
steps:
1) unpacking super.img
2) resizing system.img in order to insert our MODS to the rom
3) mounting system.img
4) do our modifications
5) umounting system
6) shrink edited system.img to the minimal size
7) generating new super.img
8) flashing it to our device
Let's Start!
1) unpacking super image:
First of all the super.img file might be in sparse format so we need to make it raw image
open termianl in super.img directory and type:
Code:
simg2img super.img super.ext4.img
now we got new file named super.ext4.img: we are working with this file.
There are multiple ways to unpack super.img:
for example: using imjtool or using lpunpack
If you use imjtool follow this
Open terminal in imjtool path and super.img path and type
Code:
./imjtool.ELF64 super.img extract
if you got and error run it as superuser by
Code:
sudo ./imjtool.ELF64 super.img extract
I will use lpunpck tool (Official tool from google)
locate lpunpack and super.ext4.img and open terminal in this folder.
Then type:
Code:
./lpunpack super.ext4.img
wait for it it may take couple of minutes.
now our folder looks like this:
2)resizing system.img in order to make enough space for modifications
turn back into your terminal and type:
Code:
fallocate -l 2G system.img
This command allocates more space for system.img (Changing to 2GB)
After that type:
Code:
resize2fs system.img 2G
This command increases the file system size of the partition to 2G
3) mounting system.img
Create new folder and mount:
Code:
mkdir system
Code:
sudo mount -t ext4 -o loop system.img system
Now system dir contains all system.img files.
4)edit it as you want
***IMPORTANT***
In order to make changes you should use superuser:
when you typing a command while you modifying use sudo prefix.
you can use the file explorer with superuser permissions by typing:
Code:
sudo nautilus
5) umount system
*)make sure the terminal is not in system directory or some sub dir of it
if Yes just type
Code:
cd ..
to go up in the directories tree (do it many times until you will be in the same directory like the image in the top)
type:
Code:
sudo umount system
Code:
e2fsck -yf system.img
(fixes file system errors)
6) shrink the edit system.img into the minimum possible size
by:
Code:
resize2fs -M system.img
fix the file system again:
Code:
e2fsck -yf system.img
7) generating new super.img
as you can see at the image above, in my case the super.ext4.img contaings 3 partitions:
1)system.img(that we worked with)
2)vendor.img
3)product.img
in you case it may be different so follow the logic of the following command and not copy paste it.
another tool from google that called lpmake using for packing super.img.
How this tool works
it creates empty super.img with all headers stuff and pushing partitions into it
so let's start with generating:
this is the documentation of the tool: link
at first we should get each partitions file size
we can do it by:
Code:
stat -c '%n %s' system.img
do it for all partitions files
And this is tricky and critical step:
***DO NOT COPY!!***
Code:
./lpmake --metadata-size 65536 --super-name super --metadata-slots 1 --device super:4294967296 --group main:3139354624 --partition system:readonly:1434726400:main --image system=./system.img --partition vendor:readonly:330866688:main --image vendor=./vendor.img --partition product:readonly:1373761536:main --image product=./product.img --sparse --output ./super.new.img
explanation:
1) --metadata-size: The maximum size that partition metadata may consume. A partition entry uses 64 bytes and an extent entry uses 16 bytes. I think 65536 should work in most cases.
2) --metadata-slots - The number of slots available for storing metadata. This should match the number of update slots on the device, 2 for A/B devices and 1 for non-A/B.
3)--device super: The size of the “super” partition on the device. It must match exactly, and it must be evenly divisible by the sector size (512 bytes).
4) --group main:4293513600: sum of all partitions files sizes
5) --partition system:readonly:1577095168:main --image system=./system.img : Every parition file size with permissions(readonly) and input img file
good work we got new custom rom!
credit to(for repacking step):
XDA Post: https://forum.xda-developers.com/showpost.php?p=82241115&postcount=70
8) flashing the new rom to a physical device
First of all we should unlock the boot loader without unlocking we may brick the phone
It can be done by allowing oem unlock in developers options and rebooting into bootloader and type:
Code:
fastboot flashing unlock
But it may not work - it depends on your device so check in google.
After you unlocked the bootloader flash the new rom by:
Code:
fastboot flash super super.new.img
If your devices alert for unlocked bootloader(orange state)
you can remove this annoying alert
just search on google.
if you have mediatek check this link:
https://forum.hovatek.com/thread-31664.html
Click to expand...
Click to collapse
when I put the command line
./lpmake --metadata-size 65536 --super-name super --metadata-slots 2 --device super: 6836715520 --group main: 6642450432 --partition system: readonly: 5244977152: main --image system =. / system.img --partition odm: readonly: 4349952: main --image odm =. / odm.img --partition product: readonly: 752545792: main --image product =. / product.img --partition vendor: readonly: 640577536: main --image vendor =. / Vendor.img --sparse --output ./super_new.img
it says this: Invalid sparse file format at header magic
why ????
I edited the vendor.img but something strange happens:
$stat -c '%n %s' *
super.img 3758096384
product.img 1596944384
system.img 1128718336
vendor.img 544976896
$../otatools/bin/lpmake --metadata-size 65536 --super-name super --metadata-slots 1 --device super:3758096384 --group main:3270639616 --partition system:readonly:1128718336:main --image system=./system.img --partition vendor:readonly:544976896:main --image vendor=./vendor.img --partition product:readonly:1596944384:main --image product=./product.img --sparse --output ./super.new.img
lpmake I 02-17 12:18:27 2646704 2646704 builder.cpp:1012] [liblp]Partition system will resize from 0 bytes to 1128718336 bytes
lpmake I 02-17 12:18:27 2646704 2646704 builder.cpp:1012] [liblp]Partition vendor will resize from 0 bytes to 544976896 bytes
lpmake I 02-17 12:18:27 2646704 2646704 builder.cpp:1012] [liblp]Partition product will resize from 0 bytes to 1596944384 bytes
Invalid sparse file format at header magic
Invalid sparse file format at header magic
Invalid sparse file format at header magic
BUT....
$stat -c '%n %s' super.new.img
super.new.img 3248851200
which is not divisible by 512!
Shouldn't it be 3758096384 ?
This is for android 10 custom os. Or it will work on all android 10 mobile. Can we modify FRP partition using this.
Me too, sorry
@Brepro1 thank you so much for writing this detailed guide.
Thanks to your detailed guide I was able to create an automated bash script that performs all of these steps automatically and makes all read only partitions inside super.img (system, vendor , product, etc...) into read write-able partitions again and flash to device as a brand new super.img.
It would be an honor for me if you could please try it and let me know if it works on your device. Thanks.
Here is the link:
https://forum.xda-developers.com/t/script-mount-system-as-read-write-android-10.4240703/
I have same issue as already was mentioned by NguyenNhutNam on Jan-20, i.e.:
In response to
sudo mount -t ext4 -o loop system.img edit
I'm getting this:
wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
And Linux tells me this:
file system.img
system.img: Linux rev 1.0 ext2 filesystem data, UUID=4729639d-b5f2-5cc1-a120-9ac5f788683c (extents) (large files) (huge files)
Of course, I tried:
sudo mount -t ext2 -o loop system.img edit
only to get this:
wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
Any ideas?
Figured out the reason.
Topicstarter confuses people with incorrect instructions.
The code below works great in Ubuntu
Code:
sudo su
mkdir /mnt/dir
mount -t ext4 -o loop,rw ./system.img /mnt/dir
But as soon as I try it directly inside Android I get this error:
Code:
mount: '/dev/block/loop10'->'/mnt/dir': Block device required
I guess this must be some kind of Android limitation...
use busybox mount applet instead of toybox
Brepro1 said:
Hello and welcome to my first post.
today I will talk about editing super.img and modifying system.img inside of it.
In android 10 and bigger, sometimes there is no system.img in ROM it because google starting use Dynamic Partitions for more flexible images size - more details here
Click to expand...
Click to collapse
None of this is working on the Moto One 5g Ace. All I want to do is get into /product/media/audio/ringtones to delete the crappy ones like I do with EVERY VERSION OF ANDROID and replace them with my own. I can't even open the images up and mod them because of the Read only xx. Please help and give detailed instructions like I'm a 5 year old. Have tried on linux and windows to ZERO success and LeBigMac's script didn't do xxxxx either.
Mod Edit: Post edited.
why don't use magisk native systemless method? just overlay magisk module with desired mods
https://topjohnwu.github.io/Magisk/guides.html#easy-replace
For those who can't mount system image see this twitter conversation by
https://twitter.com/i/web/status/1170404631865778177

Categories

Resources