yashsingh1/xdaforums huggingface dataset:
[HTC EVO 3D] dragonfyre13:
They are using 4.41. 4.4 didn't have a few of the features that this card supports (simpler boot for one)
[HTC EVO 3D] EarlyMon:
Late chime-in so the record here is complete - nothing otherwise helpful, sorry, maybe nothing much to see here.

The leaked schematic from the FCC does show the MCP as Samsung KMMLL000QM-B503, interesting that it's actually ending with a 6. That schematic lists the RAM on that package as 768 MB, causing me to have earlier speculated that the missing 256 MB might be in the 8660 - or maybe the change in the ending part number was to update the RAM - either way, no big deal.

Samsung's policy on publicly releasing datasheets has changed. Until last year, you could get datasheets for a great many things (such as the Hummingbird) that you now no longer can. If anyone who has used their web to try to find the datasheet for this MCP, I think you'll find that the newest dates of the available datasheets all go back over a year. At least, it was that way when I tried to find this datasheet a month ago. Effectively, they've pulled back from public consumption.

PS - first two chars are product class as I recall, so I don't think you'll find a mapping between KM and others that will matter.
[HTC EVO 3D] jason62082:
Can you dump the contents of EXT_CSD?
[HTC EVO 3D] markgolly:
Its probably so that prospective buyers will contact Samsung sales for the datasheets so that they can size-up the opportunity before committing to releasing information. Plus, I've been seeing a trend towards watermarked datasheets, ostensibly so any that get 'leaked' can be traced back to the source (i.e. Samsung being able to say 'fix your leaks or we won't do business with you any more').
[HTC EVO 3D] markgolly:
With agrabren's comments here, I'm wondering if we shouldn't be attacking the eMMC with an eye towards fiddling with the radio firmware or radio "config" (i.e. to find and change secuflag) instead of attacking the eMMC to change the hboot. According to the author of "tjworld.net" (http://tjworld.net/wiki/Android/HTC/Vision/BootProcess)

the radio is what boots first before Linux boots. So if we can find a way to keep the eMMC chip without the write protections long enough to write a single bit/byte into the "secuflag" section of the radio config or firmware, maybe we'll just have a shot at this....
[HTC EVO 3D] dragonfyre13:
Theoretically, what I'm doing should unlock everything on the emmc card. Shouldn't be any write protection at all when I'm done.

