People keep asking me for my “fix” and I’m considering making the source public, especially since I want to make a better deobfuscator anyway. Very few people seem to have made it work and those who do can’t really make much out of the source because it has to be renamed.
The thing I’m worried about is that someone might make an autodeobber and that will be the first step toward another Aryan-like situation, where the game is ruined for legitimate and cheating players alike.
Renaming is for noobs.
Also, I don’t think the current bots now use a deobfuscated client. I thought we weren’t allowed too 
(Last I read). Or have you worked around that one? 
You dont have to worry about me making one, I am definatly not concerned with that anymore, it basically becomes detectable when you deob it anyway doesnt it?
I would say just release it, you never know, some guy who is better than all of us with java may see the deob/deobber and make somthing great, it wouldnt hurt to try 
Well i could use a deobs for refrence.
Someone beat you to it krichevskoy, no longer do the elite of the community have sole access to deobs
he even made an autodeobber, rather good work If I say so myself, especially for a previously unknown noob (CM shortly perhaps? :P)
Well, I think showing people how to do it/releasing an auto deobber would be a great idea. How long was saev’s deobber out before the “aryan situation” happened? And most of those people would have had no clue how to use the deobber. By releasing deobs or releasing an autodeobber, there would be more people able to learn the way it works again.
I dont think many people use deobs for bots now. I personally use them for referance and rename them to understand the client better :).
With arga were going to make sure we limit users (ie, atm closed regs and doing as many user prunes as possible =P, down from 1200 members to about 300) so hopefully we dont have another Aryan-like situation, lol we better not :(. Your right, it does ruin the game for legits and cheaters.
I wouldnt mind releasing the ref if i get enough done :), just bare in mind im not good at deciding names for varibles & methods 
SDouble, no one made them an Aryan yet though
haha. your late
All your deobs belong to me.
Cool. Is it original or the same method as saevion used?
More importantly, how well does it work?
[quote=“Krichevskoy, post:12, topic:5558”]Cool. Is it original or the same method as saevion used?
More importantly, how well does it work?[/quote]
he said it is based on saevion’s deobber, but it looks all original to me, and it works very well 
(for now, cross your fingers)
Looks like saevion’s deobfuscator without the structure.
Fixing saevions deobfuscator is relatively easy to do, adding to it a piece of cake. If you can fix it, you should be entitled to a ‘deob’, spoonfeeding should be kept to a minimum.
That said, deobs are a great way of learning the client, if you are willing to put in the effort. I recall when waffendennis’ site was the only place to obtain one (if you had no idea how to do it yourself), a setup like that would be good nowadays, though with extra features.
total deobfuscation is almost impossible, we all know that, however it may be possible to gain an extremely readable client source.
opaque predicates are still able to be removed using saevions method.
exception tracing can be removed using using saevion’s method, though using a better regex
irrational shifting is easy to fix
the logical not in equality tests is also easy to fix, however it should be done in a method similar to that of the arithmetic obfuscation
arithmetic obfuscation seems easy to remove (i say probably because i havent done it). one would construct an abstract syntax tree traverse it in a manner as to standardise the operations (eg, constants go on the right) and simplify where appropriate
definition ordering is another method of obfuscation that i have noticed, this could be reversed by splitting bytecode into groups that represent a line of code, or after the source code has been produced
if statement inversion exists throughout the client. whether this is for an optimisation or an obfuscation technique is arguable, though when decompiled the nested ifs are somewhat hard to read. this might be fixed by constructing a control flow graph and negating the conditional branches
dummy arguments might be removed (if you wish to have a readable source, obviously not in a live client). this might be achieved by tracing the use of the argument through the method, or seeing values passed to the method as the argument regularly fall in or out of the allowable range, or both methods, or more… there are many ways
class fracturing is somewhat difficult, you might lump everything into one class, or you might identify methods and group them (though you might as well make a renamer while you are at it)
i dont know for a fact, but it looks a little suspicious, some methods appear as though they may have once been instance methods, if this is the case, it would be relatively straightforward to revert this
renaming would be a nice feature to have, though it would be assumed that whomever wrote it knows what they are talking about; so many “pioneers” have created mnemonics for classes that are often misleading or just bad
i am almost certain that i have missed something, feel free to add or correct me. perhaps there should be another thread for discussion of reversing obfuscation?
a deob that was alittle more readable would be choice.
It would be easy to put a line of code in my http://moparisthebest.com/rs/ script to make deobs out of the latest client when they come out.
Removing dummy args seems like it would be the best, if the hardest, thing to do. And like I was telling you last night, 90% or more of them could be removed by simply checking all occurrences of the method call and removing whatever value is constant. The other small few that use a variable that is only set once would slightly harder to remove, but still not that bad.
About class fracturing, it is certainly one of the hardest things to do. However, if the rest of the deobfuscation worked well enough, as in removed all dummy args, removed if statement inversions and blocks of code that are never executed, we could then in theory identify most methods via a control flow graph and arguments and then group them together in correct classes defined by a template that was written by a human before hand.
[quote=“Moparisthebest, post:17, topic:5558”]About class fracturing, it is certainly one of the hardest things to do. However, if the rest of the deobfuscation worked well enough, as in removed all dummy args, removed if statement inversions and blocks of code that are never executed, we could then in theory identify most methods via a control flow graph and arguments and then group them together in correct classes defined by a template that was written by a human before hand. [/quote]exactly what i was getting at, one would assume you would have a mnemonic attached to the ID, so renaming would go hand in hand
Yes, if one were to rename you would most certainly do it at this juncture.