Hi ppl here is a guide on how to gain radio S-OFF, Super CID , SimUnlock
What You Need
-- This File
-- If on OSX / Linux ADB binary (they are not included in the .zip)
-------------------------------------------------------------------------------------------
Bits in red Are Only for people who dont already have perm root
Bits in Blue are for everyone
-------------------------------------------------------------------------------------------
1) Extract the zip file (to your adb directory if on mac / linux)
2) Open a command prompt / shell and navigate to your where you extracted the files
3) run
adb install visionaryplus-r14.apk
Click to expand...
Click to collapse
4) open visionary on phone
5) tick Run visionary.sh after root" and "set system r/w after root"
6) Now click "temproot now" and wait 30 - 60 sec
7) run line per line
adb push gfree /data/local
adb shell
su
cd /data/local
chmod 777 gfree
./gfree
sync
reboot
Click to expand...
Click to collapse
Now We Are Radio S-OFF and SuperCID + SimUnlocked
8) If you where not already perma rooted run visionary Temp root, then perm root.
[To Check]
1) run
adb reboot bootloader
Click to expand...
Click to collapse
ON SHIP HBOOT
Just check the top line if you see
SHIP S-OFF (it worked )
SHIP S-ON (it didnt )
ON ENG HBOOT
2) tap bootloder option
3) use vol down to get to system info and tap
4) check CID for CID-11111111 (if you have this all is done 100%)
5) reboot
[PROBLEMS]
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IF THIS DOESNT WORK AND U GET
***WARNING***: Did not find brq filter.
Click to expand...
Click to collapse
Get either a stock kernel CM/SENSE or my buzz-1.0.7 as its confirmed working on those
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
[FAQ]
Does this install the ENG hboot ?
No as that is no longer required, still an opition if you want to gain the extra functions
Click to expand...
Click to collapse
How can i install custom recovery for roms without ENG hboot ?
Just get rom manger from marked and install with that
Click to expand...
Click to collapse
What does all this mean ?
Radio S-OFF = we have s-off regardless or hboot we are using so if you update the hboot s-off will stay
Super CID = Allow to install RRU's from ANYONE
Click to expand...
Click to collapse
[CREDITS]
Paul O'Brien for visionary
scotty2 and others who found the method to patch P7
everyone else who has worked on the G2 root and wpthis
hey there, thanks for the guide but something didnt work while running ./gfree
Code:
./gfree
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.25-Buzz-1.0.6-OCUV
New .modinfo section size: 212
Attempting to power cycle eMMC... OK.
Searching for mmc_blk_issue_rq symbol...
- Address: c02ccc70, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02cc000
Kernel memory mapped to 0x40001000
Searching for brq filter...
- ***WARNING***: Did not find brq filter.
Patching and backing up partition 7...
after some seconds it rebooted on its own but nothing happened to my cid. any ideas?
same here
That will be the live kernel patching failing as it cant find where to patch .... try running with my 1.0.7 kernel and then restore back (shuld run on stock kernels)... as i know that works ill relay this info to scotty2 and see if he can fix for these kernels.
Can you post your kernel info from the about phone menu ?
Apache14 said:
Can you post your kernel info from the about phone menu ?
Click to expand...
Click to collapse
here it is
2.6.32.25-Buzz-1.0.6-OCUV
[email protected] #66
Sat Nov 27 18:38:35 GMT2010
Worked great
To verify all went well, do this:
Plug in your phone to your computer
In the Terminal/command line, type this:
PHP:
adb shell
this puts you in the phone's shell. now it's a simple matter of the following:
(note the # is your prompt. Don't type the "#". The lines without the # are returned by the phone.)
PHP:
# stop ril-daemon
# cat /dev/smd0 &
# echo -e 'ATE1\r' > /dev/smd0
0
#
# echo -e 'ATV1\r' > /dev/smd0
OK
# echo -e '[email protected]?\r' > /dev/smd0
@CID: 11111111
OK
echo -e '[email protected]?40\r' > /dev/smd0
# [email protected]?40
@SIMLOCK= 00
OK
#echo -e '[email protected]?AA\r' > /dev/smd0
[email protected]?AA
@secu_flag: 0
OK
It should look something like that anyway. It may look slightly different if you were typing while the computer was sending you back information.
Did it work? Here's what you're looking for:
@CID: 11111111 <--- this response means you have superCID! Congrats!
@SIMLOCK= 00 <--- this means your simlock is off. Mazel Tov!
@secu_flag: 0 <--- this means your radio is S-OFF. Hurrah!
Hi,
not work for me.
Code:
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Users\Administrator>d:
D:\>cd D:\Handy\HTC Desire HD\SuperCID
D:\Handy\HTC Desire HD\SuperCID>adb push gfree /data/local
adb server is out of date. killing...
* daemon started successfully *
1939 KB/s (683255 bytes in 0.344s)
D:\Handy\HTC Desire HD\SuperCID>adb shell
# su
su
# cd /data/local
cd /data/local
# chmod 777 gfree
chmod 777 gfree
# ./gfree
./gfree
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.25-Buzz-1.0.6-OCUV
New .modinfo section size: 212
Attempting to power cycle eMMC... OK.
Searching for mmc_blk_issue_rq symbol...
- Address: c02ccc70, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02cc000
Kernel memory mapped to 0x40001000
Searching for brq filter...
- ***WARNING***: Did not find brq filter.
Patching and backing up partition 7...
D:\Handy\HTC Desire HD\SuperCID>
with friendly greet
starbase64
For the moment
IF THIS DOESNT WORK AND U GET
***WARNING***: Did not find brq filter.
Get either a stock kernel CM/SENSE or my buzz-1.0.7 as its confirmed working on those
Hi,
now works (or not ), but system info is no longer available on bootloader
with friendly greet
starbase64
Yep it worked
Look at the top SHIP S-OFF
Hi,
but how i can see the SuperCID? System info?
with friendly greet
starbase64
starbase64 said:
Hi,
not work for me.
Code:
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Users\Administrator>d:
D:\>cd D:\Handy\HTC Desire HD\SuperCID
D:\Handy\HTC Desire HD\SuperCID>adb push gfree /data/local
adb server is out of date. killing...
* daemon started successfully *
1939 KB/s (683255 bytes in 0.344s)
D:\Handy\HTC Desire HD\SuperCID>adb shell
# su
su
# cd /data/local
cd /data/local
# chmod 777 gfree
chmod 777 gfree
# ./gfree
./gfree
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.25-Buzz-1.0.6-OCUV
New .modinfo section size: 212
Attempting to power cycle eMMC... OK.
Searching for mmc_blk_issue_rq symbol...
- Address: c02ccc70, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02cc000
Kernel memory mapped to 0x40001000
Searching for brq filter...
- ***WARNING***: Did not find brq filter.
Patching and backing up partition 7...
D:\Handy\HTC Desire HD\SuperCID>
with friendly greet
starbase64
Click to expand...
Click to collapse
Try with 1.07 kernel.
If it doesnt work try with stock kernel which works fine
I think only the ENG Hboot shows system info...
Flawless, cheers
starbase64 said:
Hi,
but how i can see the SuperCID? System info?
with friendly greet
starbase64
Click to expand...
Click to collapse
fastboot getvar all
So can we now flash radio's without fear of being locked down again?
Apache14 said:
fastboot getvar all
Click to expand...
Click to collapse
I love ur 1.0.6 kernell.
Can I flash 1.0.7, S-OFF radio, and then back 1.06??
yep u can flash official HTC RUUS / RADIO / HBOOT without any fear of loosing root
xmoo said:
I love ur 1.0.6 kernell.
Can I flash 1.0.7, S-OFF radio, and then back 1.06??
Click to expand...
Click to collapse
yep yep thats fine
Is there anyway to undo this? Incase of garanty issues?
dubstepshurda said:
Is there anyway to undo this? Incase of garanty issues?
Click to expand...
Click to collapse
S-OFF has nothing to do with legal or illigal.
In somecases when you send your phone for repair, they S-off it, and forget to remove it.
So just remove superuser, install stock rom. And don't matter S-ON or s-OFF
"ON ENG HBOOT
2) tap bootloder option
3) use vol down to get to system info and tap
4) check CID for CID-11111111 (if you have this all is done 100%)
5) reboot"
2) tap bootloader option You fotgot the A.
About:
No clicks radio s-off for console lovers
Requirements:
0. Rooted desire hd
1. jkoljo's Easy Radio tool v2_2.zip from this thread http://forum.xda-developers.com/showthread.php?t=857537
2. USB Debugging enabled. Connect charge only!
Steps:
0. unpack gfree from the above zip file
1. $ adb remount
2. $ adb push gfree /system/xbin
3. $ adb shell
4. # chmod 700 /system/xbin/gfree
5. # /system/xbin/gfree -s off
6. # rm -i /system/xbin/gfree # be sure that you are removing the right file
7. # exit
8. reboot the phone.
10x:
jkoljo for the tool
There is already a thread for gfree, it has all the necessary info in it.
WildsideUK said:
There is already a thread for gfree, it has all the necessary info in it.
Click to expand...
Click to collapse
second that, also puzzled as all your doing is using adb why linux specific?
Tried to do it. Failed. Can anybody help? :-(
Code:
[email protected]:~/Desktop/AndroidSDK/2.2/tools$ ./adb remount
remount succeeded
[email protected]:~/Desktop/AndroidSDK/2.2/tools$ ./adb push gfree /system/xbin
1713 KB/s (134401 bytes in 0.076s)
[email protected]:~/Desktop/AndroidSDK/2.2/tools$ ./adb shell
# chmod 700 /system/xbin/gfree
# /system/xbin/gfree -s off
--secu_flag off set
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.27-cyanogenmod
New .modinfo section size: 208
Attempting to power cycle eMMC... OK.
Searching for mmc_blk_issue_rq symbol...
- Address: c02b99a8, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02b9000
Kernel memory mapped to 0x40009000
Searching for brq filter...
- ***WARNING***: Did not find brq filter.
Patching and backing up partition 7...
patching secu_flag: 0
Done.
# rm -i /system/xbin/gfree
rm: remove '/system/xbin/gfree'? y
# exit
You have incompatible kernel, try it in some 1.32 based sense rom with buzz 1.1.4 kernel. 1.1.4 CM could be enough, though, so try it first.
Hi all,
I am serching the whole internet to findout how to build a Clockworkmod for LG P920.
This is what i got so far:
P920's boot.img and recovery.img are uImage format. it loads by uboot. and i can get info from it using uboot's mkimage -l command.
the uImage using by LG P920 is a Multi-File format.
this is the info of Clockworkmod 4.0.0.9 for LGP920:
PHP:
[email protected]:~/temp$ ./mkimage -l recovery-clockwork-4.0.0.9-p920.img.backup
Image Name: Image
Created: Sun Jul 10 03:55:14 2011
Image Type: ARM Linux Multi-File Image (uncompressed)
Data Size: 5149182 Bytes = 5028.50 kB = 4.91 MB
Load Address: 0x80008000
Entry Point: 0x80008000
Contents:
Image 0: 3325552 Bytes = 3247 kB = 3 MB
Offset = 00000050
Image 1: 1823618 Bytes = 1780 kB = 1 MB
Offset = 0032BEC0
i already get the Image 0 and Image 1 using dd withe command below:
PHP:
2018 dd if=recovery-clockwork-4.0.0.9-p920.img.backup of=ramdisk.img skip=3325632 bs=1 count=1823618
2019 dd if=recovery-clockwork-4.0.0.9-p920.img.backup of=kernel.img skip=80 bs=1 count=3325552
so am i right? and how to extra the ramdisk.img?
what i want to do is add external sd card support for this clockworkmod recovery. why the original clockwokmod just support for internal sdcard?
I am also try to find the kernel source for this device. where can i find it?
any help will do.... Thanks!
why do you ever need to build one when it already has one in Rom Manager? Just 2 cents, no expert here
precsmo said:
why do you ever need to build one when it already has one in Rom Manager? Just 2 cents, no expert here
Click to expand...
Click to collapse
the one in rommanager dont support external sdcard....
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.