Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

In Windows, many of the functions work with from the GUI with callbacks. This means that after some action is performed, then the callback function is made.

While using functions such as xxxMenuWindowProc and others of the GUI API, there is an issue with the callback setup However, this pattern is complicated, especially when functions may have side effects on some objects. What if the object type changes between the original call and the callback? Type confusion!

My first thought would be a race condition, since a type change between a threaded application would make sense. Instead, there is a complicated flow of callbacks being exploited. By setting up the callback xxxClientAllocWindowClassExtraBytes to trigger the NtUserConsoleControl method.

When the NtUserConsoleControl method is ran within the callback, the type has changed! However, upon further usage of the object in its current context, there is no check for a type change.

What does the type confusion do? There are likely many things this corrupted. The main one is that this leads to a user mode pointer being treated as the offset to a heap. This leads to an out of bounds access: both a read and write.

Using the OOB read and write, exploitation in the kernel probably is not too complicated. Interestingly enough, this was found being used in the wild! It was patched in the Windows January 2022 update.