Webserver (for Mango)
Webserver is now supported for Mango devices!
During NoDo this tool was used much for exploring the "\Windows" directory, but when Mango came none could explore it.
There is probably many new things to find in the new OEM Mangos (that could not be extracted till now (Exception's: ROM dumps))
Source code is available in attachment and should build without any problems (except for the dll reference)
- Follow stem 6 for Microsoft.Phone.InteropServices.dll errors
Install XAP => Navigate to the phone's IP shown in application => Browse and enjoy.
- Change password on first launch (its randomized)
Many thanks to davux for creating the base for this tool.
- Orginal NoDo thread Here
Changelog:
v0.1 - Initial Mango version release
v0.2 (iconizer)
- Thanks MarysFetus aka Suicide Clown for the great icon set and start screen, love em
- Many thanks to GoodDayToDie for informing me that this app can / and will run from now without the <"ID_CAP_INTEROPSERVICES">
- Removed old OEM dll's that where not used (xap size: 812 KB => 250 KB)
//fiinix
Nice works my friends... I Like It
Thankx
@fiinix:
Thx for porting the webserver to Mango !
As I remember the initial version from Davux had an on device execute feature.
Do you plan to implement execute feature ?
Could be very useful for exploring all .exe files in the windows folder.
Greetz
contable
Freaking awesome, man!
One suggestion: I don't believe this app does anything that requires ID_CAP_INTEROPSERVICES (that is, it doesn't need to open any driver handles). I may be mistaken about that, of course. If it doesn't, however, there's a real benefit to removing that capability as people with interop-locked phones could then run it. Note that the library used may try to do things requiring interop even though the app doesn't need it to.
In addition to its uses as a hacker's tool, I also want to point out that this app can be used to store files on the phone for easy transfer between computers. It's less convenient than true USB Mass Storage, but it works (even if you don't have the USB cable with you) so long as there's a WiFi access point that the phone and PC can both connect to.
Oh, and by the way, this app will run happily in the background if you use JaxBot's no-dehydrate hack. You can do other things then, even browsing the webserver from the phone's own browser! Of course, it will also use some resources.
Now slimmer, and no ID_CAP_INTEROPSERVICES
OK, this is just a modification of the XAP file - I didn't even recompile the source (thank you so much for including it, though!)
Things I did:
Removed ID_CAP_INTEROPSERVICES from the AppManifest. This will allow the app to be installed on interop-locked phones. It wasn't using it anyhow.
Removed the OEM-specific DLLs that are only useful if you have ID_CAP_INTEROPSERVICES. They weren't being used, but they made the download and install bigger.
Result: A smaller app that works exactly the same and can be installed on any Dev-unlocked Mango phone.
Really neat. Mind if I design some sort of decent icon for this app?
Regards, Suicide Clown
//Update:
finished the Icon:
Hope you like it.
MarysFetus said:
Really neat. Mind if I design some sort of decent icon for this app?
Regards, Suicide Clown
Click to expand...
Click to collapse
Sure, go ahead.
Its the freedom of XDA, do what you want
I added the new NativeIO_Mango.dll to my battery status app instead of the old filesystem.dll. I hope that's okay. Thanks so much for your great libraries.
singularity0821 said:
I added the new NativeIO_Mango.dll to my battery status app instead of the old filesystem.dll. I hope that's okay. Thanks so much for your great libraries.
Click to expand...
Click to collapse
The "NativeIO_Mango.dll" is actually a communicator for "Homebrew.csproj" containing COM+ "IWinSock" and "IFileSystem"
- Homebrew.csproj exists in this projects code.
The battery interop will not talk to NativeIO_Mango.dll (the "Webserver" will tho)
Phone.Battery.GetBatteryAdvanced()
-- goto here
---- DllImportCaller.lib.GetSystemPowerStatusExAdv7(ref str, true);
Homebrew.IO.Directory.GetFiles ( [path] )
-- cctor (static constructor) => Register("NativeIO_Mango.dll", "B0E4E41C-BE1D-4BA2-B8CE-7D632EA1CA37");
---- FileSystem.FindFirstFile ( ... ) & while FileSystem.FindNextFile( ... )
:here
Code:
[COLOR="DeepSkyBlue"]Registrer[/COLOR].Register(BasePath +
[COLOR="RoyalBlue"]#if[/COLOR] RUNNS_UNDER_MANGO
[COLOR="DarkRed"]"DllImportMango.dll"[/COLOR], [COLOR="DarkRed"]"434B816A-3ADA-4386-8421-33B0E669F3F1"[/COLOR]
[COLOR="RoyalBlue"]#else[/COLOR]
[COLOR="Silver"]"FileSystem.dll", "F0D5AFD8-DA24-4e85-9335-BEBCADE5B92A"[/COLOR]
[COLOR="RoyalBlue"]#endif[/COLOR]
);
Filesystem.dll is not used anymore in Mango version (its a NoDo dll)
"Thanks so much for your great libraries."
- Thank you so much
I could swear it didn't work without the filesystem.dll one time I tried haha. I guess that was something else
Thanks~
perfect! Now we'll look for regedit editing & file transfering. Any ideas?
Fiinix this is just amazing work! Because of you, I've need to rewrite a chapter of my thesis
Let me ask some questions regarding the supplied source code:
There are four folders inside the rar archive:
The Lib folder contains all OEM DLLs from Samsung, HTC and LG.
The Homebrew folder contains all old code from davux that is necessary to open up the sockets, files and registry entries (if needed?)
NativeIO_Mango contains your altered native DLL that can be used under Mango
The Webserver folder contains the actual WP7 application, that glues everything together into one nice app.
From the underlying workings:
Davux tried to build an API that resembles C# Sockets from the desktop. This way the C# Webserver project of jgauffin can be reused in the WP7 application. You removed from Davux's NativeIO project the references to all parts that require the native OEM DLLs (which is why GoodDayToDie stripped the unneeded DLL files and removed ID_CAP_INTEROPSERVICE to allow users without interop-unlock to use the app).
If this is so far correct, I'm wondering how some things in this application could work:
Ok, so you've removed the code that allows access to the filesystem and registry which uses the native OEM DLLs. How is it possible, that this application can access folders outside its Isolated Storage??? The application should not be allowed to access the windows folder nor any other folders? I know only of one folder, that should be read/writeable. Its a folder that heathcliff found in the policies, I think it was some kind of log folder. Or is readable access with WM6 native API to all files possible?
In WMAppManifest.xml stands ID_CAP_NETWORKING. This is necessary for navigating between different XAML pages but also necessary if we want to do something with the native network access. Can this capability removed or will the application break?
To sum up, if these assumptions are all correct, the policy system is partly useless from the moment on, where someone is capable to call native code, that does not require ID_CAP_INTEROP. This would theoretically allow a submission to the Marketplace?
Right now, I'm heavily confused and irritated, please explain me my error in thinking
PS: I tried to build the NativeIO_Mango project. I changed to release target and build. However, it exits with error message regarding the missing _CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA setting. I've added it, but then I get 19 more errors. Each time it is unresolved external symbol.
Hi Rudelm,
I can't answer exactly what Fiinix did, but I can resolve a couple other points for you.
The OEM DLLs allow higher-than-normal app permissions (breaking out of the low-privilege "sandbox" that apps normally operate in). However, there are a few parts of the filesystem that can be accessed even without them, by design. One of those is the Isolated Storage for the app, which obviously needs to be readable and writable by the app. Another one is the install directory, which only needs to be readable so libraries and resources can be loaded (the webserver app doesn't allow you to browse this folder, but I'm confident that it could if it was coded to). The third is the Windows directory, which is also read-only (and many files and folders within it can't be read) but is similarly required because the app needs to be able to load system libraries (including the TaskHost.exe binary that hosts the app DLL). "Normal" apps can't access these folders simply because the Silverlight API doesn't have a function to open or list an arbitrary location on the filesystem (only within the isostore, which it abstracts the path to).
I don't know what happens if ID_CAP_NETWORKING is removed. It's quite likely the app would break, since that capability may be checked any time the app tries to open a socket (directly as this app does, or indirectly via the Silverlight APIs). You could experiment and do some research to find out, though. It would be interesting to see.
I wouldn't worry too much about apps in the marketplace running amok with native code (even in the low-privileged process, they could still do some harm). The ComBridge Silverlight API that is required to access native code at all is prohibited from use by independent software vendors - only Microsoft and their partners are allowed to use it for Marketplace apps. Somebody tried submitting a Homebrew app to the marketplace (another opportunity for some research, if you'd like to find out more) and discovered that the use of ComBridge is detected and blocked during the submission process.
There we go, a enchanted new version v0.2
- Optimization's from what everybody has told, the best from all worlds
thanks for the explaination!
It seems like a plausible idea that the native code and the WP7 app needs to access some of the folders to work. So the silverlight managed code won't grant access by design to the Windows folder. Can you tell me where this folder for the installation packages is?
Regarding the capabilities: I've checked it with the marketplace capability test tool:
Result Details
[INFORMATION] : Capabilities used by application :
ID_CAP_PUSH_NOTIFICATION
ID_CAP_NETWORKING
ID_CAP_IDENTITY_DEVICE
I've removed ID_CAP_NETWORKING and it immediately stopped working. No dialogue that shows the IP address, only username and password. That is at least good to hear
Regarding the marketplace certification: You could be right, I've also read somewhere that COM is only available to some third parties like Adobe and manufacturers. Maybe I try to submit a little test app that uses interop.
rudelm said:
thanks for the explaination!
It seems like a plausible idea that the native code and the WP7 app needs to access some of the folders to work. So the silverlight managed code won't grant access by design to the Windows folder. Can you tell me where this folder for the installation packages is?
Regarding the capabilities: I've checked it with the marketplace capability test tool:
Result Details
[INFORMATION] : Capabilities used by application :
ID_CAP_PUSH_NOTIFICATION
ID_CAP_NETWORKING
ID_CAP_IDENTITY_DEVICE
I've removed ID_CAP_NETWORKING and it immediately stopped working. No dialogue that shows the IP address, only username and password. That is at least good to hear
Regarding the marketplace certification: You could be right, I've also read somewhere that COM is only available to some third parties like Adobe and manufacturers. Maybe I try to submit a little test app that uses interop.
Click to expand...
Click to collapse
The Capabilities Test only checks through managed code and its caller references (Dll references, method usage within dll)
Why the ID_CAP_NETWORKING is needed is because of the WP7 policy system; ID_CAP_NETWORKING allows usage to those resource locations:
Allowance to "WINSOCK", windows socket API
Code:
<Rule Description="Authorization rule for capability ID_CAP_NETWORKING" ResourceIri="$(GLOBAL_RESOURCES)/WINSOCK/CONNECT" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
- <Match AccountId="$(CAPMACRO_ID_CAP_NETWORKING)" AuthorizationIds="GENERIC_ALL" />
<Rule Description="Authorization rule for capability ID_CAP_NETWORKING" ResourceIri="$(GLOBAL_RESOURCES)/WINSOCK/LISTEN" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
- <Match AccountId="$(CAPMACRO_ID_CAP_NETWORKING)" AuthorizationIds="GENERIC_ALL" />
<Rule Description="Authorization rule for capability ID_CAP_NETWORKING" ResourceIri="$(GLOBAL_RESOURCES)/WINSOCK/ACCEPT" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
- <Match AccountId="$(CAPMACRO_ID_CAP_NETWORKING)" AuthorizationIds="GENERIC_ALL" />
<Rule Description="Authorization rule for capability ID_CAP_NETWORKING" ResourceIri="$(GLOBAL_RESOURCES)/WINSOCK/SERVICE_PROVIDER_CHAIN" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
- <Match AccountId="$(CAPMACRO_ID_CAP_NETWORKING)" AuthorizationIds="GENERIC_READ" />
"Can you tell me where this folder for the installation packages is?"
\Applications\Install\9bfacecd-c655-4e5b-b024-1e6c2a7456ac\Install\
Nice, thanks for the policy entry. Where did you find it?
Regarding the installation path: I thought you ment a special path to the place where the compressed xap is deployed or something like that before installation. But now it is clearer to me why the application is able to access Windows, installation dir and isolated storage
I've tried to upload a small app with native code but as GoodDayToDie said, the marketplace will see that it contains access to native API and that my account isn't allowed to do that.
So the world is safe again, I'm calmed down now hehe
The policy is from a ROM dump: BasePolicy.xml (Currently got "WP7 Mango Build 7661" dump), i think its this one i downloaded: [DUMP]WP7.1 Build 7661 "Mango"
Some more clearance: \Applications\Install\{ The application Guid }\Install\
- Each application has its own isolation storage:
\Applications\Data\{Guid}\Data\IsolatedStore\
I don't know if it's possible but can you add access to /My Documents?
voluptuary said:
I don't know if it's possible but can you add access to /My Documents?
Click to expand...
Click to collapse
Sorry to say but the basics of this app allows only access to \Windows (dll reference location) as used for extracting of xap files, xml and dll (reverse engineer). You will probably need WP7 Root tools.
Related
Looking around the IMGFS, I found some undocumented capabilities that can be used in building an app (in addition to the standard ones mentioned in the WMAppManifest.xml file).
These are the extra ones I found, in case anyone is interested (from BasePolicy.xml):
ID_CAP_RINGTONE_ADD:Allows ringtone-marketplace applications to read/write into the Ringtones directory
ID_CAP_MEDIALIB:Access to the media library - read, play-back, etc.
ID_CAP_INTEROPSERVICES:Temporary Interop Service Capability.. To be removed by feature team
ID_CAP_SIMrovides access to SIM manager API
ID_CAP_SMSrovides access to SMS API
ID_CAP_WAProvides access to WAP API
ID_CAP_IDENTITY_USER:Allow an application to use a phone.info.dll to retrieve user properties
ID_CAP_TESTPUBLIC1:Small public test capability
ID_CAP_LOADUNSIGNEDMANAGEDDLL:Capability to load unsigned managed dll into chamber's process space
ID_CAP_LOADUNSIGNEDNATIVEDLL:Capability to load unsigned native dll into chamber's process space
ID_CAP_DEBUG:Allow an application to run in debugging enviorment.
---Edit---
I've tested each of these individually, and some work, and others don't.
ID_CAP_INTEROPSERVICES works
ID_CAP_RINGTONE_ADD works
ID_CAP_MEDIALIB works
ID_CAP_IDENTITY_USER works
ID_CAP_TESTPUBLIC1 works
ID_CAP_SIM ID doesn't work
CAP_SMS doesn't work
ID_CAP_WAP doesn't work
ID_CAP_LOADUNSIGNEDNATIVEDLL doesn't work
ID_CAP_LOADUNSIGNEDMANAGEDDLL doesn't work.
Note that even for the ones that work, Microsoft may still reject them in the app store.
I tested these by entering them in the WMAppManifest.xml in the XAP, and loading them on a windows phone device. This guy suggests that if it loads on the device, you have the permission: http://www.drdobbs.com/windows/227701092 and I think he's right. If you don't have permission, it doesn't actually load, and in every case, if it loaded it ran.
ID_CAP_RINGTONE_ADD - So i guess with next update we will get Custom ringtones that can b installed from an app
off topic can some one create utility that will do something about tuch sensetive buttons, when using camera if u tuch any of then by accident it exit camera, so u have to hold phone very carefully.
also, app to lock screen rotation would be nice.... any of thous features undocumented anywhere
P.S sorry for unrelated message
I think the ID_CAP_RINGTONE_ADD feature will only be enabled for the carriers (who knows what Microsoft really has in mind, though). The Windows Phone has done a good job (or lousy job, compared to what I desire) managing permissions so they can choose what capability to give whom.
Disabling other buttons shouldn't be hard if you can get to the native API. So once the phone is jailbroken......
Actually, Microsofts own Q&A on Windows Phone 7 states to look in the Marketplace for additional ringtones. Here is an excerpt and a link:
To find a ringtone in Marketplace
1
On Start, tap the arrow to go to the App list, then tap Marketplace .
2
Press the Search button.
3
Do one of the following:
•
To browse a variety of ringtones, type ringtones, then tap Enter .
•
To look for a more particular type of ringtone, type something more specific, like Halloween ringtones.
Tip
To hear what a ringtone or alert sounds like, tap Play .
Note
Marketplace may not be available in your country or region.
Click to expand...
Click to collapse
http://www.microsoft.com/windowsphone/en-us/howto/wp7/start/ringtones-and-sounds.aspx
All well and good having that, but why should we purchase a ring tone?
TheDisneyMagic said:
All well and good having that, but why should we purchase a ring tone?
Click to expand...
Click to collapse
Well, I don't see myself buying any, but this means an app could be made to create/add ringtones.
Long press on a song in Zune won't let you set it as the ringtone?
Iridox said:
Long press on a song in Zune won't let you set it as the ringtone?
Click to expand...
Click to collapse
Nope, I asumed this would be how it worked but no option in the list to do so.
Ah, that's a PITA >_>
naplesbill said:
Well, I don't see myself buying any, but this means an app could be made to create/add ringtones.
Click to expand...
Click to collapse
A whole app just to add a ringtone!?
naplesbill said:
Actually, Microsofts own Q&A on Windows Phone 7 states to look in the Marketplace for additional ringtones. Here is an excerpt and a link:
http://www.microsoft.com/windowsphone/en-us/howto/wp7/start/ringtones-and-sounds.aspx
Click to expand...
Click to collapse
To me that excerpt looks like you can download ringtones from the store, not that you can create an app to download ringtones. It would appear that Microsoft has an internal application that can add ringtones (which makes sense). These permissions are enforced by the OS, not the app store (maybe the app store does too). So if they want to be able to install ringtones, they need to give their own app permission to do so.
athompson said:
Looking around the IMGFS, I found some undocumented capabilities that can be used in building an app (in addition to the standard ones mentioned in the WMAppManifest.xml file).
These are the extra ones I found, in case anyone is interested (from BasePolicy.xml):
ID_CAP_RINGTONE_ADD:Allows ringtone-marketplace applications to read/write into the Ringtones directory
ID_CAP_MEDIALIB:Access to the media library - read, play-back, etc.
ID_CAP_INTEROPSERVICES:Temporary Interop Service Capability.. To be removed by feature team
ID_CAP_SIMrovides access to SIM manager API
ID_CAP_SMSrovides access to SMS API
ID_CAP_WAProvides access to WAP API
ID_CAP_IDENTITY_USER:Allow an application to use a phone.info.dll to retrieve user properties
ID_CAP_TESTPUBLIC1:Small public test capability
ID_CAP_LOADUNSIGNEDMANAGEDDLL:Capability to load unsigned managed dll into chamber's process space
ID_CAP_LOADUNSIGNEDNATIVEDLL:Capability to load unsigned native dll into chamber's process space
ID_CAP_DEBUG:Allow an application to run in debugging enviorment.
Visual Studio won't let you add all of them directly, but uncompress your .xap in the build directory, and add it manually.
If anyone is thinking of doing this, the phone rejected my attempts to do so. I tried to give myself ID_CAP_LOADUNSIGNEDNATIVEDLL, but it wouldn't even load on the phone. Oh well.
Click to expand...
Click to collapse
But if someone use these things in an application , I think microsoft doesn`t approve it in the market place!
amir_rafie said:
But if someone use these things in an application , I think microsoft doesn`t approve it in the market place!
Click to expand...
Click to collapse
Ya, not only that, they probably automatically check to make sure you don't try to use them. The phone automatically checks, too.
The main reason I put them here is because I couldn't find them documented anywhere on the web, and I thought it would be good to save someone the time if they started down the same path I did.
hopefully once there is a jailbreak that turns of security/cert checking we can add these capabilities to our apps. Im particularly interested in the p/invoke capability.
indiekiduk said:
Im particularly interested in the p/invoke capability.
Click to expand...
Click to collapse
YES! It would make the world beautiful and skies turn blue.
So I set up VS 2010 and tried debugging an app that had a simple DLLImport in it and ID_CAP_INTEROPSERVICES in the manifest, however it still crashed with a MethodAccessException. It was def a valid dll and method name because I took it from one of the DLLImports in the system.location .net dll decompiled with Reflector.
indiekiduk said:
So I set up VS 2010 and tried debugging an app that had a simple DLLImport in it and ID_CAP_INTEROPSERVICES in the manifest, however it still crashed with a MethodAccessException. It was def a valid dll and method name because I took it from one of the DLLImports in the system.location .net dll decompiled with Reflector.
Click to expand...
Click to collapse
Interesting. If your app installed, it means you were able to get the ID_CAP_INTEROPSERVICES permission, because if the phone rejects your permission, it rejects it at install time. Maybe the DLL path was wrong, like you need to do ..\DLLNAME.dll or something.
indiekiduk said:
So I set up VS 2010 and tried debugging an app that had a simple DLLImport in it and ID_CAP_INTEROPSERVICES in the manifest, however it still crashed with a MethodAccessException. It was def a valid dll and method name because I took it from one of the DLLImports in the system.location .net dll decompiled with Reflector.
Click to expand...
Click to collapse
Try a relative URI path. ./DLLName.dll
On the subject of Native Applications on Windows Phone 7:
A few days ago, an Application called "Network Profile" appeared in the Samsung Zone of my Omnia 7's Marketplace.
This app is the first external app that uses native code - The Marketplace says that it "Requires access to your interop services", and on opening the XAP on my PC, I found it to contain three native COM DLLs, alongside two .NET DLLs and a further native DLL with MUIs that appear to only serve to hold resources.
I'm not sure whether this can be linked to here, so I'm going to describe the interesting parts.
It has not one, but three XMLs - the typical WMAppManifest.xml (pastebin.com/uEJWdTuA), a WMAppPRHeader.xml (pastebin.com/AVcv7JUX) which seems to have something to do with PlayReady DRM, and most interestingly WMInteropManifest.xml (pastebin.com/NCVKP6kM).
There is also the AppManifest.xaml (pastebin.com/rRrB090h).
The NetworkProfile.dll has a number of COM Imports like so:
Code:
[ComImport, InterfaceType(ComInterfaceType.InterfaceIsIUnknown), Guid("F1113B13-AAB8-45E9-91A5-CBE568C29612")]
internal interface INwProfInterface
The Constructor for the class containing all the COM Interfaces:
Code:
ComBridge.RegisterComDll("NwProfDLL.dll", new Guid("4A2580BA-11A3-49AB-AC98-C30B5E72D381"));
this.NwInterface = (INwProfInterface) new CNwProfClass();
ComBridge.RegisterComDll("SecVersion.dll", new Guid("DFE52822-B526-4913-807A-D2AABC7BF911"));
this.SecVerInterface = (ISecVersionInterface) new SecVersionClass();
ComBridge.RegisterComDll("COMRilClient.dll", new Guid("A18F6B1A-924E-4787-AA82-19F98B49CF5D"));
this.SecRILControlInterface = (ISecRilControl) new COSecRilControl();
Happy to answer any questions, and if allowed, either guide people to getting it themselves, or providing a download link to the XAP.
Sweet, good find! I downloaded that app. How did you get it off your phone? If you have a download link to the XAP no one will complain, either.
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
Hello,
I'm new to prgramming with C# and wanted to know how I can read a value from the phone's registry and display its data in a TextBox on WP7?
Thanks
The problem isn't C# per se, but the public phone API doesn't allow registry access. If you only need read support, there's a library out there that will give you read capability on most of the registry, though you won't get write (permissions issue). Write surrport is also available on some devices, though that gets... tricky.
One place you can find this library, along with an example of how to use it, is in my IE Search Switcher app, located on this site. The short version is you include the native.dll library, enable some optional application capabilities, use the phone's interop library to get COM import into C#, and import the nativle library using COM. You can then call them from the managed (C#/.NET) code.
The Homebrew library comments and and included readme should explain enough to get you started. Be aware that any app doing this will fail Marketplace certification; you'll only be able to distribute it to people who have developer-unlocked phones.
At the moment I'm working on an app called "WP7 Root Tools". I got the registry editor almost finished, but I am also going to add a File Explorer, Certificate Stores and maybe more. When the registry editor is working I will release the first alplha-version. As the title of the app implies, the tool uses root privileges to perform queries and transactions. I let the tools parasitize other processes to get the code executed in the TCB chamber of the device. I have this working stable now on my Samsung Omnia 7. Unfortunately I have to use a little bit of device-specific API's to do this. And I have to make quite a detour to make it work, which has a negative impact on the performance.
So the ultimate goal is that, in the end, this will work with other, more direct API's, which work on all devices. During my research I found some possiblities that need more investagation. I already decided that I will first concentrate on getting this working with my Samsung device, so that I have at least the tools to do further research. But I thought I'd drop some of my findings here that may lead to better device-support and better performance for future-versions of the tools.
There are many ways that may lead to executing code with elevated or root privileges. But in this post I want to concentrate on XML provisioning. A lot of info can be queried and configured through these API's. I have tried to call the native OS functions for XML provisioning. The function you need to call is: DMProcessConfigXML(). And it is declared in: Cfgmgrapi.h. If you call this function it returns errorcode: 0x4ec (or 0x800704ec), which means "Access disabled by policy". If you use a native COM dll and you forget to add ID_CAP_INTEROPSERVICES to the WMAppManifest.xml, you will get the same errorcode when calling a native function through the COM-interop. So when I get the same errorcode when calling DMProcessConfigXML() this may suggest, that I might be missing a capability in the WMAppManifest.xml.
In another thread on this forum some undocumented capabilities were discussed. One of them was ID_CAP_WAP. Since OMA Client Provisioning is also call WAP-Provisioning, I thought that might be the missing capability. I was not able to add the capability from within Visual Studio, because the capability is missing from the corresponding xsd's so it will give an validation error on building the project. But I could add it manually after the project was build. When I deploy it to the device, using the Application Deployment tool, it would return "Access is denied". I thought it might be an invalid capability, but when I changed the capability to ID_CAP_XXXXXX that would return "Install failed. Fix the capabilities." which is the real error message for an invalid. That implies that ID_CAP_WAP is in fact an existing capability, but I'm just not allowed to use it. When I would be able to use it, I would probably have access to the function DMProcessConfigXML(). That part of the app would be impesonated into higher chambers.
So the big question is what is keeping me from using the ID_CAP_WAP? Why am I not allowed to use it? I tried to attach a debugger to XapDeploy.exe, but it does not throw any exceptions at all. The errorcode is generated in the phone. Getting this fixed will give a big boost to getting closer to root access on all devices. Any help or insight on this will be appreciated.
Heathcliff74
I sent some tweets to da_g, chris, chevron, julien schapman, and a few other devs to let them know this is going on...I'll try tom hounsell too he may know a bit more about this
I'm notifying notebookgrail too because he has been doing some work with dell venue pro devices
Good luck
At a wild guess, it's probably looking for a signature. Using signed code for trusted functions is the kind of thing MS likes to do. :-/
All that said, if you have ProvXML working on Samsung, I would *love* to take a look at it. I'm maintaining a cross-platform Homebrew library. Currently I have at least partial ProvisionXML on HTC and LG, but none on Samsung. I don't have a Samsung device to test with, which is making it hard to try things out...
ID_CAP_WAP isn't a capability you can assign yourself. A higher up has to assign it to you.
<!-- Account loaded from: W:\WINCEROOT\temp\oakcopy28570\Release\x86\XDE\Policy\cb659c75-eac9-4db7-afd8-055632acf233.policy.xml(292,2) -->
<Account Id="S-1-5-112-0-0X71-0X49445F4341505F574150" Description="Autogenerated group for capability ID_CAP_WAP" FriendlyName="ID_CAP_WAProvides access to WAP API" Type="Group">
<!-- MemberOfGroup loaded from: W:\WINCEROOT\temp\oakcopy28570\Release\x86\XDE\Policy\cb659c75-eac9-4db7-afd8-055632acf233.policy.xml(293,2) -->
<MemberOfGroup GroupAccountId="S-1-5-112-0-0X71" />
Click to expand...
Click to collapse
(BasePolicy.xml)
domineus said:
I sent some tweets
Click to expand...
Click to collapse
Thanks.
GoodDayToDie said:
All that said, if you have ProvXML working on Samsung, I would *love* to take a look at it.
Click to expand...
Click to collapse
Well, the whole ProvXml stuff will become irrelevant, when I finish the tools. Because ProvXml is not really user-friendly and my tools will provide that functionality in a user-friendly fashion. So at this moment I want to concentrate on finishing the first alpha-version. Later on, I will probably clean-up the code and release it. But it's quite complex, because I added async multithreading to keep it all smooth.
WithinRafael said:
ID_CAP_WAP isn't a capability you can assign yourself. A higher up has to assign it to you.
Click to expand...
Click to collapse
Thanks for this info. But what I read from this is that you just need to be able to impersonate. Has anyone tried CeImpersonateToken() with this SID?
Abstraction of the ProvXml capabilities is awesome, assuming that we can fully use them and/or extend them if needed. It's useful for a ton of stuff. I've written a small amount of abstraction for registry writes and such, but having the full functionality exposed through a clean API would be fantastic.
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