Running Homebrew Native Executables - Status: DONE!!

Search This thread

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
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.
 

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
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...
 
Last edited:

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
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.
 

Attachments

  • HtcUtility.c
    22 KB · Views: 56
Last edited:

Heathcliff74

Inactive Recognized Developer
Dec 1, 2010
1,646
2,610
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 :D

Ciao,
Heathcliff74
 

snickler

Retired Forum Mod / Inactive Recognized Developer
Aug 17, 2010
1,320
1,133
Dub V
www.sinclairinat0r.com
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 :D

Ciao,
Heathcliff74


You guys are brilliant!
 
  • Like
Reactions: contable

GoodDayToDie

Inactive Recognized Developer
Jan 20, 2011
6,066
2,933
Seattle
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...
 

Jaxbot

Inactive Recognized Developer
Mar 14, 2009
1,224
548
windowsphonehacker.com
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 :D

Ciao,
Heathcliff74

Fascinating... this could really make life a lot easier :p
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?
 

Heathcliff74

Inactive Recognized Developer
Dec 1, 2010
1,646
2,610
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.

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.

Great!

I won't tell to anyone :D

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

Fascinating... this could really make life a lot easier :p
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
 
  • Like
Reactions: kurdland

BigJeff

Senior Member
Jun 4, 2011
836
178
Stanwood
YESSSS this is what I've been hoping for! Root Tools 1.0 come on baby! Devs start cooking up some sweet homebrew apps :) Will this allow for other browsers and things of those nature? Or like a full file browser/downloader? Man I'm excited for these great things to come :D GO HEATHCLIFF AND COTULLA!!!
 

Nickg.

Senior Member
Jan 5, 2010
190
106
Congratulation! This is very great thing, now the gap from custom Rom is almost null!

The possibilty to install other driver will allow several new hack
 

sensboston

Recognized Developer
Nov 18, 2009
2,165
814
Boston, MA
does this mean windows phone has finally been jailbroken?

No, it doesn't. It only means: some "hackable" handsets (supported by Root Tools) will have ability to run native WinCE executables. But of course not all: there are a lot of other restrictions like a missing GUI libraries, missing API etc. and so on. Don't expect to have any WinMo app running on your policy-unlocked phone.
 
  • Like
Reactions: kirk999

Heathcliff74

Inactive Recognized Developer
Dec 1, 2010
1,646
2,610
does this mean windows phone has finally been jailbroken?

Ehhhm. Many WP7 devices have been jailbroken. The RTM version of WP7 was jailbroken by the ChevronWP7 team. Back then, with that unlock, almost anything was possible.

But WP7 is not the same as iOS or Android. Android can be unlocked by changing the available source code and recompile it. With iPhones, there is only one OEM: Apple. That, and the fact that Apple doesn't know how to protect their OS, makes it a lot easier to hack it.

WP7 is very well protected by Microsoft and the OEM's. Exploits need to be found in the bootloader, Microsoft code or OEM code. Most WP7 devices have been hacked one way or the other. But in most cases, the vulnerabilities have been fixed in the most recent versions by MSFT and the OEM's. And everytime an vulnerability is fixed we need to find new exploits. So generally, you should not update your phone unless you really need to.

This new unlock will not unlock devices that previously could not be unlocked. This only brings more possibilities to devices that could already be Policy Unlocked before.

This will allow personalization as a new hack?

You can customize your WP7 device to some degree. There are homebrew tools for that. This new unlock does not really give more possibikities for customization.

The main reason I've been working on this, is that I want to have a good understanding of the pokicy system in WP7 and this unlock allows all types of background tasks and services, like native debugging, improved remote filesystem and registry access, etc.

Currently I'm working on 3 projects:
- New features for WP7 Root Tools.
- Unlock new HTC's and NOKIA's (no ETA!!!)
- Policy Unlock for Homebrew Executables (this project)

Ciao,
Heathcliff74
 

huismeester

Senior Member
May 3, 2008
3,006
650
Samsung Galaxy S9
Ehhhm. Many WP7 devices have been jailbroken. The RTM version of WP7 was jailbroken by the ChevronWP7 team. Back then, with that unlock, almost anything was possible.

