Post Reply

Goal: S-off HOX (TEGRA3)

19th February 2013, 03:22 PM   |  #171  
Member
Thanks Meter: 48
 
30 posts
Join Date:Joined: Jun 2009
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.

http://forum.xda-developers.com/show...1#post26516911

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.

lrwxrwxrwx root root 2013-02-19 11:08 APP -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2013-02-19 11:08 CAC -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2013-02-19 11:08 DLG -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2013-02-19 11:08 DUM -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 2013-02-19 11:08 LKM -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 2013-02-19 11:08 LNX -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2013-02-19 11:08 MSC -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2013-02-19 11:08 PDT -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2013-02-19 11:08 PG1 -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2013-02-19 11:08 PG2 -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2013-02-19 11:08 PG3 -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2013-02-19 11:08 RCA -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2013-02-19 11:08 RFS -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2013-02-19 11:08 RV1 -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2013-02-19 11:08 SIF -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2013-02-19 11:08 SOS -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2013-02-19 11:08 SP1 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2013-02-19 11:08 UDA -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2013-02-19 11:08 WDM -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2013-02-19 11:08 WLN -> /dev/block/mmcblk0p1

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?
Last edited by backXslash; 19th February 2013 at 04:34 PM.
The Following 4 Users Say Thank You to backXslash For This Useful Post: [ View ]
19th February 2013, 06:59 PM   |  #172  
Senior Member
Flag Here
Thanks Meter: 449
 
1,007 posts
Join Date:Joined: Mar 2009
More
Quote:
Originally Posted by backXslash

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.

http://forum.xda-developers.com/show...1#post26516911

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.

lrwxrwxrwx root root 2013-02-19 11:08 APP -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2013-02-19 11:08 CAC -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2013-02-19 11:08 DLG -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2013-02-19 11:08 DUM -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 2013-02-19 11:08 LKM -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 2013-02-19 11:08 LNX -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2013-02-19 11:08 MSC -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2013-02-19 11:08 PDT -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2013-02-19 11:08 PG1 -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2013-02-19 11:08 PG2 -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2013-02-19 11:08 PG3 -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2013-02-19 11:08 RCA -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2013-02-19 11:08 RFS -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2013-02-19 11:08 RV1 -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2013-02-19 11:08 SIF -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2013-02-19 11:08 SOS -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2013-02-19 11:08 SP1 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2013-02-19 11:08 UDA -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2013-02-19 11:08 WDM -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2013-02-19 11:08 WLN -> /dev/block/mmcblk0p1

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
19th February 2013, 10:37 PM   |  #173  
Senior Member
Thanks Meter: 399
 
287 posts
Join Date:Joined: Jul 2010
Donate to Me
my research on hox
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!
Last edited by sieempi; 19th February 2013 at 11:18 PM.
The Following 3 Users Say Thank You to sieempi For This Useful Post: [ View ]
20th February 2013, 12:51 AM   |  #174  
OP Recognized Contributor / Recognized Developer
Flag Swansea
Thanks Meter: 6,739
 
5,268 posts
Join Date:Joined: Mar 2009
Donate to Me
More
Quote:
Originally Posted by teemo

STOP now please. All "investigation" is HERE. No need to repeat. Do your homework - then come back with some real news




That would be the system image = linux partition. Already covered in above OLD thread.

i would like to point out the following

1) This thread is for the HOX AND HOX+

2) Your crap does NOT = development or anything of the sort
The Following 3 Users Say Thank You to Lloir For This Useful Post: [ View ]
20th February 2013, 01:13 PM   |  #175  
TripNRaVeR's Avatar
Senior Member
Flag Stevensweert
Thanks Meter: 12,581
 
2,379 posts
Join Date:Joined: Jun 2010
Donate to Me
More
Quote:
Originally Posted by backXslash

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.

http://forum.xda-developers.com/show...1#post26516911

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.

lrwxrwxrwx root root 2013-02-19 11:08 APP -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2013-02-19 11:08 CAC -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2013-02-19 11:08 DLG -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 2013-02-19 11:08 DUM -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 2013-02-19 11:08 LKM -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 2013-02-19 11:08 LNX -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2013-02-19 11:08 MSC -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 2013-02-19 11:08 PDT -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 2013-02-19 11:08 PG1 -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2013-02-19 11:08 PG2 -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2013-02-19 11:08 PG3 -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2013-02-19 11:08 RCA -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2013-02-19 11:08 RFS -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 2013-02-19 11:08 RV1 -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2013-02-19 11:08 SIF -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2013-02-19 11:08 SOS -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2013-02-19 11:08 SP1 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2013-02-19 11:08 UDA -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2013-02-19 11:08 WDM -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2013-02-19 11:08 WLN -> /dev/block/mmcblk0p1

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...
Last edited by TripNRaVeR; 20th February 2013 at 01:17 PM.
The Following 4 Users Say Thank You to TripNRaVeR For This Useful Post: [ View ]
20th February 2013, 01:29 PM   |  #176  
scotty1223's Avatar
Senior Member
Thanks Meter: 2,322
 
2,279 posts
Join Date:Joined: Jan 2011
Quote:
Originally Posted by TripNRaVeR

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 Following 3 Users Say Thank You to scotty1223 For This Useful Post: [ View ]
20th February 2013, 01:37 PM   |  #177  
TripNRaVeR's Avatar
Senior Member
Flag Stevensweert
Thanks Meter: 12,581
 
2,379 posts
Join Date:Joined: Jun 2010
Donate to Me
More
Quote:
Originally Posted by scotty1223

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.
The Following 15 Users Say Thank You to TripNRaVeR For This Useful Post: [ View ]
20th February 2013, 02:23 PM   |  #178  
scotty1223's Avatar
Senior Member
Thanks Meter: 2,322
 
2,279 posts
Join Date:Joined: Jan 2011
Quote:
Originally Posted by TripNRaVeR

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
20th February 2013, 03:52 PM   |  #179  
virtualflyer's Avatar
Senior Member
Thanks Meter: 45
 
331 posts
Join Date:Joined: Mar 2011
More
Quote:
Originally Posted by TripNRaVeR

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!
20th February 2013, 07:42 PM   |  #180  
TripNRaVeR's Avatar
Senior Member
Flag Stevensweert
Thanks Meter: 12,581
 
2,379 posts
Join Date:Joined: Jun 2010
Donate to Me
More
My bad, wrong command

Add to build.prop:

Code:
ro.sdcard2=
Correct values are 0 and 1

Also add to build.prop
Code:
persist.fuse_sdcard=
Correct values are true and false

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

The Following User Says Thank You to TripNRaVeR For This Useful Post: [ View ]
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools
Display Modes