History of the study of one jar trojan



An article on how to explore unfamiliar * .jar files.
I often get spam in ICQ. As a rule, they suggest going to one of the fake "VKontakte" with a typo in the name. But then they sent a request to authorize with a link to the photo. The message is corny, nothing new, something like: "I want to meet you, look at the picture on the link ... .., you will be interested in taking a picture with me." The link did not lead to a fake VKontakte, but offered to download the foto.jar file.
We check with antivirus - everything is OK.

Cursory review

It becomes interesting. We open the archive and begin to explore.
The jar file contained the following files:



We are dealing with a Java application. Most likely for mobile devices. We look at the main.class file with any text file editor and see confirmation - there are MIDlet calls in the program text .



It remains to figure out what this program does. Again, use a text editor. Let's look at class files. In the a.class file, we look for a hint what this application does:



“MessageConnection, javax.wireless.messaging.TextMessage, sms: //” - they hint to us that the application sends SMS.
Usually you can stop there. The file that came with ICQ spam, which is called a photograph, actually turns out to be a program for mobile devices that sends SMS.
In parallel, it was decided to see what this application does. I load the emulator, the runtime. As a result, we get:



A form with a progress bar is loaded, click OK, the bar grows, at a certain moment, when it reaches a certain percentage, an SMS is sent.
When we reach 100% - the application "spoils"

Dive into code


Attempts to find directly in the class code the number to which the message was sent were unsuccessful. Became interesting.
For a deeper study, decompile the source. Decompilation yielded half the results. One decompiler could not open the startApp () method, giving an error. Therefore, after a short search, an online decompiler was found that could open all the files, but substituted only “a” as the name of the variables. But that was enough to understand the logic of the application.
All the result of decompilation will not lead, only the most significant fragments:
Fragment function startApp () class Main.class :

  …….
      this.a = "";
      this.b = "http://ero.******.ws";
      if(this.a == null) {
         this.a = "";
	   ……..
   try {
         b var1;
         (var1 = this.a).a = var1.getClass().getResourceAsStream("/settings.xml");
         var1.a = var1.a.available();
         var1.a = new int[var1.a];
         int var2;
         for(var2 = 0; var2 < var1.a; ++var2) {
            var1.a[var2] = var1.a.read();
         }
    ………


This fragment shows that information is loaded from the settings.xml file . And a line is formed with the name of the site.

  public void commandAction(Command var1, Displayable var2) {
      if(var1 == this.d) {
         ++this.a.b;
         ++this.a.d;
         this.a.a += this.a.c;
         if(this.a.d == 17) {
            this.a.d = 0;
            this.Sender();
         }
         if(this.a.b == 100) {
            this.destroyApp(false);
         }
         this.a.repaint();
      }
      if(var1 == this.a) {
         this.a.setCurrent(this.a);
      }
      if(var1 == this.c) {
         this.notifyDestroyed();
      }
      if(var1 == this.b) {
         try {
            this.platformRequest(this.b);
         } catch (ConnectionNotFoundException var3) {
            var3.printStackTrace();
         }
         this.notifyDestroyed();
      }
   }

When we reach 17%, we call Sender () . When we reach 100%, we call destroyApp () so that the user cannot start the application again. We pass to the Sender () procedure .
public void Sender() {
      if(this.a < this.a.length) {
         a var1 = this.a;
         (new Thread(var1)).start();
      }
   }
 

An instance of a variable of class a is launched in a new thread.
Class a code snippet.
public final void run() {
      try {
   ……..
         this.a = "sms://" + this.a.a[this.a.a];
   ……..
         this.a.send(this.a);
      } catch (SecurityException var1) {
         System.out.println("!!!!!!!!!!!");
      } catch (Exception var2) {
         this.a = false;
      }
	   ……..
   }
 

So, to summarize.

This application is distributed via ICQ, it infects mobile phones, tries to send an SMS to the number that is stored in the settings.xml file, by the way: 7781 .

Check online antivirus again.



UPD Thanks for the prompts MainNika

Unobfuscated trojans with a similar working mechanism:
habrahabr.ru/blogs/java/112165
habrahabr.ru/blogs/infosecurity/113017
habrahabr.ru/blogs/personal/50072

Question on Java code for a similar trojan, with an interesting discussion:
habrahabr.ru/blogs/personal/75899

Also popular now: