yashsingh1/xdaforums huggingface dataset:
[Windows Phone 7 Development and Hacking] indiekiduk:
Ok I'd like to try opening that driver too. What's the lpFileName?
[Windows Phone 7 Development and Hacking] n0psl3d:
Sure, I guess there's a chance you could damage the flashlight with this. So use at your own risk. I tested on a HTC HD7 flashes one pulse.

char buf[256];
HANDLE h1 = CreateFileW(L"FLA1:",0xC0000000,0x3,0,0,0,0);
DeviceIoControl(h1,0xA0000000 | 0x800,&buf,256,0,0,0,0);

LEDFlashComDLL.dll is where that code was from, the driver is HTC_Flashlight.dll.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Actually, I wasn't thinking about patching the .NET assembly. Instead I wanted to try patching the native dll. I assumed it is the .NET assembly that is signed and therefore getting elevated privileges. I thought, maybe the native dll is not signed and can therefore be patched. Anyway, I should probably first check which dll's are signed. I guess both the .NET assembly and the native dll are signed to keep elevated privileges (read/write access to the full filesystem and registry). If either one of the two is not signed, it is possible to patch it and make it possibly useful for other devices.
[Windows Phone 7 Development and Hacking] n0psl3d:
Why do you think that the HTC hub has elevated privs? Its signed using the LPC cert like all the other OEM apps. It just uses the Registry and Filesystem COM dlls which we can already use the functionality from (ComFileRw_HTCHub.dll, ComKeyEvents_HTCHub, ComRegRw_HTCHub, GetInfoComDll_HTCHub).
[Windows Phone 7 Development and Hacking] Heathcliff74:
Hmm. Makes me think.

- Why are these files signed then? Code-integrity? Removing all signatures from the dll's/assemblies and also remove the signatures from the references would allow us to patch the files. I've done this before. I got a tool to do that. I'm not sure if it will work on silverlight assemblies too. Will try that.

- Need to find out if the app (HTC Hub in my case) does check the DRM from the WMAppPRHeader.xml. Need to patch that.

- Patch the IsHTCDevice functions (native/managed).

About the signatures. I assumed the signatures gave extra privileges, because for instance the Registry Viewer has a lot of access denied. I thought that signing the files with these signatures would give the app those permissions. You said that yourself, didn't you? If it isn't the signature, what is causing those 'permission denied' errors?? And how are you sure about being signed with LPC cert?

Thanks.
[Windows Phone 7 Development and Hacking] WithinRafael:
You can check HTC's YouTube application, or anything with ComRegRw*.dll (which seems to be a lot of HTC's applications).
[Windows Phone 7 Development and Hacking] n0psl3d:
Ok, take ComFileRw_HTCHub.dll for example. If you go Properties > Digital Signatures > Details > Advanced > Issuer

CN = VeriSign Mobile CA Authority for Microsoft

OU = Microsoft Phone Applications for LPC

Then you look in the security policy:

<Rule PriorityCategoryId="PRIORITY_STANDARD" ResourceIri="/LOADERVERIFIER/GLOBAL/CERTIFICATES/HASH/SHA1/069DBCCA9590D1B5ED7C73DE65795348E58D4AE3" SpeakerAccountId="S-1-5-112-0-0-1" Description="VeriSign Mobile Root Authority for Microsoft is honored by LPC Identity Group">

Everything I have seen from marketplace has been LPC signed. I doubt we will see anything else there unless its a proper phone update (i.e. via ULDR)

Compare that to a file from the base ROM image which gets loaded into a TCB chamber (you will see that is signed differently). mcf.dll for example: Windows Mobile TCB Test Signing Cert.

ciroots.p7b seems to be one place where the code signing certificates are stored on the device.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Okay. Thanks for elaborating. So that would mean that LPC signing is just for code integrity, right? And it can probably be easily removed.

Edit: and I still don't understand the 'access denied' in the registry viewer...
[Windows Phone 7 Development and Hacking] n0psl3d:
Dunno really, try it. You can probably patch it, then resign if necessary (with your dev cert). I haven't looked into the cert stuff in that much detail yet. Im not 100% sure how the development unlock affects the code signing checks.

With registry viewer access is denied is likely because of the rules in security policy protecting certain registry keys from that (user/chamber/whatever). For example:

