True it's for another chipset so the S-OFF portion won't work, but (and I may be wrong) I don't see a reason the SuperCID thing won't work for us, provided we find the right partition to edit.
This is for the One X, and it's also confirmed to work on the One S, and they're editing /dev/block/mmcblk0p4 with root permissions. I'm ASSUMING that means that S-ON is only partially enforced. If we could get SuperCID, that's be a huge step in the right direction, would it not? Does anyone know what that partition actually is, and what the analogous partition on the One X+ is?
__________
Upon further investigation, /dev/block/mmcblk0p1 through /dev/block/mmcblk0p11 are all -something- though none of them contains strings for my CID or IMEI. HOWEVER, /dev/block/mmcblk0p9 DOES contain the string value for the last RUU flashed, which in my case is 1.17.401.1, with the entire rest of the file being padding.
There are more partitions, beyond 11. They actually go up to 20, as per ls -la /dev/block/, but everything beyond 11 seems to be excessively large.
-------
Sorry for the continuous posting, but I'm investigating. Anyway, the command "ls -la /dev/block/platform/sdhci-tegra.3/by-name/" yields a partition map with names.
True it's for another chipset so the S-OFF portion won't work, but (and I may be wrong) I don't see a reason the SuperCID thing won't work for us, provided we find the right partition to edit.
This is for the One X, and it's also confirmed to work on the One S, and they're editing /dev/block/mmcblk0p4 with root permissions. I'm ASSUMING that means that S-ON is only partially enforced. If we could get SuperCID, that's be a huge step in the right direction, would it not? Does anyone know what that partition actually is, and what the analogous partition on the One X+ is?
__________
Upon further investigation, /dev/block/mmcblk0p1 through /dev/block/mmcblk0p11 are all -something- though none of them contains strings for my CID or IMEI. HOWEVER, /dev/block/mmcblk0p9 DOES contain the string value for the last RUU flashed, which in my case is 1.17.401.1, with the entire rest of the file being padding.
There are more partitions, beyond 11. They actually go up to 20, as per ls -la /dev/block/, but everything beyond 11 seems to be excessively large.
-------
Sorry for the continuous posting, but I'm investigating. Anyway, the command "ls -la /dev/block/platform/sdhci-tegra.3/by-name/" yields a partition map with names.
This is from CM10.1, with the latest BLADE kernel, radio 3.1204.167.31 and HBOOT 1.35. Does anyone know what's what here?
The reason the SuperCID won't work for us, was also unclear to me for a long time..
Someone finally explained why.
The CID Is not saved the same way as with qualcomm chips!
A different location or way of saving data, not traditionally on a partition.
So this will not help/work us in any way
Actually some info is stored on a partition that is not easily accesible in android (DIA not mapped). CID, for example, along with IMEI are stored, I believe, @ 00a00015.
This is a hexdump -C of /dev/block/mmcblk0
Code:
00a00000 48 54 43 2d 42 4f 41 52 44 2d 49 4e 46 4f 21 40 |HTC-BOARD-INFO!@|
00a00010 9e 00 00 00 48 54 43 5f 5f 30 33 32 33 35 33 34 |....HTC__0323534|
00a00020 xx xx xx xx xx xx xx xx xx xx xx 00 23 05 00 00 |xxxxxxxxxxx.#...|-> imei not
00a00030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| shown
I believe a lot of other flags are found in this area. It would be nice to map this to a partition in a custom kernel for easier access.
I even tried the following:
dd if=/dev/block/mmcblk0 bs=1 skip=10485780 count=8 of=/sdcard/a.bin (a.bin has the actual CID)
hexedit a.bin to supercid
dd if=/sdcard/a.bin of=/dev/block/mmcblk0 bs=1 seek=10485780 count=8 (patch with supercid)
but due to some protection mechanisms I don't yet understant, the changes are not submitted to emmc. (we need a tegra3 advisor)
I think this might be the place to hit if we, somehow, get access to rw.
If anyone is having heavy stuff to test, I'm willing to be the rat test. So far I'm trying to force into apx with TripNRaVeR's buggy rom version for further insights, but I've been "unfortunate" so far.
PS: each time I'm running fastboot oem boot my phone doesn't boot, nor says anything, but gets stuck in fastboot - it needs a forced poweroff; any ideea why? (I don't recall to have this issue with other phones)
PS2 @ teemo: that is NOT linux LNX partition, but a part of DIA partition which is hidden to android!
True it's for another chipset so the S-OFF portion won't work, but (and I may be wrong) I don't see a reason the SuperCID thing won't work for us, provided we find the right partition to edit.
This is for the One X, and it's also confirmed to work on the One S, and they're editing /dev/block/mmcblk0p4 with root permissions. I'm ASSUMING that means that S-ON is only partially enforced. If we could get SuperCID, that's be a huge step in the right direction, would it not? Does anyone know what that partition actually is, and what the analogous partition on the One X+ is?
__________
Upon further investigation, /dev/block/mmcblk0p1 through /dev/block/mmcblk0p11 are all -something- though none of them contains strings for my CID or IMEI. HOWEVER, /dev/block/mmcblk0p9 DOES contain the string value for the last RUU flashed, which in my case is 1.17.401.1, with the entire rest of the file being padding.
There are more partitions, beyond 11. They actually go up to 20, as per ls -la /dev/block/, but everything beyond 11 seems to be excessively large.
-------
Sorry for the continuous posting, but I'm investigating. Anyway, the command "ls -la /dev/block/platform/sdhci-tegra.3/by-name/" yields a partition map with names.
This is from CM10.1, with the latest BLADE kernel, radio 3.1204.167.31 and HBOOT 1.35. Does anyone know what's what here?
Well i'm not sure what you are posting here but all the 20 partitions are allready found and known by probably all the devs here. The partitions are set to ro with the force_ro binary placed on the mmcblk0 and mmcblk1 (boot) partitions. EDIT:
marked ( ) the boot, not only the boot but all the relevant partitions are forced_ro
The force_ro binary can only be found when you set the correct permissions on the boot partitions. Otherwise it says doesnt exist unless you type in the full cat 0 > /sys/..../force_ro command then it says permission denied.
I have several ways to gain rw access to the binary and i can set it disabled. Problem is that it needs to be removed completely for us to have proper acces.
Mounting boot/recovery partitions to the rom cannot be done right now because of the filesystem. I have walked the road you describe allready and my results are in this topic. This method is way to risky to try without having a backup hox available.
I had quite a bunch of success rates when i used my hox with broken screen but since that one is bricked i stopped this s-off development.
Quote:
Originally Posted by sieempi
Actually some info is stored on a partition that is not easily accesible in android (DIA not mapped). CID, for example, along with IMEI are stored, I believe, @ 00a00015.
This is a hexdump -C of /dev/block/mmcblk0
Code:
00a00000 48 54 43 2d 42 4f 41 52 44 2d 49 4e 46 4f 21 40 |HTC-BOARD-INFO!@|
00a00010 9e 00 00 00 48 54 43 5f 5f 30 33 32 33 35 33 34 |....HTC__0323534|
00a00020 xx xx xx xx xx xx xx xx xx xx xx 00 23 05 00 00 |xxxxxxxxxxx.#...|-> imei not
00a00030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| shown
I believe a lot of other flags are found in this area. It would be nice to map this to a partition in a custom kernel for easier access.
I even tried the following:
dd if=/dev/block/mmcblk0 bs=1 skip=10485780 count=8 of=/sdcard/a.bin (a.bin has the actual CID)
hexedit a.bin to supercid
dd if=/sdcard/a.bin of=/dev/block/mmcblk0 bs=1 seek=10485780 count=8 (patch with supercid)
but due to some protection mechanisms I don't yet understant, the changes are not submitted to emmc. (we need a tegra3 advisor)
I think this might be the place to hit if we, somehow, get access to rw.
If anyone is having heavy stuff to test, I'm willing to be the rat test. So far I'm trying to force into apx with TripNRaVeR's buggy rom version for further insights, but I've been "unfortunate" so far.
PS: each time I'm running fastboot oem boot my phone doesn't boot, nor says anything, but gets stuck in fastboot - it needs a forced poweroff; any ideea why? (I don't recall to have this issue with other phones)
PS2 @ teemo: that is NOT linux LNX partition, but a part of DIA partition which is hidden to android!
The fastboot command doesnt work since hboot 0.96 it is blocked by htc.
I have found the IMEI, CID etc and i could read them just fine directly from the mmcblk0 /1 partitions after setting permissions. Sorry to say this and not trying to offend but this doesnt help us in any way by gaining s-off.
IF i understand the s-off correctly for the QCOM chips, its been done by overwriting cids?? It isnt that hard to gain acces to the CID settings, they are not high level secured...
If you like my work.. you may always buy me a ice cold beer join #TripNDroid on IRC server: freenode
IF i understand the s-off correctly for the QCOM chips, its been done by overwriting cids?? It isnt that hard to gain acces to the CID settings, they are not high level secured...
well,not directly. with qualcom chips,the secureflag is turned of by(with my limited understanding):
1) sd card phones- getting the processor into download mode,then booting temporarily from the sd instead of the emmc
2)non-sd card phones- the recent exploit being used on hoxl,hos,and dna is attempting to flash a signed update.zip onto a superCID device. when the flash fails with a 92 supercid error,forcing a boot apparently does so without emmc write protection,wich allows the secureflag to be turned off from the booted OS on that next boot.
so superCID is needed for this recent exploit to work,but its function is somewhat indirect. maybe a similar method to disable write protect is possible with the tegra? ive got a one x,id love to see you figure it out.. mebbe we could pool some donations to get you anoter broken screen/damage device?
The Delivery Guy
If someone has helped you,please click the THANKS button on that post.
Please post questions so others can benefit from the answers(<-this means do not PM me questions) donate to my device fund
well,not directly. with qualcom chips,the secureflag is turned of by(with my limited understanding):
1) sd card phones- getting the processor into download mode,then booting temporarily from the sd instead of the emmc
2)non-sd card phones- the recent exploit being used on hoxl,hos,and dna is attempting to flash a signed update.zip onto a superCID device. when the flash fails with a 92 supercid error,forcing a boot apparently does so without emmc write protection,wich allows the secureflag to be turned off from the booted OS on that next boot.
so superCID is needed for this recent exploit to work,but its function is somewhat indirect. maybe a similar method to disable write protect is possible with the tegra? ive got a one x,id love to see you figure it out.. mebbe we could pool some donations to get you anoter broken screen/damage device?
If you run a sense rom would you mind trying this out:
Add to build.prop:
Code:
ro.sdcard=2
Possible that it requires the fuse command also but i cant remember it know, will check when i'm home. If what youre saying is true then i found some stuff. See if something happens. Also anyone knows what GEP means? It is all related to the sdcard hack.
A sense rom, and a sense rom only, is capable of this stuff. Sense actually checks a few modes during bootup (very early) they can be altered but since this is the first time i actually found this stuff (yesterday) i hardly know 5% of the things that can be done.
The fact that you telling me this now made me see (maybe a far) link to my findings from yesterday.
If you like my work.. you may always buy me a ice cold beer join #TripNDroid on IRC server: freenode
The Following 15 Users Say Thank You to TripNRaVeR For This Useful Post: [ Click to Expand ]
AOWS (20th February 2013), clyder (20th February 2013), davitox87 (20th February 2013), eirikgu (20th February 2013), ejnreon (20th February 2013), HC4Life (20th February 2013), Juanig (20th February 2013), lms24 (20th February 2013), lrbpereira (20th February 2013), MRKikas (20th February 2013), nitrous˛ (20th February 2013), Synoptex (21st February 2013), Thant (20th February 2013), thecknt (20th February 2013), virtualflyer (20th February 2013)
If you run a sense rom would you mind trying this out:
Add to build.prop:
Code:
ro.sdcard=2
Possible that it requires the fuse command also but i cant remember it know, will check when i'm home. If what youre saying is true then i found some stuff. See if something happens. Also anyone knows what GEP means? It is all related to the sdcard hack.
A sense rom, and a sense rom only, is capable of this stuff. Sense actually checks a few modes during bootup (very early) they can be altered but since this is the first time i actually found this stuff (yesterday) i hardly know 5% of the things that can be done.
The fact that you telling me this now made me see (maybe a far) link to my findings from yesterday.
sure... i can try that later this evenig.im at work now,ill be home 8-9ish
The Delivery Guy
If someone has helped you,please click the THANKS button on that post.
Please post questions so others can benefit from the answers(<-this means do not PM me questions) donate to my device fund
If you run a sense rom would you mind trying this out:
Add to build.prop:
Code:
ro.sdcard=2
Possible that it requires the fuse command also but i cant remember it know, will check when i'm home. If what youre saying is true then i found some stuff. See if something happens. Also anyone knows what GEP means? It is all related to the sdcard hack.
A sense rom, and a sense rom only, is capable of this stuff. Sense actually checks a few modes during bootup (very early) they can be altered but since this is the first time i actually found this stuff (yesterday) i hardly know 5% of the things that can be done.
The fact that you telling me this now made me see (maybe a far) link to my findings from yesterday.
I know I'm not a dev, but I have both a one x and a sense rom, so I've tried this...
Nothing seems to change actually, I can assure you I did everything right.
If you need further tests, or prefer someone else to do it better, say it!
Some random stuff i found, dont pin me on this, i'm only posting my finds here:
- enc security key is stored on "extra" partition
- enc security key is checked BEFORE all partitions are mounted
- emmc bkops (kernel) seems needed
- sd enc key read failure on boot? phone gets into read only mode
- ro.ril.ruim.carrier=ct
- read_marked looks for security key
- key192 and key256 used (why? i dont know)
Response and results please
If you like my work.. you may always buy me a ice cold beer join #TripNDroid on IRC server: freenode
Recovering iPad users may still remember the multitasking function where you can swipe left or right to … more
XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality. Are you a developer?
Introducing XDA:DevCon – A Conference For Developers By Developers
>
Goal: S-off HOX (TEGRA3)
Print
Email
View Profile
View Forum Posts
.gif "Netherlands - Vodafone (Libertel)")
Visit Homepage
Follow on Twitter
Follow on Google+
my research on hox
View GitHub profile
Linear Mode
