Related
Can anyone help me: I was do everything by the book (http://forum.xda-developers.com/viewtopic.php?t=24779&postdays=0&postorder=asc&start=0); I first run unlock tool v1.5, and I had "Input unlock code" problem after soft reset (code 00000000 does not work for me!), then I tried v1.6 using command prompt and prun with command: prun \xdadev_all_unlock-v1.6.exe -q -f, and I'm still getting this stupid "Input network code" messages. I tried this last step many times with and without SIM card, and nothing helped.. I can use PDA functions, but when I try to turn off flight mode...
This is c/p of log file:
xdadev_all_unlock started
xdadev_all_unlock started
device=PM10A
key found
ril ioctl 0xc2: 00000000
simlock answer: %SIMLOCK= 01
0
current lock status: 01
security answer:
000
security answer2:
at%LISTNETWORKCODE answer: 0
at%LISTNETSUBCODE answer: 0
at%LISTSPCODE answer: 0
at%LISTCORPORATECODE answer: 0
at%LISTSIMCODE answer: 0
+CFUN: 1
0
at%LISTIMSIRANGECODE answer: 0
at%CLEARNETWORKCODE answer:
at%CLEARNETSUBCODE answer:
at%CLEARSPCODE answer:
at%CLEARCORPORATECODE answer:
at%CLEARSIMCODE answer:
at%CLEARIMSIRANGECODE answer:
removing lock 01
htclock answer:
simlock answer:
invalid sim lock answer
xdadev_all_unlock done
ril ioctl 0xc2: 00000000
ril ioctl 0xc6: 00000000
Please help someone!!
Thanks.
P.S. Sorry on my bad English.
Have tried this one from the ftp as well: 07/13/2005 09:35 16,384 xdadev_all_unlock-v1.0.exe
Can't remember which one I used, but it worked perfectly.
Cheers, M
ThanX to everyone, I tried xdadev_all_unlock-v1.6 using prun about 15 times more, and I finally fix the problem!
Here's the last (Winner) log file:
xdadev_all_unlock started
device=PM10A
key found
ril ioctl 0xc2: 00000000
simlock answer: %SIMLOCK= 01
0
current lock status: 01
security answer:
000
security answer2:
at%LISTNETWORKCODE answer: 0
at%LISTNETSUBCODE answer: 0
at%LISTSPCODE answer: 0
at%LISTCORPORATECODE answer: 0
at%LISTSIMCODE answer: 0
at%LISTIMSIRANGECODE answer: 0
at%CLEARNETWORKCODE answer:
at%CLEARNETSUBCODE answer:
at%CLEARSPCODE answer:
at%CLEARCORPORATECODE answer:
at%CLEARSIMCODE answer:
at%CLEARIMSIRANGECODE answer:
removing lock 01
htclock answer:
simlock answer: 0
0
0
0
0
0
%SIMLOCK= 00
0
xdadev_all_unlock done
ril ioctl 0xc2: 00000000
ril ioctl 0xc6: 00000000
Does anyone know how to rebuild a system dll in rom after exporting it using viewimgfs tool?
I mean that after the exporting I have these files:
imageinfo.bin
imageinfo.txt
S000
S001
S002
S003
S004
...I would like to have xyz.dll.
Thanks.
Bye Sektor
I know
Just take any PE-editor, take an empty PE-file and insert there these sections while giving them base/RVA/size/etc from imageinfo.txt. And edit PE-header (resources/imports/etc). Of cause you'll get an unworking DLL, but you would be able to decompile it or extract resources.
It is easy to make a program that would automatically reconstruct such DLLs, but I'm too lazy for this.
Thanks for your reply.
Can I ask you another little help?
I'm trying to use Ida to decompile my S000 file: when I run it I choose ARM Processor as Processor Type and then it asks me information about ROM and Input file. The info required are:
ROM: ROM start address, ROM size
Input file: Loading address, File offset, Loading size
Using the data in the imageinfo.txt, attached below, I compile the form as following:
ROM start address: 0x01BD0000
ROM size: 0x0004A000
Loading address: 0x01BD1000
File offset: 0x00001000
Loading size: 0x00046158
...but Ida seems to not decompile it correctly.
Could you suggest me a good Pe-Editor?
Thanks in advance.
Bye Sektor
[imageinfo.txt]
Module name: ril.dll
e32_objcnt: 00000004
e32_imageflags: 0000212E
e32_entryrva: 000458FC
e32_vbase: 01BD0000
e32_subsysmajor: 00000005
e32_subsysminor: 00000001
e32_stackmax: 00010000
e32_vsize: 0004A000
e32_sect14rva: 00000000
e32_sect14size: 00000000
e32_timestamp: 5598523F
e32_unit[0].rva: 00045D40
e32_unit[0].size: 00001415
e32_unit[1].rva: 00045C24
e32_unit[1].size: 0000003C
e32_unit[2].rva: 00000000
e32_unit[2].size: 00000000
e32_unit[3].rva: 00049000
e32_unit[3].size: 00000DD8
e32_unit[4].rva: 00000000
e32_unit[4].size: 00000000
e32_unit[5].rva: 0004A000
e32_unit[5].size: 00001000
e32_unit[6].rva: 00001000
e32_unit[6].size: 0000001C
e32_unit[7].rva: 00000000
e32_unit[7].size: 00000000
e32_unit[8].rva: 00000000
e32_unit[8].size: 00000000
e32_subsys: 00000009
o32[0].o32_vsize: 00046155
o32[0].o32_rva: 00001000
o32[0].o32_psize: 00046158
o32[0].o32_dataptr: 20000201
o32[0].o32_realaddr: 01BD1000
o32[0].o32_flags: 60002020
o32[1].o32_vsize: 00000558
o32[1].o32_rva: 00048000
o32[1].o32_psize: 00000558
o32[1].o32_dataptr: 00000000
o32[1].o32_realaddr: 01C18000
o32[1].o32_flags: C0002040
o32[2].o32_vsize: 00000DD8
o32[2].o32_rva: 00049000
o32[2].o32_psize: 00000DD8
o32[2].o32_dataptr: 00000000
o32[2].o32_realaddr: 01C19000
o32[2].o32_flags: 40002040
o32[3].o32_vsize: 00001000
o32[3].o32_rva: 0004A000
o32[3].o32_psize: 00000920
o32[3].o32_dataptr: 10000000
o32[3].o32_realaddr: 00000000
o32[3].o32_flags: 42002042
there are lots of PE-editors, for example PEditor. Look at protools.cjb.net
Hey
A mate came from th UK to NZ and he gave me his orange SPV m500. He upgraded to the new M600 SPV
I tried the unlock application. I ran it on the phone and it said it was unlocked successfully but when I pop the new SIM in it does not work.
Here is the log file. When it comes to mobes, I am not an expert but I would appreciate any advice from the techies who know a thing or 2 about these mobiles. PLEASE PLEASE PLEASE.
The app I used was xdadev_all_unlock-v1.6.exe
I copied it to my phone and ran it. Was that the right way????
Here is my log file
*********************************
xdadev_all_unlock started
device=PM10B
key found
ril ioctl 0xc2: 00000000
simlock answer: %SIMLOCK= 05
0
current lock status: 05
security answer:
000
security answer2:
at%LISTNETWORKCODE answer: %NetworkCode: 23433F%NetworkCode: 00101F0
at%LISTNETSUBCODE answer: 0
at%LISTSPCODE answer: %SPCode: 000
at%LISTCORPORATECODE answer: 0
at%LISTSIMCODE answer: 0
at%LISTIMSIRANGECODE answer: 0
at%CLEARNETWORKCODE answer:
at%CLEARNETSUBCODE answer:
at%CLEARSPCODE answer:
at%CLEARCORPORATECODE answer:
at%CLEARSIMCODE answer:
at%CLEARIMSIRANGECODE answer:
removing lock 01
htclock answer:
removing lock 04
htclock answer:
simlock answer:
invalid sim lock answer
xdadev_all_unlock started
device=PM10B
key found
ril ioctl 0xc2: 00000000
simlock answer:
invalid sim lock answer
error getting current lock status
xdadev_all_unlock failed
ril ioctl 0xc2: 00000000
ril ioctl 0xc6: 00000000
xdadev_all_unlock done
ril ioctl 0xc2: 00000000
ril ioctl 0xc6: 00000000
xdadev_all_unlock started
device=PM10B
key found
ril ioctl 0xc2: 00000000
simlock answer: %SIMLOCK= 04
0
current lock status: 04
security answer:
000
security answer2:
at%LISTNETWORKCODE answer: 0
at%LISTNETSUBCODE answer: 0
at%LISTSPCODE answer: 0
at%LISTCORPORATECODE answer: 0
at%LISTSIMCODE answer: 0
at%LISTIMSIRANGECODE answer: 0
at%CLEARNETWORKCODE answer:
at%CLEARNETSUBCODE answer:
at%CLEARSPCODE answer:
at%CLEARCORPORATECODE answer:
at%CLEARSIMCODE answer:
at%CLEARIMSIRANGECODE answer:
removing lock 04
htclock answer:
simlock answer:
invalid sim lock answer
xdadev_all_unlock done
ril ioctl 0xc2: 00000000
ril ioctl 0xc6: 00000000
Hi,
I was curious to help, so I just gave it a try to my SPV M500 /aka HTC Magician, by the way)
It went great in less than a minute. I just copied xdadev_all_unlock-v1.6.exe to my SD card, then launched the app in the phone using file explorer. A pop up came after 20 seconds to confirm the phone had been successfully unlocked
You might give it another try, using the tool + info found on the link below. If still bad, you could try to hard reset and do the thing again...
http://forum.xda-developers.com/viewtopic.php?t=24779&highlight=xdadev
working!
thanx man
Hi mate, we have the same phones here at work, Orange SPV M500 but we use them with Vodafone GPRS sims, so we use the same program to unlock them. BUT I find that running it once doesn't always work, so I run it three times in a row, wait till you get the message on screen before re-running it and you will be fine mate.
i did with all instruction i copy to SD card then i got this info when i enter code it shows invalid plzz help
xdadev_all_unlock started
device=PM10B
key found
ril ioctl 0xc2: 00000000
simlock answer: %SIMLOCK= 05
0
current lock status: 05
security answer:
000
security answer2:
at%LISTNETWORKCODE answer: %NetworkCode: 23433F%NetworkCode: 00101F0
at%LISTNETSUBCODE answer: 0
at%LISTSPCODE answer: %SPCode: 000
at%LISTCORPORATECODE answer: 0
at%LISTSIMCODE answer: 0
at%LISTIMSIRANGECODE answer: 0
at%CLEARNETWORKCODE answer:
at%CLEARNETSUBCODE answer:
at%CLEARSPCODE answer:
at%CLEARCORPORATECODE answer:
at%CLEARSIMCODE answer:
at%CLEARIMSIRANGECODE answer:
removing lock 01
htclock answer:
removing lock 04
htclock answer:
simlock answer:
invalid sim lock answer
xdadev_all_unlock done
ril ioctl 0xc2: 00000000
ril ioctl 0xc6: 00000000
Click to expand...
Click to collapse
Hi,
I stumbled upon this a few days back:
http://bloggingthemonkey.blogspot.de/2014/06/fire-in-root-hole.html
This describes a CVE that Rob Clark discovered earlier this year. He did not create a root method using this as Towelroot was still working back then. He published some proof of concept code though:
https://github.com/robclark/kilroy
Now, Qualcomm created patches to fix this and published them here:
https://www.codeaurora.org/projects...can-change-the-iommu-page-table-cve-2014-0972
It also has been fixed in the official Android source:
https://android.googlesource.com/kernel/msm/+/android-4.4w_r8/drivers/gpu/msm/adreno.c (see Log)
I downloaded the latest source that Amazon provided for the FireTV:
https://kindle-src.s3.amazonaws.com/firetv_src_51.1.3.0_user_513011820.tar.bz2
The Linux kernel sources in there all have a timestamp from June 2014, I assume this is when they created this source bundle.
However, as example adreno.c has still a Copyright notice from only 2013. It looks like Amazon is working with older source code here. I also searched for the added lines of the patch and can not find them in there.
Please note that the latest FireTV firmwares source is not yet published, so there is a possibility that this is fixed in the latest versions. I'm hopeful however, that it might very well not be fixed, as they seem to use some old kernel branch even in mid of 2014.
My FireTV did not arrive yet unfortunately, but I hope this can help to root mine and many others!
Could someone please compile the proof-of-concept code and check it out on a FireTV running a recent version?
Ask geohot maybe he can
Wish I could be more helpfull but I tried to compile it and somehow it doesn't work out.
I've built it, pushed it over to /data/local/tmp, chmod 755 but all I get is "not executable: magic 7F45". There seems to be something wrong with my toolchain. Maybe it's because I'm using Windows... Tried to use the NDK and followed the last post over there: http://stackoverflow.com/questions/6745064/how-to-run-arm-binary-on-android-platform
At least there is something I can provide to you, the CONFIG_KGSL_PER_PROCESS_PAGE_TABLE parameter is set to y in the kernel config for version 51.1.3.0_user_513011820.
And I attached the files that are needed to compile kilroy for version 51.1.3.0_user_513011820. Note I have modified the msm_ion.h from #include <ion.h> to #include "ion.h" so it finds the file in the same directory.
Hopefully someone with a bit more knowledge (and the right operating system ) could check this out!
g4rb4g3 said:
Wish I could be more helpfull but I tried to compile it and somehow it doesn't work out.
I've built it, pushed it over to /data/local/tmp, chmod 755 but all I get is "not executable: magic 7F45". There seems to be something wrong with my toolchain. Maybe it's because I'm using Windows... Tried to use the NDK and followed the last post over there: http://stackoverflow.com/questions/6745064/how-to-run-arm-binary-on-android-platform
At least there is something I can provide to you, the CONFIG_KGSL_PER_PROCESS_PAGE_TABLE parameter is set to y in the kernel config for version 51.1.3.0_user_513011820.
And I attached the files that are needed to compile kilroy for version 51.1.3.0_user_513011820. Note I have modified the msm_ion.h from #include <ion.h> to #include "ion.h" so it finds the file in the same directory.
Hopefully someone with a bit more knowledge (and the right operating system ) could check this out!
Click to expand...
Click to collapse
Cool, thanks.
Are you running v5.1.1.3.0 on your FireTV? If yours is newer I could imagine that you need to compile the binary statically. This way it should no longer depend on the library versions currently installed.
freezer2k said:
Cool, thanks.
Are you running v5.1.1.3.0 on your FireTV? If yours is newer I could imagine that you need to compile the binary statically. This way it should no longer depend on the library versions currently installed.
Click to expand...
Click to collapse
Yes my FTV is running on this version. I compiled it static already but it doesn't work...
Finaly I was able to compile it, I used the Terminal IDE and compiled it on the FTV.
But I don't know if it works the right way... when I execute it suddenly every connection breaks down and the FTV restarts after a few seconds. I don't know how to proof that it worked out the way we want it to...
I had to make the following changes to the source files to compile it:
kilroy.h:
change line 24 from
Code:
#include <sys/unistd.h>
to
Code:
#include <unistd.h>
add
Code:
#define NEW_ION
kilroy.c
change line 350 from
Code:
CHK((ion_fd = open("/dev/ion", O_RDONLY|O_DSYNC, 0)) < 0);
to
Code:
CHK((ion_fd = open("/dev/ion", O_RDONLY|O_SYNC, 0)) < 0);
commands used to compile it (start Terminal IDE app and launch telnetd to connect from your pc):
Code:
terminal-gcc -c ./ion.c -o ./ion.o
terminal-gcc -c ./kgsl.c -o ./kgsl.o
terminal-gcc -c ./kilroy.c -o ./kilroy.o
terminal-gcc -o ./kilroy ./ion.o ./kgsl.o ./kilroy.o
I have attachted the compiled file, extract it push it to /data/local/tmp, chmod 755 it and start it.
Maybe someone can find out if this is helpfull for us or not.
g4rb4g3 said:
Finaly I was able to compile it, I used the Terminal IDE and compiled it on the FTV.
But I don't know if it works the right way... when I execute it suddenly every connection breaks down and the FTV restarts after a few seconds. I don't know how to proof that it worked out the way we want it to...
Click to expand...
Click to collapse
Did you had adb debug output running during execution? Anything you can see there?
I couldn't resist and just picked up a FireTV @ MediaMarkt in Berlin.
Successfully blocked any updates during the inital setup and my version is now 51.1.3.0_user_513010720 -- so looks like it's even older than 51.1.3.0_user_513011820.
Okay,
just tried running the kilroy binary you provided.
Exactly the same thing happens, the FireTV reboots immediatly.
I had adb logcat running in a second window, but no output there.
On a 2nd try I had another shell open writing dmesg to /data/local/tmp/dmesg in a loop every 200ms, but it did not capture anything.
In another local shell window, i ran ping -i 0.1 <FireTV> to ping it every 100ms, the FireTV stopped responding immediatly after ./kilroy was started.
Not sure what it is doing, but it seems to manage to crash the box hard Not sure what this means exactly, should a faulty binary cause a reboot like this? Maybe it did manage to corrupt the memory in some way, causing a system crash?
Will try to compile this on my own, though I'm not an expert on Android. Maybe someone else could give this a shot!
I've written a comment on Robs blog, maybe he can held us.
http://bloggingthemonkey.blogspot.c...omment=1414359782492&m=1#c4713581984059861436
freezer2k said:
I couldn't resist and just picked up a FireTV @ MediaMarkt in Berlin.
Successfully blocked any updates during the inital setup and my version is now 51.1.3.0_user_513010720 -- so looks like it's even older than 51.1.3.0_user_513011820.
Click to expand...
Click to collapse
Try rooting it with one of the apps on that FW just for kicks... Since is not on the list of FW's. You never know..
Y314K said:
Try rooting it with one of the apps on that FW just for kicks... Since is not on the list of FW's. You never know..
Click to expand...
Click to collapse
I just installed Towelroot v3 and it just says 'This phone isn't currently supported' when i click on the 'make it ra1n' button.
freezer2k said:
I just installed Towelroot v3 and it just says 'This phone isn't currently supported' when i click on the 'make it ra1n' button.
Click to expand...
Click to collapse
Ahh.. Was worth a shot. Guess any 51.1.3.0 FW is out of reach. Thanks for trying.
Y314K said:
Ahh.. Was worth a shot. Guess any 51.1.3.0 FW is out of reach. Thanks for trying.
Click to expand...
Click to collapse
I tried to use the default modstring, this is the ADB output:
I/towelroot( 7479): ************************
I/towelroot( 7479): native towelroot running with pid 7479 params 1337 0 1 0 4 0
I/towelroot( 7479): CPU affinity was 1
I/towelroot( 7479): set CPU affinity 0
I/towelroot( 7479): parsing modstring
I/towelroot( 7479): modstring is valid 0 1 0 4 0
I/towelroot( 7479): i have a client like hookers
But it seems to hang after that, root button stays greyed out and after clicking a bit the app just closes.
SuperSU 2.4.0 won't open at all and 1.9.4 says it can't install the su binary.
freezer2k said:
Okay,
just tried running the kilroy binary you provided.
Exactly the same thing happens, the FireTV reboots immediatly.
I had adb logcat running in a second window, but no output there.
On a 2nd try I had another shell open writing dmesg to /data/local/tmp/dmesg in a loop every 200ms, but it did not capture anything.
In another local shell window, i ran ping -i 0.1 <FireTV> to ping it every 100ms, the FireTV stopped responding immediatly after ./kilroy was started.
Not sure what it is doing, but it seems to manage to crash the box hard Not sure what this means exactly, should a faulty binary cause a reboot like this? Maybe it did manage to corrupt the memory in some way, causing a system crash?
Will try to compile this on my own, though I'm not an expert on Android. Maybe someone else could give this a shot!
Click to expand...
Click to collapse
What do you want to see in the logcat? The program accesses memory and writes a string into it.
As it crashes and reboots the device, i assume that it did not got there and crashed the gpu/cpu before that and so there is no system log as the cpu resets and not the system. Even if it worked, you wont have seen anything in the logcat - that would be the point where somebody would need to inject proper shellcode into the exploit to use it.
sammy98 said:
What do you want to see in the logcat? The program accesses memory and writes a string into it.
As it crashes and reboots the device, i assume that it did not got there and crashed the gpu/cpu before that and so there is no system log as the cpu resets and not the system. Even if it worked, you wont have seen anything in the logcat - that would be the point where somebody would need to inject proper shellcode into the exploit to use it.
Click to expand...
Click to collapse
Thats what we want to see, so we can be sure that it worked out the way we want it to.
Code:
Before:
[ 11.974607] ###### victim=c11ac000 (813ac000): ""
After:
[ 33.401709] ###### victim=c11ac000 (813ac000): "Kilroy was here"
g4rb4g3 said:
Thats what we want to see, so we can be sure that it worked out the way we want it to.
Code:
Before:
[ 11.974607] ###### victim=c11ac000 (813ac000): ""
After:
[ 33.401709] ###### victim=c11ac000 (813ac000): "Kilroy was here"
Click to expand...
Click to collapse
Yeah but it crashed before that and resets the cpu. So no cookies here
sammy98 said:
Yeah but it crashed before that and resets the cpu. So no cookies here
Click to expand...
Click to collapse
since no exploit was ever really made from his findings, its very possible that it could still be used. its not known if the fix was patched by amazon.
I catched this yesterday doing a 'while true; do dmesg; done' via ADB and then running ./kilroy:
<6>[ 699.556243] binder: release 5006:5006 transaction 124685 out, still active
<6>[ 699.559326] binder: 639:951 transaction failed 29189, size 4-0
<6>[ 699.559326] binder: send failed reply for transaction 124685, target dead
Also, while streaming a video, kilroy does not kill the box, and this shows up in dmesg:
<3>[ 144.678894] ion_mmap: failure mapping buffer to userspace
Only seems to happen when streaming video, box does crash immediately while the screensaver is running, a game is running etc.
I had a chat with Rob, summing up:
<robclark> ... but basically what you want to do is figure out some kernel fxn to overwrite w/ your own code to give you root.. or maybe some data structure to overwrite... find it's virtual address.. find the offset between some lowmem virtual address and phys address so you can convert the virtual address you want to smash to a phys address to smash..
<robclark> I guess the interrupt vector table is always at a well defined virtual address.. that might be something to attack.. although that might be more tricky because your shell code would have to somehow restore it again at the end..
We tried to check out the physical addresses from /proc/kallsyms ; but as non-root all addresses are 0x0, could someone with a similar kernel and root do this and paste it here? Dmesg prints the virtual memory layout, so we have that.
At least on my non-rooted box there is no /proc/last_kmsg, so a dmesg from the previous boot that could contain the dmesg of the crash. Anyone knows how to enable this or something similar?
Hopefully Rob will have some time to help us with this
I will proceed now and set up my own Android build environment.
Okay, I set up the latest Android NDK on Ubuntu 14.04 and made the changes suggested by you, g4rb4g3!
Interestingly enough, the resulting bytesize is different from yours, i used the howto from here:
http://stackoverflow.com/questions/6745064/how-to-run-arm-binary-on-android-platform
And then:
$CC -c ./ion.c -o ./ion.o
$CC -c ./kgsl.c -o kgsl.o
$CC -c ./kilroy.c -o kilroy.o
$CC -o ./kilroy ./ion.o ./kgsl.o kilroy.o
Some interesting output:
<2>[51518.474853] kgsl kgsl-3d0: |a3xx_err_callback| CP | Protected mode error| WRITE | addr=1ec
<3>[51518.628448] kgsl kgsl-3d0: |adreno_ft_detect| Proc kilroy2, ctxt_id 4 ts 1 triggered fault tolerance on global ts 1225504
<3>[51518.628601] kgsl kgsl-3d0: RBBM STATUS 80004001 | IB1:10009000/00000000 | IB2: C000B000/00000033 | RPTR: 1D20 | WPTR: 1EB6
<3>[51518.629791] kgsl kgsl-3d0: |push_object| snapshot: Can't find GPU address for 10009000
<3>[51518.629882] kgsl kgsl-3d0: |kgsl_snapshot_get_object| Unable to find GPU buffer C000B500
<3>[51518.639801] kgsl kgsl-3d0: |kgsl_device_snapshot| snapshot created at pa adf00000 size 136036
<3>[51518.639984] kgsl kgsl-3d0: |kgsl_iommu_clk_disable_event| IOMMU disable clock event being cancelled, iommu_last_cmd_ts: 12b322, retired ts: 12b31f
<2>[51518.646911] kgsl kgsl-3d0: |a3xx_err_callback| CP | Protected mode error| WRITE | addr=1ec
<3>[51518.807830] kgsl kgsl-3d0: |adreno_ft_detect| Proc kilroy2, ctxt_id 4 ts 1 triggered fault tolerance on global ts 1225504
<3>[51518.807983] kgsl kgsl-3d0: |adreno_idle| spun too long waiting for RB to idle
<3>[51518.807983] kgsl kgsl-3d0: |_adreno_ft| Replay unsuccessful
<3>[51518.828369] kgsl kgsl-3d0: |adreno_ft| policy 0x6 status 0x0
<3>[51550.911590] init: untracked pid 29017 exited
[email protected]:/data/local/tmp $ ./kilroy2
main:362: ttbr0=a000006a
add_large_mapping:232: pa=a0000000, va=10000000, len=1000000, cached=0
add_large_mapping:232: pa=81000000, va=81000000, len=1000000, cached=1
add_small_mapping:271: pa=07c00000, va=c000c000, len=1000, cached=0
add_small_mapping:271: pa=07d00000, va=c010c000, len=1000, cached=0
add_small_mapping:271: pa=a0008000, va=c000b000, len=1000, cached=0
main:403: cs[0]: 10008000/c000b000 (115 dwords) (limit: c000b1cc)
main:444: buf: 0x40515000 / 10000000
main:448: ibaddrs[0]: 0x4051e000 / 10009000 (152 dwords)
00000000: c0733d00 c000b000 000001ec 00000020 c0002600 00000000 c0001300 00000000
00000020: c0013d00 c000b500 000000a0 c0002600 00000000 c0043c00 00000013 c000b500
00000040: 000000a0 ffffffff ffffffff c0023d00 c000c010 a000006a a000006a c0013d00
00000060: c000b500 000000a7 c0002600 00000000 c0043c00 00000013 c000b500 000000a7
00000080: ffffffff ffffffff c0023d00 c010c010 a000006a a000006a c0013d00 c000b500
000000A0: 000000ae c0002600 00000000 c0043c00 00000013 c000b500 000000ae ffffffff
000000C0: ffffffff c0013d00 c000c000 00000003 c0002600 00000000 c0043c00 00000013
000000E0: c000c000 00000003 ffffffff ffffffff c0013d00 c010c000 00000003 c0002600
00000100: 00000000 c0043c00 00000013 c010c000 00000003 ffffffff ffffffff c0013d00
00000120: c000c800 00000001 c0002600 00000000 c0013d00 c010c800 00000001 c0002600
00000140: 00000000 c0013d00 c000b500 000000b9 c0002600 00000000 c0043c00 00000013
00000160: c000b500 000000b9 ffffffff ffffffff c0002600 00000000 c0001300 00000000
00000180: 000001ec 00000000 c0002600 00000000 c0001300 00000000 c0013d00 c000b500
000001A0: 000000cb c0002600 00000000 c0043c00 00000013 c000b500 000000cb ffffffff
000001C0: ffffffff c0002600 00000000 c0001300 00000000 c0002600 00000000 c0013700
000001E0: c000b000 00000073 c0002600 00000000 c0013700 c000b000 00000073 c0002600
00000200: 00000000 c0002600 00000000 c0004600 00000006 c0043d00 813ac000 726c694b
00000220: 7720796f 68207361 00657265 c0002600 00000000 c0013d00 c000b500 cafebabe
00000240: c0002600 00000000 c0043c00 00000013 c000b500 deadbeef ffffffff ffffffff
[email protected]:/data/local/tmp $
It does not crash my box anymore. Not sure if this was compiled correctly, as i only took the 3 header files from the Amazon package and the rest is from the NDK.
@g4rb4g3
Could you try to run this binary on your box as well, as I'm running a different kernel/firmware, that does not match exactly https://kindle-src.s3.amazonaws.com/firetv_src_51.1.3.0_user_513011820.tar.bz2.
Wonder if that could also be related to changing DSYNC to SYNC in kilroy.c?
I know that this comes a little bit late but this device still a good machine...
This could be used potentially to boot bricked devices. Unfortunately further work would be required since the Shield Tablet uses a private key (not on the device) to sign the bootloader and if I understand correctly from fuses, nvflash cmds. Probably it could be posible boot into Linux implementing something like shofelf2 does and reflash the emmc from it.... at the same time I don't have a bricked device to verify this.
My main aim with this was to learn about SOCs bootchain/baremetal and related protocols and maybe boot clean Debian with a clean uBoot.... I still pending to acknowledge the second but I really don't know how long will it take me... I don't have that much spare time and this took me almost 1 year and a half to earn the knowledge to reach this point...
ShofEL2 for T124
This is a Fusee Gelee / ShofEL2 exploit port for the Nvidia T124 (a.k.a Jetson TK1, Shield K1, etc).
Currently this code allows you to download and execute a payload to the T124, dump the fuses and memory and boot bct without apply the locks.
Mostly of my code is based on the original ShofEL2 code and Katherine Temkin research, so I cannot take that much credit for this.
See the original fail0verflow blog post: https://fail0verflow.com/blog/2018/shofel2/ See additional info at the original Katherine Temkin github: https://github.com/Qyriad/fusee-launcher/blob/master/report/fusee_gelee.md
Obligatory disclaimer
This code is provided without any warranty, use under your own resposability.
Usage
You need an arm-*-eabi toolkit. You can use Crosstool-ng compile it.
Build the loader and payloads:
$ cd ShofEL2-for-T124
$ make
Usage
$ ./shofel2_t124 ( MEM_DUMP | READ_FUSES | BOOT_BCT | PAYLOAD ) [options]
$ MEM_DUMP address length out_file -> Dumps "length" bytes starting from "address" to "out_file".
$ READ_FUSES out_file -> Dumps the T124 fuses to "out_file" and show them in console.
$ BOOT_BCT -> Boots BCT without applying locks.
$ PAYLOAD payload.bin [arm|thumb] -> Boots "payload.bin" the entrymode mode can be specified (thumb by default)
Interesting facts (maybe some of them wrong):
RCM loads the payload to IRAM at 0x4000E000 (described on tegrarcm source code).
RCM cmd format is sligitly different. RCM cmd header length is 0x284 bytes but the firtst 4 bytes still containing the RCM cmd length.
RCM cmd length restrictions are different to X1 bootrom:
Bulk transfers need to be multiply of 0x1000 to ensure use the whole usb buffer.
RCM cmd length minus 0x284 (header length) must be a multiple of 0x10 (which means RCM CMD length needs to end in 4).
RCM cmd min length is 0x404 bytes. Due to the previous condition the minimun length would be 0x1004.
RCM cmd length cannot exceed avaiable IRAM for the payload (from 0x4000E000 till 0x4003FFFF).
With all this in mind max RCM cmd length is 0x32274 bytes.
Since the exploit uses usb buffer 2, only 0x31000 bytes can be used for the payload in order to avoid finishing the RCM cmd.
A payload can still be loaded using the same path as the one used by the original shofEL2, since no validation is carried out till the whole payload is received.
Even if the specs says that the JTAG is enabled by default, cold bootrom code disasbles it while is runnig (not as dumb as expected ).
RCM runs on an ARM7TDMI core, I manage to halt the CPU on uboot using a Segger J-LINK.
When the poisoned get status is executed, 0x30C bytes will be copied before the payload. These bytes are part of the execution stack, starting with the USB status var.
Using the original sanity_check function from shofel2, I got from the execution stack that the RCM USB buffers are located at 0x40004000 and 0x40008000.
Two USB buffers of 0x1000 bytes still present. They still alternating on each USB txn. And odd number of USB txn will let you on the hight buffer for the next txn.
Using the original sanity_check function from shofel2, I got from the execution stack that the memcpy return address is located at 0x4000DCD8 (0x4000DCF4 - 0xC - 2 * 4 - 2 * 4).
The position in the RCM cmd where the entry adress need to be write to smash the memcpy return address is calculated as follow:
n_bytes_to_copy = 0x4000DCD8 - 0x40008000 (memcpy_ret_add_loc - usb_buf2_add) -> n_bytes_to_copy = 0x5CD8 bytes
pos_in_payload = n_bytes_to_copy - 0x30C (copied from the execution stack) - 0x4 -> pos_in_payload = 0x59C8
pos_in_rcm_cmd = pos_in_payload + 0x284 (header length) -> pos_in_rcm_cmd = 0x5C4C
I found the following functions on the the bootrom:
void ep1_in_write_imm(void *buffer, u32 size, u32 *num_xfer) -> 0x001065C0 -> Writes EP1_IN
void ep1_out_read_imm(void *buffer, u32 size, u32 *num_xfer) -> 0x00106612 -> Reads EP1_OUT
void do_bct_boot() -> 0x00100624 -> Boots BCT without applying locks.Hello
Source: https://github.com/LordRafa/ShofEL2-for-T124/releases
Great work! Does this mean you could in theory push payloads made for the switch to the K1, as they are both tegra-based devices?
xdpirate said:
Great work! Does this mean you could in theory push payloads made for the switch to the K1, as they are both tegra-based devices?
Click to expand...
Click to collapse
Well, yes that is partially right but bear in mind that these payloads relies sometimes on the switch peripherals, so for example if you want to show something on the LCD it will not work because the shield and switch LCDs controllers aint the same, the code will run on the boot CPU but the LCD will not work because they don't work in the same way... It is something like use the wrong driver for a device.
Also you need to understand that the payloads normally are used as first stage loader for something else, if that something else is wrote for the switch app CPU it will not work at all. Switch Tegra app CPU is an arm64 CPU and shield app CPU is a 32bit armv7 so they are not compatible. E.g. this is why I cannot run the Switch Linux directly on my shield.... and even if they could work, again you will find the problem of the peripherals and many others customized things for Nintendo... that is why a Shield TV is not a Switch... same same... but different.
This can be more useful to those people that are interesting to do some research around this device.
Is it possible to unbrick a Shield Tablet killed with this ?
Tonio1987french said:
Is it possible to unbrick a Shield Tablet killed with this ?
Click to expand...
Click to collapse
With some additional development I think that it could be posible. Unfortunately I don't have a killed device to work on this.
Someone that would like to work on this, would need to check where the kill switch is enabled and where is verified.
If I understand correctly this would be the boot chain: bootrom -> nvtboot ( boot cpu code ) -> nvtboot ( app cpu code ) -> second stage bootloader( uboot/fastboot??? ) -> Android.
I would be tempted to think that nvtboot at boot cpu is the responsible to check if the kill switch has been enabled, or maybe the kill switch just modifies the bct header to break the boot chain... If I am right then maybe it would be posible to use shoelf2 to restore a backup to the emmc.
A payload would still need to be developed to being able to read/write the emmc using shoelf2. This is something that I am considering to implement as part of the works porting mainline Linux.
Also it would be nice to see if all devices shares the same private key that would be great because anyone could read a working shield emmc and share it to restore a killed one... if anyone could share the fuse dump, that my shoelf2 generates I could answer this question....
Anyway I would require a killed switch to being able to work on this... My main focus now is run mainline Linux....
Lord_Rafa said:
With some additional development I think that it could be posible. Unfortunately I don't have a killed device to work on this.
Someone that would like to work on this, would need to check where the kill switch is enabled and where is verified.
If I understand correctly this would be the boot chain: bootrom -> nvtboot ( boot cpu code ) -> nvtboot ( app cpu code ) -> second stage bootloader( uboot/fastboot??? ) -> Android.
I would be tempted to think that nvtboot at boot cpu is the responsible to check if the kill switch has been enabled, or maybe the kill switch just modifies the bct header to break the boot chain... If I am right then maybe it would be posible to use shoelf2 to restore a backup to the emmc.
A payload would still need to be developed to being able to read/write the emmc using shoelf2. This is something that I am considering to implement as part of the works porting mainline Linux.
Also it would be nice to see if all devices shares the same private key that would be great because anyone could read a working shield emmc and share it to restore a killed one... if anyone could share the fuse dump, that my shoelf2 generates I could answer this question....
Anyway I would require a killed switch to being able to work on this... My main focus now is run mainline Linux....
Click to expand...
Click to collapse
I do have a killed Shield Tablet LTE. Where are you from?
The OTA that kills the tablet has been dissected here: https://forum.xda-developers.com/shield-tablet/general/kill-kill-switch-shield-tablet-xx-t3179489
Once flashed the tablet doesn't give any signs of life, and goes only in APX mode when connected:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Is it possible to use ShoEL in APX mode? I don't think?
Gave a quick try compiling crosstool-ng on Debian 8 but it's hanging at make, will have a look at it later.
On a side note, one user (Drims75) from Ukraine restores motherboard for a modic cost, you can find a couple of user who sent their motherboard to him: https://forum.xda-developers.com/showpost.php?p=71516196&postcount=139
Thanks for your work!
I can confirm the exploit is working.
Thanks so much LordRafa, you're a legend!
How do i get the SBK Key? Is the FUSE_PRIVATE_KEY i get via READ_FUSES the SBK? And is it possible to dump the BIS keys? The biskeydump payload seems only working for switch. Anyone has a biskeydump payload for t124?
This is absolutely awesome.
I have a bricked shield tablet, here is the output from the fuses:
Waiting T124 to enter RCM mode (ctrl-c to cancel). Note: root permission could be required.
K1 in RCM mode connected.
Chip ID: 0x40 0x02 0x07 0x01 0x00 0x00 0x00 0x10 0x09 0xa1 0x0c 0x74 0x01 0x10 0x00 0x64
Hacky Get Status returned error... Probably the stack got smashed, Congrats
Dumping 768 bytes from 0x7000f900.
FUSE_PRODUCTION_MODE: 00000001
FUSE_JTAG_SECUREID_VALID: 00000001
FUSE_ODM_LOCK: 00000006
FUSE_OPT_OPENGL_EN: 00000001
FUSE_SKU_INFO: 0000001f
FUSE_CPU_SPEEDO_0_CALIB: 000008cd
FUSE_CPU_IDDQ_CALIB: 0000030f
RESERVED_0x01C: 00000000
RESERVED_0x020: 00000000
RESERVED_0x024: 00000000
FUSE_OPT_FT_REV: 00000022
FUSE_CPU_SPEEDO_1_CALIB: 00000000
FUSE_CPU_SPEEDO_2_CALIB: 000007fe
FUSE_SOC_SPEEDO_0_CALIB: 0000089f
FUSE_SOC_SPEEDO_1_CALIB: 00000000
FUSE_SOC_SPEEDO_2_CALIB: 00000000
FUSE_SOC_IDDQ_CALIB: 0000025f
RESERVED_0x044: 00000000
FUSE_FA: 00000000
FUSE_RESERVED_PRODUCTION: 00000002
FUSE_HDMI_LANE0_CALIB: 00000000
FUSE_HDMI_LANE1_CALIB: 00000000
FUSE_HDMI_LANE2_CALIB: 00000000
FUSE_HDMI_LANE3_CALIB: 00000000
FUSE_ENCRYPTION_RATE: 00000000
FUSE_PUBLIC_KEY 0-3: bc420312 298f5d3c a5abe328 9e556001
FUSE_PUBLIC_KEY 4-7: 0eefbfaa 756a7b0f b7507e2f 149672c4
FUSE_TSENSOR1_CALIB: 03a27cbb
FUSE_TSENSOR2_CALIB: 03ee9ee6
RESERVED_0x08C: 00000000
FUSE_OPT_CP_REV: 00000022
FUSE_OPT_PFG: 00000000
FUSE_TSENSOR0_CALIB: 0053a324
FUSE_BOOTROM_PATCH_SIZE: 00000002
FUSE_SECURITY_MODE: 00000001
FUSE_PRIVATE_KEY: 5f244a57 d0197865 940f80a3 15484c8f
FUSE_DEVICE_KEY: 5e65bbde
FUSE_ARM_DEBUG_DIS: 00000000
FUSE_BOOT_DEVICE_INFO: 00000000
FUSE_RESERVED_SW: 00000000
FUSE_VP8_ENABLE: 00000001
FUSE_RESERVED_ODM 0-3: 00000000 00007090 0000000b 00000000
FUSE_RESERVED_ODM 4-7: 00000000 00000000 00000000 00000000
FUSE_OBS_DIS: 00000000
RESERVED_0x0EC: 00000000
FUSE_USB_CALIB: 02c6038b
FUSE_SKU_DIRECT_CONFIG: 00000000
FUSE_KFUSE_PRIVKEY_CTRL: 00000003
FUSE_PACKAGE_INFO: 00000004
FUSE_OPT_VENDOR_CODE: 00000000
FUSE_OPT_FAB_CODE: 00000000
FUSE_OPT_LOT_CODE_0: 00000000
FUSE_OPT_LOT_CODE_1: 00000000
FUSE_OPT_WAFER_ID: 00000000
FUSE_OPT_X_COORDINATE: 00000000
FUSE_OPT_Y_COORDINATE: 00000000
FUSE_OPT_SEC_DEBUG_EN: 00000000
FUSE_OPT_OPS_RESERVED: 00000000
FUSE_SATA_CALIB: 00000000
FUSE_GPU_IDDQ_CALIB: 0000036e
FUSE_TSENSOR3_CALIB: 03e21f59
FUSE_SKU_BOND_OUT_L: 00000000
FUSE_SKU_BOND_OUT_H: 00000000
FUSE_SKU_BOND_OUT_U: 00000000
FUSE_SKU_BOND_OUT_V: 00000000
FUSE_SKU_BOND_OUT_W: 00000000
RESERVED_0x144: 00000000
FUSE_OPT_SUBREVISION: 00000000
FUSE_OPT_SW_RESERVED_0: 00000000
FUSE_OPT_SW_RESERVED_1: 00000000
FUSE_TSENSOR4_CALIB: 03b41d91
FUSE_TSENSOR5_CALIB: 0024c106
FUSE_TSENSOR6_CALIB: 03f15f1c
FUSE_TSENSOR7_CALIB: 00788335
FUSE_OPT_PRIV_SEC_EN: 00000000
FUSE_PKC_DISABLE: 00000000
RESERVED_0x16C: 00000000
RESERVED_0x170: 00000000
RESERVED_0x174: 00000000
RESERVED_0x178: 00000000
FUSE_FUSE2TSEC_DEBUG_DISABLE: 00000001
FUSE_TSENSOR8_CALIB: 00173ab1
FUSE_OPT_CP_BIN: 00000003
FUSE_OPT_GPU_FS: 00000000
FUSE_OPT_FT_BIN: 00000001
RESERVED_0x190: 00000000
FUSE_SKU_BOND_OUT_X: 00000000
FUSE_APB2JTAG_DISABLE: 00000000
RESERVED_0x19C: 00000000
FUSE_PHY_FLOORSWEEP: 00000000
FUSE_PHY_FLOOR_ENABLE: 00000000
FUSE_ARM_CRYPT_DE_FEATURE: 00000000
FUSE_DENVER_MTS_DE_FEATURE: 00000000
FUSE_DIE_VERSION_OVERRIDE: 00000000
FUSE_TRIMMERS: 00000000
FUSE_DENVER_BOOT_SEC: 00000000
FUSE_DENVER_DFD_ACCESS: 00000000
FUSE_WOA_SKU_FLAG: 00000000
FUSE_ECO_RESERVE_1: 00000000
FUSE_GCPLEX_CONFIG_FUSE: 00000002
RESERVED_0x1CC: 00000000
RESERVED_0x1D0: 00000000
RESERVED_0x1D4: 00000000
RESERVED_0x1D8: 00000000
RESERVED_0x1DC: 00000000
RESERVED_0x1E0: 00000000
RESERVED_0x1E4: 00000000
RESERVED_0x1E8: 00000000
RESERVED_0x1EC: 00000000
RESERVED_0x1F0: 00000000
RESERVED_0x1F4: 00000000
RESERVED_0x1F8: 00000000
FUSE_SPARE_REALIGNMENT_REG: 00000000
FUSE_SPARE_BITS 00-03: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 04-07: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 08-11: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 12-15: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 16-19: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 20-23: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 24-27: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 28-31: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 32-35: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 36-39: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 40-43: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 44-47: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 48-51: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 52-55: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 56-59: 00000000 00000000 00000000 00000000
FUSE_SPARE_BITS 60-63: 00000000 00000000 00000000 00000000
Lord_Rafa said:
With some additional development I think that it could be posible. Unfortunately I don't have a killed device to work on this.
Someone that would like to work on this, would need to check where the kill switch is enabled and where is verified.
If I understand correctly this would be the boot chain: bootrom -> nvtboot ( boot cpu code ) -> nvtboot ( app cpu code ) -> second stage bootloader( uboot/fastboot??? ) -> Android.
I would be tempted to think that nvtboot at boot cpu is the responsible to check if the kill switch has been enabled, or maybe the kill switch just modifies the bct header to break the boot chain... If I am right then maybe it would be posible to use shoelf2 to restore a backup to the emmc.
A payload would still need to be developed to being able to read/write the emmc using shoelf2. This is something that I am considering to implement as part of the works porting mainline Linux.
Also it would be nice to see if all devices shares the same private key that would be great because anyone could read a working shield emmc and share it to restore a killed one... if anyone could share the fuse dump, that my shoelf2 generates I could answer this question....
Anyway I would require a killed switch to being able to work on this... My main focus now is run mainline Linux....
Click to expand...
Click to collapse
Did you have any success running/porting mainline linux?
Would this dump the key required to nvflash u-boot?
Edit: I think I understand enough now to know why this is a dumb question. One would use tegrarcm, not nvflash.
Fuses - Nintendo Switch Brew
switchbrew.org
Edit: From NVidia's bct-overview:
When a chip has an RSA public key (PKC) programmed into its flash, it expects the BCT to contain RSA-PSS signatures created/validated using that key pair. When a chip has an AES key (SBK; Secure Boot Key) programmed into its flash, it expects the BCT to contain AES-CMAC hashes created/validated using that key.
Click to expand...
Click to collapse
Has anyone done any testing around what that means for devices with both PKC and SBK? As in does it validate both, either or a does one take precedence over the other?