A CS Source Engine² for creating cheat debug valve codes, exploring hidden game engine features, exploit development, assembly analyzer or a full network emulator, a custom scripting interface for study and cloud-based decompiler for testing (and binary analysis), think about it maybe as a basis for you to make your own tool, or use it however you want, after all it exists for studies.
! This project was created just for portfolio so I don't guarantee there will be updates and I can discontinue whenever I want.
- Network emulator
- Intercept encrypted logs and network traffic
- Intercept game and developer logs and hidden logs(Vac, Feedback and game crash/stuck)
- Draw on the game's own interface with their own API
- A custom injector based on syscall (know what you are doing first)
- Send your own network packets
- Modify network packages
- Store logs of captured or emulator packages for private analysis
- Use all processor cores for processing
- Own scripting systems that are easy to understand and learn
- Possibility of Disassembler by Address, Pattern, All .text section or all binary sections.
- Possibility of using a cloud-based decompiler provided by me for my own tests.
- Possibility to create patches in specific regions based on patterns or addresses using the scripting system.
- Possibility to remove and restore patch in specific regions applied.
- Possibility to disable or enable patches
- Possibility to download patches from other shared users to use
- Other functions that I want to apply or that someone contributes or improves.
The scripting language used was nicknamed by a friend of Kurumi Lang, with it it is possible to customize several tasks that the application must perform, new features may appear in the future, so I will introduce you a little about this scripting language
Let's assume you want to get the main executable from memory, hl2.exe, there are several ways to do this, so that you don't have to use external ways you can use the following script:
IMGBASE("hl2.exe")
With this, the base of the image will be automatically returned in memory, but let's suppose now that I had my IDA open and out of nowhere I found an instruction that checks the RVA 0x1234, I don't need to keep adding the address there is a much more process easy thanks to the scripting system, but before this use we use the concatenation symbol that tells the script that it must join both values, for example:
IMGBASE("hl2.exe")+RVA("0x1234")
The "+" symbol has the function of joining both addresses, and the RVA function will be used to retrieve that address and at the end we can obtain the relative address that contains that desired instruction, the prefix "0x" is not mandatory more help in identification. There is another instruction that also has a similar function, we can often work with compressed or virtualized or obfuscated binaries, and they do not always have a default address or RVA offset, in this case we use the memory byte patterns, the engine also supports you You can see an example of usage below:
IMGBASE("hl2.exe")+PATTERN("40??90??10")
That way the engine will know to look for the pattern in the mapped sections of the binary.
The scripting language is very important new features may arrive soon, and these features are used in two places you can check the screenshot below:
Sometimes you can choose the options more precisely what action you want to do, for example:
Another use for the scripting language is for the patching system, here's a quick example:
After we insert the script we are asked to insert the shellcode we want, in this next example I put two "nop" instructions, standard from the intel manual.
And after that, our engine prepared, activated the patch and left it on a list so that we can modify our game:
The scripting system is very useful and will definitely speed up your patch life and organization.
With the patch list system you can make several quick modifications, it is possible to create a new patch in a certain address or region of the binary or search by memory pattern, when created this patch is automatically activated and added to the list and from there you You can remove, disable or enable whenever you want.
Let's see more didactic usage examples:
In this example, on the 1st click a prompt will open informing you to insert the script for the engine, 2nd I inform this script, in this case I informed that it should look for the module "server.dll" loaded and direct to the RVA "0x122266" and there put a shellcode when clicking ok, notice that in 3rd the tree is normal, and that in the disassembler we can see the instructions responsible for aligning the leaf with the trunk of the tree.
1st Notice that the window requesting the shellcode was opened after pressing OK, I informed that it would be 0x90, 0x90, "referencing two nop instructions", basically the processor will ignore the execution and go straight, pay attention to the 3rd one which is the trunk of the tree aligned with its leaf.
Notice that in 1st a patch was added to the list, and the game was applied, see in 2nd that the instructions have already been modified in Disassembler View, 3rd you can see that we can already see the difference in the game and that the trees are no longer aligned with their change, 4th you can disable this patch or enable it whenever you want, and finally on the "-" button you disable the patch and recover all the instructions of the modified region that are stored as backup in a model class.
In the 1st you must inform the script you want to run, define a custom search option, and finally in the 2nd you will get all the Disassembler output after completion by the engine.
I'm working on my own compiler studying open source projects, currently I need a lot of binaries to study and improve, that's when the idea to create this function in this project came up, it's still under development but the technical details are as follows:
When a binary is sent to the server for decompilation, the content is encrypted with a private key shared between the user and the server, the server receives all the data and allocates a position in the queue for the user to wait until the binary is decompiled on the server. server and returns an index of the queue, this index is checked every period of time until the server indicates a payload of the content of the decompiler encrypting with the shared key that only the user has access, thus making the decompiled code available.
Here you can check out videos I recorded, showing how the project works and its features, I hope you like it.
Here you can download all my IDB's and my complete analysis see my organization chart while I was developing my project, I hope this helps you to learn or share more knowledge and improve the project.
- client.dll.idb (IDA 7.5)
- engine.dll.idb (IDA 7.5)
- server.dll.idb (IDA 7.5)
- steamclient.dll_after_21_09_2022.idb (IDA 7.5)
- steamclient.dll_before_21_09_2022.idb (IDA 7.5)
- tier0.dll.idb (IDA 7.5)
You can contribute to the project by suggesting features or improvements.
Any like, issue, PR's are welcome, as long as they are polite and good for the long-term development of the project, as it is a testing project.