My Debugging Manifesto for Systems

It is not a secret that writing low level systems is difficult. Especially, when you build a huge system yourself (and no one else can help you) and you end up in memory corruptions or (my personal favorite) experience undefined behavior.

I wrote this small guide in order to come back later in the future when I lose hope again (aka when I cannot locate the bug in my code for days). It is really enjoyable writing Assembly, C and C++ but bug hunting becomes sometimes a pain in the ass (usually when your deadline is near). The best system developers that I know are really good at debugging and testing their code. I usually call these people “bug” bounty hunters.

So, what the “future Alex” should do when he “bug” hunts?

  1. Put effort in building a detailed logger aka log everything and when I say everything, I mean everything
  2. Clean and simplify my code as much as possible. Simplicity is the ultimate sophistication
  3. Modularize my code. Doing that would help me to isolate the bug and easier reproduce the scenario that “triggered” the bug
  4. Enable several compiler warnings
  5. Use available analysis tools such as Valgrind
  6. Nothing works … I should use gdb and pray!!!
  7. Patience is a virtue

Enjoy!!! 🙂

Posted in Uncategorized | Leave a comment

Hacking: The Art of Exploitation, 2nd Edition — Mini-Review

This book is a perfect introductory in software security for three reasons. One is the fact that it gives an amazing hands-on experience. You learn some basic staff … then you learn some complex techniques based on the fundamentals and finally you are “breaking” things. The second reason that this book is unique is that it extensively uses GDB in order to resolve any questions of the reader. The third and the most important reason is that this book does not try to make you a novice hacker. It tries to give you all the prerequisites in order to build a solid security background. There are many books and sources out there that only care about the result (the actual hacking) and not about the acquired knowledge.

So if you want to get your hands dirty, this is the book for you.
Enjoy!!! 🙂

Posted in Books | Tagged | Leave a comment

To mmap or not mmap?

Mmap is a frequently used system call. Many people use it due to its performance gains. Personally, I prefer to use it mostly because of its simplicity (come on manipulating an array is easier than using read/write low level I/O). However, is it really so robust? Let’s first understand what mmap does? It creates a mapping between a resource and the virtual memory of a process and it returns a pointer to that memory. Consequently, we can use pointer and array arithmetic to read/write that resource. However, this mapping doesn’t come from nowhere … so every mmap takes some additional time to “establish” the mapping. Furthermore, because we now have a mapping between the resource and the virtual memory, kernel can make a bunch of things like caching, prefetching (many decades of research in the field of memory management). These effects will be very clear when we have random writes/reads and especially when some records/blocks/pages are accessed more frequently. On the other hand this mapping effect needs some time to be established. Therefore, the advantages of mmap over read/write in sequential accesses of small files are doubtful. There is a great Linus’ article about this issue.

🙂

P.S. If you are not sure about what to use just make two wrappers one over low level read/write I/O and one over mmap. Let’s call them my_read1 and my_read2 and assume both have the same function signature (except their name of course). At some interval you can benchmark your app using my_read1 and my_read2  and choose the best one. In order not to fill your code with unnecessary if’s hold a function pointer array of your I/O functions and each time the benchmark is completed just update a global integer function_number to the index associated with the “best” function.

P.S.2 Of course only making a suitable I/O benchmark may be the big deal!!!!

Posted in CS | Tagged | Leave a comment

Life saver tools

I just wanted to share two things that really make my life easier. When you want to do some system staff, you need to install some dev packages and look in their header files (for declarations mostly), locate missing .h files etc…. Ok, of course there is whereis command and google search (which are both the first thing that I wanted to mention) but I really desire something more sophisticated. For example when I want to take a look at tcmalloc.h (google’s malloc header), I want something to tell me which package has tcmalloc.h or where tcmalloc.h is located in my system (if I have already installed the required package):

apt-file search tcmalloc.h
libgoogle-perftools-dev: /usr/include/google/tcmalloc.h
libgoogle-perftools-dev: /usr/include/gperftools/tcmalloc.h
libgoogle-perftools-dev: /usr/share/doc/libgoogle-perftools-dev/tcmalloc.html
.

You can simply install it with sudo apt-get install apt-file 🙂

P.S. apt-file search works both with installed and not installed packages. Don’t forget to apt-file update before doing the search!!!!

Enjoy….. 🙂

Posted in CS | Tagged , | Leave a comment

Calloc VS Malloc+Memset

These days, I needed to create a dynamic array and initialize all its elements to 0. I usually use one of the two most common ways, malloc+memset or calloc. Today, I just wondered if there is any performance penalty of using calloc (which I find a bit easier), or if malloc+memset is slower or if both techniques have around the same performance. I google it a bit and I found many interesting articles (as usual in stackoverflow :)). Here, I will present an example benchmark and the explanation provided for the results.

calloc:

#include <stdlib.h>
#define BLOCK_SIZE 1024*1024*256
int main(void)
{
        int i=0;
        char *buf[10];
        while(i<10)
        {
                buf[i] = calloc(1,BLOCK_SIZE);
                i++;
        }

        return 0;
}

Output of calloc Benchmark:

time ./a.out  
real 0m0.079s                                                             
user 0m0.023s
sys 0m0.056s
 

malloc+memset:

#include <stdlib.h>
#include <string.h>
#define BLOCK_SIZE 1024*1024*256
int main(void)
{
        int i=0;
        char *buf[10];
        while(i<10)
        {
                buf[i] = malloc(BLOCK_SIZE);
                memset(buf[i],0,BLOCK_SIZE);
                i++;
        }

        return 0;
}

Output of malloc + memset benchmark:

time ./a.out  
real 0m0.741s
user 0m0.201s
sys 0m0.530s

Hm, I was really suprised by these results. Consequently, I looked for a proper explanation and I think I found one. There is some ‘kernel magic’ in the way. When you try to (c)allocate a large enough region of memory (like in our benchmark), it takes a lot of time in order to zero all this memory and here comes the kernel to cheat :). There is a page of memory already zeroed set aside. All pages in the new allocation point at this one page of physical ram, which is shared among all processes on the system, so it doesn’t actually use any memory.

The “memset” implementation touches every page in the allocation, resulting in much higher memory usage — it forces the kernel to allocate those pages now, instead of waiting until you actually use them.

The “calloc” implementation just changes a few page tables, consumes very little actual memory, writes to very little memory, and returns.

P.S. If the results are different in your machine, just see the implementation details of calloc, malloc and memset. There is an issue of ‘poor’ calloc implementations in some compilers, if I am correct.

Sources:

http://stackoverflow.com/questions/2605476/calloc-v-s-malloc-and-time-efficiency http://stackoverflow.com/questions/2688466/why-mallocmemset-is-slower-than-calloc http://stackoverflow.com/questions/19813072/calloc-slower-than-malloc-memset http://stackoverflow.com/questions/4316696/difference-in-uses-between-malloc-and-calloc/4319790#4319790

Posted in CS | Tagged | Leave a comment

Great power comes with great responsibility …. the strtok() case.

I came across some friend’s code and I saw some strange results. He used strtok() a lot. I would really like to explain all the problems I found in his code and my solutions but I will just provide three links … (too much work today 🙂 ).

https://www.securecoding.cert.org/confluence/display/cplusplus/STR06-CPP.+Do+not+assume+that+strtok()+leaves+the+parse+string+unchanged http://en.wikipedia.org/wiki/Reentrancy_(computing) http://stackoverflow.com/questions/22210546/whats-the-difference-between-strtok-and-strtok-r-in-c

Enjoy guys!!!

P.S. https://www.securecoding.cert.org/ rocks \m/

Posted in CS | Tagged | Leave a comment

Qemu + Debian “Squeeze” for PowerPC

You may want a Big-endian machine and it may not be easy to find one.
That’s a very good opportunity to try Qemu + Debian port for PowerPC. When I tried it, it took me some time to configure everything. Consequently, I decided to make a blog post about it.

