yashsingh1/xdaforums huggingface dataset:
[Windows Phone 7 Development and Hacking] Heathcliff74:
@fiinix,

You did a lot of testing. Good job, man.

A few comments:

0x800704ec "blocked by group policy" is THE error of the new WP7 security model. It is basically telling you to go f*ck yourself. Everything you do without enough privileges or capabilities results in this error.

The two ways of policies, exe-path and cert-hash, is result of difference between rom-modules and executables that are signed and added as a file. Rom-modules are not even normal files. You can't open and read them. They are executable sections that are mapped in rom-address-space. You can only call loadlibrary() and createprocess() on them. Since they are only executable sections, they don't have a signature, like a normal executable file would have. Therefore they are referred to with an exe-path. You may safely assume that every path to an executable in the policy files is referring to a rom-module and can't be overwritten in any way (except by cooking your own rom - who is going to unlock our bootloaders?!?) Other than that, there are a few signing certs that Microsoft has. Signing the different executables with different privileges and accordingly a different cert. Their hashes are in the policies.

Using ARMv7 isn't going to add much I'm afraid. Although it may make a difference in the exe-header. But you've seen tools that were really old, remember ;) And they were signed to have TCB access. And they were compiled for ARMv4. So it should not make much difference.

I did some testing with certificates myself yesterday. Up until Zune totally went bezerk on it. I don't know what happened, but after removing my own cooked certs it all seems normal again. Zune started using 100% cpu on verifying certs and dropping my connection all the time. Help! So I haven't made much progress. I will try again later. Hope it will go better. And I will try to resign an existing executable, as Flow WP7 suggested.
[Windows Phone 7 Development and Hacking] fiinix:
According to policy on my omnia (webserver dumped) there seems to exist two typed of HDD, one ROM hard coded and one that points to internal sd card. It seems that all exe and dll on the sd are not "protected" and therefore can be hijacked.

Seems like ARMv4 will be enough, but to be on the safe side i compile with both, to have more chance getting it work.

Zune, hmm, did not seem to like you, maybe Microsoft DDOS'ed you lol

"Sent from my fingers on my phone", don't expect way too long text :)
[Windows Phone 7 Development and Hacking] Heathcliff74:
At the moment fiinix and I are both working on Samsungs and we use a couple of Samsung-specific exploit to get deeper in the system and getting a better understanding of the system. The ultimate goal is to find exploits that will work for all devices. But we're not at that stage yet. Hacking is research, a lot of trying and being lucky sometimes. Just bear with us ;)

Ciao,

Heathcliff74
[Windows Phone 7 Development and Hacking] fiinix:
Starting todays hacking, shall we? :)

Going through some research i'w found pretty fast.

MSDN > Security Loader

"

LVMOD uses the following criteria to determine whether to run an application:

* Any module loaded from read-only memory (ROM) can run.

* Any module that is digitally signed with a certificate from the device certificate store can run. For more information about digital signing with a certificate, see Signing Binaries.

* Any module that does not meet these criteria cannot run.

"

Microsoft's new retarded function:

MSDN > LoaderVerifierAuthorize

MSDN > LoaderVerifierAuthenticateFile

guidAuthClass: MSDN > LV_AUTHENTICATIONGUID_

HRESULT LoaderVerifierAuthorize(
__in HANDLE hslauthnFile,
__out LV_AUTHORIZATION* pslauthz
);

HRESULT LoaderVerifierAuthenticateFile(
__in const GUID* guidAuthClass,
__in_opt HANDLE hFile,
__in LPCWSTR szFilePath,
__in_opt LPCWSTR szHashHint,
__in HANDLE hReserved,
__out LPHANDLE phslauthnFile
);

How it calls our exe to check it:

BOOL success = LoaderVerifierAuthenticateFile(
LV_AUTHENTICATIONGUID_PORTABLEEXECUTABLE,
fopen("\\Windows\\ExeX.exe") // file handle IO
"\\Windows\\ExeX.exe",
LoaderVerifierGetHash( ... ) //unknown if called [COLOR="DarkRed"]OR[/COLOR] NULL
NULL,
&OUT_authInfo);

