tegra30_debrick
tegra30_debrick copied to clipboard
tofurky
Tegra K1(T124) debrick?
I have a working payload to pass security check. It does work in my Tegra K1 board. Just one patched nvflash for t124 is missing
payload: ShofEL2-for-T124
this repo is only for tegra30. you can look at git history for the patched nvflash for details on what was changed: https://github.com/tofurky/tegra30_debrick/commits/master/utils/nvflash_v1.13.87205_miniloader_patched
basically, you need to identify the embedded miniloader binary(s) inside nvflash using a decompiler, see if there is one for k1 (the version of nvflash in this repo does not have it, i think), copy that miniloader to a file, decompile the miniloader, patch that, and then apply the patched miniloader to the nvflash binary.
./nvflash --getpartitiontable table --bl fastboot.bin --go
Nvflash 4.13.0000 started
BR_CID: 0x34xxxxxxxxxxxxxxxxxxxxxxx
#Originally starting with 0x64 has changed to starting with 0x34
rcm version 0X400001
System Information:
chip name: unknown
chip id: 0x40 major: 1 minor: 1
chip sku: 0x0
chip uid: 0x0xxxxxxxxxxxxxxxxxxxxxxx
macrovision: disabled
hdcp: disabled
jtag: disabled
sbk burned: false
board id: 0
warranty fuse: 0
dk burned: false
boot device: emmc
operating mode: 6 #It is strange(odm mode with pkc encrypt). It should have been 3 (develop board).
device config strap: 0
device config fuse: 0
sdram config strap: 0
RCM communication completed
downloading bootloader -- load address: 0x83d88000 entry point: 0x83d88000
sending file: fastboot.bin
- 594363/594363 bytes sent
fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader failed NvError 0x0
command failure/warning: bootloader download failed (bad data)
bootloader status: bootloader validation failed (code: 30) message: nverror:0xd0010 (0x1d0010) DownloadBootloader 995 flags: 0
It seems that the miniloader need be patched.
this repo is only for tegra30. you can look at git history for the patched nvflash for details on what was changed: https://github.com/tofurky/tegra30_debrick/commits/master/utils/nvflash_v1.13.87205_miniloader_patched
basically, you need to identify the embedded miniloader binary(s) inside nvflash using a decompiler, see if there is one for k1 (the version of nvflash in this repo does not have it, i think), copy that miniloader to a file, decompile the miniloader, patch that, and then apply the patched miniloader to the nvflash binary.
Okay, thank you. Thank you for your contribution
fwiw, the miniloader code was very similar to the boot rom from what i remember. they both did the same fuse checks; seems based on a shared codebase.
./nvflash --getbct --bct BCT.bin --configfile flash.cfg
Nvflash 4.13.0000 started
BR_CID: 0x34xxxxxx
rcm version 0X400001
Skipping BoardID read at miniloader level
System Information:
chip name: unknown
chip id: 0x40 major: 1 minor: 1
chip sku: 0x0
chip uid: 0x000xxxxxxxxxxx
macrovision: disabled
hdcp: disabled
jtag: disabled
sbk burned: false
board id: 0
warranty fuse: 0
dk burned: false
boot device: emmc
operating mode: 6
device config strap: 0
device config fuse: 0
sdram config strap: 0
RCM communication completed
retrieving bct into: BCT.bin
BCT.bin received successfully
Time taken for flashing 1 Secs
$ bct_dump BCT.bin
Version = 0x00400001;
BlockSize = 0x00004000;
PageSize = 0x00000200;
PartitionSize = 0x08000000;
OdmData = 0x7309c008;
.......
I have successfully obtained the BCT for my device. Unfortunately, due to my limited expertise, I was unable to locate the corresponding check fuse function for the Tegra T124 nvflash (v4.x).
However, I easily found the corresponding code in the nvflash for T30 (nvflash v1.x), perhaps this is due to the compiler. It's quite disappointing, but I will continue to look into it when I have time.
fwiw, the miniloader code was very similar to the boot rom from what i remember. they both did the same fuse checks; seems based on a shared codebase.
Indeed, that is the case.
maybe also look at https://github.com/NVIDIA/tegrarcm/blob/master/src/miniloader/tegra124-miniloader.h and tegrarcm rather than nvflash.
maybe also look at https://github.com/NVIDIA/tegrarcm/blob/master/src/miniloader/tegra124-miniloader.h and tegrarcm rather than nvflash.
tegrarcm --bct=BCT.bin --bootloader=u-boot.bin --loadaddr=0x80108000
bct file: BCT.bin
booloader file: u-boot.bin
load addr 0x80108000
entry addr 0x80108000
device id: 0x7f40
uid: 0x34xxxx
RCM version: 64.1
downloading miniloader to target at address 0x4000e000 (136920 bytes)...
miniloader downloaded successfully
Chip UID: 0x000xxx
Chip ID: 0x40
Chip ID Major Version: 0x1
Chip ID Minor Version: 0x1
Chip SKU: 0x1f (t124)
Boot ROM Version: 0x1
Boot Device: 0x2 (EMMC)
Operating Mode: 0x3 (developer mode)
Device Config Strap: 0x0
Device Config Fuse: 0x0
SDRAM Config Strap: 0x2
.......
BCT.bin sent successfully
u-boot.bin sent successfully
tegrarcm: error downloading bootloader: u-boot.bin: Input/output error
Yes, it seems that patching the fuse-checking function in this file has had an effect. However, the bootloader still cannot be loaded. Perhaps I should consider creating a completely open-source boot chain like hekate does. Since I found fuse checks in both fastboot.bin and uboot.bin, patching them was ineffective. Nvidia is too terrible. 😢
Since I found fuse checks in both fastboot.bin and uboot.bin, patching them was ineffective. Nvidia is too terrible. 😢
the fastboot bootloaders in this repo didn't have a fuse check that i encountered, but have a signature check which prevented flashing unsigned code (e.g. dumped ouya bootloader). it was necessary to patch it out for ouya. of course, it may be a different situation on the chip/board you're working with.
also - and forgive me because i am a bit rusty - the fastboot bootloaders here, when uploaded via nvflash, would start up in nv3pserver mode rather than fastboot mode. hence the convoluted steps to exit this mode for ouya to reflash via fastboot flash command.
have you tried replugging usb after uploading your bootloader and checking dmesg to see if it is actually enumerating to communicate via fastboot?
also - and forgive me because i am a bit rusty - the fastboot bootloaders here, when uploaded via nvflash, would start up in nv3pserver mode rather than fastboot mode. hence the convoluted steps to exit this mode for ouya to reflash via
fastboot flashcommand.have you tried replugging usb after uploading your bootloader and checking
dmesgto see if it is actually enumerating to communicate viafastboot?
It seems that no mode has been activated. Well, I'm thinking about ways to get rid of NVIDIA.
Wow, someone has managed to do it. https://github.com/lumingyu0423/tegra124_tegra132_debrick
Just use the ipatch payload.
./shofel2_t124 PAYLOAD ipatch_rcm.bin
Waiting T124 to enter RCM mode (ctrl-c to cancel). Note: root permission could be required.
K1 in RCM mode connected.
Chip ID: 0x80 0x84 0x04 0x16 0x00 0x00 0x00 0x0c 0x02 0xe1 0x0d 0x74 0x01 0x10 0x00 0x64
Hacky Get Status returned error... Probably the stack got smashed, Congrats :-)
Start receiving debug logs from device
Error: Fail receiving debug logs.
./nvflash_4.13.0000_miniloader_patched_fuze --bl fuze-bootloader.bin --getpartitiontable fuze_flash.cfg
Nvflash 4.13.0000 started
BR_CID: 0x34001001740de1020c00000016048480
rcm version 0X400001
System Information:
chip name: unknown
chip id: 0x40 major: 1 minor: 1
chip sku: 0x0
chip uid: 0x00000001740de1020c00000016048480
macrovision: disabled
hdcp: disabled
jtag: disabled
sbk burned: false
board id: 0
warranty fuse: 0
dk burned: false
boot device: emmc
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
RCM communication completed
downloading bootloader -- load address: 0x80108000 entry point: 0x80108000
sending file: fuze-bootloader.bin
- 666445/666445 bytes sent
fuze-bootloader.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
Succesfully updated partition table information to fuze_flash.cfg
Time taken for flashing 2 Secs