yashsingh1/xdaforums huggingface dataset:
[Windows Phone 7 Development and Hacking] Heathcliff74:
I see. Well, I didn't find a solution. I just checked if MY exploit still works. And it does! I don't even know what you use exactly (I assume you use some HTC DLL's, but I don't know which and I don't know which functions). I don't use the HTC DLL's myself. Mainly because I don't want to get copyright issues when releasing WP7 Root Tools. Just look at the current release of WP7 Root Tools. No OEM code in there. So I don't think I can fix that for you.

Ciao,

Heathcliff74
[Windows Phone 7 Development and Hacking] rudelm:
Hm ok, I understand. I was using a HTC dll for changing a registry value (overriding DHCP DNS Server). However, it is interesting to know why the HTC DLLs all of sudden stopped working after this update. The DLLs inside the HTC tools seem to be the same size and should not be changed by the update.

But this shouldn't then influence the DLL made with your instructions in this thread i guess?
[Windows Phone 7 Development and Hacking] contable:
@rudelm:

The HTC devices have HSPL support, so why you don´t flash the latest xboxmod rom ? This saves a lot of time and all available types of unlocking can be sent via cab sender.

For writing registry keys or doing file operations you can use DiagProvXML til Heathcliff has finished the next version of WP7 Root Tools.

Is there any other reason why you are updating your phone the official way ?
[Windows Phone 7 Development and Hacking] GoodDayToDie:
@rudelm: The HTC DLLs don't actually have elevated permissions by themselves. To do things that an app n ormally lacks permissions for (like accessing the whole filesystem or writing to the registry), it needs to call into a high-permission component (probably a driver or a high-permission process). All HTC had to do to make the registry and filesystem COM DLLs stop working is to change that component so it didn't do what the COM DLLs told it to do.

@contable: I've heard enough reports of things that *should* work on HTC phones not working on the custom ROMs that I'm hesitant to install one. Then there's the risk of bootloader issues. Then there's the lose-all-your-data-because-your-phone-gets-reformatted issue - until I have my backup app working fully, I prefer to avoid the last one in particular.
[Windows Phone 7 Development and Hacking] rudelm:
Edit: If you are looking for working attachments, please look at this posting.

@contable:

I need an unmodified version of WP7 for my master thesis. The other thing is that I don't want to play around with HSPL without having the original SPL or firmware. It's like GoodDayToDie said: I'm still hesitating of the said reasons.

@GoodDayToDie:

The HTC applications still work and they were not updated afaik. So they are using the same DLL files. If there would be some driver running in TCB or ECB and they changed something, then their applications should stop working too. However, they can still be executed without problems. I am not sure what DLLs are used by advancedexplorer, but I think it were also the HTC dlls. My own application which used the HTC dlls stopped also.

@Heathcliff:

I've tried your instructions and found some errors in it:

step 23: *OutpuString = SysAllocString(msg); instead of *OutputString = SysAllocString(msg);

step 25: ; missing after OutputString)

step 28: add \MyApp to path, because VS2010 Solutions always have a subfolder with the same name of the solution

step 36: [return : MarshalAs(UnmanagedType.BSTR)] should be [return : MarshalAs(UnmanagedType.BStr)]

step 37: result 2 needs a type => string result 2 = ...

on first run:

This is because you forgot to register the DLL first. Look here: http://thounsell.co.uk/2010/11/avoi...g-the-interopservices-library-to-the-wp7-sdk/ and then down in the comments:

In addition that, you will have to unblock the file in Windows Explorer, Properties of the file. Otherwise you will get this error in Xaml view:

This unblock will only work, if you use the Windows Explorer in administrator mode. The DLL file should be copied to a path were every user can access the file. Unblock it there and move it than back to the WindowsPhone71 folder. I've extracted it directly to the WindowsPhone71 folder and I couldn't change its properties there.

I've created a VS2008 and VS2010 sample project on your instructions and tried to add some comments to the sources. I've attached them to this post. Here are a few extra information to my project:

Interface-GUID: D28D8CB9-F8BC-4379-9D0A-FA77C87EF814

coclass-GUID: 7300CD4A-03F4-4569-B2D8-F1515385D46D

COM Class: NativeTestClass

INativeTestClass and CNativeTestClass

