Related
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.
SL 101 with cwm. on ICS.
I have tried over and over and many different ways to figure this out.... here is what's happening.
"power on" is stuck in splash screen and WILL NOT recognize on my PC as a device or in ADB
"power + vol down" grants me recovery mode which WILL recognize.
SD card will not mount to device. (i purchased brand new)
Cannot seem to push any files to internal storage... this is what my CMD looks like.
---------------------------------------
adb devices =
list of devices attached
0123456789abcdef recovery
C:\Users\me\Desktop\Android>adb push C:\Users\me\Desktop\US_epad-user-9.2.1.27.1.zip /sdcard/Download/
---------------------------------------
When I hit enter it does nothing but go to the space below and won't let me type anything.
I have tried PERI which didn't work because when it starts rebooting my device it just boots to the splash screen where it won't recognize on my PC
PLEASE any help I'm ripping my hair out here!
I have got the same problem, which is mentioned here: http://forum.xda-developers.com/showthread.php?t=2244728
Now I am trying to discover which of the mounting points are internal sdcard and data, so I would be able to format them and I hope that this will fix my problem.
You are also unlucky because Slider and TF101G versions of the tablet doesn't support NVflash: http://forum.xda-developers.com/showthread.php?t=1688447
They support but ASUS hasn't provided developers with the keys: http://androidroot.mobi/technical/tf-secure-boot-key/
Sincerely,
Žiga
ZigaG said:
I have got the same problem, which is mentioned here: http://forum.xda-developers.com/showthread.php?t=2244728
Now I am trying to discover which of the mounting points are internal sdcard and data, so I would be able to format them and I hope that this will fix my problem.
But since you have got the TF101 version (not G or slider) of the tablet, you can try to use NVflash: http://forum.xda-developers.com/showthread.php?t=1688447
Sincerely,
Žiga
Click to expand...
Click to collapse
I do have the slider and would prefer to find help pertaining to that but it seems there are way more guides on the TF101 not SL101
It specifically says you cannot use the NVflash for sl101....
Sorry, I misread it. I fixed my post.
ZigaG said:
I have got the same problem, which is mentioned here: http://forum.xda-developers.com/showthread.php?t=2244728
Now I am trying to discover which of the mounting points are internal sdcard and data, so I would be able to format them and I hope that this will fix my problem.
You are also unlucky because Slider and TF101G versions of the tablet doesn't support NVflash: http://forum.xda-developers.com/showthread.php?t=1688447
They support but ASUS hasn't provided developers with the keys: http://androidroot.mobi/technical/tf-secure-boot-key/
Sincerely,
Žiga
Click to expand...
Click to collapse
So does that mean I'm stuck until something comes out? Or is there an alternative route.
chchas said:
So does that mean I'm stuck until something comes out? Or is there an alternative route.
Click to expand...
Click to collapse
You can check the file /proc/mtd and /proc/mounts and upload it here, so I can see if we are dealing with the same problem. You can try to mount external sdcard.
While in ADB use:
Code:
adb pull /proc/mtd backup/
adb pull /proc/mounts backup/
This will copy this 2 files to folder backup.
Žiga
ZigaG said:
You can check the file /proc/mtd and /proc/mounts and upload it here, so I can see if we are dealing with the same problem. You can try to mount external sdcard.
While in ADB use:
Code:
adb pull /proc/mtd backup/
adb pull /proc/mounts backup/
This will copy this 2 files to folder backup.
Žiga
Click to expand...
Click to collapse
remote object '/proc/mtd' does not exist
remote object '/proc/mounts' not a file or directory
chchas said:
remote object '/proc/mtd' does not exist
remote object '/proc/mounts' not a file or directory
Click to expand...
Click to collapse
Strange!? What is outputted if you write:
Code:
adb shell ls
ZigaG said:
Strange!? What is outputted if you write:
Code:
adb shell ls
Click to expand...
Click to collapse
cache ---- init.rc ---- sys
data ---- proc ---- system
default.prop ---- res ---- tmp
dev ---- root --- ueventd.goldfish.rc
etc --- sbin --- ueventd.rc
fstab.ventana --- sdcard--- ueventd.ventana.rc
init --- staging---
chchas said:
cache ---- init.rc ---- sys
data ---- proc ---- system
default.prop ---- res ---- tmp
dev ---- root --- ueventd.goldfish.rc
etc --- sbin --- ueventd.rc
fstab.ventana --- sdcard--- ueventd.ventana.rc
init --- staging---
Click to expand...
Click to collapse
OK, do you have busybox installed?
Can you post files: (-> adb pull... or you can insert external SDCARD and copy the files on it)
- /etc/fstab? -> here is written which partition is mounted as sdcard, system, data...
- /proc/partitions -> here are listed all the partitions that you have on the tablet.
Sincerely,
Žiga
ZigaG said:
OK, do you have busybox installed?
Can you post files: (-> adb pull... or you can insert external SDCARD and copy the files there)
- /etc/fstab? -> here is writted which partition is mounted as sdcard, system, data...
- /proc/partitions -> here are listed all the partitions that you have on tablet
Sincerely,
Žiga
Click to expand...
Click to collapse
I do not have busy box. and cannot install any new apps on tablet as far as I know... unless downloading on my computer will send it to my tablet? still wouldn't be able to open anything.
I'm a little confused about
Can you post files: (-> adb pull... or you can insert external SDCARD and copy the files there)
-/etc/fstab -> here is writted which partition is mounted as sdcard, system, data...
- /proc/partitions -> here are listed all the partitions that you have on tablet
should i write in cmd adb pull /etc/fstab/ ?
Sorry I feel like i need someone to hold my hand while i do this. I am so frustrated with the millions of different ways I've tried but it seems I have a very unique problem that doesn't have many helps vids/threads out there.
chchas said:
I do not have busy box. and cannot install any new apps on tablet as far as I know... unless downloading on my computer will send it to my tablet? still wouldn't be able to open anything.
I'm a little confused about
Can you post files: (-> adb pull... or you can insert external SDCARD and copy the files there)
-/etc/fstab -> here is writted which partition is mounted as sdcard, system, data...
- /proc/partitions -> here are listed all the partitions that you have on tablet
should i write in cmd adb pull /etc/fstab/ ?
Sorry
Click to expand...
Click to collapse
You can try, but without / at the end of fstab since fstab is not directory but file.
Code:
PULL usage: adb pull "file on tablet" "copy to remote machine"
adb pull /etc/fstab backup/fstab
adb pull /proc/partitions backup/partitions
If this doesn't work, you can insert micro SD in tablet and use adb shell to write linux commands.
Sincerely,
Žiga
ZigaG said:
You can try, but without / at the end of fstab since fstab is not directory but file.
Code:
PULL usage: adb pull "file on tablet" "copy to remote machine"
adb pull /etc/fstab backup/fstab
adb pull /proc/partitions backup/partitions
If this doesn't work, you can insert micro SD in tablet and use adb shell to write linux commands.
Sincerely,
Žiga
Click to expand...
Click to collapse
fstab gave me
17 kb/s <108 bytes in 0.006s>
proc/partitions
60 kb/s <374 bytes in 0.006s>
not sure where i'll need to go to figure out which linux commands would need to be done...
chchas said:
fstab gave me
17 kb/s <108 bytes in 0.006s>
proc/partitions
60 kb/s <374 bytes in 0.006s>
not sure where i'll need to go to figure out which linux commands would need to be done...
Click to expand...
Click to collapse
OK, I see. This is only time needed for transfer.
Go to your folder, where you have got adb.exe (you can search with windows). There is created new folder backup, where you can find fstab and partitions. Upload the files or open them with notepad++ or regular notepad and paste the content of files here (it is the best to use #-tag in the editor of the post so the code is easier to read.)
Sincerely,
Žiga
ZigaG said:
OK, I see. This is only time needed for transfer.
Go to your folder, where you have got adb.exe (you can search with windows). There is created new folder backup, where you can find fstab and partitions. Upload the files or open them with notepad++ or regular notepad and paste the content of files here (it is the best to use #-tag in the editor of the post so the code is easier to read.)
Sincerely,
Žiga
Click to expand...
Click to collapse
fstab -
#-tag /dev/block/mmcblk0p2 /cache ext4 rw
/dev/block/mmcblk0p7 /data ext4 rw
/dev/block/mmcblk0p1 /system ext4 rw
partitions
#-tag major minor #blocks name
179 0 15097856 mmcblk0
179 1 524288 mmcblk0p1
179 2 542208 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 542208 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 13457920 mmcblk0p7
179 8 15558144 mmcblk1
179 9 15554048 mmcblk1p1
chchas said:
fstab -
#-tag /dev/block/mmcblk0p2 /cache ext4 rw
/dev/block/mmcblk0p7 /data ext4 rw
/dev/block/mmcblk0p1 /system ext4 rw
partitions
#-tag major minor #blocks name
179 0 15097856 mmcblk0
179 1 524288 mmcblk0p1
179 2 542208 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 542208 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 13457920 mmcblk0p7
179 8 15558144 mmcblk1
179 9 15554048 mmcblk1p1
Click to expand...
Click to collapse
OK thank you, I will analyse and compare the files with mine and from other TF's. But so far, I discovered, that TF's don't have special partition for data as on other Android devices and this probably causes problem.
For posting code, you can use [ CODE ] You write here code [ /CODE ] - write CODE in brackets without spaces. In post editor there is a sign # for indicating code.
You can try mounting /dev/block/mmcblk0p7 to a folder:
Code:
adb shell
mkdir NEW
mount /dev/block/mmcblk0p7 NEW
It probably won't work and this will indicate, that we are issuing the same problem.
Sincerely,
Žiga
ZigaG said:
OK thank you, I will analyse and compare the files with mine and from other TF's. But so far, I discovered, that TF's don't have special partition for data as on other Android devices and this probably causes problem.
For posting code, you can use [ CODE ] You write here code [ /CODE ] - write CODE in brackets without spaces. In post editor there is a sign # for indicating code.
You can try mounting /dev/block/mmcblk0p7 to a folder:
Code:
adb shell
mkdir NEW
mount /dev/block/mmcblk0p7 NEW
It probably won't work and this will indicate, that we are issuing the same problem.
Sincerely,
Žiga
Click to expand...
Click to collapse
Code:
adb shell mount/dev/block/mmcblk0p7
/sbin/sh: adb not found
chchas said:
Code:
adb shell mount/dev/block/mmcblk0p7
/sbin/sh: adb not found
Click to expand...
Click to collapse
Use commands as I wrote them:
This will connect to your tablet and access tablet's terminal commands
Code:
adb shell
You need to create new folder to which you will mount partition
Code:
mkdir /NEW
Now you only need to mount the partition
Code:
mount /dev/block/mmcblk0p7 /NEW
Did you have external sdcard attached, when you uploaded file partitions?
ZigaG said:
Use commands as I wrote them:
This will connect to your tablet and access tablet's terminal commands
Code:
adb shell
You need to create new folder to which you will mount partition
Code:
mkdir /NEW
Now you only need to mount the partition
Code:
mount /dev/block/mmcblk0p7 /NEW
Did you have external sdcard attached, when you uploaded file partitions?
Click to expand...
Click to collapse
I don't remember partitioning the SD card. I did not have an SD card when I rooted.
I followed the code lines and it only came back as ~ #
chchas try this http://forum.xda-developers.com/showthread.php?t=2244728.
If you have any questions feel free to ask.
Have a nice day,
Žiga
Hello.
I have a Samsung Relay that is rebranded by Cellular One of North East AZ. They have a fancy super thin sticker over the Tmobile logo on the glass. lol... But the firmware in the device is branded by Cellular One.
I cannot find that firmware anywhere and want to know if anyone has any directions on how to back up the firmware so It could be loaded onto a t-mobile Relay to "brand" it for Cellular One.
Appreciate any help you can offer.
Thanks.
(I normally play in CDMA world, but I moved to po dunk nothing ville and VZW Sucks here, so had to go with Cell One. First real experience with GSM)
I've never done this before and I'm not 100% sure if it can be done. But there probably are ways if you're clever enough. So here's what I would try if I were in your position:
1. Check if there's a way to dump it with Odin. You can google around to see if it's possible but I'm pretty sure it's a feature in Odin (Whether our phone supports it is another story). You would have to boot into download mode, (vol down + home + power when powering on) and then follow whatever directions you find for dumping a rom. Just make sure you don't flash anything to your device. And make sure you know what you're doing with Odin because it can brick your phone if you push the wrong buttons.
2. The other way to do it is to dump your partition contents with the dd command (I would do it through an adb shell). This would require you to have root. I'm not sure of how to get root without modifying your ROM (kind of defeats the purpose of what you're trying to do if we have to change the ROM) but there are usually ways to get a temp root. Not sure how to do it on our phone but maybe someone else can help you with that part. Or maybe do some googling. The dd part I've at least done for the boot partition. Basically what you want to do is open an adb shell and run:
"ls -l /dev/block/platform/msm_sdcc.1/by-name/"
This will give you a list of all the partition name symlinks and show you the block devices they point to. For example, when I was getting boot.img I found that the "boot" symlink pointed to "/dev/block/mmcblk0p7". Find all the partitions you want to image in this list and figure out which block devices they point to.
The next part is to figure out how big each of the partitions is. You can find this in /proc/partitions. So from your adb shell you would run:
"cat /proc/partitions"
This will print out all of your flash block devices (look at the ones you were interested in from above). The 3rd column in this list will be the # of blocks in the partition. I believe the block size is 1k (1024 bytes). For example, my boot partition was 10240 blocks which comes out to 10 Megs, which sounds about right. The 1k assumption also agrees with the total device flash size, which is 7634944 blocks (mmcblk0) which is just under the 8GB they say the phone has. So I'm pretty confident about the block size.
So now we're at the part where things get a little hairy. I'm assuming you've found some way to get root in your adb shell. Be very careful with these dd commands and if you don't know what you're doing, don't do it. You would want to run something like the following:
"dd if=/dev/block/<partition name> of=/storage/sdCard/<name of image file> bs=1024 count=<# of blocks for partition you found in /proc/partions>"
You would do this for each partition you want dumped.
Again, be careful if you decide to try and do any of this stuff (especially with the dd commands, if you mix up the in file and out file you can brick your device). But like I said this worked for me to get boot.img and I was able to extract it and get the kernel and ramdisk. Hope this helps and sorry I don't know more about getting you a temp root without modifying your ROM.
Jeff
Can you send me a screenshot of your about phone screen?
Sent from my SGH-T699 using Tapatalk
hello everyone,
i resurrection this thread so bring some information to pepole who want to backup stock rom so they can flash it back with odin.
i constructed a list of partitions names/partition location nb./partition block size for a refreance of what to backup:
block size partition block location partition name
7634944 /dev/block/mmcblk0 Whole SSD on Device
2048 /dev/block/mmcblk0p5 aboot
6144 /dev/block/mmcblk0p20 backup
10240 /dev/block/mmcblk0p7 boot
860160 /dev/block/mmcblk0p17 cache
13952 /dev/block/mmcblk0p11 efs
10240 /dev/block/mmcblk0p19 fota
3072 /dev/block/mmcblk0p21 fsg
5120 /dev/block/mmcblk0p23 grow
61440 /dev/block/mmcblk0p1 modem
3072 /dev/block/mmcblk0p12 modemst1
3072 /dev/block/mmcblk0p13 modemst2
512 /dev/block/mmcblk0p9 pad
10240 /dev/block/mmcblk0p10 param
8192 /dev/block/mmcblk0p16 persist
10240 /dev/block/mmcblk0p18 recovery
512 /dev/block/mmcblk0p6 rpm
128 /dev/block/mmcblk0p2 sbl1
256 /dev/block/mmcblk0p3 sbl2
512 /dev/block/mmcblk0p4 sbl3
8 /dev/block/mmcblk0p22 ssd
1228800 /dev/block/mmcblk0p14 system
512 /dev/block/mmcblk0p8 tz
5386240 /dev/block/mmcblk0p15 userdata
so all you have to do is to use this command via terminal:
"dd if=/dev/block/<partition name> of=/storage/sdCard/<name of image file> bs=1024 count=<# of blocks for partition>"
you can cnange "sdCard" for "extSdCard" if you wish.
this will make you the raw imgae of all partitions and then you will need to use tar in linux to make a tar.md5 file for odin.
use the commands below in terimanl to do so:
"tar -H ustar -c image1 image2 image3 etc... > package_name.tar"
"md5sum -t package_name.tar >> package_name.tar"
"mv package_name.tar package_name.tar.md5"
remember you will need superuser on you phone to do this, also the commands are without the quotation mark.
the only thing left to know is what partitions you must backup to beable to restore fully to stock with/without data.
i know you should backup the boot/efs/recovery/system partitions for clean stock + userdata/cache if you want your data back.
does anybody know of other critical partitions to backup?
Code:
*** Disclamer
* Your warranty is now void.
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
Hi guys and girls, as you may know it's pretty easy to find here on xda but on other forums (techablets for example) info and files for rooting this tablet, but who has the TCL variant /which is Dual Boot Type C one) will only find outdates files and complex guides; that's the reason why - after spending a lot of time on bootloops and fails trying to figure how the hell modify the boot.img) I finally decided to share what I found here.
First thing first: this guide collects, improves and updates how-to from Laura of techtablets; I also want to thanks @jetfin and @master.pumpgun (aka Tom on techtablets) - they know why!
I will basically divide this guide per two: first section is READY TO FLASH, where you'll find my own boot.img (from and ONLY for the latest available stock build); before flashing this image file PLEASE be sure to check if your version is the same I had when preparing the image; also you should absolutely check the MD5 of all the files you will download from here:
check MD5 on any Linux distro by simply typing
Code:
md5sum /path/to/file/file
on Windows you could maybe use this tool: WinMD5
The second section is DO IT YOURSELF, and it's for users with a different kernel/build version from mine. I'll try to eventually update the boot.img if we will receive any new OTA, which I think will never happen. I'll write the second section as soon as possible, but I can speed work up if requested and if Cube updates
- - - - - - - - - - -
---> READY TO FLASH
Code:
PLEASE NOTE
While the general procedure here reported remains
always correct, the files provided in this part of the
guide - specially the modified boot.img may not work
into your device is the kernel and build version are different
from the one I had, so please go to Settings, About tablet
and check if your specs meet mine:
[B]Model[/B] i15-TCL
[B]Kernel[/B] 3.14.37-x86_64-L1-R517 [email protected] #1
Sat May 7 17:02:18 CST 2016
[B]Build[/B] i15-TCL_V1.0_20160507
If you want to root your i15-TCL there's an high chance you would not need nothing more than backup your data, install drivers and adb/fastboot tools and flash file you will download here! BUT you need to have the same kernel and build as I had when prepared the boot.img file, which is the latest at the moment I'm writing. If you know about a newer version lease notify me and I'll try to process it again.
Last but not least, please note that is a pretty long and detailed Guide, I tried to explain and illustrate every single step, also covering some very common issues you may have, so please don't blame on me if it's a long story to read, I'm sure that a few newbies will appreciate
First thing to do is to backup data you want to restore because we need to unlock the bootloader (unfortunately there's no way to achieve the root without that, I tried everything I could but it's not possible). Also a general backup of all your partitions (both Windows both Android) could help and make you feel more comfortable. To backup partition please refer this thread on techtablets: The big threads of how-tos. Windows users could also have to install the proper Intel driver attached to end of the post.
Once you did that install adb/fastboot:
if you use Windows you can use this tool;
if you use a Linux distro please check if the package android-tools (more info here is available for your distro, otherwise you may have to install the official Android SDK (info about that here; no need Android Studio).
Into your tablet go to Settings / About tablet and press 7 times the Build number fields to enable Developer options; now go Back and tap the new voice Developer option: be sure that the main switch is ON and so the OEM unlocking and the USB debugging ones.
Connect your tablet to your PC, open the command prompt or a Linux shell and type
Code:
adb devices
you should receive an output like
Code:
adb devices
List of devices attached
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
0123456789ABCDEF device
If not, please please stop and check previous steps, but also:
If you use Linux and you see a udev error about permissions you have two solutions: one is running the adb/fastboot by root/sudo, another one is to let udev correctly recognize your idVendor and so your device (always prefer this last way, if possible!), which you can do by following this great mini tutorial on StackOverflow
If you use Windows 64bit try to install the driver attached below; don't know if they are also available for 32bit.
Now you have the basic stuff prepared and you are ready to go to fastboot/bootloader, so this is the last time you could check if your build is the same I had, so please do it if you missed that step before. Once more, the info you read from Settings / About tablet have to be
Code:
[B]Model[/B] i15-TCL
[B]Kernel[/B] 3.14.37-x86_64-L1-R517 [email protected] #1
Sat May 7 17:02:18 CST 2016
[B]Build[/B] i15-TCL_V1.0_20160507
Into your command prompt or shell type
Code:
adb reboot-bootloader
Your device will now go to fastboot mode. You can use your Volume Down / Volume Up to move choose menu commands and Power button to pick one. At the moment you don't need to pick any, so check if you have these two lines in red:
Code:
[COLOR="Red"]SECURE BOOT - disabled
LOCK STATE - unlocked[/COLOR]
If you have these exact lines you can jump to step10. My bootloader (and also Tom one) was already unlocked; others people reported it was locked, I guess it depends from where we bought the device. So, if your bootloader has those two red lines (which means the bootloader is already unlocked) go to step 10. If you have similar lines but in white and with different text, go to next step
CAUTION: this will permanently erase your userdata partition, which is where you store the applications and their data; you may also have there downloads, music, videos and photos so BE SURE you updated your relevant stuff!! If want to go further type into your command prompt/shell
Code:
fastboot devices
and check if you have the right output, that is
Code:
0123456789ABCDEF fastboot
If so, go on by typing:
Code:
fastboot oem unlock
This will erase your data and finally unlock the bootloader. you'll see something like that
Code:
...
OKAY
[ 0.162s] finished. total time: 0.162s
Now reboot the bootloader: move between the menu with the Volume rockers and press Power when you selected the Restart bootloader command. Wait for reboot, choose Android and you are on bootloader / fastboot mode again. Now you should absolutely have those two lines in red from step 6.
Download modified boot.img rootboot_mod.img and once finished PLEASE CHECK THE MD5 of the file: it should ABSOLUTELY match this one: 53cc4b08b123489e7c73cb013742f35d
Type on command prompt/shell
Code:
fastboot flash boot /path/to/your/file/rootmod_boot.img
Let the magic happen!
Now download the custom TWRP recovery (courtesy of @vampirefo), check if MD5 is correct (3c05a8704f5a77e20a45364c7a822a2b) and flash it with
Code:
fastboot flash recovery /path/to/your/file/i15_recovery.img
Use the Volume rockers to pick the Recovery mode command and press Power to go to recovery. Swipe to allow modification, go to Mount and tap the System checkbox
Download the latest SuperSu recovery flashable version available here, check the MD5 reported in that page and then from your tablet in recovery tap Advanced and then Adb Sideload. Swipe to let sideload mode start and type into your command prompt / shell (and change the path /opt/android-sdk/platform-tools/ with the path where YOU installed adb/fasboot)
Code:
adb sideload /path/to/your/file/supersu_file_you_downloaded.zip
If you are on Linux and you have udev permissions issues again when sideloading proceed like that
Code:
cd /opt/android-sdk/platform-tools
su
Password:
[email protected]*********:/opt/android-sdk/platform-tools# ./adb kill-server
[email protected]*********:/opt/android-sdk/platform-tools# ./adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]*********:/opt/android-sdk/platform-tools# ./adb devices
List of devices attached
0123456789ABCDEF sideload
[email protected]*********:/opt/android-sdk/platform-tools# ./adb sideload /path/to/your/file/supersu_file_you_downloaded.zip
If you have issues on Windows or still having issues on Linux you can always copy the SuperSu zip to a USB Pen and attach the pen to the tablet using the OTG cable or paste the file to a micro SD.
Reboot your device and it's done!
Doing that instead of using the well know root.bat is much better - IMHO - because we don't have to reboot the device two times and we don't have to uninstall SuperSu and flash a new version to update binaries (SuperSu it is not able to update the binaries by itself, nor by recovery nor by app. Also remember that when a new version os SuperSU will be available: Open SuperSu app, go to Settings and tap on Reinstall. Wait for it to finish and shut down the device. Go to bootloader (or use adb when the device is still on), download latest updated flashable SuperSu zip and flash via recovery).
DOWNLOADS SECTION
rootmod_boot.img
i15_recovery.img
- - - - - - - - - - -
---> DO IT YOURSELF
WARNING: to do that you need a Linux machine / Virtual machine!
First, be sure to have adb and fastboot working; if issues read the first section for common solutions; you should also have already unlocked your bootloader.
If you did not create a dd backup of your partition I recommend once again to do that; you should at least backup android_boot, android_recovery, android_system (but also consider android_bootloader and android_bootloader2). Please note that to check partition in a human readable mode you can use
Code:
adb shell
ls -las /dev/boot/by-name/*
Now we should create our working folders environment; you can do that by yourself or follow my suggstions.
Open a terminal as normal user; you should be in your home folder; launch the following commands one by one
Code:
mkdir -p Android/iWork10/_working/ ; cd Android/iWork10
mkdir _stockimg ; cd _stockimg
adb shell
su
dd if=/dev/block/by-name/android_boot of=/sdcard/boot.img
cd /sdcard/
md5sum boot.img > bootmd5
exit
please note that you could have to execute the exit command 2 times; just be sure to go back to your terminal into your
Code:
/home/USER/Android/iWOrk10/_stockimg
if su is still not available try to dd the same; for me the bootloader was already unlocked and I had no issue to create the dd image
Then
Code:
adb pull /sdcard/boot.img
adb pull /sdcard/bootmd5
and check if MD5 is OK with
Code:
md5sum -c bootmd5
if error recreate the boot image file, if OK go on.
Now we need to download and extract the Android Bootimg Tools; click this link and save it into the
Code:
/home/USER/Android/
folder; once downloaded (the file it's less than 8 kB) we'll extract the two file in the _working dir so to have all the stuff organized; please note that it's important to keep files organized because we'll decompress and re-compress the boot partition and the kernel it contains; if we don't move files appropriately unneeded stuff could go into the kernel! So please try to understand the process or to follow my steps
Code:
cd ../_working/
tar -zxvf ../../android_bootimg_tools.tar.gz
mkdir bootimg
./unpackbootimg -i ../_stockimg/boot.img -o bootimg/
As you can see we unpacked the stock boot.img to the folder bootimg we just created..
Now let's extract the ramdisk, that is where we were pointing from the start..
Code:
cd bootimg ; mkdir ramdisk ; cd ramdisk
gunzip -c ../boot.img-ramdisk.gz | cpio -i
Now if you are familiar with nano or pico terminal continue on terminal to apply the following mods, otherwise open your file manager to the ramdisk folder, then open the default.prop file and change
Code:
ro.secure=1
to
Code:
ro.secure=0
Save and close the editor.
Open the init.rc file and change
Code:
service media /system/bin/mediaserver
class main
user [COLOR="Red"]media[/COLOR]
to
Code:
service media /system/bin/mediaserver
class main
user [COLOR="Red"]root[/COLOR]
Please note here that if your bootloader was unlocked without your intervention you could have already user root (I had). In that case just leave as it is and close, otherwise save and close.
Go back to your terminal, you should still be into the ramdisk folder, if not navigate with cd to go to that folder and then
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Now we have our new ramdisk; at this point we need to open the boot.img-cmdline file that is located into the bootimg folder and copy its content, then go back to the terminal; the terminal should be still in ramdisk folder, so
Code:
cd ..\..\
and we are into the _working folder.
Now the last command, that you CANNOT simply copy and paste. The command is something like that (hold on, don't execute it)
Code:
./mkbootimg --kernel bootimg/boot.img-zImage --ramdisk bootimg/newramdisk.cpio.gz --cmdline 'CONTENT OF YOUR boot.img-cmdline CONTENT HERE; PUT IT BETWEEN SINGLE ' BOTH AT THE START BOTH AT THE END' -o root_boot.img
Please note the double -- for kernel, ramdisk and cmdline options (while single - for -o that stays for output) and also note the single ' peaks that contain the boot.img-cmdline content.. So in my case it will be:
Code:
./mkbootimg --kernel bootimg/boot.img-zImage --ramdisk bootimg/newramdisk.cpio.gz --cmdline 'loglevel=5 androidboot.hardware=cht_cr_mrd_w firmware_class.path=/system/etc/firmware i915.fastboot=1 memmap=4M$0x5c400000 vga=current i915.modeset=1 drm.vblankoffdelay=1 enforcing=0 androidboot.selinux=permissive console=ttyS0,115200n8 bootboost=1 pm_suspend_debug=1 pstore.backend=ramoops' -o ../root_boot.img
BUT PLEASE DON'T COPY AND PASTE THIS ONE; JUST USE YOUR boot.img-cmdline FILE (I'm pretty sure they are identical but cannot be sure, SO USE YOURS)
If the command doesn't give errors or the standard output that describe the usage of a linux command (so like usage: mkbootimg --kernel <filename> --ramdisk <filename> - this means you missed something) we are done, we just need to flash it and root. So we now have our modified boot image which will let the tablet boot a rooted OS without bootloop.
If you haven't do it already go to download latest Recovery Flashable zip of SuperSU from SuperSu webpage and the custom TWRP recovery for this device that you find in the first section (also check MD5) and copy both to your internal of external sdcard (if you are not familiar with sideload)
Reboot your device to bootloader with
Code:
adb reboot-bootloader
Once it's there,
Code:
fastboot flash boot /home/USER/Android/iWork10/root_boot.img
fastboot flash recovery /path/where/you/downloaded/recovery.img
Now use the volume rockers to pick RECOVERY MODE option and press the Power button. The device will boot the TWRP recovery; allow system modifications when asked and finally flash the SuperSu zip file you downloaded and copied to the tablet (or use adb sideload /path/to/supersu/into/your/pc/supersufile.zip)
You may need to adjust settings in TWRP (timezone and language), then reboot the system and you should have rooted your i15-TCL!
It's easy, isn't it?
PLEASE NOTE: If you have errors like adb, fastboot not recognizing your device, don't ask but read the other section where I explain the most common solution for Windows and Linux; same if you don't find links for recovery, SuperSU or other read the first section, thanks!
- - - - - - - - - - -
THANKS
@jetfin for providing a lot of goodies that saved my ****** last month (wish you all the best for the next future mate!)
@master.pumpgun (aka Tom on techtablets - amazing guy! :good
@vampirefo for custom TWRP for this device
Laura - for all the info she's made available for this device
Great job mate!
It seems very analytical and very useful for people who need a step by step guide.
Unfortunately it requires a full wipe of user data, so for now I am not willing to try this guide.
Sent from my i15-TCL using Tapatalk
RASTAVIPER said:
Great job mate!
It seems very analytical and very useful for people who need a step by step guide.
Unfortunately it requires a full wipe of user data, so for now I am not willing to try this guide.
Sent from my i15-TCL using Tapatalk
Click to expand...
Click to collapse
Well, I feel you, unlocking is always annoying but there are apps which let you backup everything.
I couldn't live without root + Link2SD into the cube!
Thanks for the nice words ?
Inviato dal mio Nexus 7 utilizzando Tapatalk
Hi brainvison,
it`s a nice, correct and clear tutorial, many thanks.
Only one question
Fortunately I have an unlocked bootloader, then I`ll do it from step 10, but I have a same kernel and build version (3.14.37/x86_64-L1-R517 and V1.0) but the date of this version is different (20160913).
What do you suggest, try it? Or could you help me to create a new version of the boot.img, please?
Nice regards
Peter
brainvision said:
Code:
PLEASE NOTE
While the general procedure here reported remains
always correct, the files provided in this part of the
guide - specially the modified boot.img may not work
into your device is the kernel and build version are different
from the one I had, so please go to Settings, About tablet
and check if your specs meet mine:
[B]Model[/B] i15-TCL
[B]Kernel[/B] 3.14.37-x86_64-L1-R517 [email protected] #1
Sat May 7 17:02:18 CST 2016
[B]Build[/B] i15-TCL_V1.0_20160507
Click to expand...
Click to collapse
rpeter said:
Hi brainvison,
it`s a nice, correct and clear tutorial, many thanks.
Only one question
Fortunately I have an unlocked bootloader, then I`ll do it from step 10, but I have a same kernel and build version (3.14.37/x86_64-L1-R517 and V1.0) but the date of this version is different (20160913).
What do you suggest, try it? Or could you help me to create a new version of the boot.img, please?
Nice regards
Peter
Click to expand...
Click to collapse
both kernel and build dates are different, aren't them?
I'll try to write the missing section as soon as possible, don't worry..
In the meantime could you please check a few things that could help to understand a few things?
If your bootloader is unlocked you should have no issue doing that; assuming you already have adb working, open a terminal and execute this commands (just "read" commands, no mods here)
Code:
adb shell
uname -a
cat default.prop
If errors try to execute adb root (this does NOT root, it just use adb as root user, it should work with the unlocked bootloader) before adb shell and if possible please report me the output from unameand cat
EDIT: also my advice is to backup your system partitions so to able to go back to stock if needed; at least partitions
Code:
android_boot
android_bootloader
android_bootloader2
android_recovery
android_system
To do that you could check Laura's thread from techtablets or use
Code:
dd if=/dev/by-name/your_partition of=/sdcard/your-partition.img
the if= option is where you choose the partition to backup while the of= one is the resulting file that will be created (an image .img file)
If you agree you could also upload those somewhere on the cloud so we could use them, too, it would be interesting to see what changes.. Naturally the partition I suggested do not contain any personal file, no worry about that (your data is on the android_userdata - or _data, don't remember the name here).
EDIT2: you'll need a Linux machine to mod your boot.img partition, do you have one?
brainvision said:
both kernel and build dates are different, aren't them? yes, both of the are the same date:20160913
the build.prop is:
Code:
[email protected]:/system # cat build.prop
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=LMY47I
ro.build.display.id=i15-TCL_V1.0_20160913
ro.build.version.incremental=eng.softteam.20160913.102513
ro.build.version.sdk=22
ro.build.version.codename=REL
ro.build.version.all_codenames=REL
ro.build.version.release=5.1
ro.build.version.security_patch=2016-03-01
ro.build.version.base_os=
ro.build.date=Tue Sep 13 10:26:20 CST 2016
ro.build.date.utc=1473733580
ro.build.type=userdebug
ro.build.user=softteam
ro.build.host=pdd-build
ro.build.tags=release-keys
ro.build.flavor=cht_cr_mrd_w-userdebug
ro.product.model=i15-TCL
ro.product.brand=i15-TCL
ro.product.name=cht_cr_mrd_w
ro.product.device=i15-TCL
ro.product.board=i15-TCL
# ro.product.cpu.abi and ro.product.cpu.abi2 are obsolete,
# use ro.product.cpu.abilist instead.
ro.product.cpu.abi=x86
ro.product.cpu.abilist=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist32=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist64=
ro.product.manufacturer=i15-TCL
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=gmin
# ro.build.product is obsolete; use ro.product.device
ro.build.product=cht_cr_mrd_w
# Do not try to parse description, fingerprint, or thumbprint
ro.build.description=cht_cr_mrd_w-userdebug 5.1 LMY47I eng.softteam.20160913.102513 release-keys
ro.build.fingerprint=intel/cht_cr_mrd_w/cht_cr_mrd_w:5.1/LMY47I/softteam09131026:userdebug/release-keys
ro.build.characteristics=tablet
# end build properties
#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.dalvik.vm.isa.arm=x86
ro.enable.native.bridge.exec=1
sys.powerctl.no.shutdown=1
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=100m
dalvik.vm.heapsize=174m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=512k
dalvik.vm.heapmaxfree=8m
ro.opengles.version=196609
ro.setupwizard.mode=OPTIONAL
ro.com.google.gmsversion=5.1_r1
ro.gnss.sv.status=true
ro.hwui.texture_cache_size=24.0f
ro.hwui.text_large_cache_width=2048
ro.hwui.text_large_cache_height=512
drm.service.enabled=true
keyguard.no_require_sim=true
ro.com.android.dataroaming=true
ro.com.android.dateformat=MM-dd-yyyy
ro.config.ringtone=Ring_Synth_04.ogg
ro.config.notification_sound=pixiedust.ogg
ro.carrier=unknown
ro.config.alarm_alert=Alarm_Classic.ogg
persist.sys.language=zh
persist.sys.country=CN
persist.sys.timezone=Asia/Shanghai
persist.sys.dalvik.vm.lib.2=libart.so
dalvik.vm.isa.x86.features=sse4_2,aes_in,popcnt,movbe
dalvik.vm.lockprof.threshold=500
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt
# begin fota properties
ro.fota.platform=IntelZ3735F_5.1
ro.fota.id=mac
ro.fota.type=pad_phone
ro.fota.oem=hampoo-cherrytrail_5.1
ro.fota.device=i15-TCL
ro.fota.version=i15-TCL_V1.0_20160913
# end fota properties
[email protected]:/system #
I'll try to write the missing section as soon as possible, don't worry..
Many thanks
Code:
adb shell
uname -a
cat default.prop
the adb root and the cat is ok, but the uname is not found
the output of the cat is:
Code:
127|[email protected]:/ # cat default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.sf.lcd_density=240
ro.frp.pst=/dev/block/by-name/android_persistent
persist.intel.ogl.username=Developer
persist.intel.ogl.debug=/data/ufo.prop
persist.intel.ogl.dumpdebugvars=1
ro.ufo.use_msync=1
ro.ufo.use_coreu=1
wifi.interface=wlan0
persist.service.apklogfs.enable=1
persist.core.enabled=0
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=1
ro.modules.location=/lib/modules
ro.dalvik.vm.native.bridge=libhoudini.so
persist.sys.usb.config=mtp,adb
persist.nomodem_ui=true
ro.zygote=zygote32
dalvik.vm.dex2oat-Xms=64m
dalvik.vm.dex2oat-Xmx=256m
dalvik.vm.image-dex2oat-Xms=64m
dalvik.vm.image-dex2oat-Xmx=64m
[email protected]:/ #
EDIT: also my advice is to backup your system partitions so to able to go back to stock if needed; at least partitions
Code:
android_boot
android_bootloader
android_bootloader2
android_recovery
android_system
All of my partitions expect the largest one(maybe windows) were backed up to sd with dd
If you agree you could also upload those somewhere on the cloud so we could use them, too, it would be interesting to see what changes.. Naturally the partition I suggested do not contain any personal file, no worry about that (your data is on the android_userdata - or _data, don't remember the name here).
I will upload it to somewhere, but which partitions are you need (i don't no clearly, how can I determinate, which partition is the boot, bootloader, ...)
the outputs of the /proc/partitions are the following:
Code:
[email protected]:/ # cat /proc/partitions
major minor #blocks name
254 0 102400 zram0
179 0 61071360 mmcblk0
179 1 102400 mmcblk0p1
179 2 102400 mmcblk0p2
179 3 30720 mmcblk0p3
179 4 30720 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 16384 mmcblk0p6
179 7 2621440 mmcblk0p7
179 8 262144 mmcblk0p8
179 9 8388608 mmcblk0p9
179 10 1024 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 102400 mmcblk0p12
179 13 16384 mmcblk0p13
179 14 48361472 mmcblk0p14
179 15 1024000 mmcblk0p15
179 48 4096 mmcblk0rpmb
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 64 15671296 mmcblk1
179 65 15667200 mmcblk1p1
253 0 2600764 dm-0
maybe the *p3 is the bootloader, the *p14 is the windows, maybe the *p9 included the data and *p7 is the system, but don't know, which one is the boot, bootloader2, recovery
EDIT2: you'll need a Linux machine to mod your boot.img partition, do you have one?
Click to expand...
Click to collapse
yes, I have, a debian.
One question, if we have any problem with the upload the modified bootloader, how can i restore the old one (how can I upload (which method, adb, fastboot, or the phone flash?) an original bootloader, if we have a problem with the modded bootloader)
Have you link(s) with the full original windows and andoid image of the i15-tcl? I found to i15-t, i15-td, but not for this version...
Nice regards
Peter
i have the same software version as rpeter. When i first boot in fastboot my bootloader was unlocked and secure boot was disabled. Itried flash twrp and it was succesful. Next i downloaded superSu zip from official website and i flashed it. After reboot i stuck at bootlogo. Can you share me a system image to restore?
The mmcblk0p9 partition is the system? I will share it as soon as possible.
07 is system. 09 is data partition.
https://drive.google.com/file/d/0B_QRR9kog1iZQ2ZaNzdZenQ4MkE/view?usp=sharing
@rpeter I'll read your long reply asap, now just want to tell you that to check partition in a human readable way you should use
Code:
ls -las /dev/block/by-name/*
the partition I would like you to share are
Code:
android_boot
android_bootloader
android_bootloader2
android_system
android_recovery
when using dd of course as I told you can directly point to that name convention (which are nothing but symbolic link) so
Code:
dd if=/dev/block/by-name/android_boot of=/sdcard/android_boot.img
this is for the boot partition, the other the same..
also please before uploading to cloud check the MD5 so we could verify it before installing
are you sure you wrote uname -a the right way? It's weird you don't have it...
About restoration, you could use fastboot in future, I tried it by myself.. the most important are
Code:
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash system system.img
I don't think we'll ever need the two bootloader restoration, it's just to go extremely safe but I still don't find a reason to flash them.. But backup anyway!
EDIT: please note the .img extension for the of= part of the dd command!
@boberq sorry for your issue but I have to say that it was obvious: it's not plenty of guides and how-to about this tablet but the few available are also easy to find, and they all clearly state that you need to modify the boot image before rooting, otherwise as you know now, bootloop!
so, if you guys need to immediately root you can send me the boot.img file and I do it for you, otherwise you can wait and do it by yourself - I'm going to write the how-to right now, it should be ready for tomorrow, I guess..
EDIT and yes, we don't have any full restoation image like for other variants, I asked them on Twitter https://twitter.com/CubeHeping (it seems this is their official account that I found via www.51cube.com) - please do the same, maybe they will listen to us
I flashed i15 td rom and it works without auto rotation. If rpeter share images i want flashthe stock.
---------- Post added at 12:52 PM ---------- Previous post was at 12:44 PM ----------
I flashed a i15td rom and everything is fine without auto rotate. Rpeter please share boot and system images, they help me to restore the stock rom.
Ps After first boot if i want enter to recovery , it show red triangle with green android. There was any recovery.
boberq said:
I flashed i15 td rom and it works without auto rotation. If rpeter share images i want flashthe stock.
---------- Post added at 12:52 PM ---------- Previous post was at 12:44 PM ----------
I flashed a i15td rom and everything is fine without auto rotate. Rpeter please share boot and system images, they help me to restore the stock rom.
Ps After first boot if i want enter to recovery , it show red triangle with green android. There was any recovery.
Click to expand...
Click to collapse
stock recovery is not a real recovery there.. Red triangle is the right thing.. BUT if you flashed the custom TWRP with
Code:
fastboot flash recovery recovery.img
you should have noticed that the process failed.. I don't remember the exact output but you should have seen FAILED instead of SUCCESS. If flash succeed you also need stock recovery, I guess, otherwise it should still bootloop after system restore..
@brainvision
Has anything changed about rooting?
I remember that the process was involving resetting in order to unlock bootloader, etc
Sent from my m1 note using Tapatalk
RASTAVIPER said:
@brainvision
Has anything changed about rooting?
I remember that the process was involving resetting in order to unlock bootloader, etc
Sent from my m1 note using Tapatalk
Click to expand...
Click to collapse
nope, and it never will in that direction..
you should definitively make a backup, the more you'll wait the worst it'll be!
I flashed twrp and from it i want flash supersu and i get bootloop. After this i flashed i15td rom andeverything works fine. So can i flash boot,recovery and system image and get stock without root? Or should i flash it using intel flash tool?
boberq said:
I flashed twrp and from it i want flash supersu and i get bootloop. After this i flashed i15td rom andeverything works fine. So can i flash boot,recovery and system image and get stock without root? Or should i flash it using intel flash tool?
Click to expand...
Click to collapse
you can flash them with fastboot indeed and then root again, I finished writing my how-to, I'm formatting it and update the first post in an hour max..
Never looked at Intel Flash Tool, I don't know if it permits the flash of a single partition or if you need a full image provided by OEM, can't help with that..
So i'm waiting for original images from rpeter and i'm goind to flash it. I have a twrp backup with original 20160913 firmware but after bootloop. I can sare it but i think it isnt usefull.
PS
Brainvision , can you share me your original partition images for i15TCL from May? I think it will repair my autorotation.
boberq said:
So i'm waiting for original images from rpeter and i'm goind to flash it. I have a twrp backup with original 20160913 firmware but after bootloop. I can sare it but i think it isnt usefull.
PS
Brainvision , can you share me your original partition images for i15TCL from May? I think it will repair my autorotation.
Click to expand...
Click to collapse
I do NOT recommend you to flash that because you will completely mess things up, having boot, recovery and kernel with a build date and system with a different one! You went to fast on rooting your device without reading stuff, now I suggest you to wait for @rpeter images - but anyway here it is system.img https://mega.nz/#!YBdw1bIT!GibOWLBNyXAhwEiEdXIV3JKKdMM9gXzLIYvppKn0Bgs
EDIT: guys I updated OP with the missing sectioon, please click thanks if you find it useful..
@rpeter before rooting remember to backup partition with dd, then upload when you can but backup before rooting!
if you have suggestion for the guide or you think something is not so clear please tell me that I'll try to improve..
brainvision, boberq, I'm so sorry, yesterday is one of my longest working day...
My gdrive is currently full, bu I created a dedicated place for yours in my server.
The link is: http://rpeter.dyndns.info/xda
user: xda_users
pwd: i15-tcl
It's included all partitions compressed and uncompressed version expect p9 and p14 (data and windows) and the md5 checksum file.
The output of the "identification" is here:
Code:
127|[email protected]:/ # ls -las /dev/block/by-name/*
lrwxrwxrwx root root 2016-11-12 12:21 Basic_data_partition -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2016-11-12 12:21 EFI_system_partition -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2016-11-12 12:21 Microsoft_reserved_partition -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2016-11-12 12:21 android_boot -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader2 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2016-11-12 12:21 android_cache -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2016-11-12 12:21 android_config -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2016-11-12 12:21 android_data -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2016-11-12 12:21 android_metadata -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2016-11-12 12:21 android_misc -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2016-11-12 12:21 android_persistent -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2016-11-12 12:21 android_recovery -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2016-11-12 12:21 android_system -> /dev/block/mmcblk0p7
[email protected]:/ #
I will put it somewhere fastest place, when I have enough time to do it
Nice regards
Peter
rpeter said:
brainvision, boberq, I'm so sorry, yesterday is one of my longest working day...
My gdrive is currently full, bu I created a dedicated place for yours in my server.
The link is: http://rpeter.dyndns.info/xda
user: xda_users
pwd: i15-tcl
It's included all partitions compressed and uncompressed version expect p9 and p14 (data and windows) and the md5 checksum file.
The output of the "identification" is here:
Code:
127|[email protected]:/ # ls -las /dev/block/by-name/*
lrwxrwxrwx root root 2016-11-12 12:21 Basic_data_partition -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2016-11-12 12:21 EFI_system_partition -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2016-11-12 12:21 Microsoft_reserved_partition -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2016-11-12 12:21 android_boot -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader2 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2016-11-12 12:21 android_cache -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2016-11-12 12:21 android_config -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2016-11-12 12:21 android_data -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2016-11-12 12:21 android_metadata -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2016-11-12 12:21 android_misc -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2016-11-12 12:21 android_persistent -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2016-11-12 12:21 android_recovery -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2016-11-12 12:21 android_system -> /dev/block/mmcblk0p7
[email protected]:/ #
I will put it somewhere fastest place, when I have enough time to do it
Nice regards
Peter
Click to expand...
Click to collapse
great work mate!
Thanks a lot. As you may have read I updated the OP with the new section, hope you'll find useful and clear enough, if not don't hesitate to ask, it will be a pleasure to help and to improve the how-to
Important:
Now since Official Oreo is out, you can simply update to Official Oreo via fastboot and your IMEI will be restored.
This method will not work if you have restored other device's persist from some Youtube video or some Internet guide.
Read post #3 if you have restored some other persist and do not have a backup of your original persist.
For those who can't read this much, here is a better guide for you:
Hello everyone, this is a guide for solving the problem for IMEI = 0 on Moto G4/Plus which is caused after flashing stock ROM.
I got this problem last week and was constantly researching for the solution to this problem for the past 5 days and finally, I was able to get my IMEI back on my Moto G4 Plus (XT1643).
Note: I will be using stock firmware and stock ROM interchangeably in this thread as a lot of people consider it the same so don't get confused since I am by no means referring to the /firmware partition.
There are two common and major problems which occur while flashing custom/stock ROMs:
1. IMEI = Unknown and Baseband = Unknown
2. IMEI = 0
1st Problem:
Reason: You flashed the firmware/stock ROM which wasn't meant for your device.
Solution: Flash the firmware which is made for your device like XT1621 or XT1643, etc.
2nd Problem:
This is a major problem and there are two reasons for this:
1. Mess up your persist partition.
2. fastboot erase all command.
If your problem is caused by the first reason, it might be possible to fix it.
However, if the problem is caused by the second reason, I'm sorry I don't know if a solution to this problem exists.
Firstly you need to check if your device still has IMEI intact or not. For that use the following command through fastboot in the bootloader mode:
Code:
fastboot getvar imei
If the command returns an IMEI, it means that the IMEI is not completely lost and it can be recovered.
However, if the command returns IMEI as 0, then there are two reasons:
1. Either you flashed the bootloader that wasn't meant for your device. This can be solved by flashing the correct bootloader which is made for your device again by the command:
Code:
fastboot flash bootloader bootloader.img
2. If you have flashed the correct bootloader that is meant for your device and facing this issue, I'm sorry I don't think there is a solution to this problem. This problem is either caused by fastboot erase all command (which erases everything like IMEI from the device's motherboard or the place where IMEI is permanently stored) or some hardware issue.
Here is a little explanation:
Device specific or device unique IDs are stored in a separate place in the device like the motherboard or some other place which I am unaware of.
When EFS partition is created, it picks up the IMEI from that unique place in the device like the motherboard (or some other place which I am unaware of) where the IMEI is stored.
On every reboot, EFS partition is checked and if it does not exists, the Android system by default creates it.
When we flash stock ROM, we use the following commands:
Code:
fastboot erase modemst1
fastboot erase modemst2
These commands wipe the EFS partition and on rebooting, EFS partition is recreated.
But, in some cases, the EFS partition is not able to regenerate IMEI or the Android system is unable to recreate it and so we are left with IMEI = 0.
Here is a detailed explanation regarding this issue:
NZedPred said:
4) Explanation
4a) What happened to persist.
To understand what happened, you need to know a few things about filesystem permissions in Linux. Files and folders have user and group ownership, and permissions. Examples of owners are the system, root, user, etc. Examples of permissions are read access, write access, execute access. The permissions are applied at three levels 1) the user, 2) the group, 3) everyone else.
@rachitrawat's investigation into the failures showed that the issue was relating to the persist partition, specifically some files dhob.bin etc that are under the rfs sub folder in this partition. Under stock, these files/folders are owned by a user called rfs, and have group ownership under a group also called rfs. Additionally, the permissions on these files/folders are limited - only the rfs user can read/write/execute these files. Other users, groups, or everyone else, cannot access the files.
There was a change in the Oreo roms. If you flash and boot into an Oreo rom, and you look at the permissions/ownership, you will see that a user and group oem_2951 owns the rfs folder, and a group oem_2952 owns the hlos_rfs folder. Now this is a different name, but on its own, a different name does not mean different ownership.
In Linux, all users and groups are assigned an ID, i.e. a number. So something happened in lineage that changed the user IDs that are applied to the rfs folder.
If you look at the ownership of persist files/folders within TWRP, you will see that a STOCK PERSIST has the owner of the rfs folder as rfs_old. Similarly in TWRP, a LINEAGE PERSIST has the owner of the rfs folder as rfs. So TWRP is seeing owners differently again to stock and Lineage. Trying to run the above commands in TWRP will not fix the issue, as it will use ID 2951 for the user rfs, but we need it to be 3012 in stock (which TWRP sees as rfs_old).
In addition to the rfs folder, there is also another folder that is impacted - hlos_rfs. Its user owner is rfs, but its group owner if rfs_shared. A stock rfs_shared is shown as rfs_shared_o in TWRP. It appears that this folder is not as important in getting the IMEI back, but I have included the commands to restore ownership, to ensure there are no future errors.
4b) What happened to IMEI.
Despite the issue above, many people who flashed Oreo roms would have had no problems (other than I guess, bugs in the roms themselves). The change of ownership of the rfs folder didn't change the actual file content, so essentially all is intact. In fact, I verified that my dhob.bin and other files had the same md5sum in stock and lineage persist.
The issue of the IMEI changing to zero has only happened when people have flashed Stock roms. All of the guides that I have seen, have included the following commands (and equivalent commands have been included in the TWRP flashable stock builds as well):
Code:
fastboot erase modemst1
fastboot erase modemst2
The partitions modemst1 and modemst2 are your EFS. Normally, if your persist is pure stock, if either is erased, the modem re-creates them. But, referring to the above about permissions, if the rfs user (which is presumably used by the modem) cannot access the files (because the owner of the files is someone else, and the permissions on the files mean that only the owner can access them), then the modem cannot recreate the EFS, and the IMEI is left as zero.
Click to expand...
Click to collapse
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Solution:
I have made a youtube video for this which just shows how to fix the issue and does not goes into explanation of the problem as well as the solution. Here is the link: Moto G4/G4 Plus IMEI=0 fix
Pre-requisites:
You must be on Stock Nougat 7.0
You must be rooted (install Elemental-X kernel first and then flash Magisk otherwise you will have boot issues)
You must be on your own persist
Terminal app or adb drivers in PC/Laptop
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Step 1: Check if there is a problem with persist
Note: The below commands are to be typed in a terminal app or adb shell.
Q) How to type in adb shell?
A) Open command prompt in the folder where you have adb and fastboot installed and type:
Code:
adb shell
So lets start now!
Code:
su
This command it to get root access for the terminal/shell. Grant the root access and you will see that the $ symbol is replaced with # symbol which means that root access has been granted.
Code:
ls -l /persist
If your presist has some problem, then you can see the following as the output.
Code:
athene_f:/ # ls -l /persist
total 176
drwxrwx--- 2 system system 4096 2018-10-21 07:40 alarm
drwxr-xr-x 2 mot_pwric mot_pwric 4096 1969-12-31 19:02 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 2017-01-12 03:35 bluetooth
drwxr-xr-x 2 mot_tcmd bluetooth 4096 1969-12-31 19:02 bt
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 camera
drwxr-xr-x 2 root root 4096 2016-07-31 00:43 coresight
drwx------ 5 system system 4096 2017-01-12 05:21 data
drwxrwx--- 2 system graphics 4096 1969-12-31 19:02 display
drwxrwx--- 2 system system 4096 1969-12-31 19:02 drm
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1970-01-01 06:48 factory
[COLOR="red"]drwxrwx--- 3 2951 2952 4096 1969-12-31 19:02 hlos_rfs[/COLOR]
drwx------ 2 root root 4096 1969-12-31 19:00 lost+found
drwxrwx--- 2 radio radio 4096 2016-08-04 20:26 mdm
drwxrwx--- 3 system system 4096 2017-11-09 16:30 misc
drwxrwx--- 2 system system 4096 1970-02-11 17:39 properties
drwxr-xr-x 8 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 public
[COLOR="red"]drwx------ 6 2951 2951 4096 1969-12-31 19:02 rfs[/COLOR]
drwxrws--- 2 mot_tpapi mot_tpapi 4096 2016-11-17 16:38 security
drwxrwxr-x 2 system system 4096 2016-07-31 00:43 sensors
drwxrwx--- 2 system system 4096 2018-09-10 18:13 time
drwxr-xr-x 2 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 wifi
drwxrwxr-x 2 mot_drm mot_drm 4096 1969-12-31 19:02 wmdrm
athene_f:/ #
You can see system instead of these red number if you flash Soak Test before flashing Stock ROM, so no worries, as the process will remain the same.
As it can be seen in the red part, the owner of rfs folder is a number (2951) which means that the system is unable to identify its real owner.
Also the owner of hlos_rfs folder is a number too (2952) which also means that the system is unable to identity its real owner.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Step 2: Check for the key persist files
Code:
find /persist -type f
If you run the above command, you will see something similar to this:
Code:
athene_f:/ # find /persist -type f
/persist/coresight/qdss.agent.sh
/persist/coresight/qdss.config.sh
/persist/coresight/qdss.functions.sh
/persist/sensors/sensors_settings
/persist/data/sfs/6lgxCka66cxdsueYeHhCqx+j1DI_
/persist/data/sfs/VsxbuQew8Rbt0TRZjDAX8S9tV+M_
/persist/data/sfs/KfLHQpS5zKuygZcMelQOTtWzBvw_
/persist/data/sfs/R9+zCYj56-AHybZuQCWLm2H46E4_
/persist/data/sfs/NjJIuGH0j7kE08PFwp1yw+BminY_
/persist/data/sfs/7pU6SoXdsBUbDsxRiZOHNIjPVtw_
/persist/data/sfs/yLawqeQeY8AQGJmo46PVJbfYVxY_
/persist/data/tz/tz_counter
/persist/data/tz/tz_counter.bak
/persist/data/app_g/wv_usage
/persist/camera/focus/offset_cal
/persist/camera/ledcal/rear
/persist/factory/audio/temp
/persist/factory/audio/cnt
/persist/factory/audio/acc
/persist/factory/audio/f0
/persist/factory/audio/ref_diff
/persist/factory/fti
/persist/public/hiddenmenu/data/mobile_data_rx
/persist/public/hiddenmenu/data/mobile_data_tx
/persist/public/hiddenmenu/data/wifi_data_rx
/persist/public/hiddenmenu/data/wifi_data_tx
/persist/public/hiddenmenu/data/factoryreset_time
/persist/public/hiddenmenu/data/activation_date
/persist/public/hiddenmenu/life_calls
/persist/public/hiddenmenu/life_timer
/persist/security/18.bin
/persist/mdm/oma_dm_update
/persist/.bt_nv.bin
/persist/rfs/shared/server_info.txt
/persist/rfs/msm/mpss/datablock/id_00
/persist/rfs/msm/mpss/datablock/id_01
/persist/rfs/msm/mpss/server_check.txt
[COLOR="Red"]/persist/rfs/msm/mpss/dhob.bin
/persist/rfs/msm/mpss/shob.bin[/COLOR]
[COLOR="Green"]/persist/rfs/msm/mpss/dhob.bin.bak[/COLOR]
/persist/rfs/msm/adsp/server_check.txt
/persist/bluetooth/.bt_nv.bin
/persist/time/ats_1
/persist/time/ats_2
/persist/time/ats_12
/persist/time/ats_13
/persist/time/ats_15
/persist/time/ats_16
/persist/.twrps
athene_f:/ #
Note: The key files here are dhob.bin, shob.bin, id_00 and id_01.
Your IMEI is stored in id_00 (first IMEI) and id_01 (second IMEI)
dhob.bin and shob.bin are responsible to create the EFS partition.
Note: If you do not have dhob.bin.bak, you will still be able to get your IMEI back (tested and confirmed working on Moto G4 Plus(athene)), however if you have some other device like Moto G5 Plus(potter) or Moto G5s Plus(sanders), you cannot get your IMEI back with this method however trying won't hurt.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Step 3: Fix the your persist
For this step, there is also a TWRP flashable zip file which will fix the persist. So for those who do not want to type the commands manually, you can simply flash the zip file (Tested and working).
Downloads:
Link: https://www.androidfilehost.com/?fid=11410963190603873125
md5: 5aac75092fc84f46dd5c6bd443df0748
These commands will restore the owners of rfs and hlos_rfs folder back to their respective original owners (rfs and rfs_shared):
Code:
chown -R rfs:rfs /persist/rfs
chown -R rfs:rfs_shared /persist/hlos_rfs
Alternatively, you can also type:
Code:
chown -R 3012:3012 /persist/rfs
chown -R 3012:3013 /persist/hlos_rfs
You will see no output on typing the first command, however, you may or may not see any output after typing the second command (there was an output shown on my device but not on the other tested devices). I'm sorry I don't have that output stored, if someone who can see it, please repond so the thread can be updated.
3012 is infact the id for rfs folder and 3013 is the id for hlos_rfs folder so instead of typing their names, you can also type their ids.
Now, to check if the owners of rfs and hlos_rfs have been set back to their original ones, type this command:
Code:
ls -l /persist
If everything went fine, you should be able to see the following output:
The below output will be seen on a perfectly fine persist as well
Code:
athene_f:/ # ls -l /persist
total 176
drwxrwx--- 2 system system 4096 2018-10-21 07:40 alarm
drwxr-xr-x 2 mot_pwric mot_pwric 4096 1969-12-31 19:02 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 2017-01-12 03:35 bluetooth
drwxr-xr-x 2 mot_tcmd bluetooth 4096 1969-12-31 19:02 bt
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 camera
drwxr-xr-x 2 root root 4096 2016-07-31 00:43 coresight
drwx------ 5 system system 4096 2017-01-12 05:21 data
drwxrwx--- 2 system graphics 4096 1969-12-31 19:02 display
drwxrwx--- 2 system system 4096 1969-12-31 19:02 drm
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1970-01-01 06:48 factory
[COLOR="red"]drwxrwx--- 3 rfs rfs_shared 4096 1969-12-31 19:02 hlos_rfs[/COLOR]
drwx------ 2 root root 4096 1969-12-31 19:00 lost+found
drwxrwx--- 2 radio radio 4096 2016-08-04 20:26 mdm
drwxrwx--- 3 system system 4096 2017-11-09 16:30 misc
drwxrwx--- 2 system system 4096 1970-02-11 17:39 properties
drwxr-xr-x 8 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 public
[COLOR="red"]drwx------ 6 rfs rfs 4096 1969-12-31 19:02 rfs[/COLOR]
drwxrws--- 2 mot_tpapi mot_tpapi 4096 2016-11-17 16:38 security
drwxrwxr-x 2 system system 4096 2016-07-31 00:43 sensors
drwxrwx--- 2 system system 4096 2018-09-10 18:13 time
drwxr-xr-x 2 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 wifi
drwxrwxr-x 2 mot_drm mot_drm 4096 1969-12-31 19:02 wmdrm
athene_f:/ #
As you can see here that the owner of rfs folder is rfs folder and the owner of hlos_rfs folder is rfs_shared folder, the problem has been resovled.
Reboot your device and the problem should be fixed and you will be able (hopefully) to get your IMEI back by either typing *#06# in phone dialer or in Settings>About Phone>Status>IMEI Information.
On rebooting, the system will check for the EFS folder and since it didn't exist earlier, it will be recreated by the system and therefore you will get your IMEI back.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
A huge thanx to NZedPred, rachitrawat, for doing in depth research in this problem and coming up with a solultion.
Also, I would like to thank Tyrantre who did a lot of research for this problem and has posted the workaround which was tried here in this thread here: Diag Mode with G4 for QPSD? which finally lead me to NZedPred's below thread as I could understand what was the problem due to which IMEI was set to 0 and why Diag mode wouldn't work.
Note: This thread was made with the help of the following guide which is confirmed to be working on Moto G5 Plus (potter) Fix Persist, resolve IMEI=0, Volte, 4G, Explanation, Requirements.
Note: This guide is made for G4/Plus and I have hardly done anything to fix this problem apart from making this thread, so all credits go to the respective owners who did research in this problem. This guide should work on other Motorola devices too as we aren't focusing on device-specific fixes that will only work on Moto G4 Plus.
Refer post #2 for fixing other issues faced after recovering IMEI.
Some Common Issues:
Here are the issues observed after recovering IMEI:
Sim card detected but no network
Baseband version changed
Volte not working
If you have any one of the above-mentioned problems, there is a specific thread made for those problems. Refer to this thread: [Guide] [XT16XX] [Solve] G4+ Baseband/Network/Volte issue, Lost 1 IMEI & fingerprint
Please discuss any issues related to the above-mentioned problems in the above-provided thread (link).
If you have any other issues apart from the issues mentioned above, discuss them here.
--------------------------------------------------------------------------
Complete Backup Zip/Script (All partitions):
Now since you have faced this issue, make sure to take a complete backup of all the partitions so that if you ever face an issue like this in future, you will always have your partitions with you to restore your device.
Here is the link to the thread to take complete backup of all partitions: [Guide] [XT16XX] Moto G4/Plus Complete Partition Backup/Restore Zip/Script
The above thread can backup/restore using TWRP flashable zip files for convenience.
There are a few youtube videos and internet guides which tells you to restore somebody else's persist file. That persist file is same in the Youtube video as well as those Internet guide (I have checked them).
Persist is unique to each and every device and using somebody else's persist on your device will never work.
IMEI is stored in /persist/rfs/msm/mpss/datablock directory where there are two files named as id_00 and id_01.
id_00 contains your 1st IMEI and id_01 contains your second IMEI.
The persist (from those guide and youtube videos) lacks id_00 and id_01 and since you restored that persist, you have those files missing as well. Those files are unique to every device anyways so if you try to restore a persist which has those files, it won't work too as your device's IMEI is different altogether.
The only possible fix that comes to my mind is by manually editing the persist file.
On comparing both the files in a hex editor, it is found that both of them are completely same except from memory address/location 00000028 to 000000C7.
This makes me think that IMEI is stored between those memory locations.
Furthermore, the first 14 digits of IMEI are stored from 00000028 to 0000002F in a different manner.
This is how it is stored,
Lets take a sample random IMEI: 3 12 34 56 78 90 12 34
This will be stored as following: 3A 21 43 65 87 09 21 03
Code:
3A [COLOR="Black"]21[/COLOR] [COLOR="DarkRed"]43[/COLOR] [COLOR="Red"]65[/COLOR] [COLOR="Magenta"]87[/COLOR] [COLOR="Sienna"]09[/COLOR] [COLOR="DarkOrange"]21[/COLOR] [COLOR="DarkOliveGreen"]03[/COLOR]
3 [COLOR="black"]12[/COLOR] [COLOR="darkred"]34[/COLOR] [COLOR="red"]56[/COLOR] [COLOR="magenta"]78[/COLOR] [COLOR="sienna"]90[/COLOR] [COLOR="darkorange"]12[/COLOR] [COLOR="darkolivegreen"]34[/COLOR]
The first set of hex numbers is what is stored in id_00 and id_01
The second set of hex numbers is what the actual IMEI is.
As you can clearly notice the difference via colors that the digits are getting flipped. The persist is storing the last digit 4 in some different way.
Why is there a letter A in the start just after 3, I found that it means that the last digit of IMEI stored in persist is 0. And that makes sense to as when you flip the last two digits i.e 03, you indeed get 30 which indicates the last digit is 0.
I don't think I need to mention this, but if you have a dual sim device, the first thirteen digits of IMEI are same and only the last two digits are different.
Now, this makes me conclude that the last digit of actual IMEI is stored in some way in the rest of the id_00 and id_01. And since most of the content in both the files are same, we just have to compare the part which is different as that part has that last digit of the two IMEIs stored.
I can't upload the contents of my IMEI for obvious reasons. If we are able to find the pattern in which the last digit is stored inside those files, then I think we can edit them and it should solve the problem for those people. Of course, editing and putting on somebody else's IMEI in those files wouldn't work either as we have already tried replacing the entire id_00 and id_01 (infact entire working persist) but the IMEI still remains 0.
Perhaps there is someplace (not talking about fastboot imei) where IMEI is stored as well, and while generation of EFS, that place and the persist are checked together and if the IMEIs in both the places match, you get your IMEI and if not, then it knows that IMEI has tampered and hence it doesn't work.
This might be too dangerous as people could edit their IMEI and put on somebody else's IMEI and can create problems, but as I mentioned above, it doesn't work as you will need to have your own IMEI in persist.
Update: Thanx to @NZedPred for correcting me. Even on deleting id_00 and id_01, and then eraseing EFS, we still get our IMEI.
I also tried changing the first digit of dhob.bin file while keeping id_00 and if_01 intact and then erased EFS, but didn't get my IMEI.
So, dhob.bin is the one which is responsible for IMEI creation and I am not able to understand anything inside dhob.bin.
I am sorry, but I was already trying beyond my capabilities earlier by using many internet sources as reference and it was just by chance that I stumbled upon id_00 and id_01. I am going to stop here for now, as this stuff goes beyond my current capabilities. If I ever get to know anything, I will update it here so that if anybody else would like to continue, they could do it.
I am sorry I tag you here, @echo92, @strongst, @NZedPred, @rachitrawat. This is what I was able to find out. I request you to read this post, and please help if you can. Thank You.
If you run the ls -l /persist command on android P ROM (which is causing this IMEI issue), this is the output you get:
Code:
athene:/ # ls -l /persist
total 88
drwxrwx--- 2 system system 4096 1970-01-10 08:37 alarm
drwxr-xr-x 2 vendor_mot_pwric vendor_mot_pwric 4096 1970-01-01 01:01 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 2018-03-29 00:04 bluetooth
drwxr-xr-x 2 vendor_mot_tcmd bluetooth 4096 1970-01-01 01:01 bt
drwxr-xr-x 4 vendor_mot_tcmd vendor_mot_tcmd 4096 2018-03-29 00:04 camera
drwxr-xr-x 2 root root 4096 2018-03-29 00:04 coresight
drwx------ 5 system system 4096 2018-03-29 00:04 data
drwxrwx--- 2 system graphics 4096 1970-01-01 01:01 display
drwxrwx--- 2 system system 4096 1970-01-01 01:01 drm
drwxr-xr-x 4 vendor_mot_tcmd vendor_mot_tcmd 4096 2018-03-29 00:04 factory
[COLOR="red"]drwxrwx--- 3 vendor_rfs vendor_rfs_shared 4096 2018-03-29 00:04 hlos_rfs[/COLOR]
drwxrwx--- 2 root root 4096 2018-03-29 00:04 lost+found
drwxrwx--- 2 radio radio 4096 2018-03-29 00:04 mdm
drwxrwx--- 3 system system 4096 2018-03-29 00:04 misc
drwxrwx--- 2 system system 4096 1970-05-31 18:25 properties
drwxr-xr-x 8 vendor_mot_tcmd vendor_mot_tcmd 4096 2018-03-29 00:04 public
[COLOR="Red"]drwx------ 6 vendor_rfs vendor_rfs 4096 2018-03-29 00:04 rfs[/COLOR]
drwxrws--- 2 vendor_mot_tpapi vendor_mot_tpapi 4096 2018-03-29 00:04 security
drwxrwxr-x 2 system system 4096 2018-03-29 00:04 sensors
drwxrwx--- 2 system system 4096 2018-03-29 00:04 time
drwxr-xr-x 2 vendor_mot_tcmd vendor_mot_tcmd 4096 1970-01-01 01:01 wifi
drwxrwxr-x 2 vendor_mot_drm vendor_mot_drm 4096 1970-01-01 01:01 wmdrm
Notice how, android Pie is using vendor suffix prefix.
One fix that was thought was to fix the owners in android Pie ROM itself before flashing Stock ROM, but on rebooting, the owners were changed back to vendor_rfs and vendor_rfs_shared.
Also, if you flash an Oreo ROM after flashing Pie ROM (which broke IMEI), this is the output you get:
Code:
athene_f:/ # ls -l /persist
total 176
drwxrwx--- 2 system system 4096 2018-10-21 07:40 alarm
drwxr-xr-x 2 mot_pwric mot_pwric 4096 1969-12-31 19:02 batt_health
drwxrwx--- 2 bluetooth bluetooth 4096 2017-01-12 03:35 bluetooth
drwxr-xr-x 2 mot_tcmd bluetooth 4096 1969-12-31 19:02 bt
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 camera
drwxr-xr-x 2 root root 4096 2016-07-31 00:43 coresight
drwx------ 5 system system 4096 2017-01-12 05:21 data
drwxrwx--- 2 system graphics 4096 1969-12-31 19:02 display
drwxrwx--- 2 system system 4096 1969-12-31 19:02 drm
drwxr-xr-x 4 mot_tcmd mot_tcmd 4096 1970-01-01 06:48 factory
[COLOR="red"]drwxrwx--- 3 root root 4096 2018-03-29 00:04 hlos_rfs[/COLOR]
drwx------ 2 root root 4096 1969-12-31 19:00 lost+found
drwxrwx--- 2 radio radio 4096 2016-08-04 20:26 mdm
drwxrwx--- 3 system system 4096 2017-11-09 16:30 misc
drwxrwx--- 2 system system 4096 1970-02-11 17:39 properties
drwxr-xr-x 8 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 public
[COLOR="red"]drwx------ 6 root root 4096 2018-03-29 00:04 rfs[/COLOR]
drwxrws--- 2 mot_tpapi mot_tpapi 4096 2016-11-17 16:38 security
drwxrwxr-x 2 system system 4096 2016-07-31 00:43 sensors
drwxrwx--- 2 system system 4096 2018-09-10 18:13 time
drwxr-xr-x 2 mot_tcmd mot_tcmd 4096 1969-12-31 19:02 wifi
drwxrwxr-x 2 mot_drm mot_drm 4096 1969-12-31 19:02 wmdrm
athene_f:/ #
Here are some of the points that can throw some light on the topic:
rachitrawat said:
Hey all,
After spending hours on the IMEI 0 problem, here are my findings:
1. IMEI is stored in nv 550 variable in QCN. However, this variable is write protected. This means all IMEI write programs such as QCOM Write IMEI tool will fail.
2. Interestingly, only IMEI 1 is stored in the nv. IMEI 2 is derived by performing some fixed hex arithmetic on IMEI 1.
3. IMEI also seems encrypted since the nv 550 in QCN never has a correct hex notation of IMEI. For example, Only half of the IMEI is correct.
4. Any attempt to restore the QCN backup of someone else will successfully write all nv variables except nv 550. Means you cannot rewrite your factory IMEI.
5. The above is true even if you hexedit the QCN with your own IMEI. NV 550 is write protected.
6. modemst1 and modemst2 are sort of some baseband cache which are created by radio/bootloader using fsg. fsg seems to be some sort of backup partition for modemst.
7. After downgrading and erasing modemst1-2, these modemst are not recreated successfully by the modem. The nv 550 variable goes missing.
8. My guess is that modem has some checksum mechanism wherein if any discrepancy is found, the modemst cache recreation fails. Not sure.
9. Our IMEI is most likely intact somewhere (not talking about fastboot IMEI). Just not interpreted properly.
10. People who restored their efs after IMEI 0 are essentially restoring working cached modemst1-2. However, if fastboot erase modemst is done, it'll likely result in IMEI 0 again because modem cannot recreate modemst correctly.
Click to expand...
Click to collapse
Thanks alot!!!
My friend was having the same problem, it worked for him??
Edit: Volte is still not working in the device...
@Heeth21,
I am facing this issue after moving to stock. Getting IMEI on "fastboot getvar imei", however unable to restore it. I followed all the instructions you had shared. Any help or further instruction in this regard would be helpful.
Thanks in advance.
checksamir said:
@Heeth21,
I am facing this issue after moving to stock. Getting IMEI on "fastboot getvar imei", however unable to restore it. I followed all the instructions you had shared. Any help or further instruction in this regard would be helpful.
Thanks in advance.
Click to expand...
Click to collapse
Can you post the output of this command in terminal?
Code:
su
ls -l /persist
Also of this command too:
Code:
su
find /persist -type f
If would be beneficial if you format it in code or you might just attach the output in a txt file.
Also can you tell me your baseband version. I think as far as I have observed, those who are getting this IMEI=0 issue, their basebands are ending with "u"
Heeth21 said:
Can you post the output of this command in terminal?
Code:
su
ls -l /persist
Also of this command too:
Code:
su
find /persist -type f
If would be beneficial if you format it in code or you might just attach the output in a txt file.
Also can you tell me your baseband version. I think as far as I have observed, those who are getting this IMEI=0 issue, their basebands are ending with "u"
Click to expand...
Click to collapse
@Heeth21,
THanks for the quick response. Please find the attached output files in text and screenshot for baseband..
checksamir said:
@Heeth21,
THanks for the quick response. Please find the attached output files in text and screenshot for baseband..
Click to expand...
Click to collapse
The files seems proper.
Type these commands again and attach the output. A screenshot would help a lot.
Code:
su
chown -R rfs:rfs /persist/rfs
chown -R rfs:rfs_shared /persist/hlos_rfs
ls -l /persist
Heeth21 said:
The files seems proper.
Type these commands again and attach the output. A screenshot would help a lot.
Code:
su
chown -R rfs:rfs /persist/rfs
chown -R rfs:rfs_shared /persist/hlos_rfs
ls -l /persist
Click to expand...
Click to collapse
I had to try it twice: after executing code /persists/rfs, some file or path or folder was missing and it started something which eventually closed before I could take a screenshot. Next time I tried, there was nothing as such. Second screenshot attached for reference.
Really appreciated your quick responses..
Heeth21 said:
The files seems proper.
Type these commands again and attach the output. A screenshot would help a lot.
Click to expand...
Click to collapse
Man! Thanks a ton! It worked like a charm... I'm back to stock with full functional VoLTE.. you're a genius.. I owe you a beer..!:good:
Nao deu certo comigo, me ajuda por favor.
Hello, I'm sorry for bad English, I'm Brazilian. I'm translating through google translator.
I am with the same problem of this post, after flashing the stock rom the imei got 0, I did the procedures of this post but it did not work with me, my imei appears correctly with the command (fastboot gevtar imei)
but in command: (ls -l / persist) does not appear the number 2951 or 2952, but the name rfs, as if everything was okay (but the imei continues 0)
and in the command: (find / persist -type f) the line does not appear (/persist/rfs/msm/mpss/dhob.bin.bak)
I finally executed the commands (chown -R rfs: rfs / persist / rfs and
chown -R rfs: rfs_shared / persist / hlos_rfs) and restarted the cell phone but the imei continued 0
the version of the base band is m8952_70030.25.03.62.02a
Is there any procedure I can try? I'll be very grateful.
---------- Post added at 01:53 AM ---------- Previous post was at 01:47 AM ----------
Hello, I'm sorry for bad English, I'm Brazilian. I'm translating through google translator.
I am with the same problem of this post, after flashing the stock rom the imei got 0, I did the procedures of this post but it did not work with me, my imei appears correctly with the command (fastboot gevtar imei)
but in command: (ls -l / persist) does not appear the number 2951 or 2952, but the name rfs, as if everything was okay (but the imei continues 0)
and in the command: (find / persist -type f) the line does not appear (/persist/rfs/msm/mpss/dhob.bin.bak)
I finally executed the commands (chown -R rfs: rfs / persist / rfs and
chown -R rfs: rfs_shared / persist / hlos_rfs) and restarted the cell phone but the imei continued 0
the version of the base band is m8952_70030.25.03.62.02a
I'll try to send prints.
Is there any procedure I can try? I'll be very grateful.
Oliver1995 said:
but in command: (ls -l / persist) does not appear the number 2951 or 2952, but the name rfs, as if everything was okay (but the imei continues 0)
and in the command: (find / persist -type f) the line does not appear (/persist/rfs/msm/mpss/dhob.bin.bak)
I finally executed the commands (chown -R rfs: rfs / persist / rfs and
chown -R rfs: rfs_shared / persist / hlos_rfs) and restarted the cell phone but the imei continued 0
Click to expand...
Click to collapse
The chown command won't do anything as the owners of the partitions are already rfs and rfs_shared.
Reflash stock rom again, and check if you get to see 2951 or 2952 on executing the command "ls -l /persist", and respond.
If you still don't get to see 2951 and 2952, then it seems you have tried doing some changes to your efs/persist partition by either restoring someone else's efs/persist or tried to edit yours.
what should I understand:It means that some custom roms erase imei while going back to stock,it can be recovered but volte cant
Is it right?
BogartX said:
what should I understand:It means that some custom roms erase imei while going back to stock,it can be recovered but volte cant
Is it right?
Click to expand...
Click to collapse
Partially right. Some custom ROMs do some changes with the EFS folder which is responsible for the recreation of IMEI. However, while flashing the Stock ROM, if you do not erase EFS partition, then you will retain your IMEI.
The commands which erase EFS partitions are:
Code:
fastboot erase modemst1
fastboot erase modemst2
The modemst1 and modemst2 are indeed the EFS partition itself. So just skip the above lines while flashing Stock ROM if the custom ROM is doing some changes with the EFS partition, and you will not lose your IMEI.
Volte can be recovered but there is a condition which should be satisfied. The baseband should remain as Indian. If it does, then you will be having Volte working and if it doesn't, you won't be having Volte running.
The only ROMs which are causing this issue on our device currently are Android Pie ROMs. I hope when Official Oreo is released for our device, the new blobs and modem will solve this issue. The developers have already checked if there is something in the ROMs which is causing this issue, and they found no problems at all. Same was the case with Oreo ROMs on Moto G5/Plus and Moto G5s/Plus
Heeth21 said:
The chown command won't do anything as the owners of the partitions are already rfs and rfs_shared.
Reflash stock rom again, and check if you get to see 2951 or 2952 on executing the command "ls -l /persist", and respond.
If you still don't get to see 2951 and 2952, then it seems you have tried doing some changes to your efs/persist partition by either restoring someone else's efs/persist or tried to edit yours.
Click to expand...
Click to collapse
yes actually I tried to restore the persistence of another person by a tutorial on youtube (I do not know if I can post the link here) and also did this tutorial to restore these files modem.img, fsg.img, hw.img: https://forum.xda-developers.com/moto-g4-plus/how-to/solve-moto-g4-plus-one-imei-fp-sensor-t3800410
already tried to reinstall the stock rom but does not appear the numbers 2951 or 2952
Do not have any solution for this?
This helped me alot,Thanks?
In my case both sim are working,with no volte
But jio 4g voice or dialer app with data on is not working
Yes I tried to restore the persist
the problem occurred after installing this rom 9.0 when I came back to the stock the imei was 0: https://forum.xda-developers.com/moto-g4-plus/development/rom-arrowos-9-x-t3859849
Oliver1995 said:
yes actually I tried to restore the persistence of another person by a tutorial on youtube (I do not know if I can post the link here) and also did this tutorial to restore these files modem.img, fsg.img, hw.img: https://forum.xda-developers.com/moto-g4-plus/how-to/solve-moto-g4-plus-one-imei-fp-sensor-t3800410
already tried to reinstall the stock rom but does not appear the numbers 2951 or 2952
Do not have any solution for this?
Click to expand...
Click to collapse
Restore your original persist back. I have seen that tutorial. This issue can only be solved if you are on your own persist as every device has its unique persist.
It doesn't matter if you tried restoring modem, hw, fsg files. Just make sure you are on your own persist.
If you haven't taken a backup of your original unmodified persist, then I'm sorry that is a completely different issue which I don't think there is a soluton to.
Pranavchorge said:
This helped me alot,Thanks
In my case both sim are working,with no volte
But jio 4g voice or dialer app with data on is not working
Click to expand...
Click to collapse
I was hoping if you could atatch your build.prop so that we can compare and check for Volte solution.
You need to grant permissions to Jio4GVoice, enable mobile data (wifi should be off), and dial via Jio4GVoice. Check if this works (it should), and then you will have an ongoing activity notification for Jio4GVoice app