how to hack ci.dll? - Windows 8 General

I want to change default Minimum Signing Level in ci.dll on my windows 8 pro.Can someone tell me how to do that?

The hack used to change Minimum Signing Level at run-time in Windows RT would also work (with replacement of the THUMB2 instructions for x64 or x86 instructions), but that's pretty wasteful as a way to do it. Using a kernel debugger would also work, though you'd probably need another computer to do it from. Modifying the file itself... possible, but tricky. You have to turn off the system file restoration service, or block it somehow. You also need to either use a debugger or Test Signing, or the kernel will probably refuse to load the library because its signature will be invalid.
Out of curiosity, why would you *want* to change that value?

GoodDayToDie said:
The hack used to change Minimum Signing Level at run-time in Windows RT would also work (with replacement of the THUMB2 instructions for x64 or x86 instructions), but that's pretty wasteful as a way to do it. Using a kernel debugger would also work, though you'd probably need another computer to do it from. Modifying the file itself... possible, but tricky. You have to turn off the system file restoration service, or block it somehow. You also need to either use a debugger or Test Signing, or the kernel will probably refuse to load the library because its signature will be invalid.
Out of curiosity, why would you *want* to change that value?
Click to expand...
Click to collapse
Because I need something like a EXE(DLL) firewall.I have tried windows 8 build in Parental Controls but its too simple and its not strong enough.So I think the Minimum Signing Level would be helpful.

The tool you want is called AppLocker. There might be others as well.
I'm curious what the use case is where you think that MSL would help. Generally, that's going to be too permissive (users can still run CMD and other MS-signed software) or too restrictive (you don't need to run *anything* third-party?) or both.

I would set app restrictions in the group policy manager if I was you.
If you really want to go down the route of editing the signing level I would suggest creating a driver that edits it instead of actually editing ci.dll. That's not trivial, but it's far simpler than actually editing ci.dll.

AppLocker in the group policy can not block unwanted(unknow) service.And cil.dll checks itself.As netham45 said,a driver is the best way.But I have never written a driver.Could you help me?

AppLocker certainly can block unknown services. You may need to enable DLL Rules enforcement (I'm not sure what it takes to create a Windows Service that runs under svchost.exe; I've never tried, but DLL rule enforcement will work anyhow) and by default APpLocker will block all EXE services (along with all other EXEs you don't specify exemptions for). Unless your users are admins (which they shouldn't be, or you're already hosed; an admin could just undo whatever changes you made anyhow via any method) they shouldn't be able to bypass properly-configured AppLocker policies.
BTW netham45, I'm pretty sure we're talking about the same feature.
FAQ for AppLocker: http://technet.microsoft.com/en-us/library/ee619725(v=WS.10).aspx
What you are asking for is exactly what this Windows feature *does*.

I was thinking of Software Restriction Policies, I've never actually worked with AppLocker but I have worked with SRPs.
That FAQ has a question in the differences.

Related

HELP: Do WM5 and WM6 apps *have* to be signed?

Hi,
I asked this question over on another mobile phone forum and a user directed me here, so here goes:
Is it necessary for apps developed for Windows Mobile 5 and 6 (PPC) to be "signed" in any way in order to be installed and run? Similar to the way newer Symbian OS apps must be signed? Or can they just be developed and flat-out installed without any hassle or complication, the same way apps for regular desktop Windows PC's can be?
As a programmer/developer and also a Symbian user, I absolutely HATE the need for signing or certifying anything for it to be able to run. If it's not necessary on a laptop or desktop, it shouldn't be necessary on a phone. I am considering switching over from Symbian to WM6, but ONLY if the platform is completely free of the need for anything resembling certificates and signing.
At the very least, is there the option for the end WM6/5 user to easily change a setting within the OS so as to allow the full installation of non-signed apps? I'd settle for that. With Symbian, both developers and users are completely imprisoned by certificates and cannot do anything without the permission of the OS fascists.
Thanks for any help on this..
on WM5 default, when you try and uninstall something unsigned, you just have to tap the "yes" button to run the application, after that it remembers it for that app.
so basically for my setup (wm5/wm6) i can run anything, signed or unsigned. And there is a fix somewhere to disable the notification warning
hope that helps
and
come to the light side
Pocket PC's for the win
Thanks for your reply.. it's certainly encouraging to hear that WM5/6 is not restricted by the absolute necessity for signed certificates like Symbian is. As a programmer I completely refuse to bother developing software for a platform that handcuffs both developer and end user so mercilessly. If I can write programs in Visual Basic that will comple to an EXE and run hassle-free on any Windows PC, I don't see why I should have any less freedom when writing programs for a mobile device.
SymbianSigned and its locked OS is a deal-breaker for me. In looking through this forum though, it seems that there are in fact some components of WM that absolutely must be signed to be installed? Like skins for example? Are there any other components that fall into that category?
Still hoping to get a defnitive answer on what components of WM require mandatory signing and which ones are totally non-restrictive optional. So far my understanding is that under no circumstances do any applications ever have to be signed in order to be installed and run, no matter what kind of advanced access and functions they involve. Correct? Whereas fully integrated keyboard skins do need to be signed, for some reason. Correct?
Any other categories not covered above that do or don't require signing?
Thanks!
As far as I know the worse case scenario for signing is that you must also install your own cert. All that happens when you do this is again a warning.
As for the merits of the whole signing thing. Although I agree symbian goes too far, I think some kind of signing procedure, that is more robust should be required for windows mobile.
My preferred solution would be to have restricted functions that on install warn the user of exactly what capabilities the SW has, and allows the user to allow or restrict certain capabilities.
Simply an I trust this or that is useless as everyone ends up trusting everything as you have little choice. But given that it is easy to write SW using the RIL functions that completely unknown to the user can call expensive pay lines, download ridiculous amounts of data over gprs, or even send me personal information from your device, some security should definitely be required.
The truth is because of the ability to make expensive phone calls directly to people who will have direct financial benefit, I would argue security for a phone is at least if not more important than on the PC.
my 2 cents
WM5/WM6 editions for touch-screen devices generally come with "relaxed" security which means that third party apps don't have to be signed to execute once somebody answers yes to a first-time warning dialog box. ROM cookers here generally relax this requirement even more by setting a registry value HKLM\Security\Policies\Policies\0000101A to a 1. This disables the first-time warning message also.
However, services and device drivers generally need to be signed because they are executed before these relaxed settings take effect. Application developers generally can work around this too by starting the service/device driver themselves with a little program placed in \windows\startup
WM6/WM5 editions for devices without touch-screens generally have a higher security setting that disallows execution of any application unless it is signed.

[Q] Help disabling features on Windows Mobile 6.5 Professional

I am using a phone that has a Windows 6.5 operating system on it.
I wish to disable all the features on my phone other than GPRS connectivity,Wifi connectivity and Camera features.i.e.I shouldnt be able to make or receive calls,text anyone,play games,or use any other default feature.
Either it must be completely disabled or i should be able to give so kind of password protection to these features.
Please help me at the earliest,i require it for a project completion,and i am not able to figure it out as how this can be done.
Thank You in advance
i dont know whether this is the right place to post as i am a new user,so i am extremely sorry if i have made a mistake.
You should get a SIM card that only supports data access for your project. This will prevent any circuit switched (i.e. voice) features and linked services like SMS. There are also options to activate call barring features for a normal SIM (so you can steer what is allowed or not) - but his is then again part of the SIM card subscription (and can be used on any phone likewise).
There are no default options which could cripple your device in such way as you have asked for.
How to make changes in security policy of Windows Mobile 6.5 Professional?
i was browsing through the net and i found this matter:
4102
Unsigned Applications Policy
SECPOLICY_UNSIGNEDAPPS
This setting indicates whether unsigned applications are allowed to run on Windows Mobile devices. If a signed application does not have a matching root certificate in the Privileged Execution Trust Authorities or the Unprivileged Execution Trust Authorities certificate store, the application is unsigned.
You should always use SECPOLICY_UNSIGNEDCABS together with SECPOLICY_UNSIGNEDAPPS policy. This means that when you block unsigned applications from running, you should also block unsigned cab files from getting installed on the device.
Default value is 1 for Windows Mobile.
The following list shows the possible values:
0 indicates that unsigned applications are not allowed to run on the device.
1 indicates that unsigned applications are allowed to run on the device.
Any value other than 1 is treated as 0.
The required role to modify this policy is SECROLE_MANAGER.
i think this will help me as i can make the applications that i dont need as unsigned applications and then make it 0 which will serve my purpose...but i have no clue how to make these changes in my mobile..
Can u please help me with this???
the solution that is given wont work for me because if anyone changes the sim then the settings i require will change and thus the solution is not full proof. i also dont know i will get any sim dat only offers data transfer.
thank you for the quick reply and i am expecting the same in future too!!
Thanks in advance
Regards,
Sneha
Let me write you this last reply to your query, please do not expect any further from my side.
This forum deals with understanding restrictions and enabling previously hidden or restricted functions mainly - learning from each other's experience.
The subforum you have chosen (chef central) deals with understanding how the Operating System is constructed from packages and how these can be recombined to new (cooked) ROMs.
There is no intention to cripple the existing functions of the operating system itself or to restrict the Radio part of it in any way.
You may think that the snippet you took from a MSDN page delivers something you could use for your purpose (which you have not outlined) without understanding the security concept of Windows Mobile. This is quite complex and often (for simplicity) simply disabled completely on several levels - so no security either for whatever you want to do.
The existing packages of the OS do not have separate components that you could omit to disable your desired functions.
Even if so, these core packages of the OS are usually delivered as modules (another special concept of Windows CE/Mobile) that do not need any security or signing - so they run anyway without restrictions.
So finally good luck with whatever you want to do, but I believe that you cannot achieve this with a crippled Windows Mobile - at least not fool proof.
Hello Sneha,
Welcome to the forums.
Unsigned Applications Policy is totally different then what you are looking for. More info here. When enabled, you will be allowed to install or run unsigned aka untrusted apps.
But the inside apps or features are already signed so you cannot stop them from running by enabling or disabling Unsigned Applications Policy.
The really thing you need is to make a custom ROM, remove all the unnecessary things and flash it to your device(s). That means you should change/modify the built in OS (in a simple word) but you cannot do within the device
However, its not a day, week or even a month task. It takes many months to learn things and then you can finally do it. I'm 99% sure that all of your needs can be fully filled but :
1. Takes many months to learn.
2. You need to get the stock ROM, Modify and flash to the device.
BTW; which device you really have?
Thanks...
Best Regards
Closed environment is something that should be done in bsp: kernel to be precise. Also it is possible via custom certmod.dll.
BUT. Little problems:
1) no bsp sources unless you're OEM
2) no certmod.dll sources.
Please look at the initial request on the restriction of radio features. This is handled in the radio layer and this cannot be cut in pieces. So there are no components to sign/restrict/omit for that query.
Cooking can do a lot, but it does not go inside one component.
Cutting all other things may be feasible - but not for radio relevant parts imho.
tobbbie said:
Please look at the initial request on the restriction of radio features. This is handled in the radio layer and this cannot be cut in pieces. So there are no components to sign/restrict/omit for that query.
Cooking can do a lot, but it does not go inside one component.
Cutting all other things may be feasible - but not for radio relevant parts imho.
Click to expand...
Click to collapse
Of courses its a lot of work but its possible. Within the OS functions. Radio thing is just for input and output but the way its handled is under OS itself. Am I right or wrong? Think of removing packages depending to what you don't want.
i.e to disable messaging, Remove all things which are related to it. I'm sure you know it.
Though its a plenty of work and have to be expert so not messing around things.
ultrashot is right but if we had the source, every thing would have been different and even easy.
Radio is special and never dealt with in cooking. The Radio lower layers are treated with code in a dedicated partition (GSM) and accessed via an interface Layer (RIL = Radio Interface Layer) from the OS.
On top of that are applications like messaging or MMS - these can be cut.
I see no option to prevent e.g. only speech calls but allow data calls. On RIL level these are just different GSMBCIE elements (look up the relevent 3gpp specs). Of course you could find dirty ways to cut off e.g. the GSM speech codecs, but this would possibly not prevent to set up a call - creating cost but not having success when connected.
Tweaking these parts has not been of anyone's interest and thus "in theory" possible but hardly practically feasible.
How can i make changes on the OS?
Thanx a lot Cracing for the positive advice.I was planning to consult the OEM to make changes in the security policies.
I am working with the Synqe device .My main aim is barcode scanning and sending the data via GPRS or Wifi.and at the same time i want that all others connectivities and applications are to be deactivated.
Moreover i wish to restrict the usage of GPRS strictly for my application.
As u mentioned that i will have to make changes in the OS,will the OEM be able to do that for me or should i consult a good Mobile OS developer?
sneha6689 said:
Thanx a lot Cracing for the positive advice.I was planning to consult the OEM to make changes in the security policies.
I am working with the Synqe device .My main aim is barcode scanning and sending the data via GPRS or Wifi.and at the same time i want that all others connectivities and applications are to be deactivated.
Moreover i wish to restrict the usage of GPRS strictly for my application.
As u mentioned that i will have to make changes in the OS,will the OEM be able to do that for me or should i consult a good Mobile OS developer?
Click to expand...
Click to collapse
I see
Going with OEM should be better idea. They have the sources to do anything. Its not so easy for 3rd party Mobile OS developers (i.e here ). Need things and takes long enough to R&D and finish the project.
Hope you will find a good solution for your project soon.
Thanks...
Best Regards

Porting the WinRT "Jailbreak"

I posted this question several months ago in the 8X forum and have decided to put this out for discussion again.
ZaneKaminski said:
So, recently, an exploit has been developed for Windows RT devices that allows modifying the minimum signing level constant for the extent of the time that Windows is running. The exploit works on Windows RT devices to allow them to run unsigned native code, but interestingly enough, can also be used on regular x86 devices to change that same value. Since WP8 devices are built on the same NT kernel, it is likely that they enforce signature verification in much the same way, and we may be able to exploit this vulnerability on our devices.
For this to work, there are at least these prerequisites...
The WP8 remote debugger needs to let us mess with the CSRSS process.
There needs to actually be a CSRSS process, or something else we can exploit that makes a call to NtUserSetInformationThread.
If this exploit works on WP8, an easy way (as in, on the start screen or something) to load unsigned/native applications on the device and execute them would be nice.
I don't know much about any of those things. Would someone more knowledgeable care to shed some light on the subject?
Click to expand...
Click to collapse
Remote debugger is disabled in retail devices. So, the first exploit should edit BCD and registry entries
this is Cotulla reply:
there are two checkers.
user mode and kernel mode.
Kernel mode - driver SecMgr.sys and user mode - CI.dll.
I patched both of them already to disable signature checking on custom files.
I am talking about EXE/DLL/SYS.
Not sure who is checking XAP files in WP7.
I think these is important winload.exe,bootmgr,ci.dll,SecRuntime.dll
The Windows RT jailbreak won't work as-is on WP8, since WP8 uses a different version of win32k and csrss. It's possible the exploit is still there but it's not too likely we'll get the tools that leaked from MS like they did on RT to actually do it.

