Into Android Meterpreter and how the malware launches it — part 2

Connecting to attacker’s server

private static final byte [] configBytes = new byte[] {                                   (byte) 0xde, (byte) 0xad, (byte) 0xba, (byte) 0xad, //placeholder                                   /*8192 bytes */ 0, 0, 0, 0, 0,... };...Config config = ConfigParser.parseConfig(configBytes);
PowerManager powerManager = (PowerManager)  context.getSystemService(Context.POWER_SERVICE);                                   wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, Payload.class.getSimpleName());                                   wakeLock.acquire();
if ((config.flags & Config.FLAG_HIDE_APP_ICON) != 0) {                                           hideAppIcon();         
}
The argument “url” is read from the malware’s hard coded configuration. It contains the host and port to connect to in (else). Or if the host is missing, a server Socket is created on the port mentioned in the config.

Hard-coded configuration

Format of hard coded configuration bytes. This can be completed optionally by other parameters such as proxy host, user, password, user agent…
$ strings classes.dex | grep "tcp://"
tcp://87.19.73.8:24079

How the server sends commands

On the smartphone, this is the code which gets called once a session is established with the remote server. The input stream (in) is a Jar (stageBytes) sent by the attacker. The attacker specifies which class name should be loaded (classFile) and the code automatically calls method start() within this class.

How is the malicious code triggered?

The MultiDexApplication constructor starts the malicious service, Xmevv. That’s how everything begins.

Who is behind those malicious samples?

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store