Hello the community
I would like to know how to perform a soft reset (reboot) from a WM user interface. Of course there is a lot of external programs and utilities providing such the functionality also, but I guess there should be a mechanism built in WM.
I am sure there should be a DLL responsible for that, so probably there is also a way to execute this DLL?! Something like Windows’ rundll.exe?
My device is HTC p3600/Trinity with WM5, but I think it doesn’t make sense.
Your advice would be much appreciated,
Br, Alexey
dll mean dynamic linked libary
which pretty much mean it's a lib full of functions that
other apps call you cant normaly just call it's functions from
the GUI
yes, I know what DLL actually mean
And that’s why I made a guess about a possible way to run DLL similar to rundll.exe
I would prefer using something like reboot.exe, but if such a program isn’t provided along with standard WM, I don’t mind using workarounds like running DLL, if possible.
Anyway, my question was not about real nature of DLL but the way how to perform a reboot using standard functions of WM.
Check out the SDK documentation, MS might have made a direct api to achieve this through a direct rundll type action, but the easiest way is just to code a tiny app and launch it, eg
http://www.pocketpcdn.com/qa/softreset.html
VJEschaton will reset in a variety of fashions.
V
Thanks
Is there a way to compile such a tiny application without installing any huge C++ IDE? Something like command line compiler downloadable thru a simple ZIP file?
shkaff said:
Thanks
Is there a way to compile such a tiny application without installing any huge C++ IDE? Something like command line compiler downloadable thru a simple ZIP file?
Click to expand...
Click to collapse
The C# compiler is free and can produce WM executables. The only problem is that you must instruct it to use the .NET Compact Framework libraries instead of the normal ones. I readied a guide when the last OS was WM2003. I don't know if it is still working, but actually I have no reason to think it won't. Just choose the right subset of files.
Here is the link:
http://www.jargoncode.it/tips/netcfcompile-eng.htm
If you want a C++ compiler... I don't know.
Ok, so I have no experience of working with any type of coding of development except for Adobe Flash. I don't think that really counts though, nor help me here, but I want to start off by saying that I'm simply a 17 year old.
I want to start development of an app to edit the registry. For example, I got the idea for everytime you click a button on the app, it edits something on the registry. Of course, phones will have to be Interop-Unlocked (Which my Samsung Focus is).
So to get on topic, how may I start creating an app for Windows Phone to edit registry and etc.? As I said before, I really don't have much experience, but I would love to learn and help the community.
Thanks in advance.
Bump up....
Ok, basic first steps: do you have the WP7 SDK? You can get it for free, and you'll need it. It includes the tools to build and deploy apps (compilers and so forth).
The project you're talking about is a bit heavy for a first foray into app development, but you can give it a shot. One of the easier ways (for me, at least) to learn things is to look at what other people did, which in coding usually means looking at open source projects. There are a few open-source apps which access the registry.
For example, my MultiTaskToggle app (linked in my sig) works on Samsung and provides an example of how to read and write a specific registry value.
If you want to browse the registry at all, you'll need something different. This can be done, using COM to call native APIs. Look at the Homebrew library (used by the Webserver projects, among others) or WP7 Advanced Explorer (open source, code is on Codeplex). These types of project have two parts: managed (.NET code, typically in C#) that calls the COM interface, and native (C/C++, written using the Windows Mobile SDK) that implements the COM object.
You may want to do some research online to get started, either here on XDA-Devs (though I think most tutorials here assume at least basic knowledge) or elsewhere (even from MS directly) if you're really starting from scratch.
I want to make a new App to change settings for my phone.
How do I create a C # App in WP7 that makes changes to the registry and files WIndows Phone?
You need a lot of stuff:
- installed Visual Studio + latest WP7 SDK;
- interop-unlocked phone;
- knowledge in C# and WP7 programming.
If you meet the above requirements, read (attentively) this: http://forum.xda-developers.com/showthread.php?t=1569832
And if you are building Windows Phone 7 apps, you qualify as a startup and can get Visual Studio for free from Microsoft:
https://www.microsoft.com/bizspark/Startup/Signup.aspx
This gets you a free MSDN Ultimate subscription for three years.
Still looking for this help
sensboston said:
You need a lot of stuff:
- installed Visual Studio + latest WP7 SDK;
- interop-unlocked phone;
- knowledge in C# and WP7 programming.
If you meet the above requirements, read (attentively) this: http://forum.xda-developers.com/showthread.php?t=1569832
Click to expand...
Click to collapse
I am an average programmer, I have these tools and capabilities.
My intention is to discover how to access and edit the registry through my applications.
wp7roottools is a good choice, but would like to know how to do it from scratch to the end user does not need to have the application installed.
kenikh said:
And if you are building Windows Phone 7 apps, you qualify as a startup and can get Visual Studio for free from Microsoft:
https://www.microsoft.com/bizspark/Startup/Signup.aspx
This gets you a free MSDN Ultimate subscription for three years.
Click to expand...
Click to collapse
Microsoft does not help much in this case
Well, you'll need to know how to write native code (use Visual Studio 2008 and the WinMo 6.x SDKs or the CE 6 or CE 7 platform builders). Write a native DLL with a COM class that exposes the functionality you want. You can then create an instance of the COM class from C# and use that via the ComBridge API. You can read more on doing this in a guide posted by Heathcliff74 on the dev&hacking sub-forum; search "guide developers native mango" and you should find it.
However, that will only give you the APIs to access the registry, it won't actually give you the permissions. You'll have read access to only part of the registry, and no write access at all. If you want higher permissions, you have four options:
1) Write an app for full-unlocked ROMs only. Full-unlock ROMs run all apps with max permissions.
2) Write an app that uses one of the existing "root" hacks that elevate an app to TCB (for example, require that people use WP7 Root Tools with your app).
3) Write an app that uses ID_CAP_INTEROPSERVICES and the OEM drivers present on most phones to do high-privilege operations. This is how registry editors and such worked before Root Tools, but requires substantial work to support various different OEM devices and firmware versions, and some device+firmware combinations aren't supported at all right now.
4) Find your own new elevation-of-privilege vulnerability, hack up an exploit for it, and use that. For example, when I created the HtcRoot project, WP7 Root Tools wasn't yet available for my phone.
GoodDayToDie said:
Well, you'll need to know how to write native code (use Visual Studio 2008 and the WinMo 6.x SDKs or the CE 6 or CE 7 platform builders). Write a native DLL with a COM class that exposes the functionality you want. You can then create an instance of the COM class from C# and use that via the ComBridge API. You can read more on doing this in a guide posted by Heathcliff74 on the dev&hacking sub-forum; search "guide developers native mango" and you should find it.
However, that will only give you the APIs to access the registry, it won't actually give you the permissions. You'll have read access to only part of the registry, and no write access at all. If you want higher permissions, you have four options:
1) Write an app for full-unlocked ROMs only. Full-unlock ROMs run all apps with max permissions.
2) Write an app that uses one of the existing "root" hacks that elevate an app to TCB (for example, require that people use WP7 Root Tools with your app).
3) Write an app that uses ID_CAP_INTEROPSERVICES and the OEM drivers present on most phones to do high-privilege operations. This is how registry editors and such worked before Root Tools, but requires substantial work to support various different OEM devices and firmware versions, and some device+firmware combinations aren't supported at all right now.
4) Find your own new elevation-of-privilege vulnerability, hack up an exploit for it, and use that. For example, when I created the HtcRoot project, WP7 Root Tools wasn't yet available for my phone.
Click to expand...
Click to collapse
Thanks to previous answers, this really seems to get bad to be useful.
So need to develop a DLL with COM classes (for Windows Mobile 6.5) that has the functions I want and then invokes it. I carefully read the topics mentioned.
Answers to your bookmarks:
Option 1) My first application is intended for the HTC HD2 fullUnlock, I believe not having problems with permissions.
Option 2) Use third party tools like WP7RootTools is not very advantageous for the moment
Option 3) seems to be the best option, but as the knowledge needed to collect it?
Option 4) I think I still do not have sufficient skills for this option.
Very grateful for your help this is really helpful and appreciated.
Hello.
I'd like to automate XAP deployment from my development environment to WP emulators running for testing. WP emulators are running as Hyper-V VMs and they have a valid IP. As much as I understand communications between MS tools like Visual Studio 2011 Beta and WP are TCP/IP based. So, I wonder what is hiding behind the "Deploy" button? Some PowerShell command? Anything else? For starting I'd like to upload the XAP and install it on the Emulator and eventually the device.
Thanks.
There are third-party deployer apps, so what you want is entirely possible. You'd have to look at the source for them, though, and then write your own that listened on a network socket for the file that it is supposed to install.
GoodDayToDie said:
There are third-party deployer apps, so what you want is entirely possible. You'd have to look at the source for them, though, and then write your own that listened on a network socket for the file that it is supposed to install.
Click to expand...
Click to collapse
Due to security restrictions I still cannot post to developers forums, so I'll try to ask here:
are these applications like Tom XAP installer or Multi-XAP installer Open Source, or what? They are distributed in a compiled form so how I can ask their developers for the source code?
There are any number of programs that can decompile managed assemblies (JustDecompile, for example, but there are a bunch and many are free). It's nice to ask for source (and some of the apps are probably open-source; you can look for the tag [SOURCE] or similar in the thread title) but unless they obfuscated the assembly for some reason, decompiling well enough to understand what it does is easy.
If you have nothing to add to this discussion please do not post. Thanks
Im hoping that we can make a list of requirements for this jailbreak to happen. Please read along with us and if you have any ideas regarding any of the steps please help us out...
Thanks,
Toxickill.
In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.
I think this is probably the only change.
LolitaPlus said:
In JB 8.0 we change a byte which indicates the sign level from "Microsoft" to "Unsigned".
Now this is protected by PatchGuard: you will get BSOD if you change it.
I think this is probably the only change.
Click to expand...
Click to collapse
Well can we bypass patchguard? Because people over at easy hook have written a c# patchguard 3 bypass driver maybe we can build off of that?
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
master.peterm said:
yeah patchguard has been bypassed I think https://twitter.com/standa_t/status/437972336705159169
Click to expand...
Click to collapse
Ok so now that it can be done im going to fire up my surface and get working on a new jailbreak tool. If all succeeds then i will update accordingly. Hopefully bypassing patchguard is all that is needed to run old bypass methods. If patch guard stays bypassed then we can make the jailbreak persistent through sessions.
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).
I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
GoodDayToDie said:
Well, the other problem is that you can't attach a debugger to CSRSS.EXE anymore. So you need a different way to change the relevant value (or a way to bypass the Protected Process restriction).
I think Myriachan already has a way to do that, though; she mentioned that she'd managed to jailbreak but Patchguard was causing the system to crash, so she was working on a way around that.
Click to expand...
Click to collapse
Would patchguard bsod if we removed the protected process on csrss?
Also, would shell code be able to call ntdll.dll methods? We might be able to code arm shell code and call a method to temporarily revoke its protected process flag.
Edit:
Could we attach the debugger to a none protected process, execute shell code that removes process protection? Only problem is writing shell code is not my thing and especially for arm where its not documented as well.
Also could someone PM me with a cdb.exe thats signed for windows rt 8.1? the one provided with the old jailbreak is only signed for 8.
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.
The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). This isn't something Microsoft is going to just allow people to turn off. We could theoretically patch around the restriction with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.
When thinking about breaking into the system, think about what you want to accomplish. Then identify attack vectors to get there. Then think about how those attack vectors might be blocked. Then think about how you might bypass those blocks. Etc... If you can't get at least as far as the fourth step, you won't accomplish much (certainly not against a target as hardened as Windows).
GoodDayToDie said:
... You do realize the Protected Process flag is in the kernel, right? How do you plan to remove it when, in order to modify kernel memory, you would need to attach to a protected process? It's not like this is the RO flag on a file or something.
The whole point of Windows protected processes is to avoid letting somebody debug them even if they have full control over the machine (they were originally designed for DRM). In testsigning mode or with a kernel debugger, they usually won't launch at all (CSRSS will - it's critical for all Win32 processes, including stuff like Explorer - but the DRM ones won't). We could theoretically patch around this with the aforementioned kernel debugger or with a testsigned kernel-mode driver, but if we could put RT into Testsigning or use a KD on it we wouldn't need anything else at all anyhow; either of those are sufficient for an easy jailbreak.
Click to expand...
Click to collapse
So just to clarify we can not use this undocumented API call that works in Win8.1 x64 on RT:
Code:
[DllImport("ntdll.dll", SetLastError = true)]
internal static extern int NtSetInformationProcess(IntPtr hProcess, int processInformationClass, ref int processInformation, int processInformationLength);
int enable = 0;
NativeMethods.NtSetInformationProcess(CSRSS.exe HANDLE, 29, ref enable, sizeof(int));
C# code of course but you could easily code in any language.
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
GoodDayToDie said:
I don't see any way you can set the Protected Process flag this way... ProcessBreakOnTermination is not, so far as I know, in any way related (although CSRSS should have that flag set anyhow, and should have had it since before protected processes were even added to NT at all). If you could *set* the ProcessBasicInformation you could in theory overwrite the PEB, but supposedly that one is query-only (according to undocumented.ntinternals.net, which may be wrong). Also, you may find that you can't call OpenProcess with PROCESS_SET_INFORMATION on CSRSS, at least on RT 8.1. Worth trying though, perhaps...
Click to expand...
Click to collapse
Well apparently when passing an int (29) as the ProcessInformationClass value that indicates a protected process, and it does work for enabling it and disabling it on other processes so far, process acts like csrss once enabled. We have to make sure to set the SeDebugPrivilege flag on the current process in order to make OpenProcess open a process with the flag PROCESS_ALL_ACCESS which is required for NtSetInformationProcess.
Looking into this, might be worth a shot.
Interesting. MSDN for NtQueryInformationProcess (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684280(v=vs.85).aspx) says that value is ProcessBreakOnTermination and indicates a "critical" process, which I interpreted to mean one that cannot be safely exited (there are a few of these, and have been since XP or before, while protected processes were introduced in Vista and "lightweight protected processes" (the kind that CSRSS is, apparently) were introduced in 8.1. Still, worth a shot.
Administrator should have SeDebugPrivilege, and *probably* have it enabled by default. I'm still not sure you will be able to open the handle to CSRSS - it's explicitly not supposed to be possible to mess with it even if you *are* Administrator (or otherwise have debug privs) - but it's worth trying.
EDIT: There's a policy in Local Security Policy Editor (secpol.msc, yes it's present on RT at least 8.0, if not on 8.1 it's in the registry anyhow), under Local Policies -> User Rights Assignment. You can control what privileges (in the NT Se*Privilege sense) processes owned by given users have. For example, "Debug programs" (This user right determines which users can attach a debugger to any process or to the kernel. Developers who are debugging their own applications do not need to be assigned this user right. Developers who are debugging new system components will need this user right to be able to do so. This user right provides complete access to sensitive and critical operating system components.). You can add "ALL APPLICATION PACKAGES" to the assignees. In theory, this would mean that app packages now have SeDebug. They *might* not be able to use it anyhow (because of the lowbox restrictions) but if they are, that removes the need to use a debugger to inject code into a desktop process running as Admin; just write a native app that calls the relevant APIs.
Great find, i'm away from my dev box until later today but i will try this out. I'm not use to finding the exploit, how ever i'm perfectly capable of writing code for one once its found. But ill dig deeper maybe powershell could still be a possibility.
Edit: Found a spreadsheet that documents all of the security registry keys for 8.1! I found Debug Programs flag for User Rights Assignment in the document for 8.1 and it says minimum requirement is Windows XP! So its most likely on 8.1, my dev box and surface are both on 8.1 so I can verify later I also have the registry key.
Also found load and unload device drivers flag, not sure if thats of any use.
Second Edit: "User Rights security settings are not registry keys" there is no registry key to edit so we would have to either use secpol.msc or figure out where these values are stored.
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?
Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."
It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb.
Edit:
Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.
Lots of me rambling on about that, hopefully we get somewhere.
Toxickill said:
Is there any way for us to figure out how csrss is being flagged as a protected process? Is that done in the kernel, with its createprocess params or is it done by the process itself?
Also has anyone checked if they modified Powershell's exe to prevent unsigned C# code from executing? And if so we also should check if we can use an 8.0 copy on 8.1 worth a shot as well but i'm almost positive it will not execute because of the "Windows cannot verify the digital signature of this application."
It would help if we could at least get cdb or WinDbg working on 8.1 even if we can't attach it to csrss.
I PMd netham45 about how he got cdb working on 8.1 but he has not replied yet. I've checked the WDK 8.1 release and everything is there even for arm except cdb.
Edit:
Also i'm working with Spazzarama over at EasyHook to see how he wrote his Patchguard disabler. If I can get unsigned code running even if it means we need to use a dev id just to start the jailbreak like the original version of nethams tool it would be worth it if it means we can disable patchguard. I have a few ideas on how to go about this, possibly creating a blank app and compile it. Then disassemble the exe with ildasm and replace the entry point with code that includes desktop code, then stitch it back up with ilasm (command line args allow arm code creation and toggling app containers, as long as the tools that create an app package don't test command line args it should work ok and be valid because it wont load any desktop dll's if they are not called i've tested this on normal environments. Then we might be able to get desktop code running that will allow us to disable patchguard, modify the value and then remove the app.
Lots of me rambling on about that, hopefully we get somewhere.
Click to expand...
Click to collapse
Have you tried the latest WinDBG that came with SDK 8.1? I'm using RT 8.0 so I cannot verify it, however it should work on RT 8.1 since it came with the 8.1 SDK
C\Program Files (x86)\Windows Kits\8.1\Debuggers\Redist
cdb is part of WinDBG
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...
They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
GoodDayToDie said:
It's a flag passed to CreateProcess (presumably therefore also in NtCreateProcess), CREATE_PROTECTED_PROCESS. Only usable on binaries with a special Microsoft signature. It blocks most access to the process, causing an OpenProcess specifying those permissions to fail. http://msdn.microsoft.com/en-us/library/windows/desktop/ms684880(v=vs.85).aspx
EDIT: Creating a sideloadable app with desktop code is easy; we managed that over a year ago. The fancy/complex way of doing involves scanning the system libraries that are loaded into memory (using an allowed API, such as GetSystemTime() as a starting point) for the entry point of LoadLibrary, then calling that using a function pointer. The simple and straightforward way is to either modify the header files (which #ifdef out the relevant prototypes when compiling for WinRT) or just copy-paste those prototypes and definitions into our own headers, and then link against the relevant libraries (it's easy to extract .LIB files from DLLs). The latter approach has more initial time investment, and is probably easier to detect, but is "cleaner" (the source code looks exactly the same as would normally be used, aside from removing some checks in the headers) and slightly more performant on startup.
Click to expand...
Click to collapse
Thats what i figured, for csrss, with the sideloadable app I was just wondering if it would be easier to do il modifications. But we are trying to get unsigned code anyway. Im home now and ill look into secpol.msc on my 8.1 tablet. It IS on my dev pc 8.1.
Edit:
Ok secpol.msc is available on my surface, and Debug programs is set to Administrators, what should I try modifying it to?
GoodDayToDie said:
@LolitaPlus: The public debug tool downloads don't include ARM debugger binaries, so they won't run on RT...
They can debug ARM programs, but that's not sufficient for this purpose. Microsoft (and OEMs) have debugging tools that run on the devices directly, and they have leaked in the past; that's what's needed.
Click to expand...
Click to collapse
I'm not talking about VS remote tools. I'm talking about WinDBG (version 6.3.xxxx, not the 6.2.xxxx) and it is on my Surface RT now.
Please correct me if you are not talking about this(WinDBG). If indeed that is what you want, give this link a try (I just uploaded it):
https://mega.co.nz/#!Rthz1aCC!chur33IsRLASnysWQOgNY9LJaeyv8oIsPaHDnwbuWCE