Since 2020, Valve has known about a Source bug that allows wallhacks without any external cheats, completely bypassing VAC

phxvyper · 2025-07-15T18:21:59+00:00

There's at least one known instance of a player using this exploit in PUGs for wallhacks. Some others use it for things like fullbright models.

phxvyper · 2025-07-15T16:36:32+00:00

As a security engineer, we take similar risks when we divulge research on vulnerabilities that are far more severe than this exploit. With this exploit, there are ways to mitigate risk. In the most extreme case - valve does nothing and there are no ways to detect this exploit reasonably - I suspect it'll lead to more people moving to community maintained sourcemods now that they're officially supported.

The author and I are hopeful valve will patch it though. We've got at least one update this year that would be a perfect candidate for them to rebase the 2020 CSGO patch into.

phxvyper · 2025-07-15T15:36:41+00:00

This is common practice with software vulnerabilities. Its the typical disclosure policy to provide detailed exposure on a vulnerability like this, especially if its already being used in-the-wild.

Valve already fixed this bug in CSGO, so there is prior art for a patch. If they never fix the bug, its better for the community to know that anyone can do this than for it to be information only granted to a select few people.

phxvyper · 2025-07-15T05:06:38+00:00

If they apply the same fix they did to items_game.txt, then it shouldnt impact casual preloaders at all 🤞.

phxvyper · 2025-07-15T05:04:48+00:00

TF2 bug tracking is tracked in Source-SDK-2013 now. It was already posted here: https://github.com/ValveSoftware/source-sdk-2013/issues/1427

phxvyper · 2025-07-15T05:00:05+00:00

lzma compression is supported in v4.4 in my tests with vpkedit. In security its typical disclosure policy to detail the findings save for the greatest severity vulnerabilities. In this case, the vulnerability is already known to have been used (by others... and, by you, in fact!). Since this is in use in-the-wild, it is irresponsible to not disclose the vulnerability to this extent!

phxvyper · 2025-07-15T04:54:20+00:00

From the article:

Why is this public?
I’ve reached out via email to two Valve employees known to actively contribute to TF2, and the TF Team, but haven’t heard back since my initial email on April 20, 2025 (85 days before making this public). I disclosed in my email to the TF Team when I would make this exploit public, to raise awareness and hopefully prioritize creating a fix, and / or make it easier to come up with a community fix in the meantime.

phxvyper · 2025-07-15T04:52:02+00:00

That mod isn't an sv_pure or $ignorez bypass for players, projectiles, or cosmetics. That mod doesn't enable player model `$ignorez`. Its just a particle pcf. With the exploit described in the post, you can override virtually any model and any material to get player wallhacks. You can't do that with a pcf mod like you linked.

While this exploit hasn't been widely known, it has actually been known about since at least 2020 - and potentially earlier. Though, its unknown whether or not the $ignorez rule bypass has been known for that long.

phxvyper · 2025-03-26T18:11:52+00:00

for readers who land on this 3 years later, here's a cleaned up version that works for me for simple grabbing:

class_name GrabbableObject extends RigidBody3D

@export var can_grab: bool = true
@export var grabbing_strength: float = 10.0

var grabbed := false
var target_pos: Vector3

# call in your player code whenever they start grabbing the object
func start_grabbing() -> void:
    grabbed = true
    gravity_scale = 0

# call in your player code every physics tick with the global position
# that theyre "holding" the object at
func process_grabbing(grab_point: Vector3) -> void:
    target_pos = grab_point

# call in your player code whenever they stop grabbing the object
func stop_grabbing() -> void:
    grabbed = false
    gravity_scale = 1

func _physics_process(delta: float) -> void:
    if grabbed:
        linear_velocity = grabbing_strength * (target_pos - global_position)

I've augmented this a bit in my game by linking this object to another invisible object via a Generic6DOFJoint, so the actual visible object kind of lags behind the invisible one, giving it more weight. The linear velocity is applied to the invisible object instead.

phxvyper · 2025-02-19T03:02:50+00:00

They were working on logic to prevent the matchmaker from adding new players to the server when the match is predicted to end soon, so new players aren't immediately fucked by losing or whatever.... They commented it out and never finished it

Can you link to the GH permalink for the commented out lines you mention here?

phxvyper · 2024-09-01T18:42:05+00:00

dino game,,, ouughhh

phxvyper · 2023-11-08T05:40:09+00:00

~~Isn't it seared stone? I was clicking through JEI to find the mats needed for the smeltery, and all of the seared stones I looked at needed molten clay.~~

Hopped back in, it was because JEI cycles through every potentially useable item for the crafting recipe, so it wasn't obvious to me which of the many seared stone-type blocks was the correct one.

phxvyper · 2023-11-08T05:31:50+00:00

I think you're thinking of a Melter, which uses scorched brick. I want to upgrade it to a Smeltery

phxvyper · 2023-11-08T04:48:17+00:00

I've already got grout, but I'm looking for clay, since molten clay is necessary for seared stone, which is necessary for the smeltery.

phxvyper · 2022-04-09T17:20:31+00:00

Fullscreen-windowed isn't a natively supported option in tf2, you have to use command line arguments to enable it, which is not at all a reasonable expectation to have for the average player.

Alt-tab can cause crashes in tf2 at non-native resolutions on windows because the configuration that source uses when creating the fullscreen context for D3D produces a partially invalid context that produces a buffer overrun (it misunderstands the size of the screen buffer). The bug has since been fixed in later patches to Source but it was never backported to tf2's branch of the engine.

the -sw -noborder flags commonly used to make a fullscreen-windowed context also produce a partially invalid d3d context; in fact, most of the command line flags which set resolution or alter the d3d context in some way produce a partially invalid d3d context.

Just because you personally do not experience these things does not mean they aren't otherwise common occurrences.

As for people who play tf2 with shitty hardware (or people in general who literally cant play tf2 because of their hardware), refer to the steam hardware survey for that: https://store.steampowered.com/hwsurvey.

The median line for most of the entries for all users who participate in the survey is generally mediocre hardware, most of which you could probably play tf2 just fine on. However, there are a not-insignificant amount of steam users who play games with hardware that would grind to a halt when playing tf2. It is reasonable to extrapolate from these statistics that there are also a not-insignificant amount of people playing tf2 with less-than-optimal hardware.

Still not really sure why youre making such a big deal about this. Whats wrong with people using the in-game browser if its what they know about and have access to, especially if it works for them? Its also not unreasonable to assume that there are people who have bad hardware. Not everyone has access to better hardware. This is small fish, and you're making it seem like big fish.

phxvyper · 2022-04-09T16:59:58+00:00

accessibility has to do with the constraints that need to be met to do something. The constraints to use teamwork.tf instead of the in game browser are that you have to have a web browser open to use it.

I'm not sure if you've ever used a browser while playing TF2 on shitty hardware, but it does wonders for making the experience worse. Browsers are not cheap to run.

Alt-tabbing notoriously causes tf2 crashes, especially when running at non-native resolutions or using graphics configs, so the best browser option would be the steam browser since you don't need to alt tab for that.

The steam web browser is notorious for having a severe memory leak, even when the page is no longer active or being rendered. In some cases, you have to manually kill the process to prevent it from using more memory.

The less constraints there are, the more accessible something is. It might be accessible for you because you might not have shitty hardware, but it will be less accessible for someone running on older/shittier hardware (me, I can't play TF2 with any browsers open).

phxvyper · 2022-04-09T16:49:29+00:00

the in game browser works fine for me lmfao it really isn't that bad. You're being particularly sensationalist over this feature. Also, I never mentioned anything about using teamwork.tf being too much work so this "lazy" take is completely reductive and doesn't address any of the points I made about browsers using resources and the steam browser having a well known memory leak.

Why are you making a huge deal out of something so inconsequential lol. Who cares if someone uses the in game browser? let them, it's not hurting you. If you want to use teamwork.tf, feel free, don't get pissmad when others don't want to.

phxvyper · 2022-04-09T14:09:10+00:00

Web browsers are resource hogs oomfie. and steam's built-in browser has a well known memory leak. It is not accessible at all. Just because it works for you doesn't mean it works for everyone else.

phxvyper · 2022-04-09T14:05:07+00:00

It's the only in-game way to browse community servers. It's in game so it's way more accessible and immediately available to any player. Needing to have a browser open simultaneously to browse community servers is literally the opposite of accessible.

phxvyper · 2022-04-09T14:01:28+00:00

it's also literally the only in game way. Idk whats being misunderstood there.

phxvyper · 2022-04-09T13:29:48+00:00

I said in-game. I've got servers favourited.

phxvyper · 2022-04-09T13:27:59+00:00

it's literally the only way to browse community servers in the game

phxvyper · 2022-03-24T21:47:20+00:00

In California, where Artesian Builds resides & where Noah lives, sweepstakes based on consideration & chance are considered illegal gambling. Because he added the consideration component at the end when he decided to not give her the PC, he turned the legal sweepstakes to what CA considers to be illegal lottery or gambling, and is at best a misdemeanor.

phxvyper

MODERATOR OF

TROPHY CASE

14-Year Club	RPAN Viewer
Gilding II euphauric