[LIBRARIES][SOURCE] WP8 Native Access project

This thread is for announcements and discussion around the WP8NativeAccess project (https://wp8nativeaccess.codeplex.com/). The purpose of this project is to provide general-purpose libraries, usable from C++ or .NET, which enable access to the underlying functions of the OS. In some cases, this will mean simple wrappers around native APIs; in other cases, these will be more advanced operations which simplify using the low-level APIs.
Some of the functions that the Native Access project exposes are already available via the official APIs. Other functions, however, are not. While I have no objection to these libraries being used in Store apps (license permitting), it is unlikely that Microsoft will permit the ones which use unofficial APIs.
Note that this library does not provide any method for elevation of privileges. Consequently, the use of these APIs will be constrained by the sandbox in which all third-party WP8 apps run, as defined by the capabilities in the app manifest. In practical terms, this means that most of the system will be either inaccessible or read-only. Even so, it has already proven useful to myself. When combined with interop-unlock and Capability-unlock hacks (making it possible for apps to obtain higher privileges), these APIs become much more useful. In fact, the EnableAllCapabilities utility uses the Registry library. Similarly, if you have the ability to use restricted Capabilities in an app you are developing, you may find these libraries useful.
The libraries are as follows:
FileSystem version 0.4.0: Implements functionality to read, write, and get information about files and directories, plus supports creating symbolic links and enumerating file system volumes. This version contains a breaking change from 0.3.x: the NativeFileSystem functions are now static and the constructor is removed. This library may be built with or without the macro USE_NON_PUBLIC_APIS; by default it now includes this macro and require kernelbase.lib to build. If this macro is not defined, it builds using the public APIs without requiring any special libraries.
Registry version 0.2.9: Implements functionality to read and write registry values, and to create and delete registry keys and values. Many, though not yet all, registry value types are fully supported. This library consists entirely of non-public (for WP8) APIs and requires the KERNELBASE.LIB and ADVAPI32LEGACY.LIB export libraries for Windows Phone 8 in order to build (the DLLs are in C:\Windows\System32 on the phone; you can use Dll2Lib.exe to extract the .LIB files).
Processes version 0.1.0: Implements basic functionality to get information about your process, and to create or kill a child process. Very early version.
They are licensed under the Microsoft Permissive License.
The FileSystem and Registry libraries are currently being used by my WP8 File Access Webserver project (http://forum.xda-developers.com/showthread.php?t=2355034).
My EnableAllSideloading app uses the Registry library (http://forum.xda-developers.com/showthread.php?t=2435697).
@hjc4869 has a basic FileExplorer app which uses the FileSystem library (http://forum.xda-developers.com/showthread.php?t=2497788).
You may need to use 7-Zip or another extraction program better than the built-in Windows Zip extractor to open the archive.
Reserved for OP...
Updated. This will be the main place on XDA for releases of the NativeAccess libraries going forward. Additionally, please report problems or make feature requests here.
I think there should be some way to list all the volumes...
Perhaps windows runtime has provided an async win32 file API wrapper which has the same ability as win32 ones ,so I think undocumented file API and registry ,process and etc are more important.
The latest version of the NativeFileSystem library can give you the mount points (as strings) for all volumes (C:\, D:\, etc.)... I implemented that a few days ago; it should be in this update. Sorry for not highlighting that more clearly (typo in the OP fixed now).
Can't open "NativeAccessLibraries_040_029_010.zip"
Edit Ok with 7-zip
How odd, you're right. I didn't do anything terribly fancy while building that ZIP, so I really don't know what's up with that.
I have added the NativeFileSystem library to my PDF to Office app...
Thanks again for all your work !
@GoodDayToDie: Congratulations, good work! Unfortunately I can't import the registry library, it says it's not a valid DLL. I have Visual Studio 2013 Pro. Does it work for WP8? Please help me solving the problem. Thanks!
Sent from my Windows Phone using Tapatalk
myst02 said:
@GoodDayToDie: Congratulations, good work! Unfortunately I can't import the registry library, it says it's not a valid DLL. I have Visual Studio 2013 Pro. Does it work for WP8? Please help me solving the problem. Thanks!
Sent from my Windows Phone using Tapatalk
Click to expand...
Click to collapse
You need to reference .winmd file, not the .dll file.
Thanks! Can we also modify hex registry values with it?
Sent from my Windows Phone using Tapatalk
If you have the required permissions, yes. There's read/write functions for REG_BINARY, and also a simple wrapper around RegSetValue that will work for any type.
However, the library doesn't actually give you any privileges your app didn't already have. Without special Capabilities (which usually require hacks to enable), you won't have write access anywhere in the registry at all...
GoodDayToDie said:
If you have the required permissions, yes. There's read/write functions for REG_BINARY, and also a simple wrapper around RegSetValue that will work for any type.
However, the library doesn't actually give you any privileges your app didn't already have. Without special Capabilities (which usually require hacks to enable), you won't have write access anywhere in the registry at all...
Click to expand...
Click to collapse
OK, thanks, but another question: I referenced .winmd file, but it gives me error, the component was not found. Any idea how to fix it?
Do you have the DLL and the WINMD in the same location? Are you creating a WP8.0 app (I don't know if apps targeting 8.1 specifically will work)? Are you building for ARM?
Yeah, I have. Library now working, but it doesn't recognize the commands, I mean if I write NativeRegistry.ReadDWORD command not found :/ Can you help me?
Sent from my RM-915_lta_lta_330 using Tapatalk
You're going to need to be way more specific.
How far did you get, i.e. can you compile the app? Install the app? Launch the app? Does it crash immediately or does it actually load? Etc.
What, *exactly*, breaks? Does it break when you try to reference the NativeRegistry library, or only when you try to actually use ReadDWORD function, or some time later? If you are able to call readDWORD, what is the return value? If it fails, what is the error code?
Are you getting an exception, or does it just not work? If it's an exception, give me as much detail about it as you can (the type, the message, the code where it happened, etc. if possible).
myst02 said:
Yeah, I have. Library now working, but it doesn't recognize the commands, I mean if I write NativeRegistry.ReadDWORD command not found :/ Can you help me?
Sent from my RM-915_lta_lta_330 using Tapatalk
Click to expand...
Click to collapse
Try to rebuild the solution.
GoodDayToDie said:
You're going to need to be way more specific.
How far did you get, i.e. can you compile the app? Install the app? Launch the app? Does it crash immediately or does it actually load? Etc.
What, *exactly*, breaks? Does it break when you try to reference the NativeRegistry library, or only when you try to actually use ReadDWORD function, or some time later? If you are able to call readDWORD, what is the return value? If it fails, what is the error code?
Are you getting an exception, or does it just not work? If it's an exception, give me as much detail about it as you can (the type, the message, the code where it happened, etc. if possible).
Click to expand...
Click to collapse
Hi, I can't even build it, it doesn't recognize the command and makes a red line under it. I can reference the library, but not use any commands like ReadDWORD, WriteDWORD and so on. Screenshot is attached, this is happening if I load your EnableAllSideloading App, for example. With self-created projects I have the same problem. My system is Win 8.1 Pro x64 and I'm using Visual Studio 2013 Professional. Can you help me? Thanks!
You have added
Registry.winmd in reference library
and
Using Registry;
in your source code
Source code for EnableAllSideloading already has the requisite using directives...
When you look in the project's References, is the Registry library referenced correctly? By default it'll try to use a relative path that I use on my PC, but probably not the same path you use. You may need to manually adjust the reference, or delete it and re-create it.
Alternatively, what auto-fix options does Visual Studio give you when you click on those red lines?

Writing to system files and registry?

Hi... I'm from the Windows RT jailbreaking world and don't have a Windows Phone, so please excuse my ignorance.
I have an exploit in Microsoft's Secure Boot code that works on all architectures. I suspect that the same bug works on Windows Phone 8. However, it requires writing to privileged areas of the system. This is easy in desktop Windows and in Windows RT, but I have no idea of its feasibility on Windows Phone 8.
Doss anyone here have insight into this? =^_^=
My RT jailbreak proof (8.1, so not the existing one):
https://mobile.twitter.com/Myriachan/statuses/365350790803619840
Myriachan said:
Hi... I'm from the Windows RT jailbreaking world and don't have a Windows Phone, so please excuse my ignorance.
I have an exploit in Microsoft's Secure Boot code that works on all architectures. I suspect that the same bug works on Windows Phone 8. However, it requires writing to privileged areas of the system. This is easy in desktop Windows and in Windows RT, but I have no idea of its feasibility on Windows Phone 8.
Doss anyone here have insight into this? =^_^=
My RT jailbreak proof (8.1, so not the existing one):
https://mobile.twitter.com/Myriachan/statuses/365350790803619840
Click to expand...
Click to collapse
Unfortunately WP8 is locked down tight and no one can write to the OS partition as far as I know.
petard said:
Unfortunately WP8 is locked down tight and no one can write to the OS partition as far as I know.
Click to expand...
Click to collapse
So to pull it off, you'd need an NT kernel privilege escalation exploit that could be done from a low box token in the WP8 sandbox...yuck. Possible, though. Such an exploit would obviate my exploit, though, because then you could make a side loaded app that jailbreaks the phone when you run it.
As I understand, some registry values can currently be modified via this app. Can't help much more unfortunately.
some of the registry can be accessed, but not all. snickler, gooddaytodie and others are trying to find a way to write to registry. theres a thread on here that talks about the progress.
In particular, we have read-only access to most of the registry, but not much (if any) in the way of write access, beyond what a handful of built in and OEM apps can do (OEM apps can have extra permissions; some store settings in the registry and/or change system configurations, but I haven't yet found a way to get arbitrary access).
Great work on that RT exploit, though. It actually may be useful on the phone even if we do find an arbitrary app EoP exploit - it could make it a lot easier to do certain things - but the most likely EoP is actually us finding a way to abuse an OEM (or built-in) app to change the registry and/or file system. If we can find that, a way to then run arbitrary code with full permissions would be a really useful thing to use such a hack for...

Categories

Resources