Always results in retval 0 and this exception:

I've rechecked every step but I am still stuck. The phone itself should be interop unlocked, otherwise I couldn't have deployed the app with the capability activated. Could you please look into it? I know this error from my earlier attempts to access the HTC dll directly, but then I used the NativeLibrary here from XDA which took care of all the GUID things etc.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Thanks for mentioning the typo's and stuff. The guide is a collection of many notes and I made some changes to them as I was writing, to make it more readable. Hence the typo's.

I will update the opening post with your corrections later today. I will also look into your problem then.

Heathcliff74
[Windows Phone 7 Development and Hacking] Heathcliff74:
@rudelm

Take a very close look at the filename in the guide at position 30 (Edit: now position 31, because I inserted an item in the guide). And then look at the filename in your project. :p Change it in the project and the rebuild the solution. Tada! The same exception may occur when you mess around with the COM-registration (files/capabilities/etc). Even when everything is sorted out it may still throw this exception. In that case you should rebuild your solution and it is probably resolved.

There one other thing. The exception is declared as COMException (I also mentioned that in the guide). But in fact it should be declared as regular Exception or UnauthorizedAccessException, because common exception-codes are casted to their corresponding exception-class. In this case a UnauthorizedAccessException.

The unblocking of the DLL in the zip is probably because you used the built-in unzip of Windows. This unzipper has the ridiculous habit of blocking the unzipped files, when it comes from a zip-archive that is blocked, due to the fact that it is downloaded. If you use WinZip/WinRar/etc, it is not necessary to unblock.

I will update the opening post with your and my comments.

Ciao,

Heathcliff74
[Windows Phone 7 Development and Hacking] GoodDayToDie:
A quick comment on removing mark-of-the-web (the "block" mentioned above): if you open the proerties of the ZIP file, and click Unblock (no particular permissions needed for this) prior to unpacking the arcive, the extracted files won't have the mark of the web so you won't need to unblock them too.
[Windows Phone 7 Development and Hacking] Heathcliff74:
Opening post updated with comments of rudelm and GoodDayToDie.
[Windows Phone 7 Development and Hacking] WithinRafael:
Hm, I think it's important to note this only works on phones that have interop service access unlocked. This means only the Focus and LG, right? The rest of the guide is just COM 101 really, nothing changed. But good explanation. :)
[Windows Phone 7 Development and Hacking] Heathcliff74:
No, no, no. As the guide (and my tweet) states, you can use native code without ID_CAP_INTEROPSERVICES and Interop Unlock. ID_CAP_INTEROPSERVICES and Interop Unlock are only necessary when you call drivers, like ::CreateFile("HCO0:", ....); That would return and error 0x04ec if you don't have the interop capability.

Edit: example: Download the attachment "Version and Language by Heathcliff74.xap" from this thread. I used native code without ID_CAP_INTEROPSERVICES.

Edit2: ComBridge.RegisterComDll() has [SecuritySafeCritical], not [SecurityCritical].

Ciao,

Heathcliff74
[Windows Phone 7 Development and Hacking] WithinRafael:
Interesting. I'll try it out. If true, this is a big change from NoDo and previous versions which required the flag.
[Windows Phone 7 Development and Hacking] Heathcliff74:
I don't think this is changed (not sure though). You still do need the WPInteropManifest.xml in order to call COMBridge.RegisterComDll(), but you don't need ID_CAP_INTEROPSERVICES until you call CreateFile() to access a driver.

Ciao,

Heathcliff74
[Windows Phone 7 Development and Hacking] WithinRafael:
Could be that all my work was dealing with drivers, so I just implicitly added it every time. Will try it, as soon as I unfuck my phone. (I used that utility you recommended to restore 3G on my Focus, I think it ****ed with the ProdURLs so when my phone locked... yeah.)

Will try overwriting those entries with Registration tool (SwitchToInt command).
[Windows Phone 7 Development and Hacking] Heathcliff74:
How where you ever able to relock with ProdURLs removed??
[Windows Phone 7 Development and Hacking] mido-mido:
i have a little Q here...could we use this method to make this Native Keyboard for WP7 for mango???i mean the app in this topic...here...

