[Nexus 7 Q&A, Help & Troubleshooting] xornibblovsky:
Reflashing Nexus 7 in APX mode, Ubuntu, Gentoo(uclibc/dietlibc), TWRP, hard bricked , sbkdetect , sbkcheck , sbk key

At the begining it was a word :) and the word was 2 bytes :) and half-nibble.

I have

Nexus 7 (bootloader unlocked), TWRP installed, and Ubuntu installed with

fastboot erase boot

fastboot flash boot raring-preinstalled-desktop-armhf+nexus7.bootimg

fastboot erase userdata

fastboot flash userdata raring-preinstalled-desktop-armhf+nexus7.img

fastboot reboot

At the beginning it was fully operational ubuntu.

I wanted to compile gentoo with optimized flags and libs - uclibc/dietlibc and to compare benchmarks with ubuntu and android.

Before experimenting I maked full backup of all partitions.

dd if=/dev/mmcblk0p1 bs=8M | nc -l -p 777

and from computer nc 192.168.0.4 777 > p1

I did the same command for p2, p3, p4, p5, p6, p7, p8, p9, boot1, boot0.

And I backuped /dev/mmcblk0 , which contained all those partitions.

I wanted to understand how it structured on the tablet.

In the process of experimenting first sectors from 0 to 64 was zeroed.

I tried to restore the device in APX mode.

Info about device:

On the box:

Nexus7 ASUS 1B/T30L/16/1G/V , CSSN:015d3248bb080218, SN:CBOKBC595625

Model ME370T , Made in China

[greped from dmesg]

Tegra Revision: A03 SKU: 0x83 CPU Process: 2 Core Process: 0

I checked most of the messages from the forum related to reflashing and restoring

soft/hard bricked tablets.

I tried to restore the device with sdk for Tegra3(for Nexus7) from developer site - developer.nvidia.com.

I registered and got SDK - Tegra Android DEveloper Pack 2.0 for windows. Then I tried to run it.

Several big files was created (there are look like files in nakasi-xxx-firmare-xxx) ,

and process stoped at moment of flashing.

Then I tried to reflash the device under linux.

usb-device

T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 20 Spd=480 MxCh= 0

D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1

P: Vendor=0955 ProdID=7330 Rev=01.03

S: Manufacturer=NVIDIA Corp.

S: Product=APX

C: #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=32mA

I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)

The easiest way to prepare the device is running

"udevadm monitor" and pressing and holding the button/buttons until You'll see the message

"add" from udevadm.

I founded that the device in my situation, started with any of following combinations

PwrUp/PwrUp+Vol_+/PwrUp+Vol_.

You can check it with

usb-device | egrep "NVIDIA|APX"

I tried to run different nvflash programs and found working one:

Nvflash v1.8.90246 / 1197539 Bytes / md5sum

d0f1fdada0508d77906d89098ad60091 nvflash

I tried

nvflash --rawdevicewrite 0 64 0_64.dat --bl bl --go

to restore zeroed sectors. It not working without correct sbk key.

I sniffed usb data with wireshark for different sbk keys and found this:

Then device is powering

GET DESCRIPTOR / Data / A.P.X

GET DESCRIPTOR / Data / N v i d i a C o r p 0x2e 0x00

SET CONFIGURATION Request

SET CONFIGURATION Response

URB_BULK in

URB_BULK out / Leftover Capture Data / 180208bb48325d01 // this is CSSN from end to beginning

URB_BULK out / Leftover Capture Data / 1028 Bytes -- generated by nvflash using some func(CSSN)

0x04 0x04 0x00 0x00 and 16 bytes and rest is 0x00

URB_BULK in 0x04 0x00 0x00 0x00

URB_BULK out / Leftover Capture Data / 4096 Bytes

When I tried different sbk keys, I got different answers from the device - those 4096 bytes

of leftover_captured_data. I realized then after checking ONE wrong sbk key , I needed to reboot the device (power off/power on).

And I received next messages:

rcm version 0X4

Command send failed (usb write failed)

You can check URB status in wireshark after running nvflash.

If key is wrong , You'll get "Broken pipe" EPIPE.

I tried

nvflash --format_all --go

in the hope that I do not needed sbk key. In

www_patentmaps_com/topic/Handling_of_secure_storage_key_in_always_on_domain_1.html developers told that

In some cases You do not need to know sbk key for reflashing the device .

And I tried manual decryption

# trying to check if decryption is correct with some generated sbk keys

#

#0xF0D1E800 0x74DB0700 0x7C20E402 0x9839F903

openssl aes-128-cbc -K F0D1E80074DB07007C20E4029839F903 -iv 0 -d -in bct.enc -out bct.dcr -nopad

