FORUMS
Remove All Ads from XDA

Running Homebrew Native Executables - Status: DONE!!

1,605 posts
Thanks Meter: 2,473
 
By Heathcliff74, Inactive Recognized Developer on 6th June 2011, 08:16 PM
Post Reply Email Thread
2nd February 2012, 04:42 PM |#101  
Inactive Recognized Developer
Flag Seattle
Thanks Meter: 2,921
 
More
A new approach
[Minor Necropost GO!]
OK, I decided to try attacking this problem from another angle.

Using the HtcUtility driver (HtcRoot project), I can elevate a process to SYSTEM. This essentially eliminates Error 1260 for that process, in my testing so far.

I can call CreateProcess() just fine, so that's my eqivalent of the Samsung driver function discussed earlier. On built-in apps, it works fine (Calc7, Settings3, etc.).

I created a self-signed certificate with the requisite characteristics using MakeCert (comes with the MS SDK, you can get to it easily using the Visual Studio Command Prompt). The command I used:
D:\Programming\Phone\Win32ExeTest>makecert -r -n "CN=GoodDayToDie" -pe -sky 0x86 -eku 1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.14 -sv GoodDayToDie.pvk GoodDayToDie.cer

I used this key and certificate to create a PFX file (private key + cert):
D:\Programming\Phone\Win32ExeTest>pvk2pfx -pvk GoodDayToDie.pvk -spc GoodDayToDie.cer -pfx GoodDayToDie.pfx

I used the PFX file to sign a very simple native EXE (Win32, not even ATL, does nothing but return a specific error code):
D:\Programming\Phone\Win32ExeTest>signtool sign /v /f GoodDayToDie.pfx Win32ExeTest.exe"

I used the HtcRoot Webserver to upload my signed executable and my certificate to \Windows (probably can put them anywhere, but KISS).

I used the Crypto API to install my cert. I'm not sure if I had to install it to both LOCAL_MACHINE and CURRENT_USER or only CURRENT_USER, but the error code for launching my homebrew EXE didn't change when I tried installing it to LOCAL_MACHINE only. This was a surprise. In retrospect, I could probably have just used registry access.

OK, at this point, here's what goes down:
Start my Silverlight ID_CAP_INTEROPSERVICES test app (custom build of HtcUtilityTest).
App uses HtcRoot project to elevate itself to SYSTEM.
App calls CreateProcess(L"\\Windows\\Win32ExeTest.exe", NULL, NULL, FALSE, 0x0, NULL, NULL, NULL, &psinfo) where psinfo is a PROCESS_INFORMATION struct.
CreateProcess fails, error code from GetLastError() is 1168.
COM function returns this error using return HRESULT_FROM_WIN32(GetLastError()).
Managed code interprets this as an InteropServices.COMException with the error code 0x80070490 and the message "Element not found".

OK, that's a message I haven't seen before (it's not in the MSDN CE7 list of error codes, either). It's probably because my binary isn't in the policy list. Now... how to get it there?

I can call PolicyLoader, but I'm not sure it would do any good if it doesn't have permissions (which seems to be the consesnus of this thread).
I can call PolicyLoader but specify the flag CREATE_SUSPENDED. That way I can use the HtcRoot project to elevate the process to SYSTEM, then "resume" it to let it run.
I can try tweaking the database directly.

However, I'm not sure any of these will work in a simple fashion, because the database files appear to be held exclusively by another process. Using the HtcRoot webserver to try and download one gives the following error:
CreateFile failed for /Windows/Security/accountdb.vol! GetLastError: 32
which is ERROR_SHARING_VIOLATION "The process cannot access the file because it is being used by another process."

OK, *somehow* Heathcliff74 has managed to modify his phone's policies, so I know it's possible. I'm pretty sure he can't have more access to his device than I have to mine, though the mechanism may be very different. Time to figure out how I can do this...

Modify the handle that is open on that file to allow shared access (probably possible with HtcUtility, but could damage things)?
Modify the memory of the process engine itself, either temporrily or such that it gets flushed back to the file (also probably possible, almost certainly a lot harder though)?
Fake an update, or else somehow load my own policy at a time where the database is unlocked (maybe I should look for the programs that are called while the phone is upgrading, see if I can fake out one of them to process a fake "update")?
Use HtcUtility and/or debug APIs to modify the behavior of the policy engine while it's running (lvmod.dll is a ROM Module, though, so maybe something else)?
Modify the policy XML files in \Windows\Security, and hope those changes at some point get merged back into the database?
Do something else that I haven't thought of yet (maybe somebody else has an idea)?


For what it's worth, here's my goal:
Create a persistent "root" app on the phone, one which is not dependent upon any driver DLL that may get patched (including HtcUtility) nor upon interop-unlock (obviously, if you're not already IUed, you'll need to roll back to NoDo to install this, but it would work for the HTC Arrive).
This root app would enable most if not all the advantages of a "fully unlocked" custom ROM. It would re-enable homebrew access that was lost in the recent updates, and keep working in the face of future updates. It would be able to patch itself, so that if it was ever blocked by an update the access could be restored without anything more painful that rolling back the update immediately after installing it (no data loss, no pain).

Obviously, I'd like to make this possible for all phones. For first-gen HTC, I can use HtcUtility via the current version of the HtcRoot project as a springboard to install this persistent app. For first-gen Samsung, Heathcliff74 probably could make this work for you too. For LG (first-gen, at least, don't know about later), Heathcliff74's Root Tools may enable this for you too. For second-gen phones, we'd need to find a springboard exploit to get the high permissions (ideally TCB/SYSTEM) needed for installing, but we'll keep looking. For other phones, the same applies (and there's still hope - go read this thread again, and you'll see that a few months ago we didn't think native code, even using COM, was possible on Mango at all).

So please, let's work together on this.
The Following 2 Users Say Thank You to GoodDayToDie For This Useful Post: [ View ] Gift GoodDayToDie Ad-Free
 
 
3rd February 2012, 09:16 AM |#102  
Inactive Recognized Developer
Flag Seattle
Thanks Meter: 2,921
 
More
OK, minor update to the above:

The policy database (\Windows\Security\policydb.vol) is held open with an exclusive lock, as expected. However, this doesn't prevent accessing it with the CE DB functions (permissions permitting of course, which for me they do).

A few catches, though:
* The file is just a database *volume* - the actual database (the thing you call an OpenDatabase function on) is inside it. The volume in question has three of them (DBTRANSACTIONTABLE | PatternDBBloomFilter | PatternDBmultimap).
* The database appears to be a CEDB (legacy), not the modern EDB. At least, if I try and get the volume's GUID (mount the database) using OPEN_EXISTING with the legacy function, it works. If I try to use the EDB variant, or also pass the flag that makes the legacy one work like the EDB variant, I get 0x80070020 (HRESULT for ERROR_SHARING_VIOLATION).
* Since it's a legacy database, make sure you use the legacy functionality. Many of the new functions actually appear to work, if you pass the legacy version flags. If you use the version flag that it tells you to use (2 instead of 1) then you'll get ERROR_INVALID_PARAMETER. It's probably best, though, to just not define EDB and live with the warning for using a deprecated function.
* If you do want to use the EDB functions, don't just try including <windbase_edb.h>. This made the linker fail. If you define EDB and then include <windbase.h> you'll get <windbase_edb.h> as well, automatically.

EDIT: It gets better. The CEDB docs are somewhere between incomplete and wrong (they will occasionally either fail to specify critical operations, or imply that you should do something which you actually shouldn't)! The EDB docs are much more accurate, and have a "Remaks" section that contains essentially a changelog from CEDB - reverse it and apply those changes to your CEDB calls. Finally, if you define EDB, you may get results which are quite simply wrong even if the function appears to work. Just put up with the warnings (or suppress them) and don't define EDB - you'll save yourself some hassle.

I'll share the source code (it'll be a new version of the native code for the HtcRoot native code) soon, once I've learned a bit more and cleaned up some debug stuff. I really should refactor that out into its own class, but that would actually take time...
3rd February 2012, 09:47 PM |#103  
Inactive Recognized Developer
Flag Seattle
Thanks Meter: 2,921
 
More
Ugh, the policy database records are pretty opaque.
There are ~3000 of them (3262 on my phone).
Each one, so far as I've seen yet, has 4 properties, and a size between 100 and 400 bytes.
The first property is a filetime (or possibly just a longlong, there only 8-byte primitive type directly supported is Double). It's value is typically in excess of 0x8000000000000000, and the value of each byte is all over the place. Maybe it really is a filetime? Haven't tried converting it yet.
The second property is a binary blob. It's typically 64-320 bytes in length (pretty variable, though). No idea what's in it.
The third property is also a binary blob, but usually shorter (40-80 bytes).
The fourth property is anothr filetime. This one might be a special value, though; the high-order DWORD seems to always be at least 0xFFFFFF00.

