Two Exploits That Need Attention

Current GMod Exploits

1) Make a models/props_c17/FurnitureTable001a.mdl
   Attach thruster and set force to 999999999999999999999999999999999999999 (39 times the digit 9)
   Server crashes
   (I have not tested if this works on other props, or if this exact force is needed)

2) Spawn wire light with all 4 boxes checked
   Make a numpad input, value off 0 and value on 9999999
   Wire red, green, blue, glow size, glow brightness to the numpad input
   Press the key to turn everything white
   Do 2-5 times and it will crash all clients

Feel free to use these exploits, i’m just hoping Garry and the Wiremod Dev Team fix these

See also:

As much as I hate to admit it, this is the best way to get rid of bugs.

My question to you, OP, is why would you say “feel free to use these exploits.” Encouraging people to do this is a douchebag move.

Encouraging people to do it is how you get it fixed. If there’s no reason to fix it, why should they?

To encourage those responsible to fix them.

You can also use motor on a explosive barrel and then shoot it, crash.

sounds like exploit #2 is the fault of the wiremod team. they should be clamping the values for wire lights so as to avoid crashing people.

Ok, so when people come to my server, start performing such exploits, etc. I’m supposed to be “ok” with that just because it has the possibility of getting fixed? Flawless logic right there.

This used to happen with the HL2 Jeep vehicle. Attach a thruster, set force really high, and the server would crash as soon as the thruster was enabled. (Too high and the vehicle would just disappear, too low and it would move fast). I didn’t think it still happened though.

The second one i think you should take directly to the Wiremod people, i don’t think they often check on FP for this sort of thing.

There’s also this exploit

When the prop falls, I’m pressing 1 and 2 repeatedly fast.
I’m not sure if it’s fixed.

I would also like too say if you have a high prop contraption with two seperated parts[chariot/horse] and you apply keep upright, and physical properties + gravity, and add a rigid rope between the props; once you hit water with the contraption it’ll spaz and crash the server.

CPhysTorque: Entity Doesn’t Exist, Deleting. :frowning:

[lua] local Constraint = ents.Create(“phys_torque”)
Constraint:SetPos( WPos1 )
Constraint:SetKeyValue( “axis”, tostring( WPos2 ) )
Constraint:SetKeyValue( “force”, torque )
Constraint:SetKeyValue( “forcetime”, forcetime )
Constraint:SetKeyValue( “spawnflags”, 4 )
Constraint:SetPhysConstraintObjects( Phys1, Phys1 )
Hmm… you could almost emulate this entity in lua. I wonder if… f*ck that I’ll let Garreh fix it.

No, you should thank the OP for posting them. Now you can block these exploits on your server instead of sneaky wankers crashing it.

Exactly this, just make a carbon copy of the stool but clamp the values.

Quick update, here are more ways to crash servers:

The engine does not have the values clamped for the sole reason of reducing the CPU use and because source engine was never meant for this kind of use. There’s hundreds of these small value related flaws which allow crashing servers or clients, And they’ve been around for a very long time. Just clamping the stool values do nothing to the issue and since there’s no real fix to these the full disclosure does nothing. It’s more likely to just inform people about how to crash servers.

Avoid creating threads about bugs or flaws which:
-Do not require immediate action to be taken.
-Are not able to cause damage
-Do not cause long term damage(see: fuck up your computer)
-Work only on a specific server
-Are not easy to exploit
-Cannot be exploited in a large scale(see: lua viruses, malicious servers)

Server crash exploits that are simple tool uses. I’d consider them worthy of reporting, maybe not a thread each otherwise we’d have 50 a day.

Good point, lets sit back and watch as servers continue to go offline from the very exploits listed in this thread, but as long as they are lua viruses, or cause your computer harm, it’s no big deal. What are you talking about the engine not having these values clamped? The tools were produced by Garry, and they could easily be clamped with lua.

[lua]TOOL.Category = “Constraints”
TOOL.Name = “#Hydraulics
TOOL.Command = nil
TOOL.ConfigName = nil

TOOL.ClientConVar[ “group” ] = “1”
TOOL.ClientConVar[ “width” ] = “3”
TOOL.ClientConVar[ “addlength” ] = “100”
TOOL.ClientConVar[ “fixed” ] = “1”
TOOL.ClientConVar[ “speed” ] = “64”

function TOOL:LeftClick( trace )

if ( trace.Entity:IsValid() && trace.Entity:IsPlayer() ) then return false end

// If there's no physics object then we can't constraint it!
if ( SERVER && !util.IsValidPhysicsObject( trace.Entity, trace.PhysicsBone ) ) then return false end

local iNum = self:NumObjects()

local Phys = trace.Entity:GetPhysicsObjectNum( trace.PhysicsBone )
self:SetObject( iNum + 1, trace.Entity, trace.HitPos, Phys, trace.PhysicsBone, trace.HitNormal )

if ( iNum > 0 ) then
    if ( CLIENT ) then
        return true
    if ( ( !self:GetEnt(1):IsValid() && !self:GetEnt(2):IsValid() ) || iNum > 1 ) then

        return true
    // Get client's CVars
    local width            = self:GetClientNumber( "width", 3 )
    local bind            = self:GetClientNumber( "group", 1 )
    local AddLength        = self:GetClientNumber( "addlength", 0 )
    local fixed            = self:GetClientNumber( "fixed", 1 )
    local speed            = self:GetClientNumber( "speed", 64 )
    // Get information we're about to use
    local Ent1,  Ent2  = self:GetEnt(1),     self:GetEnt(2)
    local Bone1, Bone2 = self:GetBone(1),     self:GetBone(2)
    local LPos1, LPos2 = self:GetLocalPos(1),self:GetLocalPos(2)
    local WPos1, WPos2 = self:GetPos(1),     self:GetPos(2)

    local Length1 = (WPos1 - WPos2):Length()
    local Length2 = Length1 + AddLength    

    local constraint,rope,controller,slider = constraint.Hydraulic( self:GetOwner(), Ent1, Ent2, Bone1, Bone2, LPos1, LPos2, Length1, Length2, width, bind, fixed, speed )

    if constraint then undo.AddEntity( constraint ) end
    if rope   then undo.AddEntity( rope ) end
    if slider then undo.AddEntity( slider ) end
    if controller then undo.AddEntity( controller ) end
    undo.SetPlayer( self:GetOwner() )
    if constraint then    self:GetOwner():AddCleanup( "ropeconstraints", constraint ) end
    if rope   then        self:GetOwner():AddCleanup( "ropeconstraints", rope ) end
    if slider then        self:GetOwner():AddCleanup( "ropeconstraints", slider ) end
    if controller then    self:GetOwner():AddCleanup( "ropeconstraints", controller ) end
    // Clear the objects so we're ready to go again

    self:SetStage( iNum+1 )

return true


There’s lua clamping in hydraulics already, same with thruster, and nearly every other stock tool with a slider.

And as stated before, posting the exploits publicly increase the chance of them being fixed.

I can’t grasp how there are now limits on so much tools, you can just go crashing servers by changing props masses to negative amounts, attaching light speed thrusters to props, entangling the entire map in ropes that could lift you up to the moon :v: