[Mitchell]

Originally Posted by Potato Uno You guys know that, with sufficient pain and effort, you can just disassemble/decompile the client mac binary (which has debug symbols in it) and attempt to figure out the detection logic, right? I'm not doing it since I don't own (or care about) csgo but for those of you who are pissed at it, that's one way to figure out how this black hole system works. I would seriously not be surprised if the people who still are unbanned using weapon paints or knife givers have found a workaround to it just by inspecting the client binary.

It immediately bans servers that change the netprops of the weapons. Even if you knew exactly what netprops they were you cant just avoid it.

[ImACow]

This cannot be true,

This means changing the
Current owner:

m_hOwner

Previous owner:

m_hPrevOwner

silencer:

m_bSilencerOn

or burst mode:

m_weaponMode

will trigger a ban.

[psychonic]

Originally Posted by Potato Uno the client mac binary (which has debug symbols in it)

It doesn't and hasn't for months.

Originally Posted by kossolax So, anyone can confirm that changing a weapon into another custom model is still safe? I'm talking about zombie hands and stuff like this.

That should still be fine. As far as I can tell, the detection hasn't changed from before. The specifics of it aren't completely clear to me, but I know that completely custom models did not trigger it.

Originally Posted by Mitchell It immediately bans servers that change the netprops of the weapons. Even if you knew exactly what netprops they were you cant just avoid it.

Avoiding anything in the DT_ScriptCreatedItem table, which exist on the m_Item propDT_AttributeContainer table, should be fine. (So no changing item def index, quality, attributes, paint, wear, etc.). You can see these in the tree of a netprop dump.

If you would like confirmation of specific props, I can check them later.

Testing changes to item def index wasn't done before since no one asked (as it didn't seem necessary as the actual changes were in the spirit of the rules). In hindsight, it makes sense that all of the econ data for the weapon would be checked for validity.

Edit: DT_AttributeContainer, not DT_ScriptCreatedItem. Need to go one level up from m_Item.

[hlstriker]

Originally Posted by psychonic Testing changes to item def index wasn't done before since no one asked (as it didn't seem necessary as the actual changes were in the spirit of the rules). In hindsight, it makes sense that all of the econ data for the weapon would be checked for validity.

Going to bet anything this is my problem. I'm not sure if you actually tested but you're right that it does make sense for them to check their validity. If this really is my only problem then after my newest key gets banned it should be smooth sailing.

[lay295]

I don't think that changing the item definition index would trigger a ban. I wasnt caught in this ban wave but on my awp servers I have special rounds and one of which modifies a deagle's weapon index to shoot awp bullets, and have received no bans.

[asherkin]

Originally Posted by lay295 I don't think that changing the item definition index would trigger a ban. I wasnt caught in this ban wave but on my awp servers I have special rounds and one of which modifies a deagle's weapon index to shoot awp bullets, and have received no bans.

We've had a reliable report that someone was banned in this wave for doing exactly that.

[lay295]

Originally Posted by asherkin We've had a reliable report that someone was banned in this wave for doing exactly that.

Weird, well I'm just trying to give some info on my end. The special round I mentioned only runs about once every 30 rounds or so, and VIP's have access to start the round. So maybe in my case it wasn't happening frequently enough to trigger a ban? Here's the relevant code. Also if you think that it is the cause, might wanna disapprove this plugin since that's where I got the idea from.

Spoiler

public Action:Event_RoundStarted(Handle: event , const String: name[] , bool: dontBroadcast)
{
	if (IsAwpRound) //Once in every 30~ rounds
	{
		for (new i = 1; i <= MaxClients; i++)
		{
			if(IsValidClient(i) && IsPlayerAlive(i) && !IsFakeClient(i))
			{
				strip_player(i);
			}
		}
		if (DeagleTimer != INVALID_HANDLE)
		{
				KillTimer(DeagleTimer);
				DeagleTimer = INVALID_HANDLE;
		}
		DeagleTimer = CreateTimer(0.1, GiveDeagle);
	}
}

public Action:GiveDeagle(Handle:timer)
{
	ServerCommand("sm_restrict pistols -1 both"); //Too lazy to use natives :(
	for (new i = 1; i <= MaxClients; i++)
	{
		if(IsValidClient(i) && IsPlayerAlive(i) && !IsFakeClient(i))
		{
			new DeagleAwp;
			DeagleAwp = CreateEntityByName("weapon_deagle");
			SetEntProp(DeagleAwp, Prop_Send, "m_iItemDefinitionIndex", 9);
			DispatchSpawn(DeagleAwp);
			EquipPlayerWeapon(i, DeagleAwp);
		}
	}
	DeagleTimer = INVALID_HANDLE;
 	return Plugin_Handled;
}

[TheWho]

Originally Posted by psychonic Changing a weapon's item def index is likely what triggered the check. I will try to verify this later.

Well he got banned but maybe he used fake skins 1 month ago..
Because Im still running:

SetEntProp(entity,Prop_Send,"m_iItemIDLow",2048);
SetEntProp(entity,Prop_Send,"m_iItemIDHigh",0);

So people have their skins on weapons placed in map.
I will change this and store some crap of the weapon in arrays so there is no infinite loop of deleting and creating weapons.

[Mitchell]

They most likely started writing down user accounts and their ips when the glove update came out.
These unforgiving rules are pretty out there, just hope for some reason some one just doesn't upload a plugin that automatically fucks you over with editing weapon skins to get your account banned.

[psychonic]

Originally Posted by TheWho Well he got banned but maybe he used fake skins 1 month ago.. Because Im still running: SetEntProp(entity,Prop_Send,"m_iItemIDLow",2048); SetEntProp(entity,Prop_Send,"m_iItemIDHigh",0); So people have their skins on weapons placed in map. I will change this and store some crap of the weapon in arrays so there is no infinite loop of deleting and creating weapons.

As I mentioned last, touching properties that are backed by the econ data is likely the cause of issue. That would include all of:

netprops subset

     Table: m_AttributeManager (offset 1724) (type DT_AttributeContainer)
      Member: m_hOuter (offset 28) (type integer) (bits 21) (Unsigned|NoScale)
      Member: m_ProviderType (offset 36) (type integer) (bits 4) (Unsigned)
      Member: m_iReapplyProvisionParity (offset 24) (type integer) (bits 6) (Unsigned)
      Table: m_Item (offset 60) (type DT_ScriptCreatedItem)
       Member: m_iItemDefinitionIndex (offset 84) (type integer) (bits 20) (Unsigned)
       Member: m_iEntityLevel (offset 92) (type integer) (bits 8) ()
       Member: m_iItemIDHigh (offset 104) (type integer) (bits 32) (Unsigned)
       Member: m_iItemIDLow (offset 108) (type integer) (bits 32) (Unsigned)
       Member: m_iAccountID (offset 112) (type integer) (bits 32) (Unsigned)
       Member: m_iEntityQuality (offset 88) (type integer) (bits 5) ()
       Member: m_bInitialized (offset 124) (type integer) (bits 1) (Unsigned)
       Member: m_szCustomName (offset 184) (type string) (bits 0) ()
       Table: m_NetworkedDynamicAttributesForDemos (offset 156) (type DT_AttributeList)
        Table: m_Attributes (offset 0) (type _ST_m_Attributes_32)
         Table: lengthproxy (offset 0) (type _LPT_m_Attributes_32)
          Member: lengthprop32 (offset 0) (type integer) (bits 6) (Unsigned)
         Table: 000 (offset 0) (type DT_ScriptCreatedAttribute)
          Member: m_iAttributeDefinitionIndex (offset 4) (type integer) (bits 16) (Unsigned)
          Member: m_iRawValue32 (offset 8) (type integer) (bits 32) (Unsigned)
          Member: m_iRawInitialValue32 (offset 12) (type integer) (bits 32) (Unsigned)
          Member: m_nRefundableCurrency (offset 16) (type integer) (bits 32) (Unsigned)
          Member: m_bSetBonus (offset 20) (type integer) (bits 1) (Unsigned)
      Member: m_OriginalOwnerXuidLow (offset 2292) (type integer) (bits 32) ()
      Member: m_OriginalOwnerXuidHigh (offset 2296) (type integer) (bits 32) ()
      Member: m_nFallbackPaintKit (offset 2300) (type integer) (bits 16) (Unsigned)
      Member: m_nFallbackSeed (offset 2304) (type integer) (bits 10) (Unsigned)
      Member: m_flFallbackWear (offset 2308) (type float) (bits 0) (NoScale)
      Member: m_nFallbackStatTrak (offset 2312) (type integer) (bits 20) ()

Originally Posted by Mitchell They most likely started writing down user accounts and their ips when the glove update came out. These unforgiving rules are pretty out there, just hope for some reason some one just doesn't upload a plugin that automatically fucks you over with editing weapon skins to get your account banned.

The whole system is automated and non-prejudicial, with possibly the exception of manual server reports, if they're even processing those.

Hopefully this weekend, I'm going to look at getting some safeguards into SourceMod itself to stop people from unknowingly doing things that risk a ban.