This program is created for educational and research purposes only. Installing software on systems you do not legally control without the consent of the owner is a crime! The computer fraud and abuse act is no joke and you could face fines or jail time.
UIAccess is a windows permission that allows screen readers and other assistive technologies to have more access to the user input and to the graphics systems that render windows. Part of this access is the ability to create what is unoficcially called a super topmost window. Normally a window can be either topmost or not. Topmost windows are renderred above other windows regardless of focus. However system popups still go in front of topmost windows. So does task manager when it is set to always on top mode. Luckily we can bypass this with UIAccess. When a process with UIAccess requests its window be topmost something slightly different happens. The window is actually put into a super topmost state where it is in front of everything. It is even on top of the alt + tab menu and other system popups. The only things which are still in front of a super topmost window are the ctrl + alt + del menu and other instances of the secure desktop like administrator popups. These popups are considered to be in the secure desktop which is always on top of any windows in a normal desktop including super topmost ones. The mouse cursor is also above our window.
The UI Access permission is highly restricted as it can cause serious annoyance and is a tempting API to abuse for developers. As such Microsoft restricts the user of the UI Access permission to apps which request it in their manifest, and which are signed with a trusted cirtificate. Forging a certificate is beyond the scope of this paper so its lucky that there is another way. System processes such as the shell (explorer.exe) need to be able to give out the UI Access permission to other apps which are signed and deserve it. To do this they use the SetTokenInformation function with TokenUIAccess set to True. Unfortunately the windows developers are smart and thought of this already and in order to call SetTokenInformation on TokenUIAccess you need to already have UIAccess to start with. This makes no difference for the kernel which is above the concept of permissions and then from there each system app with UIAccess shares the permission with the next. But for us this creates a bit of a parodox. In order to get UIAccess we need to already have it in the first place. Another restriction of SetTokenInformation is that it can only be called on brand new tokens. Once a process is created with a token it can no longer be changed with SetTokenInformation. Luckily that is an easy fix. Once we get a token with UIAccess we can just duplicate it and then use the CreateProcessAsUser function to restart the current process under the new token. But we still need to find a way to get UIAccess even just for a tiny second so we can create a new token with it. Luckily we have one more trick up our sleve. Impersonation. We can impersonate a system process like winlogon.exe by making a copy of its token and then using the SetThreadToken function to temporarily impersonate winlogon's token for our thread. This allows us to have UIAccess through impersonation for just a second so we can copy our own token, give it UIAccess and restart the app with that new token. YIPPIE!
But that's like really complicated... I hear you say. Do we really need to do all that? Yes every single step of this process is required and here is why.
We can't restart the process with UIAccess until we have a UIAccess token. We can't give UIAccess to the current process token because you can't change token information after a token is used. We can't just give UIAccess to a copy of our token because you need UIAccess in order to give UIAccess. We can't just launch our process with the winlogon token because it's already in use by winlogon. We can't just launch our process with a copy of winlogon's token because its setup to not allow that and we get access denied. We can't just call it good enough after impersonating the winlogon token because impersonating a token with UIAccess doesn't seem to work quite the same as actually having UIAccess and you're windows are still not super topmost.
Huge shoutout to https://github.com/killtimer0/uiaccess/ for being the inspiration for this project!