The question is, is the radio's data (secuflag) sitting in emmc? I'm not entirely sure how the radio fits into all this (where it's data is stored, etc). Though I suppose I should get pretty familiar pretty quickly.
[HTC EVO 3D] unCoRrUpTeD:
Not sure if the radio data is stored on eMMC or in the radio chip itself, or is it all bundled into one SOC. I know we have a radio partition, I'll post what I find out in a little bit.
[HTC EVO 3D] Zarboz:
I posted a link to the extended convo transcript it mentions stuff about set secu flag and location

sent from my EVO 3D
[HTC EVO 3D] unCoRrUpTeD:
I started looking through it. I wasn't even going to attempt trying anything. I figured their are so many people out there working on this. I'm sure unrevoked is also looking at it as well as TeamWin and all of you on here. But I'm getting bored with not being able to do much with my phone that I'm going to try some things. From all the stuff I have read so far it appears this phone is locked up pretty tight.
[HTC EVO 3D] pinky059:
Does anyone know if the radio checking the hboot and then reverting everything back to before "temp root" happens DURING the shutdown/reboot "processes" of the phone (aka RAM)? Or does the radio check the hboot upon startup? Has any tried getting a logcat of what is going on after temp root is done (system writes can happen and stick for a bit) during actual shutdown/reboot??

I ask because if that is one of the only things with the suid bit set, then, maybe that's where things happen at, during reboot or shutdown, as opposed to boot up. Yes, I know, I have read the thread regarding the bootup process. But, maybe it's the actual SHUT down that is checking, then, restoring before the phone goes back into booting mode.

I know we originally push to /data/local/tmp which is RAM; so that is not why I am asking.

Thoughts?
[HTC EVO 3D] itsallsubliminal:
i'm by no means a dev/hacker, but i did notice that the startup takes longer after rebooting from temp root. The shutdown seems to be the same speed/time as normal.
[HTC EVO 3D] Zarboz:
If you successfully ported Wpthis or gfree over to our emmc and kernel for functionality we can unlock emmc and edit radios set secu flag to read.out properly in theory or will we still need to focus on directing attempts at radio? I'm also curious if there are any s off EVO 3ds and if so I am wondering of their radio software will differ in any way. Or if the set secu is permanently placed in boot Rom

sent from my EVO 3D
[HTC EVO 3D] ninoriff:
Same here, Phone is a lot slower after Temp Root. .. weird!!
[HTC EVO 3D] daneurysm:
This seems very relevant: http://xdaforums.com/showthread.php?t=1155768
[HTC EVO 3D] sn0b0ard:
I've been trying to cross-compile wpthis and gfree on to the msm8x60 arm platform and it hasn't been easy, nor have I been successfull. I keep running into issues building the kernel with my cross compile toolchain. I think some of the issues are because the kernel I am using is 2.6.35 from the android-msm-2.6.35 branch, and I don't know if msm8x60 is fully supported or has been patched into this kernel. It has an entry in the msm_defconfig under ARCH_QSD8X60 and also appears in under arch/arm/mach-msm/Kconfig.
[HTC EVO 3D] Zarboz:
I believe dragonfyre has some other stuff worked in.

sent from my EVO 3D
[HTC EVO 3D] dragonfyre13:
Yeah, I've got a bunch of other crap worked in. Gfree/wpthis do NOT work as is, that was the first thing I tried. I've also gone through more other attempts than I can count. The wpthis method does not work on this phone, but there's similar vectors that (kinda) do. That's what I've been working on for a while now.

And no, this doesn't compile against the android-msm-2.6.35 branch off of CAF, or the ace kernel code (desire HD) from the HTC site. There's a mix of both you need to use, as well as additional code from AOSP among other areas.
[HTC EVO 3D] sn0b0ard:
Thank you for clearing that up for me. It's been bugging the heck out of me why it wasn't compiling, lol.
[HTC EVO 3D] dragonfyre13:
Just found the request. Here you go:

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001e005001000000000000000000000000000101c60100030001000000051f010000000000000000000000000000000001000000000000050002000700010100000000000000000000000000004800001300070708010101060400070a0a150100000000000000000a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001030100000000000000
[HTC EVO 3D] dragonfyre13:
I commented in there. We're not using that filesystem type, we're using ext4. But that is an addition HTC might make in the future (don't give them any ideas...) :)
[HTC EVO 3D] dragonfyre13:
I'm going through the kernel logs pretty regularly, and finding loads of wierdness with the way power management is done before and after temproot. Might be how they got it, or a side affect, but could also be affecting speed somehow.
[HTC EVO 3D] Zarboz:
It's the emmc freakin out that we have root and tryin to revert the system?

The root exploit had been mentioned to use graphics drivers

sent from my EVO 3D
[HTC EVO 3D] dragonfyre13:
Nah, the emmc freaking out is when I sent it into an inactive state. it's an interesting bug, introduced by HTC's own protections. They removed access to the GPIO pin by setting the master (only one that can control the pin) to something that you can never get to. Then, if they attempt to access the card for a while, try suspending, then waking, try sending commands to get it back into a decent state, etc. it looks like they are attempting a hard reset as a last ditch effort. Unfortunately, they got the same error I did when they attempted a hard reset... :)

Not that the above helps the process in any way, but it's interesting nonetheless.
[HTC EVO 3D] Zarboz:
Could we hardmod a mobo with the right equip? Like reflowing the emmc chip? Or is the access removed via a software lock?

sent from my EVO 3D
[HTC EVO 3D] dragonfyre13:
You could screw with the voltage (with a VERY steady hand) to the hard reset pin physically, but that wouldn't exactly be a software based perm root. No way everyone is going to open up their phone...

Access is in the software, but it's not in the running kernel. The kernel just tells the emmc chip to prevent access for as long as the emmc controller is on, has power, etc. Difficulty is getting the kernel to shut power completely down to the chip, when everything in there is trying to prevent that (it's an always on chip, etc.).
[HTC EVO 3D] MikeC84:
Was that sprint guy with the 3vo s-off not of any help to us???
[HTC EVO 3D] xHausx:
What about the power management systems? If it is possible to cut power to the eMMC chip through the kernel you may be able to get it to reset.

edit: n/m, just saw your last post.
[HTC EVO 3D] markgolly:
Only the devs that have his phone's dump know that. As far as I can tell, no one has posted his dumps out of fear that they can be traced back to the guy.

EDIT: Oh, and I have sent several PMs to those who I think are "in the know" for more information. No reply yet....
[HTC EVO 3D] markgolly:
JTAG?

Does anyone have any information on where the JTAG pins are on the 3D's motherboard?
[HTC EVO 3D] seashell11:
If someone (me) volunteered to hard reset the pin physically, could I then get information off the phone to help you find a permanent software root?
[HTC EVO 3D] blakeboys:
Ditto!, Im comfortable enough to open the phone and try a hard reset. Just need someone to explain the process and what the side effects will be. I'm still within my 30 days so if it screws up I'll take one for the team and go return for a new 3d. Then try again :p
[HTC EVO 3D] jason62082:
I am assuming these values are listed from offset 0 to offset 511 (left to right), otherwise they don't match up to anything.

The registers I am interested in are:

BOOT_WP = 0x00

USER_WP = 0x00

RPMB_SIZE_MULT = 0x01

RST_n_FUNCTION = 0x01

BOOT_WP: Boot region is not power-on write protected; Boot region is not permanently write protected.

USER_WP: Power-on write protection is not applied when CMD28 is issued; Permanent write protection is not applied when CMD28 is issued; Password protection features are enabled.

RPMB_SIZE_MUL: the RPMB partition size is 128 kB.

RST_n_FUNCTION: RST_n signal is permanently enabled.

And from the standard, "By default, RST_n_ENABLE is set to 0x0, which is RST_n is temporarily disabled. Host can change the value to either 0x1 (permanently enabled) or 0x2 (permanently disabled). Once host sets the value to either one, the value can not be changed again."

Power-on write protection seems to be disabled. It also looks like the reset pin is enabled at the eMMC chip itself.

I'm also interested in the CSD registers. Could you please dump those also?

I'm interested in PERM_WRITE_PROTECT and TMP_WRITE_PROTECT in CSD[13] and CSD[12], respectively,
[HTC EVO 3D] goodelyfe:
what all kinda trouble could he possibly be in? im SURE that him recieving a s-off device wasnt because he was an employee, correct? just seems like he got lucky and a coincidence that he works for sprint and just so happened to receive a device that was s-off

paranoid much?
[HTC EVO 3D] Zarboz:
Leaking could result in that employees termination

sent from my EVO 3D
[HTC EVO 3D] sgt. slaughter:
you dont know the whole story so commenting on it like that saying they are "paranoid" is a lil much imho.

this was before the phones shipped that they got this dump.
[HTC EVO 3D] goodelyfe:
while my comment may be a little bit pre-mature and insensitive....it was only a question.

Just seems like a big coincidence that Sprint would be intentional willing to give one of their employees a device that would be s-off.... I would guess (in my mind of course) it would be more probable that HTC screwed up (like they've done before) and some device that were s-off got shipped out....and it just so happens that a person who is employed by Sprint got lucky? Or perhaps even an HTC employee who 'leaked it' would be more probable?

either way, no harm was intended :) my apologies if the relative parties were offended :)
[HTC EVO 3D] mlin:
Aren't we talking about the dump that was shared last night?

I think its the latter. There are a few Sensations floating around with S-OFF for awhile as well and considering there is no S-OFF for that device I don't have my hopes up about the E3D.

This is my last post in this thread b/c I am not contributing to the cause.
[HTC EVO 3D] pastorbob:
Exactly. I noticed the thread with him talking about his s-off phone and then when I got home to look it up on my computer It was gone... I was interested in seeing where that could have possibly lead.
[HTC EVO 3D] welrope:
From what abargen said, it is the radio that is setting s-on or s-off on the device? if so, wouldn't we need a dump of his radio. If his radio is flashable, wouldn't that provide s-off for our current hboots? I got to see a screen shot of his radio and it wasn't any one of the ones we have? Also, does a dump retain the signature that is required for us to flash with s-on?
[HTC EVO 3D] nizzull2:
Here is a pic
[HTC EVO 3D] welrope:
I saw it when it was posted. Was more looking for an answer to my question. Thanks though!
[HTC EVO 3D] xHausx:
maybe HTC is starting to ship them unlocked, as promised? Probably not but who knows.

Interesting how his says RH instead of RL and his shows the radio version where mine doesn't.

maybe,

RL = Radio Lock

RH = ??
[HTC EVO 3D] welrope:
If they are shipping unlocked, we should see more of them popping up.....hopefully!
[HTC EVO 3D] Vinchenzop:
Based on the radio (baseband) version number...his seems old compared to mine...

Mine is 0.97.10.0530

So if assume this is from a dev/engine phone and not a newer shipped phone
[HTC EVO 3D] welrope:
Thought so too, but i like the fact it says SHIP and not ENG...whiiiiiich could mean a signed bootloader unlike the ENG one we have ?

Also, looks like someone in the sensation forum has permanently rooted his s-off phone. _no ban please_
[HTC EVO 3D] unCoRrUpTeD:
No. It's been mentioned that everything is tied together. The radio boots 1st. It verifies the bootloader. There are a lot of unknowns.

The eng bootloader is not zipped and signed with HTC's keys. That is the only way to get it on the phone at this time.

Some people here are trying to unlock eMMC by power cycling the chip. Doing this should remove the write protection. Some are trying to attack the radio, and some are trying to gain access to the hboot.
[HTC EVO 3D] welrope:
Understood. But, can his "unlocked" hboot be pulled from his phone without messing with the signing of said hboot?
[HTC EVO 3D] unCoRrUpTeD:
We have no way of flashing it. The eMMC is locked.
[HTC EVO 3D] dragonfyre13:
I turned off power on write protection earlier when I was messing around with a few things (trying to jump in the middle of where the kernel seemed to be re-enabling it). Sorry bout that, here's the values from a clean dump:

<4>[ 945.156652] csd: d02701320f5903fff6dbffe78a404056

<4>[ 945.158483] ext_csd[173] BOOT_WP: 00000000

<4>[ 945.158757] ext_csd[171] USER_WP: 00000000

<4>[ 945.159032] ext_csd[168] RPMB_SIZE_MULT: 00000001

<4>[ 945.159551] ext_csd[162] RST_n_FUNCTION: 00000001

<4>[ 945.159856] ext_csd[192] EXT_CSD_REV: 00000005
[HTC EVO 3D] markgolly:
Depending on how the CSD is read (MSB first or LSB first), temp write is off and Perm write is either off or on (from the direction that makes sense, Perm write is on...).

Temp write protection is r/w and value is kept over power cycles.

Perm write protection is r/w, but writable only once.

Again, according to the spec....

EDIT: Seems the CSD here doesn't quite go to spec. According to the spec CSD[0] should always be a '1'. However, if the above number is read left to right as MSB to LSB, CSD[0] is a '0'....
[HTC EVO 3D] jramz:
Here's something really strange... On my hboot... I have:

SHOOTER XC SHIP S-ON RL

HBOOT-1.30.0000

eMCC-boot

May 20 2011, 00:32:22

but in OS, my baseband version matches the s-off version... 0.97.00.0518... so does that mean it's not the radio that caused his phone to be s-off?
[HTC EVO 3D] markgolly:
The "radio" is another ARM core running its own software. It is the first to boot and it in turn boots the other cores into Android. It has its own partitions of eMMC for its programs and data. I believe (but I have no proof...) that S-ON/S-OFF is located in the radio-data partition.

The 0.97.blahblah is just the version of software that the radio ARM core is running.
[HTC EVO 3D] markgolly:
Where did you see the post?
[HTC EVO 3D] jramz:
Sure... but if the "radio" is what tells hboot s-on/s-off as has been suggested then wouldn't the differing "radio" version numbers be associated with different s-on/off statuses? Or is it variable within each radio software version?

Similar to how with the E4G, x version of the hboot was s-on, but once we flashed the older version of the hboot (engineering one) it was s-off
[HTC EVO 3D] nizzull2:
Prob saw this but different bootloader on RS it has MFG Kernal and system info...

http://radioshackwireless.com/templ....aspx?pageid=10059&referringdomain=radioshack
[HTC EVO 3D] markgolly:
Check out:

http://tjworld.net/wiki/Android/HTC/Vision/BootProcess

This guy has done a lot of introspection into how these phones work.

Furthermore, on my old E4G, I had a shipped bootloader but it was S-OFF. I never needed to flash the engineering bootloader.
[HTC EVO 3D] Zarboz:
Couldn't we use a boot.img from a s-off device to allow use of s off hboot or write to emmc or will that be a interaction between hboot radio and kernel

sent from my EVO 3D
[HTC EVO 3D] markgolly:
Nope. First, the boot.img won't be signed (so the phone won't flash it). Second, if we were able to get it jammed in there somehow, we don't know where the keys are, so the primary boot loader probably wouldn't load it. Third, even if we did get past those hoops, the S-ON/S-OFF bit may yet be somewhere else (and not in the actual firmware).
[HTC EVO 3D] goodelyfe:
so markgolly, what would be your solution? angle?
[HTC EVO 3D] markgolly:
My Thoughts....

My thought is if:

1. we can identify the exact set of bytes that determine S-ON/S-OFF (which I think would be located in the radio-data partition), and

2. dragonfyre13 can get the eMMC permissions removed for just a split second (just long enough to write a few bytes to the eMMC), and then crash the whole phone (to avoid something else detecting that some bits have been twiddled),

