UART and bootloader strap pinouts for recovery

tylerwhall · May 21, 2013

I started looking into bootloader-level recovery tonight before messing with the file system too much and potentially getting into a bad state. I couldn't find this information anywhere else.

UART pinout
J3 - 4 pin unpopulated header on the front of the board near the LED
Pin 1: 3.3v
Pin 2: TX
Pin 3: RX
Pin 4: GND
Bootloader and kernel console output comes out this port, but android doesn't start a shell.

Bootloader strap
On the back of the board in the center, there is an unpopulated button (U33). When jumped while the power button is pressed, this appears to put the bootloader into USB recovery mode. It enumerates with an nvidia vendor id. Presumably nvflash or tegrarcm could be used to unbrick the device.

I haven't done anything with the bootloader recovery since I haven't yet made a backup. I'm not sure how much of the functionality is allowed given the state of the production fuse, but I would think we could use this to at least get back to a stock state.

embeem · May 21, 2013

I had posted pretty much the same thing a few hours earlier over on the ouya forums - https://forums.ouya.tv/discussion/comment/11742/#Comment_11742

The good news about the bootloader is that none of the android partitions have any sort of signature, which means that the bootloader is effectively "unlocked", you can even do a "fastboot boot". The bad news is that there doesn't seem to be any sort of hotkey to enter the bootloader or recovery mode, although I did find that you could usually get into recovery with the sysrq, just press alt-sysrq-i a few times at bootup to crash the processes spawned by init and eventually it will reboot into recovery -- obviously this won't work if your ouya doesn't even boot that far, so be careful.

The button at u33 does get you into nvflash mode, but from what I can tell it's entirely useless since every command will return a 0x4; we'll need the secure boot key to actually get this working.

As far as backups, the OTA download contains an entire copy of the system and boot partitions, this can be flashed from recovery using adb sideload; rayman has posted a link to all the known OTA downloads over on this thread - http://xdaforums.com/showthread.php?t=2266629

rayman · May 22, 2013

tylerwhall said:
I started looking into bootloader-level recovery tonight before messing with the file system too much and potentially getting into a bad state. I couldn't find this information anywhere else.

UART pinout
J3 - 4 pin unpopulated header on the front of the board near the LED
Pin 1: 3.3v
Pin 2: TX
Pin 3: RX
Pin 4: GND
Bootloader and kernel console output comes out this port, but android doesn't start a shell.

Bootloader strap
On the back of the board in the center, there is an unpopulated button (U33). When jumped while the power button is pressed, this appears to put the bootloader into USB recovery mode. It enumerates with an nvidia vendor id. Presumably nvflash or tegrarcm could be used to unbrick the device.

I haven't done anything with the bootloader recovery since I haven't yet made a backup. I'm not sure how much of the functionality is allowed given the state of the production fuse, but I would think we could use this to at least get back to a stock state.

Sadly, no. The way nvidia does security means that you need to know the Secure Boot key (if set - but it is set on ouya) to even be able to communicate with the device through APX/nvflash.
As embeem mentions, it will return 0x4, which essentially means "go away, i don't know you" after which it goes into an almost turned off state where it refuses to do anything but restart. The SBK is an AES-128 key so it's essentially impossible (inpractical) to bruteforce it.

wolf849 · Jun 1, 2013

rayman said:
Sadly, no. The way nvidia does security means that you need to know the Secure Boot key (if set - but it is set on ouya) to even be able to communicate with the device through APX/nvflash.
As embeem mentions, it will return 0x4, which essentially means "go away, i don't know you" after which it goes into an almost turned off state where it refuses to do anything but restart. The SBK is an AES-128 key so it's essentially impossible (inpractical) to bruteforce it.

So what was the trick that you used/developed to bypass the encryption on TF101 B80+ / TF201 / TF701 ? As far as I know their bootloaders also required SBK, nevertheless you published tool that works with them even though SBK remain unknown, or am I wrong and misread something?

Cheers

rayman · Jun 1, 2013

wolf849 said:
So what was the trick that you used/developed to bypass the encryption on TF101 B80+ / TF201 / TF701 ? As far as I know their bootloaders also required SBK, nevertheless you published tool that works with them even though SBK remain unknown, or am I wrong and misread something?

Cheers

Black magic.

invisiblek · Jun 13, 2013

Well, not much capable in nvflash mode, can't get anything to work properly.

UART lets me see it boot up, and fail miserably. Sadly, nothing doing there either. Nothing I send to it seems to affect it.

Back story: I broke init. The sysrq trick doesn't work unless you're getting to init.

Boot log via UART:
http://pastebin.com/ENQYQbTS

