Abstract
This tutorial will debug a corrupted boot.img and is an answer to a question/request.
Background
I took the time to look at a corrupted boot.img, posted on the HTC One X forum [1].
Since the Android boot image structure is general for all devices,
I thought this could be of some help for all of you who is trying to find out why your boot.img doesn't work.
ehsanmp said:
Hi all,
I've been trying to edit a stock boot.img's ramdisk so that I can get proper rw access in USB debugging.
I've successfully
1. unpacked the img.
2. edited the default.prop file to ro.secure=0 and all other variables to 1
3. repacked the ramdisk
But I still can't repack the ramdisk and kernel into the new boot.img!
I've tried using the android kitchen, repack-bootimg.pl and mkbootimg, both in cygwin and a virtual machine running Ubuntu 12.04.
everytime mkbootimg gives an error, either "permission denied" or "no such file or directory"
I'm gonna attach the kernel gz and the edited and compiled ramdisk gz, as well as the boot.img (just in case).
Could someone please repack them into a new boot.img for me?
Many thanks!HelpingEhsan.rar
Click to expand...
Click to collapse
Downloading, hashing, and unpacking the helpingehsan.rar file.
The MD5 hash sum of the original rar-file is of course not necessary...
Code:
[email protected]:~$ [email protected]:~$ mkdir helpingehsan; cd helpingehsan; wget https://dl.dropbox.com/s/72wgogz9ll62s0w/ helpingehsan.rar?dl=1 -O helpingehsan.rar; md5sum helpingehsan.rar; rar x helpingehsan.rar; ls -la
--2012-09-16 21:46:06-- https://dl.dropbox.com/s/72wgogz9ll62s0w/helpingehsan.rar?dl=1
Resolving dl.dropbox.com (dl.dropbox.com)... 23.23.133.20, 50.19.106.181, 107.20.134.222, ...
Connecting to dl.dropbox.com (dl.dropbox.com)|23.23.133.20|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17250294 (16M) [application/rar]
Saving to: 'helpingehsan.rar'
100%[=====================================================>] 17,250,294 1.01MB/s in 21s
2012-09-16 21:46:29 (807 KB/s) - 'helpingehsan.rar' saved [17250294/17250294]
ea9840823ad5cf2b865a4eb5be86eb5d helpingehsan.rar
RAR 4.20 Copyright (c) 1993-2012 Alexander Roshal 9 Jun 2012
Trial version Type RAR -? for help
Extracting from helpingehsan.rar
Extracting boot.img OK
Extracting boot.img-kernel.gz OK
Extracting ramdisk.cpio.gz OK
All OK
total 37636
drwxr-xr-x 2 j users 4096 Sep 16 21:46 ./
drwx--x--x 34 j users 4096 Sep 16 21:46 ../
-rw-r--r-- 1 j users 8388608 Sep 1 22:42 boot.img
-rw-r--r-- 1 j users 4104448 Sep 2 08:48 boot.img-kernel.gz
-rw-r--r-- 1 j users 17250294 Sep 16 21:46 helpingehsan.rar
-rw-r--r-- 1 j users 8781519 Sep 2 08:51 ramdisk.cpio.gz
Initial preview
At a first look, the boot.img looks suspicioucly big for being a boot image.
The ramdisk.cpio.gz is also even greater than the boot.img, while the compressed kernel seems to have a realistic size.
Dumping the boot.img start with a hex editor reveals that the real header seems to start at offset 0x100 (256 bytes) and
the initial data seems to be irrelevant junk.
Code:
[email protected]:~/helpingehsan$ ls -la boot.img; hexdump -C -n 2048 boot.img
-rw-r--r-- 1 j users 8388608 Sep 1 22:42 boot.img
00000000 51 16 28 f1 d1 b4 ae 77 fa 56 1f 79 49 ef cf a3 |Q.(ñÑ´®wúV.yIïÏ£|
00000010 92 4e ef 25 61 15 6f fe 80 9a b3 16 05 dd b8 87 |.Nï%a.oþ..³..ݸ.|
00000020 88 d5 1c b1 5d fa 45 1a b4 2a b4 20 d7 e8 e3 84 |.Õ.±]úE.´*´ ×èã.|
00000030 62 a6 41 eb 83 3c 35 77 e3 44 31 6c 34 73 8a 57 |b¦Aë.<5wãD1l4s.W|
00000040 3d ba c0 dc 74 fe 5a 9d bd a1 da bd 20 f6 16 89 |=ºÀÜtþZ.½¡Ú½ ö..|
00000050 d4 ef 97 50 e5 46 f0 fc c5 07 af 13 14 b4 35 de |Ôï.PåFðüÅ.¯..´5Þ|
00000060 4f c8 c1 bd dc 05 67 95 85 76 70 63 88 eb 15 ea |OÈÁ½Ü.g..vpc.ë.ê|
00000070 7d da ac ad 6d c7 44 78 73 d3 8d 1b 37 ad cc 73 |}Ú¬*mÇDxsÓ..7*Ìs|
00000080 d5 a5 d6 e9 6d 0c 05 0a 64 49 d6 65 b3 98 f4 67 |Õ¥Öém...dIÖe³.ôg|
00000090 9c e1 90 64 c6 92 75 dc 55 fd da e5 c3 3c 35 d0 |.á.dÆ.uÜUýÚåÃ<5Ð|
000000a0 e5 7a 92 d5 e8 5f 65 8f f7 77 69 11 72 a6 f8 82 |åz.Õè_e.÷wi.r¦ø.|
000000b0 ee ad cc ad 2a 62 55 11 89 eb 4d dd 74 f2 f1 5b |î*Ì**bU..ëMÝtòñ[|
000000c0 ee 93 05 fe 94 b4 d8 28 09 2c 9b d1 3a d8 1e 60 |î..þ.´Ø(.,.Ñ:Ø.`|
000000d0 89 52 9e f9 3f ea af b5 c0 d0 b6 60 51 ba b6 ab |.R.ù?꯵Àж`Qº¶«|
000000e0 41 ab ab 1b e0 06 a3 ca bb 37 6f aa eb b6 6f c3 |A««.à.£Ê»7oªë¶oÃ|
000000f0 26 fa 28 f7 48 55 10 83 42 4e 02 37 9f be 5f d7 |&ú(÷HU..BN.7.¾_×|
00000100 41 4e 44 52 4f 49 44 21 b0 9b 3e 00 00 80 00 10 |ANDROID!°.>.....|
00000110 7c 8a 04 00 00 00 00 11 00 00 00 00 00 00 f0 10 ||.............ð.|
00000120 00 01 00 10 00 08 00 00 00 00 00 00 00 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000340 bf f4 50 e5 45 4b 2d 1b 13 40 2a be 0d fe 25 2e |¿ôPå[email protected]*¾.þ%.|
00000350 2b ef b4 07 00 00 00 00 00 00 00 00 00 00 00 00 |+ï´.............|
00000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000800
Kernel image analysis
Next up to be analysed is the compressed kernel image, a zImage file.
Also in this case, the image starts at offset 0x100.
The first 256 bytes are zeros and should be chopped off to work as a kernel image.
Code:
[email protected]:~/helpingehsan$ hexdump -C -n 512 boot.img-kernel.gz
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 |..*á..*á..*á..*á|
*
00000120 02 00 00 ea 18 28 6f 01 00 00 00 00 b0 9b 3e 00 |...ê.(o.....°.>.|
00000130 01 70 a0 e1 02 80 a0 e1 00 20 0f e1 03 00 12 e3 |.p*á..*á. .á...ã|
00000140 01 00 00 1a 17 00 a0 e3 56 34 12 ef 00 20 0f e1 |......*ãV4.ï. .á|
00000150 c0 20 82 e3 02 f0 21 e1 00 00 00 00 00 00 00 00 |À .ã.ð!á........|
00000160 44 47 9f e5 45 00 00 eb ec 00 8f e2 4e 1a 90 e8 |DG.åE..ëì..âN..è|
00000170 1c d0 90 e5 01 00 40 e0 00 60 86 e0 00 d0 8d e0 |.Ð.å[email protected]à.`.à.Ð.à|
00000180 01 a8 8d e2 01 a9 8a e2 0a 00 54 e1 15 00 00 2a |.¨.â.©.â..Tá...*|
00000190 09 a0 84 e0 0f 00 5a e1 12 00 00 9a 02 ab 8a e2 |.*.à..Zá.....«.â|
000001a0 ff a0 ca e3 44 50 4f e2 1f 50 c5 e3 05 90 46 e0 |ÿ*ÊãDPOâ.PÅã..Fà|
000001b0 1f 90 89 e2 1f 90 c9 e3 05 60 89 e0 0a 90 89 e0 |...â..Éã.`.à...à|
000001c0 0f 5c 36 e9 05 00 56 e1 0f 5c 29 e9 fb ff ff 8a |.\6é..Vá.\)éûÿÿ.|
000001d0 06 60 49 e0 06 d0 8d e0 48 01 00 eb 7c 00 4f e2 |.`Ià.Ð.àH..ë|.Oâ|
000001e0 06 00 80 e0 00 f0 a0 e1 00 00 30 e3 08 00 00 0a |...à.ð*á..0ã....|
000001f0 00 b0 8b e0 00 c0 8c e0 00 20 82 e0 00 30 83 e0 |.°.à.À.à. .à.0.à|
00000200
Ramdisk image analysis
The last file is the gnuzipped ramdisk. A quick analysis of its header indicates that it seems to be fine.
The first two bytes (1f 8b) gives a hint of a gzip file [3].
Code:
[email protected]:~/helpingehsan$ hexdump -C -n 32 ramdisk.cpio.gz
00000000 1f 8b 08 00 7a 80 43 50 00 03 bc 3c 6b 6f db b8 |....z.CP..¼<koÛ¸|
00000010 b2 fb b5 f9 15 44 83 7b ef 2e ce ca b2 9d a4 e9 |²ûµù.D.{ï.Îʲ.¤é|
00000020
An unpack of the huge ramdisk is necessary to better get an idea of its content.
Code:
[email protected]:~/helpingehsan$ mkdir ramdisk; cd ramdisk; gunzip -c ../ramdisk.cpio.gz | cpio -i; ls -al
25487 blocks
total 12272
drwxr-xr-x 3 j users 4096 Sep 16 22:11 ./
drwxr-xr-x 3 j users 4096 Sep 16 22:11 ../
-rwxrwxrwx 1 j users 8388608 Sep 16 22:11 boot.img*
-rw-rw-r-- 1 j users 4104448 Sep 16 22:11 boot.img-kernel.gz
drwxrwxr-x 8 j users 4096 Sep 16 22:11 boot.img-ramdisk/
-rwxrwxrwx 1 j users 24302 Sep 16 22:11 mkbootfs*
-rwxrwxrwx 1 j users 23798 Sep 16 22:11 mkbootimg*
-rwxrwxrwx 1 j users 901 Sep 16 22:11 repack-bootimg.pl*
-rwxrwxrwx 1 j users 1710 Sep 16 22:11 unpack-bootimg.pl*
No wonder why the size!
The ramdisk contains even more you could wish for - and an incorrect directory structure.
By hashing the boot.img and the boot.img-kernel.gz in the compressed ramdisk
and comparing them with the included images in the helpingehsan.rar
will tell if those files are identical - which seems to be the case.
The only conlusion to make is that something went wrong.
Code:
[email protected]:~/helpingehsan/ramdisk$ md5sum ../boot.img boot.img ../boot.img-kernel.gz boot.img-kernel.gz
00aec167963e7d5df4b3fc9661439fa3 ../boot.img
00aec167963e7d5df4b3fc9661439fa3 boot.img
f5adbe66ef11e0d6a3cea6f0d04ec798 ../boot.img-kernel.gz
f5adbe66ef11e0d6a3cea6f0d04ec798 boot.img-kernel.gz
We also need to get a picture of the boot.img-ramdisk directory. How big is it? What does it contain?
Code:
[email protected]:~/helpingehsan/ramdisk$ du -b boot.img-ramdisk/
322935 boot.img-ramdisk/sbin
4096 boot.img-ramdisk/system
4096 boot.img-ramdisk/data
4096 boot.img-ramdisk/sys
4096 boot.img-ramdisk/proc
4096 boot.img-ramdisk/dev
529719 boot.img-ramdisk/
Code:
[email protected]:~/helpingehsan/ramdisk$ du -b boot.img-ramdisk; ls -la boot.img-ramdisk
322935 boot.img-ramdisk/sbin
4096 boot.img-ramdisk/system
4096 boot.img-ramdisk/data
4096 boot.img-ramdisk/sys
4096 boot.img-ramdisk/proc
4096 boot.img-ramdisk/dev
529719 boot.img-ramdisk
total 244
drwxrwxr-x 8 j users 4096 Sep 16 22:11 ./
drwxr-xr-x 3 j users 4096 Sep 16 22:11 ../
-rw-r--r-- 1 j users 1395 Sep 16 22:11 cwkeys
drwxrwx--x 2 j users 4096 Sep 16 22:11 data/
-rw-r--r-- 1 j users 118 Sep 16 22:11 default.prop
-rw-r--r-- 1 j users 118 Sep 16 22:11 default.prop~
drwxr-xr-x 2 j users 4096 Sep 16 22:11 dev/
-rwxr-x--- 1 j users 111468 Sep 16 22:11 init*
-rwxr-x--- 1 j users 14390 Sep 16 22:11 init.endeavoru.common.rc*
-rwxr-x--- 1 j users 18122 Sep 16 22:11 init.endeavoru.rc*
-rwxr-x--- 1 j users 2344 Sep 16 22:11 init.goldfish.rc*
-rwxr-x--- 1 j users 22319 Sep 16 22:11 init.rc*
-rwxr-x--- 1 j users 6140 Sep 16 22:11 init.usb.rc*
drwxr-xr-x 2 j users 4096 Sep 16 22:11 proc/
drwxr-x--- 2 j users 4096 Sep 16 22:11 sbin/
drwxr-xr-x 2 j users 4096 Sep 16 22:11 sys/
drwxr-xr-x 2 j users 4096 Sep 16 22:11 system/
-rw-r--r-- 1 j users 1417 Sep 16 22:11 ueventd.endeavoru.rc
-rw-r--r-- 1 j users 272 Sep 16 22:11 ueventd.goldfish.rc
-rw-r--r-- 1 j users 4105 Sep 16 22:11 ueventd.rc
Identification of the kernel base address
The kernel base address = (hdr.kernel_addr - 0x00008000) [2].
We can from the boot.img see that the hdr.kernel_addr is set to the value 0x10008000.
This results in the base address 0x10000000.
Code:
[email protected]:~/helpingehsan/ramdisk$ hexdump -C -n 16 -s 256 boot.img
00000100 41 4e 44 52 4f 49 44 21 b0 9b 3e 00 00 80 00 10 |ANDROID!°.>.....|
00000110
Recompilation of the ramdisk
A recompilation into a new ramdisk (boot.img-ramdisk.cpio.gz) is the carried out [4],
even if we do not know if it works properly. It's all depending on the source.
Code:
[email protected]:~/helpingehsan/ramdisk$ cd boot.img-ramdisk; find . | cpio -o -H newc | gzip > ../boot.img-ramdisk.cpio.gz; cd ..; ls -la
985 blocks
total 12564
drwxr-xr-x 3 j users 4096 Sep 16 23:44 ./
drwxr-xr-x 4 j users 4096 Sep 16 22:57 ../
-rwxrwxrwx 1 j users 8388608 Sep 16 22:11 boot.img*
-rw-rw-r-- 1 j users 4104448 Sep 16 22:11 boot.img-kernel.gz
drwxrwxr-x 8 j users 4096 Sep 16 22:11 boot.img-ramdisk/
-rw-r--r-- 1 j users 297162 Sep 16 23:44 boot.img-ramdisk.cpio.gz
-rwxrwxrwx 1 j users 24302 Sep 16 22:11 mkbootfs*
-rwxrwxrwx 1 j users 23798 Sep 16 22:11 mkbootimg*
-rwxrwxrwx 1 j users 901 Sep 16 22:11 repack-bootimg.pl*
-rwxrwxrwx 1 j users 1710 Sep 16 22:11 unpack-bootimg.pl*
Removal of the initial 256 zeros from the boot.img-kernel.gz
Code:
[email protected]:~/helpingehsan/ramdisk$ dd if=boot.img-kernel.gz of=boot.img-kernel.gz.new skip=256 iflag=skip_bytes
8016+0 records in
8016+0 records out
4104192 bytes (4.1 MB) copied, 0.03337 s, 123 MB/s
Creating a new boot.img
Remeber: the original boot.img header did not have a kernel command line.
Code:
[email protected]:~/helpingehsan/ramdisk$ mkbootimg --kernel boot.img-kernel.gz.new --ramdisk boot.img-ramdisk.cpio.gz --base 0x10000000 -o boot.img
[email protected]:~/helpingehsan/ramdisk$ ls -la boot.img; md5sum boot.img
-rwxrwxrwx 1 j users 4405248 Sep 16 23:58 boot.img*
dba17088ff533adec1fb5a92478fafe2 boot.img
Summary
With knowledge in the boot.img structure, some experience in using a hex editor
(my personal favourite is the KDE Okteta) and DIY-mentality, I think you could solve most of such problems.
I have no idea if theresulting boot.img will work, the content is based on the files that was found in the original tar-file.
Here is a copy of the original file in case the original file was deleted
The resulting boot.img is there too.
For those who wonders about the analysis environment: Linux (here: Slackware 13.37 / current).
Take care and good luck!
References:
[1] [HELP] Can anyone help me recompile this boot.img?, Sept 2012
[2] mkbootimg.c, bootimg.h by The Android Open Source Project, 2007
[3] GZIP file format specification version 4.3, RFC 1952, chapter 2.3.1., L. Peter Deutsch, 1996
[4] HOWTO: Unpack, Edit, and Re-Pack Boot Images, Android-DLS, 2012
Lollipops are on me!
This is Absolutely Glorious
Nice guide. Amazing for those new to building ROMs, and a good read for those who are experieced
Sent from my HTC One XL using XDA Premium 4 mobile app
My moto e boot corrupted
Means hardbrick
Now it is not starting not even.going to fastboot mode
Plz help me to install official bootloader
Related
hi,
i've bought a Utano Barrier T180 outdoor android phone and i want to root it. it has android 2.3.5.1 installed and i tried already:
universalAndroot app
z4root app
the zergRush exploid
everything isn't working. zergRush means:
Code:
[-] Hellions with BLUE flames !
any idea what that mean and if there is still a chance to do it over the exploit.
another way would be to modify the recovery image. if I look a little closer it seams to be an unencrypted image in some container format:
hd /tmp/a/image/factory.mbn
Code:
00000000 80 10 00 00 00 10 02 00 49 6d 61 67 65 20 66 69 |........Image fi|
00000010 6c 65 20 77 69 74 68 20 68 65 61 64 65 72 00 00 |le with header..|
00000020 01 02 00 00 62 61 64 5f 62 6c 6f 63 6b 5f 62 79 |....bad_block_by|
00000030 74 65 5f 61 64 64 72 65 73 73 20 3d 20 32 30 30 |te_address = 200|
00000040 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |0...............|
00000050 70 61 67 65 5f 62 79 74 65 73 5f 75 73 65 72 20 |page_bytes_user |
00000060 20 20 20 20 20 20 20 3d 20 32 30 34 38 00 00 00 | = 2048...|
00000070 62 6c 6f 63 6b 5f 70 61 67 65 73 20 20 20 20 20 |block_pages |
00000080 20 20 20 20 20 20 20 3d 20 36 34 00 00 00 00 00 | = 64.....|
00000090 64 65 76 69 63 65 5f 62 6c 6f 63 6b 73 20 20 20 |device_blocks |
000000a0 20 20 20 20 20 20 20 3d 20 34 30 39 36 00 00 00 | = 4096...|
000000b0 64 61 74 61 5f 77 69 64 74 68 20 20 20 20 20 20 |data_width |
000000c0 20 20 20 20 20 20 20 3d 20 31 36 00 00 00 00 00 | = 16.....|
000000d0 64 65 76 69 63 65 5f 4d 42 79 74 65 20 20 20 20 |device_MByte |
000000e0 20 20 20 20 20 20 20 3d 20 35 31 32 00 00 00 00 | = 512....|
000000f0 64 65 76 69 63 65 5f 74 79 70 65 20 20 20 20 20 |device_type |
00000100 20 20 20 20 20 20 20 3d 20 53 4c 43 00 00 00 00 | = SLC....|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 66 6c 61 73 68 5f 64 65 76 69 63 65 20 20 20 20 |flash_device |
00000130 20 20 20 20 20 20 20 3d 20 30 78 30 30 30 30 3d | = 0x0000=|
00000140 43 55 53 54 4f 4d 5f 53 45 54 54 49 4e 47 00 00 |CUSTOM_SETTING..|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000160 66 6c 61 73 68 5f 69 64 20 20 20 20 20 20 20 20 |flash_id |
00000170 20 20 20 20 20 20 20 3d 20 30 78 30 30 30 30 00 | = 0x0000.|
00000180 71 75 61 6c 63 6f 6d 6d 5f 64 65 76 69 63 65 20 |qualcomm_device |
00000190 20 20 20 20 20 20 20 3d 20 4d 53 4d 37 32 78 78 | = MSM72xx|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001b0 70 61 67 65 5f 6c 61 79 6f 75 74 5f 73 74 72 69 |page_layout_stri|
000001c0 6e 67 20 20 20 20 20 3d 20 28 64 61 74 61 5f 34 |ng = (data_4|
000001d0 36 34 5f 73 70 61 72 65 5f 32 5f 64 61 74 61 5f |64_spare_2_data_|
000001e0 34 38 5f 73 70 61 72 65 5f 31 34 29 78 34 00 00 |48_spare_14)x4..|
000001f0 71 66 69 74 5f 76 65 72 73 69 6f 6e 20 20 20 20 |qfit_version |
00000200 20 20 20 20 20 20 20 3d 20 31 2e 36 2e 31 30 00 | = 1.6.10.|
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000220 6c 6f 67 5f 66 69 6c 65 20 20 20 20 20 20 20 20 |log_file |
00000230 20 20 20 20 20 20 20 3d 20 4d 61 72 32 33 2d 32 | = Mar23-2|
00000240 30 31 32 2d 31 31 32 32 2d 31 37 2e 6c 6f 67 00 |012-1122-17.log.|
00000250 66 69 6c 65 5f 63 72 65 61 74 65 5f 70 61 74 68 |file_create_path|
00000260 20 20 20 20 20 20 20 3d 20 0a 20 20 64 3a 2f 54 | = . d:/T|
strings /tmp/a/image/factory.mbn
Code:
Image file with header
bad_block_byte_address = 2000
page_bytes_user = 2048
block_pages = 64
device_blocks = 4096
data_width = 16
device_MByte = 512
device_type = SLC
flash_device = 0x0000=CUSTOM_SETTING
flash_id = 0x0000
qualcomm_device = MSM72xx
page_layout_string = (data_464_spare_2_data_48_spare_14)x4
qfit_version = 1.6.10
log_file = Mar23-2012-1122-17.log
file_create_path =
d:/T18/0322/AMSS/products/76XX/tools/qfit/Local/FactoryImage2.mbn
end_of_header
Start End Actual
0 0:MIBIB 0x0000 0x0009 0x0004 main_ecc_10 1x_pages
D:\T18\0322\AMSS\products\76XX\build\ms\bin\TSNCJOLYMT18/mibib.mbn
1 0:SIM_SECURE 0x000A 0x000D 0x0000 main_ecc_10 1x_pages
2 0:QCSBL 0x000E 0x000F 0x0001 main_ecc_10 1x_pages
D:\T18\0322\AMSS\products\76XX\build\ms\bin\TSNCJOLYMT18/qcsbl.mbn
3 0:OEMSBL1 0x0010 0x0014 0x0005 main_ecc_10 1x_pages
D:\T18\0322\AMSS\products\76XX\build\ms\bin\TSNCJOLYMT18/oemsbl.mbn
4 0:OEMSBL2 0x0015 0x0019 0x0000 main_ecc_10 1x_pages
5 0:AMSS 0x001A 0x00ED 0x0091 main_ecc_10 1x_pages
D:\T18\0322\AMSS\products\76XX\build\ms\bin\TSNCJOLYMT18/amss.mbn
6 0:EFS2 0x00EE 0x014D 0x0005 main_ecc_10 1x_pages
D:/T18/0322/AMSS/products/76XX/tools/qfit/cefs.mbn
7 0:FOTA 0x014E 0x014F 0x0000 main_ecc_10 1x_pages
8 0:NV 0x0150 0x0160 0x0000 main_ecc_10 1x_pages
9 0:APPSBL 0x0161 0x0163 0x0001 main_ecc_10 1x_pages
D:\T18\0322\AMSS\products\76XX\build\ms\bin\TSNCJOLYMT18/appsboot.mbn
10 0:BOOT 0x0164 0x018B 0x0021 main_and_spare_ecc_10 1x_pages
D:\T18\0322\AMSS\products\76XX\build\ms\bin\TSNCJOLYMT18/boot.img
11 0:SYSTEM 0x018C 0x086B 0x0421 main_and_spare_ecc_10 1x_pages
D:\T18\0322\AMSS\products\76XX\build\ms\bin\TSNCJOLYMT18/system.img
12 0:SPLASH 0x086C 0x0873 0x0003 main_and_spare_ecc_10 1x_pages
but my linux knowledge isn't big enough to extract the system partition from this container, mount the yaffs2 file system, add an su programm and an superuser.apk and pack it all together again.
what do you think, could this way work??
could someone help me please to do so?
the imagefile is available at h t t p : / / share.branddistribution.de/utano_outdoor/sw/utano_BARRIER_T180_ANDROID_2_3_5_1.rar
thanks treaki
On your phone, go to Settings, About phone, Model number and verify it says HW-T18. If so go to google and do a search for "HW-T18 root" without the quotes. Should be the website android-hilfe. If you use chrome, when on the site you can translate. Sorry I cant post the link, but have to wait for 10 posts.
Tommy Top Drive said:
On your phone, go to Settings, About phone, Model number and verify it says HW-T18. If so go to google and do a search for "HW-T18 root" without the quotes. Should be the website android-hilfe. If you use chrome, when on the site you can translate. Sorry I cant post the link, but have to wait for 10 posts.
Click to expand...
Click to collapse
I have this same phone, branded "insmat rock v5". This is same as Utano barrier t180, agm rock v5, caterpillar b10, texet tm-3200r, hw-t18 etc.
But seems to be near impossible to root. Tried to load "update.zip" (also tried different versions of this superuser) via sd-card as instructions for those mentioned phones say. Managed to hard-boot phone by pressing vol-down and pwr. Phone gives red screen with text "welcome update" with white letters, and that's it.. Nothing happens then. Doesn't take key presses after that. But when i take battery out and back, then boots normally, but still without superuser.
from phone:
model info: hw-t18
android version: 2.3.5.
kernel: 2.6.35.11-perf
software version:QC_7x27_T18I_VERI_03011_120918
BASEBAND version:QC_7x27_T18I_VERI_03005_120918
What to try next to root this?
e: managed to install and reboot superuser update.zip via "droid explorer"
rooting
Hello,
Do you allready manage to root the Utano?
If not there is a succesfull description on a german site.
Boomkweker said:
Hello,
Do you allready manage to root the Utano?
If not there is a succesfull description on a german site.
Click to expand...
Click to collapse
Can you pls give the link to this site?
wookario said:
Can you pls give the link to this site?
Click to expand...
Click to collapse
The post is on a site android-hilfe with the extension de. I'm not allowed to post outgoing links. You can search for Utano barrier root zugriff. It's in a post of 29-06-2012 by Wolk. When you have problems with the translations I can help.
I hope this question is appropriate for this subforum, but before I void my warranty, I want to know *exactly* what is going on in my device so that I am prepared if something goes wrong.
On my locked TF700 (via adb) I get this:
Code:
[email protected]:/ $ su
[email protected]:/ # cat /proc/partitions
major minor #blocks name
179 0 62087168 mmcblk0
179 1 786432 mmcblk0p1
179 2 438272 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 835584 mmcblk0p4
179 5 5120 mmcblk0p5
179 6 512 mmcblk0p6
179 7 5120 mmcblk0p7
179 8 59976192 mmcblk0p8
8 0 31166976 sda
8 1 31162880 sda1
[email protected]:/ # hexdump -C /dev/block/mmcblk0 | head -3
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00380000 41 4e 44 52 4f 49 44 21 dc d0 3d 00 00 80 00 10 |ANDROID!..=.....|
[email protected]:/ #
I already know what the important partitions are, and that there are no visible partition entries for bootloader, recovery and kernel. But if I dump mmcblk0 directly, shouldn't I be able to see the code of the bootloader in the first few blocks? Where the BCT, PT and EBT partitions should be according to the NVFlash layout, I read only zeros.
Can someone with unlocked bootloader, root and busybox installed please run the hexdump line from above and tell me if you get more than all zeros before offset 00380000?
My output:
Code:
[email protected]:/ # hexdump -C /dev/block/mmcblk0 | head -3
00000000 0b 72 0f 00 78 09 33 ef 99 6f 51 bf b0 6b 39 8c |.r..x.3..oQ..k9.|
00000010 4b e8 ff 0a 96 ce ce e1 34 8c 8a 89 0b b1 c3 6f |K.......4......o|
00000020 53 ec 76 61 ba 77 f1 af 61 eb 51 10 b6 96 bb 06 |S.va.w..a.Q.....|
Sent from my ASUS Transformer Pad TF700T using XDA Premium HD app
BossMafia2 said:
My output
Click to expand...
Click to collapse
Thanks! This proves that the unlocked bootloader "un-hides" the data at the beginning of the eMMC. However it looks encrypted, I expected a lot more zeros.
Can someone else try the same command and check if you get the same or a completely different output?
Alternatively, could maybe some developer explain to me what unlocking does in detail?
[email protected]:/ # hexdump -C /dev/block/mmcblk0 |head -3
00000000 8b 8d 9e 8f ff ff ff ff 00 01 00 00 a0 05 00 00 |................|
00000010 f3 43 fa 12 9c b6 e6 f2 07 ea 37 ad 9b c0 6d 3e |.C........7...m>|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
above all is my output,I also have such a problem just like you ,my tablet is crappy and even the offical does not want to release the rom for us!and recently they updated system from 1.05 to 1.07,and it's very frustrating that they didn't correct any bugs but gave us 4.1.1 system ,and the power battery consuming problem is still exist since they updated system to 1.05!!
I want to grab bootloader from device nand,but no solution till now!
first of all ,you should know that my tablet is not asus tf700
my tablet's info.
I have a rooted galaxy tab 3 7" device
major minor #blocks name
179 0 15388672 mmcblk0
179 1 61440 mmcblk0p1
179 2 128 mmcblk0p2
179 3 256 mmcblk0p3
179 4 512 mmcblk0p4
179 5 2048 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 12800 mmcblk0p8
179 9 8192 mmcblk0p9
179 10 13952 mmcblk0p10
179 11 3072 mmcblk0p11
179 12 3072 mmcblk0p12
179 13 10240 mmcblk0p13
179 14 10240 mmcblk0p14
179 15 10240 mmcblk0p15
179 16 7160 mmcblk0p16
179 17 3072 mmcblk0p17
179 18 8 mmcblk0p18
179 19 8192 mmcblk0p19
179 20 12288 mmcblk0p20
179 21 1740800 mmcblk0p21
179 22 512000 mmcblk0p22
179 23 16384 mmcblk0p23
179 24 20480 mmcblk0p24
179 25 12926959 mmcblk0p25
179 32 62367744 mmcblk1
179 33 62366720 mmcblk1p
The command for hex dump with the head -3 wasn't eventful so here is the beginnings of my blk0:
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001c0 00 00 ee 00 00 00 01 00 00 00 ff 9f d5 01 00 00 |................|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART....\...|
00000210 d2 06 97 6c 00 00 00 00 01 00 00 00 00 00 00 00 |...l............|
00000220 ff 9f d5 01 00 00 00 00 22 00 00 00 00 00 00 00 |........".......|
00000230 de 9f d5 01 00 00 00 00 32 1b 10 98 e2 bb f2 4b |........2......K|
00000240 a0 6e 2b b3 3d 00 0c 20 02 00 00 00 00 00 00 00 |.n+.=.. ........|
00000250 80 00 00 00 80 00 00 00 51 a4 95 d5 00 00 00 00 |........Q.......|
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7 |......3D..h..&..|
00000410 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000420 00 20 00 00 00 00 00 00 ff ff 01 00 00 00 00 00 |. ..............|
00000430 00 00 00 00 00 00 00 00 6d 00 6f 00 64 00 65 00 |........m.o.d.e.|
00000440 6d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |m...............|
00000450 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
...
07600000 41 4e 44 52 4f 49 44 21 88 ad 64 00 00 80 20 80 |ANDROID!..d... .|
07600010 5a 4a 2a 00 00 00 20 82 00 00 00 00 00 00 10 81 |ZJ*... .........|
07600020 00 01 20 80 00 08 00 00 00 00 00 00 00 00 00 00 |.. .............|
07600030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
07600040 63 6f 6e 73 6f 6c 65 3d 6e 75 6c 6c 20 61 6e 64 |console=null and|
07600050 72 6f 69 64 62 6f 6f 74 2e 68 61 72 64 77 61 72 |roidboot.hardwar|
07600060 65 3d 71 63 6f 6d 20 75 73 65 72 5f 64 65 62 75 |e=qcom user_debu|
07600070 67 3d 33 31 00 00 00 00 00 00 00 00 00 00 00 00 |g=31............|
07600080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
mine also shows zeros, even though it's unlocked:
[email protected]:/ # busybox hexdump -C /dev/block/mmcblk0 | head -3
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00380000 41 4e 44 52 4f 49 44 21 6c 68 38 00 00 80 00 10 |ANDROID!lh8.....|
<><sharkcow><>
Hi Everyone!
Attached to this post I have created an excel file which contains what I know to date about the various partitions on the HTC One S (as you will see its not a lot). It includes brief and more lengthy descriptions, as well as what img and other files flash to those partitions from RUUs and OTA updates. It also includes some information I have gathered by viewing various partitions with a hex editor.
As you can see, this file is far from complete (as my own knowledge of these matters is similarly lacking). Some information may also be incorrect. I wanted to share this file in the hopes that developers and other members who may have more knowledge than I can contribute to making this file better, so that we can all understand our HTC One S's and what makes it tick.
If you want to assist this project, please feel free to post updated versions of this file to this thread. I will then merge those updates onto a master file and update the Original Thread with that info for easy access for others.
First I want to thank SneakyGhost who has already shared a basic text file with some information about some of the partitions on his public dropbox. (Sneaky, let me know and I can share that public dropbox on this link too if you see fit). We can let this post evolve with more development information too based on peoples suggestions.
Original Version 01/10/2013
-First draft with good info from SneakyGhost and very basic n00b stuff from AKToronto
Developers & Members Who Contributed:
SneakyGhost
[others to follow i hope]
Just wondering, is there any different between mmpcblk0p* and mmcblk0p* because when getting file from phone we type dd if=/dev/block/mmcblk0p* not mmpcblk0p*.... thx
Hello,
Here is some information I recieved from touch of jobo. Some of it might help.
1 emmc: (no) ruu: sbl1-?.img
2 emmc: (no) ruu: sbl2.img
3 emmc: (no) ruu: (no) data: PGFS, securoty, simlock, simunlock
4 emmc: (no) ruu: (no) data: htc-board-info, cid, imei
5 emmc: (no) ruu: (no) data: htc-board-info, cid, imei
6 emmc: (no) ruu: (no) data: macaddr, devid, imei, ..
7 emmc: (no) ruu: (no) data: PGFS, sbl2_update, sbl3, rpm,tz, ..
8 emmc: (no) ruu: (no) empty
9 emmc: (no) ruu: sbl3.img
10 emmc: (no) ruu: rpm.img
11 emmc: (no) ruu: tz.img
12 emmc: (no) ruu: hboot.nb0
13 emmc: (no) ruu: (no) data: htc-security-rec
14 emmc: (no) ruu: splash1.nb0 data: raw rgb565 540x960x2
15 emmc: (no) ruu: (no) empty
16 emmc: dsps ruu: (no) empty
17 emmc: radio ruu: radio.img mount: /firmware/radio vfat (fat16)
18 emmc: adsp ruu: adsp.img mount: /firmware/q6 vfat (fat16)
19 emmc: wcnss ruu: wcnss.img mount: /firmware/wcnss vfat (fat12)
20 emmc: radio_config ruu: rcdata.img @+0x10018C
21 emmc: boot ruu: boot_signed.img, bootable
22 emmc: recovery ruu: recovery_signed.img, bootable
23 emmc: misc ruu: (no) mostly empty, FNOC, FNOC
24 emmc: modem_st1 ruu: (no) data looks compressed or encrypted
25 emmc: modem_st2 ruu: (no) data looks compressed or encrypted
26 emmc: devlog ruu: (no) mount: /devlog ext4
27 emmc: (no) ruu: (no) empty
28 emmc: pdata ruu: (no) empty
29 emmc: (no) ruu: (no) empty
30 emmc: local ruu: (no) empty
31 emmc: extra ruu: (no) empty
32 emmc: (no) ruu: (no) empty
33 emmc: system ruu: system.img mount: /system ext4
34 emmc: cache ruu: (no) mount: /cache ext4
35 emmc: data ruu: (no) mount: /data ext4
36 emmc: fat ruu: (no) mount: /mnt/sdcard fat32
Rsotbiemrptson
cat2115 said:
Just wondering, is there any different between mmpcblk0p* and mmcblk0p* because when getting file from phone we type dd if=/dev/block/mmcblk0p* not mmpcblk0p*.... thx
Click to expand...
Click to collapse
No difference. Just a type-o on my part. Thx for the correction!
Rsotbiemrptson said:
Hello,
Here is some information I recieved from touch of jobo. Some of it might help.
1 emmc: (no) ruu: sbl1-?.img
2 emmc: (no) ruu: sbl2.img
3 emmc: (no) ruu: (no) data: PGFS, securoty, simlock, simunlock
4 emmc: (no) ruu: (no) data: htc-board-info, cid, imei
5 emmc: (no) ruu: (no) data: htc-board-info, cid, imei
6 emmc: (no) ruu: (no) data: macaddr, devid, imei, ..
7 emmc: (no) ruu: (no) data: PGFS, sbl2_update, sbl3, rpm,tz, ..
8 emmc: (no) ruu: (no) empty
9 emmc: (no) ruu: sbl3.img
10 emmc: (no) ruu: rpm.img
11 emmc: (no) ruu: tz.img
12 emmc: (no) ruu: hboot.nb0
13 emmc: (no) ruu: (no) data: htc-security-rec
14 emmc: (no) ruu: splash1.nb0 data: raw rgb565 540x960x2
15 emmc: (no) ruu: (no) empty
16 emmc: dsps ruu: (no) empty
17 emmc: radio ruu: radio.img mount: /firmware/radio vfat (fat16)
18 emmc: adsp ruu: adsp.img mount: /firmware/q6 vfat (fat16)
19 emmc: wcnss ruu: wcnss.img mount: /firmware/wcnss vfat (fat12)
20 emmc: radio_config ruu: rcdata.img @+0x10018C
21 emmc: boot ruu: boot_signed.img, bootable
22 emmc: recovery ruu: recovery_signed.img, bootable
23 emmc: misc ruu: (no) mostly empty, FNOC, FNOC
24 emmc: modem_st1 ruu: (no) data looks compressed or encrypted
25 emmc: modem_st2 ruu: (no) data looks compressed or encrypted
26 emmc: devlog ruu: (no) mount: /devlog ext4
27 emmc: (no) ruu: (no) empty
28 emmc: pdata ruu: (no) empty
29 emmc: (no) ruu: (no) empty
30 emmc: local ruu: (no) empty
31 emmc: extra ruu: (no) empty
32 emmc: (no) ruu: (no) empty
33 emmc: system ruu: system.img mount: /system ext4
34 emmc: cache ruu: (no) mount: /cache ext4
35 emmc: data ruu: (no) mount: /data ext4
36 emmc: fat ruu: (no) mount: /mnt/sdcard fat32
Rsotbiemrptson
Click to expand...
Click to collapse
Really helpful. Will add in to the file. Do you know what he is refering to with the (no) tag?
AKToronto said:
Really helpful. Will add in to the file. Do you know what he is refering to with the (no) tag?
Click to expand...
Click to collapse
Hello,
I have no Idea what the (no) means.
Rsotbiemrptson
AKToronto said:
Really helpful. Will add in to the file. Do you know what he is refering to with the (no) tag?
Click to expand...
Click to collapse
* emmc: (no) means the partition is not listed in /proc/emmc. otherwise it states the parition name from /proc/emmc
* ruu: (no) means it does not contains an image from a ruu. otherwise it states the filename of the image from the ruu.
* data: something interesting or recognizable
* mount: /mount/point/when/booted/ filesystemtype
-Jobo
EDIT: /proc/partitions lists the number of blocks for each.
Hi guys!
Nice thread. Just found it cuz i had no partition list, no complete one at least. Good work.
Credits for the initial few partitions should go to Tecardo though, i think i got the numbers from him.
I have just finished a Script that dumps all partitions to PC, well, all but Radio, System, Kernel, Data, Cache and the empty ones.
I will make a Dump of my two devices (normal Ville and Taiwan Ville 64gb) so you can maybe add a partition list for the SE variant here too.
Since Tec has a RIFF Box now and my old bricked device, we can maybe work some stuff out.
If we find out more information on the Partitions we could input it here too if you like. Just let us know.
regards,
Sneaky
Sneakyghost said:
Hi guys!
Nice thread. Just found it cuz i had no partition list, no complete one at least. Good work.
Credits for the initial few partitions should go to Tecardo though, i think i got the numbers from him.
I have just finished a Script that dumps all partitions to PC, well, all but Radio, System, Kernel, Data, Cache and the empty ones.
I will make a Dump of my two devices (normal Ville and Taiwan Ville 64gb) so you can maybe add a partition list for the SE variant here too.
Since Tec has a RIFF Box now and my old bricked device, we can maybe work some stuff out.
If we find out more information on the Partitions we could input it here too if you like. Just let us know.
regards,
Sneaky
Click to expand...
Click to collapse
That works for me! Im happy for you guys to edit the file and post, and then I can update the OP with that file too! Whatever works! Thanks again!
One S SE Partitions
I've got the cat /proc/emmc readout now, which is surprisingly only showing a few partitions on the One S SE.
I am unsure if that is a reliable readout. There is no mention of an SD or hboot partition. The device might need to run an insecure boot and be rooted for a complete readout.
If anyone can tell me how to obtain a complete listing i would be grateful. Thanks.
Find the listing attached.
AKToronto: you might be willing to integrate that excel sheet into the existing as a second sheet? Thanks.
Let me know if i can do anything to obtain more info. I've got a normal and an SE here so no worries doing some messing about. I just need precise infos what to do because my time is very limited. Sorry.
One Notice concerning the use of Excel: i hope you guys are aware that you need to set cell formatting to text only before inserting any hex or decimal values as excel loves to reformat them for you and hence mess them up! I'd recommend a different program to collect this data. Can't imagine if anything goes wrong when flashing raw stuff because someone read the wrong numbers from the sheet lol. There's guys with linux and a RIFF Box out here who might go by the partition offsets lol...
Sneakyghost said:
I've got the cat /proc/emmc readout now, which is surprisingly only showing a few partitions on the One S SE.
I am unsure if that is a reliable readout. There is no mention of an SD or hboot partition.
Click to expand...
Click to collapse
That is normal. See my list. The ones that say "emmc: (no)" are not listed in /proc/emmc on the OneS. The ones that say: "ruu: something.img", I mapped out by dumping the partitions from the device and comparing to images extracted from a RUU. The one labeled 'fat' is the sdcard partition.
-Jobo
Thanks.
Please specify compare dump to RUU. Are the dumps identical to the images in a RUU? So a hash compare would do the trick?
Or how do you go about? I have UltraEdit with UltraCompare. I could also compare line-by-line...
Sneakyghost said:
Thanks.
Please specify compare dump to RUU. Are the dumps identical to the images in a RUU? So a hash compare would do the trick?
Or how do you go about? I have UltraEdit with UltraCompare. I could also compare line-by-line...
Click to expand...
Click to collapse
You can't do a hash compare, as the dump from your device is typically bigger than the image from the RUU, so it won't match. If you know exactly from which RUU the images on the device come (and you haven't flashed any special/extra partitions, you could do a byte-for-byte or line-by-line compare.
I did it a bit more 'visually'. If you see roughly the same stuff in roughly the same place, it is (most probably) the same kind of image. For example, these are not identical, but similar enough to know it's the same kind of thing, just a different version:
Code:
rpm.img from a RUU:
00006d00 40 30 06 00 70 b5 a8 20 06 f0 ff fd 1d 4c 07 23 |@0..p.. .....L.#|
00006d10 21 68 1d a2 05 f0 40 ff 21 68 1b 25 ad 01 49 19 |[email protected]!h.%..I.|
00006d20 c8 61 a8 20 06 f0 f1 fd 61 68 01 23 1a a2 05 f0 |.a. ....ah.#....|
00006d30 33 ff 61 68 49 19 c8 61 a8 20 06 f0 e6 fd a1 68 |3.ahI..a. .....h|
00006d40 09 23 19 a2 05 f0 28 ff a1 68 49 19 c8 61 a8 20 |.#....(..hI..a. |
00006d50 06 f0 db fd e1 68 03 23 17 a2 05 f0 1d ff e1 68 |.....h.#.......h|
00006d60 49 19 c8 61 a8 20 06 f0 d0 fd 21 69 05 23 16 a2 |I..a. ....!i.#..|
00006d70 05 f0 12 ff 21 69 49 19 c8 61 70 bc 08 bc 00 20 |....!iI..ap.... |
00006d80 18 47 00 00 24 a3 03 00 61 70 70 73 20 68 61 6e |.G..$...apps han|
00006d90 64 6c 65 72 00 00 00 00 6d 6f 64 65 6d 20 68 61 |dler....modem ha|
00006da0 6e 64 6c 65 72 00 00 00 6c 70 61 73 73 20 68 61 |ndler...lpass ha|
00006db0 6e 64 6c 65 72 00 00 00 72 69 76 61 20 68 61 6e |ndler...riva han|
00006dc0 64 6c 65 72 00 00 00 00 64 73 70 73 20 68 61 6e |dler....dsps han|
00006dd0 64 6c 65 72 00 00 00 00 70 b5 80 20 06 f0 95 fd |dler....p.. ....|
00006de0 1d 4c 08 23 21 68 1d a2 05 f0 f6 fb 21 68 1b 25 |.L.#!h......!h.%|
00006df0 ad 01 49 19 08 62 80 20 06 f0 87 fd 61 68 02 23 |..I..b. ....ah.#|
00006e00 1a a2 05 f0 e9 fb 61 68 49 19 08 62 80 20 06 f0 |......ahI..b. ..|
00006e10 7c fd a1 68 0a 23 19 a2 05 f0 de fb a1 68 49 19 ||..h.#.......hI.|
00006e20 08 62 80 20 06 f0 71 fd e1 68 04 23 17 a2 05 f0 |.b. ..q..h.#....|
00006e30 d3 fb e1 68 49 19 08 62 80 20 06 f0 66 fd 21 69 |...hI..b. ..f.!i|
00006e40 06 23 16 a2 05 f0 c8 fb 21 69 49 19 08 62 70 bc |.#......!iI..bp.|
00006e50 08 bc 00 20 18 47 00 00 24 a3 03 00 61 70 70 73 |... .G..$...apps|
00006e60 20 63 68 61 6e 67 65 72 00 00 00 00 6d 6f 64 65 | changer....mode|
00006e70 6d 20 63 68 61 6e 67 65 72 00 00 00 6c 70 61 73 |m changer...lpas|
00006e80 73 20 63 68 61 6e 67 65 72 00 00 00 72 69 76 61 |s changer...riva|
00006e90 20 63 68 61 6e 67 65 72 00 00 00 00 64 73 70 73 | changer....dsps|
00006ea0 20 63 68 61 6e 67 65 72 00 00 00 00 06 28 12 d2 | changer.....(..|
00006eb0 78 44 00 79 00 18 87 44 02 04 06 08 0a 0c 07 a0 |xD.y...D........|
00006ec0 70 47 08 a0 70 47 09 a0 70 47 0a a0 70 47 0b a0 |pG..pG..pG..pG..|
00006ed0 70 47 0c a0 70 47 0d a0 70 47 00 00 41 50 53 53 |pG..pG..pG..APSS|
00006ee0 00 00 00 00 4d 50 53 53 5f 53 57 00 4c 50 41 53 |....MPSS_SW.LPAS|
00006ef0 53 00 00 00 52 49 56 41 00 00 00 00 44 53 50 53 |S...RIVA....DSPS|
00006f00 00 00 00 00 4d 50 53 53 5f 46 57 00 3c 75 6e 73 |....MPSS_FW.<uns|
mmcblk0p10 from my device:
00006d00 bc 08 bc 00 20 c0 43 18 47 a9 00 08 18 04 62 70 |.... .C.G.....bp|
00006d10 bc 08 bc 00 20 18 47 a4 a3 03 00 40 30 06 00 70 |.... [email protected]|
00006d20 b5 a0 20 06 f0 d3 fd 1d 4c 07 23 21 68 1d a2 05 |.. .....L.#!h...|
00006d30 f0 14 ff 21 68 1b 25 ad 01 49 19 c8 61 a0 20 06 |...!h.%..I..a. .|
00006d40 f0 c5 fd 61 68 01 23 1a a2 05 f0 07 ff 61 68 49 |...ah.#......ahI|
00006d50 19 c8 61 a0 20 06 f0 ba fd a1 68 09 23 19 a2 05 |..a. .....h.#...|
00006d60 f0 fc fe a1 68 49 19 c8 61 a0 20 06 f0 af fd e1 |....hI..a. .....|
00006d70 68 03 23 17 a2 05 f0 f1 fe e1 68 49 19 c8 61 a0 |h.#.......hI..a.|
00006d80 20 06 f0 a4 fd 21 69 05 23 16 a2 05 f0 e6 fe 21 | ....!i.#......!|
00006d90 69 49 19 c8 61 70 bc 08 bc 00 20 18 47 00 00 70 |iI..ap.... .G..p|
00006da0 94 03 00 61 70 70 73 20 68 61 6e 64 6c 65 72 00 |...apps handler.|
00006db0 00 00 00 6d 6f 64 65 6d 20 68 61 6e 64 6c 65 72 |...modem handler|
00006dc0 00 00 00 6c 70 61 73 73 20 68 61 6e 64 6c 65 72 |...lpass handler|
00006dd0 00 00 00 72 69 76 61 20 68 61 6e 64 6c 65 72 00 |...riva handler.|
00006de0 00 00 00 64 73 70 73 20 68 61 6e 64 6c 65 72 00 |...dsps handler.|
00006df0 00 00 00 70 b5 80 20 06 f0 69 fd 1d 4c 08 23 21 |...p.. ..i..L.#!|
00006e00 68 1d a2 05 f0 f4 fb 21 68 1b 25 ad 01 49 19 08 |h......!h.%..I..|
00006e10 62 80 20 06 f0 5b fd 61 68 02 23 1a a2 05 f0 e7 |b. ..[.ah.#.....|
00006e20 fb 61 68 49 19 08 62 80 20 06 f0 50 fd a1 68 0d |.ahI..b. ..P..h.|
00006e30 0a 23 19 a2 05 f0 dc fb a1 68 49 19 08 62 80 20 |.#.......hI..b. |
00006e40 06 f0 45 fd e1 68 04 23 17 a2 05 f0 d1 fb e1 68 |..E..h.#.......h|
00006e50 49 19 08 62 80 20 06 f0 3a fd 21 69 06 23 16 a2 |I..b. ..:.!i.#..|
00006e60 05 f0 c6 fb 21 69 49 19 08 62 70 bc 08 bc 00 20 |....!iI..bp.... |
00006e70 18 47 00 00 70 94 03 00 61 70 70 73 20 63 68 61 |.G..p...apps cha|
00006e80 6e 67 65 72 00 00 00 00 6d 6f 64 65 6d 20 63 68 |nger....modem ch|
00006e90 61 6e 67 65 72 00 00 00 6c 70 61 73 73 20 63 68 |anger...lpass ch|
00006ea0 61 6e 67 65 72 00 00 00 72 69 76 61 20 63 68 61 |anger...riva cha|
00006eb0 6e 67 65 72 00 00 00 00 64 73 70 73 20 63 68 61 |nger....dsps cha|
00006ec0 6e 67 65 72 00 00 00 00 06 28 12 d2 78 44 00 79 |nger.....(..xD.y|
00006ed0 00 18 87 44 02 04 06 08 0d 0a 0c 07 a0 70 47 08 |...D.........pG.|
00006ee0 a0 70 47 09 a0 70 47 0d 0a a0 70 47 0b a0 70 47 |.pG..pG...pG..pG|
00006ef0 0c a0 70 47 0d a0 70 47 00 00 41 50 53 53 00 00 |..pG..pG..APSS..|
00006f00 00 00 4d 50 53 53 5f 53 57 00 4c 50 41 53 53 00 |..MPSS_SW.LPASS.|
out of thanks already...
Gotcha. Thanks.
Did it for testing purposes with mmcblk0p1 from JB One SSE and mmcblk0p1 from ICS One S and they both are fairly similar so i can tell by using UltraCompare that it is the same partition type.
I now dumped all One SSE partitions successfully apart from the SD and the UserData got stuck, it never finished. But all others dumped fine. Will start looking into them when i get time.
For now, Partition 1 is same. That's what i can already say lol.
[EDIT]
Userdata (0p35) didn't get stuck. I aborted it and then found an image on the SD which was already 7,5 GB big. I believe the Data Partition is quite large on the SE.
Will update the OP soon. Sorry Ive been a bit busy with kernels
Nevermind.
Tecardo's gonna help me with doing a writeback-script, just in case you already read my request here. Thanks.
Sneakyghost said:
Nevermind.
Tecardo's gonna help me with doing a writeback-script, just in case you already read my request here. Thanks.
Click to expand...
Click to collapse
I was going to suggest you take a bootsplash zip and modify it .. but got ninja'd.
AW: [PARTITION LIST] Partition Information and RUU/OTA Files,Work In Progress, 01/10/
On the One S special edition the sdcard is mapped to /data/media. It's mounted differently, also the recovery can't mount the sdcard as mass storage or partition.
Interesting. A very minor difference in the otherwise totally identical partition layout...
sent from viper 2.1
The same title. I want to use 1 license for multiple devices but max of license just for 1 device. To use it for multiple devices I need to check what information the software receives from the device (example: android id, imei, android version,...). Then fake the 2nd device information into the first device's information. But when I check, the information is encoded into strings that are difficult to understand. So I want to ask what kind of encryption is that, and the data after decrypted. Below is an image of the encrypted string that the software checks my device information. Please help me.
"htttp://arteam.pro/log-sys/?data=Qcdw1B9CILI+xcDA7mY9v/wSuMPEvvjr3H72jMubzO3MaWWONvTbZc34J+qxHq1tNYSVhJezLBJM4EuapwTqhqqtCcxCWA6+Dai9lm99D32nj+RqIuvN3Z3QE7ezJ4ZFrLn8QsUEFka7x6DDQj4ekQJbyuQ+prf80PDh7kSWTfzllQq9munu/9UKCg1XolmtY5EDRPxMU99nnPkrAf5lmfOkeVMV4Bn1yR/o0vUPopQ="
The data parameter is some binary data encoded in base64. I used
Bash:
$ echo "Qcdw1B9CILI+xcDA7mY9v/wSuMPEvvjr3H72jMubzO3MaWWONvTbZc34J+qxHq1tNYSVhJezLBJM4EuapwTqhqqtCcxCWA6+Dai9lm99D32nj+RqIuvN3Z3QE7ezJ4ZFrLn8QsUEFka7x6DDQj4ekQJbyuQ+prf80PDh7kSWTfzllQq9munu/9UKCg1XolmtY5EDRPxMU99nnPkrAf5lmfOkeVMV4Bn1yR/o0vUPopQ=" | base64 -d - | tee decode.bin
and opened that in Bless. It's using some kind of encryption, output below in hex.
Code:
41 C7 70 D4 1F 42 20 B2 3E C5 C0 C0 EE 66 3D BF
FC 12 B8 C3 C4 BE F8 EB DC 7E F6 8C CB 9B CC ED
CC 69 65 8E 36 F4 DB 65 CD F8 27 EA B1 1E AD 6D
35 84 95 84 97 B3 2C 12 4C E0 4B 9A A7 04 EA 86
AA AD 09 CC 42 58 0E BE 0D A8 BD 96 6F 7D 0F 7D
A7 8F E4 6A 22 EB CD DD 9D D0 13 B7 B3 27 86 45
AC B9 FC 42 C5 04 16 46 BB C7 A0 C3 42 3E 1E 91
02 5B CA E4 3E A6 B7 FC D0 F0 E1 EE 44 96 4D FC
E5 95 0A BD 9A E9 EE FF D5 0A 0A 0D 57 A2 59 AD
63 91 03 44 FC 4C 53 DF 67 9C F9 2B 01 FE 65 99
F3 A4 79 53 15 E0 19 F5 C9 1F E8 D2 F5 0F A2 94
Good luck decrypting it. Considering this is an app with such highly restrictive license terms, I'm sure the devs have heavily guarded the code against reverse engineering. The best way to deal with this imo is to just find an alternative if one exists.
The binary data encoded in base64 is difficult to understand.
This is a continuation of a previous thread which diverted from it's original topic (see here @CryptMan @MrCrayon). Making the tablet work with Android 11 again was done successfully by flashing persist.img but the widewine l3 status didn't change even after re-locking the bootloader und the stock ROW firmware.
Stuff I/we know:
Flashing a different persist.img can apparently cause the level to drop to L3 (see here)
In my case it presumably was caused by unlocking but not fixed by relocking the bootloader.
Another user got L3 on the J716F model but without unlocking the bootloader. Commenters suggest using the QCN file from a l1 certified tablet (see here)
I flashed persist.img from the latest 62X firmware and upgraded via OTA to 63X (not hosted yet) (see here)
I once selected "erase all before download" (attempt to fix bootloop, stupid for sure!) which probably wiped important parts of my QCN file.
The QCN file seems to hold the devices fingerprint.
L1 can be achieved using Magisk and certain module(s) but I haven't tried this since that's not for everyone.
Stuff I don't know:
does the loss of SN, MAC, BT, PN cause widewine L3 or do you have already recovered it as described by another thread? (see here)
Does L1 work if downgrade to 62X - the ROM I extracted the persist.img from and don't do the OTA?
L1 can be achieved using Magisk which might be a lot easier. Is this solution "stable" and can't be broken by Google snapping their fingers?
is it possible to have widewine L1 but safetynet not passing (regarding Magisk)?
Note: the category is neither question nor development, but dev seems a better fit as this will drive less people here who confuse this as a howtoguide and don't have anything to contribute.
The thread will be changed to a howtoguide once we found a solution.
MateUserHHTT said:
I once selected "erase all before download" (attempt to fix bootloop, stupid for sure!) which probably wiped important parts of my QCN file.
Click to expand...
Click to collapse
Yeah, I also did this. And then my SN, PN, MAC etc. where gone. Also the device certification!
I'm very sure that this option in QFIL causes damage to QCN and (!) wipe some important data(partition).
I have compared some partitions from J606F (working, L1) with my J706F (damaged QCN, L3) and I found a partition named "secdata" which is empty on the J706F.
I made a copy of this from the 606 and it looks like this partition stores certificates (SSL/TLS).
Then I tried to write this to the 706, but this results in soft-brick. The 706 only boots to 9008 mode. And it stays there even if I delete the secdata partition again, very strange.
CryptMan said:
And it stays there even if I delete the secdata partition again
Click to expand...
Click to collapse
Damn, that's bad. In Germany we have a saying that translates to "No Backup, no pity" but I wouldn't think about backing up empty partitions either. Did you erase it or format it afterwards? Maybe you could create an empty image of fitting size with dd filled with zeros? Also: did you check that the secdata partition actually existed on the J706F? If so, was it empty or could it be that you had no read permissions? And was the file size of the image you flashed fitting? I think it doesn't matter because fastboot doesn't overwrite other partitions (has a failsafe) but I'm not sure of that.
I have access to a J706L (model with sim-slot) but I can only access it in a "reading" way (tablet of a friend...).
I put it into FFBM but it didn't show up in QFIL at the same machine I used for my J706F. I'll check the drivers and attempt again. I guess that's our best bet on restoring L1 without rooting it.
My J606F (the working one) in FFBM is also NOT visible to QFIL.
BUT if it is fully booted to system (and USB debug is anabled) THEN it is seen as "901D" device and I was able to read QCN.
This secdata partition is presend on J706F but filled with 0x00.
Size is 28.672 bytes, on both devices.
I used QFIL "Partition Manager" for reading and writing, And wiped the whole GPT there as last restort to restore function after flash of secdata soft-bricked the J706F.
The thing is, while "persist" is part of the ZIP file the secdata is NOT.
The secdata of J606F (the working one) looks like a linux binary/executable:
Code:
00000000h: 7F 45 4C 46 02 01 01 00 00 00 00 00 00 00 00 00 ; ELF............
00000010h: 00 00 28 00 01 00 00 00 00 F0 FF 45 00 00 00 00 ; ..(......ðÿE....
Later in the file/partition you can find this, please pay attention to the strings "Attestation", "Root CA" and "General Use Root Key":
Code:
000012a0h: 02 42 4A 31 11 30 0F 06 03 55 04 07 13 08 42 65 ; .BJ1.0...U....Be
000012b0h: 69 20 4A 69 6E 67 31 0F 30 0D 06 03 55 04 0B 13 ; i Jing1.0...U...
000012c0h: 06 4C 45 4E 4F 56 4F 31 0F 30 0D 06 03 55 04 0A ; .LENOVO1.0...U..
000012d0h: 13 06 4C 45 4E 4F 56 4F 31 1E 30 1C 06 03 55 04 ; ..LENOVO1.0...U.
000012e0h: 03 13 15 4C 45 4E 4F 56 4F 20 41 74 74 65 73 74 ; ...LENOVO Attest
000012f0h: 61 74 69 6F 6E 20 43 41 30 1E 17 0D 32 30 30 38 ; ation CA0...2008
00001300h: 32 31 30 39 30 33 33 33 5A 17 0D 58 58 58 58 58 ; 21090333Z..XXXXX
00001310h: 58 58 58 58 58 58 58 58 30 5D 31 0B 30 09 06 03 ; XXXXXXXX0]1.0...
00001320h: 55 04 06 13 02 43 4E 31 0B 30 09 06 03 55 04 08 ; U....CN1.0...U..
00001330h: 13 02 42 4A 31 1D 30 1B 06 03 55 04 03 13 14 53 ; ..BJ1.0...U....S
00001340h: 65 63 54 6F 6F 6C 73 20 41 74 74 65 73 74 20 55 ; ecTools Attest U
00001350h: 73 65 72 31 0F 30 0D 06 03 55 04 0A 13 06 4C 45 ; ser1.0...U....LE
00001360h: 4E 4F 56 4F 31 11 30 0F 06 03 55 04 07 13 08 42 ; NOVO1.0...U....B
00001370h: 65 69 20 4A 69 6E 67 30 82 01 22 30 0D 06 09 2A ; ei Jing0‚."0...*
Code:
000016a0h: 42 4A 31 11 30 0F 06 03 55 04 07 13 08 42 65 69 ; BJ1.0...U....Bei
000016b0h: 20 4A 69 6E 67 31 1D 30 1B 06 03 55 04 0B 13 14 ; Jing1.0...U....
000016c0h: 47 65 6E 65 72 61 6C 20 55 73 65 20 52 6F 6F 74 ; General Use Root
000016d0h: 20 4B 65 79 31 0F 30 0D 06 03 55 04 0B 13 06 4C ; Key1.0...U....L
000016e0h: 45 4E 4F 56 4F 31 0F 30 0D 06 03 55 04 0A 13 06 ; ENOVO1.0...U....
000016f0h: 4C 45 4E 4F 56 4F 31 19 30 17 06 03 55 04 03 13 ; LENOVO1.0...U...
00001700h: 10 4C 45 4E 4F 56 4F 20 52 6F 6F 74 20 43 41 20 ; .LENOVO Root CA
00001710h: 31 30 1E 17 0D 32 30 30 34 30 39 30 36 31 38 35 ; 10...20040906185
00001720h: 36 5A 17 0D 58 58 58 58 58 58 58 58 58 58 58 58 ; 6Z..XXXXXXXXXXXX
00001730h: 58 30 6F 31 0B 30 09 06 03 55 04 06 13 02 43 4E ; X0o1.0...U....CN
00001740h: 31 0B 30 09 06 03 55 04 08 13 02 42 4A 31 11 30 ; 1.0...U....BJ1.0
00001750h: 0F 06 03 55 04 07 13 08 42 65 69 20 4A 69 6E 67 ; ...U....Bei Jing
00001760h: 31 0F 30 0D 06 03 55 04 0B 13 06 4C 45 4E 4F 56 ; 1.0...U....LENOV
00001770h: 4F 31 0F 30 0D 06 03 55 04 0A 13 06 4C 45 4E 4F ; O1.0...U....LENO
00001780h: 56 4F 31 1E 30 1C 06 03 55 04 03 13 15 4C 45 4E ; VO1.0...U....LEN
00001790h: 4F 56 4F 20 41 74 74 65 73 74 61 74 69 6F 6E 20 ; OVO Attestation
000017a0h: 43 41 30 82 01 22 30 0D 06 09 2A 86 48 86 F7 0D ; CA0‚."0...*†H†÷.
Code:
00001af0h: 1B 06 03 55 04 0B 13 14 47 65 6E 65 72 61 6C 20 ; ...U....General
00001b00h: 55 73 65 20 52 6F 6F 74 20 4B 65 79 31 0F 30 0D ; Use Root Key1.0.
00001b10h: 06 03 55 04 0B 13 06 4C 45 4E 4F 56 4F 31 0F 30 ; ..U....LENOVO1.0
00001b20h: 0D 06 03 55 04 0A 13 06 4C 45 4E 4F 56 4F 31 19 ; ...U....LENOVO1.
00001b30h: 30 17 06 03 55 04 03 13 10 4C 45 4E 4F 56 4F 20 ; 0...U....LENOVO
00001b40h: 52 6F 6F 74 20 43 41 20 31 30 1E 17 0D 32 30 30 ; Root CA 10...200
00001b50h: 34 30 39 30 36 31 37 34 38 5A 17 0D 58 58 58 58 ; 409061748Z..XXXX
00001b60h: 58 58 58 58 58 58 58 58 5A 30 81 89 31 0B 30 09 ; XXXXXXXXZ0‰1.0.
00001b70h: 06 03 55 04 06 13 02 43 4E 31 0B 30 09 06 03 55 ; ..U....CN1.0...U
00001b80h: 04 08 13 02 42 4A 31 11 30 0F 06 03 55 04 07 13 ; ....BJ1.0...U...
00001b90h: 08 42 65 69 20 4A 69 6E 67 31 1D 30 1B 06 03 55 ; .Bei Jing1.0...U
00001ba0h: 04 0B 13 14 47 65 6E 65 72 61 6C 20 55 73 65 20 ; ....General Use
00001bb0h: 52 6F 6F 74 20 4B 65 79 31 0F 30 0D 06 03 55 04 ; Root Key1.0...U.
00001bc0h: 0B 13 06 4C 45 4E 4F 56 4F 31 0F 30 0D 06 03 55 ; ...LENOVO1.0...U
00001bd0h: 04 0A 13 06 4C 45 4E 4F 56 4F 31 19 30 17 06 03 ; ....LENOVO1.0...
00001be0h: 55 04 03 13 10 4C 45 4E 4F 56 4F 20 52 6F 6F 74 ; U....LENOVO Root
00001bf0h: 20 43 41 20 31 30 82 01 22 30 0D 06 09 2A 86 48 ; CA 10‚."0...*†H
The strings "Attestation", "Root CA" and "General Use Root Key": make me think two things.
First this cloud be the device certification.
Second this looks like a "normal" SSL/TLS certification process.
But what I do NOT understand is why does the flashing of this partions soft-bricks the device?
Security behavior?
CA of J606F does NOT match J706F?
In the first case, we need to know HOW to write this.
In the second case, we need a backup of this from a J706F.
Also in second case, we need to know if this partition is device specific!
Because if Lenovo run's the ROOT-CA it is no big deal for them to chain this secdata to the device serial while generation this specific for any device they make.
In this case, we are lost ... very lost ...
My j716f has screwed up serial and widevine is L3..I deleted all in qfil..the Chinese guys didn't sort it out..maybe restoring serial number will restore widevine..
CryptMan said:
Also in second case, we need to know if this partition is device specific!
Because if Lenovo run's the ROOT-CA it is no big deal for them to chain this secdata to the device serial while generation this specific for any device they make.
In this case, we are lost ... very lost ...
Click to expand...
Click to collapse
Since I have two working J706F I'm probably in the best position to check this.
I can also do some other checking but I'll have to wait the weekend.
{Mod edit: Quoted post deleted}
I just skimmed it quickly but it looks like that's only to restore L1 in Netflix when you still have L1 in the device, is that right?
The problem here is for those people that lost L1 in the device (not only Netflix)
MrCrayon said:
I just skimmed it quickly but it looks like that's only to restore L1 in Netflix when you still have L1 in the device, is that right?
The problem here is for those people that lost L1 in the device (not only Netflix)
Click to expand...
Click to collapse
No, it was L3 before, checked by DRM info app.
{Mod edit: Quoted post deleted}
If I understand this correct, then changed just to "GB" instead of there real region, logged in in Google and then the device was L1 again?!
That sounds a bit too simple, but yeah I could try that.
May on weekend, for now I have seen all the install, configuration and import/export data options a but too often ...
MrCrayon said:
Since I have two working J706F I'm probably in the best position to check this.
I can also do some other checking but I'll have to wait the weekend.
Click to expand...
Click to collapse
That would be great if you can compare the partitions, thank you.
One other thing, I found was a file called "factory rescue zip" for the P11, sadly not for free download but free for an different Lenovo device.
So I downloaded that one to have look inside. And in that Zip file I found a file called "sec.dat". Which looks differend, but hey it's from different device.
If that "factory rescue zip" for the P11 also contains this "sec.dat", may this could be another route to go?
f1tm0t said:
No, it was L3 before, checked by DRM info app.
Click to expand...
Click to collapse
What was the cause of L1 loss?
In my and CryptMan's case it's most likely due to the fact we checked "erase all before download" in QFIL.
CryptMan said:
If I understand this correct, then changed just to "GB" instead of there real region, logged in in Google and then the device was L1 again?!
Click to expand...
Click to collapse
Just now I flashed clean ZUI with GB region and I have L1
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
MateUserHHTT said:
What was the cause of L1 loss?
In my and CryptMan's case it's most likely due to the fact we checked "erase all before download" in QFIL.
Click to expand...
Click to collapse
I never checked "erase all before download". L3 and "device not certified by Google" came after unlocking bootloader in my cases (rich expirience)
f1tm0t said:
I never checked "erase all before download". L3 and "device not certified by Google" came after unlocking bootloader in my cases (rich expirience)
Click to expand...
Click to collapse
Sadly losing L1 when you unlock bootloader is normal.
Relocking bootloader should bring back L1 unless something else has been erased/changed.
f1tm0t said:
I never checked "erase all before download"
Click to expand...
Click to collapse
Then the way you restored your L1 will most likely not help us. But thank you anyways.
@CryptMan
I tried Partition Manager but it's giving me Sahara error, can't read packet header.
It's probably because I'm using VirtualBox on Linux but before I try in a Windows machine I wanted to clarify something.
When I clcik on Partition Manager it asks me to verify if the correct firehose file is selected (or something like that), do I need to select prog_firehose_ddr.elf from the current ROM installed in the device or any ROM is OK?
MateUserHHTT said:
I flashed persist.img from the latest 62X firmware and upgraded via OTA to 63X (not hosted yet) (see here)
Click to expand...
Click to collapse
I never had a 63x ota, what's the full version?
P.S.
I noticed prog_firehose_ddr is slightly differente between last global and CN, so I guess current ROM would be better
@MrCrayon
I have always used the latest version of prog_firehose_ddr from the latest firmware ZIP.
As far as I understand this concept, firehose will be loaded to the SoC and must "only" match to it because it is executed there. After successfully loading/running firehose on the SoC the whole communication between PC and SoC/Flash uses Qualcomm sahara protocol to transfer data.
I have a Z3X box, and was successfull in using the firehose from the firmware ZIP. Official Z3X does NOT support the P11, but firehose/sahara is generic communication with Qualcomm devices so it was possible to read partitions with this tool too.
Running QFIL in VMware (or some other virtual machine) is always a very bad idea. I was never successful while doing this.
Best way is to always connect the device directly.
@MrCrayon
Oh, one more very very important thing!
Be very very careful when using the partition manager!
Do NEVER click on "erase" or "load" there is no "Are you sure what you are doing?" the tool just to the job!
Using "Read" is no problem.
To get to this dialog, you have to right click on the partition you want to work with and select the first option "manage partition data".
MrCrayon said:
I never had a 63x ota, what's the full version?
Click to expand...
Click to collapse
Build number: TB-J706F_630185_220128_ROW
Kernel ver.: 4.14.190-perf+
Android ver.: 11.
This version came with WeChat and GG (some chinese app) preinstalled. Including a "Tablet Center" with options like "protect your devices from accidetnal damage", "ADP One" or "Depot Support". Usually each points results in "No Internet connection" (which ain't true) or some other error message.
The title at the top-left corner says "Tablet Center{Test Only}" so I kinda feel like I received an update I wasn't supposed to receive
Good news for Linux users I used https://github.com/bkerler/edl and it worked perfectly.
To print partitions I used:
Bash:
edl printgpt --memory=ufs
and to back them up I used:
(--skip did not work so make sure you have 130GB of free space and 50 minutes)
Bash:
edl rl dump_folder --memory=ufs --genxml --skip=super,userdata
I was not expecting it but secdata is the same
fpinfo.bin contains selected region, SN and PN.
Anything else I can check?
@MrCrayon
Cool. Thank you very much.
I have flashed your file to my J706F, the good news is ... it still boots up (unlike my try with the secdata from J606, which resultet in soft-brick).
The bad news is ... it does not change anything for Widevine .
May you could post your QCN but with overwritte SN and 2nd part of all MAC adresses?
Or can I send you mine to compare if some options my missing?
Best regards