"Be strong and courageous. Do not be afraid or terrified because of them, for the LORD your God goes with you; he will never leave you nor forsake you." - Deuteronomy 31:6
This Github account officially represents the capabilities possessed as an individual pursuing more sophisticated methods of obtaining advanced technical literacy in the field of Cybersecurity and Offensive Cyberspace Operations.
- An "in-memory" DRM (Direct Rendering Manager) bitmap framebuffer control tool for low level screen capture functionality.
-
Could utilize extensions for X11 to target the display server or a custom/modified video compositor for subsequent success in further operations.
-
Taking information stored about each frame buffer (/dev/dri/card0, etc) and using it to further establish acceptable forms of operations.
-
May consider implementing a Bitwise XOR Copy style algorithm for capturing specific regions of the screen (i.e - targeting/reading different areas of memory) more efficiently.
-
Especially if such areas of memory are within a double buffer/page flipped memory region in which the frame buffer has enough memory (virtual) to store the current bitmap within half of its alloted address space contiguously, and the other half being stored before it is processed.
-
Can such information from the other half of the double buffer not in use be "readily" sent, stored, and updated as to appear to be peering into the future before it is sent to the main display?
- Whilst obtaining information regarding the GPU's current display modes via FB (frame buffer) interrogation, taking a closer look at the refresh rate, could this value be modified to lower the current refresh cycle further to increase the speed in which the frames are read by the operator before being sent to the main display driver?
-
-
Easy Explantion: It should be possible to capture bitmap scalar data frames (think about a single picture of your screen) before they are sent to the main display (monitor, TV, etc) in such a way that the screen refresh rate (think FPS) is incrementally lowered (would need to compensate for avg CPU load) over a set period to "allow" time to utilize the CPU without affecting the end-users reactionary gap (the time between noticing discrepancies within their environment) to stay undetected.
NOTE: Skeleton C source files have been developed, thus it seems such a process is indeed possible. Time and true low level understanding/techniques will consume a considerable amount of time.
Written in C++ OnionBatch/BatchOnion loader is a fast multi-media downloader that egresses outbound traffic through the TOR network.
- To get up-to date with the latest
Quiet Weeping Server
project click here. - To download the latest release (v1.2.2) with the associated source code and pre-built binary executable click here.
-
To view the current project with a more detailed overview click here.
-
To download the latest v1.0 release (zip archive) you can obtain it from here.
-
Learning the Rust programming language.
- Planning to create:
- Android based administration tool (android debug bridge wrapper in Rust)
- Linux agent w/ encrypted socket communications, obfuscation routines at runtime, etc.
- Planning to create:
-
Raw 802.11 a/b/g/n 2.4 GHz wireless deauthentication framework (Written in C)
-
In singular development of BrightStar.
- Adding small scale updates on occasion.
- Planning future roadmap for v2.0 feature set.
-
Learning Software Reverse Engineering with the Ghidra SRE framework.
-
Developing a DLL injection framework on Windows for process interaction and manipulation.
- Systematically identify vulnerable applications which allow the availability of non-privileged DLL hooking/injection, etc.
- Target specific applications or a subset of specific applications to test against.
- Future: Encrypted DLL loader (Encrypt target DLL files while in memory until they need to be decrypted for runtime execution)