<Rule PriorityCategoryId="PRIORITY_HIGH" ResourceIri="/REGISTRY/HKLM/COMM/SECURITY/LVMOD/(*)" SpeakerAccountId="S-1-5-112-0-0-1" Description="Protect LoaderVerifier Registry Keys">
<Match AccountId="S-1-5-112-0-0X02" AuthorizationIds="KEY_ALL_ACCESS, KEY_READ, KEY_WRITE, KEY_EXECUTE" />
<Match AccountId="S-1-5-112-0-0XFF" AuthorizationIds="KEY_READ, KEY_EXECUTE" />

<Account Id="S-1-5-112-0-0X02" Description="TCB Resource Group" FriendlyName="TCB Resource Group" Type="Group">
<Account Id="S-1-5-112-0-0XFF" Description="Everyone Group" FriendlyName="Everyone Group" Type="Group" />

In English, only applications running in the TCB have write access to those keys but everyone has read access (including LPC chamber apps)... Unless another rule overrides it!
[Windows Phone 7 Development and Hacking] JoeTheFro:
I extracted the full XAP out of the device. Like OEM and OP cabs were placed back in the olden days, there should be nothing changed in them.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Wow. I got write access to the entire registry on my Samsung Omnia 7. I mean, at least at the places I tried, it worked. I used the COMRilClient.dll (and dependencies) and call

CoRILClient.CallInterface().RegSetDWORD(CoRILClient.HKEY_LOCAL_MACHINE, @"System", "Test", 10);

And that just works. I can also retrieve the value. I can't enumerate keys or values with this api, just read/write dwords and strings.

Next I will try to break the code. I will start changing the binaries and see when it stops having write-access. I want to know what exactly determines the write-privileges. I will remove the signatures from the assemblies and native dlls and I will try to patch them.

When I know what I can do and what I can't do I will try to use the HTC dlls on my Samsung, because they have a better API at the moment.

Got to have some sleep now. To be continued.
[Windows Phone 7 Development and Hacking] ceesheim:
http://dl.dropbox.com/u/5011238/Data/HTC_OEMAPPS.7z

all the oem apps (htc)
[Windows Phone 7 Development and Hacking] ajhvdb:
Wow, is a good word for this...Wow :)
[Windows Phone 7 Development and Hacking] ceesheim:
http://dl.dropbox.com/u/5011238/Data/O2_DE_operatorpkg.7z

and here : O2_DE_operatorpkg.7z (latest rom)

and O2_DE_HTC_OEMAPPS is coming (real slow upload :( )
[Windows Phone 7 Development and Hacking] ceesheim:
but you can dump a rom your self now to :)

look in the main forum (wp7 dev % hack) for htcRIE_0.7.0.11 ( beta editor for wp7)

http://dl.dropbox.com/u/5011238/Data/O2_DE_HTC_OEMAPPS.7z

O2_DE_HTC_OEMAPPS.7z
[Windows Phone 7 Development and Hacking] WithinRafael:
This is expected behavior; I don't believe you stumbled on anything new here. Sadly, one can't roll their own (unsigned) COM component to provide the same capabilities.
[Windows Phone 7 Development and Hacking] ceesheim:
here is a link to code signing .cer

http://dl.dropbox.com/u/5011238/Data/Code_signing_cer.7z

http://dl.dropbox.com/u/5011238/Data/certs.7z
[Windows Phone 7 Development and Hacking] n0psl3d:
Sure they can, if the driver is exposing the IOCTL's and there's no policy in place then you can call that straight off.
[Windows Phone 7 Development and Hacking] WithinRafael:
I thought we already established policies are in place?
[Windows Phone 7 Development and Hacking] n0psl3d:
Sure for certain things but HTC/Samsung etc are allowing access to their filesystem/registry drivers from the LPC chamber. So you could compile a com dll which determines what the phone is, then uses one of the drivers (CreateFile/DeviceIoControl) to get elevated access to the fs/registry. This will give you more permissions than using standard win32 API functions from your COM.
[Windows Phone 7 Development and Hacking] WithinRafael:
Ah gotcha. I thought Heathcliff74 was doing this and running into errors. Not sure what he's doing then, accessing the driver directly is simple enough.
[Windows Phone 7 Development and Hacking] indiekiduk:
How can you read/write the registry using a DeviceIoControl? Do you mean that HTC/Samsung have written a driver that supports that and then internally does the WinAPI calls?
[Windows Phone 7 Development and Hacking] n0psl3d:
Yea indeed, sorry didn't make that very clear. If you use DeviceIoControl calls to the HTC/Samsung drivers they expose the IOCTLs for reading/writing fs/registry etc.. This seems to allow greater access than using WinAPI calls directly from your COM (such as RegistryGetDWORD/RegistrySetDWORD etc..).