I doubt I'll be able to interpret these unassisted. Time to go examine the way the policy engine works...

I've attached some source to this. It's a mess because currently it's basically just a bunch of tests strung together - I'll organize it out and put it behind proper COM APIs later. Also, apparently the longest part of running the test is marshalling a 2048-byte string into managed code (which seems odd; I've have expected that to be mostly just memory copy operations - it should be much less than a million clock cycles for the CPU, so it should take less than a milisecond - but it'll actually make my phone stutter music playback for a second or so!)

Oh FFS xda, you'll accept a .C or .H file but not a .CPP?!? Be that way...
The relevant code is in TestDatabase (), a helper function near the bottom.
Attached Files
File Type: c HtcUtility.c - [Click for QR Code] (22.0 KB, 54 views)
3rd June 2012, 02:12 AM |#104  
Heathcliff74's Avatar
OP Inactive Recognized Developer
Thanks Meter: 2,473
 
Donate to Me
More
Talking Breakthrough!
Today I will change the topic title from "Status: Not possible >YET<" to "Status: Possible!".

On Custom ROMs with Full Unlock it was already possible to run homebrew executables. For stock ROMs with Interop Unlock there is WP7 Root Tools which allows Policy Unlock for Silverlight applications. But running homebrew executables like Opera Mini was still not possible.

But now I've found a way to unlock homebrew executables using policies and certificates. I need to do more research before I can implement this unlock in WP7 Root Tools, because the unlock currently still needs some manual actions. But I know it's possible now, because I have it working.

I will keep you updated on the progress for implementing this in WP7 Root Tools.

I have to thank Cotulla for helping me find a stupid mistake I made! His incredible knowledge helped me see why I thought it was not working yet

Ciao,
Heathcliff74
The Following 25 Users Say Thank You to Heathcliff74 For This Useful Post: [ View ] Gift Heathcliff74 Ad-Free
3rd June 2012, 05:34 AM |#105  
snickler's Avatar
Forum Moderator / Recognized Developer
Flag Dub V
Thanks Meter: 1,122
 
Donate to Me
More
Quote:
Originally Posted by Heathcliff74

Today I will change the topic title from "Status: Not possible >YET<" to "Status: Possible!".

On Custom ROMs with Full Unlock it was already possible to run homebrew executables. For stock ROMs with Interop Unlock there is WP7 Root Tools which allows Policy Unlock for Silverlight applications. But running homebrew executables like Opera Mini was still not possible.

But now I've found a way to unlock homebrew executables using policies and certificates. I need to do more research before I can implement this unlock in WP7 Root Tools, because the unlock currently still needs some manual actions. But I know it's possible now, because I have it working.

I will keep you updated on the progress for implementing this in WP7 Root Tools.

I have to thank Cotulla for helping me find a stupid mistake I made! His incredible knowledge helped me see why I thought it was not working yet

Ciao,
Heathcliff74


You guys are brilliant!
The Following User Says Thank You to snickler For This Useful Post: [ View ]
3rd June 2012, 10:51 AM |#106  
Inactive Recognized Developer
Flag Seattle
Thanks Meter: 2,921
 
More
Oooh, gotta admit, I'm curious. I've been working on this as well, and haven't gotten it yet - even for built-in apps lifted from the ROM and then written back over the ROM file, whether or not I signed them with a cert I had added to my phone.

That said, well done!! Acknowledging your desire to tool-ify this within Root Tools, any info you can share that may let us begin building things using this would be great...
3rd June 2012, 02:45 PM |#107  
sensboston's Avatar
Recognized Developer
Flag Boston, MA
Thanks Meter: 750
 
Donate to Me
More
Great! Looking forward for release. And "yes", Cotulla is a great guy with a really good knowledge
3rd June 2012, 02:50 PM |#108  
Cotulla's Avatar
Retired Senior Recognized Developer
Thanks Meter: 5,472
 
More
Great!

Quote:

I have to thank Cotulla for helping me find a stupid mistake I made! His incredible knowledge helped me see why I thought it was not working yet

I won't tell to anyone
The Following 6 Users Say Thank You to Cotulla For This Useful Post: [ View ] Gift Cotulla Ad-Free
3rd June 2012, 02:59 PM |#109  
Inactive Recognized Developer
Thanks Meter: 548
 
Donate to Me
More
Quote:
Originally Posted by Heathcliff74

Today I will change the topic title from "Status: Not possible >YET<" to "Status: Possible!".

On Custom ROMs with Full Unlock it was already possible to run homebrew executables. For stock ROMs with Interop Unlock there is WP7 Root Tools which allows Policy Unlock for Silverlight applications. But running homebrew executables like Opera Mini was still not possible.

But now I've found a way to unlock homebrew executables using policies and certificates. I need to do more research before I can implement this unlock in WP7 Root Tools, because the unlock currently still needs some manual actions. But I know it's possible now, because I have it working.

I will keep you updated on the progress for implementing this in WP7 Root Tools.

I have to thank Cotulla for helping me find a stupid mistake I made! His incredible knowledge helped me see why I thought it was not working yet

Ciao,
Heathcliff74

Fascinating... this could really make life a lot easier
I'll keep tabs on this; it's unfortunate that all the exciting stuff happens while I'm on my forced work absences. That being said, good job!
How exactly does this work, though? Could this allow us to run unsigned DLLs, too, as drivers? Or just execute EXEs?
3rd June 2012, 08:00 PM |#110  
Heathcliff74's Avatar
OP Inactive Recognized Developer
Thanks Meter: 2,473
 
Donate to Me
More
Quote:
Originally Posted by GoodDayToDie

Oooh, gotta admit, I'm curious. I've been working on this as well, and haven't gotten it yet - even for built-in apps lifted from the ROM and then written back over the ROM file, whether or not I signed them with a cert I had added to my phone.

That said, well done!! Acknowledging your desire to tool-ify this within Root Tools, any info you can share that may let us begin building things using this would be great...

I'm still testing a few things. I'm not sure yet how I want to implement this. I'm thinking of simply unlocking all unsigned native executables at once, but I'm not sure that will work yet. If not, I can also add a "Mark trusted" context item for executables in the file-explorer, and executables in an application-install-folder can be unlocked when marking the app as trusted.

Quote:
Originally Posted by sensboston

Great! Looking forward for release. And "yes", Cotulla is a great guy with a really good knowledge

It was really stupid. I had it already working, but I didn't see it. The reason that I didn't see it was that I accidentally replaced my test.exe with another test.exe which only had Sleep(-1) in it, LOL! I had about 20 test.exe's floating around, so I cleaned that up a bit. But before we found out about the mistake I made we were going through kernel logs etc. But we couldn't find what was going wrong... because it was already working.

Quote:
Originally Posted by Cotulla

Great!

I won't tell to anyone

Oh. No problem, haha. Even I make mistakes sometimes The positive thing about that for me was that I learned some new things from you

Quote:
Originally Posted by Jaxbot

Fascinating... this could really make life a lot easier
I'll keep tabs on this; it's unfortunate that all the exciting stuff happens while I'm on my forced work absences. That being said, good job!
How exactly does this work, though? Could this allow us to run unsigned DLLs, too, as drivers? Or just execute EXEs?

You could already install new drivers if you call the right api's. The problem is that you could only let them run in Elevated Rights Chamber. Not in TCB. Because there is a hard-coded rule in the policy engine that every binary that is loaded into TCB must be properly signed. But I already had an exploit for that, because I'm already letting Homebrew Silverlight apps run in TCB with the current version of WP7 Root Tools. I could apply the same hack for drivers. But if you really just want to run a background "service", I think the easiest thing is just to run an executable at startup. You can add a shortcut to the executable in \Windows\Startup and you're done. With the next version of WP7 Root Tools that should be possible.

Ciao,
Heathcliff74
The Following User Says Thank You to Heathcliff74 For This Useful Post: [ View ] Gift Heathcliff74 Ad-Free
3rd June 2012, 09:09 PM |#111  
huismeester's Avatar
Senior Member
Thanks Meter: 625
 
More
Good work Heatcliff74 and yes Cotulla is a master
Post Reply Subscribe to Thread

Tags
executable, homebrew, mango, native, wp7

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes