5

Just now I was testing a very simple code in Java when I noticed a strange thing. On compiling the program my antivirus detected it as trojan and deleted the jar file.

Further it is not allowing me to compile the program. The above characteristic is not displayed on removing str.replaceAll() from the code.

  1. Why is this happening?

  2. What kind of exploit is it in Java and how can it be fixed?

  3. Why using str.replaceAll() specifically shows this kind of behavior?

My Java code is

public static void main(String args[]) 
{
String str="1000010111111010101010101001111110111010110101000001000000000000000000000000000000000000000000000000000"
    + "111111111111111110000000000000000000000000000000000000000000000000000000000000000";

System.out.println("String len="+str.length()+"  No of ones= "+(str.length()-str.replaceAll("1", "").length()));

}

Antivirus Warning enter image description here

techraf
  • 9,141
  • 11
  • 44
  • 62
A. Sinha
  • 377
  • 1
  • 3
  • 12

2 Answers2

4

Just a bit of conjecture here, but there may be some common patterns the av uses for all languages it can analyze deeply, and the pattern displayed in your program is quite similar to the sort of encoding one sees in obfuscated javascript (where they will have a string, perform some operations on it, and eventually end up evaling it). This is a heuristic signature we're talking about, so it could be something like that.

Does the signature still fire without the code which counts the 1s (specifically the call to str.replaceAll)?

techraf
  • 9,141
  • 11
  • 44
  • 62
broadway
  • 444
  • 2
  • 3
  • The code runs fine without str.replaceAll() but displays warning with the method being used – A. Sinha Oct 15 '15 at 08:15
  • I suspect the av heuristic combines a suspicious string (possibly a long string containing just valid hex characters, could be nearly anything) combined with replacement operations on the same string. As heuristics go, though, that's probably a lot more valid in js than java. – broadway Oct 15 '15 at 08:25
  • Sir How can I verify the exact cause of such behaviour or could study the pattern generated by the above piece of code? I shall be very much grateful 2 u if u cud provide me the link to some study or research related to such patterns, for the better understanding of the concept :) – A. Sinha Oct 16 '15 at 08:49
  • Assuming their support won't tell you how this specific av signature works, your choices probably come down to experimentation based inference or binary reverse engineering (probably against the eula). – broadway Oct 16 '15 at 08:54
1

The code you have written, when compiled, matches the signature that your AV uses to detect a trojan. That does not mean that your java program is an exploit, or that it could do any harm, only that there's a similarity strong enough that your AV has flagged it. It could be the long string of ones and zeros, or what your program does with it.

GdD
  • 17,291
  • 2
  • 41
  • 63
  • Sir but the code runs fine without str.replaceAll().......which means whatever str.replaceAll() does internally acts as signature to the AV. How can this be analyzed that what exactly does .replaceAll() method does which leads to the generation of such pattern. – A. Sinha Oct 15 '15 at 08:30
  • The malware scanner is not looking at the source code, but the compiled result. If you wrote a method that did the same thing as str.replaceAll() it would probably work, if you changed the string to something else it may work. If you declare extra variables and defined and used methods which did not actually do anything it might work because the JAR file compiled would be different – GdD Oct 15 '15 at 10:22