Adwind-RAT-v3.0-1 Adwind RAT v3 0 adwind rat Adwind-RAT adwind Adwind-RAT-v3.0-1 Download( 111 ) Up vote( 2 ) Down vote( 1 ) Comment( 0 ) Favor( 0 ). Adwind-RAT-v3.0-1 Adwin Rat 3.0 Cracked by MZ tech. Download: R.A.T, Crypter, Binder, Source Code, Botnet. AlienSpy is the latest in a family of RATs such as Adwind, Frutas and Unrecom. Part of Malware-as-service platform Used as a generic name for Java-based RAT Functionality - collect general system and user information - terminate process -log keystroke -take screenshot and access webcam - steal cache password from local or web forms - download and execute Malware - modify registry - download components - Denial of Service attacks - Acquire VPN certificates Initial.
Introduction
Raw download clone embed print report. 1) Adwind Rat v3.0 Cracked 2) BlackShades Fusion Source Code 3) DenDroid Source Code 4) Hunter Exploit Kit. Now Adwind RAT is a Java RAT and the author is adrigohh the java RAT was sale for $150 Adwind RAT is the Rebranded version of Frutas RAT after Frutas RAT v1.0 then have the author have make a new RAT (Adwind RAT v1.0) Now i give screenshots and the download link You can ask me things in the description screenshots.
As the title suggestes, this post will feature a practical example of cracking obfuscated Java code, namely Allatori 4.7. For the sake of example I’ve chosen an astonishing Java RAT (Remote ‘Administration’ Tool) worth every of the $100 It got sold for, but I will come back to this later. To start, let’s compare the usual workflow of cracking Java programs and then find out why it won’t work for obfuscated code.The ‘usual’ way to crack Java programs is by decompiling, modifying and recompiling the source code. To understand what this means you need to know that Java source code, unlike e.g. C++, doesn’t get directly translated to low-level machine-code interpreted by the processor. Instead, it gets distributed in a more abstracted code set called java bytecode. This code then gets interpreted by a Java Virtual Machine similar to the .NET Common Language Runtime (CLR) on execution.
This offers the ability to distribute programs in a platform independent format (only the VM needs to get adjusted), but as everything, it comes with a downside. Since bytecode has such an abstracted, diverse Instruction set it turns out to be vulnerable to so-called decompiling, which basically means ‘reversing’ the process of compilation by guessing how the original source code might have looked like. Since this is a massive problem of not only application security but also intellectual property there are some efforts to prevent this by obfuscating the code in different ways.
One of the results of these efforts is Alatori, a commercial obfuscator starting at $290. It comes with all the features you would except from a commercial obfuscator, most important for us string obfuscation, flow obfuscation and inserting ‘invalid’ bytecode (bytcode ignored by the VM but crashing/confusing known decompilers/deobfuscators).
Adwind 3 – Overview
Adwind 3 is a Java based RAT supporting not only common desktop operation systems but also Android. It originated from a spain Proof of Concept called Frutas and got recently rebranded and sold as UNRECOM. It’s protected both by a custom login system with serials and hardware identification. Adwind is using the Swing API to draw its GUI. This means that it defines some user input elements (buttons, text boxes, drop downs..) which offer user triggered ‘ActionEvents’ (button click..) and connects them to ActionListenern performing the desired action/method. Our first goal is the ‘Login’ button of the window below.
Adwind gets distributed as an executable Java Archive (JAR) containing not only the bytecode in form of .class files corresponding to the different Java classes but also resources like images and sounds and a Manifest file pointing to the main class function (the one which get’s called on execution of the Jar).
When trying to decompile this main class using JD-GUI, we get just get an ‘// INTERNAL ERROR //‘ instead of the class functions. Of course we could look for a way to fix this, either by hunting down the locations causing them and either patching the decompiler or the class file. But even then, obfuscation techniques like flow obfuscation would result into a source code not really usable.
Messing with bytecode
Today I want to show you another approach – why going through the whole mess of decompiling and recompiling of we could patch the code directly? There are several bytecode editors to make this easier, my favorite one being dirtyJOE, which is written in C++ and supports python-scripts to perform different manipulations. Since dirtyJOE can’t handle Jars we have to unpack the .class file in question first using any zip-utility. You should really pay attention at this point since zip-archives support case-sensitive filenames (for example cG.class, cg.class), but some operating systems like windows don’t. Since Allatori is utilizing this, it may lead to class files getting overwritten without any notice when unpacking the whole archive to one directory.
dirtyJOE welcomes us with some basic information about the class if available, for example it’s parent/super-class, the number of constants (constant_pool_count) and methods. constants are basically all hardcoded references to other functions and strings used by the bytecode. You can find out more about the ClassFile structure here: http://www.javaworld.com/article/2077233/core-java/bytecode-basics.html.
If we switch to the ‘Methods’-tab, we directly see the main-Method – but before digging into it, we should take a short break – Before using any method of a class we need to initialize it to an object, and so does the JVM. In fact, it even needs to initialize the class. This is happening by invoking (object initialization) and (class initialization).
In our case, nothing spectacular is happening in , since the Login class inherits by ‘javax/swing/JFrame’ (User Interface) it initializes the basic Login form and creates the basic form elements:
To understand what’s going on, you need a basic understanding of the bytecode instruction set and how it gets interpreted. Going through all of this would exceed the scope of this post, and there are people explaining it way better than I could: http://www.javaworld.com/article/2077233/core-java/bytecode-basics.html
This isn’t the button you’re looking for
With the above basics it should be relatively easy to guess what’s going on. Basically, four Swing GUI elements get created, initialized and its references stored in the corresponding fields of the Login-class.
Adwind Rat
But hey! Those aren’t all fields, are they? Where are all those buttons, graphics – where is the Login-button we’re looking for? Let’s check the <init> method:
At first glance, this doesn’t look way better, only a single ‘javax.swing’ is in sight. But let’s take a closer look and figure out what’s going on.
If you don’t know the meaning of an instruction, you can look ut up in Oracles JVM Instruction Set Reference
First, null gets pushed on the stack (aconst_null). Then aload_0 get’s executed. This loads the first (pos 00) local variable onto the stack, which is always a reference to the object itself, similar to the .this directive in Java.The top value of the stack gets duplicated (dup) and the new top-value gets duplicated two values down the stack. Finally, the object reference get’s loaded another time. At this point, the stack should look like this:
You could theoretically get the same result by doing 1 aconst_0 and four aload_0 s, but that would be way to simple! Those this references are then used to invokespecial (call) 4 methods and in the end null gets returned – Remember the stack is based on the LIFO (last in, first out) principle. All of those functions are void methods, which means that they don’t return anything to the stack. At this pont, you also see another annoying feature of Allatori, the renaming of foreign methods and classes – B() doesn’t ring any bells, does it? And it gets even worse… If we look for the B() method, we notice that there is not just one, but three of them! This is possible because the JVM allows methods of the same name with different descriptors. Those are the three B() method in question:
- static synthetic void B(cliente.Login, java.awt.event.ActionEvent)
- private synthetic void B()
- private synthetic void B(java.awt.event.ActionEvent)
Since we know that no parameters got pushed to the B() method when it was called above we have to look at the second method, void B(). I won’t post all 381 lines but point out some important aspects.
Aha! A button. This leads us in the right direction, but since there are multiple buttons and ‘cliente.Login.g’ isn’t telling us much, we need to look for another way to identify it. How about the text of the button shown to the user? It has to get set somewhere, does it?
String deobfuscation – the lazy way
Well, this part definitively sets some text on the button, and it also loads a string, but the string looks kinda strange, and there is another function in between of the loading of the string (ldc_w ” F0@9″ and the text-setting (invokevirtual .setText(java.lang.String) which also takes a string as its parameter. This means that the mysterious ALLATORI_DEMO(String) function probably takes ‘garbage’ as input and returns a more useful string which then gets used to perform whatever operation. In Java, it might look like this:
This happens for every single usage of strings, only with different methods, which means that we just figured out where strings get deobfuscated. The way Allatori deobfuscates strings got analyzed before, actually it’s pretty simple. The method iterates through the strings characters backwards and performs XOR and AND bit-operations on them – the result gets stored in a array which then gets converted and returned as a string. Due to it’s nature, it’s possible to revert the obfuscation by applying the same method again. However the program which we are looking at is using Allatori 4.7, and here things changed a little. The actual obfuscation is more or less the same, but the key used in it is not simply pushed to the stack but calculated using different stack operations. This, and the fact that Allatori 4.7 uses multiple string obfuscation methods (with different keys) in the same method make it harder to deobfuscate the program by going through all strings automatically.
But there is a good message – we don’t even need to get our hands dirty with all of this! Since class file functions can easily used in other Java programs and Allatori didn’t bother to include some asymmetric encryption method we can import the class file (or the whole Jar) to a new Java program and call the method like any other to both de- and encrypt strings.
Because some encrypted strings contain line breaks and Java doesn’t support raw strings you might encounter some problems – you can partially fix this by enabling automated escaping when pasting text between string literals in Eclipse (Preferences -> Java -> Editor -> Typing.
As we can see thanks to the deobfuscated string, the button text gets indeed set to ‘Login’. Now we just have to find out which EventHandler get’s associated to it.
Here we go. A new instance of class i gets created, initialized and ‘added’ to the JButton as an ActionListener. When the button gets clicked, the instances method ‘ActionPerformed’ gets called…
..which calls ALLATORI_DEMO(cliente.Login, java.awt.event.ActionEvent) in our Login-Class…
which finally calls cliente.Login.B(ActionEvent). What a ride!
I already made some comments so it should be pretty clear what’s going on here – some checks if there is any input – but no _real_ checks, no web request. If we patch the return above the main(null)call (triggered by no license being selected) to nop (do nothing / 00), run the program and enter some garbage, the progress calls the main method and then closes. This means that the login/license check is not in the Login-class at all but in another castle, somewhere in that / or main() method of Adwind.main
Another castle
I will cut things down a bit at this point since finding the method isn’t really anything new – after some minutes you should have found an Adwind.B() – call at the top of Adwind.<init> which begins with this lovely VM-Check..
Adwind Rat V3.0 Crack Download Windows 7
..and also the reason why Adwind closed without any warning when entering wrong credentials:
As you can see, the method checks if ‘adwind.com.mx’ resolves to a hardcoded IP adress, probably to detect DNS-manipulation. Since the domain isn’t up anymore, the request will fail, even for valid customers (great!)
The method also generates a kind of hwid and issues a web request to the login server using a horrible case switch taking about 200 lines, but I will spare you that. Instead, why don’t we just try to nop the invoke of B() in the first place? Since it only checks conditions to exit, this actually works. If we also change the Main-Class in the Jar-manifest, we can even skip the whole login-window.
PS: Found this in the Login.main class:
You might wonder what’s the connection of Auditory, a music editor and Adwind, a ‘Premium’RAT. Answer: Complete Copy Pasta.
http://www.ibm.com/developerworks/library/j-mer0730/