Seriously, actual technical discussion this time.
Continued from the other thread:
READ THIS FIRST:
ace42588 said:
If the phrase "I don't know if anyone has tried this..." appears in your post, stop. Read both threads. Reconsider your post. Your post should no longer have that phrase and wont waste space.
If the phrase "I don't know, but..." appears in your post, stop. Find out. The interwebz is amazingly useful for learning things. Reconsider your post. Your post should no long have that phrase and you will sound knowledgable and educated.
If you don't have any idea how an exploit is supposed to work, please don't suggest it. Look it up. If it sounds applicable to the G2, proceed to share.
Click to expand...
Click to collapse
What we know now:
- The eMMC supports setting a range of blocks temporarily or permanently read-only. That seems to be the case for the bootloader, /system and recovery.
(From the datasheet: Specific segments of the iNAND may be permanently, power-on or temporarily write protected. Segment size can be programmed via the EXT_CSD register.)
- The reason we can write to /system using "temproot" is that it is getting cached by linux. (Write-through, so the card is accepting and discarding writes but we are seeing the cached version only.) Flushing the cache removes all changes from system and upsets the kernel.
- Because no changes are making it to the actual flash, rebooting removes all updates. It is not being magically reflashed.
- It is not a rootkit. It is the OPPOSITE of a rootkit. Rooting it is much much more like a rootkit. Seriously.
- OTA isn't an answer. It isn't even helpful. The way it works: update.zip is downladed, and the key checked. saved to /cache, and an update script is written. it reboots to recovery. recovery checks the keys again, then runs the script to install it. there's no exploitable action there. It doesn't unlock the emmc, etc.
The eMMC security standard (pdf) and specifically, the parts applying to write protection
And the SanDisk part manual/datasheet
Some pieces of the current state are accessible from fastboot, or by mounting debugfs.
Status Blocks:
CSD and decode
Decode of EXT_CSD (via "fastboot oem get_ext_csd_emmc")
EXT_CSD (raw) while the phone is running
Some notes concerning the above
Useful flags in the security standard, specifically relating to temporarily and permanently write protecting regions of flash.
CMD29 is clear write protect. Hmmmm...
Or we might permanently writeprotect it. Or permanently -block- write protection.
Can a kernel module just reset the WP blocks? maybe (more info here) and the value should be "d00f00320f5903fffffffde0124040c8"
If we have to reset the controller, here is how
Examinations of the cache behavior, rmt_storage, etc.
If you have other updates, stick the links in the replies. Also, there is a wiki being set up.
Currently (10/9) we're looking at either resetting the part (and then reconfiguring it to get it out of boot mode - page 38 in the spec) or chewing up the bootloader.
Alternate approach by lbcoder - apply the leaked engineering bootloader as an update, convincing the system via misc that it has already passed signature validation:
Kinda unrelated, but here is HTC's response to their gpl violation. And finally, here is their possibly-accidental source code release.
Edit: What I posted is now in the above post. Just trying to help. I have faith in you guys to get root.
CHANGELOG:
- 10-08 18:32 wiki link fixed
- 10-08 22:07 added the cache examinations
- 10-09 13:45 added the disclaimer and the currently-trying
- 10-13 10:11 add CSD decode
- 10-14 09:37 add kernel source
mrozzeh said:
rmt_storage was basically just proof to me that there was a write-back issue in place.
Part of the bootloader's preboot sequence is a call to mpu_emmc_protection(I believe that is what its called off the top of my head), followed by a call that sets up the physical nand protection that we're already used to. Setting superCID or S-OFF would disable those calls, which would kill the ramfs and allow physical access.
Click to expand...
Click to collapse
Ah, ok this makes sense to me. Basically you are changing the time of the attack to earlier on in the life-cycle. I agree that disabling write-protection while the phone is operational (after boot) could be problematic (because we seem to have cached writes).
So what you're suggesting is that we turn off protection earlier on (in the bootloader)?
Oh by the way, there's no point writing that value (that I mentioned earlier) to the CSD register since those bits are RO.
vi5in said:
Ah, ok this makes sense to me. Basically you are changing the time of the attack to earlier on in the life-cycle. I agree that disabling write-protection while the phone is operational (after boot) could be problematic (because we seem to have cached writes).
So what you're suggesting is that we turn off protection earlier on (in the bootloader)?
Click to expand...
Click to collapse
It may be that it can't be turned off at all once it is turned on (eg if we can't get the chip back into a sane state after a reset), so it is possible that the only time we can turn it off (or rather, not turn it on) is bootloader.
The cached writes issue is easy to deal with - there is no reason to ever remount it read/write, so there are no cached writes pending. (There is a red herring from earlier - htc didn't set it up read/write, that is a side-effect of a typo in the 'root' script from the directions thread. The last line attempts to put it back to read-only, but fails because it uses android mount instead of busybox mount.)
The wiki link is broken.
Maqr said:
The wiki link is broken.
Click to expand...
Click to collapse
Wiki is now here.
Now im not a dev by any means.
let me see if i have this right:there is a read only file that contains the "primary" android system files and we cant modify that and it gets re applied everytime the phone is restarted.henchforth makeing the phone unrootable. now logically speaking the area had to at one point been writable, and has since been locked by a command, of which we cant find. and the mmc has a little todo with the whole process. so its safe to say that it might be one of the "key" components. just looking at the design of the phone and with what looks like a back cover sensor on the lower of the hinges on the back cover. Now the command to read the read only part of the phone is looking like what we have to get too to change where it is looking for the sys info to allow us perm root. i have a g2 and am excited on the amount of skill comming to gether to get this done.
Always willing to donate for a good cause, let me know if we need to get a pot going to buy someone a G2 like JesusFrekee.
Maybe HTC wants to force use inside the G2 so we void warranties. Jtag adapter, or a hardware related jumper/mod.
Someones gonna need a G2 bought by the community that they are not going to mind tearing apart
jeagoss has already torn one apart and JTAGed it and has been poking around
Sorry to dig up old info from the other thread, but I couldn't help but notice a few things here:
Disconn3ct said:
Where do you think the ramfs is coming from, as opposed to a write-through cache? It certainly behaves like a cache. (Not disagreeing that it gets set early. And if we can't get the bootloader, replacing recovery might be enough - it has to be r/w when starting recovery for OTAs to work, so the bootloader can behave 'as designed'.)
rmt_storage_client_txt (and the source)
this post shows changes disappearing after a cache flush (easily verifiable) and memory use going up as data is 'written'.
changes disappear "randomly" over time - ramdisk maintains data.
Where is the info that got you thinking rmt_storage creates a ramdisk? I saw something about that a couple days (and dozens of pages) back, but it didn't pan out. Did we miss something?
Click to expand...
Click to collapse
I think there is an interaction between rmt_storage and the actions of the radio/mmc interfering with the temp root. rmt_storage is certainly being used as a proxy to communicate with the storage in some way. Not as a ram-disk, but as an overlay to the visible partitions that are on lock-down. Your observations of free memory being clobbered by big writes to protected partitions could very well be linux caching the writes - because there's simply nothing better to do with that memory at that moment in time. However, as rmt_storage continues to communicate with other parts of the system, the trigger to flush cache as it sees fit may very well be sent through the RPC mechanism. It does not exactly explain the cache flush scenario, unless rmt_storage sends a message to clear all volatile blocks at that time. Any way you slice it, rmt_storage has a lot to do with the overlay, and probably nothing to do with the lockout.
mrozzeh said:
rmt_storage was basically just proof to me that there was a write-back issue in place.
Part of the bootloader's preboot sequence is a call to mpu_emmc_protection(I believe that is what its called off the top of my head), followed by a call that sets up the physical nand protection that we're already used to. Setting superCID or S-OFF would disable those calls, which would kill the ramfs and allow physical access.
Click to expand...
Click to collapse
This makes sense to me. Coming from a N1, I did the locked bootloader root via SDcard trick a few months back. This explains why HTC has blocked adb from communicating with the device while in recovery mode. The same trick would presumably work if they left it open.
So....
It seems we have some evidence that the lock happens during the early stage of the boot sequence. From here, it is likely that rmt_storage plays a role in how the overlay/cache/whatever is reverting writes over a period of time. But it does not appear to have anything to do with the security lock-out.
With no recovery vector to exploit, this leaves us with few options. I would put my money on exploiting the pre-boot process (possibly with a race condition exploit similar to what we have seen with other recent HTC devices) and either preventing the partitions from being write protected *or* disabling the security outright. I have yet to see any evidence that we can disable the write lock from userspace *or* kernelspace - only speculation.
Re-read rmt_storage_client.txt - it seems likely that this is what we are observing with the rooted units degrading over time. rmt_storage sends RPC calls, stuff happens, filesystem overlay changes disappear. Once the kernel is up, this is *the only* interface to restricted parts of the storage system.
Based on the rmt_storage_client.txt you linked, rmt_storage provides storage access to the radio / modem processor via RPC since it doesn't have any direct way to access emmc, rmt_storage doesn't sound like it's doing anything for the application (the one android runs on, we root, etc) processor.
It's not impossible that it might somehow be exploitable in some fashion but I glanced through the code and nothing jumped out at me as doing anything interesting.
HamNCheese said:
This explains why HTC has blocked adb from communicating with the device while in recovery mode.
Click to expand...
Click to collapse
But wait- don't you remember the part when T-Mobile said that the inability to save changes is a mere side effect of HTC's security measure intended only to prevent "key operating software from becoming corrupted and rendering the device inoperable"?
And their 90-120 day delays are totally "within the requirements of the open source community", no matter what the GPL might say.
I'll keep looking here.
W
biosehnsucht said:
Based on the rmt_storage_client.txt you linked, rmt_storage provides storage access to the radio / modem processor via RPC since it doesn't have any direct way to access emmc, rmt_storage doesn't sound like it's doing anything for the application (the one android runs on, we root, etc) processor.
It's not impossible that it might somehow be exploitable in some fashion but I glanced through the code and nothing jumped out at me as doing anything interesting.
Click to expand...
Click to collapse
My understanding is that the eMMC is abstracted since it is not yet directly supported by linux. Therefore, the radio would be the next logical choice for accessing it.
rmt_storage = remote storage. Keep in mind that we're dealing with a new SOC - it's perfectly reasonable to assume it has the ability to access eMMC on its own. RPC via rmt_storage is a likely suspect. It would also explain where the missing space went.
You have it backwards. Read the beginning of the rmt_storage doc. The radio can't access it so it makes rpc calls to linux so that linux can handle read/write for it. It is well documented. Seriously people. Stop guessing and do a little reading..
Subbed for updates. I'm not good at this stuff. So I'm reading trying to learn.
Sent from my T-Mobile G2 using XDA App
HamNCheese said:
My understanding is that the eMMC is abstracted since it is not yet directly supported by linux. Therefore, the radio would be the next logical choice for accessing it.
rmt_storage = remote storage. Keep in mind that we're dealing with a new SOC - it's perfectly reasonable to assume it has the ability to access eMMC on its own. RPC via rmt_storage is a likely suspect. It would also explain where the missing space went.
Click to expand...
Click to collapse
the emmc is very directly supported by linux.
the radio does not have the ability to talk to the controller, that is why its storage must be proxied through one of its mailboxes to the kernel, and then to the userspace client.
i don't believe it's related to our root issues.
I own a Droid X and I hope you guys have more success with the G2 than the X community has had unlocking our bootloader. In the long run though, the manufacturers will win the battle of locking devices. The answer to this problem is really to stop buying locked devices. Not much chance of that happening either. A pretty depressing picture for the time being and short term future.
burpootus said:
I own a Droid X and I hope you guys have more success with the G2 than the X community has had unlocking our bootloader. In the long run though, the manufacturers will win the battle of locking devices. The answer to this problem is really to stop buying locked devices. Not much chance of that happening either. A pretty depressing picture for the time being and short term future.
Click to expand...
Click to collapse
Its truly my belief that they do these things to prevent having to fix peoples rooted phones... android, with its open market and cross-hardware nature, are already a big risk for manufacturers but fortunately they have given it a shot (and we have rewarded that)
If you were truly passionate about having an unlocked phone, vote with your dollar and buy a dev phone like the new nexus one dev phone.
Otherwise.. pay less and work for root.
Sent from my T-Mobile G2 using XDA App
Hah web2go is 'key operating software' ? I call BS
VValdo said:
But wait- don't you remember the part when T-Mobile said that the inability to save changes is a mere side effect of HTC's security measure intended only to prevent "key operating software from becoming corrupted and rendering the device inoperable"?
And their 90-120 day delays are totally "within the requirements of the open source community", no matter what the GPL might say.
I'll keep looking here.
W
Click to expand...
Click to collapse
Sent from my T-Mobile G2 using XDA App
Related
Now I've got experience with system security among other security related talents. So now basically I've run a unix based server and had to break into it if I lock myself out among other reasons for testing the security level.... So 1 can you open up a terminal with the stock permission settings of the phone.. And two I'm assuming just getting the root password hash and brute forcing the **** out of it for a week or so would get you the root password....but what's at that point keeping us from "ROOTING" froyo....i mean I'm sure one of you has a hash allready dropped.... And are we just waiting for good-old john the ripper to do his thing Or am i slightly confused..or compleatly off. Or that I don't know what I'm talking about and I should do some more reading. Any clarification is appreciated..... Thankyou
Sent from my PC36100 using XDA App
With a server you are just trying to brute force someones, usually lame, password. In this case you would have to crack HTC's security key, instead of a few days consider an optimistic estimate of 20 years to crack with a really fast computer. No gonna happen, what the people that are looking for a break are doing is looking for a security loophole. Each time HTC comes out with an update, they patch the holes that allowed root in the last one, last time it was a vulnerability in flash. we will wait and see where the hole will be found this time. No doubt someone will find one, but it gets harder every time.
Well its still a unix based system right...i mean the only reason id brute force would be too get the original root password..but there's other ways in unix systems too reset the unix password...at that point were would be able to log in as root user..... Or is that not the goal (to just get logged in as root) but rather find ann exploit too give you root user permission.
Sent from my PC36100 using XDA App
Well I guess the encryption key is sort of like a password, but any file that you want to flash to the system area must be signed with HTC's key, which nobody but HTC has.
Here is an interesting quote from this thread in the developers forum regarding the key.
sk63 said:
Brute forcing this is nigh impossible. Based on some back of the envelope calculations, using a top of line personal system, which I estimate around 10 teraflops, or for my calculations, 10 trillion operations per second, a 1024 bit RSA key would take around 3,000 years to crack and if they used a 2048 bit key then number jumps to around 10 trillion years.
To put that in perspective, the largest processing power available today is the [email protected] project at just around 3 Petaflops (3,000 teraflops). If this large amount of power was used it would still take 12 years to crack 1024 and 50 billion years to crack 2048
Click to expand...
Click to collapse
So my point is, the password or "brute force" approach is pretty much the ultimate long shot.
My guess is that what needs to be found is a moment in time when the phones operating system itself has the system area unlocked for a legitimate purpose. During that time window a way needs to be found to flash an unsigned file into the system area that unlocks it permanently. Keep in mind, my expertise in this area is limited at best, so I am just guessing and there may be other ways.
Well.....it sounds good lol but 2.2 was just rooted.... Somewhere on this forum, so they've got the signature required, or atleast found how to get root on froyo.... Now there just trying to find a way to flash the unsigned files too run in the system? Couldn't you just get a big enough memory card and hack itso the os loads from the removable storage
Sent from my PC36100 using XDA App
About 2 weeks ago, I took johnkussack's advice (I think it was him) and went to LinkedIn to try t be friends with anyone who came up on the search for "kin phone". In the invite email, I just said that I noticed they worked on the Kin phones and would like to ask them a few questions on how one could write to the phone. I have had 3 responses in the last 2 days.
Guy1: didn't know because he worked on the UI for the Kin Studio
Guy2: kindly told me he couldn't release an unauthorized build and that he would be breaking the law by doing so.
Guy3: This guy worked on the phone for over a year. He first told me I was breaking the DCMA by hacking/reverse engineering Kin, regardless of intent. Then he said this important thing:
"You are absolutely right in assuming that the device is locked; in fact, it has a hardware lock that is common to many such devices. When the devices roll of the manufacturing line the programming fuses are blown (literally) preventing any further programming of the device. This is all handled by hardware so unless you find a flaw with that you are out of luck."
So if this is true (sounds like it is), the "dream" is over. Hopefully there is some way that someone out there can find.
If I get more responses, I will post them here. Don't ask me to go back to these three who already replied and asked them more questions, I think I made some of them mad.
Hmmmm... I don't know whether or not the KIN models will accept OTA updates so that's a good question to ask. If OTA updates are possible then it's inherently possible to change the software. I wonder...
Yes, it was me the one who said about "linkedin".
But i also said "in one word NDA". You should known even before ask that the signed NDA are also legal contracts, so i prevented before asking them.
On the DCMA, yes.. on the USA. Outside the big country, the legal question is different and may not operate with that law. (if ever). If they provide a normal (legal?) way to unbrick my factory mode here, or to use the phone options, then i wait for the cost for it.
And everyone knew that hardware was not the way, just at the moment where first flash attempt failed. "Dream" is doable by software, if anything is to be done.
What i don't get is why to ask for rom rom roooooms, where we need drivers drivers driveeeeers... or sdk's. We won't get it anyway from MS, but no flashing means a rom is futile, non useful,crap pack of bytes.
But i also said "in one word NDA". You should known even before ask that the signed NDA are also legal contracts, so i prevented before asking them.
Click to expand...
Click to collapse
I figured I just take a shot in the dark; hope for the best and expect the worst. Since the phone and suuport from MS was discontinued, maybe the NDAs would be voided.
And everyone knew that hardware was not the way, just at the moment where first flash attempt failed. "Dream" is doable by software, if anything is to be done.
Click to expand...
Click to collapse
Good to know you still think there's a way.
What i don't get is why to ask for rom rom roooooms, where we need drivers drivers driveeeeers... or sdk's. We won't get it anyway from MS, but no flashing means a rom is futile, non useful,crap pack of bytes.
Click to expand...
Click to collapse
I just asked if "there is a way to get around the write lock". Had I known ahead of time to ask about drivers or SDKs, I would have put that in the msg.
I strongly believe that we could operate with the device,softwarewise. there is proof that the kin NAND memory (for now on, called "Storage" as label) is writeable. Not sure on the Rom part.
Of course, i mean.. just use it as a normal writable storage memory.
I posted how it could be done and would do it myself but, again, i bricked my phone, and available ones (through bidding sites) are so expensive to buy another one just for this (+ $150). Don't see a way to get it internationally again.
And even doing it, i'm not sure about what could be done just writing on the storage mem....
If the fuse byte is burn't should not it have prevented you from bricking?
kintwouser said:
If the fuse byte is burn't should not it have prevented you from bricking?
Click to expand...
Click to collapse
Nvitem bricked, not flashing bricked. You can succesfully write to the NVItems memory. But i guess it's just configuration memory and not the one "fused".
I just want to mention that jailbreaking a phone is NOT illegal in the United States! Geohot hacked the iphone... Apple went after him... Apple lost.
Also blowing the programming fuses seems a little fishy to me actually. No other phone does that. The majority of other phones have been flashed. I just think it would be pretty odd for a company to do that so that they no longer could update it. I am not sure I believe him. If this really was true... then why wouldn't Apple or Sony be doing it? This also doesn't make sense since Microsoft actually originally intended on putting WP7 on this as well as allowing apps for it. Check this article out:
http://www.intomobile.com/2010/05/12/kin-windows-phone-7-a-lot-closer-than-we-thought/
you must understand, its not possible to blow fuses in the hardware, it would be a top news story if they were able to keep the OS running in complience with the flash memory without it crashing. Obviously that was a lie to discourage us, and i dont even think that was a real kin developer, because microsoft clearly stated that all kin developers would be moved to WP7 or another programming section. And it doesnt matter if its legal or not to jailbrake phones, if we are porting a new OS, we wouldnt have modified the original OS, which is what jailbraking means. Most likely the OS is hidden deep in the flash memory with a write - protection. If you think its saying access denied because they said the fuses were blown, its wrong. They must just have a password or code that needs to be sent continuasly to the phone to access files. If the fuses were blown, then nothing would be able to be accessed by zune, because it would be impossible to reach the memory.
soninja8 said:
Most likely the OS is hidden deep in the flash memory with a write - protection. If you think its saying access denied because they said the fuses were blown, its wrong. They must just have a password or code that needs to be sent continuasly to the phone to access files. If the fuses were blown, then nothing would be able to be accessed by zune, because it would be impossible to reach the memory.
Click to expand...
Click to collapse
Not my expertise field, but this mobiles can (and in fact they do) have several memories, storing the OS in the ROM memory and all the data on the NAND memory (our "8gb" storage).
Zune software has protocols to query for available storages (requiring its label/id) and is allowed to write/read to it. If you dare to click on update version (at least in the 1st version I tried) it expressed that the option was not "available" to that device without web requesting data, apparently.
So.. in the nand flash we may only have the equivalent of a SD Card. And my last wince PDA showed that as /Storage too, apart from main wince ROM.
You can format the nand memory using win explorer if in fact it is the 8gig storage. I did this and it deleted all pics,albums etc. It was interesting to note that we cannot copy or view these pics without an access error but it does let me delete them.
I just wan't to be able to get my pics off this piece of crap without emailing them.
I posted it once. You are able to:
- Query storage properties (label, size, id,...)
- Query storage folders
- Query folder files.
- Query tracks / albums / playlist / images / anyZuneSupportedFile
- Delete * file (whatever)
- Format the storage
You are "unable" to:
- Upload (create) a file into the device
- Download a file from the device.
MTP protocol tools allows you to do so, from command line (not quite sure if they are available on Win32 OS's), but... fails to operate with this device when it comes to the "unavailable" operations.
I am curious as to which former developers you contacted?
I was doing some research and noticed that Microsoft acquired the company Danger, Inc. After Microsoft purchased them, the former president of Danger went to develop Android (later acquired by Google). One thing I read was that most of Dangers employees left after being purchased by Microsoft. Apparently these people don't like Microsoft all that much! I also looked into it a little more and found one of the founders of Danger who had a twitter account. Of course all of his tweets were via a "KIN". Thought that was interesting. It seems to me that these former Danger employees would be interested in helping out if they don't hold to high of an esteem for the big "M".
seems like this is your first "inside the move" trying-to-hack/reverse a thing, so i will say:
people involved doesnt wanna risk through legal issues, even if they were pissed off, just for "some kids" to have a driver or rom. NDA are strong there, and they could either sign them or leave (if leaving, they don't have the interesting things).
At most you would get bad-mood or good-luck comments, and ocassionaly (very uncommon), leaks (wont happen here).
yeah, they purchased danger for an amazing 500 million dollars, which they later developed the kin with it, they were planning to put windows phone 7 on it, but they were to behind and released it with the old windows CE, then the former developer moved to work on a free source OS, later called android. Google wanted to get android while it was cheap, so they bought that company, and made the old developer as 2nd engineer.
Maybe not worth yet, but we should get more *info* about the SBL mode (aka "Ms Pink Bootstrap), as coinflipper said that it was the way to flash OS or parts (like radio's).
I have been trying even OMA wap WBXML bootstrap examples with it, but as we dont know if our phone is standard, it's like looking for a water drop in the sea of possibilities.
We do not need a guide on how to do something, but what-to-do with it.
Maybe, JUST MAYBE, we could design a program like bitpim. I am a mac user and when I used bitpim with my enV touch, I used to edit all sorts of files. Examples would be phone info, server info etc. We could make a program like that to get the info. I know programming may be hard, but its worth a shot. I hate the OS on this phone, ESPECIALLY WHEN YOU PIN APPS! THEY LOOK HORRIBLE
Kinuser1 said:
Maybe, JUST MAYBE, we could design a program like bitpim. I am a mac user and when I used bitpim with my enV touch, I used to edit all sorts of files.
Click to expand...
Click to collapse
We can't. If we have not the protocols or the supported phone features (protocols, drivers, documentation,...) you cannot guess it and put it into visual basic (or Xcode) and then by *magic*get the program you want.
i will admit that i know very little about protocols and drivers but i would like to point out that bitpim is open source, and that the code can be found here ->
http-//sourceforge.net/scm/?type=svn&group_id=75211 (change "-" to ":")
i seem to recall bitpim already having limited support for the kin, but perhaps with a little research and a little code tweaking we can find ways to improve it? i'm not sure how feasable it is as i have very little experience with programming for phones/usb devices, but it's just a thought.
slimeq said:
i will admit that i know very little about protocols and drivers but i would like to point out that bitpim is open source, and that the code can be found here ->
http-//sourceforge.net/scm/?type=svn&group_id=75211 (change "-" to ":")
i seem to recall bitpim already having limited support for the kin, but perhaps with a little research and a little code tweaking we can find ways to improve it? i'm not sure how feasable it is as i have very little experience with programming for phones/usb devices, but it's just a thought.
Click to expand...
Click to collapse
We can't. If we have not the protocols or the supported phone features (protocols, drivers, documentation,...) you cannot guess it and put it into visual basic (or Xcode) and then by *magic*get the program you want.
Click to expand...
Click to collapse
The above applies to any software you want. Unless you magically found documentation or files (like OP), there's no way to. So f#cked.
The thing is always the same, tweaking tweaking... what to tweak, huh?
As it is known that HTCUtility.dll will provide complete, unrestricted access to the TCB chamber on HTC devices, can this be used to unlock (at any level) the OS?
I have not heard anyone speaking of it and exists on my HTC Arrive. Seems to be a bypass for unrestricted access to anything within HTC devices.
I am looking at it myself, but thought I would share.
See details here...
http://labs.mwrinfosecurity.com/files/Advisories/mwri_htc-htcutility-kernmem_2011-11-10.pdf
Your link is down
very interesting but you link is down so please fix it so I can take a look. I too have a HTC arrive and have been working on an unlock.
Don't know what happened to the link.
Here is the link to the google docs version.
https://docs.google.com/viewer?a=v&...1C1HkN&sig=AHIEtbTwK-r8RyAyFmt1ai119m7EVAqsNA
-Paul
This looks promising, I'd like to know if what's written there is true ...
The paper is a couple months old, so it *could* have been patched by HTC... but hey, it also might not have been! This bears investigation post-haste.
It's easy enough to use this to execute some arbitrary code at high permissions, which is certainly useful as-is (do things like unrestricted registry and filesystem access). The real potential of it, though, is to turn off the security restrictions for specific apps. Essentially, get the benefits of a "fully unlocked" ROM but on a stock ROM, and only for the apps you specify.
One thing to note here: this is still going to require an interop-unlocked phone. It's opening a handle to a driver, and just like everything else that does so, it needs ID_CAP_INTEROPSERVICES. This is great news for owners of interop-unlocked/unlockabe phones (since this makes interop-unlock useful again) but probably doesn't help on 2nd-gen phones or on the Arrive (unless you want to roll back to NoDo, in which case this can probably be used to make an interop-unlock that works on Mango, though it wouldn't be easy).
I hope some one gets this working for the Arrive ASAP
Oh this was talked about a while back. It was patched back in NODO
Really? The paper is from only 3 months ago (assuming USA numeric date style, 2 months otherwise). You don't typically publish security advisories for things that were patched more than 6 months prior.
In any case, HTCUtility.dll still exists on my phone. No idea yet if that IOCTL still works, though. I'll try it out in any case, and report back.
For those asking about it for the Arrive though, you're likely out of luck even if this works. It is *not* a way to interop-unlock a phone, and it is *not* a way around interop-unlock. It's a way to do more things on an interop-unlocked phone. You can't even reach a driver (which is what HTCUtility.dll is) unless your app has ID_CAP_INTEROPSERVICES - that's what the capability is actually for, accessing drivers - and you can't install a homebrew app with that capability unless interop-unlocked (or on pre-Mango).
GoodDayToDie said:
I'll try it out in any case, and report back.
Click to expand...
Click to collapse
Thank you
GoodDayToDie said:
Really? The paper is from only 3 months ago (assuming USA numeric date style, 2 months otherwise). You don't typically publish security advisories for things that were patched more than 6 months prior.
In any case, HTCUtility.dll still exists on my phone. No idea yet if that IOCTL still works, though. I'll try it out in any case, and report back.
For those asking about it for the Arrive though, you're likely out of luck even if this works. It is *not* a way to interop-unlock a phone, and it is *not* a way around interop-unlock. It's a way to do more things on an interop-unlocked phone. You can't even reach a driver (which is what HTCUtility.dll is) unless your app has ID_CAP_INTEROPSERVICES - that's what the capability is actually for, accessing drivers - and you can't install a homebrew app with that capability unless interop-unlocked (or on pre-Mango).
Click to expand...
Click to collapse
Yeah I think it was mentioned here on XDA and it was believed to already have been patched.
I think by "patch" they mean that Interop was restricted as of Mango, thereby securing this exploit, in Mango. But for those that are Interop unlocked, this should still grant full access to everything else.
Just my observations. I have an Arrive and am not Interop unlocked yet, so I can't test it.
Looking at the hand-free provisioning to see if I can find a way to leverage that....
-Paul
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
GoodDayToDie said:
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
Click to expand...
Click to collapse
All the information looks like it is in the advisory. KDataStruct is what you want. That is equivalent to the PEB in Windows CE.
GoodDayToDie said:
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
Click to expand...
Click to collapse
Can you confirm this works only on already Interop Unlocked device ?
Thx for your efforts.
Could htclv.dll be helpful in setting security on an app? It supports the following functions:
LVModInitialize LVModUninitialize LVModAuthenticateFile LVModRouting LVModAuthorize LVModGetPageHashData LVModCloseAuthenticationHandle LVModGetHash LVModProvisionSecurityForApplication LVModDeprovisionSecurityForApplication LVModGetSignerCertificateThumbprint LVModSetDeveloperUnlockState LVModAuthorizeVolatileCertificate LVModGetDeveloperUnlockState
In particular the "Deprovision Security for App" and "Get/set DeveloperUnlock" or maybe "Authorize Volatile Certificate"....
Or maybe htcpl.dll which seems to be the HTC policy engine interface. Supports:
GetFunctionTable PolicyCloseHandle PolicyEngineInit PolicyRuleAbortTransaction PolicyRuleAddRawData PolicyRuleBeginTransaction PolicyRuleBuildRawData PolicyRuleCommit PolicyRuleCommitTransaction PolicyRuleCreate PolicyRuleDelete PolicyRuleFindFirst PolicyRuleFindNext PolicyRuleGetInfo PolicyRuleOpen PolicyRuleParseRawData PolicyRuleReadRawData
These all look good to modify the security policies on HTC, assuming Interop-Unlocked.
-Paul
@dragonide: Confirmed, this requires interop-unlock since the very first step is opening a handle to a driver.
@Paul_Hammons: The LVMod functions look quite interesting indeed. Where are you getting these functions from (straight out of the DLLs, or some doc somewhere, or decompiled code, or...?), are they user or kernel entry points, and what permissions do they require? The ability to modify app security doesn't do as much good if you already have to be high-privileged to call it, though it might simplify my current goal.
@n0psl3d: Cool, I'll get to work on it.
@n0psl3d: KDataStruct contains kernel information, but I'm pretty sure what I need is in a PROCESS struct (such as is pointed to by pCurPrc). The problem is, I can't find any documentation for that struct. I'm searching online but so far coming up empty. CE doesn't seem to use PEBs or TEBs as I've seen them on NT (not terribly surprising, but annoying).
EDIT: I'm downloading the Embedded CE toolkit, which comes with source code. It'll take a while but hopefully that will have what I need.
OK, digging through the CE source I've found some interesting things. No idea if this will work yet; it'll be exciting just to make it compile.
PROCESS struct -> hTok (handle to a Token) -> phd (PHDATA, pointer to the handle data) -> pvObj (PVOID to the actual object, which is probably a TOKENINFO) -> psi (pointer to ADBI_SECURITY_INFO) -> contains the actual ACLs and privileges, and can be created from an account ID.
Probably the easiest option is to find a relatively high-privilege process and clone its token or some such. Token re-use (if I increment the reference count, this should work) may be easier. Modifying an existing token might also be doable.
Anyhow, I'm not going to have this finished tonight, but it'll get there. For those wondering wht you can do with this, it basically breaks you out of the sandbox entirely. You can call any function, access any resource, etc. that is available to a userland process (executing in kernel mode is also possible but trickier). Practically speaking, this makes all the other high-privilege COM DLLs useless - instead of ComFileRW, just use the file IO methods (anywhere you want), instead of DMXMLCOM just call ConfigProvXml directly. Even things like launching native EXEs directly should become possible (run those Opera ports on a stock ROM, for example).
I'm sorry, I still don't know what any of that means. But it sounds good! I wish I knew how to do this kind of stuff. Thanks for all of your work!
I'm posting this here because it says I need to get 10 posts in order to post on the Windows 8 development forums.
Why does the Windows RT jailbreak require that you press the volume button? As far as I can tell, pressing volume is used to trigger a code path in winsrv.dll on which a hook is placed. The hook jumps to the code cave between the .text and .data segments.
Reading the disassembly, the injected code uses the native API equivalent of EnumDeviceDrivers to get ntoskrnl.exe's base address, then calls the broken NtUserSetInformationThread subfunction 9 0x7EFF0 times to clear g_ciEnabled in the kernel. (I read the part about interlocked operations causing an exception in ARM if the target is unaligned, unlike x86 where it's merely not atomic.)
Instead of hooking an existing code path, why not inject a DLL into csrss.exe and create a thread in it? This seems like it would be much more stable, and wouldn't require pressing the volume button. CreateRemoteThread doesn't work with csrss.exe, because it tries to register the new thread with csrss.exe. Oops. However, RtlCreateUserThread *does* work, since native threads don't need to talk to csrss.
Where did cdb.exe come from? It doesn't come with the Visual Studio 2012 Remote Tools, so I'm guessing that it's a leak. In the absence of any other information, I'm going to guess that it's a leaked ARM version of Debugging Tools for Windows given to hardware developers who write drivers for Windows RT.
I'm working on a custom jailbreak that improves on a lot of issues. It's a single file, a .bat, that extracts everything needed, and a jailbreak program written in C. I've already gotten the custom C DLL loaded and executing, and am now looking into what I need to do to csrss.exe. Getting code executing inside csrss.exe won't be too hard, but I'm wondering what that code will need to do.
Moved here as not an Android related development issue, so was out of place in General forums.
You won't be able to inject .dll's. Windows will refuse to load the modules, unless the jailbreak has already ran.
As far as why it needs the volume button, you're correct in that it just executes an easily hooked code path in csrss.
netham45 said:
You won't be able to inject .dll's. Windows will refuse to load the modules, unless the jailbreak has already ran.
As far as why it needs the volume button, you're correct in that it just executes an easily hooked code path in csrss.
Click to expand...
Click to collapse
My DLL was linked with /filealign:4096, resulting in a perfect RVA to file offset mapping (assuming I don't create more than a small amount of zero-initialized global variables). With that, I can use NtMapViewOfSection without SEC_IMAGE to map it into csrss's memory without ci.dll getting in the way.
Once the DLL is mapped, I fix up its relocations, load the imports, and RtlAddFunctionTable. From there, the DLL is stable enough to do most things. All this works already - I'm just writing what to do next.
Does Tuesday's win32k.sys patch fix this bug? I saw that the patch had fixes for like 20 win32k bugs found by the Google guy who discovered the NtUserSetInformationThread 9 exploit.
Myriachan said:
I'm posting this here because it says I need to get 10 posts in order to post on the Windows 8 development forums.
Why does the Windows RT jailbreak require that you press the volume button? As far as I can tell, pressing volume is used to trigger a code path in winsrv.dll on which a hook is placed. The hook jumps to the code cave between the .text and .data segments.
Reading the disassembly, the injected code uses the native API equivalent of EnumDeviceDrivers to get ntoskrnl.exe's base address, then calls the broken NtUserSetInformationThread subfunction 9 0x7EFF0 times to clear g_ciEnabled in the kernel. (I read the part about interlocked operations causing an exception in ARM if the target is unaligned, unlike x86 where it's merely not atomic.)
Instead of hooking an existing code path, why not inject a DLL into csrss.exe and create a thread in it? This seems like it would be much more stable, and wouldn't require pressing the volume button. CreateRemoteThread doesn't work with csrss.exe, because it tries to register the new thread with csrss.exe. Oops. However, RtlCreateUserThread *does* work, since native threads don't need to talk to csrss.
Where did cdb.exe come from? It doesn't come with the Visual Studio 2012 Remote Tools, so I'm guessing that it's a leak. In the absence of any other information, I'm going to guess that it's a leaked ARM version of Debugging Tools for Windows given to hardware developers who write drivers for Windows RT.
I'm working on a custom jailbreak that improves on a lot of issues. It's a single file, a .bat, that extracts everything needed, and a jailbreak program written in C. I've already gotten the custom C DLL loaded and executing, and am now looking into what I need to do to csrss.exe. Getting code executing inside csrss.exe won't be too hard, but I'm wondering what that code will need to do.
Click to expand...
Click to collapse
Hello!
Glad to see here sensible Guru, who understand, that non-permanent JB, requiring "Vol -" pressing and hanging in RAM - is a vicious way! I can't understand reluctance of Netham45 to make a permanent JB (nothing personal). If you will develop your own JB with options, described above, it will be a breakthrough! Wish you good luck and fastest implementation of planned :fingers-crossed:
If you think netham45 is reluctant to make a permanent jailbreak, your lack of understanding is far greater than you know. A permanent jailbreak would be excellent, especially one that was active immediately at boot (instead of requiring a delay after booting, during which time the default restrictions are still in place).
However, there are some issues with the current jailbreak technique. In particular, it's dependent upon knowing the correct offset for the flag that needs changing, there's no way to know for certain the state of that flag before writing it, and the offset changes with updates. If the wrong offset is written to, or the wrong value written, the system crashes. Therefore, making a "permanent" jailbreak using this hack runs a very real and serious risk of putting the device into a bluescreen-reboot loop after an update, even one that isn't intended to break the jailbreak, just by accident.
In order to make a reasonably safe permanent jailbreak, a new jailbreak method will need to be discovered. That's not a trivial thing; the first one took some time to discover at all, and the effort on finding new methods has fallen off somewhat as many people are now looking for ways to use the existing one rather than looking for new ones. Additionally, even if a new method is found (which would be good; we should always have a backup), there's no guarantee that the new technique will any better-suited for being persistent or even automatic on bootup.
GoodDayToDie said:
However, there are some issues with the current jailbreak technique. In particular, it's dependent upon knowing the correct offset for the flag that needs changing, there's no way to know for certain the state of that flag before writing it, and the offset changes with updates. If the wrong offset is written to, or the wrong value written, the system crashes. Therefore, making a "permanent" jailbreak using this hack runs a very real and serious risk of putting the device into a bluescreen-reboot loop after an update, even one that isn't intended to break the jailbreak, just by accident.
Click to expand...
Click to collapse
I did put in some code to automatically find the offset (downloads the pdbs from MS and disassembles that chunk of code from ntoskrnl and parses it), though it still does make some heavy assumptions that I wish I could do without. It should be in 1.13a.
Note that it's still just assuming that csrss is perfect, though.
Denis_63 said:
Hello!
Glad to see here sensible Guru, who understand, that non-permanent JB, requiring "Vol -" pressing and hanging in RAM - is a vicious way! I can't understand reluctance of Netham45 to make a permanent JB (nothing personal). If you will develop your own JB with options, described above, it will be a breakthrough! Wish you good luck and fastest implementation of planned :fingers-crossed:
Click to expand...
Click to collapse
I'd love a persistent jailbreak, but we don't have an exploit for one yet. I'm not reluctant to make one, I don't presently have the ability to. The tool that Myriachan is talking about would have the same issue.
netham45
GoodDayToDie
Hey, guys, I bag pardon, if I were too harsh... I'm not the Guru as you are, and really had no notion about the level of complexity of the problem. Becose of that I wrote - "Nothing personal" Wish all of you GOOD LUCK in your important work!
Hey everyone, I've been a lurker for quite sometime, so I'm finally posting something. This is isn't in any of the dev sections because this is my first post.
When I first got my GNex (toroplus) was very annoyed with the capabilities of the gsd4t gps chip. Static navigation makes it really hard to use the chip for telemetry projects and the 1Hz position update doesn't give me enough sample data for the things I'm working on. I decided to do some investigation to see if it was limited to the hardware itself or the driver.
I scoured the forum, and tried a bunch of apps, found datasheets and the what not and nothing really improved my situation. I decided to take matters into my own hands and poke around lib_gsd4t.so (stock).
With verbose logging turned on, I noticed an interesting looking entry.
Code:
Hello EE downloder !!!.
{sgee.samsung.csr.com, instantfix.csr.com}, port : 80
Y3Nyc2xsOmROTkw5NnN1, /diff/packedDifference.f2p3enc.ee, format 2
EE_DOWNLOAD: EE_Download_Init done.
EE_Download_Init - returned 0 !!!.
EE_DOWNLOAD: EE_Download_Start successful.
EE_DOWNLOAD:EE_Download_Scheduler started; server_address=(sgee.samsung.csr.com,instantfix.csr.com), port=80, file=/diff/packedDifference.f2p3enc.ee
...
The string Y3Nyc2xsOmROTkw5NnN1 really stuck out to me. The character set fit in the base64 space which for some reason or another, developers seem to think base64 encoded text is somehow a good way to make things more secure. I have seen this numerous times. To me, it just makes it more noticeable that someone is trying to hide something.
So I went ahead and decoded the string and got
Code:
csrsll:dNNL96su
Just to be sure it wasn't some string unique to my phone, I checked where it most likely came from, which is the lib_gsd4t.so and it is indeed there (@offset 0x1b7429).
What's so special about that string?
I'm almost 100% sure that it is the username : password combo for downloading the SGEE data. I'm guessing it is using a post request (anyone wanting to use wireshark to packet sniff this can confirm) because there are extra parameters being used to retrieve the data.
Have I tried to access the file with those credentials?
No.
Why am I posting this?
I thought it was funny that the username and password are hardcoded in the driver and written to the logs. What's the point of having it password protected if you're just going to tell everyone the account credentials?
My actual job involves application security and I used this as an example for the other programmers on my team as to why we shouldn't ever mistake encoding for encryption and if you try to hide something, chances are you are actually drawing attention to it.
Oh also, is anyone interested in knowing more about the library. I have figured out quite a bit
How odd!
If you've figured out the gps drivers maybe you know how to make an updated file to disable static navigation? I op'd this thread http://forum.xda-developers.com/showthread.php?p=38684789 based on the ics version, but would love an android 422 based mod.
I posted my modded drivers. It may also require new configs.
afrotronics said:
I posted my modded drivers. It may also require new configs.
Click to expand...
Click to collapse
Did you ever figure out the proper request? (curl or wget?)