SLAE Helper Scripts
I decided to share the scripts that I have been working on to assist with my assembly language programming projects while completing the 64 bit edition of the SecurityTube Linux Assembly Expert course and certification.GitHub Link: https://github.com/rtaylor777/nasm/blob/master/helper_scripts.zip
Target Operating System: 64 bit Linux (x86_64 GNU/Linux)
About
The work directory contains the main scripts.
The work/templates directory contains a skeleton of a c source file and a nasm source file.
The work/info directory contains some scripts to help with remembering where to get information etc..
As you might expect the scripts are intended to be run on 64 bit Linux. I use Kali Linux for this project.
Unzip
To unzip the scripts put the zip file into the directory where you want the contents to be extracted and type:
unzip helper_scripts.zip
Or you can specify the destination directory on the command line like this:
unzip -d /root helper_scripts.zip
General Strategy
The general strategy for using the scripts is that you would keep the scripts in a higher directory than your projects.
You would create a subdirectory within the work directory for each project for example. This should reduce the number of files within the project directory to the minimum making it easier to find the desired file and more efficient to use TAB completion on the command line.
Then to run the script you would simply type ../Assemble filename.nasm etc.. I will include some examples when I describe the function of each script further along in the Blog post.
Keeping the scripts in a parent directory means that you don't have to copy them from one project to another to use them and you only have to maintain one copy of the scripts.
If you are familiar with TAB completion on the command line the scripts can save some repetitive typing.
For example:
../A<tab> should fill in ../Assemble
And if your assembler source file was named ExecveStack.nasm in the current directory:
../Assemble E<tab> should produce ../Assemble ExecveStack if you already have other files with the same name and if you don't it will complete the command line ../Assemble ExecveStack.nasm.
The scripts echo the command that is about to be executed before actually running the command so you can see what the command is actually doing.
Example of Assemble and Link
Example of Compile
Example of Debug
gdb -q filename -tui
which hides the command line with the gdb interface. After exiting the gdb interface the command line looks like this.
New
I have it coded to first copy the appropriate template over top of the filename you specify and then open the file that you specify with vi (vim). If you wish to use a different editor simply change the command line in the script.
Edit the templates in the work/templates directory to add default code to your templates or to add your license text for example.
The script will protect you from overwriting an existing file with your template if you happen to specify an existing file together with the ../New script.
The Remaining Two Scripts
The next two scripts do a lot more than you might expect.GenerateShellcode
The GenerateShellcode outputs the formatted shellcode from the specified object file. This is the obvious part.
What may not be so obvious is that this command also generates the shellcode.c file with the shellcode text embedded into it.
The contents of the shellcode.c file..
The bash script that is doing all this work already has the ability to count the bytes and the nulls it sees so why not embed that into the c source while we are at it?
Additionally, I took the liberty of filling the registers with 0xffffffffffffffff before calling the shellcode to ensure that the shellcode does not take anything for granted. I hate to say it but I have seen a few shellcodes on sites like exploit-db.com that would not execute correctly if tested with this process.
Build
Last but not least, the Build script.
The build script puts it all together. It was the reason for creating all the little scripts, the bits (modular programming, agile programming, etc.) are orchestrated to really provide time saving value.
The build script expects the "nasm" source file as the argument on the command line. The only thing it leaves for you to do is to run the debug command if you desire it.
If you are familiar with the bash command line history, using the up and down arrows etc. using this Build script reduces the commands to cycle through to possibly 3 or 4 while doing incremental testing.
Warning! The GenerateShellcode and the Build script will clobber any shellcode.c file that is in the current directory when you run them. The solution is easy, copy the shellcode.c somewhere else if you wish to make customizations to it that you do not wish to lose.
Work Info
The contents in the work/info directory are fairly self explanatory.ls -c1 info/
dup2
listen
system_codes
bzero
execve
socket
gdbinit
The dup2, listen, bzero, execve, and socket scripts simply run the man command to display the respective information.
The gdbinit script will create a file in your home directory called "~/.gdbinit" and it will set the contents to "set disassembly-flavor intel". This will prevent you from needing to type "set disassembly-flavor intel" every time you run gdb. You only need to run the script once to create the configuration file.
The system_codes script will launch "vi /usr/include/x86_64-linux-gnu/asm/unistd_64.h". This happens to be the file on my system (Kali Linux) that contains the system codes...
Enjoy!
Comments
Post a Comment