BOOL success2 = LoaderVerifierAuthorize(
OUT_authInfo, //from the function above; chained call.
&OUT_auth
);

if second call "LoaderVerifierAuthorize" fails (return value = 0):

INT code = GetLastError();

LV_E_BLOCKED
The file is blocked by security policy.
LV_E_NO_SIGNATURE
The file is not digitally signed by trusted authorities.
LV_E_TAMPERED
The module has been tampered with.
LV_E_CERTIFICATE_EXPIRED
The signing certificate or one of the certificates in the trust chain is expired.
LV_E_CERTIFICATE_NOT_TRUSTED
The signing certificate or one of the certificates in the trust chain is not trusted.
LV_E_CERTIFICATE_USAGE_VIOLATION
The signing certificate or one of the certificates in the trust chain violated its usage constraint.
LV_E_RESTRICTED_TO_LAUNCH
The security policy restricted the file to launches from only one specific chamber.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Heeyy,

Very nice info. Have you tried to call these functions? Are you allowed to call them from your Silverlight app in LPC? We really got to disassemble these functions!

Heathcliff74
[Windows Phone 7 Development and Hacking] fiinix:
Nope haven't called them, but i certainly can say they are access denied due these functions really needs to be protected.

Currently searching for "un-protected" exes (like this new one: TestShow.exe)

It HAS a compass Int32 value displayed, but that's an exe so we need disassemble that one.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Are we talking about the same thing?

I meant, have you tried to call the functions LoaderVerifierAuthorize() and LoaderVerifierAuthenticateFile() with your homebrew exe?? And did you get an error code that specifies why it is not allowed? Or does it possibly return 0x800704ec again, meaning that we cannot verify the executables from our LPC at all? I should try these functions with my own cert added to the "Code Integrity" store. See if that makes any difference.
[Windows Phone 7 Development and Hacking] Heathcliff74:
I'll PM you.
[Windows Phone 7 Development and Hacking] CopyCounsler:
The juice to get loose is protected by a private message?! LOL

This is the most interesting and thought provoking thread I've read in some time. Keep up the great work everyone and I'm so glad fiinix dropped in to help heathcliff out here.

I'd say they are 2 of the 5 best wm7 users on here. We need to open up a thanks thread just for these few people who are pioneering the homebrew scene.

Thank you.
[Windows Phone 7 Development and Hacking] fiinix:
That was ~ of what i have been thinking, if we now succeed hacking it, running exe.

What if "code posting via PM" is a Microsoft guy, right? Then he gets the source (obfuscated, but still traceable).

What if someone here on xda leaks the xap, then its all over. sigh...

Now, everybody wants that awesome code, right, but if he is a "noob" (sry, dont take it against yourself if you are one, nobody wants to be a noob), ill directly in mind, point that person as "dangerous leak" because it could be a Microsoft guy only hunting for the source code. Then again, it would be unfair if only "older" members could get it. Then once again, what if there was a "older" Microsoft member guy. sigh....

Then ill just stay with nodo (because then they cant patch it lololol).

Or ill release it after Mango if we get this working.
[Windows Phone 7 Development and Hacking] Heathcliff74:
LOL! You wouldn't believe how much PM's I got from people asking source-code (related to this thread, WP7 Root Tools, NoDo unlocking etc). If I would print it out I could paper my wall with it :p Anyway, I got a real ****load of exploits at the moment. Most of them are not very useful. Others are extremely useful or have the potential to be very useful. I open up these threads to attract people that can explore the possibilities. And if I'm confident enough that someone can really contribute to the homebrew/exploit thing, I'll share that over PM. And the most important stuff is being discussed in PM already. But until now that have only be a handful of people, that I'm confident I can share this stuff with. So don't worry. I'll keep the important stuff away from the Microsofties ;)
[Windows Phone 7 Development and Hacking] Heathcliff74:
Hmm.. Two things:

1. It doesn't seem that there are any policies about the PolicyLoader.exe itself. That would probably mean that it is subject to standard rights and that we should be able to run it with our exploit, which uses elevated rights :D

