A cross-platform, lightweight anti-cheat and digital rights management security solution supporting both x64 and x86 architectures. Developed entirely in C++17, without the use of non-native dependencies.
Cybersecurity
The differences between anti-cheat and digital rights management (DRM) is simply how the system is used. On one hand anti-cheat helps prevents cheating in games, and on the other digital rights management (DRM) helps prevent piracy in software. However, both systems boil down to utilizying anti-tampering and analyitcal techniques to ensure that a software as a service (SaaS) is used as intended without unauthorized modification.
Identifies the device being used in a variety of different ways. This collective data can then be used to identify which accounts are being used by the same individual as well as provide further analytics. In an anti-cheat setting, this can be used to help prevent ban evasion and account sharing. While in a digital rights management (DRM) setting, this can be used to enforce hardware related licensing systems.
Determine the possibility that the application is being run within a sandbox application environment. This is important as the use of a sandbox can prevent the security system from working as indented.
Through the use of various techniques, determine the possibility that the application is being run within a Virtual Machine, rather than on the host device.
Specified files can be verified through a cyclic redundancy check (CRC) to ensure that these files have not been modified in any way. In addition, unexpected foreign files within the application folder will be detected.
Certain processes and modules can be defined as Hack Tools, Macro Tools, Analysis Tools, Sandbox Utilities, Virtual Machine Utilities, and VPN Utilities. The process monitor can then identify and flag these processes when detected. This information may be used to provide further user analytics or perform certain actions upon discovery.
Proactive measures are taken to ensure it is more difficult for a debugger to obtain important information from the protected application. In addition, the debug monitor will detect if a debugger has been attached by the user.
Multiple techniques are used to ensure the process of obtaining an accurate memory dump from the application is as difficult as possible.
Compile time literal string encryption ensures that raw string data will never be exposed within the build files and prevent users from locating the protected string information in memory. Every build uses a different randomly generated seed to ensure the encryption method is never the same.
Secure variable types can be used to ensure that specified variables are encrypted and cannot be located and modified. This is used to protect the data contained within these variables and ensure they cannot be be edited within the memory.
The speed of which the application is currently running at is compared against the expected speed of the application to determine whether or not the process is being accelerated.
Threads can be manually verified within the applications code upon their creation. Providing the capability of using thread verification checks throughout other parts of the application. These checks will detect whether or not the function calls come from a verified thread of an outside unauthorized source.
Return address verification checks can be placed throughout important parts of the application. These checks will detect whether or not the function calls are coming from within the application itself or an outside unauthorized source.
Additional instances of the application running on the same machine will be flagged. This can be used for analytical purposes or to restrict the number of instances of the application that can be running simultaneously on one device.
Information such as file verification, device identification and all detection flags are generated into report structures for analytical purposes. This information can be sent to a server and used to help find weak points in the system as well as identify those that are using the application with malicious intents.
An internal heartbeat is sent periodically that can be caught by other parts of the application. The periodic reception of this heartbeat can be used in order to ensure that the security system is still running and perform certain actions if it has been disabled.
An external heartbeat is sent periodically that can be caught and sent to a server. If the server does not periodically receive this heartbeat, it can assume the security system has been disabled and perform certain actions.
Developer Portfolio
By Mazen M.