Using the full WINAPI within an AppContainer Application(Windows 10)

I successfully injected a DLL into Microsoft Edge while it is suspended, using COM API.
(EnableDebugging(), ActivateApplication())

While it is suspended, i’m creating a remote thread within the Universal App process context, but it seems that because of the SID and Groups policy restrictions that AppContainer enforces on the process, the DLL cannot call any API or use any straightforward system resource (filesystem, sockets)

I tried to change the Application’s token with 2 methods:

Using a kernel module, replacing the token in the struct EPROCESS with a token that belongs to the system process / a token that belongs to an administrator.

Microsoft Edge/Calculator refuses to launch with this modification.
Using OpenProcessToken() and SetThreadToken() to the Application’s main thread, doesn’t seem to work either, even if i have the ‘Replace process level token’ privilege. Edge, refuses to launch, once again.
I cannot change the DLL to use the only API that is allowed within an AppContainer, since it is very limited and doesn’t provide what i need(sockets and full filesystem access)

I can actually use some of the APIs, they’re not blocked to the process, but when Windows is performing an access check on some of them, thats where i get blocked.

Is there any other method?

Thanks.

Yes, don’t inject the dll as is or change it to be compliant. What you are trying to do will break app container and allow the proceeds to acces the same things your dll is trying to access, which is the whole point of app container. What does this dll of yours do that makes you compelled to inject it into an app container process?

Bent from my phone


From: xxxxx@lists.osr.com on behalf of xxxxx@gmail.com
Sent: Saturday, April 8, 2017 5:52:53 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Using the full WINAPI within an AppContainer Application(Windows 10)

I successfully injected a DLL into Microsoft Edge while it is suspended, using COM API.
(EnableDebugging(), ActivateApplication())

While it is suspended, i’m creating a remote thread within the Universal App process context, but it seems that because of the SID and Groups policy restrictions that AppContainer enforces on the process, the DLL cannot call any API or use any straightforward system resource (filesystem, sockets)

I tried to change the Application’s token with 2 methods:

Using a kernel module, replacing the token in the struct EPROCESS with a token that belongs to the system process / a token that belongs to an administrator.

Microsoft Edge/Calculator refuses to launch with this modification.
Using OpenProcessToken() and SetThreadToken() to the Application’s main thread, doesn’t seem to work either, even if i have the ‘Replace process level token’ privilege. Edge, refuses to launch, once again.
I cannot change the DLL to use the only API that is allowed within an AppContainer, since it is very limited and doesn’t provide what i need(sockets and full filesystem access)

I can actually use some of the APIs, they’re not blocked to the process, but when Windows is performing an access check on some of them, thats where i get blocked.

Is there any other method?

Thanks.


NTDEV is sponsored by OSR

Visit the list online at: https:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at https:

To unsubscribe, visit the List Server section of OSR Online at https:</https:></https:></https:>

Automation testing. Currently changing the DLL is not the task(since it is HUGE and uses some respectable amount of system resources), but rather trying to break the AppContainer is the task.

Well the main problem is that my DLL uses named objects(mutex, semaphore, and file mapping), but these named objects exist only in appcontainer namespace, i can’t communicate with my DLL at all… (since other objects live in the administrator namespace, not appcontainer). Thats only one of the issues…

I think you could create global named object from the different process which has enough privelegies to do it and apply SDDL:

// S:(ML;;NW;;;LW) - access from Low Integrity
// D:(A;;GA;;;WD) - access for Everyone
// (A;;GA;;;AC) - access for AppContainer (Windows 8 or greater)

I use same method to communicate with AppContainer application through ALPC port and it works for me.