2. Be very careful with the change you proposed: LEAST_PRIVILEGE_CHAMBER_GROUP_NAME S-1-5-112-0-0X00. This can also be used for "Blahblahblah is allowed by LEAST_PRIVILEGE_CHAMBER_GROUP_NAME". But since you still run under S-1-5-112-0-0X80, you lock yourself out of the system!!! You suddenly don't have access to anything that is normally accessible to LPC!

So I think this could be a very good find, but try to use it in a different way as you proposed. Read the opening post again plz. This might be the missing link for us. :D

Ciao,

Heathcliff74
[Windows Phone 7 Development and Hacking] fiinix:
New info about PolicyLoader.

I Succeeded to call it (verifies we have access), and got 2 files in super root "\" { PolicyMerged.xml (183 Bytes), PolicyMeta.xml (183 Bytes) }

Simple call: WP7Process p = device.LaunchEXE("PolicyLoader.exe", "-writedump");

Not sure what was written to them tho; empty "<CeSecurityPolicyFile></CeSecurityPolicyFile>" probably, because i did not say direct path to what file to dump.

Next up, adding our SHA1 to the LOADERVERIFIER:

- Maybe the SHA1 way will work after all :?

XDAA.cer: SHA-1 Hash=DF23D303099CEA31D0972CE7BE50888CE813BC98

nfo: Custom policy below

<Rule
PriorityCategoryId="PRIORITY_STANDARD"
ResourceIri="/LOADERVERIFIER/GLOBAL/CERTIFICATES/HASH/SHA1/DF23D303099CEA31D0972CE7BE50888CE813BC98"
SpeakerAccountId="S-1-5-112-0-0-1"
Description="System Identity Group honors XDAA Code Signing PCA">
<Authorize>
<Match AccountId="S-1-5-112-0-0X01" AuthorizationIds="LV_ACCESS_EXECUTE" />
</Authorize>
</Rule>

Add one of these:

Add it to "<Account Id="S-1-5-112-0-0-1" Description="Local System" FriendlyName="TCB" Type="User">"

<Rule
PriorityCategoryId="PRIORITY_LOW"
ResourceIri="/LOADERVERIFIER/GLOBAL/ROUTE_TO_ACCOUNT/(+)/(+)/PRIMARY/WINDOWS/EXEX.EXE"
SpeakerAccountId="S-1-5-112-0-0-1"
Description="Route ExeX.exe">
<Authorize>
<Match AccountId="S-1-5-112-0-0-1" AuthorizationIds="LV_ACCESS_LOAD, LV_ACCESS_EXECUTE" />
</Authorize>
</Rule>

Basics from where i go now ~:

New call: PolicyLoader.exe "\Applications\Install\B2A1493F-42E1-4C0E-A5CB-EF204B677C43\Install\XDAA.policy.xml"

Note: this is just speculations, where i try to understand how i can add my exe.

> Havent executed something yet.

edit:

Forgot to add one of these lol, or it wil never "load" (PE_AUTHZ)

<Rule
PriorityCategoryId="PRIORITY_STANDARD"
ResourceIri="/LOADERVERIFIER/GLOBAL/AUTHORIZATION/PE_AUTHZ/NONE/NONE/PRIMARY/WINDOWS/EXEX.EXE"
SpeakerAccountId="S-1-5-112-0-0-1"
Description="Authorize ExeX.exe be loadable to $(XDAA_EXE_SID) and chambers">
<Authorize>
<Match AccountId="S-1-5-112-0-0X1" AuthorizationIds="LV_ACCESS_LOAD, LV_ACCESS_EXECUTE" />
</Authorize>
</Rule>
[Windows Phone 7 Development and Hacking] Heathcliff74:
Looking good.

Two things:

1. The AccountId in the PE_AUTHZ part should be "S-1-5-112-0-0X01" instead of "S-1-5-112-0-0X1", right?

2. You use "PRIORITY_LOW" and "PRIORITY_STANDARD". But I think we got best chance using "PRIORITY_HIGH" for all three policies.
[Windows Phone 7 Development and Hacking] fiinix:
According to [Ctrl] + [F], only "S-1-5-112-0-0X01" exists. Altho both of them mean the same in HEX.

