LimeTech

Free2BeKicked – The Complete Interview

Asher — Wed, 15 Feb 2012 21:09:19 +0000

UPDATE: This post is still much in need of an introduction and some background regarding the event, for now though, I’m allocating time elsewhere – post in the comments below if you’d like to see this added to.

Patrick Klepek

Wed, Jun 29, 2011 at 7:42 PM

To: Asher Baker

Hey man,

I’m the news editor over at Giant Bomb.

Someone linked me towards your anti-F2P mod for TF2 and I was hoping to send you a few questions about it and your reasons for releasing it, if you don’t mind. Are you up for it?

Thanks,
Patrick Klepek
News Editor, Giant Bomb

Asher Baker

Wed, Jun 29, 2011 at 10:02 PM

To: Patrick Klepek

Hey Patrick,

Yeah, sure. Fire some questions my way and I’ll get back to you with the answers as soon as possible. Just keep in mind that it was made because there was demand for it rather than because I have a personal vendetta against F2P users, which a large amount of people seem to be trying to imply.

Regards,
Asher.

Patrick Klepek

Wed, Jun 29, 2011 at 10:26 PM

To: Asher Baker

Hey Asher,

That’s precisely why I wanted to talk to you, since the knee-jerk reaction is that someone who makes a mod like that is someone who’s having a knee-jerk reaction to this change in the community.

So walk me through it…how did you decide to make this mod? How difficult was it to make?

Has the response from the community been what you expected?

If you don’t have a “vendetta” against F2P users, how do you feel about them?

Do you expect Valve to disable your plugin? Have you heard any response from them?

Asher Baker

Thu, Jun 30, 2011 at 1:10 AM

To: Patrick Klepek

Hey Patrick,

Firstly, let me apologise for length. I promise it’s a good read, even if it does get a bit technical in places.

Well, there is quite a bit of background related to why it was made, so let me start with a conversation I had on IRC with the owner of AlliedModders after the first day or so:

personally i put it in the same category as banning high ping people which i hate

but valve has created a problem

a community needs a barrier to entry and it needs a way to heal itself if there is a misbehaving member

if there is no barrier to entry – and no recourse against those people – it could be bad

but its too early to tell

there are also a large number of tf2 servers aimed specifically at trading, the non-premium players can’t start trades and therefore just end up in these servers taking up a slot and begging for items

(it’s a trade server owner that originally asked me for the plugin)

and yeah, I also dislike high ping kickers, that silly cross-game vac ban detector, and even this one

but I figured it was better to do it myself properly before someone released something that did something silly like parse their backpack page to see how many slots they had etc.

So yeah, basically it just boils down to there being a demand for it, yet there being very few developers who had the necessary background knowledge to do it without “hacks”. I was in a unique position due to my work on Open Steamworks (I’m afraid our regular web site with a description of the is offline due to a series of attacks and threats against anyone that hosts it, so I’ll give you the short version: It’s a series of scrounged, leaked and reverse engineered headers that allow the usage of the client-side portions of Valve’s Steamworks API), using OSW I created a SourceMod (a popular and well-known server administration and plugin system for the Source engine) Extension called SteamTools to expose all the game server functionality to other plugins, this has allowed some amazing things to be written, including: a plugin to manage server administrators using Steam Community Groups, a patch for the server rules listing bug in the Linux version of SrcDS, a plugin to allow VAC-banned people into a Secure server (arguably the most controversial plugin in my portfolio, but hardly as well-known as Free2BeKicked, also now includes some fixes for more bugs Valve introduced in the engine), and of course Free2BeKicked.

As for the demands aspect, a few days before the Free2Play announcement was made, Valve made some changed to the CDR (Content Description Record, simply a large database detailing all the content on Steam that is distributed to all the clients) that were noticed by another Open Steamworks developer that strongly hinted that TF2 would soon by F2P. After discovering this I was talking with a good friend of mine who runs the Xomby.org gaming community (which at the time ran a single TF2 trading server) and he asked me if I could look into a way to detect F2P players. When Free2Play was publicly announced and it was made known that they would be unable to trade he of course asked me again to make a plugin to outright prevent them from joining the server, this coupled with a thread made to request it on AlliedModders and some other requests directly to me on IRC persuaded me to create and release the plugin.

Regarding the difficulty of creating it, it’s quite hard to put a fixed value on it. I had already done a large amount of work required in SteamTools, and of course more was put into OSW by the Open Steamworks team (3 other people and I). I’ll try and go into a bit more detail (and also cover your later question about Valve) by explaining the technical details of how it works: When the game client wants to connect to a game server, it requests an authentication ticket from Steam and sends it to the server which then passes it onto the Steam backend in order to verify it and the client (check it’s from a valid account, the account owns the game, the client is already playing in another server, the client isn’t VAC-banned, etc.). SteamTools hooks into the server and “listens in” on the server’s request to Steam and does it’s own parsing of the auth ticket, this ticket contains (amongst other information) the subscription(s) the game was bought in (simply the “pack”, for example TF2, TF2 + GMod, Valve Complete Pack, etc.) and the DLC associated with the game. With this and some information about how Steam functions, it became easy to identify Free2Player players: They own TF2 in subscription 0 and no others (0 = Steam = owned by everyone) and they don’t have DLC 459 (“Team Fortress 2 - Premium DLC”). While Valve can implement the latter using other methods available to them (and would have the side-effect of needing other methods to detect F2P players who later upgraded to premium), stopping the subscription check would require rewriting whole the entire Steam game authentication system functions (please don’t take this as “taunting” Valve, it’s just an observation as to how the system operates). So while Valve may wish to prevent the plugin from operating, it would only end up with a large amount of work and worse methods being used to the same effect. As long as there is demand a version of the plugin will exist, although probably not written by myself.

Finally, yes, I anticipated a negative response from the general player base and a positive response from the server operators. I hadn’t anticipated it to be this strong either way, even including receiving death threats (but who doesn’t expect that online these days). In the end my loyalty is to the server operators and other developers trying to fight with the Source engine, so I’m glad of the outcome there. I don’t really have a personal opinion about TF2 going free to play, it’s brought in lots of new players, but I’m not sure it’s worth the long-term cost. I think that once the droves of inexperienced players dies down, we’re going to be left with a (slow) steady stream of new players (good), but primarily just cheaters and people evading server bans. I suppose you could say my plugin was ahead of it’s time. I did propose a possible solution to the latter on the Steam Powered User Forums, so I’ll just include that here:

I think the best way would be a hardware identifier exposed as part of the authentication ticket (covering the whole system, so that changing an individual component does change the ID, but this is still “stronger” than going after individual IDs). This would mean that and individual server could ban that computer, lasting only on that server. This would be saner than IP bans (the only solution to multiple accounts other than my plugin) as it wouldn’t affect multiple people as in the case of a dynamic IP, but it would also be harder to change for that individual hacker.

Hardware bans work fine on a per-server case like this, they just fall apart when used by an invasive global system like VAC, because they are inherently “unfair” since someone who just “tried” a cheat (or someone used their computer) could get that computer permanently banned. Previously, this did work fine with SteamIDs because the limitation was to get a new Steam account. Since, with my idea, if it’s just a per-server ban you can join another server, where if a user continued to cheat they would just get banned again or if they didn’t they wouldn’t have any issue.

Hope that answers all your questions and gives you plenty of content, just let me know if you have anything else you wish to ask.

Regards,
Asher.

Patrick Klepek

Thu, Jun 30, 2011 at 11:22 PM

To: Asher Baker

Hey Asher,

Thanks for getting back to me so quickly, and for going so in-depth technically, even if much of it goes over my head.

Let me see if I’m getting this straight. Basically, you’ve created a sever filter for free-to-play users without doing anything crazy–you’re working within the tools that Valve’s okay with? If they were to squash your plugin, it would only lead to people going to more extreme measures for the same aim?

A couple of follow-ups…

What does this mean? “like parse their backpack page to see how many slots they had etc.” Basically, you guys decided to make this plugin in the cleanest way possible, so that someone wouldn’t create something more sadistic?

How popular has the plugin been so far?

Asher Baker

Fri, Jul 1, 2011 at 3:38 AM

To: Patrick Klepek

Hey Patrick,

No problem. Sorry about the technical stuff, needed to write a post up for my personal site as well, so figured I’d kill two birds with one stone .

