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

[dretax]

Hey @Jacckii. I just wanted to revisit this issue, as I have yet to correctly align the bone positions, and that's something that came into my mind :D

Have you been using Garhal by any chance, and experienced trust factor changes?

[Jacckii]

Hey @dretax, I've been testing the trust factor problem for a while now, so far my 3 testers that use a modified version of this didn't get into the "red trust factor" or at least there is no lobby message saying otherwise when played with high trust factor players. They've experienced cheaters in 1 of 3 match-making games, but that may be due to the high amount of reports.

In my "modified" version, I have removed all writings to the memory just in case, so all I do is read memory.

But yet a VAC auth error occurred quite a few times. I'm not sure if it's due to the driver or something in the usermode application.

And about bone aligning, it's a problem in the world 2 screen function, I have mine working I can make PR if you want with a working version.

[skhrlx]

Currently, I'm using the old garhal modified, my plan it's work with features that only read the memory to avoid future detections since they can notice write to memory and detect features like the noflash, and bhop that got untrusted.

My modified garhal has these features:
Sonar (Using a simple Beep() and the logitech integration changing my mouse color to red)
Aimbot (Using arduino to aim to enemy's)
RCS (reading the punch angles and converting it to my arduino move my mouse)
Triggerbot (using arduino to mouse click)
BHOP (using arduino for mouse scroll)
Logitech LED SDK integration (working with the sonar)

I known that is unnecessary for bypass the VAC, but I worked on my project just for fun, and now it's working well and I belive that it will not get me untrusted or VAC banned.

I'm making my own poly engine for now...making slow progress day-by-day, since I have no time 👍

[Jacckii]

@skhrlx did you experience VAC auth errors kicking you from MM servers too?

[skhrlx]

@skhrlx did you experience VAC auth errors kicking you from MM servers too?

No, I don't

[Jacckii]

Perhaps the VAC error could be something with my mouse_event call since you're using Arduino to do this instead.

[Jacckii]

Hey @Jacckii. I just wanted to revisit this issue, as I have yet to correctly align the bone positions, and that's something that came into my mind :D

Have you been using Garhal by any chance, and experienced trust factor changes?

I have made a pull request with a fix for the bone position alignment problem you have.

[dretax]

Hey @dretax, I've been testing the trust factor problem for a while now, so far my 3 testers that use a modified version of this didn't get into the "red trust factor" or at least there is no lobby message saying otherwise when played with high trust factor players. They've experienced cheaters in 1 of 3 match-making games, but that may be due to the high amount of reports.

In my "modified" version, I have removed all writings to the memory just in case, so all I do is read memory.

But yet a VAC auth error occurred quite a few times. I'm not sure if it's due to the driver or something in the usermode application.

And about bone aligning, it's a problem in the world 2 screen function, I have mine working I can make PR if you want with a working version.

Sounds good. Yeah I assumed It was just never actually had the energy to come back to the Garhal project, I always got something else to roam with when on PC and they are good topics on our projects. Thanks for the PR and the info.

Currently, I'm using the old garhal modified, my plan it's work with features that only read the memory to avoid future detections since they can notice write to memory and detect features like the noflash, and bhop that got untrusted.

My modified garhal has these features: Sonar (Using a simple Beep() and the logitech integration changing my mouse color to red) Aimbot (Using arduino to aim to enemy's) RCS (reading the punch angles and converting it to my arduino move my mouse) Triggerbot (using arduino to mouse click) BHOP (using arduino for mouse scroll) Logitech LED SDK integration (working with the sonar)

I known that is unnecessary for bypass the VAC, but I worked on my project just for fun, and now it's working well and I belive that it will not get me untrusted or VAC banned.

I'm making my own poly engine for now...making slow progress day-by-day, since I have no time 👍

The new source provides an example for that, other than that interesting setup. The view angles part honestly is something that you should not worry of, a very few games make server side checks for suspicious "movements". It's not hard to write one, but complex to make a reliable check.

Perhaps the VAC error could be something with my mouse_event call since you're using Arduino to do this instead.

I'm not sure what arduino does in the backgrounds to translate inputs to the windows OS, but If I were to guess I'd assume its something simple as that, unless they utilize even more low-level implementations.

[Jacckii]

I'm not sure what arduino does in the backgrounds to translate inputs to the windows OS, but If I were to guess I'd assume its something simple as that, unless they utilize even more low-level implementations.

Okay, now I have implemented MouseClassServiceCallback instead, it might be bit overkill for VAC but, at least it's great start if I want to try make it undetected on Faceit etc. (tho I have seen some posts about Faceit having this hooked and checked)

Now it would be great time to implement alternative for the ioctl communication. Any idea what could be fast and realible? I was thinking maybe about named pipes

[dretax]

@Jacckii Research shared memory if you want to go super safe. The way it works basically is you have some sort of section in your usermode that your kernel mode scans for, and they exhange a struct of memory based on a certain flag.
It's not as fast due (although very fast) to being limited to single read/writes, and is secure/reliable. Do note you have to use a lock.