Good reminding me, so that i dont take the wrong :)

Proof:

<Macro Id="SYSTEM_IDENTITY_GROUP_NAME" Description="TCB Identity Group SID" Value="S-1-5-112-0-0X01" />

The PRIORITY_ { LOW, STANDARD, HIGH }, i don't see a difference when to use low or standard. :/

Low as in "OrderBy(pri => pri)"? Maybe a sort mode of whats gonna be added first in row?

I Need to read the policy more, to understand why they do so at MS. :)
[Windows Phone 7 Development and Hacking] fiinix:
Rule order (BasePolicy.xml) (all exe policy)

First (not needed, if nothing to protect (REG, IO, ect)) (HIGH's)

2'nd: ROUTE_TO_ACCOUNT (LOW)

3'rd: PE_AUTH (STANDARD)

PE_AUTH: STAND

ROUTE_TO_ACC: LOW

"Protect": HIGH

ex: "/FILESYS/PRIMARY/WINDOWS/AUTODATACONFIG.EXE" (HIGH) ("Only System authorized to access adc.exe file")

ex: "/REGISTRY/HKLM/SYSTEM/AUTODATACONFIG/(*)" (HIGH) ("Protect adc registry keys. Only System can write to them, but everyone can read them")

Haha, would not use HIGH, ofc the word HIGH is "cooler", but it comes with a price, "it protects".
[Windows Phone 7 Development and Hacking] Heathcliff74:
Something else. The original policy for the TCB certificate looks like this:

<!-- Rule loaded from: \IMGFS\8314b832-8d03-444f-9a2a-1ef6fadcc3b8.policy.xml(31,2) -->
<Rule PriorityCategoryId="PRIORITY_STANDARD" ResourceIri="/LOADERVERIFIER/GLOBAL/CERTIFICATES/HASH/SHA1/88BCAEC267EF8B366C6E6215AC4028E7A1BE2DEB" SpeakerAccountId="S-1-5-112-0-0-1" Description="Microsoft Mobile Device TCB PCA is only honored by WLIDSVC_STANDARD_SELF_ISOLATED">
<!-- Authorize loaded from: \IMGFS\8314b832-8d03-444f-9a2a-1ef6fadcc3b8.policy.xml(32,6) -->
<Authorize>
<!-- Match loaded from: \IMGFS\8314b832-8d03-444f-9a2a-1ef6fadcc3b8.policy.xml(33,8) -->
<Match AccountId="S-1-5-112-0-0X21-0X00000001" AuthorizationIds="LV_ACCESS_EXECUTE" />
</Authorize>
</Rule>

The match accountid is "S-1-5-112-0-0X21-0X00000001". This is a chamber for Windows LiveID services (WLID).

I thought these entries were to tell which executables were executed in which chambers. But if that were true, that would mean that every executable signed with this specific TCB cert would be run in the WLID chamber. That doesn't make sense.

I see you used accountid "S-1-5-112-0-0X01" for the certificate. Any particular reason?
[Windows Phone 7 Development and Hacking] Heathcliff74:
I think it is important to use the exact accountid, although they are the same in hex. The string is matched for this.

The priority of the policies is the order in which the policies are queried in the policy database. The ones with high priority always apply. Policies with lower priority can be overruled by policies with high priority.
[Windows Phone 7 Development and Hacking] fiinix:
"I see you used accountid "S-1-5-112-0-0X01" for the certificate. Any particular reason?"

Because then i bind it as a system main certificate, simple :)

ofc, we want our programs to run under "System Identity Group", the highest. "SYSTEM" is super root. right, don't you want that?

This is where my "base" rule came from:

"System Identity Group honors Microsoft Code Signing PCA"

<Rule
PriorityCategoryId="PRIORITY_STANDARD"
ResourceIri="/LOADERVERIFIER/GLOBAL/CERTIFICATES/HASH/SHA1/FDD1314ED3268A95E198603BA8316FA63CBCD82D"
SpeakerAccountId="S-1-5-112-0-0-1"
Description="System Identity Group honors Microsoft Code Signing PCA">
<Authorize>
<Match AccountId="S-1-5-112-0-0X01" AuthorizationIds="LV_ACCESS_EXECUTE" />
</Authorize>
</Rule>
[Windows Phone 7 Development and Hacking] Heathcliff74:
Where the heck did you get this policy from. Can't find this anywhere.

Offtopic: Google is watching us. Did you know there is a google robot constantly indexing this thread? Anything posted here is indexed by google within minutes. Freaky.
[Windows Phone 7 Development and Hacking] fiinix:
Enumator (Mango) lol, no difference, just more policies that i can "on nom nom" (learn from) :)

Also i found this interesting Rule (from my raw phone) (attachment):

It says all "PE" (exe) are LV_ACCESS_LOAD, BUT what they miss is LV_ACCESS_EXECUTE. This is why they can be remote executed (but fail becuase the next step is "has it LV_ACCESS_EXECUTE") (Blocked by policy exception)

<Rule
PriorityCategoryId="PRIORITY_LOW"
ResourceIri="/LOADERVERIFIER/GLOBAL/AUTHORIZATION/PE_AUTHZ/SHA1/(*)"
SpeakerAccountId="S-1-5-112-0-0-1"
Description="By default, every non-ROM module can be loaded into any chamber if its signature allows">
<Authorize>
<Match AccountId="S-1-5-112-0-0X01" AuthorizationIds="LV_ACCESS_LOAD" />
</Authorize>
</Rule>

edit:

The Google thing:

Because this is "vbulletin" forum, it has the support like many blogs to have "RPC Ping"

So XDA has enabled this function "allow indexing by search engines".

The PING api notifies google everytime to say "Something has changed on page: "

Sample of googles blog RPC: http://blogsearch.google.com/ping/RPC2
[Windows Phone 7 Development and Hacking] Heathcliff74:
Ok. That explains it.

Well, I think we should add these policies to our Homebrew.policy.xml:

<Rule PriorityCategoryId="PRIORITY_HIGH" ResourceIri="/LOADERVERIFIER/GLOBAL/CERTIFICATES/HASH/SHA1/DF23D303099CEA31D0972CE7BE50888CE813BC98" SpeakerAccountId="S-1-5-112-0-0-1" Description="System Identity Group honors XDAA Code Signing PCA">
<Authorize>
<Match AccountId="S-1-5-112-0-0X01" AuthorizationIds="LV_ACCESS_EXECUTE" />
</Authorize>
</Rule>

<Rule PriorityCategoryId="PRIORITY_HIGH" ResourceIri="/LOADERVERIFIER/GLOBAL/ROUTE_TO_ACCOUNT/(+)/(+)/PRIMARY/WINDOWS/EXEX.EXE" SpeakerAccountId="S-1-5-112-0-0-1" Description="Route ExeX.exe">
<Authorize>
<Match AccountId="S-1-5-112-0-0-1" AuthorizationIds="LV_ACCESS_EXECUTE" />
<Match AccountId="S-1-5-112-0-0X80-0X00000001" AuthorizationIds="LV_ACCESS_EXECUTE" />
</Authorize>
</Rule>

<Rule PriorityCategoryId="PRIORITY_HIGH" ResourceIri="/LOADERVERIFIER/GLOBAL/AUTHORIZATION/PE_AUTHZ/NONE/NONE/PRIMARY/WINDOWS/EXEX.EXE" SpeakerAccountId="S-1-5-112-0-0-1" Description="Authorize ExeX.exe be loadable to any chamber">
<Authorize>
<Match AccountId="S-1-5-112-0-0-1" AuthorizationIds="LV_ACCESS_LOAD, LV_ACCESS_EXECUTE" />
<Match AccountId="S-1-5-112-0-0X01" AuthorizationIds="LV_ACCESS_LOAD, LV_ACCESS_EXECUTE" />
<Match AccountId="S-1-5-112-0-0X13" AuthorizationIds="LV_ACCESS_LOAD, LV_ACCESS_EXECUTE" />
<Match AccountId="S-1-5-112-0-0X22" AuthorizationIds="LV_ACCESS_LOAD, LV_ACCESS_EXECUTE" />
<Match AccountId="S-1-5-112-0-0X80-0X00000001" AuthorizationIds="LV_ACCESS_LOAD, LV_ACCESS_EXECUTE" />
<Match AccountId="S-1-5-112-0-0X80" AuthorizationIds="LV_ACCESS_LOAD, LV_ACCESS_EXECUTE" />
</Authorize>
</Rule>

