OSBot's mouse movement is easily detected

[asdttt]

Going to make a mechanism to physically click my mouse on an interval set by gears. GL Jagex

[Search12]

On 4/18/2019 at 4:50 PM, Alek said:

Yes, I'm way more qualified to talk about detection and hacking than you. I wrote public aimbots and sold them for 2 years (Paladins, CSGO, Day of Infamy - all with my own custom updaters and AOB scanners), I'm fluent in MASM32 (x86 assembly), and I've disassembled more PEs, bypassing more DRMs and anticheat software than you have.

Got me gut laughing. I was in two minds about joining this discussion since I rarely take a front seat to these types of discussions but this one was way too fucking funny to resist. Shit, you can search memory for an array? OMG, you can use a disassembler?? bypassing DRMs??? Teach me how to be like you bro.

 

On 4/17/2019 at 5:07 AM, Alek said:

Because you're using SendInput... all Windows API functions can be hooked and detected. Look into JNI/JNA (Java). Please don't say something is undetected/hardware call when you're using a usermode public Windows API function call.

On 4/17/2019 at 5:27 AM, Alek said:

It's very detected on the JVM level, I already told you that you can use JNI/JNA. I don't mean to be offensive or pick on you, but do I need to spoon feed you all the resources? Just because you don't know how something is being detected, doesn't mean its undetected...

........

On 4/17/2019 at 5:17 AM, Alek said:

Ugh... Gary's Hood is literally using SendInput as well. Yes your mouse is detected because you can hook onto the windows hook chain and monitor for input thats generated by a real device vs those injected by application code - aka using SendInput directly like you are.

Mouse Hook: https://docs.microsoft.com/en-us/windows/desktop/api/winuser/ns-winuser-tagmsllhookstruct

Just please stop making these cringey threads, you're really out of your league.

Imagine belittling someone but being too ignorant or stupid to actually check if they even use the detection method. There is no low level native mouse or keyboard hook in oldschool runescape for the context of detecting injected input. It simply doesn't exist. Anyone with 5% of the experience you so humbly bragged about could easily check that before making a baseless claim on the detection of SendInput and contributing to the shit show here on this thread. Outstanding job pal. 

Keeping the discussion civil. It doesn't matter if you use SendInput or regular java event dispatching in the context of detecting the validity of input since there's isn't any differing integrity tests on input events anywhere in the client. Bytecode or native. While they're both detectable, neither are being detected. Keynoting that this says nothing about the timings, and delays of those events. 

[Norppa]

[Naked]

On 4/20/2019 at 5:33 AM, Search12 said:

Got me gut laughing. I was in two minds about joining this discussion since I rarely take a front seat to these types of discussions but this one was way too fucking funny to resist. Shit, you can search memory for an array? OMG, you can use a disassembler?? bypassing DRMs??? Teach me how to be like you bro.

 

Imagine belittling someone but being too ignorant or stupid to actually check if they even use the detection method. There is no low level native mouse or keyboard hook in oldschool runescape for the context of detecting injected input. It simply doesn't exist. Anyone with 5% of the experience you so humbly bragged about could easily check that before making a baseless claim on the detection of SendInput and contributing to the shit show here on this thread. Outstanding job pal. 

Keeping the discussion civil. It doesn't matter if you use SendInput or regular java event dispatching in the context of detecting the validity of input since there's isn't any differing integrity tests on input events anywhere in the client. Bytecode or native. While they're both detectable, neither are being detected. Keynoting that this says nothing about the timings, and delays of those events. 

Prove they're not being detected.

[Search12]

4 hours ago, Naked said:

Prove they're not being detected.

You want me to provide proof of something that isn't there? Here, i'll just teach you how to do you yourself.

Write a SetWindowsHookEx hook/detour and place it in a DLL which installs our hook in DLLMain. You can copy and paste any basic 32bit trampoline function. WinAPI functions all come with a standard useless 2 byte hotpatch point (mov edi, edi). This includes SetWindowsHookEx. The hook will notify us if any process (which has our DLL loaded into it's address space) invokes SetWindowsHookEx.
Start oldschool runescape in a suspended state. Inject your DLL. Resume oldschool runescape so it is no longer in a suspended state. If the process calls SetWindowsHookEx then it has tried to create a hook. That's how you would detect windows hooks. 

Extra: You can grab the params which have been passed to SetWindowsHookEx. Including a function pointer and manually navigate to the code in memory (can use any decompiler) if you happen to find that hooks have been installed.

[asdttt]

22 hours ago, Search12 said:

You want me to provide proof of something that isn't there? Here, i'll just teach you how to do you yourself.

Write a SetWindowsHookEx hook/detour and place it in a DLL which installs our hook in DLLMain. You can copy and paste any basic 32bit trampoline function. WinAPI functions all come with a standard useless 2 byte hotpatch point (mov edi, edi). This includes SetWindowsHookEx. The hook will notify us if any process (which has our DLL loaded into it's address space) invokes SetWindowsHookEx.
Start oldschool runescape in a suspended state. Inject your DLL. Resume oldschool runescape so it is no longer in a suspended state. If the process calls SetWindowsHookEx then it has tried to create a hook. That's how you would detect windows hooks. 

Extra: You can grab the params which have been passed to SetWindowsHookEx. Including a function pointer and manually navigate to the code in memory (can use any decompiler) if you happen to find that hooks have been installed.

Would still be detectable as it's not coming off the HWID stack, but that's if they even have the anti-cheat measures to check that. Still wouldn't be impossible to bypass. Hell, you could make an autoclicker in Logitech's driver software and it'd come clean off the HWID stack. 

IMO, I think Jagex understands that botting is simply a part of the game at this point. They're getting little to no new players, RS3 is pretty much dead, and OSRS is full of autoclickers. It makes zero sense why I can bot on the most blatant script ever made for 4 hours straight and get no ban. ZERO sense. To me, it feels like they actually just allow micro-botting as long as it wont harm the economy. This game is so repetitive, if you actually took the time to train your strength or what not to 99 MANUALLY then you should probably get a job lol. 

And from what it appears during my testing, they've done nothing with windows API. They do have code to download jars and load .dll files, but I haven't been able to detect anything while botting. Maybe they load it after 6-10 hours of straight botting for a bit, then unload it? I've got no idea. I got 75 magic about 2 days ago by autoclicking alch for like 9 hours straight and got no ban either. It's been theorized by most botters that their system is tiered, so this would certainly back that claim up. Maybe detecting clicks is the very top tier of detection, their last ditch effort. That would also mean that fixing other flaws such as the mouse movement would further delay bans, therefor, in theory, allowing for a much longer botting period. 

[Search12]

2 hours ago, asdttt said:

Would still be detectable as it's not coming off the HWID stack, but that's if they even have the anti-cheat measures to check that. Still wouldn't be impossible to bypass. Hell, you could make an autoclicker in Logitech's driver software and it'd come clean off the HWID stack. 

Are you keeping up with the flow of the conversation? I was stating why Alek's point is bad because they don't do that specific type of detection (hooks through SetWindowsHookEx) and Naked asked me for proof. It has nothing to do with other types of detection or other types of input. All types of input are detectable but not being detected (Integrity isn't being tested anywhere). Logitech's driver software isn't a MouClass.sys replacement. It's what you would call a filter driver. Lives at a higher level than MouClass.sys but it is still under Win32K.sys so it is in kernel space. All these methods are easily detectable unless your AC is running in userland. I will state it again; This type of detection doesn't exist anywhere in the game client. They don't test the integrity of mouse/key events anywhere in the oldschool runescape client.

You can check for yourself but i can tell you that there's nothing nefarious in any native code in oldschool runescape.

Edited April 26, 2019 by Search12

[asdttt]

1 hour ago, Search12 said:

Are you keeping up with the flow of the conversation? I was stating why Alek's point is bad because they don't do that specific type of detection (hooks through SetWindowsHookEx) and Naked asked me for proof. It has nothing to do with other types of detection or other types of input. All types of input are detectable but not being detected (Integrity isn't being tested anywhere). Logitech's driver software isn't a MouClass.sys replacement. It's what you would call a filter driver. Lives at a higher level than MouClass.sys but it is still under Win32K.sys so it is in kernel space. All these methods are easily detectable unless your AC is running in userland. I will state it again; This type of detection doesn't exist anywhere in the game client. They don't test the integrity of mouse/key events anywhere in the oldschool runescape client.

You can check for yourself but i can tell you that there's nothing nefarious in any native code in oldschool runescape.

I was just pointing out that they could achieve nearly the same level of detection based on raw input, so you wouldn't be able to detect that using the method you described. 

And yeah I couldn't find anything interesting either, but as I described above, the detection appears to be tiered. Quoting myself:

3 hours ago, asdttt said:

And from what it appears during my testing, they've done nothing with windows API. They do have code to download jars and load .dll files, but I haven't been able to detect anything while botting. Maybe they load it after 6-10 hours of straight botting for a bit, then unload it? I've got no idea. I got 75 magic about 2 days ago by autoclicking alch for like 9 hours straight and got no ban either. It's been theorized by most botters that their system is tiered, so this would certainly back that claim up. Maybe detecting clicks is the very top tier of detection, their last ditch effort. That would also mean that fixing other flaws such as the mouse movement would further delay bans, therefor, in theory, allowing for a much longer botting period. 

 

So in other words, I don't believe they use this level of detection. If they do, then they're very very sneaky with it and it's injected only after botting a certain amount of time, and only for a certain length of time. Like a "last ditch effort" as I described above.

 

Edit: Also I forgot to mention, there actually was a .dll file called "jaclib.dll" or whatever that contained code to catch the API input flag "LLMHF_INJECTED" (From sendInput) - although there was never a callback implemented. Weird... Very weird.. Especially since they bothered to ship it... Maybe because they realized that programmers could easily remove that flag through a hook + trampoline function, or by just unregistering it lmao (Through WH_DEBUG). They appear to have removed it though. 

Edited April 26, 2019 by asdttt

[Turkoize]

I literally have no idea what any of this code talk means but it’s entertaining watching you all go at it, keep it up

Edited April 26, 2019 by Turkoize

[Search12]

31 minutes ago, asdttt said:

I was just pointing out that they could achieve nearly the same level of detection based on raw input, so you wouldn't be able to detect that using the method you described. 

And yeah I couldn't find anything interesting either, but as I described above, the detection appears to be tiered. Quoting myself:

 

So in other words, I don't believe they use this level of detection. If they do, then they're very very sneaky with it and it's injected only after botting a certain amount of time, and only for a certain length of time. Like a "last ditch effort" as I described above.

 

Edit: Also I forgot to mention, there actually was a .dll file called "jaclib.dll" or whatever that contained code to catch the API input flag "LLMHF_INJECTED" (From sendInput) - although there was never a callback implemented. Weird... Very weird.. Especially since they bothered to ship it... Maybe because they realized that programmers could easily remove that flag through a hook + trampoline function, or by just unregistering it lmao (Through WH_DEBUG). They appear to have removed it though. 

My own belief is that while things like third-party clients probably do contribute; detection is massively based on whether your account has similarities to other accounts (including banned accounts) - basic machine learning. Similarities including but not limited to delays and timings, account progression and so on. Reports probably trigger the server side AC system. Maybe large disparity trades do too.

Is common information at SRL and has been for years. There was never a dll called jaclib.dll in oldschool runescape. That one only exists in RS3 so they couldn't remove it from oldschool since it never existed there to begin with. NXT actually has hard detection. jaclib.dll still exists in rs3 java client last i checked.

[asdttt]

10 minutes ago, Search12 said:

My own belief is that while things like third-party clients probably do contribute; detection is massively based on whether your account has similarities to other accounts (including banned accounts) - basic machine learning. Similarities including but not limited to delays and timings, account progression and so on. Reports probably trigger the server side AC system. Maybe large disparity trades do too.

Is common information at SRL and has been for years. There was never a dll called jaclib.dll in oldschool runescape. That one only exists in RS3 so they couldn't remove it from oldschool since it never existed there to begin with. NXT actually has hard detection. jaclib.dll still exists in rs3 java client last i checked.

Ah that explains why I couldn't find it. Haven't played RS3 in ages. 

And I agree completely that they use machine learning, or at least pattern matching. Which is why I produced this thread showing how their current logging capabilities could EASILY pickup on OSBot. Every bot client I tried actually has flawed mouse movement patterns (Only tried 2 others). 

It split off into another direction primary because Alek basically said "If it's detectable by x, then why bother fixing y".

Edit: And there's other basic stuff like NEVER loosing keyboard focus, even when the virtual mouse is "moved off the screen" that probably adds to the probability of a user being a bot. 

Edited April 26, 2019 by asdttt

[Imthabawse]

Love that you guys are actively trying to understand how to prevent botting bans and improve the client and I'm sure there's stuff going on behind the scenes that we don't even know about. With that said I've been botting multiple accounts in moderation for bout two years using OsBot so cheers OsBot keep doing what you do but also hear out the community and try to keep the peace. One love lol.

[adjacent]

This is an interesting topic. If Jagex collects mouse movement - they don't do it "just because", there's a purpose for it, highly likely botwatch related.

If Osbot manages to improve it's mouse movement and eliminate the obvious patterns - this could give a huge 1up against competion. Even if accounts survive a couple days longer with Osbot than with other bots - this will provide a significant business boost as word spreads around.

[caketeaparty]

This is gold. I've been wondering why my mouse recorder used correctly results in virtually 0 bans vs. Injection and even Mirror, even on flagged proxies. By the way, I'm pretty sure the random lag spikes on Mirror skews the mouse data a bit as well, which might be why it tends to result in fewer bans.

They can only reliably get this data on the client-side, right? That means if they use mouse movements as a detection vector (they aren't collecting this data for no reason), this is their only way to do so - transparently. It's kind of odd people are contesting this despite you literally proving it with the deobfuscated code and demonstrating detectable patterns, but at the end of the day...What works is what works.

Honestly, the only ways they can determine you are a bot are:

1. Your script breaks and gets stuck for hours, dead giveaway.
2. Creating patterns from your inputs and likely comparing them to other bots.
3. Detecting scripts/bot client. Everyone claims the client is not detected, but you never know. They don't have to load classes or dlls for this, they can probably determine whether you're using a specific bot client or running a script on a certain client by checking your behaviours against all of the data they've gathered over time, and mouse movement evidently factors into this.

There are plenty of people who play 15 hours a day farming Vorkath or something and never catch a ban, to say that you can never figure out a way to bot that long is obviously wrong. They aren't deciding who is and isn't a bot out of thin air. This is clearly one of the factors if not the most significant one, next to IP type and other patterns, like keyboard patterns if they gather that. After all, you have to move the mouse to play the game at all.

Edited May 6, 2019 by caketeaparty

[NotInsomnia]

Didn't know they actually tracked mouse movement this way, interesting read