EDIT: Just checked HTC App Driver, HTCRegUtility.dll uses WinAPI inside that.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Can someone with a HTC or LG test this package. It uses Samsung dll's, but I want to know if this works on non-samsung. I did remove the signatures on the dll's and on my samsung it still works.

When installed the program simply reports "Fail" or "Success". Please let me know the result. Thanks!
[Windows Phone 7 Development and Hacking] ceesheim:
Fail on hd7
[Windows Phone 7 Development and Hacking] Heathcliff74:
Okay, thanks!

Concerning File-system- and registry-write access through the native dll's I think I can conclude so far:

- It has nothing to do with signing (TCB or LPC) / certificates / strong names (TCB signing may elevate privileges, but that is another story)

- There is no need for higher privileges, just the interop-capabitility

- HTC and Samsung have their drivers installed with their own API's to access filesystem and registry (like n0psl3d explained)

- If you know on which device you are and you know how to use the driver API you can access it.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Thanks for explaining, but doesn't that contradict? You say that the drivers have greater access than WinAPI and then you state that the drivers uses WinAPI.

Which disasm do you use?
[Windows Phone 7 Development and Hacking] Heathcliff74:
Thanks, but these only include the public keys, so it is not useful for signing our own assemblies.
[Windows Phone 7 Development and Hacking] n0psl3d:
I think what's happening is that the HTC drivers are running as elevated permissions, therefore if you make the call into the driver (IOCTL) then because that is running as elevated then the WinAPI call it makes internally is elevated.

If you make a WINAPI call directly from your COM and don't use the App drivers then you have lower permission.

I use IDA pro for disassembly...
[Windows Phone 7 Development and Hacking] ceesheim:
I dumped them from a rom (all the .cer ) sorry that it didn't work :)
[Windows Phone 7 Development and Hacking] WithinRafael:
I think there's some confusion in this thread. There are only two ways of accessing the registry/filesystem:

* Standard Win32 API

* Driver communication

We already established that accessing resources via the former is restricted via policies and various measures in place. Think of this like ACLs on an NTFS file system.

The latter is how all the carrier-specific applications operate. The native libraries bundled with their applications are merely DeviceIoControl wrappers. Reads, writes, etc. are all done in kernel mode and ferried back to the user via a carrier-defined interface. (I have a feeling we're going to see a Microsoft smackdown on carriers in future updates.) The only reason these COM components exist is because carriers can't P/Invoke DeviceIoControl (and others) in managed code.

I'm going to ping Chris Walsh over the break. We'll write a cross-device COM wrapper to allow reg/filesystem read/write so we can eliminate all the confusion.
[Windows Phone 7 Development and Hacking] n0psl3d:
Its actually more complicated than that. There are user mode drivers and kernel mode driver security segregation as well. Even with the carrier elevated rights you still can't screw with stuff in the TCB (so the policy is still enforced). The security policy is enforced from the TCB. I think the HTC filesystem and registry drivers are still running in userland just elevated privs.

I am quite impressed by the way its done to be honest.. It seems a good way to allow carriers elevated access but not fully compromise the OS security.
[Windows Phone 7 Development and Hacking] Heathcliff74:
You explained it a bit better than I did, but that is kinda what I meant. I said "through the native dll's" and with that I meant the carrier-specific driver communication.

The point I tried to make was this: Although the WinApi is restricted with policies and ACL's that need TCB-signing to get the necessary privileges, there seems to be a security hole in the driver communication.

When talking to the drivers there is no need for code-signing-certificates/strong names etc. You just need to identify the necessary driver/API and use it. I think that is an important fact.
[Windows Phone 7 Development and Hacking] WithinRafael:
I agree, this is where I think Microsoft will lay the smackdown soon. Although lots of carriers are tied to this stuff... I'll ask the WP7 folks in January to see what's in store for this.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Yeah, except it seems that nothing is stopping us from using the elevated access from the carrier-drivers.
[Windows Phone 7 Development and Hacking] WithinRafael:
I reckon Microsoft will get involved and force carriers to do signature checking (of the callers) in their COM components. Given how horrible the carrier code is, I doubt we'll see this any time soon.
[Windows Phone 7 Development and Hacking] Heathcliff74:
I tried that one too, but I guess my ARM knowledge is not quite enough :o I can see the calls to CreateFileW and DeviceIoControl, but I can't figure out how arguments are passed between the functions. I don't see which device is used. Do you know a good reference to learn this stuff?
[Windows Phone 7 Development and Hacking] Heathcliff74:
That would be awesome!
[Windows Phone 7 Development and Hacking] n0psl3d:
Indeed :) The security policy is still enforced though. The stuff I want to do requires full TCB access, elevated wont cut it... the only easy way for that is a custom ROM.

