Jump to content

Excels

Members
  • Posts

    56
  • Joined

  • Last visited

Reputation

0 Neutral
  1. True. Disabling the garbage collection is a gutsy move, especially when java isn't very well known for manual memory management. Garbage collection isn't disabled, per se - it's just so clamped down now that it can't help but be considered disabled. If the memory locations are explicitly released then there won't be much of an issue, but that essentially turns Java's memory management scheme into C++. On to the actual Object[][]: It's just given bot makers a really interesting problem to solve. Given enough time, it will be overcome. I'm not sure what this would accomplish for the long run yet. It's far, far, FAR less efficient than C++'s manual garbage collection. Jagex basically needs to keep track of objects and release them manually. Essentially, think of its this way: before, a garbage collector went around picking up garbage. Now, we have two parallel universes. The moment one garbage collector - Jagex's - picks up a piece of garbage, it is magically transferred to the parallel universe. Then, Java's garbage collector picks it up and releases memory (recycles it). Ignore double finalization. This is obviously highly inefficient. I've thought of another thing. Mountains of data have shown that most objects are "dead" moments after creation. Modern GC is tuned for this; they segment objects into generations. Basically, you have new - aka eden - mid, and old generations. Normal behavior involves the garbage collector prioritizing checking eden first - because that's where all the garbage is! Now, I don't know how good Jagex's garbage collection scheme is. I don't expect it to exactly be optimal; which would involve immediate release moments after the object is no longer used. In any case, they've probably flipped the paradigm around which GC is designed upside down. It's almost as if people suddenly decided to move all their garbage cans into 50 foot sequoia trees. The garbage collector will scratch his head, wonder where all the garbage is; and when the heap grows too large, will eventually invoke "stop the world" - a full stop to execution and a full graphing of references. Pause times for this often run into thousands of milliseconds... An array of Object[][] is actually very hard to get around. The botter has to figure out the PRECISE object layout, since the type is (hopefully) hidden on the server. Also, properly encyrpting and randomizing the layout of the object array would make it difficult. The thing is, yes, you can crack the object array. But how difficult is it? Can jagex just shift things again and make you have to do the same amount of work on your end for little work on theirs... Being able to typecast out the object array is a very useful feature for explicitly hiding the contents of the object from the calling code. Well, you could always instanceof the objects in question through a ton of known types. Or, you could try reflection on the object itself. Jagex broke reflection using obfuscation, and not, if the info we have is correct, by actually prohibiting reflection. Here's how you get type: Object o = Main.ClusterFlutterer[234][567]; Class c = o.getClass(); Can you explain how you would typecast out the object array? Don't you eventually have to dereference the object to do anything to it? And how would you have type stored on the server? EDIT: I just got it, Object[] are a subclass of Object, and Object[][] are a subclass of Object[] and Object, etc. But I still need some help seeing how that helps. And does anyone think it wouldn't be a bad idea to split off all the technical discussion?
  2. Theory: Due to clusterflutterer's approach of holding a reference to every single object, it torpedoes effective memory management by Java. RS now must explicitly nullify object references. This confuses the garbage collection algorithms Java uses, forcing it to resort to the old graph-tracing Stop the World garbage collections. I really hate the fact I can't get on rs reliably atm. Not only can't I invest in the market, but I can't do some self-learning by having my JVM print out advanced GC info :(
  3. The idea that "getting rid of bots doesn't hurt the game" ignores the fact that the continued grind, along with bots, was decimating legitimate player activity. Bots served to mask this.
  4. So they haven't really done anything that inventive. They just dumped everything into a giant Object[][]. They probably have some code generation tool for it. But really, it doesn't really prevent the botmakers from doing anything; they'll just need to be really aggressive now. I can totally see some smart person using bytecode instrumentation - almost like a profiler - to intercept any constructor calls and maintaining private references to everything. And it doesn't prevent reverse engineering of the network protocol. Moreover, there are definitely performance issues. If they dumped every single object into an Object[][], how will garbage collection function? Maybe they're using something from java.lang.ref instead. Otherwise, they need to explicitly release every single object reference, to prevent unholy memory leakage. This is practically like explicit memory management, in a language that has memory management built in. Even in compiled high-level languages, the heap taken care of by the compiler. It's a very interesting, albeit limiting, approach they've taken. Also, I think they just made it impossible for them to use generics. It's not exactly a mark of a bot if you don't talk. This has been discussed to death. It's a mark of not being a bot if you talk. Not talking is not the mark of a bot. It's not, though. Like I said, it's been discussed to death. Many of the more popular scripts have 'human-like' actions programmed into it, like bankstanding for a small amount of time, periodically examining people and objects, turning the camera, and talking. Well, if I'm talking in HYT chat constantly, and I make sense, either I'm a person or the best chatting AI ever invented; and I should be working for google designing their next advance in search algorithms, having passed the Turing test... I'm not talking about Siri like intelligence - responding to queries about my levels and what not - but actual intelligence. Of course, there could be bots that allow chatting while botting :s Ok -- I LOL'd IRL ... :lol: But, here's a question for you (or anyone else who wants to answer it) -- at what level will you accept Clusterflutterer to be a "success"? Only if it manages to eliminate 98% of all bots AND these accounts and all correlated accounts are permanently banned? Are you willing to accept less and just appreciate the effort? :unsure: Right now, Jagex says that the changes will stop 98% of the current bots. Now, assuming they're honest after the fact, that should mean around 100,000 bots active at any one time. Again, I assume that's the number of bots messed up after each update only this time they stay messed up. If it's not near 100k, then I'd consider it a failure. Now, how they treat those that they've identified is another tale. I don't mind rollbacks cause it does the same as banning and starting a new character for most. That's assuming they're just botting for levels and not gold farming for RWT. If 98% of bots are stopped and you expect 100k bots active at any one time, then you're saying that 50 x 100k = 5m bots are active at any one time. That makes no sense. Bots don't need to log off after long hours. That 100k could represent just the computers set up for botting with accounts rotating through them. There's no telling how many throw away accounts are on that. However, if the average number of active players at any one time is now about 50% of the average over the last year, I think it'd be safe to say that Jagex did its intended change. Right now 93k players are online, so what was that like over the last week at this time? Of course, I'm more interested in what happens in four weeks when what Jagex actually did is better understood. There'll still be bots, but new methods will need to be found to circumvent both Jagex auto detection and basic player tricks to mess up the bots. You still haven't explained things in a way that makes sense to me. If there are 100k computers set up for botting, each with multiple accounts, then the number of bots shoots up to an even higher and more ludicrous number. Fact is, on the rs front page we see how many players are online at one point. I don't ever remember seeing anything over 1m, much less 5m. It doesn't matter how many throwaway accounts they have or mules; 100k botting accounts active at any time after a 98% reduction implies an original steady bot population of 5 million.
  5. The 2% that survive will be auto clickers and pascal based bots. However they're hugely unreliable and high ban rates, reflection and injection actually deal with the java code. Well, not for things like alching. Can you explain how pascal based bots work? Why pascal? Why not C? Ok -- I LOL'd IRL ... :lol: But, here's a question for you (or anyone else who wants to answer it) -- at what level will you accept Clusterflutterer to be a "success"? Only if it manages to eliminate 98% of all bots AND these accounts and all correlated accounts are permanently banned? Are you willing to accept less and just appreciate the effort? :unsure: Right now, Jagex says that the changes will stop 98% of the current bots. Now, assuming they're honest after the fact, that should mean around 100,000 bots active at any one time. Again, I assume that's the number of bots messed up after each update only this time they stay messed up. If it's not near 100k, then I'd consider it a failure. Now, how they treat those that they've identified is another tale. I don't mind rollbacks cause it does the same as banning and starting a new character for most. That's assuming they're just botting for levels and not gold farming for RWT. If 98% of bots are stopped and you expect 100k bots active at any one time, then you're saying that 50 x 100k = 5m bots are active at any one time. That makes no sense. It's not exactly a mark of a bot if you don't talk. This has been discussed to death. It's a mark of not being a bot if you talk. Not talking is not the mark of a bot.
  6. Yes, there are ramifications. All anti-cheat software has them. It's would be a very high impediment to bots. And yes, in the end the computer has to make sense of it; but other processes don't have to. The rs process must make sense of it, but neighboring processes don't have to make sense of it. Rs could store its keys in a hard to find memory location, and continually zerioize and change it. It could hook into available cryptographic APIs intended to hide the keys from every process but the source process. (encrypting the packets is my idea as to a countermeasure against a reverse engineered client that basically is a drop-in replacement botting client; not something I think jagex is using or needs to use). I assume that they will have to port code to each device separately. It may not be necessary with Android and iOS, given the strong separations between apps. Of course, you can modify the OSes themselves...
  7. This is complete bullocks. Any idea how incredibly WRONG it would be to install spyware software on user's pc's and scan them without our permission? That would mean every company out there could insert spyware to check for passwords, sensitive information or other personal things. Think twice before posting this stuff, makes no sense at all :D This is exactly what almost every anti-cheat mechanism does.
  8. I believe CAPTCHAs were defeated in RSC not via machine vision, but via a distributed system. The idea was that a small proportion of botters would be solving captchas at any given moment. It would be interesting to see how effective that would be today.
  9. Given that Jagex is now requiring the usage of signed Java, does anyone else find it probable that Jagex - given the ability to run arbitrary code on your system through JNI - has implemented something like Warden, Punkbuster, or VAC? They could scan the memory space and your hard drive for botting programs. Also, they may have rewritten key parts of their client in native code and used something like http://en.wikipedia.org/wiki/ASLR to hide their locations, preventing reflection. A further method of defence would be to somehow encrypt their network packets...
  10. I'm going to be brutally honest; Sonikku; the two times I entered your chat; no one really responded. The majority of people there are people who sell fast larges, and they are generally not interested in dungeoneering with people other than their team.
  11. It would be interesting if someone could test this; this guaranteed healing is a huge change if I understand it right.
  12. Depends on what you do really. If you're a hardcore magic PvPer, definitely go with the blastbox. If you're just a regular training dude or simply skilling, tome of frost is the better choice. Sonikku, have you noticed anything funky with fire blast in dungeons recently? See http://forum.tip.it/topic/302323-magic-accuracy-nerf/. Also, why do you recommend tome of frost over blastbox? I realize there's increased accuracy, but when would you ever use its water providing abilities except for say, water blast? The magic blastbox has an effective 5% extra damage. Also, you should mention that sighted longbows are 1 rank faster, so sighted longs on rapid are equivalent to shorts on accurate with a lot higher accuracy. Shortbows may still be higher xp, though... Finally, how long are your average large c6s and how much xp do you get? I was just wondering how my best dungeon with world 7 randoms - 29k xp in 27 minutes stacks up. One more tip - the ferret catching room can be done in f2p if you have someone with the requisite hunter skill, by catching the ferret.
  13. In response to the person who was talking about my 5 hits under 30 - it was 5 hits in a row. I would consistently hit under 30. I've run through 2 more c6 larges, and I estimate around 30% of my hits are under 20 and 70% are under 100.
  14. I am not imagining things, at all. I do not store chaos runes in my blastbox. I use a normal fire staff. I recorded a max hit splat of 77 with fire blast in a dungeon. A teammate in my dg team with much higher mage than me was also reporting a lowered max of 146. I'm going on a c1 right now. Maybe that's a glitch with dungeoneering or fire blast specifically, but all my spells have been functioning normally. You should probably submit a bug report. Or something f2p related...
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.