SQL Injection back in 2006

Many years ago a friend of mine came around with an idea, not new even back on those days, but fun anyways.

The idea was to automate SQL Injection attacks by using search engines to find vulnerable targets.

Integrated with a tiny Delphi malware (yes, Delphi 0_o) it has became powerful.

This code lays in a separate part of my heart (yes, I do have a heart) not because it was 31337 (it wasn’t!) or extremely advanced but only because it was fun to write.

I did not run the code in the wild, not even once, truly. I wrote it with the help of other people testing it at the same time I was writing it down, back on 2006 when internet was a savage place with practically no rules. Nowadays things has changed a lot and everything you do is either illegal or shameful, so I do nothing else like this anymore.

This code is outdated and no longer work so it is not of much use, even less because the Deplhi malware is not included but I would like to share Volatile myself because other people already did this so it is my right, right?.

I believe I’ll sleep well and apart from that, this software is already out there on the internet since 2006 and it was used even  for teaching computer security in few Universities.

It has basically three steps to accomplish complete control over remote computers running ASP + Windows:

– Find possible vulnerable targets using web search engine by applying an specific SQL command and testing its return, if it was an error then:

+ Perform cmd_shell command, pinging origin IP, Volatile would then start an ICMP sniffer to see if ICMP packets would arrive from remote target, if so;

– Execute a new cmd_shell command downloading and executing the malware from a different remote host. Such malware would take control over the box and then send a screenshot and star to listen an specific port (backdoor) , waiting for connections.

– It would keep running through hundreds of possible vulnerable machines , creating a list of compromised hosts.

Fun enough, but nowadays pretty illegal and I do not recommend anyone to do anything similar to this in the times we live, so it is a fossil , only, for posterity (myself) appreciation.

Here is the code: https://gist.github.com/carloslack/9f6348606c4447b89830


Hidden pids

After few years I’ve found myself looking for a code I wrote after suspecting that my system had a weird behave while using chorme browser then I thought that I could take a deeper look at the running PID’s to see if there was anything suspicious.

Sometime ago, in ancient days, I was a fanatic Slackware user (I am not anymore) and the system/kernel/applications those times hadn’t the annoying approach of hiding some of its PID’s , it was rootkits approach only. Time has changed since then.

When you perform a simple “ps -ax” in your Linux system nowadays lots of running processes are hidden from userland tools like ps. Actually I don’t know exactly why but anyways the following code may help you to locate those PID’s in your system.


Compile: gcc -c psearch.c


./a.out |while read line ; do echo -n "$line: " ; cat /proc/$line/cmdline ; echo ; done 2>/dev/null

It is possible to list then because they are hidden only from sys_getdents* (If my memory is not failing) but once you know their numbers (PID’s) you can chadir() into.

NULL pointer dereference bug for dummies

Has been a while since this class of bug has emerged as a potential Linux kernel (and others) vulnerability. Actually it is still out there but since Brad Spengler (spender), of grsecurity, made public  a pretty cool exploit gaining local root, the guys from the Linux kernel paid attention and rushed out to provide a workaround fix in the kernel. Since then exploiting such vulnerability has become harder and harder.

Well, this is just a short story and the reader can Google around for it and learn more, it is pretty interesting, the whole story. Perhaps the best place to learn more about it is here.

Now let’s forget about Linux kernel current protections details and keep in mind only that there is a special proc file:


The above file keeps a virtual memory address value, such value means that regular users are not able to write below the address, for example 4K, the first page which is 4096. Most systems have 4GiB of total virtual memory, 1GB for kernel only, privileged mode, and 3GB for user processes. High memory > 3Gib belongs to kernel and memory < 3Gib to users. The kernel, of course, can access the whole 4Gib.

NULL (void*)0 and 0 are not the same thing, but for practical purposes they are, because both point to address 0x00 in the virtual memory.

Long story made short tells that if the user can mmap()  an address range beginning at 0x00 (NULL) and then inside of kernel a sad programmer deference a pointer, before making sure it is valid or in other words, not NULL, then if virtual memory starting at 0x00 was previously mapped by the malicious user, things will get wild.

mmap() is usually used for mapping files in memory, but it is possible to map any kind of data, for example a shellcode or a local address (function) written inside of an exploit executable file, executing code in privileged mode.

Now, I wrote this whole text just to give an introduction for a simple piece of code that may exemplify the concept without having to delegate to a real kernel bug, making it simpler and userland only.

In the code there is a local funcion named exec() and a bytecode, which is an asm code like the one following:

$ cat addr.s
xor %eax , %eax # %eax := 0
call 0x000000000040062c # exec addr

Line #3 is the address of my exec() function, in my ARCH Linux 64 bits, which may be different in your system. I got it from objdump:

$ objdump -d a.out |grep exec| awk '{print $1}' |head -1

Then it was easy to write the following bytecode:

char loadexec[] = "\x31\xc0" // xor %eax, %eax

"\xe8\x25\x06\x40\x00" // call 0x80484b4 # exec()

"\xc3"; // ret

Now can “see” a NULL pointer dereference bug in action without having to mess around with the kernel.

To run the code you have either to write zero to /proc/sys/vm/mmap_min_addr, as ROOT:

# echo "0" > /proc/sys/vm/mmap_min_addr

or run the executable as root.

The output, if it works, would be like the following:

$ sudo ./a.out
+memcpy has successfully failed 🙂
+fp is NULL but it is supposed to execute data, let's try to call 0x40062c...
*** Yeah, it works ***

If you see “*** Yeah, it works ***” it is obvious.

The code is reasonably documented so I think the reader will get it.


Chained hash tables

People not much used with data structures does not know about the use of chaining when applying hash tables.

There are few types of hash tables out there and most of then does not implement dynamic size adjustment , for those types of hash tables a special technique can be put on the “table”.

Denominated by Chained Hash Tables, are very simple and useful. Consisting in the mix use of hash tables and single/double linked lists.

The theory is quite simple as well, when you run out of table entries you can fall down into a merged linked list, allowing the same key to have multiple entries in the hash table.

Hash tables are well known for fast access, can be very straightforward:

data = table[key]->data;

But because of its stack nature ( datatype table[CONSTANT_VALUE] ) hash table is “limited” (it can be adjusted in run-time but it is not our scope now) in size. So if someone makes use of linked lists it will be virtually unlimited (OK, let`s forget for an instant about RAM and virtual memory limitations) and will often be accessed immediately because in some cases hash collisions and/or same key usage will be much less frequent, reducing access time.

The hash key algorithm I use was written by Bernstein, there are many algorithms out there but this one is quite reasonable.
Below you can find an example code I wrote of hash chaining implementation. I took out other helper functions like delete() entries or find() specific entries because the reader will figure it out easily:


pthread: exiting from thread

Hi!  Programmers used with Posix threads (http://en.wikipedia.org/wiki/Pthread) mechanisms know pretty well about its auxiliary functions, pthread_cancel(), pthread_kill() and so on so one can make a thread that to perform some work inside of a loop to exit and release its resources, not a big deal.

However there is a dirty hack technique which may consist in the approaching explained below.

You make use of pthread_exit() in order to do it.

First create a function pointer to pthread_exit(), this way:

static void(*pexit)(void *) = NULL;

Then you’ll have your thread running in loop doing something and at some point you need to terminate the thread, but first a snip code of our thread:

void *our_thread(void *args) {


while(!pexit) {

//do something





Now somewhere else you just need to set pexit pointer:

pexit = pthread_exit;

Then your thread will terminate as expected.