cause u say NATIVE and i just saw some DLL in this method...and i saw some DLL in this app...could we(or i) just make this app for mango????
[Windows Phone 7 Development and Hacking] rudelm:
OMFG, thank you! :eek: WMAppManifext.xml vs WMAppManifest.xml

What a small typo can do is incredible... I had the project then recompiled but that was not enough. I removed it from the phone, rebuild the project and deployed it again and now it works perfectly.

I also added the part on the exception, the project is now runnable and I attached it to this post, so that anyone who wants to try it without going through all these steps can see for themselves.

Guess I will have to rewrite some parts of my thesis with this new information :cool:
[Windows Phone 7 Development and Hacking] Heathcliff74:
The app could probably be made compatible with Mango. It's up to the developer. I'm also working on an SDK, which should make that easier, but it's taking me much longer than I expected. Got to be patient on that one.

Ciao,

Heathcliff74
[Windows Phone 7 Development and Hacking] Heathcliff74:
Well, it took me a while before I saw it too. I saw it when I did a file-compare on a working app and your sources. :)

I'm curious to read your thesis. To be honest, I'm hoping to release the next version of WP7 Root Tools (and SDK) before you finish your thesis, so you can write about that too (delivering more work for you ;)), but I'm really not sure about that.

Ciao,

Heathcliff74
[Windows Phone 7 Development and Hacking] rudelm:
Thanks :) I hope you can do it until the end of October or mid of November. That could be enough time to fully add your root tools ;) For now it's just a reference to your threads and announcements of the coming sdk and root tool for Samsung devices.

But back to this thread and native programming: Am I right to assume that with calling drivers you mean access to the phones hardware resources like networking, file system etc.? At least thats whats CreateFile can do on WM6.5. This language CAB tool of yours can use native DLL without ID_CAP_INTEROPSERVICES, therefore I assume you call only generic methods that don't breach the policies? I am still a noob regarding IDA, native ARM code and especially C++ :( Guess that won't change so fast either until the end of my thesis.

I am looking for some kind of list which methods can be called without the capability, or at least some clue on what I have to look for. SecuritySafeCritical marked code could be called on some assumptions (see the following quote), but SecurityCritical is absolutly no go for the applications without having root access and running in TCB?

taken from here
[Windows Phone 7 Development and Hacking] Heathcliff74:
Usually CreateFile() is used to get access to a driver. Drivers are usually used to get access to hardware, but can serve other purposes too. Drivers run in separate chambers, which have higher privileges. Usually "Elevated" or "TCB". The OEM drivers may have have functions to manipulate the file-system or registry. The interface and possibilities of these functions are defined by the OEM's. If I access these drivers and send commands to the drivers, I might be able to do things that are usually not possible with the restrictions of LPC (sandbox of the Silverlight app). This is what we call a privilege-escape. This type of exploit is the most commonly used exploit in WP7 now.

With native code you can call ANY WP7 API you want. BUT.. as soon as you try to access resources, the policy-engine will check your privileges and see if you have access. If you don't, the policy-engine says: 0x04ec or 0x800704ec or "Blocked by policy" or "F#ck you for trying to hack WP7". So when you call CreateFile() to access the driver, you privileges are checked to see if you are allowed to access those resources. In this case the necessary privileges are defined in the ID_CAP_INTEROPSERVICES capability. If you don't have it, you'll get errorcode 0x800704ec.

Same thing for CopyFile(). You can call it. But if it will succeed, completely depends on the access levels you have on source and destination. All policies are merged into "PolicyCommit.xml" and then Policydb.vol (read here). It is a very comprehensive type of ACL. So there is not a list of API-functions you can use. You can use them all. You should study the policy-definitions to see what access you have.

The exploits I have will put some shortcuts into the policy-system, which will allow selected apps to bypass the policy-definitions. This is what I'm now implementing for the next version of WP7 Root Tools.

SecuritySafeCritical and SecurityCritical tags are something completely different. These are meant for managed code. Basicly, if you're not a .NET core library, you can't call SecurityCritical functions. This will even give you a compile-error. I think at runtime the strong-name-key of the assembly is verified for this, but that is just a guess.

Hope that helps,

Heathcliff74
[Windows Phone 7 Development and Hacking] Nudua:
Just wanted to say thanks for your hard work Heathcliff74, been playing with this for a few days and everything seams to work quite well. The possibilities for new apps have certainly opened up.

Also I wanted to give people an extra warning with using the ID_CAP_INTEROPSERVICES when it's not needed, a lot of us are still stuck on a interop-lock.
[Windows Phone 7 Development and Hacking] snuk182:
Hi Heathcliff74.

Can you please tell, do we have a possibility of background execution of an unmanaged code? I really need a background socket listener...

Thanks in advance!
[Windows Phone 7 Development and Hacking] GoodDayToDie:
@snuk128:

Well, you can use Mango's background agents, but they have limitations and I'm not sure how many of those limitations can be worked around.

Alternatively, you can try using JaxBot's dehydration hack, sometimes referred to as "true multitasking". With a 7.0 app, you can code it to ignore the backgronding event and keep running (remember that this will have an impact on battery life). It might be possible with a 7.1 app too, though I haven't checked.

However, enabling this hack requires a registry edit, which requires raised privilieges, which requires ID_CAP_INTEROPSERVICES, which requires interop-unlock, which is currently difficult to get on an HTC device. So, you risk limiting your audience if you do this.
[Windows Phone 7 Development and Hacking] snuk182:
Wow, if this is really true - it's enough for me to go on with development.

I actually don't believe in MS's stories about amounts of battery draining they scare, think it's just a matter of selling their cloud services.
[Windows Phone 7 Development and Hacking] GoodDayToDie:
It depends on what the app is doing when it's in the background. Puzzle Quest 2, which isn't even a real-time game, is death on your battery if you leave it in the background - since it isn't real-time, there's no need to "pause" when backgrounded, so the XNA update/render cycle keeps running, using the CPU and GPU. The phone will become very warm if left in your pocket, and you can kill a full charge in 4 hours.

On the other hand, if you're using a server socket, and just calling listen() on the main thread (or having the other threads inactive until the main thread gives them work) then the app should use almost no extra battery for CPU time. It will, however, keep the radio on all the time - which definitely will have an impact. I don't know how big an impact, since I don't know exactly how cellular radios work, but it's probably comparable to the difference in battery life between a push email account ("as it arrives") and one that updates on a schedule, even every 15 minutes. You can still get two days of battery life with a couple of push email accounts (and almost no other activity), but you can get a week of battery if you have the same low activity and turn off all "push" services (email, push notifications, IM, etc.) - basically, what Battery Saver does.
[Windows Phone 7 Development and Hacking] snuk182:
Heh, even iphone and android die in hours if UI rendering is not disabled. This is common.

AFAIK, GPRS/HSPA session drains battery only during data transmission, but if socket needs just to keep its connection open, the power consumption is minimal. At least iphone api has constant background socket listener (limited to VOIP data only), which almost have no influence on uptime duration.
[Windows Phone 7 Development and Hacking] rudelm:
Hm normally, WP7 does not allow to open up sockets on the phone so that it can act as a server. However there was one developer here on XDA (sorry, forgot the name) that programmed a server with native code. But my guess, that it won't run unless you will elevate its rights with either Heathcliffs root tools or by using the OEM DLL files.

But it sounds interesting. I was happy to hear, that Mango finally supports sockets but it could only connect to other server and did not allowed incoming connections.
[Windows Phone 7 Development and Hacking] GoodDayToDie:
@rudelm: The entire point of this thread is that you do not need elevated permissions to call native code. Davux's webserver (which may have been built on somebody else's sockets lib, I don't know) would already run on Mango - even interop-locked Mango - if the homebrew native DLL used for the Sockets API was written according to the guidelines Heathcliff74 pointed out in the first post.

Now, the capabilities of that webserver would certainly be limited. For example, you couldn't write to most of the filesystem (unless you had elevated permissions, through something like HTC's ComFileRW.dll or Heathcliff74's WP7 Root Tools, both of which require ID_CAP_INTEROPSERVICES and therefore interop-unlock).

Actually opening the server sockets would be no problem, though; they have no security restrictions. The only reason you can't do Server sockets with the normal Mango SDK, and the only reason you couldn't do sockets at all with the pre-Mango SDK, is quite simply because the phone's .NET framework is missing the required APIs. Thus, write native code to do it, and expost that functionality via a COM API.
[Windows Phone 7 Development and Hacking] rudelm:
@GoodDayToDie:

Yes, I am well aware that I do not need to be elevated to call native code. However, there is always the problem of interop-unlock or the usage of API that can be used without the interop-unlock. You will get stuck either way or another, unless you go and try to circumvent all these restrictions. Thats what I meant with using elevated access.

Where is your information taken from regarding that the sockets do not have security restrictions? That would reduce the whole capability and LPC thing to absurdity. You could actually write an managed C# app, that do not need the networking capability, although you are calling a native DLL over COM that allows networking?
[Windows Phone 7 Development and Hacking] GoodDayToDie:
I don't know if ID_CAP_NETWORKING is or is not required for opening native sockets via COM. I can certainly believe that it is, though. My point about "no security restrictions" though is that using sockets doesn't require using any elevation-of-privilege hacks. The standard application runtime gives all the required permissions. It may not give the APIs, but that's what the native access is for.

I still don't understand what you mean by "[a network server app] won't run unless you will elevate its rights with either Heathcliffs root tools or by using the OEM DLL files". The webserver app used a generic homebrew library that included registry write capability and therefore included the OEM DLLs, but it didn't actually use that functionality and could have worked just fine (and been a smaller download/install) without those DLLs, much less WP7 Root Tools (which didn't even exist at the time).
[Windows Phone 7 Development and Hacking] rudelm:
ok, I'll try to explain:

I think, it is necessary to use ID_CAP_NETWORKING even if we use native sockets over a COM DLL file. Otherwise this whole concept of capabilities and least privilege would be pointless. There are APIs that can be used without ID_CAP_NETWORKING or any other capability, as Heathcliff showed on page 1.

My guess is, that you think we can use the native networking sockets API without special hacks like wp7 root tools, interop-unlock or ID_CAP_INTEROPSERVICES. Did I get this right? :) As I've written: I'm looking for proof that this is possible. To my knowledge, we would need to include ID_CAP_NETWORKING for that to work, even with native code and API methods. Or we need to know what methods are allowed to be called and which not. Heathcliff said, we should take a look at the policies to find out, what is allowed and what not. Guess that would be a good starting point then. I'm just unsure, how to extract them from my phone.

Regarding the network server app: OK, if it uses OEM DLLs and ID_CAP_INTEROPSERVICES just to allow read/write access to registry and filesystem, we could strip that part and restrict it to its IsolatedStorage. That should be no problem and wouldn't interfere with the security policy. This limitation to one folder would be kind of pointless but it would show that native network sockets could be opened without any of the OEM DLLs, ID_CAP_INTEROPSERVICES, ID_CAP_NETWORKING or any native method that is blocked by policy.
[Windows Phone 7 Development and Hacking] GoodDayToDie:
Yes, that's what I'm saying. :) Davux's NoDo webserver didn't actually have high filesystem permissions (he could have gotten them via HTC's ComFileRW.dll, but didn't) so it could read from isostore and \Windows\ only, and could only write to isostore. It did have the registry DLLs, but never used them. If someobdy still has a NoDo phone, you could test whether ID_CAP_NETWORKING is required by removing that from the manifest and then installing it on the NoDo phone and seeing if it works...

It worked as a proof of concept though, and was still a useful way to either transfer files on or off the phone (use another app to move them into/out of the webserver isostore), or just to transfer files between computers (for example, store the driver and instructions for USB tethering in the webserver, then if you have a PC with WiFi but no Internet access, you can copy the tethering files from the phone using the Webserver app, install them on the PC, put the phone in tethering mode, and get the PC online).
[Windows Phone 7 Development and Hacking] mailwl:
just want to mention:

we can develop native dll for WP7-emulator , using Windows Embedded Compact 7, with VirtualPC x86 vm+sdk (and even debug dll's inside VPC vm, but i don't try it yet)
[Windows Phone 7 Development and Hacking] bexp:
print logs

Hi, I wondering whether it's possible to print console logs from native code

(something like Console.WriteLine() in C#) ?
[Windows Phone 7 Development and Hacking] GoodDayToDie:
It takes some work, but yes. Check out the DllImport Project thread; there's a discussion in there of how to send debug messages from native code out.