VAC detection

[Jacckii]

VAC detection
Since CS:GO update in February 2022, CS:GO started to check cvars such as m_bSpotted, m_flFlashMaxAlpha, m_clrRender, and many more. This means most of the features of this cheat are by now detected. Tho the VAC ban may be delayed by 1 or more months. This may be due to many reasons as:

• collecting and training AI using your data
• to make it harder to analyze what's detected and what's not
• many more...

To Reproduce
Turn only the radar feature in-game and normally play, ignore the extra radar info, within a few games you will start getting rage cheaters against you, which means you have moved into low trust factor games.

The trust factor is Valves' measure of how likely are you going to cheat, since you've played legit while reproducing this problem, your play style or reports shouldn't matter. That leaves you only with the detection factor. So they've detected you and successfully flagged you as a cheater and changed your trust factor accordingly.

I have personally tested this on a known good account with green trust with many hours on record. The driver was manually mapped into memory using a different signed driver.

Solutions
Those checks can be easily hooked, and therefore prevent CS:GO from detecting you.

For me, I rather chose a different path, such as only reading the memory of the game and rendering data collected from the game on WebRadar. But that may be too much paranoid approach.

I would just note in the README file in the VAC section, that everything except Aimbot, and Trigger bot may flag you as a cheater there for lowering your trust factor and possibly banning you in a few months.

[dretax]

Thank you for the notice. I haven't been following CSGO changes for quite a while due to lack of interest, and other cheating projects we maintain.

If thats the case, the solution to this is rather simple, we stop writing those netvar flags, and we will utilize imgui to render data.
Since Garhal is an (early?) POC that provided an example for many-many people I'd like to retain the original form of the controllers, and a separate new project would be fitting for this cause, thus 2 examples can be seen in this repository. I should be able to start this sometime.
Let me know what you think.

[Jacckii]

Yes, a separate project would do just fine.
How do you plan to render the data tho?

[dretax]

Nothing advanced / secret, a basic implementation is sufficient for this public project. I'd probably create or hijack a window/overlay, and render the players based on their bone matrix.

[Jacckii]

wouldn't that be another detection vector that could possibly be detected in the near future?

[dretax]

@Jacckii Honestly everything can be a detection vector in that aspect.
There are various solutions we utilize for our BattlEye, and EAC projects, but judging by the fact that VAC has taken years to even check simple fields change like those I doubt they will quickly adapt to do so.
I think leveling the project accordingly to VAC's state should be more than enough, the window part shouldn't be a concern for VAC honestly, they would need to know how to distinguish between proper overlays first. Detecting "malicious" read memory even from kernel side, well... good luck with that.

From the base changes you can always go ahead, and read how to make your project more advanced kernel-mode / user-mode wise. I'll try to do this quickly next week, this week was just too busy for me.

[dretax]

Alright. I got the whole base code ready to be merged soon, I'm working on making the menu now, and involved @ThePaimon who likes doing menu designs.
From there I just need to render the csgo player bones approprietly with some customization added, and remove most of the parts where we write in the memory aside of the aimbot feature.

[dev5tar]

@dretax does the fork currently being updated have the ret addr checks sorted? Looking forward to seeing the release. Great stuff.

[dretax]

@dev5tar this is an external project thus we do not call functions internally, and there is no point in patching any checks. We will be just reading memory, optionally writing some.
I'm updating the project to avoid writing into the glow, and other certain properties to allow users to avoid unwanted trustfactor issues with their latest checks on them.

[dretax]

Ready! Now just @ThePaimon has to finish a quick design and I'm ready to make the first stage released.

[dretax]

@Jacckii @dev5tar @skhrlx @lordkronos
Consider this sort of done. There are still various things to work on, some things we will be adding along and working out.
Right now the only major issue is the bone scaling approprietly by the distance, probably transforming the position to the local player camera matrix would fix the issue.
I'll be fixing that hope you will like the current example.

• Readme updated accordingly