drivetheory 10 Posted August 9, 2011 I've spent all day removing hackers/script-kiddies off of my guys' server (ArmA 2 isn't my game but somehow I'm in charge of maintaining it, go figure) using wireshark. Unfortunately i still cannot identify the packet(s) where the in-game admin is hijacked, or when the player's arma2 client who was logged into the in-game admin is locked up. any ideas or insights? Share this post Link to post Share on other sites
gossamersolid 155 Posted August 9, 2011 (edited) Unfortunately i still cannot identify the packet(s) where the in-game admin is hijacked, or when the player's arma2 client who was logged into the in-game admin is locked up.any ideas or insights? That's because too many people don't understand how these script kiddies issue admin commands. It's not "hijacking" at all. They are simply issuing perfectly valid commands via holes in the scripting language. Edited August 9, 2011 by GossamerSolid Share this post Link to post Share on other sites
drivetheory 10 Posted August 9, 2011 (edited) well the fact still remains, running a vanilla server, if you're logged into the in-game admin slot your arma2 client locks up and you can't do anything. and, as i posted, i still can not find a single instance of this in a capture file. yes, i've read they are just exploiting holes in the scripting language, but like i said already, the fact still remains and i don't see "servercommand" listed in any packets associated with this. is it some other plain text command? i've been reading the wiki and http://community.bistudio.com/wiki/Category:Scripting_Commands_ArmA2 ..... please do clarify what im missing Edited August 9, 2011 by drivetheory typos Share this post Link to post Share on other sites
Dwarden 1125 Posted August 9, 2011 read http://forums.bistudio.com/showthread.php?t=121438 and http://forums.bistudio.com/showthread.php?t=123407 threads, secure You server correct first ... use BattlEye Share this post Link to post Share on other sites
drivetheory 10 Posted August 9, 2011 read http://forums.bistudio.com/showthread.php?t=121438and http://forums.bistudio.com/showthread.php?t=123407 threads, secure You server correct first ... use BattlEye current server launch shortcut is already: C:\Program Files\Bohemia Interactive\ArmA 2\arma2server.exe -port=9999 -name=ArmA2 -config=D:\blah\the-config.cfg -cfg=D:\blah\the-cfg.cfg -profiles=D:\blah -BEpath=D:\blah\be the-config.cfg already contains: verifySignatures = 2; BattlEye = 1; as far as sharing bans that would be a great idea, something similar to what punkbuster does already... but im still were i was at the first post in this thread..... Share this post Link to post Share on other sites
.kju 3244 Posted August 9, 2011 remove bi.bikey and keep bi2.bikey Share this post Link to post Share on other sites
gossamersolid 155 Posted August 9, 2011 well the fact still remains, running a vanilla server, if you're logged into the in-game admin slot your arma2 client locks up and you can't do anything. and, as i posted, i still can not find a single instance of this in a capture file. yes, i've read they are just exploiting holes in the scripting language, but like i said already, the fact still remains and i don't see "servercommand" listed in any packets associated with this. is it some other plain text command? i've been reading the wiki and http://community.bistudio.com/wiki/Category:Scripting_Commands_ArmA2 ..... please do clarify what im missing They aren't using serverCommand for that freezing portion. They are using _user [url="http://community.bistudio.com/wiki/disableUserInput"]disableUserInput[/url] true; NOTE: _user is probably not the specific variable used for the targetted player Look for that when it happens. Share this post Link to post Share on other sites
drivetheory 10 Posted August 9, 2011 (edited) thanks for the replies. seriously, thank you! @PvPscene bi.bikey has now been deleted, thanks @GossamerSolid that code snippet helps immensely; led me to discover this lil bit of info: packet1: TargetPLSTRINGdrivetheory packet2: Code STRINGdisableUserInput true; also found this: if (name vehicle player == hTargetPL) then {_xcompiled = compile hijCode;call _xcompiled;};+if (name vehicle player == hTargetPL) then {_xcompiled = compile hijCode;call _xcompiled;}; Edited August 9, 2011 by drivetheory typos Share this post Link to post Share on other sites
gossamersolid 155 Posted August 10, 2011 There you go! PM me sometime and I can actually show you where that entire script is as I've stumbled upon the author. Share this post Link to post Share on other sites
nomad_man 10 Posted August 11, 2011 remove bi.bikey and keep bi2.bikey What are these keys for? Share this post Link to post Share on other sites
sickboy 13 Posted August 11, 2011 There you go!PM me sometime and I can actually show you where that entire script is as I've stumbled upon the author. Sent to BIS? Share this post Link to post Share on other sites
.kju 3244 Posted August 11, 2011 @ nomad man Check this BIKI page as a start: Addon_Signatures Share this post Link to post Share on other sites
gossamersolid 155 Posted August 11, 2011 Sent to BIS? Pretty sure they already know about it as it's also the same author and location as the script used to download server configs. But I'll msg Dwarden on Skype tonight. Share this post Link to post Share on other sites
nomad_man 10 Posted August 12, 2011 @ nomad manCheck this BIKI page as a start: Addon_Signatures what are they singing specifically? I mean why i should remove them. What functionality does the mod they sign do? Share this post Link to post Share on other sites
.kju 3244 Posted August 12, 2011 bi.bikey = v1 key bi2.bikey = v2 key in the a2 server (NOT OA) is an exploit if you keep the v1 key Share this post Link to post Share on other sites
Rexxenexx 0 Posted August 12, 2011 bi.bikey = v1 keybi2.bikey = v2 key in the a2 server (NOT OA) is an exploit if you keep the v1 key That is BRILLIANT!!! I never thought of that. You just have to make sure your add-ons keys are all v2 compatible right? Share this post Link to post Share on other sites
.kju 3244 Posted August 12, 2011 yep (for a2) for OA setting verifySignatures = 2; does the job already (you can keep v1 keys too) Share this post Link to post Share on other sites
=WBG=ati 10 Posted August 12, 2011 maybe there shoud be something out there maybe a script of somekind that the client side dont inject something on your server.. *something to thinkabout* Share this post Link to post Share on other sites
gossamersolid 155 Posted August 12, 2011 maybe there shoud be something out there maybe a script of somekind that the client side dont inject something on your server.. *something to thinkabout* There's already some anti-cheat systems out there, but with the nature of the scripting system, it's pretty much impossible to prevent these attacks. We look in their code to prevent it, then they look in our preventions and make a workaround. There's no real way to fix this Share this post Link to post Share on other sites
DementedFool117 10 Posted August 24, 2011 Well I partially decyphered how they do it, since I wrote an Admin Tool with a Dropdown Box that allows to add eventhandlers and do other crazy stuff to players (BAD players that HACK or TEAMKILL, no honest players are affected) to constantly kill them, open their maps (forcemap) and disable their input, make them fly, attach them to somebody else's vehicle, etc.; It is simple: They don't use Admin commands, they just use compile and publicvariable and (maybe, mine is different :D) exec. Solution: get somebody on with their own "Tool" and as soon as some weirdness starts going on, freeze them up. They need to restart their game, since there's no counter (unless they loop a script in the bg which sets disableuserinput false on themselfes) and that gives enough time to ban. But then again, the best way'd be, shoot them in the head. Share this post Link to post Share on other sites
nuxil 2 Posted August 24, 2011 its old news how its done. example. code = format["foobar"] player setVehicleInit code; processInitCommands; clearVehicleInit player volla. tha shit is loose. Share this post Link to post Share on other sites
gossamersolid 155 Posted August 24, 2011 I guess setVehicleInit and publicVariable should only be allowed to be called on the Server to prevent this, but then a lot of gamemodes will be broken methinks. Share this post Link to post Share on other sites
sickboy 13 Posted August 24, 2011 (edited) Simply deploying signature protection and not allowing mods that allow you to execute those things should be the primary way to prevent this. Also use BattlEye. If such protections are broken (on massive scale), or other means of injection are used, those things should be sent to BIS for analysis and seen what can be done about that. Crippling what mods and missions can achieve is IMO counter productive. Though as an optional option, usable for Public servers that are haunted by these problems, might be an idea, yet better improve protection. Edited August 24, 2011 by Sickboy Share this post Link to post Share on other sites
gossamersolid 155 Posted August 24, 2011 Simply deploying signature protection and not allowing mods that allow you to execute those things should be the primary way to prevent this.If that protection is broken (on massive scale), or other means of injection are used, those things should be sent to BIS for analysis and seen what can be done about that. Crippling what mods and missions can achieve is IMO counter productive. Right, I was thinking more in the sense of ArmA 3 ideas (but soon realized I'm still in the ArmA 2 forums). Share this post Link to post Share on other sites
eddieck 10 Posted August 24, 2011 What about not allowing kick/ban from setVehicleInit? Either way, it's good to know that can be done. 1.59 made our mission-based anti-hack (or rather anti-script-kiddie since it's incredibly easy for anyone who knows a tiny bit to get around) worthless since we could only disable their input. Share this post Link to post Share on other sites