Related
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
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?
I can still sidle load and my phone is still interop unlocked but neither my registry editor nor my advanced configuration editor work. Way to go HTC and MS, pat your selves on the back. I pay $99 dollars a year to have my phone unlocked and to develop apps but I can't even develop useful apps because APIs and restrictions, I can't customize my phone with out hacks, nothing! And to top it all off the phone has very limited functionality. What is MS thinking? I'm seriously thinking about jumping ship after being a loyal Windows Mobile supporter from the very begging. It use to make me sick to think about how flooded the market is with Android phones and now I know why. I can't even come on here and vent my frustrations or voice my opinions without someone getting offended or warned like I'm some child. Granted that all phones have their fails but not as many as this phone, I wish Windows Mobile was still around, imagine a world with no having to have an Windows live account or no complicated Zune, imagine just being able to do what you want or need to do without any limitations or restrictions. Imagine being able to laugh at Android and iPhone users. I honestly don't see Windows Phone 8 being any better at all. Say what you want, lash out at me with your fan boy comments, report me to your MOD but no matter what you say or do at this rate WP will fail.
what is the radio driver version , is it 5.71??
well u cant blame anyone, WP7 is more secure than IOS.
thats a good thing right?
The purpose of paying $99 per year is to develop applications and publish them to the app store.
Being able to sideload for anything other than testing was just a side benefit.
If all you wanted was to side load apps, the ChevRon utility would have been a much better deal. One time fee verses yearly and 10% the cost.
Surprised that the radio drivers are to blame. Unless there was a flaw in them that was being exploited to make the editor.
It is pretty annoying that you can't directly programatically alter the registry.
But, I believe the provisioning methods still work. Just write a C# app that will provision a file. Then have the app generate an xml provisioning string to alter the registry and apply it.
There are ways to read the registry doing the same thing.
I can probably find a link in the Windows Phone 7 development section on how to do this.
I will update with a link if I find something.
Link for an HTC ProvXML importer and Reg to Prov XML convertor: http://forum.xda-developers.com/showthread.php?t=907169&highlight=registry
Try searching that forum for ProvXML. There probably are examples. Serach is temporarily disabled. It always around this time of day for about 20 to 30 minutes.
I was afraid of this. The HTC driver updates may have been to v2 and that breaks the interop-unlock ability (such as allowing ACT and Reg Editors to run). This is known and mentioned by Heathcliff.
Magpir said:
what is the radio driver version , is it 5.71??
well u cant blame anyone, WP7 is more secure than IOS.
thats a good thing right?
Click to expand...
Click to collapse
They just fixed an exploit.
Of course it's good to have your own device unlocked, but if Microsoft or HTC wanted you to modify the registry they would have released that feature natively.
For example LG has a native application to do this on their Windows Phones.
I interop unlocked my girlfriend's Optimus 7 the next day she got it in 1-2 mins.
what has the radio got to do with this?
will downgrading radio help then?
I know, it's my fault for being stupid and accepting the update, it's a little faster but I noticed it drains my battery much quicker and it disabled my reg exploits. to be honest I thought it was the keyboard fix but the keyboard seems to be getting worse. Microsoft is not what it use to be, Steve Jobs was right, MS is not original and always steal Apples ideas, why if the thing that made WM better is what is diving Androids success. I went to the T-Mobile store and was tempted to switch but walked out and have not decided yet but I just give up on WP this year if MS doesn't stop being so Communist like.
JVH3 said:
The purpose of paying $99 per year is to develop applications and publish them to the app store.
Being able to sideload for anything other than testing was just a side benefit.
If all you wanted was to side load apps, the ChevRon utility would have been a much better deal. One time fee verses yearly and 10% the cost.
Surprised that the radio drivers are to blame. Unless there was a flaw in them that was being exploited to make the editor.
It is pretty annoying that you can't directly programatically alter the registry.
But, I believe the provisioning methods still work. Just write a C# app that will provision a file. Then have the app generate an xml provisioning string to alter the registry and apply it.
There are ways to read the registry doing the same thing.
I can probably find a link in the Windows Phone 7 development section on how to do this.
I will update with a link if I find something.
Link for an HTC ProvXML importer and Reg to Prov XML convertor: http://forum.xda-developers.com/showthread.php?t=907169&highlight=registry
Try searching that forum for ProvXML. There probably are examples. Serach is temporarily disabled. It always around this time of day for about 20 to 30 minutes.
Click to expand...
Click to collapse
Unfortunately I don't know how to work with ProvXML's. I will check out your link, thanks. do you by any chance know how to change the dark background color back to black using this method?
So you mean to tell me that Windows Phone is actually more secure than the iPhone? God all mighty!! I seriously hope Windows 8 is not as lame as Windows Phone.
sinister1 said:
Unfortunately I don't know how to work with ProvXML's. I will check out your link, thanks. do you by any chance know how to change the dark background color back to black using this method?
Click to expand...
Click to collapse
I just read the thread you sent me and it says that the new drivers also disable this method too.
To the OP, they also fixed a problem, If you ran connection setup with your phone in CDMA mode, it would kill 3G and the only real way to get it back was to hard reset the phone. It also broke those apps too.
To note, I manually installed 8107(last weekend, 3 days before vzw's release) and it did break Advanced Config (could not add more colors but, only had 3-4 extra onces) but, I am still able to sideload as I need. So, I'm not sure if it was the firmware that broke it...
I don't know what the big deal is with MS not letting us to simply personalize our phones? I mean really what is wrong with changing a notification tone, background color or tile color? If they really don't want anyone hacking the phone then simply give us those options. In every update instead of giving us simple features and options that we want all they do is secure the damn phone down even more It's almost like Microsoft wants to fail. Who wants to pay for a phone that is dictated to the point to where you can't even do that? As much as I hate to admit it; Android is coming up more and more when I think about my options.
sinister1 said:
I don't know what the big deal is with MS not letting us to simply personalize our phones? I mean really what is wrong with changing a notification tone, background color or tile color? If they really don't want anyone hacking the phone then simply give us those options. In every update instead of giving us simple features and options that we want all they do is secure the damn phone down even more It's almost like Microsoft wants to fail. Who wants to pay for a phone that is dictated to the point to where you can't even do that? As much as I hate to admit it; Android is coming up more and more when I think about my options.
Click to expand...
Click to collapse
I guess it really comes down to what you can do. Opening up the phone, opens it to hack software to run. So, it opens a world of phones with pirated software on it with nothing MS can do it about it. Not everyone will go this route but, there are people who will not buy anything, and that kills the marketplace and vendors who will add to the marketplace.
As I always say, Pirates will always Pirate, block them and they'll find another way around it. BUT with blocking it makes honest people have a harder time to use their devices or software.
I personally just want to customize my phone and use all the home brew apps but, sad to say they will try to block the honest people just to attempt to stop the pirates...
Back to the subject on hand...
So, Connection setup no longer works (I get a Invalid sim if I go to GSM mode or in CDMA mode, Carrer is not in the database), is it possable to get a older version to sideload that would enable registry edits again ?
DavidinCT said:
I guess it really comes down to what you can do. Opening up the phone, opens it to hack software to run. So, it opens a world of phones with pirated software on it with nothing MS can do it about it. Not everyone will go this route but, there are people who will not buy anything, and that kills the marketplace and vendors who will add to the marketplace.
As I always say, Pirates will always Pirate, block them and they'll find another way around it. BUT with blocking it makes honest people have a harder time to use their devices or software.
I personally just want to customize my phone and use all the home brew apps but, sad to say they will try to block the honest people just to attempt to stop the pirates...
Back to the subject on hand...
So, Connection setup no longer works (I get a Invalid sim if I go to GSM mode or in CDMA mode, Carrer is not in the database), is it possable to get a older version to sideload that would enable registry edits again ?
Click to expand...
Click to collapse
I had that problem before, I had to toggle airplane mode and WIFI back and forth until it took.
DavidinCT said:
I guess it really comes down to what you can do. Opening up the phone, opens it to hack software to run. So, it opens a world of phones with pirated software on it with nothing MS can do it about it. Not everyone will go this route but, there are people who will not buy anything, and that kills the marketplace and vendors who will add to the marketplace.
As I always say, Pirates will always Pirate, block them and they'll find another way around it. BUT with blocking it makes honest people have a harder time to use their devices or software.
I personally just want to customize my phone and use all the home brew apps but, sad to say they will try to block the honest people just to attempt to stop the pirates...
Back to the subject on hand...
So, Connection setup no longer works (I get a Invalid sim if I go to GSM mode or in CDMA mode, Carrer is not in the database), is it possable to get a older version to sideload that would enable registry edits again ?
Click to expand...
Click to collapse
The registry being locked down is less to do with piracy than control.
Code for the Windows Phone 7 was not a complete rewrite of the OS. They did reuse much of the old Windows Phone 6.5. They might have reviewed each piece and modified most, but they did reuse code. If they give you or developers control of the registry, then the entire device could be put into a state that would make nothing work. Or worse, your phone could be made to do just about anything in the background without your knowledge.
It's one thing to not allow programmers to access it. It's another to stop users from doing it intentionally. Any user doing it themself, knows the risks. And you can always reset the phone.
This latest lockdown might spur more interest in creating custom ROMs. Not sure if it is even possible yet for things like the Titan 2 and the new Nokia phones. But, this is the site to find out or find people doing it.
Your right I don't think it's possible at least not for the Trophy or CDMA phones at the moment, I guess we are just stuck at the state of sucks. Either way MS isn't making any money with their strategy at all the hold like 1% of the market; if it weren't for their PC sales they would have already went under.
sinister1 said:
Your right I don't think it's possible at least not for the Trophy or CDMA phones at the moment, I guess we are just stuck at the state of sucks. Either way MS isn't making any money with their strategy at all the hold like 1% of the market; if it weren't for their PC sales they would have already went under.
Click to expand...
Click to collapse
Microsoft has alot more products as well. SQL Server, Visual Studio (professionals don't use the express versions), Exchange Server, Office, XBox 360, msdn subscriptions, Skype, etc.
Microsoft makes money on all HTC and Samsung Android sales. Somewhere between $10 to $15 for each Samsung Android Phone and somewhere around $5 to $10 for HTC Android phone from patent licensing.
So, every Android sold helps Microsoft. Hopefully they use those dollars to improve Windows Phone 7.
This is actually the real reason that Microsoft can afford to deliver things a little late and still be OK.
They have a ton of cash flowing in all the time and the competition financially supports them.
I'm guessing that there is still a way using provisioning to affect the registry. When exchange servers push policies down, I thought they did that through provisioning. If exchange can do this, then there should be another way as well.
It's also how custom ringtones were created prior to Mango. It would create a xap to create a program that would write a ringtone file using provisioning. Something similar should be doable for the registry. Doing it this way would require you to use a computer to deploy the changes, but you should be able to make them.
Thaks guys for your feed back and support. If anyone knows a way that I can change my background back to default #FF00000 black now that the registry option is gone; please let me know, I will dontae becuse I have lookd at some Android phones and to be honest they are always pluged in and charging and the only other opption is the iPhone
Hmm.. was about to update and then cancelled it when I read this. Does it add tethering? but since it still lets us sideload... I kind of want to update, I don't do any registry stuff and i can always hard reset to interop unlock again right?
slick13 said:
Hmm.. was about to update and then cancelled it when I read this. Does it add tethering? but since it still lets us sideload... I kind of want to update, I don't do any registry stuff and i can always hard reset to interop unlock again right?
Click to expand...
Click to collapse
No it actually does nothing other that updates your radio's firmware and blocks exploits, worth less update unless you travel out of the country. This was lame on HTC and Verizon's part. I hate Verizon, MS should just stop doing business with them.
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!
Out of curiosity why isn't root allowed out of the box on the Nexus 7?
I mean I get that no one should use superuser access/root privileges on anything more than a "need to use" basis and honestly, I'll even admit that with the way the ecosystem has evolved, root isn't really entirely "needed" but, it still boggles my mind that there is no way I can just open up a terminal, type in a code, and get root.
I've tried googling the issue but, I generally get a bunch of responses about things which aren't quite related.
Snow_fox said:
Out of curiosity why isn't root allowed out of the box on the Nexus 7?
I mean I get that no one should use superuser access/root privileges on anything more than a "need to use" basis and honestly, I'll even admit that with the way the ecosystem has evolved, root isn't really entirely "needed" but, it still boggles my mind that there is no way I can just open up a terminal, type in a code, and get root.
I've tried googling the issue but, I generally get a bunch of responses about things which aren't quite related.
Click to expand...
Click to collapse
I think its fine the way it is. its jailbroken out of the box so you can use your device how you wish and that is what matters. You can't expect a company to support users to change everything about it. Then people complain about bricked devices or contact them for support for some custom rom.
However I believe they made it pretty easy to root. They certainly could have made it a lot harder. Anyone who has the skills (or patience to learn how) to use root certainly can root a device based on the tutorials given. And other users who don't want to worry about it don't ever see it. The little bit of effort helps weed out the people who would mess things up for themselves.
firesoul453 said:
I think its fine the way it is. its jailbroken out of the box so you can use your device how you wish and that is what matters. You can't expect a company to support users to change everything about it. Then people complain about bricked devices or contact them for support for some custom rom.
However I believe they made it pretty easy to root. They certainly could have made it a lot harder. Anyone who has the skills (or patience to learn how) to use root certainly can root a device based on the tutorials given. And other users who don't want to worry about it don't ever see it. The little bit of effort helps weed out the people who would mess things up for themselves.
Click to expand...
Click to collapse
I don't expect a company to support me changing anything I want about it. If I misuse root privileges, then I don't expect to have a lifeline when I call asus/google. I don't expect say Dell or HP to cover my PC if I try to install ubuntu and I botch something up.
However, refusing to let me have root because "might" mess something up is also flawed logic. I may also for one reason or another need root access.
While I am glad they make it easy to root, the reality is there is they are being counter productive. Honestly, just leaving in root access would decrease the chances of me bricking my device at this point. As of now to get root access I'll have to flash a custom recovery compared to just giving the ability to go into a terminal and type in "oem -su enable" or something.
If the flashing issue is really that big of a deal, then why force users to flash to get what they want in the first place?
Snow_fox said:
I don't expect a company to support me changing anything I want about it. If I misuse root privileges, then I don't expect to have a lifeline when I call asus/google. I don't expect say Dell or HP to cover my PC if I try to install ubuntu and I botch something up.
However, refusing to let me have root because "might" mess something up is also flawed logic. I may also for one reason or another need root access.
While I am glad they make it easy to root, the reality is there is they are being counter productive. Honestly, just leaving in root access would decrease the chances of me bricking my device at this point. As of now to get root access I'll have to flash a custom recovery compared to just giving the ability to go into a terminal and type in "oem -su enable" or something.
If the flashing issue is really that big of a deal, then why force users to flash to get what they want in the first place?
Click to expand...
Click to collapse
Root can cause problems. It can cause security problems if not used right and can brick not only while rooting but while flashing custom roms and things.
while you and I don't go asking for support, a lot of people do. People try to pass things off as warrenty problems and do call and email asking for support for things not originally on that phone.
And it hurts them in other ways. Google makes pretty much all their money from ads. Rooting makes it easy to block ads and you average rom might have it built right in. The only reason google bothers with android was for the ad money. So there is no incentive for them give root out of the box. They already are more open and free than their main competitions.
You could look at samsung. THey make their money of the hardware and so have been more open with rooting with odin, thought they still don't really care for it (probably because of the support issue)
And the carriers are even worse because rooting allows for things like wireless tethering for free and data is their biggest costs. Their certnaly isn't any reason for carriers to push for root.
I honestly don't know the true answer; only Google would know.
But in my opinion, it's because Android is an open source OS, and giving users root access allows them to alter .apk's very easily. This is bad for developers, because most developers make money from advertisements or in-app currency, and allowing users to alter their .apk to easily block ads or change in-app currency would thwart developer interest.
In Windows for example, the OS is not open source, but users have "root" access because they can always get to the root of every program/file. BUT users CANNOT EASILY alter the programs installed on Windows - if they want a hacked version, they usually have to download a hacked version that someone else hacked.
Whereas in Android, it's very easy for me to download any .apk I want, run my hack app that says "Search for this value and change it to this" and BAM it's now hacked in literally seconds.
firesoul453 said:
Root can cause problems. It can cause security problems if not used right and can brick not only while rooting but while flashing custom roms and things.
while you and I don't go asking for support, a lot of people do. People try to pass things off as warrenty problems and do call and email asking for support for things not originally on that phone.
And it hurts them in other ways. Google makes pretty much all their money from ads. Rooting makes it easy to block ads and you average rom might have it built right in. The only reason google bothers with android was for the ad money. So there is no incentive for them give root out of the box. They already are more open and free than their main competitions.
You could look at samsung. THey make their money of the hardware and so have been more open with rooting with odin, thought they still don't really care for it (probably because of the support issue)
And the carriers are even worse because rooting allows for things like wireless tethering for free and data is their biggest costs. Their certnaly isn't any reason for carriers to push for root.
Click to expand...
Click to collapse
I'm not going to deny adblocking is one of my many vices. While many people have many views on it, all I can say is until ads no longer break my experience completely, I'll be stuck using adblockers. While this is becoming less of a problem with phones/tablets that have faster processors I've had my entire phone lock up before because of certain types of ads my phone couldn't handle. On top of that many are frustrating to deal with as there is no "x" visible for me to tap and I have to back out of whatever I was doing because the phone can't handle the discrepancy in size and find some way to navigate around the ad.
While this is only one example there have been other issues. Hell I had to use a script that required root back when I had my captivate just to get it it to work on my schools wifi. There were a number of issues and I imagine there are still a number of issues that make the lack of root almost a deal breaker.
Sure you can argue from a support issue point of view but, realistically as I already said, I wouldn't have to flash anything if I had access to root... I guess they just chalk it up to "some people are going to do whatever it takes anyway...." but, that just doesn't make much sense to not let people have it anyway.
Geodude074 said:
I honestly don't know the true answer; only Google would know.
But in my opinion, it's because Android is an open source OS, and giving users root access allows them to alter .apk's very easily. This is bad for developers, because most developers make money from advertisements or in-app currency, and allowing users to alter their .apk to easily block ads or change in-app currency would thwart developer interest.
In Windows for example, the OS is not open source, but users have "root" access because they can always get to the root of every program/file. BUT users CANNOT EASILY alter the programs installed on Windows - if they want a hacked version, they usually have to download a hacked version that someone else hacked.
Whereas in Android, it's very easy for me to download any .apk I want, run my hack app that says "Search for this value and change it to this" and BAM it's now hacked in literally seconds.
Click to expand...
Click to collapse
This is actually one of the best reasons I think I've ever heard and I've actually asked this question a lot in different places over the years. That's a pretty feasible answer.
Geodude074 said:
I honestly don't know the true answer; only Google would know.
But in my opinion, it's because Android is an open source OS, and giving users root access allows them to alter .apk's very easily. This is bad for developers, because most developers make money from advertisements or in-app currency, and allowing users to alter their .apk to easily block ads or change in-app currency would thwart developer interest.
In Windows for example, the OS is not open source, but users have "root" access because they can always get to the root of every program/file. BUT users CANNOT EASILY alter the programs installed on Windows - if they want a hacked version, they usually have to download a hacked version that someone else hacked.
Whereas in Android, it's very easy for me to download any .apk I want, run my hack app that says "Search for this value and change it to this" and BAM it's now hacked in literally seconds.
Click to expand...
Click to collapse
Rooting has nothing to do with decompiling apks. apk hacking is bad but thats a whole other thing. Anyone can get a hold of pretty much every apk easliy, no need for root.
Windows doesn't really have root, its pretty different. You can give programs administrator privileges I guess, but not exactly the same. Decompiling apks is only easier because its java, it has nothing to do with the os or root privileges.
Don't expect any of these companies support to support root until they have a reason to.