Jump to content

asdttt

Members
  • Posts

    152
  • Joined

  • Last visited

  • Days Won

    3
  • Feedback

    100%

Everything posted by asdttt

  1. Woow it's almost as if JNI/JNA calls native code huh?
  2. Uhh I said it was undetected on the JVM level, which it true. Low level, of course it is detected..
  3. I'll work on a way to remove all flags like LLMHF_INJECTED and so on. There's 100% a way to hide the fact it's an emulated input without the use of a driver Edit: ASSUMING they're using native code to check input that is.. Wouldn't put it past Jagex but I just don't see why they'd bother logging press->release delays when they have a solid way to detect emulated mouse clicks
  4. My mouse's driver uses SendInput.. (Assigned to bumper through Logitechs software) I think you're WAAAAY overthinking this man. They're clearly checking for the delay between press, and release. If they had a way to detect non-hardware clicks, why the fuck would they bother getting the delay lol? Edit: Also, does the on-screen keyboard not use SendInput API...? Of course it does. Edit2: Not to mention if they had native code, we'd be able to see it. Kinda hard to hide software being ran on the endusers computer..
  5. Explain how you'd detect that on the JVM level.. My own mouse assigns macros using sendInput... Atm on my mouse, I use one of my bumpers for mouse clicks because the left click is broken from being dropped. Also the input event delays are logged as clear as day in runescapes code...
  6. Here's the auto-clicker I made in C++. Put simply, you need to input your minimum click delay (In milliseconds), and your maximum click delay (In milliseconds). The mouse will then emulate a normal person clicking their mouse at the rates you provided and at the current position of your mouse. Keep in mind that these rates will NOT be exact, and simply kept as some sort of target goal. It also wont click at absurd speeds like 20 clicks per second or so on. <LINK REMOVED BY STAFF DO NOT RE-UPLOAD> This auto-clicker, unlike most auto clickers, does not produce flaws that the JVM could pickup on (As far as I know that is...). If Jagex somehow manages to distinguish a hardware click from a software click through some crazy magic then this will obviously get you banned. I doubt they can detect it, but I still wouldn't use it for large time periods. FYI: I tested Gary's Hood autoclicker, and unless I'm using an outdated version or it interacts differently with RS's window, it produces the same flaws I described above. Not recommended. To those who have bypassed using it, lucky you. IMO Jagex purposely lets people bypass at times just to further you from figuring out why the hell you're being detected lmao. Jerks Timings: ->> Mouse press timings (MS): 51 ->> Mouse press timings (MS): 113 ->> Mouse press timings (MS): 147 ->> Mouse press timings (MS): 75 ->> Mouse press timings (MS): 72 ->> Mouse press timings (MS): 56 ->> Mouse press timings (MS): 57
  7. Well for starters, let's accept the fact that Jagex sends mouse movements to the server for analyzing, AND I myself was able to very very easily pickup on OSBot's using basic math using the exact same data they're sent. There's serious flaws in the movement, mostly the last bit where it ends. Please review my research so you too will actually see these flaws. I have no idea how you find this to be naive, especially since a fairly large amount of anti-cheats rely on mouse DPI movements to detect certain hacks - even aimbot. OSBot's mouse movement is flawed, as simple as that. If you dispute that fact, please give me insight because I'd love to see you defend that obvious pattern... FYI, many anti-hacks actually use 50MS tick sampling. Hell, minecraft's servers RUN on 20 TPS. It's a great number for anything but visual rendering. To Next, I've searched through the runescape source numerous times and yes. To say we're not ever able to bypass is a bit absurd considering WE are feeding them the data. You need to remember that even though Jagex made the client, they're still on a virtual machine. Java is VERY VERY manipulable on purpose due to how high level it is, and the nature of how it's deployed on many platforms - which I'm sure you already know. Autoclickers are easily detected because, as you said, they do not execute the same click as a mouse would. Although an internal autoclicker, as far as they know, does not produce the same flaws and you're then in control of nearly every factor including press/hold timings (Assuming you don't create flaws...). They also do not do any stracktrace checks from what I've seen, although tomorrow I'll be sure to search for that. If you'd like me to provide hard evidence on click sampling, I'll do so tomorrow. It's hard to elaborate without providing at least something to back me up. So for example: https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L3371 That's where they send the timings of the mouse, and here's where they track the mouse input/timings (Using normal Java events)... https://github.com/zeruth/runescape-client/blob/master/src/MouseInput.java Also if they did detect all autoclickers, that wouldn't explain the HUGE amount of people using them on their mains and never getting banned. As for the garbage collector... Your actually absolutely correct on this one. Jagex at ANY time can request a sample of your garbage collector. IMO a garbage collector simply can't be enough to distinguish a bot client from an official client, but they could probably detect a difference between a non-official client and official. Although I could be wrong as I myself haven't personally tested the garbage collector timings, oldGen size, newGen size, or frequencies between collections. This would be banning solely on assumption though which I doubt Jagex would do. Here's the nearly-de-obfuscated code for that: https://pastebin.com/FzdBmKPL It's just measuring the actual collection events rather then memory consumption. Still though, this is a very unstable measurement and I doubt they'd ban us soly based on this. However.. There is one other thing they could possibly use to directly detect a bot, although I still kinda doubt they'd go to this extent. They have a class checker which they, like the GC info, can request at anytime. https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L4315 Weird right? I'm sure they use it for debugging purposes and possibly client compatibility/version checking, but you can't deny they couldn't use that to snoop around the JVM and find some bot classes. Especially considering how specific java packaging is. And this isn't anti-ban. The whole "anti-ban" thing makes 0 sense. There's no such thing as some magical thing that makes you unbannable. It's a combination of your bot's ABILITY that lead to a ban, not checking skills, not taking breaks, and not talking in chat. For instance, mouse movement, button hold times, mouse click-rate (Yes IMO they take account for this), mouse hold-time, and so on. There's no SINGLE check on their anti-hack, so implementing new mouse movement wont suddenly make OSBot 100% undetectable. Although, it's a major step in the right direction. Not sure if you're aware of this, but there is a LAAARGE amount of people who bypass.. Not going to name any groups because of how censoring you guys are on here, but Ik that you know they exist so please stop pretending bypassing is impossible. Not to mention, I've still yet to be banned..? If you'd like to discuss this in private, I'd love to show you a much better way of moving the mouse without generating patterns. -- Oh and just to close this, who really cares what Jagex says..? You really think they'd give critical detection information out to the public? I doubt they'd even tell their own moderators what they use to detect the majority of bot clients. Personally, I think they purposely spread false information just to fool botters.. I mean come on, this company couldn't even do dead man mode correctly without killing everyone. Edit: Eh I made something quick with JavaFX to further display what I meant by autoclicker flaws (Press->Release): My normal mouse: ->> Mouse press timings (MS): 78 ->> Mouse press timings (MS): 63 ->> Mouse press timings (MS): 59 ->> Mouse press timings (MS): 70 ->> Mouse press timings (MS): 75 ->> Mouse press timings (MS): 87 Autoclicker: ->> Mouse press timings (MS): 0 ->> Mouse press timings (MS): 0 ->> Mouse press timings (MS): 0 ->> Mouse press timings (MS): 0 ->> Mouse press timings (MS): 0 See? When you use that windows event, you have a delay of 0. This is also true if you make an internal autoclicker, but don't delay your events. Jagex is sent this data which they collect using the JVM's event's. Edit2: Also please at least give me some level of respect. I'm not some random moron shouting at potential super cool anti-ban features. I'm a fellow programmer trying to help this community by finding flaws in OSBot. Many reject me simply based on my account age, but I'm not full of shit. At least read what I have to say and test it for yourself before tossing it out the window like it's meaningless.
  8. Account's dead. Even if you manage to unlock it, it'll get banned by the next wave. Make another
  9. OSBot IMO has actually done a very good job. It's up to the scripters to make their scripts look legitimate though. Only issue with OSBot atm would be its mouse movement's nearly 100% consistent mouse patterns. I'm sure the developers are currently working on changing that movement.
  10. Yeah residential IP's are absolutely better then using a proxy in terms of banrates. There's still a few proxies/VPN's out there that don't flag this system, but it's very few. You just need to check your own IP's against many different blacklists such as https://iphub.info/
  11. Nah, stealth injection isn't detected. Those scripts are just detected. More intensive tasks such as mining or agility result in higher samples which therefor leads to faster bans (In theory). You'd be better of trying to find a reputable private script developer then buying premium/VIP scripts or using free ones.
  12. I added some more explanation as to how certain mouse movements are logged for anyone who was confused by the obfuscation or integer compression.
  13. I really don't know how well this will work against Jagex's heuristic checks though. I mean moving from one exact pixel to another exact pixel in 1 movement multiple times can't be safe. I was thinking maybe I could integrate recording with the actual bot however.. Like rather then repeating one pattern, it'd take all similar repeated actions (Like moving your mouse from an ore, to another ore), then slightly modify them to click in a different position, and move on a slightly different mouse vector. So you'd create a pattern, run it through many times, then the bot would randomize every "frame" in some aspect to fool pattern detection. Could also bind frames with entities, so if the frame fails to interact with this entity, it'll retry.
  14. No issue with me with iron collector bots
  15. Private/personal scripts > Any other (Even paid) People making private scripts generally know bypasses. Although this is not always the case so I'd recommend you either make your own, or find a reputable seller who is actually able to bypass to some extent. Injection is not detected directly, however there's two possible ways they could abuse their debugger packets to detect the client (These packets only get sent upon request by the server): Possibly by their GC check: https://pastebin.com/FzdBmKPL However, this would NOT prove whether someone is using a bot client. Rather, it may just give insight into whether or not the user is using the official client or not. That's still a MASSIVE stretch though considering short lived memory tends to get collected quite often, and having a high resolution with a massive amount of entities around you would also increase memory usage leader to more often GC events. Very unlikely this is used for anything but debugging Possibly by their class check: https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L4315 https://github.com/zeruth/runescape-client/blob/master/src/Client.java#L3273 This appears to be more of a debugger check, like for checking whether your client is outdated or simply incompatible. However, they could also directly check whether a class belonging to OSBot exists (Injection only of course). Once again, I highly doubt that because it'd be a super simple bypass. But its' there :shrug: I highly doubt they detect Stealth injection though. It'd be too easy to bypass those checks. Mirror-mode simply insures your safety I guess.
  16. Jagex has nothing directly to detect it. However, if disabling rendering has a major effect on the garbage collector, it's possible they could detect it with: https://pastebin.com/FzdBmKPL You wont get banned for disabling rendering though. Even if the GC check returned some odd numbers, how would they differentiate that from a client like RuneLite.
  17. Nah I'm good. Why waste my time on people who don't believe me despite the evidence I've brought forward. Hell I bet even after those samples, those same people will still express concerns about my samples lol. I'm sure some people at least took something from this topic which is all I can hope for.
  18. Just stop it at this: OSBot needs new or altered mouse movement. The current CAN BE easily detected based solely off the data collected by Jagex. IMO, and in my own tests, it is. Whatever that means to you is up to you. Edit: And I'm not going to waste my whole week building a bigger sample size for you guys. I like this community, but not THAT much lol. Either take what I say into consideration, or don't. Completely up to you. But I wont ever deny what I've said here.
  19. Well here's what throws our entire argument under the bus. You don't believe anything I say. We'll never know what they do with the data. No fucking anti-cheat to ever exist blatantly tells hackers how they're being detected so please stfu with that. Everything is not based on trial an error unless you decide to take that route. For me, everything is based on being able to analyze the very data they are analyzing and seeing if I can pickup on it. If I can, change it. If I can't, then I'll move on to trail and error. The only reason I'm suddenly bypassing on all my scripts is because of using new mouse movement. Whether you want to believe that is up to you. But imo, that's a pretty fucking solid link lmao. Enough of this argument. I've shown more then enough evidence. You can keep saying "Oh yeah!! Well maybe they collect thousands upon thousands of mouse samples so they can tie it in with the game engine! Yup!" Even though - BTW, they only started doing this AFTER they implemented the new heuristic checks... HMM What's absolutely known: OSBot doesn't have human mouse movement Leave it at that and please don't bother me with another one of your "OH YEAH BUT HOW DO YOU KNOOOOW THEY ARE USING THIS DATA TO DETECT MEE!!". Data is present on their servers. Same data is detectable by myself and anyone else who reads my samples. Therefor, needs to be changed Edit: I didn't even fully read you because I was pissed, but: "The mouse is also just a piece of the puzzle." Yeah no shit. Once this is fixed, I'll move onto other OSBot API related aspects that are easily detected (If there is any). Until then, fix the mouse movement
  20. 1) I mean they're logging the differences between X/Y for small/medium movements, and the position for larger movements. They're also logging the time between each movement. Therefor, they're most certainly viewing/checking individual mouse movements, just as I did in my sample. They have all the data they need to figure out OSBot's flaws 2) ????. Of course they wouldn't show their "top secret methods" (Which btw, are a lot more common then you think lol). But as you can cleaaaarly see, they're logging mouse data, and the perfect amount to figure out the flaw for themselves. 3) Based on previous experience with hacking/anti-cheats, I can relate to some of the detection methods they're most likely using. Flaws being the easiest, while patterns not being far behind. Do I personally know what they do with the data? No? But can I speculate and use the same data they're collecting to see if I too can detect it? Absolutely yes! Jagex didn't invent Heuristic/anti-cheat. They've merely implemented it into their own system and tuned it to fit. We know what data we're sending them, and we can manipulate that data however we want. So lets start with the flaws, then move onto the patterns. Current most obvious flaw is the mouse movement - which as I've showed you.. Jagex has this same data being sent to them (I literally rebuilt the obfuscated code for u wtf). Edit: I'll give a prime example of a flaw in one of my aimbots on battlefield. I was making my aim based on YAW/Pitch of my character/camera, rather then mouse delta + sensitivity factors. Why is this a flaw? Well, you see, the camera is moved based on mouse delta, therefor if my yaw/pitch movement wasn't align with what a mouse would of made, it's easily detected
  21. Read the initial post. There is where I post where they feed the an array your mouse positions on a 50MS tick cycle, then I also post were they ship it off. Few things the code tells me as to what they're tracking: ||) Equal, or zero movements are tracked by ticks. If you don't move your mouse for 30 ticks, they'll know. 1) Movement of the mouse is tracked, smalls/medium movements exactly by this (Reconstructed): int yDiff = (recordedY - previouslyRecordedYMove); int xDiff = (recordedX - previouslyRecordedXMove); handler.packetBuffer.putShort(yDiff + (idleIndexesPassed<< 12) + (xDiff << 6)); idleIndexesPassed = 0; movementIndex = the indexes skipped before finding a mouse move in the X/Y mouse recorder. Used to track time between mouse movmenets. 2) Larger movements that are made in less then 8 ticks of "idle" mouse: int var10 = (recordedY * 765 + recordedX); handler.packetBuffer.put24bitInt((idleIndexesPassed << 19) + var10 + 8388608); idleIndexesPassed = 0; 3) Large movements that are made 8+ ticks from being "idle" int var10 = (recordedY * 765 + recordedX); var14.packetBuffer.putInt((field608 << 19) + var10 + -1073741824); idleIndexesPassed = 0; The majority of OSBot's movements would fall under #1's logging. The others are just for larger mouse movements (in terms of last X/Y -> new X/Y) What does that mean? Well for starters, they can easily pickup on those last 3-4 samples of OSBot's flawed mouse movement as it's sent to the server. Edit: Why do they record mouse movements like: (recordedY * 765 + recordedX);?! Well, they do that because they're lazy and combine the integers as so. You see, they cap the X axis at 764, therefor it can never be over 765. So getting the recordedY from the recordedX in that single integer is basic math. It's just like that for performance So they could fetch the X/Y of a large movement from that recorded integer like: int combined = (100 * 765 + 50); #Equals 76550 int y = (76550 / 765); int x = (76550 % 765);
  22. Idk feel free to ban me I guess..? Wont help the client in anyway though
  23. It's my brother's account obviously MonkaS
  24. For all you know I have an alt with a paid subscription. Don't worry about it. It's for the best
×
×
  • Create New...