But WP7 is not the same as iOS or Android. Android can be unlocked by changing the available source code and recompile it. With iPhones, there is only one OEM: Apple. That, and the fact that Apple doesn't know how to protect their OS, makes it a lot easier to hack it.

WP7 is very well protected by Microsoft and the OEM's. Exploits need to be found in the bootloader, Microsoft code or OEM code. Most WP7 devices have been hacked one way or the other. But in most cases, the vulnerabilities have been fixed in the most recent versions by MSFT and the OEM's. And everytime an vulnerability is fixed we need to find new exploits. So generally, you should not update your phone unless you really need to.

This new unlock will not unlock devices that previously could not be unlocked. This only brings more possibilities to devices that could already be Policy Unlocked before.



You can customize your WP7 device to some degree. There are homebrew tools for that. This new unlock does not really give more possibikities for customization.

The main reason I've been working on this, is that I want to have a good understanding of the pokicy system in WP7 and this unlock allows all types of background tasks and services, like native debugging, improved remote filesystem and registry access, etc.

Currently I'm working on 3 projects:
- New features for WP7 Root Tools.
- Unlock new HTC's and NOKIA's (no ETA!!!)
- Policy Unlock for Homebrew Executables (this project)

Ciao,
Heathcliff74

Hi heatcliff i hope so for the lumia 900 my fingers are crost :D
 

IzaacJ

Inactive Recognized Developer
Sep 2, 2008
688
91
34
Eskilstuna
izaacj.github.io
Ehhhm. Many WP7 devices have been jailbroken. The RTM version of WP7 was jailbroken by the ChevronWP7 team. Back then, with that unlock, almost anything was possible.

But WP7 is not the same as iOS or Android. Android can be unlocked by changing the available source code and recompile it. With iPhones, there is only one OEM: Apple. That, and the fact that Apple doesn't know how to protect their OS, makes it a lot easier to hack it.

WP7 is very well protected by Microsoft and the OEM's. Exploits need to be found in the bootloader, Microsoft code or OEM code. Most WP7 devices have been hacked one way or the other. But in most cases, the vulnerabilities have been fixed in the most recent versions by MSFT and the OEM's. And everytime an vulnerability is fixed we need to find new exploits. So generally, you should not update your phone unless you really need to.

This new unlock will not unlock devices that previously could not be unlocked. This only brings more possibilities to devices that could already be Policy Unlocked before.



You can customize your WP7 device to some degree. There are homebrew tools for that. This new unlock does not really give more possibikities for customization.

The main reason I've been working on this, is that I want to have a good understanding of the pokicy system in WP7 and this unlock allows all types of background tasks and services, like native debugging, improved remote filesystem and registry access, etc.

Currently I'm working on 3 projects:
- New features for WP7 Root Tools.
- Unlock new HTC's and NOKIA's (no ETA!!!)
- Policy Unlock for Homebrew Executables (this project)

Ciao,
Heathcliff74

This could prove very useful. The implemented background service is not as near as good as it could be, that due to the restrictions Microsoft has put in.
But will it be possible for an exe to create and update a Live tile more often than a regular XAP, so it could be possible to create a real clock tile with seconds and everything? :)

Regards
Izaac
 