I would doubt Valve are okay with the method. While it uses data that is sent to the server as part of the authentication process, it’s packed into a proprietary structure (which was reverse-engineered) and not actually exposed by any official API, it’s only meant to be passed through the server for processing on the Steam backend, the game server isn’t meant to look at the data inside.

Well, F2P players only get 50 slots in their TF2 backpack, Valve expose this slot count via their web API. However, accessing this would require making a costly request to the Steam Community website (which is often very slow), parsing the large amount of data returned to look for the number, and then kicking based on the number of available slots, which of course could change at any time (not that that would be much different from how making plugins for the Source engine normally is ). My method uses data that is already sent to the server, and therefore requires no calls to outside data sources, making it a lot more efficient.

Well it’s certainly seen a lot of publicity, but getting an accurate number of server’s running it is almost impossible due to a bug I mentioned in my previous email. There are at least 17 server’s running my plugin, but since rules querying is broken on Linux (and the majority of TF2 server’s seem to be hosted on Linux machines), this number could be significantly higher. There have also been about 7 plugins based on mine posted on AlliedModders by various authors, that each performs a different action upon F2P players. As for the actual players, the author of the main thread covering the plugin on SPUF gained over 250 reputation points because of his post.

Regards,
Asher.

Steam and CD Keys

Asher — Thu, 29 Sep 2011 13:37:52 +0000

int main(int argc, char* argv[])
{
	CSteamAPILoader loader;
	CreateInterfaceFn steamclientFn = loader.Load();
	IClientEngine *clientEngine = (IClientEngine *)steamclientFn(CLIENTENGINE_INTERFACE_VERSION, NULL);

	HSteamPipe pipe = clientEngine->CreateSteamPipe();
	HSteamUser user = clientEngine->ConnectToGlobalUser(pipe);

	IClientBilling *clientBilling = clientEngine->GetIClientBilling(user, pipe, CLIENTBILLING_INTERFACE_VERSION);
	IClientUser *clientUser = clientEngine->GetIClientUser(user, pipe, CLIENTUSER_INTERFACE_VERSION);
	IClientApps *clientApps = clientEngine->GetIClientApps(user, pipe, CLIENTAPPS_INTERFACE_VERSION);

	uint32 numLicenses = clientBilling->GetNumLicenses();
	for (uint32 licenseID = 0; licenseID < numLicenses; licenseID++)
	{
		PackageId_t packageID = clientBilling->GetLicensePackageID(licenseID);

		if (packageID == 0)
			continue;

		uint32 numApps;
		clientBilling->GetPackageInfo(packageID, &numApps, NULL, NULL, NULL, NULL, NULL, NULL, NULL);

		AppId_t *apps = new AppId_t[numApps];
		clientBilling->GetAppsInPackage(packageID, apps, numApps, true);

		for (AppId_t appIndex = 0; appIndex < numApps; appIndex++)
		{
			AppId_t appID = apps[appIndex];

			bool hasCDKey = clientUser->HasLegacyCDKey(appID);
			if (!hasCDKey)
			{
				clientUser->RequestLegacyCDKey(appID);

				while (true)
				{
					CallbackMsg_t callback;
					if (!Steam_BGetCallback(pipe, &callback))
						continue;

					if (callback.m_iCallback != LegacyCDKeyRegistered_t::k_iCallback)
					{
						Steam_FreeLastCallback(pipe);
						continue;
					}

					LegacyCDKeyRegistered_t *data = (LegacyCDKeyRegistered_t *)callback.m_pubParam;

					if (data->m_eResult != k_EResultOK)
					{
						Steam_FreeLastCallback(pipe);
						break;
					}

					char name[512];
					clientApps->GetAppData(appID, "name", name, 512);

					cout << name << " (" << appID << ")" << " = " <<  data->m_rgchCDKey << endl;
				
					Steam_FreeLastCallback(pipe);
					break;
				}

				continue;
			}

			char CDKey[64];
			clientUser->GetLegacyCDKey(appID, CDKey, 64);

			char name[512];
			clientApps->GetAppData(appID, "name", name, 512);

			cout << name << " (" << appID << ")" << " = " <<  CDKey << endl;
		}

		delete apps;
	}

	clientEngine->ReleaseUser(pipe, user);
	clientEngine->BReleaseSteamPipe(pipe);

	cout << "Press any key to continue . . . " << endl;
	while (!_kbhit()) {}
	return 0;
}

Interfaces and Listeners in C++

Asher — Tue, 05 Apr 2011 11:53:59 +0000

So, time for my first ever tutorial/guide/whatever, let me know in the comments what you think and/or if you have any suggestions for future posts. Now, on with the main event.

When I started writing VoiceHook I realised that I needed a way to keep the ‘core’ (provider) closed-source, while allowing Metamod:Source plugins and SourceMod extensions (consumer) to interface with it.

Now, I already had an idea how to implement the consumer → provider portion of it (interface) thanks to Voogru’s work on Attachables, but the provider → consumer part was still a mystery. Here I turned to the SourceMod core and it’s PlayerHelpers interface, this gave me an idea where to start and I managed to complete it.

So here is how you implement an interface in a Metamod:Source plugin (in this case, the sample one):

First things first, let’s define a simple interface:

class IMyInterface
{
public:
	virtual int AddFive(int input) = 0;
}

#define MY_INTERFACE_VERSION "MY_INTERFACE_001"

This is what goes in the public header to be provided to consumers.

Interface classes generally start with the letter ‘I‘, with the implementation in the provider having the same name but starting with ‘C‘. This interface exposes a single function called AddFive which takes an integer as a parameter and returns another integer.

The string defined as MY_INTERFACE_VERSION is passed by the consumer into the providers factory (covered later) to instruct it on what interface to return. A version number is packed into this so that if the interface is changed and the provider and consumer’s copies are incompatible it fails to get the interface rather than crashing when trying to use it. With extra work it is also possible for a provider to return all previous versions of an interface.

Now, lets implement this interface. I’m going to do the function implementation inline with the class definition as it’s simpler that way, you can (and will probably want to) split this up.

class CMyInterface: public IMyInterface
{
public:
	int AddFive(int input)
	{
		return (input + 5);
	}
} g_MyInterface;

As you can see, it’s very simple. The implementation derives from the public version of the interface class and implements the functions exposed. g_MyInterface acts as a global singleton for the interface, and will be covered shortly.

Next we’ll make it so other plugins can get this interface, ensure that your main class derives from IMetamodListener and add the prototype for OnMetamodQuery to your class definition.

class SamplePlugin: public ISmmPlugin, public IMetamodListener
{
...
public: //IMetamodListener
	void *OnMetamodQuery(const char *iface, int *ret);
}

Need to hook up the IMetamodListener next, add the following line to the end of SamplePlugin::Load.

g_SMAPI->AddListener(g_PLAPI, this);

Now we’re hooked up to Metamod:Source’s factory (I’m not going to cover implementing your own factory from scratch in this post), lets implement OnMetamodQuery so other plugins can get our new interface.

void *SamplePlugin:: OnMetamodQuery(const char *iface, int *ret)
{
	if (strcmp(iface, MY_INTERFACE_VERSION) == 0)
	{
		if (ret)
			*ret = IFACE_OK;
		return static_cast(&g_MyInterface);
	}
	if (ret)
		*ret = IFACE_FAILED;

	return NULL;
}

Again, really simple. Just return your singleton if the interface requested matches the string you defined.

Here is how you can get the interface in the consumer. This part is very simple, it’s just like getting any HL2 SDK interface, just with a different factory.

int ifaceerror;
g_pInterface = (IMyInterface *)g_SMAPI->MetaFactory(MY_INTERFACE_VERSION, &ifaceerror, NULL);
if (!g_pInterface )
{
	snprintf(error, maxlen, "Could not find interface %s (error %d)", MY_INTERFACE_VERSION, ifaceerror);
	return false;
}

That’s it for just a simple interface, let’s add a listener so that the provider can trigger callbacks in the consumer.

Firstly, add an extra class to your public header to define your listener.

class IMyListener
{
public:
	virtual void OnCallbackFired(void)
	{
	}
};

The empty OnCallbackFired implementation will be overridden with the clients if they implement it, you can use = 0; here to force them to.