# incorrect sbk key 0xF0D1E80074DB07007C20E4029839F903

bct.dcr suppouse to look like bct structure

if You need to find more info about manual decryption check showthread.php?t=1698560

even if You have correct decrypted buffer and encrypted buffer , AES are not susceptible to

known-plaintext attacks.

Solution 0 ) Send it to ASUS (read the warranty before)

( in my case i still need that sbk key for deleveloping purpose and I hope

that key will be added to sdk)

Solution 1 ) The are couple of algorithms of generating sbk key from CSSN

usualy it a simple formula and we need to guess that constants

Solution 2 ) Reverse engineering of usb protocol.

Part of the code in the device, that responsible for usb protocol can be vulnerable.

ASUS BIOS developers is good, but a chance exist.

This is a new device on the market. My guess - that part of code can be common for

many models - they just recompile that for different models.

This joke for that developers:

If constructors will build the houses , like programers writing the

programs, then the first flying woodpecker will destroy the civilization.

For now, I am checking algorithms of generation of sbk key.

[ I still looking for any infos about generation sbk from CSSN ]

[ I trying to restore formula of generation sbk key from nvflash that I have ]

[ You can help me with posting every nvflash that you have ]

I tried sbkcheck but I get segmentation fault // solution - found the proper

libusb or better ask sbkcheck.c from author and recompile it.

if You can't get sbkcheck.c then analyze sbkcheck

readelf -a ./sbkcheck > sbkcheck._

objdump -d ./sbkcheck > sbkcheck.dump

./sbkcheck: file format elf32-i386

[cutted]

8048d25:	a1 84 a4 04 08	mov 0x804a484,%eax

8048d2a:	89 c2	mov %eax,%edx

8048d2c:	b8 41 8f 04 08	mov $0x8048f41,%eax [ offset 0x0000f41 in ./sbkcheck ] Error in bulk transfer

8048d31:	89 54 24 0c	mov %edx,0xc(%esp)

8048d35:	c7 44 24 08 17 00 00	movl $0x17,0x8(%esp)

8048d3c:	00

8048d3d:	c7 44 24 04 01 00 00	movl $0x1,0x4(%esp)

8048d44:	00

8048d45:	89 04 24	mov %eax,(%esp)

8048d48:	e8 4b fa ff ff	call 8048798 <fwrite@plt>

8048d4d:	b8 ff ff ff ff	mov $0xffffffff,%eax

8048d52:	eb 70	jmp 8048dc4 <main+0x35a>

8048d54:	c7 44 24 04 00 00 00	movl $0x0,0x4(%esp)

8048d5b:	00

8048d5c:	8b 44 24 64	mov 0x64(%esp),%eax

8048d60:	89 04 24	mov %eax,(%esp)

8048d63:	e8 70 fa ff ff	call 80487d8 <libusb_release_interface@plt>

8048d68:	8b 44 24 4c	mov 0x4c(%esp),%eax

8048d6c:	3d 01 00 02 00	cmp $0x20001,%eax !!!!! if $0x20001 getted from device !!!!

8048d71:	75 0e	jne 8048d81 <main+0x317>

8048d73:	c7 04 24 6b 8f 04 08	movl $0x8048f6b,(%esp) [ offset 0x0000f6b in ./sbkcheck ] Detected SBKv2

8048d7a:	e8 39 fa ff ff	call 80487b8 <puts@plt>

8048d7f:	eb 1a	jmp 8048d9b <main+0x331>

8048d81:	c7 04 24 7a 8f 04 08	movl $0x8048f7a,(%esp) [ offset 0x0000f7a in ./sbkcheck ] Detected SBKv1

8048d88:	e8 2b fa ff ff	call 80487b8 <puts@plt>

[cutted]

I wanted to find the difference between sbkv1 and sbkv2 and sbkv3.

And I still looking for sources of sbkcheck.c and Sbkdetect.c or latest

sbkcheck/Sbkdetect

I found some info about tegrarcm () - for reflashing with u-boot bootloader but

It does not supported locked devices with an encrypted boot key, only

open devices such as the ventana, cardhu, or dalmore reference boards.

git://nv-tegra.nvidia.com/tools/tegrarcm.git

and good infos at

http_download_nvidia_com/tegra-public-appnotes

developer_download_nvidia_com/tegra

I found patents info:

www_patentmaps_com/topic/Handling_of_secure_storage_key_in_always_on_domain_1.html

Handling of secure storage key in always on domain

and this pdf www_sourceconference_com/publications/bos12pubs/android-modding-source.pdf

SBK of a Tegra device is leaked or predictable

P.S. Sorry for my bad bad English :)