Abstract I used to be a Java/PHP/PolymerJS developer for 2 years before joining the wonderful information security industry and developing in C/C++ and C#. I'm probably not a great programmer but a least I'm documenting my code! Trust me, well documented code will save your butt. I have subscribed to a professional GitHub account few weeks back, which gave me access to the 3000 minutes of GitHub Actions per months. GitHub Action is awesome because this allow developers to create custom software development life cycle (SDLC) workflows, directly from GitHub. For each workflow you can define custom jobs and tasks. My plan was to use GitHub Actions to automatically generate and deploy Doxygen documentation when I push code to a master branch. In our case we will have one job with two tasks. To archive that, I am using the following GitHub Actions: mattnotmitt/doxygen-action@v1.1.0; and peaceiris/actions-gh-pages@v3 First one will be used to generate the HTML documentati

0x00 Abstract Allowing direct access to named or un-named executive objects to user mode and kernel mode applications would be extremely dangerous as it would interfere with, and render the duty of the executive subsystems obsolete. As a result, this would put the whole system at risk and make the management of executive objects almost impossible. Additionally, executive objects resides in kernel memory, which means that if user mode applications could directly modify data structure in kernel memory this would also be extremely dangerous and chances of a BSOD would be high. Driver and kernel applications can obviously directly access these data structures, however, most of the objects are undocumented and therefore it is highly recommended not to do so. Instead drivers and kernel applications should (must) use kernel APIs exposed by the different executive subsystems. Finally, they should also increase (i.e. ObfReferenceObject ) or decrease (i.e. ObfDereferenceObject ) the executiv