Now, add Add and Remove functions to your interface, these will (de)register the listener with the provider. If Add is called but Remove isn’t called on unload, the server will crash due to accessing non-executable memory if one of the callbacks is fired.

class IMyInterface
{
public:
	virtual int AddFive(int input) = 0;

public:
	virtual void AddListener(IMyListener *pListener) = 0;
	virtual void RemoveListener(IMyListener *pListener) = 0;
}

As before, these need to be implemented. We’ll be using the List structure provided with SourceHook to store all the added interfaces. An important point to note is that all calls to the listener’s functions need to take place from inside the interface implementation, or errors will occur.

class CMyInterface: public IMyInterface
{
public:
	int AddFive(int input)
	{
		return (input + 5);
	}

public:
	void AddListener(IMyListener *pListener)
	{
		m_pPluginHooks.push_back(pListener);
	}

	void RemoveListener(IMyListener *pListener)
	{
		m_pPluginHooks.remove(pListener);
	}

	void NotifyListeners(void)
	{
		SourceHook::List::iterator iter;
		IMyListener *pListener = NULL;
		for (iter = m_pPluginHooks.begin(); iter != m_pPluginHooks.end(); iter++)
		{
			pListener = (*iter);
			pListener->OnCallbackFired();
		}
	}

private:
	SourceHook::List m_pPluginHooks;
} g_MyInterface;

All they are doing is adding and removing from the SourceHook::List. The NotifyListeners function is a simple one that loops all added listeners and fires the OnCallbackFired callback for each.

The provider can use

g_MyInterface->NotifyListeners();

to call NotifyListeners from anywhere else in the plugin.

I think that pretty much covers everything, have fun implementing interfaces and listeners in your plugins!

BackpackHook

Asher — Thu, 14 Oct 2010 20:16:51 +0000

This project is no longer maintained, significant changes to Team Fortress 2′s internals removed functionality it was built upon.

BackpackHook is a SourceMod extension that exposes some internals of the Team Fortress 2 item system, including exposing details such as renamed item names, equipped state and global ids.

See this project’s topic on AlliedModders for more info and discussion.

RulesFix

Asher — Fri, 17 Sep 2010 16:43:25 +0000

This project is no longer maintained, the bug it corrected was fixed in an update to the engine.

RulesFix is a very simple SourceMod plugin utilising http://limetech.org/projects/steamtools/ designed to fix an issue affecting external information queries on Linux OrangeBox servers.

See this project’s topic on AlliedModders for more info and discussion.

VPhysics

Asher — Wed, 25 Aug 2010 16:55:24 +0000

VPhysics is a SourceMod Extension to expose the API of the Source game server’s physics library of the same name to SourceMod Plugins.

VPhysics is an extremely comprehensive physical simulation library built by Valve around the Havok and Ipion physics libraries, with an extensive C++ API.

See this project’s topic on AlliedModders for more info and discussion.

ZombieFix

Asher — Fri, 06 Aug 2010 03:34:12 +0000

ZombieFix is a very simple SourceMod extension designed to fix a crash issue with Half-Life 2: Deathmatch game servers running on Windows when spawning NPC zombies, caused by an unfixed bug in the server code.

See this project’s topic on AlliedModders for more info and discussion.

UnVAC

Asher — Mon, 19 Jul 2010 16:37:40 +0000

UnVAC is a Metamod:Source Plugin that allows server owners to whitelist specific players from Valve Anti-Cheat checks on connect, allowing them to let currently banned players into their servers.

It was created as a proof-of-concept, but released when Valve started VAC-banning non-cheaters.

See this project’s topic on AlliedModders for more info and discussion.

SteamTools

Asher — Wed, 16 Jun 2010 17:56:24 +0000

SteamTools is a SourceMod Extension that exposes the server-side portion of Valve’s Steamworks API to SourceMod plugins, utilizing the headers from the OpenSteamworks project.

See this project’s sub-forum on AlliedModders for more info and discussion.

TFDodgeball

Asher — Sun, 16 May 2010 12:33:57 +0000

TFDodgeball is a combination of a SourceMod Plugin and Extension that together provide an implementation of the popular Team Fortress 2 gamemode known as Dodgeball.

It was the first open source implementation available and is highly configurable.

See this project’s sub-forum on AlliedModders for more info and discussion.