Related
Hey guys,
There has been a lot of great strides here in learning more about this WP7 and what it's capabilities are! I'm very excited about what everyone is doing!
I'm sure a lot of you have been doing your own tinkering and was hoping to combine some efforts and maybe eventually come up with a solid SDK for home brew applications.
Here is where I'm at with my exploration:
With the COM bridge and Visual Studio 2008 one can develop a native ARM COM DLL to talk to native code from Silverlight.
I believe the ComBridge.RegisterComDll does not really register the COM class in the system registry. I believe the runtime simply caches the clsid and filename and creates the class when the runtime is looking to instantiate the ComImport COM class.
We are able to use wince's win32 API to make operating system calls from the C++ code.
There does not seem to be any security restrictions that I have come across in using the operating system from native code. I will note that without the NETWORKING caps in the manifest, DNS would only resolve cached addresses, but the rest of the sockets worked fine. I do not believe this to be a security measure, but more of a missing initialization method I am not aware of.
We can return other COM interfaces created in our native code and talk to it by implementing the COM interop interfaces in C# ( InterfaceType(ComInterfaceType.InterfaceIsIUnknown))
Currently I have written a sockets library here: dl[dot]dropbox[dot][c][o][m]/u/4165054/PhoneNetworkingSample[dot]zip
I also have the workings of a file system library that I have not completed yet. I realize there is some OEM lib out there that does FS access, but I believe it to be important to homebrew that we make our own.
I recently have been looking into Direct3D 11 API support for the phone. I have successfully created a D3D11 device and passed it back to .NET code where I was able to execute some methods on it. A lot of work needs to be done here. First the device is almost useless if we cannot render to something. I believe I have been able to create a window, but not been able to actually show it. My next method of attack will be to find the hwnd Silverlight is rendering to, hook its WndProc and do our own rendering here.
If anyone else has any information on their hacking, please let us know! You can contact me on this board or on twitter [at-sign]jmorrill.
-Jer
Great work! I will definitely have a look at the sockets source code. This should open up a lot of possibilities for app developers
Sent from my HTC HD2 using XDA App
jmorrill said:
Hey guys,
[*]We are able to use wince's win32 API to make operating system calls from the C++ code.
[*]There does not seem to be any security restrictions that I have come across in using the operating system from native code. I will note that without the NETWORKING caps in the manifest, DNS would only resolve cached addresses, but the rest of the sockets worked fine. I do not believe this to be a security measure, but more of a missing initialization method I am not aware of.
[/LIST]
Click to expand...
Click to collapse
There definitely are security restrictions applied to the native code. This is what I think. Our applications are deployed in the Least Privilidged chamber (LPC) which has dynamic capabilities by the ones we specify when the application is deployed.
<Macro Id="LEAST_PRIVILEGE_CHAMBER_GROUP_NAME" Description="Least Privilege Chamber Group" Value="S-1-5-112-0-0X80" />
and are members of the:
<Account Id="S-1-5-112-0-0X70" Description="All public capability accounts are members of this group" FriendlyName="Public capabilities group" Type="Group" />
There are certain win32 API calls which are allowed but anything which could be used to compromise the OS is only allowed to be called from the TCB chamber.
<Macro Id="SYSTEM_CHAMBER_GROUP_NAME" Description="TCB Chamber Group" Value="S-1-5-112-0-0X00" />
<Macro Id="SYSTEM_USER_NAME" Description="TCB user SID" Value="S-1-5-112-0-0-1" />
For example, loading nativeinstallerhost.exe:
<Rule PriorityCategoryId="PRIORITY_HIGH" ResourceIri="/LOADERVERIFIER/ACCOUNT/(+)/ACCOUNT_CAN_LAUNCH/NONE/NONE/PRIMARY/WINDOWS/NATIVEINSTALLERHOST.EXE" SpeakerAcc ountId="S-1-5-112-0-0-1" Description="Only TCB can launch into this chamber">
I am guessing the LOADVERIFIER is doing this using the code signing certificates. If you check your apps they will be signed with a LPC certificate but if you look ones included in the ROM then they have TCB signing.
I can't see anything that would prevent you from doing socket stuff in the security policy (as you have found). However, it looks like you need:
<Macro Id="ELEVATED_RIGHTS_RESOURCE_GROUP_NAME" Description="Elevated Rights Resource Group SID" Value="S-1-5-112-0-0X14" />
To use raw sockets:
<Rule PriorityCategoryId="PRIORITY_STANDARD" ResourceIri="/RESOURCES/GLOBAL/WINSOCK/RAWSOCKET" SpeakerAccountId="S-1-5-112-0-0-1" Description="Acess to Winsock Ra w sockets">
<Authorize>
<!-- Match loaded from:
<Match AccountId="S-1-5-112-0-0X14" AuthorizationIds="GENERIC_ALL" />
</Authorize>
Would be useful to confirm that this is the case and that this policy is actually being applied
Yep, that reflects the same behavior in Windows on the desktop. Normal socket use is okay, raw requires admin.
Do we have a tutorial on how to create native COM classes?
Also, this url explains why you cannot copy/read some files from the \Windows directory, but can LoadLibrary on them (which is how I load d3d11.dll).
blogs.msdn.com/b/windowsmobile/archive/2007/12/29/why-can-t-i-copy-programs-out-of-windows.aspx
Sorry no tutorial on making COM objects. But basically just create a new smart device mfc dll in VS2008, then add a new ATL class to the project. I modified the COM interface/classes to inherit from IUnknown vs. IDispatch.
I guess I misspoke about the security restrictions. Really what I'm looking for, is to have about the same level of access to the device as any Windows Mobile application has, which is enough to suite most of my needs personally.
Ok, I've just created a native dll and call it from Silverlight.
Once you know what type of project to create it's quite easy. The longest part was to reinstall Visual Studio 2008.
Quick question: how do you handle passing string between native and managed? I have several ways in mid but they all seems very complicated.
(nico) said:
Ok, I've just created a native dll and call it from Silverlight.
Once you know what type of project to create it's quite easy. The longest part was to reinstall Visual Studio 2008.
Quick question: how do you handle passing string between native and managed? I have several ways in mid but they all seems very complicated.
Click to expand...
Click to collapse
Depends. Sometimes you can get away with StringBuilder. Or you can do a string outgument, and create the wchar_t in native code.
What I've done so far is creating wchar_t in native code, return an IntPtr to managed code, use Microsoft.Phone.InteropServices.Marshal.PtrToStringUni to get a string and then call a custom native method to delete my wchar_t array (didn't find a release method).
Seems a lot of work just to get a string...
(nico) said:
What I've done so far is creating wchar_t in native code, return an IntPtr to managed code, use Microsoft.Phone.InteropServices.Marshal.PtrToStringUni to get a string and then call a custom native method to delete my wchar_t array (didn't find a release method).
Seems a lot of work just to get a string...
Click to expand...
Click to collapse
Just stick it in a function, and be done with it. That way you only have to do it once. Don't worry about efficiency; unless it is in a tight loop, the string conversion isn't going to slow you down noticeably.
BTW, I got registry working and started working on a registry viewer.
However, I got access denied when trying to browser most of the node.
For example I can browse HKLM\System\State but not HKLM\System.
(nico) said:
What I've done so far is creating wchar_t in native code, return an IntPtr to managed code, use Microsoft.Phone.InteropServices.Marshal.PtrToStringUni to get a string and then call a custom native method to delete my wchar_t array (didn't find a release method).
Seems a lot of work just to get a string...
Click to expand...
Click to collapse
That isn't necessary at all. Simply define your managed class/interface with the MarshalAs attribute on your params. .NET will take care of the rest.
For example:
HRESULT MyFunction([in] LPWSTR param)
Would translate to:
UInt32 MyFunction(
[MarshalAs(UnmanagedType.LPWStr)]
[In] String param);
Thanks Rafael.
This is nice! How do I do the opposite? I need to create a string in unmanaged and use it from managed code Do I just have to use [out] instead of [in] in your example?
This is much simpler that my method
(nico) said:
Thanks Rafael.
This is nice! How do I do the opposite? I need to create a string in unmanaged and use it from managed code Do I just have to use [out] instead of [in] in your example?
Click to expand...
Click to collapse
Yep, it should match the direction indicated in your COM library's IDL. It basically just drives how Marshaller handles copying of memory, pinning, etc.
You guys are smarter the me at this, obviously, but is there a site where you share your code? because i'm smart enough to use existing code and make something happen..
jmorrill said:
I recently have been looking into Direct3D 11 API support for the phone. I have successfully created a D3D11 device and passed it back to .NET code where I was able to execute some methods on it. A lot of work needs to be done here. First the device is almost useless if we cannot render to something. I believe I have been able to create a window, but not been able to actually show it. My next method of attack will be to find the hwnd Silverlight is rendering to, hook its WndProc and do our own rendering here.
Click to expand...
Click to collapse
Have you checked out ZuneBoards? They've done some work in this area already with their OpenZDK, which looks similar to what we may need to do. Their method of breaking out of the CLI virtual machine is different than ours, but a lot of what they've done is what we want to do, too.
One thing that doesn't work are the typical WinCE graphics functions:
GetDC(NULL) ;
GetDesktopWindow();
LineTo();
GetClientRect();
That is they work, but the root window is empty! 0 wide and 0 tall. The drawing engine (unsurprisingly) is elsewhere.
ajhvdb said:
You guys are smarter the me at this, obviously, but is there a site where you share your code? because i'm smart enough to use existing code and make something happen..
Click to expand...
Click to collapse
Have you gotten anything to compile yet?
Check this one out: http://dl.dropbox.com/u/4165054/PhoneNetworkingSample.zip
And see if you can get it to compile (I would make it an attachment in this post but it's jmmorril's code). I've been using Visual Studio 2008 and the WinCE 6 refresh to compile the com dll: http://www.microsoft.com/downloads/...3A-A651-4745-88EF-3D48091A390B&displaylang=en
Then I copy the com dll over to my visual studio 2010 Windows Phone project, ready to be used. There are probably better ways, but you need to find out at least some way of doing it.
I've managed to create a basic Registry Viewer, readonly for the moment.
For now, I didn't manage to get access to root path, so the first 2 levels are hardcoded.
Download it here: (link removed, see below)
Edit:
Updated version here: http://bit.ly/eEZ0Uf
(nico) said:
I've managed to create a basic Registry Viewer, readonly for the moment.
For now, I didn't manage to get access to root path, so the first 2 levels are hardcoded.
Download it here: http://bit.ly/hOWLnI
Click to expand...
Click to collapse
wow man nice work , could you also make a file explorer ?
edit: here is a direct link http://www.xda-developers.ch/download/?a=d&i=7061084002
Do you have a locked phone with Nodo?
So, at this moment your chances are:
Restore the phone to previous version (from Zune)
If your device is LG, you can use the integrated registry editor to unlock it
Buy a developer account subscription
What if your country is not supported by the Marketplace to buy a developer account subscription?
Well, you can ask someone to unlock your phone via remote desktop with their account, then apply any relock prevention
You can use Yallapps unlocking service
I was thinking on update chevron for nodo. There is no marketplace in my country to test and check what is the token used by the developer unlocker application from the phone tools.
Recently I discovered yallaapps (where everyone can register and unlock their phones). It is very unfair compared to the standard marketplace rules (you can upload only free apps, and like 3-4 every 80 dollars).
Anyone here have a yallaapps account to share? (via remote-ethernet usb for example) and unlock my phone to check what is the token, and test if microsoft did something to avoid chevron.cer, etc... I can work some nights trying to get an updated unlocker for us.
Comments?
I've thought about this too. But I have an unlocked Omnia 7 now, with NoDo. And I'm kinda afraid to test for locking/unlocking, because it might lock my phone, while not being able to unlock again. Only a restore of backup or reflash firmware would possibly fix that, but I too busy to risk that now. If it wasn't for that I would've tried a couple of things.
With registry access we can set the value of HKEY_LOCAL_MACHINE\Software\Microsoft\DeviceReg\PortalUrlProd to anything we like. Set it to something like this: http://www.wp7unlock.com. That site does not exist, but that doesn't matter. Note that I mention "http" and not "https" to make it easier. Then add this url to the hosts-file on your computer. Open a http-server on port 80 which logs all http-requests. Now run ChevronWP7 unlocker and try to lock / unlock. Note: Don't try this if your device is upgraded to NoDo and unlocked, and you wish to keep it like that. You can grab the exact request. That is the first step. But this may already lock your device, if you got it unlocked. You need an unlocked device in the first place to edit the registry. If you got the exact http-request that is sent by the NoDo-device, you can manually try to send it to the original url: https://developerservices.windowsphone.com/Services/WindowsPhoneRegistration.svc/01/2010. Now grab the response. That will be the second step. Having the request and response may already provide very useful information and help us further.
I think the chance of getting your device re-locked is small. But only someone who is doesn't matter restoring a backup or older firmware in order to re-unlock should try this. If someone feels like testing this, we may get a start on unlocking NoDo.
Ciao,
Heathcliff74
I'm just guessing here, I haven't actually done any research into it, but I believe the patch was relating to the certificate - aimed at the fact that ChevronWP7 relied on WP7 accepting an untrusted certificate being used by the unlocking server if that certificate had been installed to the phone's store. Simply doing some basic checking on the certificate to ensure it's from a trusted authority for example, is probably the route Microsoft took, or something along those lines.
I'm kinda busy with other things right now, but I'll have to get a copy of a NoDo ROM at some point and take a peak at the relevant files.
Another possibility is to hide a registry editor in some app and submit it to the marketplace. But soon or later they will notice the trick.
Pretty convenient the LG devices with their integrated registry editor...
The odds of being able to sneak any app with the InteropServices capability into the marketplace is pretty low, I think. Without that capability, you can't access COM, which means no native code, which means no registry editing.
GoodDayToDie said:
The odds of being able to sneak any app with the InteropServices capability into the marketplace is pretty low, I think. Without that capability, you can't access COM, which means no native code, which means no registry editing.
Click to expand...
Click to collapse
I am just guessing here, but can't you download a dll file to the isolatedStorage, then on the next app start use that file (for example the samsung dll to edit registry keys used by samsung "root" tools)?
hounsell said:
I'm just guessing here, I haven't actually done any research into it, but I believe the patch was relating to the certificate - aimed at the fact that ChevronWP7 relied on WP7 accepting an untrusted certificate being used by the unlocking server if that certificate had been installed to the phone's store. Simply doing some basic checking on the certificate to ensure it's from a trusted authority for example, is probably the route Microsoft took, or something along those lines.
I'm kinda busy with other things right now, but I'll have to get a copy of a NoDo ROM at some point and take a peak at the relevant files.
Click to expand...
Click to collapse
Ok.. Think with me please.. I am by no means a HTTP or SSL expert, but I know a little bit about it. So please correct me if I'm wrong.
HTTPS is HTTP over SSL. SSL does a handshake for encryption keys. Any HttpListener will support this. And SSL with mutual authentication will also do a certificate check. Tom, if what you said is true, then we should install a genuine certificate for developerservices.windowsphone.com. I'm sure some devs have one laying around for us to use. The phone will accept it, because a certified authority has issued it. That would solve things at the end of the WP7 device.
Now the important part. As far as I know, but I may very well be wrong about this, the certificate is only verified on the end of the server. In this case that would be our own HttpListener on the local PC with the hosts-file containing a mapping for developerservices.windowsphone.com to 127.0.0.1. I think the WP7 device does not validate the server, isn't it? So when we let our server accept the certificate, we're done. We can let it accept the certificate with this line of code:
Code:
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
Would that do the trick???
Ciao,
Heathcliff74
eried said:
I am just guessing here, but can't you download a dll file to the isolatedStorage, then on the next app start use that file (for example the samsung dll to edit registry keys used by samsung "root" tools)?
Click to expand...
Click to collapse
I'm guessing now. But I think the capabilities are stored somewhere. And if you didn't have the Interop-capability when you installed the app, you will still not be able to load a COM-dll later on. Also, I don't think you will be able to call LoadLibrary on a file in the IsolatedStorage.
And in my WP7 Root Tools, there are NO Samsung dll's. Only my own code. Both native and managed dll's are written 100% by me. No copyrighted dll's from another party in my code. I explicitly avoided that, because my app will never be banned for that reason. I think Julien Schapman's Windows Phone Device Manager does ship the HTC dll's (not 100% sure about that though). I think he might have a problem with that if he ever want to sell his product.
Ciao,
Heathcliff74
Heathcliff74 said:
Now the important part. As far as I know, but I may very well be wrong about this, the certificate is only verified on the end of the server. In this case that would be our own HttpListener on the local PC with the hosts-file containing a mapping for developerservices.windowsphone.com to 127.0.0.1. I think the WP7 device does not validate the server, isn't it? So when we let our server accept the certificate, we're done. We can let it accept the certificate with this line of code:
Code:
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
Would that do the trick???
Ciao,
Heathcliff74
Click to expand...
Click to collapse
Just a guess here, but I would say that it's the phone who verify the certificate, not the server. That's why you had to install the chevron cert on the phone.
Im not up to date on how these certificates work and where or how they are approved and if there is a difference between certain certs but i was wondering about the cert that we used by xboxmod when he released those omnia apps for all devices or was that just another way to get xaps to work instead of resigning them? Could it be used if not?
I did a bit of reading up on SSL and certificates. I'm still not sure about alot of things, but this is what I get from it:
SSL sets up a secure transport layer by exchanging encryption-keys. And it also supports client-authentication and server-authentication. Authentication can take place by letting one party send its certificate and let the other verify it. For a client this usually means that the issuing party sent a generated certificate against which it can be authenticated. A server is authenticated by its certificate. The certificate needs to be verified. The verification is done by checking the certification-path. The issuers must be trusted by the verifying device. I'm not sure, but I don't think it is normally necessary to install a certificate when you genuine unlock your device. If it is necessary, then that means that the unlock server from Microsoft does client-authentication too. But that is not important when we want to spoof that server with a http-server on our localhost (like ChevronWP7), because we can just skip the client-authentication. We simply don't care about that.
(nico) said:
Just a guess here, but I would say that it's the phone who verify the certificate, not the server. That's why you had to install the chevron cert on the phone.
Click to expand...
Click to collapse
I think the unlocking software on the WP7 device probably does something like this (pseudo-code):
Code:
if (!SecureConnection.Server.IsTrusted())
{
LockDevice();
return;
}
If the server is not trusted, the unlock will fail. So Chevron has its own built-in http-server. With its own certificate. Except that certificate is normally not trusted by the WP7 device, because that certificate is not signed/issued by one of the Certified Authorities that is known by the device. So in order to let the IsTrusted() succeed, a certificate must be installed on the device first. That certificate adds the signing authority (self-signed by Chevron) to the trusted authorities.
Now in NoDo, if Tom is right, Microsoft changed it into something like this:
Code:
if (!SecureConnection.Server.IsTrustedByCertifiedAutority())
{
LockDevice();
return;
}
That means, that it does not only verify if it is trusted, but the top of the certification-path must be a Certified Authority. In this case a self-signed certificate is not accepted anymore.
I have access to the certificate-stores on my Samsung Omnia 7. But for that the device needs to be unlocked. So, that is not useful for unlocking devices. And that exploit only works on Samsung devices.
Now that I understand this better, I see that my previous proposal won't work. But it gives me something to think about. Got to get a way around that.
lucasryan said:
Im not up to date on how these certificates work and where or how they are approved and if there is a difference between certain certs but i was wondering about the cert that we used by xboxmod when he released those omnia apps for all devices. Was that a cert that just allowed us to use those apps to work on other devices just like we do now by resigning a xap to work from another brand, or is it a cert that might could be used?
Click to expand...
Click to collapse
That was some developer-certificate from the WinMo 6.5 SDK or something. It didn't really do anything other than invalidating the signature, which in combination with removal of the DRM file in the XAP would remove the DRM-protection. It works even better to simply remove the certificate from the file. The certificate was simply to replace the valid certificate with an invalid one. The certificate from xboxmod is not of any use here.
Ciao,
Heathcliff74
ok I understand now how they work and what it needs to be. Alot more to it than i was thinking, so there is a chance to find a cert somewhere. somehow.
Very good information, I am not too much into SSL security also. I have an Idea for a new unlocker (not based in chevron's method):
Someone in a Marketplace-enabled country buys a subscription
An application uses that subscription + the code inside the Developer unlock application to unlock a phone
Then the same application deploys (and executes) a xap (like samsung tools) to prevent the device relocking
The same application then deletes the device from the developer account
So, with a minor cost, we can have unlocked phones. I don't know if the dev account can get blocked if the user unlocks and "relocks" a lot of devices, but if one account is good for 10 phones, its fine ($10 usd each unlock)
lucasryan said:
ok I understand now how they work and what it needs to be. Alot more to it than i was thinking, so there is a chance to find a cert somewhere. somehow.
Click to expand...
Click to collapse
No. These are the best kept secrets in the industry. When those key leak a lot of DRM is compromised. And in most systems certificates, once compromised, can be revoked (through updates that are pushed or pulled). The ChevronWP7 guys did a brilliant job in finding the loophole in the server-authentication. I think Microsoft has closed that one now. But maybe there's another loophole in the unlocking system.
There might also be other attack-vectors. If we can get XML-provisioning working from outside the device we can set the registry-values to unlock the device. Maybe OTA Provisioning can be done with WP7 devices.
Another possibility for XML provisioning can be found in this dll:
Code:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.DeviceConnectivity.Interop.10.0\v4 .0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DeviceConnectivity.Interop.10.0.dll
You can open it in Reflector. There's a class called DevicePackageClass. It has a method called ProvisionDeviceXML(). So I tried using it, but when I instantiate the DevicePackageClass it gives me an error:
Retrieving the COM class factory for component with CLSID {E987B9DE-8471-11DB-96A9-00E08161165F} failed due to the following error: 80040154 Class not registered (REGDB_E_CLASSNOTREG)
The class is actually a wrapper for a COM class. So I looked it up in the registry. It seemed to be found in this dll:
Code:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\dip.dll (VSD Device Integration Package)
But is actually part of Visual Studio 2008, not Visual Studio 2010. The dip.dll is not installed with Visual Studio 2010. So I figured I might have a better chance with this dll:
Code:
C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.DeviceConnectivity.Interop.9.0\9.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.DeviceConnectivity.Interop.9.0.dll
But it gives me the same error. I also tried to register dip.dll with regsvr32. The registration worked, but the error was still the same. I even tried to access dip.dll directly, but I still couldn't create the COM class DevicePackageClass ("Can't create object").
So if we can somehow instantiate that class we might get XML provisioning working and unlock the device directly in the registry. Needs more research.
Ciao,
Heathcliff74
eried said:
Very good information, I am not too much into SSL security also. I have an Idea for a new unlocker (not based in chevron's method):
Someone in a Marketplace-enabled country buys a subscription
An application uses that subscription + the code inside the Developer unlock application to unlock a phone
Then the same application deploys (and executes) a xap (like samsung tools) to prevent the device relocking
The same application then deletes the device from the developer account
So, with a minor cost, we can have unlocked phones. I don't know if the dev account can get blocked if the user unlocks and "relocks" a lot of devices, but if one account is good for 10 phones, its fine ($10 usd each unlock)
Click to expand...
Click to collapse
Microsoft scans the apps that are submitted for the marketplace. I doubt very much this will ever pass through. And if it will Microsoft will block it as soon as they find out. And it also needs the InteropService capability, which will never be allowed in the Marketplace.
Heathcliff74 said:
Microsoft scans the apps that are submitted for the marketplace. I doubt very much this will ever pass through. And if it will Microsoft will block it as soon as they find out. And it also needs the InteropService capability, which will never be allowed in the Marketplace.
Click to expand...
Click to collapse
My idea was not an app for the marketplace but a desktop app like Chevron
eried said:
My idea was not an app for the marketplace but a desktop app like Chevron
Click to expand...
Click to collapse
Ohw. Sorry. Misunderstood. I get what you meant. But you're gonna need new dev-accounts all the time. Everytime Microsoft will block one dev-account after a certain amount of unlocks, you'll have to get a new one. Who is willing to get all these accounts? This will probably run out very fast.
Heathcliff74 said:
Ohw. Sorry. Misunderstood. I get what you meant. But you're gonna need new dev-accounts all the time. Everytime Microsoft will block one dev-account after a certain amount of unlocks, you'll have to get a new one. Who is willing to get all these accounts? This will probably run out very fast.
Click to expand...
Click to collapse
Of course, but I personally don't have a problem about paying $10-$40 usd to unlock my device. Even $100-$200 seems fair to me for the complete developer account, but I can't pay here in Chile
eried said:
Of course, but I personally don't have a problem about paying $10-$40 usd to unlock my device. Even $100-$200 seems fair to me for the complete developer account, but I can't pay here in Chile
Click to expand...
Click to collapse
Personally I don't like the idea, that I just bought a device of €550 and I have to pay another €100 to actually be able to have control over the device. I also needed to put in countless hours of work to get access to my system and to be able to set the colordepth for instance.
To be real honest, I really don't like the locked-down nature of the device. I liked Microsoft for their open systems (not open source, but highly customizable etc). And I also highly appreciate their developer tools and SDKs. And I love Silverlight. But if I would have known that the phone was so much locked down, I may have considered a Samsung Galaxy S instead of Samsung Omnia 7. Both great phones with super AMOLED etc. WP7 looks much better than Android, but Android is an open OS, which I would prefer. I think Microsoft should have made 2 flavors of WP7; one locked down version for the privacy-freaks and an open version for the tweakers. Anyway, I have the Omnia 7 now with WP7. And I will get it open, even if I have to break it open myself.
Heathcliff74 said:
Personally I don't like the idea, that I just bought a device of €550 and I have to pay another €100 to actually be able to have control over the device. I also needed to put in countless hours of work to get access to my system and to be able to set the colordepth for instance.
To be real honest, I really don't like the locked-down nature of the device. I liked Microsoft for their open systems (not open source, but highly customizable etc). And I also highly appreciate their developer tools and SDKs. And I love Silverlight. But if I would have known that the phone was so much locked down, I may have considered a Samsung Galaxy S instead of Samsung Omnia 7. Both great phones with super AMOLED etc. WP7 looks much better than Android, but Android is an open OS, which I would prefer. I think Microsoft should have made 2 flavors of WP7; one locked down version for the privacy-freaks and an open version for the tweakers. Anyway, I have the Omnia 7 now with WP7. And I will get it open, even if I have to break it open myself.
Click to expand...
Click to collapse
Nobody likes a locked device.
But I do understand the Microsoft posture about this.
As I briefly posted on my blog Monday, Mango will no longer support the deployment of XAPs containing the ID_CAP_INTEROPSERVICES flag. This means you won't be able to deploy your web servers, root tools, and other assorted unsupported hackery.
With our sanctioned, dirt cheap unlock service around the corner, trying to jailbreak NoDo (without upgrade hacks) is a waste of time. I believe the ROI on time spent on hacking this interop limitation is much greater.
This limitation is implemented in PacmanInstaller.exe (on the phone); it scans the manifest for the flag and bails with HRESULT 0x81030120.
As Mango FFUs haven't been released yet, I haven't tested upgrade path 'hacks'; worse, this behavior doesn't appear to be reproducible in the emulator limiting current testing to those w/ Mango phones. (That should change in the next few weeks, hopefully.)
I'm interested to see what ideas you guys have!
How does Microsoft even explain this? What's the point in allowing your unlock officially and then blocking the very functionality we unlock devices for?
Maybe this is a temporary problem?
As far as Microsoft is concerned the new Unlock variant is for people who want to develop for their devices but without intention to publish the results to the Marketplace, e.g. people who want to play around with things.
If you're a Nokia Dev today you get the unlock for free - allowing people to access undocumented APIs is not what Microsoft wants to happen but more to make people experiment with the platform and then perhaps publish their work to Marketplace later on - but that would not be able to happen if those experiments used COM-Interop which is not allowed on the Marketplace.
Well, this way, from an end user perspective, unlocking is useful only for piracy. Getting sideloading without extended capabilities is a weird proposition.
Re hacking Mango, I guess people need to get it on their phones somehow to begin with.
In the other thread I requested that everyone who upgrades makes a wireshark log and post it here, so we can tear it apart. I also left some instductions there.
Plz also let know if apps with native code survive the upgrade and if the chevron unlock with prevent relock survives the update.
Ciao,
Heathcliff74
mfw i already found out a possible solution how to bypass this.
>NoDo needed before Mango.
No trolling. Also, cant say it here on xda, then the Microsofties will pick it up and block...
>Trusted people i can tell, sry.
Thanks for sharing this secret, but up to this moment, Ansar way (flashing stock ROM, then using advanced configuration utility to avoid relocking) is the only effective way.
One could write an application for NoDo, for example a ChevronWP7 Homebrew Enabler, that uses native APIs to modify manifests of homebrew applications found on the phone. Then upgrade to Mango.
There are lots of upgrade scenarios but we have to remember -- new phones will only ship with Mango.
yeah lets tell rafael and his ms homies how the people here try to hack mango, so that he can tell ms to fix it before mango released to everyone.
I hope you wont tell a thing in the public @ fiinix, jaxbox, heathcliff
diboze said:
rafael and his ms homies
Click to expand...
Click to collapse
Really? Rafael informs us of an important issue that we should try resolving, and your response is "OMG he's in bed with Microsoft let's ostracize him"? That saddens me.
@arktronic: please...you cant be this naive...
I won't dignify that with a response.
Oh wait...
There seems to be a way ... for current NoDo users. It is similar to what happened going from original 7008 to NoDo ... in terms of unlocking. I will stop there.
I'm curious, is the ID_CAP_INTEROPSERVICES merely a flag that the xap contains native code, or does the executive actually forbid the application from running native code unless the flag's present?
i.e. could we modify the xap to remove this flag, but still run the native code app on the phone?
elyl said:
I'm curious, is the ID_CAP_INTEROPSERVICES merely a flag that the xap contains native code, or does the executive actually forbid the application from running native code unless the flag's present?
i.e. could we modify the xap to remove this flag, but still run the native code app on the phone?
Click to expand...
Click to collapse
The flag must be present.
diboze said:
yeah lets tell rafael and his ms homies how the people here try to hack mango, so that he can tell ms to fix it before mango released to everyone.
I hope you wont tell a thing in the public @ fiinix, jaxbox, heathcliff
Click to expand...
Click to collapse
You're an idiot.
Here are some things to consider then:
Can something be done to the XAPs to allow the flag? Signing? Other XML file modifications that, in turn, would allow the flag to be used?
Can something be done to the system? A registry change perhaps?
Have any new flags been added to Mango that might also allow low-level system access?
It seems more complicated that just the flag.
Homebrew apps or resigned apps (like Scansearch, or HTC apps) won't run, but official manufacturer apps (Scansearch on LG, HTC apps on HTC) run fine.
So it seems to depends on some certificate.
Also, installing an apps then upgrade to Mango keeps the app on the phone, but it won't allow you to launch it (no error, just launch and quit).
(nico) said:
It seems more complicated that just the flag.
Homebrew apps or resigned apps (like Scansearch, or HTC apps) won't run, but official manufacturer apps (Scansearch on LG, HTC apps on HTC) run fine.
So it seems to depends on some certificate.
Also, installing an apps then upgrade to Mango keeps the app on the phone, but it won't allow you to launch it (no error, just launch and quit).
Click to expand...
Click to collapse
Ah, thanks for testing that. So that means installing an application then upgrading won't be as easy as it sounded.
One test would be to sign a XAP and place your root certificate in the CA store (with Heath's toolset).
diboze said:
yeah lets tell rafael and his ms homies how the people here try to hack mango, so that he can tell ms to fix it before mango released to everyone.
I hope you wont tell a thing in the public @ fiinix, jaxbox, heathcliff
Click to expand...
Click to collapse
I too hope everyone will be a selfish bastard and will never get anything done.
Arktronic said:
Here are some things to consider then:
Can something be done to the XAPs to allow the flag? Signing? Other XML file modifications that, in turn, would allow the flag to be used?
Can something be done to the system? A registry change perhaps?
Have any new flags been added to Mango that might also allow low-level system access?
Click to expand...
Click to collapse
I'm trying some things with the package manager. I haven't got anything yet, but I got some ideas I yet have to try. I'm working on flagging an app as "not being sideloaded".
(nico) said:
It seems more complicated that just the flag.
Homebrew apps or resigned apps (like Scansearch, or HTC apps) won't run, but official manufacturer apps (Scansearch on LG, HTC apps on HTC) run fine.
So it seems to depends on some certificate.
Also, installing an apps then upgrade to Mango keeps the app on the phone, but it won't allow you to launch it (no error, just launch and quit).
Click to expand...
Click to collapse
Ok. So it looks like the package-manager doesn't allow the interop-flag for apps with a full install-cycle through side-loading. The flag is probably allowed for upgrades and marketplace-installs (including DRM licenses). And the PolicyEngine (runtime system) requires the dll's to be signed properly or else it will deny interop to native code.
WithinRafael said:
Ah, thanks for testing that. So that means installing an application then upgrading won't be as easy as it sounded.
One test would be to sign a XAP and place your root certificate in the CA store (with Heath's toolset).
Click to expand...
Click to collapse
Please refer to the opening post of this thread. For the purpose of code-signing the certificates in the "Code Integrity" store are used. The certificates in that store would probably need a signing-root in the CA store. The means that you have to create a certificate that has the properties of a "Code Integrity" certificate AND the properties of a "CA" certificate and then add this cert to both "Code Integrity" and "CA" stores. Then use the private key to sign all the dll's.
If you look at the certs in the "Code Integrity" store, then all, except the one used for LPC singing have this:
Key Usage: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing (86)
Enhanced 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)
If you look at the certs in the CA store, then you see that they all have:
Certificate Signing, Off-line CRL Signing, CRL Signing (06)
That means that you have to create a cert with:
Key Usage: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing (86)
Enhanced 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)
Than add this to "Code Integrity" and "CA".
You have to create the cert with OpenSSL. You can't create such a cert with Visual Studio tools.
I already created such a cert. I will create a new version of the WP7 Root Tools and sign the dll's with this cert. And I will make an option to install/uninstall the public cert in "Code Intergrity" and "CA". I advise everyone who wants to try this to first make a backup! Then, when you have this version of the WP7 Root Tools installed and you used it to install the certificates too, then you should try to upgrade to Mango and see if the WP7 Root Tools are still working.
I will let you know when I got this new version of the WP7 Root Tools ready.
Ciao,
Heathlciff74
Hello everybody,
I got a WP7 Samsung Focus and I want to port my old application to this device and join native forces for WP7
My plan is simple: I'll convert my app into a dll, rewrite new gui in C# (or whatever the way to do it on WP7). I saw multiple posts about calling native code (original from Cris Walsh: http://goo.gl/2Tjks). Then I saw a few posts mentioning that it's impossible etc etc.
So, a few questions:
0) can I do it for my app (I don't need marketplace exams etc, I don't care for that)? I know that some WinAPI could be unavailable/broken, all I ask at this point if it's possible to load and run native dll without changing or re-flashing ROM.
1) ms wants 100$ out of my pocket to be able to deploy to my own device (WTF?!). What can I do to deploy to my phone without paying the crooks? (VS2010 tell me to register there and registration askes for 100$).
2) Is there a sample project I could D/L and run, I have zero experience in C# and I have no idea how to load and call native DLL from managed code in WP7? All these half broken samples are totally useless to me, I simply wanted to working HelloWorld app that loads and runs simple dll.
thanks
0) Yes, what you describe is possible. There are lots of limits, though - WP7 applications have very low permissions, and calling native code doesn't fix that. Unless you need to edit something outside the app's own iolated storage, though, you're probably OK.
1) Aside from the official marketplace account ($100), there are a few options:
a) if you've got an LG phone, they come with a built-in registry editor that can be used to dev-unlock your phone. I forget the exact key you need, though.
b) if you've got a student email address (ends in .edu) you can try registering through DreamSpark. This is free.
c) if you don't mind rolling back to pre-NoDo (7004 or 7008) you can use ChevronWP7 Unlock (instructions available on this forum). If you don't have a restore point that far back you can flash an official ROM for that version.
d) if you don't mind waiting, ChevronWP7 Labs will be available at some point (no ETA that I've seen, but it's been talked about for months) and will provide dev-unlock (but not marketplace account) for a nominal fee.
2) There are lots of apps distributed with source, and most of them will use some native code. You could do a search on this forum for subject lines including the tag "[SOURCE]" and find several (I release source for all my apps). However, I suspect what you'd find most useful is Heathcliff74's guide to WP7 apps that use native code, which is on this forum at http://forum.xda-developers.com/showthread.php?t=1299134. It includes step-by-step instructions.
Hope that helps! I look forward to seeing your app. Also, don't hesitate to ask for help with the actual development; I suck at GUIs and Silverlight but am fairly proficient at C# if you need somebody who knows that language, for example.
There is an ETA for the new ChevronWP7 unlocker:only a few weeks away from launch!
Hi GoodDayToDie
GoodDayToDie said:
0) Yes, what you describe is possible. There are lots of limits, though - WP7 applications have very low permissions, and calling native code doesn't fix that. Unless you need to edit something outside the app's own iolated storage, though, you're probably OK.
Click to expand...
Click to collapse
At this point I want to make a DLL from my simple app and call a few functions that interact with filesystem and network. FS is needed only for simple stuff (loading config file etc) from installation folder and creating some temporary files for local storage. Network is tcp/udp, I guess network should be available.
GoodDayToDie said:
1) Aside from the official marketplace account ($100), there are a few options:
...
Click to expand...
Click to collapse
I did some search, it seem that I've done that part. Chevron dev unlock was pulled out from their site, but the old version remains scattered all over the board. There is a good thread a good thread on how to do it. It happens that my phone is 7004. Where can I get old ROM in case if something goes bad and I need to re-flash? Is it easy, am I risking to brick and loose my phone?
I just tried to run sample phone app and it runs on the phone. Initially it said that it was revoked by MS, I run dev-unlock one more time and now it works.
GoodDayToDie said:
2) There are lots of apps distributed with source, and most of them will use some native code. You could do a search on this forum for subject lines including the tag "[SOURCE]" and find several (I release source for all my apps). However, I suspect what you'd find most useful is Heathcliff74's guide to WP7 apps that use native code, which is on this forum at http://forum.xda-developers.com/showthread.php?t=1299134. It includes step-by-step instructions.
Click to expand...
Click to collapse
I'll try to search, hope I'll be up and running soon. Too bad WP7 is DOA. They always had much better tools than all these ghetto Symbian/Android/Xcode crapware tools... WTF is wrong with these guys, at the point when they were surpassed at speed of light by newbies iPhone and Android they made some backward steps to cut off most of the devs (but they added all these 500K Silverlight newbie devs...). I'm so disappointed with Android, seems like they hired all these retards who were fired at symbian: same **** tools
I downloaded a few samples and it seems that all of them contain prebuild dll's and all of them are COM dlls or something like that.
What I'd like to find is simple sample that contains src code to native WinMo dll and C# project that it uses.
As far as I know native dll cannot be build with latest tools (am I right?), but I can use cegcc or VS2008 to build native DLL's.
stuff like:
Code:
if (ComBridge.RegisterComDll("ComFileRw.dll", new Guid("EEA7F43B-A32D-4767-9AE7-9E53DA197455")) != 0)
is totally unknown to me. I would really like to avoid to even elarning anything about COM related stuff. I prefer not to mess up with code that isn't portable.
HI mtlgui,
unless Heathcliff finishes his WP7 Root Tools SDK, you don't have any other way to access native c++ code besides using COM. DFT (The DarkForcesTeam) released a firmware loader, that allows you to flash customized unsigned firmware. They were also able to do some native c++ coding with the WM API. However the used firmware for that is not public and it is limited to HTC devices.
Did you already consider to write your application in c#? Mango has now TCP/UDP socket support for outgoing connections. Incoming connections or services running on the phone aren't possible without using native code, at least for the moment.
Hi rudelm,
if the only way to use native is to build COM dll, then I'm OK with that. My app code is old and I'd rather throw my WP7 device to trash can than trying to rewrite my app in C#.
Eventually, down the road while hacking maybe I'll learn c# well enough to do anything with it other than GUI and calling native/COM dlls.
So, just to confirm my understanding. I need to write COM dlls that access native API (socket, filesystem, wavein/waveout etc) and then load these COM dlls and call their functions from C# (or whatever is the closest lang to c/c++ in the WP7 world).
@mtlgui:
You've pretty much got it. A few thoughts, though:
There is a webserver project available on this site. It includes source for its C++ native component (the library is called NativeIO; I can probably send you the source if you can't find it). It exposes registry, filesystem, and TCP server and client sockets to COM. Note that because this library was built for pre-Mango phones, just compiling it and shipping it may not work on Mango phones as many deprecated libraries were removed in Mango and if the DLL contains any references to them, it won't load.
Generally speaking, what you're asking for with TCP/UDP is possible, though you may have to code against the winsock API directly. It sounds like you're doing as little as possible with C#, so even if the Socket API that is available with Mango were sufficient for your app's needs, you wouldn't be using it.
Filesystem access... even if you have read access to your app's install folder (I haven't checked, though you should), you almost certainly won't have write access. Each app does have a writable "isolated storage" though, under \Applications\Data\{GUID}\Data\IsolatedStore\. I've only ever tried writing to it using C# though, so I don't know for sure if it's writable using the native APIs directly (should be, though).
It's probably perfectly OK to write your app as one big native DLL (hell, it *might* work to just change the build type from Application to Library, then rename main() or something like that). You will need to expose the library to COM, but that's easy. You can then write a very simple C#/Silverlight app (see Heathcliff's instructions, or just post the COM interface and soembody could write it for you). All the C# app needs to do is use ComBridge to access the native DLL, and call a "run()" function or something similarly simple.
For what it's worth, C# is very close to a superset of C++, at least on the desktop. The phone version is crippled a little by not allowing the use of pointers - everything has to be done with strongly-typed references instead, which can make network code a little annoying but is otherwise rarely a problem - but with a little experimentation you may find your disdain for C# to be misguided. It's a useful language to know it today's job market, if nothing else.
Why is your phone still on 7004? That's the launch retail build, something like eight months out of date. On the plus side, this means that things like ChevronWP7 Unlocker still work for you, as you found. On the minu side, it means you're putting up with bugs and missing features that you needn't be. Have you tried updating at all? If/when you do update, make sure to back up the restore points that the Zune software generates (they got in %localappdata%\Microsoft\Windows Phone Update\). That way, if you ever need to roll back to 7004, you can do it. Normally, only the most recent restore point is kept.
Flashing ROMs is safe so long as you don't try something like flashing the wrong one for your device. Unless your bootloader is unlocked (only possible on HTC), you can only flash official ROMs anyhow, which saves you from most of the risks. On the other hand, you're already on as old a ROM as you will find, and so long as you keep your restore points, you can return to it any time you want to, easily.
I'm googling now the board to find NativeIO and that webserver app. So far only references to it, but no src code.
I'm ok with isolated read/write access. All I care is persistent fs storage.
My phone is still 7004 because I just bought it so I can do some WP7 development. I don't want to mess up with updates at the moment.
As I understand from another post ComBridge is C#->COM->native c++ dll or any other dll that can be used, right? I'm just learning some COM to learn enough to start actually programming for the phone. I see that I can pass whatever data I want, but I don't seem to be able to see a way to register callbacks so that native/COM could call back to C#
mtlgui said:
I'm googling now the board to find NativeIO and that webserver app. So far only references to it, but no src code.
I'm ok with isolated read/write access. All I care is persistent fs storage.
My phone is still 7004 because I just bought it so I can do some WP7 development. I don't want to mess up with updates at the moment.
As I understand from another post ComBridge is C#->COM->native c++ dll or any other dll that can be used, right? I'm just learning some COM to learn enough to start actually programming for the phone. I see that I can pass whatever data I want, but I don't seem to be able to see a way to register callbacks so that native/COM could call back to C#
Click to expand...
Click to collapse
Basic introduction to native code and COM, including references to more background info: http://forum.xda-developers.com/showthread.php?t=1299134.
Callback from C++ -> COM -> C# can be done. Decompile the WP7 Acrobat Reader app. You'll see how it works.
Ciao,
Heathcliff74
As it is known that HTCUtility.dll will provide complete, unrestricted access to the TCB chamber on HTC devices, can this be used to unlock (at any level) the OS?
I have not heard anyone speaking of it and exists on my HTC Arrive. Seems to be a bypass for unrestricted access to anything within HTC devices.
I am looking at it myself, but thought I would share.
See details here...
http://labs.mwrinfosecurity.com/files/Advisories/mwri_htc-htcutility-kernmem_2011-11-10.pdf
Your link is down
very interesting but you link is down so please fix it so I can take a look. I too have a HTC arrive and have been working on an unlock.
Don't know what happened to the link.
Here is the link to the google docs version.
https://docs.google.com/viewer?a=v&...1C1HkN&sig=AHIEtbTwK-r8RyAyFmt1ai119m7EVAqsNA
-Paul
This looks promising, I'd like to know if what's written there is true ...
The paper is a couple months old, so it *could* have been patched by HTC... but hey, it also might not have been! This bears investigation post-haste.
It's easy enough to use this to execute some arbitrary code at high permissions, which is certainly useful as-is (do things like unrestricted registry and filesystem access). The real potential of it, though, is to turn off the security restrictions for specific apps. Essentially, get the benefits of a "fully unlocked" ROM but on a stock ROM, and only for the apps you specify.
One thing to note here: this is still going to require an interop-unlocked phone. It's opening a handle to a driver, and just like everything else that does so, it needs ID_CAP_INTEROPSERVICES. This is great news for owners of interop-unlocked/unlockabe phones (since this makes interop-unlock useful again) but probably doesn't help on 2nd-gen phones or on the Arrive (unless you want to roll back to NoDo, in which case this can probably be used to make an interop-unlock that works on Mango, though it wouldn't be easy).
I hope some one gets this working for the Arrive ASAP
Oh this was talked about a while back. It was patched back in NODO
Really? The paper is from only 3 months ago (assuming USA numeric date style, 2 months otherwise). You don't typically publish security advisories for things that were patched more than 6 months prior.
In any case, HTCUtility.dll still exists on my phone. No idea yet if that IOCTL still works, though. I'll try it out in any case, and report back.
For those asking about it for the Arrive though, you're likely out of luck even if this works. It is *not* a way to interop-unlock a phone, and it is *not* a way around interop-unlock. It's a way to do more things on an interop-unlocked phone. You can't even reach a driver (which is what HTCUtility.dll is) unless your app has ID_CAP_INTEROPSERVICES - that's what the capability is actually for, accessing drivers - and you can't install a homebrew app with that capability unless interop-unlocked (or on pre-Mango).
GoodDayToDie said:
I'll try it out in any case, and report back.
Click to expand...
Click to collapse
Thank you
GoodDayToDie said:
Really? The paper is from only 3 months ago (assuming USA numeric date style, 2 months otherwise). You don't typically publish security advisories for things that were patched more than 6 months prior.
In any case, HTCUtility.dll still exists on my phone. No idea yet if that IOCTL still works, though. I'll try it out in any case, and report back.
For those asking about it for the Arrive though, you're likely out of luck even if this works. It is *not* a way to interop-unlock a phone, and it is *not* a way around interop-unlock. It's a way to do more things on an interop-unlocked phone. You can't even reach a driver (which is what HTCUtility.dll is) unless your app has ID_CAP_INTEROPSERVICES - that's what the capability is actually for, accessing drivers - and you can't install a homebrew app with that capability unless interop-unlocked (or on pre-Mango).
Click to expand...
Click to collapse
Yeah I think it was mentioned here on XDA and it was believed to already have been patched.
I think by "patch" they mean that Interop was restricted as of Mango, thereby securing this exploit, in Mango. But for those that are Interop unlocked, this should still grant full access to everything else.
Just my observations. I have an Arrive and am not Interop unlocked yet, so I can't test it.
Looking at the hand-free provisioning to see if I can find a way to leverage that....
-Paul
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
GoodDayToDie said:
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
Click to expand...
Click to collapse
All the information looks like it is in the advisory. KDataStruct is what you want. That is equivalent to the PEB in Windows CE.
GoodDayToDie said:
It works. I successfully opened a handle, read a kernel-mode memory address, modified it, confirmed the modified value, and restored it.
Next trick: finding something really useful to change. Ideally, probably the process security info - if I can simply elevate a given process to full permissions, then I'm golden.
Will share code soon. If somebody knows where I can find the important part of the process info, let me know - I have a little familiarity with NT process contet blocks, but none with CE ones (if it even uses such a structure).
Click to expand...
Click to collapse
Can you confirm this works only on already Interop Unlocked device ?
Thx for your efforts.
Could htclv.dll be helpful in setting security on an app? It supports the following functions:
LVModInitialize LVModUninitialize LVModAuthenticateFile LVModRouting LVModAuthorize LVModGetPageHashData LVModCloseAuthenticationHandle LVModGetHash LVModProvisionSecurityForApplication LVModDeprovisionSecurityForApplication LVModGetSignerCertificateThumbprint LVModSetDeveloperUnlockState LVModAuthorizeVolatileCertificate LVModGetDeveloperUnlockState
In particular the "Deprovision Security for App" and "Get/set DeveloperUnlock" or maybe "Authorize Volatile Certificate"....
Or maybe htcpl.dll which seems to be the HTC policy engine interface. Supports:
GetFunctionTable PolicyCloseHandle PolicyEngineInit PolicyRuleAbortTransaction PolicyRuleAddRawData PolicyRuleBeginTransaction PolicyRuleBuildRawData PolicyRuleCommit PolicyRuleCommitTransaction PolicyRuleCreate PolicyRuleDelete PolicyRuleFindFirst PolicyRuleFindNext PolicyRuleGetInfo PolicyRuleOpen PolicyRuleParseRawData PolicyRuleReadRawData
These all look good to modify the security policies on HTC, assuming Interop-Unlocked.
-Paul
@dragonide: Confirmed, this requires interop-unlock since the very first step is opening a handle to a driver.
@Paul_Hammons: The LVMod functions look quite interesting indeed. Where are you getting these functions from (straight out of the DLLs, or some doc somewhere, or decompiled code, or...?), are they user or kernel entry points, and what permissions do they require? The ability to modify app security doesn't do as much good if you already have to be high-privileged to call it, though it might simplify my current goal.
@n0psl3d: Cool, I'll get to work on it.
@n0psl3d: KDataStruct contains kernel information, but I'm pretty sure what I need is in a PROCESS struct (such as is pointed to by pCurPrc). The problem is, I can't find any documentation for that struct. I'm searching online but so far coming up empty. CE doesn't seem to use PEBs or TEBs as I've seen them on NT (not terribly surprising, but annoying).
EDIT: I'm downloading the Embedded CE toolkit, which comes with source code. It'll take a while but hopefully that will have what I need.
OK, digging through the CE source I've found some interesting things. No idea if this will work yet; it'll be exciting just to make it compile.
PROCESS struct -> hTok (handle to a Token) -> phd (PHDATA, pointer to the handle data) -> pvObj (PVOID to the actual object, which is probably a TOKENINFO) -> psi (pointer to ADBI_SECURITY_INFO) -> contains the actual ACLs and privileges, and can be created from an account ID.
Probably the easiest option is to find a relatively high-privilege process and clone its token or some such. Token re-use (if I increment the reference count, this should work) may be easier. Modifying an existing token might also be doable.
Anyhow, I'm not going to have this finished tonight, but it'll get there. For those wondering wht you can do with this, it basically breaks you out of the sandbox entirely. You can call any function, access any resource, etc. that is available to a userland process (executing in kernel mode is also possible but trickier). Practically speaking, this makes all the other high-privilege COM DLLs useless - instead of ComFileRW, just use the file IO methods (anywhere you want), instead of DMXMLCOM just call ConfigProvXml directly. Even things like launching native EXEs directly should become possible (run those Opera ports on a stock ROM, for example).
I'm sorry, I still don't know what any of that means. But it sounds good! I wish I knew how to do this kind of stuff. Thanks for all of your work!