Jump to content
Frequently Asked Questions
  • Are you not able to open the client? Try following our getting started guide
  • Still not working? Try downloading and running JarFix
  • Help! My bot doesn't do anything! Enable fresh start in client settings and restart the client
  • How to purchase with PayPal/OSRS/Crypto gold? You can purchase vouchers from other users
  • Try asking for help in the chatbox
  • Defiled

    $250 Donor
    • Posts

      577
    • Joined

    • Last visited

    • Days Won

      9

    Defiled last won the day on September 5

    Defiled had the most liked content!

    About Defiled

    Scripter+
    • Birthday 09/09/1995

    Profile Information

    • Gender
      Male
    • Location
      Desert
    • Interests
      Bytecode Engineering, Java, C++, Web Development

    Contact Methods

    • Discord
      Defiled#0140

    Recent Profile Visitors

    4379 profile views

    Defiled's Achievements

    1. I agree that timezones aren't a factor (in the case of daily playtimes) because that's utterly stupid to use. I never said player reports aren't used by Jagex, but they don't lead to automated bans anymore like pre-2010 era. They may lead to flagging tho. Yes Mac Addresses play a big part if its constantly changing on a single account. Timezones/local time matter if you load the account on multiple proxies/networks simultaneously as that will 100% flag the account (personally tested). So always wait some time before switching to another network. The 2 points above do matter but do not play a significant role in bans honestly. what mostly matters in Botting is action patterns, play times, & network bot density (density is very important as real players got banned simply for playing multiple accounts on the same IP including an ex-JMOD Gudi). Jagex is able to read the JVM time so when you change the proxy on the same jvm, the time won't change. but I don't think this matters or if this is even a factor they check. but I think they might compare the jvm time with the proxy location time, maybe that's what you mean.
    2. I'm not gonna call a man cute to his face lol. are you daft or somethin?
    3. You don't need to be a mod to know that, this process is pretty much in every game even shooters and even years back Not getting flagged is not easy. I believe 90% of accounts created for the purpose of Botting are flagged once they log onto tutorial island. You will be 100% flagged but I think Jagex has a threshold which if the player crosses, they either ban him automatically if the evidence is overwhelming to their automation or send to their "ICU" team to vet the player. and no Jagex doesn't rely mostly on players reporting that'll be EXTREMELY stupid and foolish as that will basically give users the power over other users. They rely on heuristics published by their automation to measure if the player is indeed a human or not. It can be simple stuff like Mouse Events to comparing current player Action Patterns to real players patterns.
    4. This will be my last reply to you, as honestly it's getting stretched way too far. Gonna break up your reply into pieces so it can be easily replied to. I do understand bots aren't the only third-party clients. The third-party clients that are approved by Jagex are given their own signature and even though they have their own signature they still happen to cause locks (yes, it's less than un-approved clients but they still occur) because Jagex knows that they aren't in control over these 3rd party clients.. well except OSBuddy. Till this day I haven't seen anyone "spoof" the official client's signature which is impervious to locks, that's why some clients use instrumentation to take advantage of the signature which is a big deal since a high percentage of botters leave due to locks. and when locks occur it's a flag on the account. a prime example of official client instrumentation is Arbiter's RuneMate. You might counter with "but RuneMate has a high ban rate", and that's because of the scripters there, rune mate has arguably the worst scripter community out in the open. Also you say this.. and that.. is irrelevant for bot detection.. well I have to disagree! I have had many accounts get banned on a normal same-jvm reflection bot and mind you.. they weren't doing anything strenuous.. merely data collection. (Wealth Checkers) I have done the same thing but on a very basic instrumentation bot for months! and the accounts still lived till about a week when I used them on a normal reflection same-jvm client to read widgets lol. I'm still adamant that instrumentation & reflection done correctly and efficiently (Ex: storing references in memory through Unsafe for an example or even direct bytebuffers transfers over sockets or rmi) is the best option out there! other than of course image recognition clients. Well thank god we have you in the community grown up and all! I can still argue that relatively there are still quite a few proficient client developers in the scene. I answered this in the previous reply (Wars are won by the best users of unpredictability). What if tomorrow a Jacmob 2.0 joins jagex? You're foolish to underestimate a half a billion $ company lol. That ego must be tamed sir.
    5. If the signature is so easy to spoof, then why has no public client done it brother? Yeah I know.. many of the new updates are just RS3 content with a new name... but that doesn't mean they're not brainstorming new detection ideas.. nevertheless never underestimate your opponent no matter how stupid they are
    6. You would think you can spot everything.. but we gotta remember the fact that Jagex has good developers and they could always come out with new shit to surprise clients like the ClusterFlutterer back in the day. The winner of every big war is the best user of Unpredictability. Having the heavy load on a separate JVM will remove the need to do checks for new tracking almost entirely. no need for new discoveries. Also through a separate JVM you could actually control multiple clients through 1 script. just think what you can do on a separate JVM... also lets not forget the signature of the Official Client which throws out the locks problem. (I'm sure there's a way to replicate the signature but that's something I'm not interested in finding out in the moment) Instead of thinking of today's findings, future proofing is a good method to stay ahead of the curve.
    7. The point I said in the the post is: "1) Scripts Running on the same JVM" You replied with "That thing can be spoofed" I replied in the reply with "You can spoof what you know, but you can't cover unknown ground" and "GC frequency is but one factor of many that encourage being on a separate JVM" Also having the heavy loads on a separate JVM will give DreamBot a cover for any future updates that have the goal of detecting anything on the JVM or something of that kind. The world of Botting is rapidly changing and going for new ways and better ways is always the right step for a better future for this community. and again just if you have short-term memory loss again : You can patch the holes in your boat (spoof) but overtime you won't be able to patch every hole and the boat will sink. also you can only patch the holes that you see.
    8. Yes I did read what you said in your one and only comment. Let me reply to the statements that I felt needed no reply to because of their obviousness You said "Official client or not literally doesnt matter, reflection is already bad enough dont downgrade to instrumentation just fix the locks? Xd" Instrumentation isn't a replacement for reflection so its not really a downgrade. (a downgrade in speed and efficiency yes, but in detectability no). It's basically dynamic injection into a JVM, so where you can communicate and interact with the Official Client. This way the Dream Team can have the reflection methods on the gamepack with some listeners (like gameticks and what not) and the rest of logic on another JVM. Did you read what I said in my thread and replies on why I think instrumentation is needed but has a cost which I think many botters are prepared to pay? You said "GC is irrelevant but if ur worried about it why wouldnt u just spoof it instead of doing what u said its literally 20x less effort" I answered this in my previous reply. You said "Painting is a bit redundant and inefficient too, what exactly are they gonna detect from a paint lmao everyone and their dads play with heavily modded clients in fact it's more sus if you're NOT using a modded client" I replied to this too in the previous reply, and yes your statement may be true if you're running the game on RuneLite or OSBuddy. and no its not more "sus" if you're not modding a client. Do you really think Jagex doesn't monitor RuneLite? with all the abusive plugins and all?
    9. Firstly to address the "just fix the locks" statement you said: This is a major problem in the community, many people quit Botting cuz of it.. so its not a "just" problem. I've talked to many new botters over my days in the Botting community and the most talked about problem is locks to the point account creators started linking the accounts and making web-unlockers to try and combat the problem. also there are many problems that can be solved with the official client and it's arguably safer. Secondly, regarding the GC problem.. GC is just one of many factors that encourage having the scripts and/or client logic on another JVM. Jagex can only play with what is on the gamepack JVM so moving the heavy loads to somewhere jagex can't touch is a big plus even with the resource-cuts. Thirdly regarding paint. yes its the least problematic out of the bunch but Jagex can detect executed events and process them server-side.. yes you can go about your spoofing ways but you can't cover ground you don't know.
    10. Hello, This is a Mouse Recorder which records several types of Mouse Actions (Moves, Drags, Clicks) then plays them for you from any starting point to any end point (compress the path or cuts it if the wanted path distance is shorter than recorded) and Manipulates the recorded path when playing it to differentiate it from the previous plays. Disclaimer: DOES NOT PLAY LONGER PATHS THAN THE RECORDED ONE. (So if you record a path which his 500px in length, you can't play a 501px path.) Disclaimer #2: This Project isn't finished and I probably won't finish it. but it does the job. I made this Mouse Recorder Several Months ago and it's not clean code as I tend not to care for code cleanliness in testing scenarios (and this project wasn't a serious one for me). 606695ec92e5f3aeb49891328fcb00db.mp4 How to use: 1) Select the Mode (Regular Moves, Drags, Clicks, etc...) 2) Click Start then follow the red box and click it (For moves and drags) 2) Click Start then click multiple times anywhere on the screen to record clicks (For Clicks) 3) Select the Mode (Regulars Moves, etc...) then Click Refresh to view the recorded samples of that mode on the right 4) To Save the recordings click "Save" and select a location. Jar file is attached CODE CAN BE READ BY DEOBFUSCATING THE JAR FILE (EX: USE JD-GUI) Enjoy I guess InputProject.zip
    11. Greetings, So over the time I spent away from DreamBot I learned a lot about Client Development & Bytecode Engineering and I've noticed somethings in the DreamBot client that could be changed to make the Botting experience better. Here are they: 1) Scripts Running on the same JVM Jagex has the ability to detect changes in the Garbage Collector Frequency and if say.. a new scripter or even a seasoned one created a script that throws a lot of objects into the garbage collector and increase the frequency that will trigger something at Jagex's Side. My suggestion here is to not use the same JVM as the gamepack and to only have reflection methods on that side while reading everything through something like Sockets, RMI, or even Memory Mapped Files. & saving objects in a ReferenceMap (where access keys are strong and the object/value is weak) 2) Loading the gamepack on Dreambot's appletviewer I've done a lot of tests throughout my scripting career and found out that accounts tend to get locked faster on a custom appletviewer than on the Official Client. I tested over 50 accounts throughout months on both clients and one of the results is: Logged into a brand new account on the Official Client: No locks (I hopped around many world and nothing happened) Logged into the same account as above on DreamBot: Locked instantly or after Hop Did the other way around and the same result. Locks don't tend to happen if the account is members (on both clients) I think this has to do with the Loader file (.exe).. I think there is some kind of signature there or something of that kind as when I tried to load the JagexAppletViewer.jar file (official client loader jar) locks occurred same as DreamBot, but when I loaded the client from the .exe file: no locks what so ever. My suggestion here is to use Instrumentation (will also solve problem #1, 2 birds 1 stone). I know I've talked about this problem to @Pandemic a year ago but this is very crucial to extremely improve DreamBot as a whole. 3) Executing Events (Mouse) & Paint Since making a mouse or painting requires overriding the native Canvas.java file or injecting into the RSCanvas this could raise flags on Jagex's part. Suggestion: For Paint: 1) Live Edit the Native Canvas class (Through a Bytecode manipulation library) and add in 3 buffered image fields, then in the getGraphics method have the paint on one of the buffered images and the game on the other then paint both of them onto the third and return its graphics instead of painting on the game graphics. or 2) Using OpenGL (through C++) overlay the paint this way (guaranteed not to flag anything but can be a bit wonky) For the Mouse: 1) Mouse can be also overlayed using C++ exbb and this way the events execution of the Mouse will be exactly as a Human Being. 2) Mouse Movements Recording + Fuzz Testing (This is an app I made to do this (except the fuzz testing bit).. has some bugs .. will probably get around to working on it more later on (when I say later on, I mean months l0l) 3) Keyboard Events (I'm not sure how the Dream Team does this so I'm gonna paste my code which I wrote 9 months back) (Disclaimer: excuse its ugliness, but it gets the point) I've basically mimicked the events reading I got from Manual Human Key Strokes (the order of the events, the information provided within the events, etc..) private static final int[] SHIFT_KEYS = {'!','@','#','$','%','^','&','*','(',')','_','+','{','}', ':','"','|','<','>','?','~'}; public static synchronized void typeKey(char c) { isTyping = true; if((c >= 'A' && c <= 'Z') || Utils.contains(SHIFT_KEYS,c)) { int mask = KeyEvent.SHIFT_DOWN_MASK; Canvas.getCanvas().dispatchEvent(new KeyEvent(Canvas.getCanvas(),KeyEvent.KEY_PRESSED, System.currentTimeMillis(),mask, KeyEvent.VK_SHIFT, (char) KeyEvent.VK_SHIFT,KeyEvent.KEY_LOCATION_STANDARD)); Utils.sleep(Utils.random(20,50)); int code = pressTypeEvent(c, mask); Utils.sleep(Utils.random(60, 100)); Canvas.getCanvas().dispatchEvent(new KeyEvent(Canvas.getCanvas(), KeyEvent.KEY_RELEASED, System.currentTimeMillis(), mask, code, c, KeyEvent.KEY_LOCATION_STANDARD)); Utils.sleep(Utils.random(20,50)); Canvas.getCanvas().dispatchEvent(new KeyEvent(Canvas.getCanvas(), KeyEvent.KEY_RELEASED, System.currentTimeMillis(), 0, KeyEvent.VK_SHIFT, (char) KeyEvent.VK_SHIFT, KeyEvent.KEY_LOCATION_STANDARD)); } else { int code = pressTypeEvent(c, 0); Utils.sleep(Utils.random(60, 100)); Canvas.getCanvas().dispatchEvent(new KeyEvent(Canvas.getCanvas(), KeyEvent.KEY_RELEASED, System.currentTimeMillis() + 33, 0, code, c, KeyEvent.KEY_LOCATION_STANDARD)); } isTyping = false; } public static synchronized void holdKey(char c, int mask, Condition condition, int timeOut) { isTyping = true; int code = 0; if (!(c >= KeyEvent.VK_LEFT && c <= KeyEvent.VK_DOWN)) { code = pressTypeEvent(c,mask); Utils.sleepUntil(condition, timeOut); } else { long currentTime = System.currentTimeMillis(); while(!condition.verify()) { if((System.currentTimeMillis() - currentTime) >= timeOut) break; Utils.sleep(Utils.random(45,100)); code = pressTypeEvent(c,mask); } Utils.sleep(Utils.random(45,100)); } Canvas.getCanvas().dispatchEvent(new KeyEvent(Canvas.getCanvas(),KeyEvent.KEY_RELEASED, System.currentTimeMillis()+33,mask,code,c,KeyEvent.KEY_LOCATION_STANDARD)); isTyping = false; } private static synchronized int pressTypeEvent(char c, int mask) { int modifier = AWTKeyStroke.getAWTKeyStroke(c,mask).getModifiers(); long time = System.currentTimeMillis(); int code = c; if(c >= 'a' && c <= 'z') code -= 32; Canvas.getCanvas().dispatchEvent(new KeyEvent(Canvas.getCanvas(),KeyEvent.KEY_PRESSED, time+33,modifier,code,c,KeyEvent.KEY_LOCATION_STANDARD)); if (!(c >= KeyEvent.VK_LEFT && c <= KeyEvent.VK_DOWN)) Canvas.getCanvas().dispatchEvent(new KeyEvent(Canvas.getCanvas(),KeyEvent.KEY_TYPED, time+33,modifier,0, c)); return code; } I've noticed that some of the event information in bot key event execution doesn't include all the information about the mask.. code.. etc... so I added that. also some keys differ in events executed before and after the Press Event. This way has really worked in lengthening the life of spammer bots immensely but nevertheless It should be written more neatly lmao. That's all the notes I can remember for now. If I'm mistaken in anything please let me know!
    12. No one knows what flags Jagex's systems and you never will unless a whistleblower comes out. But what you should know is that Jagex doesn't just ban you straight away if you're doing something suspicious.. The suspicious actions pile up to a point where it either reaches the team and they vet you or you get insta-permed if its through the roof. Datacenter Proxies are known to be one of the flags because normal players tend not to use them. also most botters that use proxies often go with Datacenter proxies, therefore when Jagex detects that you're using one... you'll be raising one of the flags. also when 1 bot is caught with a Datacenter IP, wave your arm to the other proxies that are in the same subnet of the first ip. so like consider the subnet like this: 1.0.0.1 1.0.0.2 ... if the first one gets banned, the second one is likely to be banned as well (if it's Datacenter of course, which is easy to know (through the ISP details)). A lot of things matter in Botting.. and one of the biggest things is of course the quality of the script. A lot of scripters wave the "Anti-ban" feature which is just a marketing play. Good scripts would incorporate real-player actions like "Far-clicking bank or moving the mouse outside the screen every now and then (to simulate click something outside the screen) or 5 minute idle break) into the script's actions code instead of a "anti-ban system". Another big thing is the Garbage Collector... since Dreambot scripts are run on the same JVM as the Client, changes in the Garbage Collector frequency will prompt flags. So a scripter must keep that in mind and try to make his or her's script lighter and try to not throw objects everywhere and to not take the "nullifying an object" lightly. Honourable mentions: Mouse Pattern, Mouse Injection, Repetitive Readable-Pattern Movements, Robot-like movements (Camera, Mouse, etc...), Keyboard Events Execution. There are tons of ways to make Botting more viable which I discussed in a thread I made a year back I think but I will make an updated one for sure.
    ×
    ×
    • Create New...

    Important Information

    We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.