Komodia says:
DLL injection is not possible with Modern UI on Windows 8,It is
possible to inject DLLs into Metro apps, BUT, you will not be able to
redirect Winsock traffic to localhost.
In other words windows metro application working into sandboxed environment, which DLL injection can't be done.
Let's see what Nektra says:
We realized we needed to sign our DLL with a cross-certificate, like
those used to sign kernel-mode drivers.
We already had a method for injecting a DLL in WinRT applications: copy the DLL file inside the System32 folder and voilá!
As you can see Komodia and Nektra says a conflicting information, my question is what's the true behind DLL injection under windows 8, can I inject my code into metro application as usual(NT,win9x) like Nektra says?
I'm the author of Nektra's article. The research began when we wanted to add more features to the limited Metro Mail application that comes with Windows 8.
Although the process was not exactly the same than in desktop applications because usually metro apps are suspended, we hooked first DCOM service.
When DCOM service launches the Metro Mail application, in that point we inject the dll using the well-known method CreateRemoteThread/LoadLibrary call.
In the initial tests we tried to inject a dll located in the same folder were our test was located and discovered that, if the dll was in system32, it loads fine.
Later we do the further research to see why the dll was not loading if not on system32 folder.
About hooking winsock, we didn't test that but I think it should be possible because, at least on desktop computers, behind metro there are the commonly known dlls (kernel32, user32 and so on) and we hooked some api's without problems.
I'm the author of the Komodia article and our article doesn't conflict with Nektra, it is possible to hook Metro apps, or the sandbox that runs the Metro apps, but you can't connect to localhost, not because of hooking but because of Metro limitation on localhost connections. In our first test we used our Win7 WFP (which is a network driver) and modified the IP of packets to localhost which didn't work with Metro apps, NDIS will not work just the same, the only way to do so is using Microsoft's WFP proxy redirection.
Maybe someone will eventually find or already found a hack that allows for localhost direct connection, and as with any hacks, there are risks to consider. If you want an approved method, WFP proxy redirection is the only way to go.
I hereby answer because everyone else is out of point with this. The dll file needs to have read/execute permission to "All Application Packages" group. With this, the loader will allow you to load arbitrary dlls in Immersive apps(=metro apps).
In the initial tests we tried to inject a dll located in the same folder were our test was located and discovered that, if the dll was in system32, it loads fine.
Yes, because System32 is in the search order for Metro (Windows store) applications. There's no magic to it.
Likewise your test's folder was likely not in the DLL search order for the app (System32, the app's package dependency graph, etc), thus the Loader wouldn't find your DLL for the app.
Related
I have a Windows desktop C++ application that currently uses ::PathCanonicalizeW. As you can see from the documentation, it was introduced in Windows 2000 and is located in shlwapi.dll. In order to support long paths on Win 10+, I need to start using ::PathAllocCanonicalize (or one of it's friends - ::PathCchCanonicalize or ::PathCchCanonicalizeEx).
This function was added in Windows 8, but I still need to support the older OS's. In order to support all OS's, I need to dynamically load ::PathAllocCanonicalize by calling ::LoadLibrary at runtime. The problem is that the documentation doesn't provide the DLL that includes this function.
After doing some searching, I found this documentation that includes all 3 of the new PathCanonicalize functions and it claims that they are in api-ms-win-core-path-l1-1-0.dll. After more searching, it appears that this is not a traditional DLL because there is no file anywhere in the OS with that name. This application has always loaded system libraries using the full path to the file in the system directory (typically C:\Windows\system32) to make sure that it's not loading malicious DLLs, but for this it will be impossible without a physical file to point to.
I have been able to test that calling ::LoadLibrary("api-ms-win-core-path-l1-1-0.dll") does work, but the fact that that documentation mentions UWP worries me. Is there any documentation for the supported way to dynamically load these kinds of functions at runtime in a desktop app? Is there a more secure way to load this DLL?
P.S. This app cannot be deployed with that DLL, and even if it were possible there's no point since any OS that doesn't have that function wouldn't have full support for long paths anyway. Using the documented pathcch.lib would require upgrading the target Windows version. Dropping support for the older OS's is also completely out of the question. The function must be manually dynamically loaded at runtime.
As pointed out by Hans, api-ms-win-core-path-l1-1-0 is known as an API set along with many others starting with api-ms-win-core. Based on the documentation there, it appears that the documentation for PathAllocCanonicalize is incomplete. It should list the API set on that page along with the DLL for desktop apps. Looking at the source on GitHub, it looks like there is a bug with that page and the other pathcch functions where that information is in the header but not rendered onto the page. That header lists api-ms-win-core-path-l1-1-0.dll and KernelBase.dll.
If for some reason I wanted to continue to load the API set instead of KernelBase.dll, ::LoadLibraryExW(L"api-ms-win-core-path-l1-1-0.dll", NULL, LOAD_LIBRARY_SEARCH_SYSTEM32) worked which would be just as secure as specifying the full path to a DLL in the system32 folder. Note that LOAD_LIBRARY_SEARCH_SYSTEM32 was not supported without KB2533623 on RTM versions of Vista, Windows 7, Server 2008, and Server 2008 R2 so that might not actually be secure on those OS's.
Using the Desktop Bridge (formerly known as Project Centennial) through the DAC, one can create a full-trust UWP App. I thought this meant you can now create a Full-Trust UWP App and if so, how do you do that?
What I am trying to figure out is what configuration can I manually set on my UWP Project to grant it full-trust.
If you need some background, I need to create an Enterprise tool that has to be UWP. The application is going to be run on my company and one of the features that would make the UX better is to be able to access some parts of the file system outside of those allowed by UWP and preferably without the summoning of a dialog. Being able to run other DLL would also be a big plus; perhaps DLL Hell is desired this time around.
#Anzurio - just stumbled across your question and thought I'd share our experiences building the new Windows Terminal.
We originally set out to create the Terminal as a UWP app, with a nice modern XAML UI, but quickly found that the UWP app platform couldn't support a couple of our key requirements:
1. Terminal must be able to be launched elevated
2. Terminal must be able to launch & connect to arbitrary executables (e.g. cmd, powershell, wsl, etc.)
Because of these limitations, we had to create the Terminal as a standard Win32 process which contains a XAML Island which hosts the Terminal's Tab Bar and Terminal XAML Control instances in the main window frame.
We have taken care to keep as much app lifetime/logic code OUT of the Win32 host as we can, so that we'll have less work to do if/when the app platform does support our requirements and we get to ship a real UWP Terminal apps.
We are working with the app plat team to figure out how we might be able to build/full-trust modern apps more cleanly in the future.
In the meantime, I hope this response helps, and hope the Terminal source gives you some inspiration as to how to craft your own apps.
I don't know such of options. Yes, DAC can contain the Full-Trusted Win32 apps, but it is only applicable for Win32. UWP - WinRT - apps are restricted with App Container.
The alternative option is - using the "Special capabilities".
Special and restricted capabilities
There are many of declarations that overcome the restrictions of sandbox. Some of these are not applicable for store submission - only for in-house deployment apps. Others need registration for Microsoft to deploy with store. If your requirement is matched, you can use it.
(Added - June 2017) From Win10 AU, we can use the "FullTrustLauncher" API to launch the Win32 component from UWP App. But, yes, it does not mean we can run the "UWP" - WinRT process with full-trust rights. It's applicable only for Win32 process. And, the Win32 app executable should be contained in the application's AppX package and the manifest should declare the executable as "windows.fullTrustProcess".
<Extensions>
<desktop:Extension Category="windows.fullTrustProcess" Executable="fulltrustprocess.exe">
<desktop:FullTrustProcess>
<desktop:ParameterGroup GroupId="SyncGroup" Parameters="/Sync"/>
<desktop:ParameterGroup GroupId="OtherGroup" Parameters="/Other"/>
</desktop:FullTrustProcess>
</desktop:Extension>
</Extensions>
FullTrustProcessLauncher Class
I'm using PDFCreator to create PDFs in VB6. My VB6 development VM is Windows XP 32-bit. On that system PDF generation works both from a desktop app and from ASP (via VB web class runtime).
When I create an exe to run on Windows 7 or Windows Server 2008 R2 or use it in the web class runtime I get:
Run-time error '429':
ActiveX component can't create object
This is when using early binding. I add a project reference to "C:\Program Files\PDFCreator\PDFCreator.exe" and then in my code I do:
Public WithEvents mPDFCreator As PDFCreator.clsPDFCreator
Set mPDFCreator = New PDFCreator.clsPDFCreator
If I don't use a project references and use late binding instead, then it works on the desktop app but still not in the web class runtime. Late binding is done like so:
Set mPDFCreator = CreateObject("PDFCreator.clsPDFCreator")
I want to use early binding so that I can use the events, plus I need it to work in ASP/Web Class Runtime.
I realise I'm dealing with ancient technologies here and I should have tempered expectations when running such things on modern 64-bit Windows and IIS. If porting this legacy app to .NET were an option, I would.
On IIS I have set the Enable 32-bit Applications setting on my app pool. I have also tried running it as Administrator to rule-out security problems.
I've done everything I know how to debug this, but I'm stumped. I suspect it has something to do with PDFCreator being a 32-bit app and COM registration. I've also tried running regsvr32 out of SYSWOW64 but PDFCreator.exe can't be registered.
Windows 64-bit architecture does not allow the load of 32-bit dll into 64-bit processes.
But you can modify the configuration of your vb project to convert it from an in-process dll COM component into an out-of-process exe COM server. This will allow you to instantiate your 32-bit component from a 64-bit process.
See Process Interoperability
Since this is a VB6 question there aren't any 64-bit processes to worry about.
It seems far more likely than anything else that this library just isn't being registered properly. I haven't use it since I don't know whether its setup works properly. I do know that the download itself does not display with a UAC Shield on its icon, suspicious in itself. For all I know the setup program spawns a run of the wrong regsvr32.exe.
But it seems more likely you have misregistered the library manually after copying it naked over to these 64-bit Win7/Server 2008 systems.
In any case, going over all of the symptoms you describe, I'd guess it got registered as a 32-bit ActiveX library but registered in the per-user virtualized part of the registry for the user you were logged on as when you registered it.
This can be a hassle to clean up after. However you should, and then be sure to manually run the original setup once again with elevation.
These threads that include hand-wringing over "ancient technologies" really get old. It's a poor workman who blames his tools. In the future why not hire an experienced programmer to handle tasks like this?
I use PDFCreator in my accounting software written in VB6. Years ago, I noticed that after a certain update from the makers of PDFCreator, my software stopped working properly with it. The problem stopped after I re-installed the older version, and came back when yet another new update was released from them, so I have had my customers freeze at the version that worked. I don't know off the top of my head what version that was, but I can check my own web site since I made it downloadable for my customers if it would help, but it's likely many years old now.
I have a ActiveX control hosting a flash-player which is in turn running a flash file trying to access data from a web-address.
In an old Windows Application version of my application everything works fine and the flash file is able to access the web-content.
However, in a newer Console Appliction version of the application it can no longer access the web-content.
Any ideas what might be causing this? Is there some kind of difference between a Windows Application and a Console application in terms of security/permissions that might affect an ActiveX hosted flash-player?
I'm using Windows 7.
First of all - how did you manage to get an ActiveX into a console application? :) I think ax needs window handles and all such things...
Anyways, there are different kinds of sandboxes from the Flash player perspective, what you are seeing is the "local not trusted" kind. In order to "trust" the SWF that issues the request you would need to use this page to confirm that the location where SWF comes from can communicate to the internet.
Doing so may be a hindrance for the user, but if this is the case, you could write the trust files on your own. Example
I need to create Solution Architechure for Windows Mobile and have following queries:
My application is like a service that will start in phone startup and that should run in background and have no UI (this is not a problem). I am using third party dlls (with source code) in my project. Does windows mobile have any problem of loading dlls when we put the application in start-up? If yes, should I include all souce code in my application (may be in AppCode folder)?
If I include all third party source code in application, my application executable size will be bigger. Will bigger size executable cause problem (slow mobile on startup or simply hang) if I put my application in start-up?
I have seen this video regarding starting applications quickly but seems that it does not apply to my case as my application does not have UI.
How should I create structure of my application such that loading application as service in start up will not have any issues?
Apps launched from the Startup folder actually launch pretty late - well after the shell is up. So no, there are no issues with launching from there. There are no problems with loading DLLs eitehr so you can put the library code in your app or leave it as a library - it makes no difference.