Top Liked Posts

  • There are no posts matching your filters.
  • 25
    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 :D

    Ciao,
    Heathcliff74
    10
    [2012/06/03] IMPORTANT UPDATE HERE

    Hi hackers,

    This is meant as a little update on one of the projects I've been working on. I'm kinda stuck now. I have a suspicion of what the problem is. I thought that maybe if I write a post about it, me or someone else will have an idea on how to get this working.

    The goal is to run native homebrew executables on WP7

    This has not been done yet. All apps are Silverlight apps that are compiled as DLL and run by Taskhost.exe with least privileges. All other executables are signed by Microsoft. Executables that are compiled as ARM executable cannot be started.

    The angle is to create a certificate that allows to sign a WP7 executable. Then add that to the appropriate certificate store. Create an executable. Sign it with the private key. Load it onto a WP7 device. Copy it to the Windows folder. Use an OEM driver to launch the executable.

    First I did research on the certificate stores. I can now with certainty state that there are 4 certificate stores:
    - CA
    - Root
    - My
    - Code Integrity

    After a lot of research I finally got complete read/write access to all of these stores. The Code Integrity store contains all the certificates that are used by the Loader Verifier to verify the executable that is being launched. When the device is launched for the first time, the certificates that are in \Windows\ciroots.p7b are installed to that certificate store. These certificates have these properties:

    Key Usage = 0x86 = Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing
    Entended Key Usage = Code Signing (1.3.6.1.5.5.7.3.3) + Unknown key usage (1.3.6.1.4.1.311.10.3.14)

    So I used OpenSSL to create such an certificate (with private key) for myself. And I installed the certificate in the Code Integrity store.

    I then used VS2008 to create a completely barebone executable (ARMv4 Console app with only Sleep(-1) in the Main). I signed it with SignTool from Microsoft.

    I loaded the executable to my device and I copied it to the \Windows folder (I think the policies restrict executing to only from that folder, but I'm not sure about that).

    I use the Samsung driver to launch the executable, because I need at least Standard Rights to launch an executable. The Samsung driver has Elevated Rights. My own app has only Least Privileges. Using the Samsung driver does not return any success or fail codes. But looking at the Running Processes list, I don't see my Test.exe running. It should be, because the main thread is put to sleep infinitely.

    So why is this not working?

    Well, I have a guess. I think it's the policies that bind the certificates in the Code Integrity store to the different accounts/chambers. In the \Windows folder there are a lot of policy xml-files. On fist boot, these are merged into PolicyCommit.xml and then compiled to policydb.vol. When the Loader Verifier (lvmod.dll) loads an executable, it queries the policies to determine access rights and chamber for that executable. The policies that matter in this context are defined in 8314B832-8D03-444f-9A2A-1EF6FADCC3B8.policy.xml. It's an xml-file that basically says this:

    Code:
    Microsoft Mobile Device Privileged PCA       - ced778d7bb4cb41d26c40328cc9c0397926b4eea - not used in this context
    Microsoft Mobile Device TCB PCA              - 88bcaec267ef8b366c6e6215ac4028e7a1be2deb - honored by System Identity Group
    Microsoft Mobile Device Unprivileged PCA     - 1c8229f5c8d6e256bdcb427cc5521ec2f8ff011a - honored by Standard Right Identity Group
    Microsoft Mobile Device VSD PCA              - 91b318116f8897d2860733fdf757b93345373574 - not used in this context
    VeriSign Mobile Root Authority for Microsoft - 069dbcca9590d1b5ed7c73de65795348e58d4ae3 - honored by LPC Identity Group

    I should find a way to add a policy with my certificate in it. Any ideas? :eek:

    Ciao,
    Heathcliff74
    6
    Great!

    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 :D
    4
    **** so CLOSE!

    Successful copied "main.exe" and "ExeX.exe" to "\Windows", where i have the right to launch them remotely.

    Method:


    WP7Process p = device.LaunchEXE(@"main.exe", "");

    main.exe (no signing, ARMv7):
    System.UnauthorizedAccessException: Access is denied.


    WP7Process p = device.LaunchEXE(@"ExeX.exe", "");

    ExeX.exe (signed with CA/ROOT custom, ARMv4):
    System.Runtime.InteropServices.COMException (0x800704EC): This program is blocked by group policy. For more information, contact your system administrator.

    There IS different things going on! Something is missing, but what :p

    edit:

    Signed main.exe with custom XDA ROOT certificate (ARMv7):
    signtool.exe sign /sha1 "[CertChomp]" "main.exe"
    > Now main.exe also gets "This program is blocked by group policy. For more information, contact your system administrator."
    Ill see if i can add it to startup list , if it boot from there.

    edit 2:
    Nope gonna hijack "fieldtestapp.exe" with my app because policy says:

    Risky-mode.Activate();

    Backup(fieldtestapp.exe, backupPath);
    Copy(main.exe, > fieldtestapp.exe);


    "LOADERVERIFIER_ROUTE_BY_NAME"
    "LOADERVERIFIER_EXE_AUTHZ_INROM_ROOT"

    <Rule Description="Route fieldtestapp.exe" ResourceIri="$(LOADERVERIFIER_ROUTE_BY_NAME)/PRIMARY/WINDOWS/FIELDTESTAPP.EXE" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_LOW">
    <Authorize>
    <Match AccountId="$(FIELDTESTAPP_EXE_SID)" AuthorizationIds="LV_ACCESS_EXECUTE" />
    </Authorize>
    </Rule>

    <Rule Description="Authorize fieldtestapp.exe be loadable to $(FIELDTESTAPP_EXE_SID) and chambers" ResourceIri="$(LOADERVERIFIER_EXE_AUTHZ_INROM_ROOT)/WINDOWS/FIELDTESTAPP.EXE" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
    <Authorize>
    <Match AccountId="$(FIELDTESTAPP_EXE_SID)" AuthorizationIds="LV_ACCESS_EXECUTE,LV_ACCESS_LOAD" />
    </Authorize>
    </Rule>


    edit 3:
    Seems like "fieldtestapp.exe" is ROM locked. Need to try out some other targets.

    edit 4:
    Target acquired "ProximitySensorDisable.exe" > "ProximitySensorDisableBackup.exe"
    Successful copy == no ROM lock.

    edit 5:
    There exists two types of talking to the LoadVerifier (the: This program is blocked by group policy.):

    Direct exe name OR special certificate
    How we do:
    > Direct exe (hijack exe)

    How we cant do (SHA1) (Nope, ain't gonna happen):
    > We certainly dont have Microsofts certificate so this way is a nodo, haha lol, no do way.

    (1: direct exe name) /LOADERVERIFIER/GLOBAL/AUTHORIZATION/PE_AUTHZ/NONE/NONE/PRIMARY/WINDOWS/CFGHOST.EXE
    (2: static/pre certificates) /LOADERVERIFIER/GLOBAL/CERTIFICATES/HASH/SHA1/91B318116F8897D2860733FDF757B93345373574

    edit 6:
    Yep, loads of edits, just for you.

    Allowed exe's to run (sorted a-z) (direct exe) (pre cert removed):
    Code:
    ACCESSIBILITYCPL.EXE
    ACCOUNTSMANAGER.EXE
    ALARMS.EXE
    APPCHECKERSHIM.EXE
    APPPREINSTALLER.EXE
    AUTODATACONFIG.EXE
    AUTOSIM.EXE
    AUTOTIMEUPDATE.EXE
    BRIGHTNESSCPL.EXE
    BTUXCPL.EXE
    CALENDARAPP.EXE
    CALLSETTINGSHOST.EXE
    CALNOT.EXE
    CALUPD.EXE
    CAM_FW_UPDATE_UI.EXE
    CELLUXCPL.EXE
    CERTINSTALLER.EXE
    CFGHOST.EXE
    CFLAUNCHER.EXE
    CHDIALERHOST.EXE
    CIPHASE2.EXE
    CLIENTSHUTDOWN3.EXE
    CLOCKNOT.EXE
    CMACCEPT3.EXE
    COLDINIT.EXE
    COMMSVC.EXE
    COMPOSITOR.EXE
    CONFIGDM.EXE
    CONFIGXML.EXE
    CONMANCLIENT3.EXE
    CONTACTS.EXE
    CPROG.EXE
    DATETIMECPL.EXE
    DCVSSWITCH.EXE
    DEPOTCOPY.EXE
    DEVICEFEEDBACKCPL.EXE
    DEVICEREG.EXE
    DIAGPORTCHANGETEST.EXE
    DLLHOST.EXE
    DMSCHEDULERCALLBACK.EXE
    DMSRV.EXE
    DMSTOOLS.EXE
    DUACLIENT.EXE
    DW.EXE
    EDM3.EXE
    EMAIL.EXE
    EMAILSETUP.EXE
    ENDPOINT.EXE
    FCROUTERCMDTEST.EXE
    FIELDTESTAPP.EXE
    FLIGHTMODE.EXE
    GAMESUX.EXE
    IEXPLORE.EXE
    INITIATEDMSESSION.EXE
    INVALIDLICENSEUXLAUNCHER.EXE
    KEYBOARDCPL.EXE
    LASSCREDENTIALEXPIRATIONCHECK.EXE
    LASSRESTARTER.EXE
    LIVETOKEN.EXE
    LOCKCPL.EXE
    LOOPBACKTEST.EXE
    MEDIAGROVEL.EXE
    MEUX.EXE
    MITSMAN.EXE
    MMSPRPROXY.EXE
    MMSTRANSHOST.EXE
    MULTIMEDIALAUNCHER.EXE
    MYPHONECPL.EXE
    MYPHONETASKSRUNTIME.EXE
    NATIVEINSTALLERHOST.EXE
    OFFICEURL.EXE
    OMADMCLIENT.EXE
    OMADMPRC.EXE
    OMHUB.EXE
    ONBOOTSQM.EXE
    ONENOTEMOBILE.EXE
    OOBE.EXE
    PACMANINSTALLER.EXE
    PHOTOENT.EXE
    PHOTOENTCAPTURE.EXE
    PHOTOUPLOADER.EXE
    PPT.EXE
    PWORD.EXE
    PWRLOGCTRL.EXE
    PXL.EXE
    RAPICONFIG.EXE
    REGIONCPL.EXE
    RMACTIVATE.EXE
    SAPISVR.EXE
    SECSIMTKIT.EXE
    SERVICESD.EXE
    SERVICESSTART.EXE
    SETTELEPORTMODE.EXE
    SETTINGS3.EXE
    SHORTMSG.EXE
    SICLNT.EXE
    SIGNALEVENT.EXE
    SIREPSERVERAPPDEV.EXE
    SMSETTINGS.EXE
    SMSTRANSPORT.EXE
    SOUNDCPL.EXE
    SPEECHCPL.EXE
    SPMC.EXE
    SQMEVENT.EXE
    SSUPDATE.EXE
    TASKHOST.EXE
    TELSHELL.EXE
    TESTSHOW.EXE
    THEMECPL.EXE
    TOGGLEBROWSERHIBERNATION.EXE
    TOGGLEDOG.EXE
    UDEVICE.EXE
    UIF.EXE
    UNIFIEDPAIR.EXE
    USBMGR.EXE
    WEBSEARCH.EXE
    WIFIUXSPLASH.EXE
    WLANEXT.EXE
    WLIDSETUP.EXE
    WWANDATAMGR.EXE
    XDRMREMOTESERV.EXE
    ZIPVIEW.EXE
    ZMFTASKLAUNCH.EXE

    How code (yes i know its super un-optimized, fast put together):
    Code:
    var doc = XDocument.Load(File.OpenRead("SamsungOmnia7_BasePolicy_webserver.xml"));
    var ea = doc.Elements().ToArray()[0].Elements()
        .Where(x => x.Name.LocalName == "Rule")
        .Where(x => x.Attributes("ResourceIri").Count() > 0)
        .Where(x =>
        {
            var r = x.Attribute("ResourceIri").Value;
            return r.Contains("LOADERVERIFIER") && r.ToLower().Contains(".exe") && !r.Contains("CERTIFICATES");
        })
        .Select(x =>
        {
            var v = x.Attribute("ResourceIri").Value;
    
            var l = v.LastIndexOf('/');
    
            return v.Substring(l + 1);
        })
        .Distinct()
        .OrderBy(x => x)
        .ToArray();

    edit 7:
    yeah, lol i say too.
    Unprotected exe (FCRouterCmdTest.exe)
    > c:\Project Work\SGH-i707(Cetus)\FCRouterCmdTest\Windows Mobile 6 Professional SDK (ARMV4I)\Release\FCRouterCmdTest.pdb
    mfw samsung use "Windows Mobile 6 Professional SDK (ARMV4I)"
    3
    FINALLY!!

    STATUS: DONE! :D

    www.wp7roottools.com

    Ciao,
    Heathcliff74