First of all we need to download QEMU and openbios-ppc…

sudo apt-get install qemu
sudo apt-get install openbios-ppc

Secondly you can download Debian port for PowerPC from the Debian website. I downloaded Debian “Squeeze” for PowerPC (debian_squeeze_powerpc_standard.qcow2 in my case).

Warning: Under at least Ubuntu 14.04 openbios-ppc doesn’t seem to work well. If you get a blank yellow screen after you start the install you will need to get openbios from other places e.g. https://github.com/qemu/qemu/tree/master/pc-bios (I just replaced openbios-ppc executable at the following location /usr/share/openbios/ in my computer).

Then you can just run the following and everything should be ok…

qemu-system-ppc -hda debian_squeeze_powerpc_standard.qcow2

– Root password: root
– User account: user
– User password: user

2014-06-24-001257_1366x768_scrot

References:
http://people.debian.org/~aurel32/qemu/powerpc/                                       http://blog.vuksan.com/2014/02/                                               https://github.com/qemu/qemu/blob/master/pc-bios/openbios-ppc http://forum.ubuntuusers.de/topic/problem-mit-qemu/#post-2299080

Posted in CS | Tagged , , , | 1 Comment

How to check if a system is Big-endian or Little-endian

There are many ways to determine if your system is Big-endian or Little-endian especially in newer Linux Kernels. However, I was looking for a solution in C that is as portable as possible also in older systems.

The following code solves the problem….

int num = 1;

if(*(char *)&num == 1)
{
    printf("\nLittle-Endian\n");
}
else
{
    printf("Big-Endian\n");
}

Someone may think that it could be a bit easier like a simple char cast…

int num = 1;

if((char )num == 1)
{
    printf("\nLittle-Endian\n");
}
else
{
    printf("Big-Endian\n");
}

However that’s completely wrong. Since you’re casting from a larger integer type to a smaller one, it takes the least significant byte regardless of endianness (or at least that is what happens to the systems that I tried it). If you were casting pointers instead (as in the first snippet of code), though, it would take the byte at the address, which would depend on endianness.

You probably have a Little-endian CPU. In order to check both snippets of code you can use an emulator like QEMU (I will describe how to do it in a future post).

P.S. Of course, everything I wrote may be wrong in some C implementations 🙂

References: (I prefer not looking for official references when I have already tested something… After all it is my blog)
http://stackoverflow.com/questions/7504277/int-to-char-casting http://stackoverflow.com/questions/8571089/how-can-i-find-endian-ness-of-my-pc-programmatically-using-c

Posted in CS | Tagged , , , | Leave a comment

TCP URG Flag

My first blog post guys 🙂 !!!!

These days I accidentally came over the TCP flags again. There are exceptional articles explaining how they work like this. After reading most of them in detail, some things about the URG flag were not so clear for me. My biggest concern was, how TCP handles previous non-urgent data (remember TCP guarantees packet order). Finally, I found the answer here and here. 

TCP must tell the user to go into “urgent mode”; when the receive sequence number catches up to the urgent pointer, the TCP must tell user to go into “normal mode” [RFC0793]. This means, for example, that data that was received as “normal data” might become “urgent data” if an urgent indication is received in some successive TCP segment before that data is consumed by the TCP user.

Consequently, packet-order is preserved by converting normal data, that came before and haven’t been consumed yet by the receiver application, to urgent. 

To conclude, I found a very good small explanation of URG and PSH flags here.

URG flag

If the urgent flag is set, it indicates that the urgent pointer is valid and points to urgent data. Simple enough, eh? Urgent data is data that should be acted upon as soon as possible, even before “normal” data that may be waiting should be processed.

PSH flag

The push flag tells the receiving end of the tcp connection to “push” all buffered data to the receiving application. It basically says “done for now”.

P.S. For more things about URG flag see this.

Posted in CS | Tagged , , , , | Leave a comment