It still responds to sysrq, but nothing I'm doing seems to do much. I can dump the memory, crash the system, reboot it, shut it down, all kinds of things. Here's the HELP for sysrq:

Code:

[   66.672046] SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z)

an easier list of sysrq commands:

Code:

alt + sysrq + [0-9] - set log level (doesn't seem to work)
alt + sysrq + B     - reboot
alt + sysrq + C     - crash
alt + sysrq + E     - terminate-all-tasks
alt + sysrq + F     - memory-full-oom
alt + sysrq + I     - kill-all-tasks
alt + sysrq + J     - thaw-filesystems
alt + sysrq + L     - show-backtrace-all-active-cpus
alt + sysrq + M     - show-memory-usage
alt + sysrq + N     - nice-all-RT-tasks
alt + sysrq + O     - poweroff
alt + sysrq + P     - show-registers
alt + sysrq + Q     - show-all-timers
alt + sysrq + S     - sync
alt + sysrq + T     - show-task-states
alt + sysrq + U     - unmount
alt + sysrq + W     - show-blocked-tasks
alt + sysrq + Z     - dump-ftrace-buffer

Some more detailed information on what these are: http://en.wikipedia.org/wiki/Magic_SysRq_key

Open to ideas!

DivinityCycle · Jun 14, 2013

This reminds me of the old Droid X I had years back, which had a locked bootloader.
Because of this, there had to be a special "boot to recovery" boot strapper installed onto the system.
We have full RW access to the Ouya's filesystem and software, so it would seem like the first thing the community should do is develop some sort of "successfully booted" flagging to make the system try to automatically drop into CWM in the event that it looks like the OS is broken.
Couldn't such a thing live in the boot.img, and thus be available even if some silly person formats their /system partition? (This has happened already, and so the guy pretty much bricked his Ouya)

invisiblek · Jun 14, 2013

DivinityCycle said:
This reminds me of the old Droid X I had years back, which had a locked bootloader.
Because of this, there had to be a special "boot to recovery" boot strapper installed onto the system.
We have full RW access to the Ouya's filesystem and software, so it would seem like the first thing the community should do is develop some sort of "successfully booted" flagging to make the system try to automatically drop into CWM in the event that it looks like the OS is broken.
Couldn't such a thing live in the boot.img, and thus be available even if some silly person formats their /system partition? (This has happened already, and so the guy pretty much bricked his Ouya)

My plan is to develop a sysrq key to write the appropriate bit(s) to SCRATCH0 and reboot. This would allow us to get into recovery via a simple keystroke. I've actually got it written but need to test it. Testing it would not be dangerous as it would normally boot the stock kernel/init.

Next week when I'm home I'll try to find a tester since I cannot test it (can't write anything to my mmcblk0)

This shouldn't be dangerous to test.

Sent from my SCH-I545 using Tapatalk 4 Beta

nchantmnt · Sep 15, 2013

Any news on uart? I guess I bricked my ouya.
I was testing my custom kernel, did forget to use fastboot boot instead of flash and now have nothing but a black screen. My linux machine doesn't recognize my ouya and I can't go to recovery. So at least knowing what is causing the issue would be helpful.

Do you mind giving me a short intro on uart?

I guess I need a usb/uart adapter? If yes, which one should I get?

Thanks in advance

Gesendet von meinem HTC One X+ mit Tapatalk 2

nchantmnt · Sep 20, 2013

anyone already saw this: http://xdaforums.com/showthread.php?t=2071626

did only have time to skimm it but might be useful to people with still working devices

aim is to get the sbk which should be - if i have understood it the right way - unique for each device as long as the company didn't burn in a fix sbk.

so maybe this will help us to save people from further bricks...as long as nvflash is usable via usb

dexter84 · Sep 21, 2013

Has anyone tested in on ouya ?

Sent from my iPad using Tapatalk - now Free

cronikman84 · Sep 21, 2013

Not yet i think...i know i won't be testing it on my OUYA no time soon, i don't feel like having my box BRICKED like nchantmnt does, screw this, it's too early to test this

, i wont even risk it, i dont feel like buying another OUYA for testing this...

nchantmnt · Sep 21, 2013

Hey... no pain no gain

Gesendet von meinem HTC One X+ mit Tapatalk 2

zondajag · Sep 21, 2013

I have an idea for a small usb device that could force the ouya into recovery mode using the keyboard combination mentioned below:
http://ouyabrew.com/how-to-put-ouya-in-recovery-mode/

Essentially my idea is to have a little usb circuit board with a micro controller that is smart enough to simulate a keyboard periodically sending the specified keypresses. When the ouya goes into recovery you would just yank out the dongle. I don't have any background technical knowledge in this stuff but this sounds like something Ben Heck could whip up (he is a legend).

Update: Looks like these are already a thing! this looks promising:

http://www.irongeek.com/i.php?page=...ke-dongle#So,_why_would_a_pen-tester_want_one

cronikman84 · Sep 22, 2013

zondajag said:
I have an idea for a small usb device that could force the ouya into recovery mode using the keyboard combination mentioned below:
http://ouyabrew.com/how-to-put-ouya-in-recovery-mode/

Essentially my idea is to have a little usb circuit board with a micro controller that is smart enough to simulate a keyboard periodically sending the specified keypresses. When the ouya goes into recovery you would just yank out the dongle. I don't have any background technical knowledge in this stuff but this sounds like something Ben Heck could whip up (he is a legend).

Update: Looks like these are already a thing! this looks promising:

http://www.irongeek.com/i.php?page=...ke-dongle#So,_why_would_a_pen-tester_want_one

this is a sweet idea, i wasn't aware of a programmable HID USB keystroke dongle...This would make things easier...i hope someone makes something out of this, this will solve the booting into recovery bigtime!!!

hecksagon · Sep 22, 2013

zondajag said:
I have an idea for a small usb device that could force the ouya into recovery mode using the keyboard combination mentioned below:
http://ouyabrew.com/how-to-put-ouya-in-recovery-mode/

Essentially my idea is to have a little usb circuit board with a micro controller that is smart enough to simulate a keyboard periodically sending the specified keypresses. When the ouya goes into recovery you would just yank out the dongle. I don't have any background technical knowledge in this stuff but this sounds like something Ben Heck could whip up (he is a legend).

Update: Looks like these are already a thing! this looks promising:

http://www.irongeek.com/i.php?page=...ke-dongle#So,_why_would_a_pen-tester_want_one

This would only work if the stock kernal is installed and the recovery partition is intact. If you lose you recovery partition you won't be able to boot recovery and get adb working, and if the kernel isn't the stock kernel the keyboard combo won't work.

nchantmnt · Sep 22, 2013

Also no use for broken init

Gesendet von meinem HTC One X+ mit Tapatalk 2

dexter84 · Sep 22, 2013

cronikman84 said:
Not yet i think...i know i won't be testing it on my OUYA no time soon, i don't feel like having my box BRICKED like nchantmnt does, screw this, it's too early to test this , i wont even risk it, i dont feel like buying another OUYA for testing this...

I don't think that this necessarily means bricking your device.
You could always try fastboot boot patched kernel and then try reading fuse values.

I was playing with this method to run Debian:
http://tuomas.kulve.fi/blog/2013/09/12/debian-on-ouya-all-systems-go/

It is an easy procedure and I've got it running. Unfortunately my USB hub is not working correctly with ouya (it's passive so voltage on USB can be low), so I didnt login into it, but you could use this method to try to extract sbk keys.

Sent from my iPad using Tapatalk - now Free

suruceanu.nick · Sep 24, 2013

nvflash

How About this : http://xdaforums.com/showthread.php?t=2455927 ????

nchantmnt · Sep 24, 2013

we first need to know if we do have a "masker sbk" or a device specific sbk.
for device-specific sbk this methode should work but only with a wheelie-enabled recovery for our device

don't try to flash any other recovery to your device or you're in danger of bricking it.
if you have access to the source and can add the required option for generating blob files to a working recovery image, then this should work for device specific sbks.

then you can use any uart-adapter/raspberry pi/etc. to connect to your device and make backup and flash partitions.
(NOTE: DO NOT USE YOUR PCS SERIAL OUTPUT - IT MIGHT DAMAGE YOUR DEVICE AND YOUR PC AS WELL... OH AND IT WILL NOT WORK)

if we do have any kind of masker-sbk i can only talk in theory:
you normally should be able to read out sbk from running system but this is of course prevented (in most cases by some kerner config).
i don't know exactly by what methode and what files exactly to change but I have read somewhere that you could make a custom kernel which doens't prevent read out of sbk. then fastboot boot boot.img, read out sbk and sould be good to go.
but praxis might be a good bit harde

... or maybe blob mehtode might work.

got important exams tomorrow but if anyone could send me link to wheelie-enabled n7 recovery i might take a look the next days.
maybe recovery-devs could make something out of it even earlier

UART and bootloader strap pinouts for recovery

Member

Member

Senior Recognized Developer

Senior Member

Senior Recognized Developer

Recognized Developer

Senior Member

Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

suruceanu.nick

Guest

Senior Member

Similar threads

Top Liked Posts