then we can simply rewrite those few bytes that determine S-ON/S-OFF and be home in time for dinner.

Please note that for #1 we either need a dump of the radio-data partition from an S-OFF phone (easy way), or reverse-engineer the primary boot (hard way) to determine the S-ON/S-OFF bits. That's why I'm so keen on getting access to the dump that the devs have of that (reportedly) S-OFF 3D.

And for #2, we're relying on you, dragonfyre13.... ;)
[HTC EVO 3D] Zabalba:
Can any Devs chime in on this link?
[HTC EVO 3D] goodelyfe:
that sounds easy enough :-) standby for PM
[HTC EVO 3D] jason62082:
I would say it's read 127:0. The hardware spec fields seem to match up that way. I wouldn't worry about CSD[0]. Most chips leave reserved bits zero.

This means PERM_WRITE_PROTECT = 0x00 and TEMP_WRITE_PROTECT = 0x00.

Questions for clarification:

1) Is it confirmed that we can't write to any part of the eMMC?

2) Is it confirmed that we can write to the eMMC, but it's erased on reboot (like RAM)?

3) Do we know where the security flag is stored for sure (could it be a bit in the image itself)?
[HTC EVO 3D] Tilde88:
Hey guys. just wondering if anyone has tinkered around with the newer builds of QPST (namely builds 362 and 366 which have the "eMMC Software Download" tool. Im thinking that we may be able to the eng bootloader through here. Would play around with it myself but im so neck deep in work... maybe tmw..
[HTC EVO 3D] unCoRrUpTeD:
I'll look at qpst. Downloaded yesterday, but haven't installed it yet. I'm also looking through the entire emmc. I've found some interesting things. I'll report back later.
[HTC EVO 3D] kpkimmel:
Noticed you can successfully turn off radio resource control through qpst
[HTC EVO 3D] williamjf77:
with *#*#4636#*#* you can turn off radio too. also what is qxdm log
[HTC EVO 3D] kpkimmel:
saw this when reading emmc

00000020
[HTC EVO 3D] Zarboz:
Questions for clarification:

1) Is it confirmed that we can't write to any part of the eMMC? Can write to system but reverts after short time believe its temp stored in RAM then boot Rom kicks it out and resets

2) Is it confirmed that we can write to the eMMC, but it's erased on reboot (like RAM)? I think that's why Su and things placed in system/bin system/xbin and sbin/ are dissapearing.after reboot because even though Su doesn't function if you use adb shell to ls /system/bin the binary is still there

3) Do we know where the security flag is stored for sure (could it be a bit in the image itself) set secu flag is sent by radio to hboot during bootrom (pre hboot load)from my understanding
[HTC EVO 3D] kpkimmel:
Question (might be stupid) but since qpst allows for read and write access to the root couldn't we somehow use that the overwrite boot image and such....?
[HTC EVO 3D] markgolly:
Dunno. Probably not while the phone is S-ON, but it would be something to try....
[HTC EVO 3D] goodelyfe:
posted in the eMMC thread

i checked out the last link and its some very interesting stuff in there. seem to make it easier than we think....
[HTC EVO 3D] goodelyfe:
that darn CSD ......
[HTC EVO 3D] wrapkgb:
I know all you guys are working your tails off.... And for that, thank you and kudos! But if i may ask, from a non dev/code illiterate person are we getting any closer to the ultimate goal of S-OFF? (It seems like we are) I am learning tons, but man this is getting waaaay over my head and I'm getting lost... :)

Again thank you to everyone involved. This community is handling business!
[HTC EVO 3D] jason62082:
One think I noticed today when I was looking through the hboot binary is that there is debug print code for both of the strings "S-OFF" and "S-ON". This makes me think the hboot is looking for the secure flag somewhere else, like the radio code as others have said. In addition, these strings are present in both the release hboot and the engineering hboot.

Maybe tomorrow I'll look through the radio binary for interesting strings.
[HTC EVO 3D] unCoRrUpTeD:
I may have something good. I'm going to test some more things, but need to download an RUU before I attempt anything else. All I can say is it has to do with writing to emmc.

Edit: I have the signed zip. Will this work if I change the name and do it from bootloader. Anyone used that one" Otherwise I need to download the RUU
[HTC EVO 3D] welrope:
Wow! Can't wait to hear any results or progress made!! I followed your dualboot thread for a long time waiting to get it on the evo. Anyway, good to know you are working on it!
[HTC EVO 3D] marc.ientilucci:
what signed zip?