They should really require carrier apps to be signed with the elevated cert, then check the callers sig. Right now, its not ideal.. but the most dangerous functionality is still denied even from elevated.

Not really, if you understand X86 asm better (like myself) you can just use the emulator DLL's for certain things. I would just refer to the ARM CPU manual and instruction set reference.
[Windows Phone 7 Development and Hacking] WithinRafael:
Do you already have a list of what applications/drivers, if any, with full TCB access? That documentation would be a good start for finding exploitable code.

I know you don't want to hear this, but the ARM architecture manuals (http://is.gd/jjg89) are your best bet. (Learning IDA, however, is best done with The Ida Pro Book. (http://is.gd/jjge6))

If you point me to the file/instructions, I can probably do the ARM->C translation for you.
[Windows Phone 7 Development and Hacking] n0psl3d:
Not yet, shouldn't be that hard to figure out. The problem is debugging it really.. Don't have any native code debugging access / KITL access and JTAG is way too expensive.. Developing a kernel exploit without a debugger is dam hard haha
[Windows Phone 7 Development and Hacking] Heathcliff74:
Well, I have quite some experience in disassembling x86 in IDA. I know how different compilers use the stack and registers for argument passing etc. I think I know enough of IDA to go around. But I was aiming for accessing the Samsung drivers in order to finally create a full-blown file/reg-explorer. I'm really in the dark with my Samsung. So it is not a matter of disassembling but I hoped to be able to create some C code to access the driver. But I'll first dive into ARM to get a grip on how this works.

Thanks.
[Windows Phone 7 Development and Hacking] n0psl3d:
Do you need to be making calls directly to the driver? Why not just include the Samsung com dll in your app then use the exported functions? That will give you the same permissions as making DeviceIoControl calls but will be a lot less effort. Though, you might figure out more functionality if you reverse the drivers.. :]
[Windows Phone 7 Development and Hacking] Heathcliff74:
The managed Samsung dll's I've seen so far only have RegGetString/RegSetString/RegGetDWord/RegSetDWord/LaunchExe/ReadTextFile. No browsing (enumerating) capabilities on filesystem or registry what so ever. I can't browse my phone to see if there are more useful assemblies/native dll's.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Well, i got FileBrowser.exe working now through LaunchExe, but this is only filebrowsing, no copy/paste etc. I still don't have possibilities to see if there are interresting binaries on there.

I got a rom image of the samsung omnia 7. Maybe I should try to extract the files from there.
[Windows Phone 7 Development and Hacking] walshieau:
Hey guys,

Some brief info on the TCB & COM DLL's. They're STILL running in userland, and they ALWAYS will.

The policies are enforced by the Core, even if you find an exploit, you've got 5 seconds to do your work, before a KernelModeException is thrown by the core, and the OS / Phone is rebooted.

Going to post some more info on this for everyone this weekend.
[Windows Phone 7 Development and Hacking] n0psl3d:
Wtf, that seems kinda obscure. 5 seconds is enough time to do something persistent (e.g ADBAddAccountToGroup to TCB) even if the phone reboots. Soon as you got control over the program counter in kernel space its game over regardless :/
[Windows Phone 7 Development and Hacking] walshieau:
I doubt you're going to get control over it. And there is a 5-10 second delay before you actually do something till it is persisted. Remember, it isn't written instantly.

How is it obsecure?
[Windows Phone 7 Development and Hacking] n0psl3d:
File system writes are performed in milliseconds.. That's enough time for example, to patch accountsdb/policydb to whatever you need to do. NX/ASLR/code signing are good exploit mitigation .. that 5 seconds until it reboots sounds retarded =) Whats this implemented in anyhow coredll?
[Windows Phone 7 Development and Hacking] indiekiduk:
See to build your HTC/Samsung hybrid registry/filesystem wrapper, wouldn't it be easiest to include both Com dlls in the app and build a managed wrapper class, try calling the HTC method, then call the Samsung if it fails. Then optimise it by storing HTC or Samsung in a user pref.
[Windows Phone 7 Development and Hacking] Heathcliff74:
But what Samsung dll to use?? The api of the NetworkProfile is not really sufficient. I'm looking for a binary I can use. But I have no real filesystem access on my phone (filebrowser.exe does not support copy/paste etc).

I downloaded a rom-image of the samsung omnia 7 here: http://www.samfirmware.com/WEBPROTECT-i8700.htm. But I don't know how to extract any files from the nb0 image. I tried prepare_imgfs.exe and and viewimgfs.exe. It give me errors like "Searching for IMGFS start... Not found!"

Anyone who can guide me to extract assemblies from the nb0 image? Or get the files from my phone in another way?

Thanks.
[Windows Phone 7 Development and Hacking] JoeTheFro:
For those interested in code signing options and inner workings... i am digging around and found some stuff...

http://www.jac-it.com/xda/CodeSigningCert.zip

here is link in case someone wants to see if its good for anything.....
[Windows Phone 7 Development and Hacking] JoeTheFro:
You can give this a shot

http://xdaforums.com/showthread.php?t=884239

However, if you try and pull modules, you will need to recmod... which from what i hear doesnt work properly with this arc.. (if anyone knows of recmod workin, lemme know, cause the exe i have doesnt work on these dumped modules )
[Windows Phone 7 Development and Hacking] Heathcliff74:
Thanks, but someone else already posted these earlier in the thread. They only contain public certificates, so they are not useful for signing our own binaries.

The xml file contains some info about where all the different certificates are trusted.
[Windows Phone 7 Development and Hacking] JoeTheFro:
Musta missed it, thanks
[Windows Phone 7 Development and Hacking] Heathcliff74:
Thanks, but unfortunately it doesn't work. I have an nb0 image file. The rom editor doesn't understand the file format. It only wants nb or nbh. I tried renaming, but it complains about unrecognized format.
[Windows Phone 7 Development and Hacking] JoeTheFro:
Da_G released a couple rom tools, i dont remember the link, but it is somewhere in the wp7 dev and hackin section
[Windows Phone 7 Development and Hacking] indiekiduk:
I could be wrong but the privileged cert hash of CED778D7BB4CB41D26C40328CC9C0397926B4EEA looks to me like the one included in the WM6 SDK, will take a look.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Thanks. I will find them. I will try tomorrow. Gotta get some sleep first. Ciao!

Edit: I took a quick peek, but those tools also seem to handle nbh/nb files. Not nb0. I'm not sure how to use the nb0 file. To be continued...
[Windows Phone 7 Development and Hacking] :
You could try osnbtool: (pass=pdaclan.com)

http://xdaforums.com/attachment.php?attachmentid=145372&d=1231679537

And the updated cecompr_nt.dll from Da_G's tools. Might work...
[Windows Phone 7 Development and Hacking] Heathcliff74:
Ha, cool! You remember the hash-code of a certificate.. Well, if it is true that this is a privileged certificate from which the private part is in the public domain, it would be really stupid from MS to use that certificate. Let us know what you find.
[Windows Phone 7 Development and Hacking] indiekiduk:
It was the other one that looked similar starting 1c28 but it's different. However, how about looking for the security policy key in the registry? I think that it builds the registry using all the policy xml files so maybe we can just add a new CA for the TCB/Elevated using the HTC registry write dll?
[Windows Phone 7 Development and Hacking] Heathcliff74:
Unfortunately doesn't work either. I have to give a number for the decompressed part. In the readme (chinese?) they use number 1. I tried numbers 0, 1 and 2. Would give me "Can not find Part-1!" everytime. Also with the new version of cecompr_nt.dll.

Thanks anyway.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Might be possible. But that would be too easy, wouldn't it? ;) I have write-access to the registry on Samsung omnia too. So if it works, it will probably work on both HTC and Samsung.
[Windows Phone 7 Development and Hacking] indiekiduk:
Just for kicks am going to try installing the WM6.5.3 SDKSamplePrivRoot.cer by email and sign an app dll and com dll with SDKSamplePrivDeveloper.cer. It's like they have renamed Unprivileged as Standard Rights and Privileged as Elevated Rights but hopefully the reg keys etc will be the same as WM.

update:

Gave it a try, the SDKSamplePrivRoot.cer installed via email ok. Signed the dll using:

D:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin>signtool sign /f sdksamp
leprivdeveloper.pfx /v WindowsPhoneApplication1.dll
The following certificate was selected:
Issued to: TEST USE ONLY - Sample Privileged Developer - Windows Mobile SDK
Issued by: TEST USE ONLY - Sample Privileged Root for Windows Mobile SDK
Expires: 31/12/2015 08:00:00
SHA1 hash: 766F54421367BD7B4002CAD11CDFA86902E92848

Done Adding Additional Store

Attempting to sign: WindowsPhoneApplication1.dll
Successfully signed: WindowsPhoneApplication1.dll

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

Zipped back up the xap and deployed. Unfortunately when try to run it it says WindowsApplication1 license is invalid. Please purchase the product. Oh well.