fusee-launcher
fusee-launcher copied to clipboard
Qyriad
Issues Exploiting a T124 device
Hello,
I am trying to run this exploit on my Shield Tabled a t124 based device. I think that I manage to enter in the right mode by pressing vol up and power on, lsusb reports "0955:7f40" but the function read_device_id returns "device is bussy".
On the other hand I have tried to run the special GET_STATUS directly but I only can see on the return buffer a 0x82 followed by many 0's. Does this mean that this device boot rom is fixed? this device is older than the discovery of the bug so that would be weird.
I see in your report that you manage to perform an special GET_STATUS on a t124 I would be really grateful if you could provide more info about how did you do it.
I would like to use this exploit to get the boot keys to use nvflash and do some experimentation with this tablet.
I think that I manage to enter in the right mode by pressing vol up and power on, lsusb reports "0955:7f40" but the function read_device_id returns "device is bussy".
This sounds like something else currently has control over the USB device (or possibly like your user doesn't have enough permissions to work with the device / unbind kernel drivers / apply configurations). Does it still happen if you run it as a privileged user (e.g. with sudo)?
On the other hand I have tried to run the special GET_STATUS directly but I only can see on the return buffer a 0x82 followed by many 0's.
This seems like a possible outcome -- the GET_STATUS request should read a bunch of data from the device's stack; depending on the location of the temporary variable where it keeps the device's status, you'll see very different data back from the device (including possibly a lot of zeros, if your request was long enough to overwrite the area you're seeing).
I'd try the GET_STATUS with a shorter request -- try setting a length of e.g. 1000 bytes and see what you get back. When I provide a request to a Shield Tablet with a length of 1000, I get the following back:
I see in your report that you manage to perform an special GET_STATUS on a t124 I would be really grateful if you could provide more info about how did you do it.
There's nothing really special, here. It's the same as the launcher for the X1; you just may need to reposition things in memory to get the exploit to work. :)
Thank you so much for your answer. Finally I review my steps and looks like I copy paste a wrong vid:pid to the code... 😅
I can get now the device ID but unfortunately when I try to load the payload I get a time out. Since I would like to focus on get a valid get_status part I have commented out this part.
Also I realised that I was trying to print out the get_status bufer immediately after the summit_ubr was send.
Now I am sending a USBDEVFS_REAPURB with its own urb structure and fixing the buffer length to 2+8 but for some reason I am getting and exception when I try to send this op.
Would you mind to tell me which software are you using to dump the USB traffic? I was planning to give a shot to wireshark/usbmon but it captures too much traffic and it is more oriented to networks
Hello,
After some peak and poke I have manage to progress a little bit with this. Using your code and the team overflow 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 team overflow 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 modifies 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?
Hi,
Finally I manage to load some trash on my T124 using the EP1, address are different: USB_BUF0: 0x40004000 USB_BUF1: 0x40008000 RCM_PAYLOAD: 0x4000e000
Also looks like the RCM messages length restrictions are anyhow different. I used the Nvidia TegraRCM to figure out how to format a correct message that was accepted by EP1
Also I found the right amount of data that need to be copy to smash the stack thanks to a tip that was provided by shuffle2.
Since then I have been doing several test, loading a very basic payload that provokes a warm reset. I would expect that if the payload is loaded correctly the device would go out of the APX mode and then lsusb would not list the APX dev. However I have failed with this.
The most basic way that I tried to load the payload was sending a payload with the program at the beginning (after some 0 padding for the RCM header) and then fill the rest of the payload with the RCM_PAYLOAD addresses. I can see that the payload was loaded because it was return on the GetStatus message but lsusb still showing the device.
Any idea how can I test if the code is running? Can you see any mistake on my suppositions?
The code is available at: https://github.com/LordRafa/shofel2/tree/t124 (I use shofel2 as a base but I have been using both projects as reference)
@LordRafa What's your progress about exploiting t124? I think I have the same device Shield Tablet but only available at RCM mode, and wants to bootup linux with this exploit.
Unfortunately I never manage to replicate the fusegelee exploit on this device.
My plan was to use a jtag to stop the boot cpu and read the memory, to verify if everything was working proporly on a jetson tk1 board but the right jtag adaptor is as much as expensive as the shield tablet. I tried some cheap jtag adapter with openocd without luck...
I have made a fork of the original shofEL2 modifying it a little bit... still no luck I would say that there is no way to smash the program stack, at this point I think that I have hit a dead end. If anyone feel curious about what I did it can be found here: https://github.com/LordRafa/ShofEL2-for-T124