Microsoft Edge hooking

c++ / delphi package - dll injection and api hooking
nomen
Posts: 48
Joined: Wed Jun 25, 2008 7:15 am

Re: Microsoft Edge hooking

Post by nomen »

Thank you Madshi!!
I wll try it.
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Microsoft Edge hooking

Post by iconic »

Nomen,

That Nektra.com blog article about Windows modern UI apps has some inaccurate information. The main thing is, the injected DLL mainly just needs to have the ALL APPLICATION PACKAGES group added to its security permissions, and of course as already mentioned avoid manifests. According to that article, one which I read nearly 2 years ago, suggests that you are unable to inject a DLL from an absolute path into a Metro/Modern UI app and that also it needs to be signed. None of this has ever been true, I've no idea what the authors are doing to trip themselves but it's simply untrue and inaccurate. The only thing they are correct about is that ALL APPLICATION PACKAGES is a must and that if you copy your DLL to System32 (could also be Windows or Program Files etc.) your DLL will automatically inherit the container properties of the parent folder, in this case ALL APPLICATION PACKAGES will be added to your DLL's file permissions automatically. I've taken the liberty to power on Windows 10 Professional x64 and have injected an "unsigned" DLL into MS Edge from a custom path to help alleviate any of your confusion. *Note* I did not use MCH for the injection but it doesn't matter since I don't need it to illustrate my point

Image

--Iconic
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Microsoft Edge hooking

Post by madshi »

Just got note from another madCodeHook customer, who had problems with Edge injection in Windows 10. After I told him to add ALL APPLICATION PACKAGES, injection succeeded. So it clearly works just fine in general. There must be something specific about Nomen's hook dll which stops it from being injected successfully.
nomen
Posts: 48
Joined: Wed Jun 25, 2008 7:15 am

Re: Microsoft Edge hooking

Post by nomen »

Ok, I see: the problem is in my code or in project setting.
As Madshi says I will start with PrintMonitor and put my code step by step.
Thank you very much for your help!

I will tell you.
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Microsoft Edge hooking

Post by iconic »

Nomen,

Yes, it's a wise idea to use PrintMonitor as a project basis or template. As you stated a few days ago
But there is a curious thing because I can check with Process Explorer that the HookPrintAPIs64.dll is loaded
--Iconic
Sirmabus
Posts: 89
Joined: Fri May 28, 2004 6:20 pm

Re: Microsoft Edge hooking

Post by Sirmabus »

Apparently just "ALL APPLICATION PACKAGES" rights (DLL directly, or entire dev folder) alone is not enough.
I found this in doing tests recently. With Windows 10 we probably need to have our DLL cross-signed like it says in that article.

What I found that does work is to put my DLL in any of the following folders (at the root or any sub folder):
"C:\Windows"
"C:\Program Files"
"C:\Program Files (x86)"

Try injecting/loading your DLL from one of those folders.
First try a DLL that just loads, don't hook anything. Attach WinDbg to the target and see if your DLL is in the 'lm' list.
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Microsoft Edge hooking

Post by madshi »

Why is nothing of that necessary with my demo then?
Sirmabus
Posts: 89
Joined: Fri May 28, 2004 6:20 pm

Re: Microsoft Edge hooking

Post by Sirmabus »

I'm not the OP. Just trying to help :-)
I wanted to avoid getting into the whole WinRT world my self, but now do some project in it for fun.

Also he should try this at least for troubleshooting, under "Settings" , "UPDATES & SECURITY", "For developer": set to "Developer Mode".
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Re: Microsoft Edge hooking

Post by madshi »

Help is very welcome, of course. It's just that my demo managed to inject Edge successfully on my Windows 10 machine, and also on the PC of the OP, without needing to be cross signed or be stored in a specific folder. So all evidence points to these things not being necessary for successful injection.
nomen
Posts: 48
Joined: Wed Jun 25, 2008 7:15 am

Re: Microsoft Edge hooking

Post by nomen »

Forgive me but I have not had time to do more tests, I'm very busy these days.
I'll try next week.
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Microsoft Edge hooking

Post by iconic »

@Sirmabus

Have you read my previous post in this thread or seen my posted screen shot of doing this in Windows 10 with an unsigned DLL from C:\1\2\3? I needed nothing more than to add ALL APPLICATION PACKAGES to my DLL. There's no other "magic" required. A picture is worth a thousand words. If you are able to reproduce an unsuccessful injection with this alone please share your project parameters

--Iconic
Sirmabus
Posts: 89
Joined: Fri May 28, 2004 6:20 pm

Re: Microsoft Edge hooking

Post by Sirmabus »

Yep, got it to work just had to reboot after setting the access rights for what ever reason.
I set the root of the project's folder to "ALL APPLICATION PACKAGES" which in turn sets the DLL or anything else I build in it with the needed rights.

Now I'm trying to figure out how to break out of the sandbox or what ever they are doing to that's keeping my DLL from writing a a log file..

EDIT: Problem solved:
Apparently the store app setup doesn't want you to open a file in any arbitrary location.
Trying to open a text file in "C:\", or even in the source App folder, etc., were all met with an HRESULT code of "Access is denied".
But it will let me create one from where my DLL exists, which is pretty ideal anyhow.
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Microsoft Edge hooking

Post by iconic »

Hi Sirmabus,

Glad to hear that it's working. These modern UI apps are sandboxed and inside their own "containers" which have IDs. Basically, file access is restricted by its token unless, as you noticed, a specific directory has the appropriate permissions group added, otherwise you'll see ACCESS_DENIED left and right. On top of file access, which also has a profound effect on some IPC (pipes, mailslots etc.) they also restrict local loopback access. You have to proxy this from WFP if you want to redirect any network communications to the local machine from what I've read. While I like the fact that MS is hardening security of these processes it's also a bit painful for developers. An example, say you had a legitimate reason to attach a debugging thread to one of these apps while it's in a suspended state. This will fail because the dbg thread will timeout since it is also suspended at the kernel level so you never gain entry. You can attach WinDbg to a sleeping/suspended metro app to verify this. To my knowledge there is no special Win32 API call that will allow you to wake your thread up directly, even trying ntdll!NtResumeProcess does not work yet yields a STATUS_SUCCESS return. Moreover, calling PsResumeProcess() in kernel land also doesn't change the end result. Metro apps have their own broker relationship and in order to dig into this massive layer of COM abstraction you need to play by their rules. Sucks for developers to be honest and anything that uses interfaces and is abstracted through COM is bloat to me. Just my 2 1/2 pennies

P.S: Throw system32\threadpoolwinrt.dll into IDA and you'll see what a mess these WinRT/Metro UI apps are

--Iconic
Sirmabus
Posts: 89
Joined: Fri May 28, 2004 6:20 pm

Re: Microsoft Edge hooking

Post by Sirmabus »

Thanks much.

The internals seem to have little documentation if at all.

Have you figured out how to reverse these in a meaningful way?

From what I understand so far is you submit your application to the MS store as .NET code.
At Microsoft they take this code and compile it to platform targets.
So if you have a PC version they will target it to x86 machine code, then one for native ARM code as well.
Apparently wrapping up a lot of the stuff that would normally be in .NET DLLs, etc., into one primary application DLL.
If your app is "MyApp" it will create a very thin MyApp.exe which loads the MyApp.DLL where your actual code is.
Part of their plan to be able to run these on not just PC, but some on MS phones and the Xbone et al.

As you know you can easily decompile .NET assemblies, but then these appear to be a different story..
iconic
Site Admin
Posts: 1065
Joined: Wed Jun 08, 2005 5:08 am

Re: Microsoft Edge hooking

Post by iconic »

The internals seem to have little documentation if at all.
100% agreed
Have you figured out how to reverse these in a meaningful way?
My time is of the essence so for now I am just dabbling with these apps and investigating how they function internally

P.S: Thanks for the info

--Iconic
Post Reply