I added more chambers and account-routes.

The commandline we should try first is something like this:

PolicyLoader.exe -writedump -nowritedb \Homebrew.policy.xml

We should look if our PolicyDump.xml look ok and then execute this:

PolicyLoader.exe \Homebrew.policy.xml
[Windows Phone 7 Development and Hacking] fiinix:
edit: removed
[Windows Phone 7 Development and Hacking] Heathcliff74:
Hmm. I think we should keep the priorities "HIGH". I think that high priority does now mean that we can't remove it anymore. It's just that the high priority policies are applied before any contradicting policies with lower priority. So that would give us a higher chance of success.

I wouldn't know what to do if we wanted to remove the policies again. :confused:

At the moment I'm also trying to finish some work on the WP7 Root Tools. I got basic cut / copy / paste for files working now. :) But I got to add more checks and locks to avoid multi-threading issues. So I'm not going to try the policies now. I need to add my cert again too, because I removed everything because my Zune went bezerk. I think I'll have some time to try this tomorrow.

I really hope this is going to be out lucky break. All the exploits are adding up now ;)

Ciao,

Heathcliff74

edit: yeah, I added all chambers for standard, elevated, tcb, etc. For executing accounts I also added the taskhost-account. If this all works, we should be able to call createprocess right from our silverlight app. No need to use the driver-exploit after applying this. I think we can safely try this, because it doesn't look like this could really mess something up.
[Windows Phone 7 Development and Hacking] fiinix:
Ok, that truly is clearing things/minds up about { LOW, STANDARD, HIGH }

I posted some code before (re-code below) and this clearly shows the "Rule upgrade technique".

It has "PRIORITY_LOW", meaning that CAN be upgraded to { LV_ACCESS_LOAD, LV_ACCESS_EXECUTE }, by a Rule that has { STANDARD or HIGH }

<Rule
PriorityCategoryId="PRIORITY_LOW"
ResourceIri="/LOADERVERIFIER/GLOBAL/AUTHORIZATION/PE_AUTHZ/SHA1/(*)"
SpeakerAccountId="S-1-5-112-0-0-1"
Description="By default, every non-ROM module can be loaded into any chamber if its signature allows">
<Authorize>
<Match AccountId="S-1-5-112-0-0X01" AuthorizationIds="LV_ACCESS_LOAD" />
</Authorize>
</Rule>
[Windows Phone 7 Development and Hacking] Heathcliff74:
Yes, that's correct. But more important, it can also be blocked by a policy with a higher priority.
[Windows Phone 7 Development and Hacking] WithinRafael:
Have you tried injecting your code into another already running process via CreateRemoteThread? :)
[Windows Phone 7 Development and Hacking] Heathcliff74:
We could try that, but I can have a guess too. It will most probably return 0x800704ec when you don't have TCB access. :p
[Windows Phone 7 Development and Hacking] fiinix:
Not going to start something big today, kind of late and i'w been very busy today.

But what i detected that we missed is that all "*.policy.xml" has this:

> or it fails PolicyLoader.exe

<?xml version="1.0" encoding="utf-8"?>
<CeSecurityPolicyFile
Description="ExeX security policy"
Vendor="Microsoft" RequiredOSVersion="7.00"
FileVersion="7.0.7390"
xmlns="urn:Microsoft.PlatformBuilder/CeSecurityPolicy">

[ ... ] (our policy)

</CeSecurityPolicyFile>
[Windows Phone 7 Development and Hacking] Heathcliff74:
Ok. Thanks for that. I'm not going to try today. I'm really curious if this will work. But it's a real pain to do all filecopy and cert stuff manually. So I'm working on the basic file copy / paste etc in the WP7 Root Tools. It's coming along nicely. Hopefully I can test it and release it in a couple of days. I think I will test the policy stuff this weekend.

Ciao,

Heathcliff74