This repository is no longer updated and is now just an informational page on things I learnt whilst playing and bypassing anti cheats for https://krunker.io during my vacation. For in depth analysis of detecting function hooking / modification take a look at Tamper detect JS
In this world, the hackers have a significant advantage, having access to a large variety of permissions that the anti cheat do not. Initially we modified the anti cheat checks directly but in recent patches, Krunker moved to anti cheat checks in WASM which is verified by the server. Instead of having to reverse engineer WASM, we work on hiding the presence of our cheat from all kinds of anti cheat checks - far more than Krunker actually check for (as of 1.5.8).
Intentionally throw an error within a try catch block and examine the stack trace. Check that the name and path of the game file has not been altered and also check that the line number it crashes corresponds to where it should be crashing. Extensions and user scripts will have a hard time dealing with this since they cannot reliably modify the message displayed by TypeError
.
Scripts can attempt to avoid detection by modifying the TypeError.prototype.name
attribute to something that the anti cheat is looking for. For example, we can modify the name of TypeError
to TypeError: https://krunker.io/js/game.XfsD.js:75
and examine the stack trace of (void 0)['name']
to be:
Uncaught TypeError: https://krunker.io/js/game.XfsD.js:75: Cannot read property 'name' of undefined
However a more sophisticated anti cheat check wouldn't be fooled by a modification of the name and would continue to examine the end of the error message.
Avoided by cheats that do not modify the game file - we can have cheats that work simply by pasting into the console.
Also avoided by using Electrons protocol.interceptBufferProtocol
to intercept the responses of requests - assuming that the line numbers of the modified response are still in line.
Send a XHR request to the same game file that has been loaded and check whether or not it has been altered at all.
Avoided by cheats that do not modify the game file (e.g. console cheats).
Avoided by cheats that only modify requests from script tags (a.k.a do not modify XHR requests). Chrome extensions and Electron can look out for non script requests inside of session.defaultSession.webRequest.onBeforeRequest
using details.resourceType !== "script"
.
Blacklist against public cheat(s) by checking for global variables.
(function(){var your_hidden_variable = null;})()
We can dynamically find the global variable of a cheat by iterating the keys in window
for (var variable in window)
and then checking the attributes of each variable for a known cheat attribute.
Object.defineProperty
with enumerable
set to false
.We can still iterate and find hidden global variables using Object.getOwnPropertyNames(window)
and getOwnPropertyDescriptors(window)
.
toString
, prototype
, hasOwnProperty
, constructor
and name
.This is really a no go since it's easy to detect. For example we can search through DOM for cheat strings used in GUIs by document.documentElement.innerHTML.indexOf('aimbot')
.
Hook canvas draw functions such as fillText
to detect cheat strings. We can even hook functions like Array.prototype.splice
or other array functions and check for cheat artifacts within the parameters.
Detect game function modifications by checking the toString()
of said function.
Update: in recent patches to Krunker anticheat they have been using this
toString
of the function being modifiedvar hideHook = function(fn, originalFunction) { fn.toString = originalFunction.toString.bind(originalFunction); }
Detect cheats by checking the storage for any settings saved.
Not really a bannable offense, but if users are using an old version of the Krunker client (which can be checked by looking at the user agent) it could raise flags since they should be updating.
Most cheats have hooks on mousedown
, mouseup
, keydown
and keyup
but code running within script tags cannot access getEventListeners
so this isn't really a detection vector.
Some things I accidentally bumped into and realised wasn't right. Just to clarify, no game breaking exploits were posted publicly until they were fixed. Exploits are ordered from oldest fix date to most recent fix date.
Publicly reported - fixed in 1.4.x
Krunker clamps angles on client side before sending it to the server but does not do re-clamp on the server side. If we remove the clamp checks and add multiples of 2 PI
to our yaw, our character appears to spin insanely on everyone elses screen whilst completely unaffecting ourselves (since effective angle wise, we are looking at the same position if we add 360). This can also be abused to cause the top half of our player model to go invisible by forcing our pitch to go upside down (head towards ground).
Publicly reported - weird fix that didn't work in 1.4.x. Still works
Player inputs get sent to the server in intervals of clientSendRate
. We can hold and queue up a buffer of inputs to send to the server instead of sending it instantly to cause ourselves to heavily lag and teleport on other players screens whilst leaving us largely affected. This can be combined with some logic that only releases the buffer if someone is about to shoot us to make us very hard to hit. Extreme uses of fake lag allow players to shoot players from spawn to spawn.
Privately reported - fixed in 1.5.3
One could observe that the session tokens used to login Krunker accounts are short. With further inspection we can extract public information from any account, and use this information to generate a session token for that account:
var sessionToken = (secondCreated * 2).toString() + dayCreated + secondCreated + username.substring(0,3) + (secondCreated * 4).toString()
It works for around 30% of accounts on first attempt. If it fails we can bruteforce with high probability the correct session token within 60 attempts by varying secondCreated
. And if this still fails we can bruteforce with 100% probability within 1800 attempts by varying both secondCreated
and dayCreated
. Time wise, it would take us 10 seconds per 3 attempts on a single PC, which means that it would take us a maximum of 1.5 hours to crack any account within the game.
Privately reported, stopped working in 1.5.4 - actual fix in 1.5.6
To move or shoot in Krunker, the client tells the Server which buttons it is pressing at a rate of ClientSendRate
. We can modify the buffer being sent to be consistently large to cause the server to konk out and kick everyone else out.
Publicly reported - fixed in 1.5.7
Respawning in Capture the Flag games are usually around the flag/base of your team - as long as we are not visible to an enemy. In ctf_littletown
there are two walls which are penetrable but not transparent which causes enemies to spawn in the exact same spot. Using an aimbot and auto instant respawn we can get over 200 kills within 4 minutes. Since Krunkers xp/level system is purely based on score and is not capped per game, we can level up insanely fast and even reach the top 10 within a few days.
Privately reported - partial fix in 1.5.8
Since Krunker allows for a large variety of characters within usernames, we can abuse zero width space characters such as ​
to create and appear as any username in the game - including no name. This also holds true for messages typed within the in game chat - Krunker filters out the characters <
and >
in messages but we can still have a message displayed (visually) with these characters by using <
and >
.
Having HTML entities such as <
, >
,  
or "
contained within a username causes the social links to that profile to break. This means that no one in the game is able to view our social profile - even if manually typed into the url!
A specific case of this led to an accounts social profile linking to a completely different account!
After observing the behavior from different malformed usernames, I concluded that there was underlying issues with:
Outside of this, there is also room for persistent XSS attacks on the follow and gift buttons which create DOM using the templates:
onclick=\x27followUser(\x22' + USERNAME + '\x22)
onclick=\x27giftPopup(\x22' + USERNAME + '\x22,\x20\x22' + SW['src'] + '\x22)
However the max length imposed on usernames limits the potential - yet we can still break the above buttons from functioning with malformed usernames.
Privately reported - attempted fix in 1.5.8, actual fix in 1.6.5
Krunker allows users to publish custom maps/mods, taking user inputs as names for the map. These maps can be accessed either ingame or through social. Anyone can create a custom map. Before playing on a custom map, a user must first click on the preview of said map.
There are certain checks on map names. For example we cannot have <
, >
or "
within a map name.
A map name would generate DOM using the following template:
onclick=\x27playMap("' + MAPNAME + '")
Knowing this, we can create a custom map with name "|alert())//
which causes the onclick
handler to become playMap(""|alert())//")
, a.k.a playMap(""|alert())
which bypasses the string and causes a pop up to appear.
Privately reported - Fixed in 1.6.7
You can reserve all slots for every server by spamming calls to seek-game
API.
Privately reported - Fixed in 1.6.9
Newly introduced captcha system on the games critical API seek-game
causes trouble when given large inputs. Since the entire krunker eco system relies on this API being alive, the end result is no one on any server being able to play a single game.
Unreported - (re?)patched 1.7.0
How to perform speed hacks are self explanatory. Lets you shoot faster, move faster, reload faster etc.