Jump to content

Chod

Administrator
  • Posts

    1,795
  • Joined

  • Last visited

  • Days Won

    378

Blog Entries posted by Chod

  1. Chod
    Gaming is one of the most popular forms of entertainment worldwide, with millions of players spending countless hours exploring virtual worlds, battling against other players, and completing quests. However, some players look for ways to gain an unfair advantage by using cheats or hacks to manipulate the game's mechanics. To counter this, game developers have implemented anti-cheat systems to prevent such behavior.
     
    Modern anti-cheat systems use sophisticated techniques to detect and prevent cheating. These systems work by analyzing the game's code, identifying patterns of behavior that suggest cheating, and taking appropriate action. While these systems are effective, they are not perfect, and game hackers have found ways to bypass them.
     
    One of the most significant technical difficulties facing game hackers is the use of encryption and obfuscation techniques by game developers. Encryption and obfuscation are techniques used to make the game's code more difficult to read and understand. This makes it harder for hackers to reverse engineer the game's code and find vulnerabilities that they can exploit.
    Another difficulty facing game hackers is the use of server-side validation. In some games, critical game data, such as health points and in-game currency, is stored on the server rather than the client-side. This makes it difficult for hackers to manipulate this data, as any changes made on the client-side will be rejected by the server.
     
    In addition, game developers have also implemented behavior-based anti-cheat systems that analyze player behavior to detect cheating. These systems monitor a player's mouse movements, keystrokes, and other inputs to identify abnormal behavior that may indicate cheating. This makes it more difficult for hackers to use automated tools to cheat, as these tools may trigger the anti-cheat system.
    Another difficulty facing game hackers is the use of machine learning algorithms by anti-cheat systems. Machine learning algorithms analyze large amounts of data to identify patterns of behavior that may indicate cheating. These algorithms are continually learning, making them more effective at detecting cheating over time. This makes it harder for hackers to develop cheats that can evade the anti-cheat system.
     
    Despite these challenges, game hackers continue to find ways to bypass anti-cheat systems. One of the most common techniques used by hackers is code injection, which involves injecting code into the game's memory to manipulate game data or bypass anti-cheat measures. This technique is challenging to detect and prevent, as it can be done without modifying the game's code.
    Another technique used by hackers is the use of virtual machines or sandboxes to run the game in a controlled environment, allowing them to modify the game's code without being detected by the anti-cheat system.
     
    In conclusion, game hackers face numerous technical difficulties when attempting to bypass modern anti-cheat systems. These systems use sophisticated techniques, such as encryption, server-side validation, behavior-based analysis, and machine learning algorithms, to detect and prevent cheating. While these systems are not perfect, they are continually improving, making it more challenging for hackers to bypass them. As such, game developers must continue to invest in anti-cheat technology to maintain the integrity of their games and provide a fair and enjoyable experience for all players.
  2. Chod
    The old version of the framework was first developed in 2016, and at the time seemed like the best project I had written so far in terms of flexibility, reusability and certainly from a design point-of-view. However, over the years it got chopped and changed so much that it became a bombsite of code; it worked, but was not pleasant to work with.
     
    One thing in particular that became apparent over time, was that developing cheats with the old framework was quite time consuming. This was because when creating the layout for a menu, all the element creation had to be done manually line-by-line by the cheat developer. In some cases, this could take up hundreds and hundres of lines of code, adding both bloat and creating a messy project. So someting I wanted to address in the new framework (its called V5 btw) is the time it takes to create a GUI...
     
    Enter the GUI Studio... This new tool allows a developer to create a menu in real-time using an graphical user interface, save it to a GUI Document, then load it into the program in one line of code. Here's a short video demonstrating the studio: 
     
    There are a lot of elements missing currently, but you can see the basic creation of a window, two text boxes and a button. The studio allows for the easy parenting of an element to any other element, and correctly handles relative positions. It also features drag snapping for easily aligning objects along a axis. Once the GUI document is exported, it gets converted into an XML document that looks like this:
     
    <?xml version="1.0" encoding="utf-8"?> <document> <meta version="100" /> <element name="Window_0"> <type>V5Interop.Window</type> <enabled>true</enabled> <hidden>false</hidden> <position_x>187</position_x> <position_y>158</position_y> <size_x>400</size_x> <size_y>210</size_y> <parent /> <backgroundcolour>34,35,43,255</backgroundcolour> <label>Please Login</label> </element> <element name="tbUsername"> <type>V5Interop.TextBox</type> <enabled>true</enabled> <hidden>false</hidden> <position_x>46</position_x> <position_y>25</position_y> <size_x>300</size_x> <size_y>20</size_y> <parent>Window_0</parent> <label>Username</label> </element> <element name="tbPassword"> <type>V5Interop.TextBox</type> <enabled>true</enabled> <hidden>false</hidden> <position_x>46</position_x> <position_y>64</position_y> <size_x>300</size_x> <size_y>20</size_y> <parent>Window_0</parent> <label>Password</label> </element> <element name="Button_0"> <type>V5Interop.Button</type> <enabled>true</enabled> <hidden>false</hidden> <position_x>267</position_x> <position_y>144</position_y> <size_x>100</size_x> <size_y>20</size_y> <parent>Window_0</parent> <fontsize>12</fontsize> <label>Login</label> </element> </document> The beauty of this system is that if a developer wants to change how the menu system works for their cheat, they can adjust it with the studio, save to XML, then upload to the server. No changes are required to the code for the GUI to be changed.
     
    Some of you may be thinking "This looks a lot like OSH GUI". Well, you're not entirely wrong. I was so impressed with the designer from OSH GUI that I wanted to replicate its ease of use and the properties panel. Gladly though, that's the extend of the similarities. While OSH uses a secondary managed renderer for displaying the elements, what we did was to pipe our D3D11 renderer through to the managed canvas, thereby only needing one renderer.
     
    One of the hurdles we had to overcome was the pathway of managed -> unmanaged code. One option would be to pInvoke everything we needed, but this would have been a huge task as the V5 Framework is quite extensive. Instead, we created an CLR interop library that acts as a middle man. For example, let's look at the code that creates a text box. Firstly in our managed front end we issue the CreateUITextBox call to the interop library:
     

     
    And the interop part:

     
    In the interop library, we perform the necessary conversion from the label to wchar_t*, then we issue the CreateElement call to the native back-end. CreateElement returns a pointer to a V5::TextBox, given a parent element, a initial position, and a label. Using this pointer, we create a managed TextBox object, and give it a reference to the native pointer. The managed TextBox simply acts as a wrapper around the native pointer so we can still use OOP on the text box from managed code. After this, we add the managed text box to the _items List and return it. The native back end of course keeps its own list of created elements, but that's not important.
    That's pretty much it, all the coder has to do on their end is one line of code:
    V5::gGuiManager.LoadDocument(L"Gui\\Login.xml", this); Where this can either be an existing gui Element to parent all the objects to, or null.
     
    I hope you enjoyed this one, next time the wait shouldn't be as long. If there's something in particular you'd like me to cover, please reply and let me know.
  3. Chod
    Today I had planned to implement some more of the missing features into Tarkov, and did eventually end up achieving that, but ended up spending far too long doing smaller jobs. 
     
    The first thing on my list was to implement loot esp into Tarkov. Simple enough, as it was mostly a case of copying the code from the old cheat into the new one and fixing up the differences. Well, for the most part this was true, except I made a stupid typo in the vector class that took me over 2 hours to diagnose. 
     

     
    Embarassing that it took me so long to spot it, but there you go.
     
    After fixing this small but significant problem the loot ESP and snap lines were working correctly:
     

     
     
    Something else that had been annoying me is the font renderer. If you look back to a post I made in September, the text is not looking great. The font is squashed together, the outline is really bad. And generally its not pleasant to look at.
     

     
    So to fix this, I fixed the spacing between characters by adjusting the amount of alpha that a pixel must emit before it is considered "the edge" of the glyph. Next up the outline, for this I changed the font pre-generator so that it doesn't smooth the outline, creating that kind of patchy outline you can see above.
     
    The results looked like this:
     

     
    Whilst I was making changes to the font system I also found a bug that once fixed, improved text rendering speeds by about 4x, the effects were immediately noticeable and the ESP is silky smooth now.
     
    That's it for today, more soon...
     
  4. Chod
    I've been wanting to start a devblog for some time, and in hindsight I wish I had started it months ago when I first started working on the new framework, but I suppose its not too late. Anyway, the point of this is to give you some insight into how I do things from a coding perspective, show you what I am working on currently, and some previews of things to come. 
     
    What with all the changes happening currently it seems like it would also be a good way to keep you all engaged and interested in the new cheats when they are finally ready. So, please follow this blog, I will keeping posting things as regularly as I can manage, starting tomorrow.
     
    Chod
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines.