Issues Exploiting a T124 device

[LordRafa]

Hello,

I am trying to exploit a Nvidia Shield using this method. I would like to see if I can recover the RCM keys to have a way to unbrick my device in order to perform some experiments that I would like to do with the bootloader.

After some peak and poke I have manage to progress a little bit with this. Using your code and ktemkin code I have manage to write a small script that collect the RCM ID using the EP1 and perform some Get Status calls to collect some info.

Looks like your code uses a GetStatus to collect some info from the device and perform a sanity check. When this sanity check is run on the T124 it fails. The parameters that are check are the SP and the USB buffer 2 address. I am supposing that since this is a different device these address could be different, hence I have modified the sanity check to match the returned values: 0x40008000 and 0x4000dcf4.

After a quick check on the values returned by the sanity GetStatus I found that there was a value of 0x40004000, I suppose that this could be the address for USB buffer 1.

Also I have succeed to execute a GetStatus for a big amount of data , hence I'am supposing that this call must be bugged and the exploit is running correctly.

However I have not succeed to load any payload to EP1. As soon as I try to write more than 0x1000 bytes to EP1 it stops to allow me to write more data (I have tried sending different amounts for the length field).

On the other hand as soon as I write any amount of data to EP1 (even if it is less than 0x1000, EP0 stops to answer.

I would say that the code that handles the RCM mode on the T124 is different and as soon as I send the first package it fails some validation that prevents to send anything else to the interface on both EPs.

Does anyone has any idea about how can I proceed? Is there any dump of the T124 iROM available?

[shuffle2]

I suggest you understand the bug, if you don't already. You can use it to dump a large amount of memory back to you over usb (shofel2 uses this a little as the sanity check function as you see already).

Generally, the straightforward way is to set the destination buffer to the higher address (0x40008000 in this case, I guess), and increase the size until the device stops responding. This likely means the memcpy just overwrote the return address on the stack. From there, you probably want to find a way to dump the full irom/iram out over usb or something.

I don't know if there's a T124 irom dump available.
Oh, for some reason I was thinking you were talking about the T214. For T124, I'm pretty sure the irom has been dumped and some people already got the exploit working....

[LordRafa]

Hello

yup finally I manage to load some trash on my T124 using the EP1, address are different:
BUF0: 0x40004000
BUF1: 0x40008000
Entry: 0x4000e000

and I was right (I guess) the T124 RCM implementation should be different. Following the execution trace for the official TegraRCM tool, after it sends a GET_DEVICE_ID, it sends another message: RCM_CMD_QUERY_RCM_VERSION which it doesn't follow the same sizing restrictions of the T210.

Using the TegraRCM tool I have generated a RCM_CMD_QUERY_RCM_VERSION message with a payload of 4094 0xAAs. Now I can see a lot of 0xAAs in my GET_STATUS response on EP0 (by sending only part of the message).

Thanks for the tip finding the return address on the stack, I am supposing the the entry point is 0x4000e000 because BUF1 and BUF2 are in total 0x2000 positions before comparing with T210 and because the tregrarcm tool load the miniloader at that address. I feel curious about why this difference but anyway.

Does anyone knows if there is any video buffer library for the T124 AVP already done so I can write and easy hello world?¿

[LordRafa]

Hum, checking the way that the payload is built I can see that it is padded with 0x1a3a*4 0s. Adding this amount to the buffer 1 adreess I can see that it would be needed 0x37c bytes more to overwrite the stack with the entry point. I suppose that this is because get_status copies part of the stack before it starts to copy the pay load, is this correct? On the t124 I can see only 0x30C bytes before the payload starts I am not sure why.

Also any ideas about how to get the right address for cbfs usb base? The 0x40003114 doesn't look to work... That supposing that I have calculated right the rest of the addresses......

[LordRafa]

I have tried to replace 0x40003114 by every single address between 0x40000000 and 0x40004000 on step of 4. The process that I follow was:

1. Reset the shield tablet power (using the help of an arduino) and read DeviceID from EP1
2. If step 1 succeed continue, otherwise fail
3. Create a Payload with a Header(big length) + 0 padding(0x59CC) + entry address (0x400139D1) * Supposing that get status reads 0x30C bytes before start to read the payload
4. Read cbfs.bin to a buffer and replace the bytes b'14310040' by an address between 0x40000000 and 0x40004000 (little endian format).
5. Add cbfs buffer to the payload
6. Padding the payload with 0s till it become multiply of 0x1000
7. Send the payload to the device on chunks of 0x1000 bytes
8. Execute get_status to smash the stack target (0x4000DCD8)
9. Try to read 8 bytes from EP1
10. Repeat from 1 till all address has been tested or no timeout has been gotten on step 9

Unfortunately I had no luck getting anything from EP1 which makes me think that probably I have made a mistake jumping to cbfs.bin or it has not been loaded properly

It is interesting that if I print the result of the getstatus for length=0x4000, I can only see the first 0x1000 values that I would expect (stack + beginning of the payload), after the first 0x1000 I can only see random values rather than the rest of the payload, initially I supposed that this was because getstatus is limited by the DMA buffer but now I am not sure.

At this point I run out of ideas about how to make this work on my shield k1, I would appreciate any comment