Skip to content

x86 registers, register conventions and calling conventions

I have started with the course “Introductory Intel x86: Architecture, Assembly, Applications, & Alliteration” by Xeno Kovah and it’s been wonderful so far. It is a repeat of many things I am already aware of but there has been a lot of new things learnt. I might write about parts of what I learnt from the course but not everything. This post is about x86 register, conventions associated with them as well as function call conventions.

x86 registers

There are 9 registers in x86: EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP and EIP. These are mostly derived by prefixing E(Extended) to their 16 bit equivalents.

EAX: The accumulator. This register typically stores return values from functions.

EBX: This register is typically the pointer to the base of an array.

ECX: This is typically used as a counter: loops, iterating through an array etc.

EDX: Commonly used as a supporting register. For example, 64 bit return values are returned in EDX:EAX in the code generated by 32 bit compilers.

ESI: The source index for string operations.

EDI: The destination index for string operations.

EBP: This register points to the base of the current function’s stack frame.

ESP: This register points to the top of the current function’s stack frame.

EIP: This register points to the address of the next instruction. This is the only instruction that cannot be manipulated by any instruction except call and ret.

x86 register conventions

Caller save registers: These registers have to be saved by the caller function if it wants to preserve their values. EAX, ECX and EDX are caller save registers. EAX is usually modified by the callee in almost all cases(it holds the return value remember?)

Callee save register: These registers have to be saved by callee function if it will modify these registers. EBP, EBX, EDI and ESI are callee save registers. EBP is usually modified by the callee in almost all cases(it points to the base of the function’s stack frame remember?)

Calling conventions

There are multiple ways to pass the parameters to the callee function. Here I will discuss 3 such conventions.

1. CDECL convention: C Declaration. In this convention, the parameters are passed in the reverse order(i.e. from right to left) on the stack by the caller and the caller is responsible for cleaning up the parameters from the stack i.e. it is caller clean up. GCC follows this convention. I think even MS Visual Studio does-at least the free Express edition.

2. STDCALL convention: Standard Call. This is exactly same as CDECL except that the callee is responsible for removing the parameters from the stack i.e. it is callee clean up. The Win32 API follows this convention.

3. FASTCALL convention: I have never encountered this convention before but the idea is that some parameters are passed through the registers and rest through the stack. There is no universal standard-each compiler designer has a different implementation of the convention. This is also callee clean up.

Well that’s about it for this post. I’ll probably write more about x86 programming later on.

Advertisements

InCTF 2013 is here!

Amrita University & Amrita Centre for Cyber Security

proudly present

InCTF ’13

National Level “Capture the Flag” style ethical hacking contest

Not a day passes when several machines are compromised and infections spread rampantly in the world today. The cyber world has witnessed several dangerous attacks including the Stuxnet virus and it’s successor Duqu. Other recent attacks include the Flame malware, which managed to disguise itself as a legitimate Windows software. It exploited a bug in Windows to obtain a certificate which allowed itself to authenticate itself as genuine Windows software. Other notable examples include rise of botnets such as the highly resilient Zeus banking trojan and the Conficker worm. There have also been instances of espionage by government agencies on one another such as the recent incident where Georgia CERT discovered a Russian hacker spying on them.

Indian websites offer little or no resistance to such security incidents. The Computer Emergency Response Team, India(Cert-In) has been tracking defacements of Indian websites amongst other security incidents. Their monthly and annual bulletins detail the various vulnerabilities and malware infections in various Indian websites. It’s really sad that with so much talent and skill, Indian websites are compromised frequently and nothing can be done to stand this wave of attacks on them.

InCTF is a Capture the Flag style ethical hacking contest, a strategic war-game designed to mimic the real world security challenges. Software developers in India have little exposure to secure coding practices and the effects of not adopting such practices-one of the main reasons why systems are compromised quite easily these. Following such simple practices can help prevent such incidents.

InCTF ‘13 is from December 2012 to April 2013 and is focused exclusively on the student community. You can participate from your own university and no travel is required. No prior exposure or experience in cyber security needed to participate.

What you need to do?
1. Form a team (minimum three and maximum five members from your college)
2. Approach a faculty/mentor and request him/her to mentor your team
3. Register online at http://portal.inctf.in

Great Rewards

20K The winning team receives a cash prize of up to Rs. 20000/-
15K The first runner-up team receives a cash prize of up to Rs. 15000/-
10K The second runner-up team receives a cash prize of up to Rs. 10000/-

See http://inctf.in/prizes

for more.

Note

  • Teams are awarded prizes based on their performance
  • Deserving teams are well awarded. Exciting prizes to be won.


So, what are you waiting for? It’s simple: Register, Learn, Hack!

Keep up with us

Website|Email|Facebook|Twitter|Mailing List|IRC

*Cash prizes are subject to their performance and participation in the CTF round. Only teams who connect to the VPN server and successfully gain points in the CTF round are eligible for prizes. In addition, cash prize winners of previous editions of InCTF and sCTF are not eligible for prizes this time. Prizes will be awarded only if all members of the team are not in final year of their education. The decision of Team InCTF is final.

Adding hello world system call to Linux

I just finished doing this and so thought I’d write about it in my blog since it took me a while to get this done after many an experimentation I suppose :P. So here goes!

I did this on an Ubuntu 12.04.1 LTS OS running on an 64bit machine but this post should mostly work on any Linux OS(with a few differences here and there).

Read more…

CSAW CTF: Reversing 400

Binary available at http://repo.shell-storm.org/CTF/CSAW-2012/Reversing/400/.

We are given an ELF binary and I wasn’t very sure I could solve this since I have not played with ELF much. It was an easy challenge though-I thought Reversing 300 was slightly more difficult.

On executing, the program prints an encrypted key and instantly, I realize it can be solved by adopting the same approach as reversing 100. Just modify the call to encrypt to call decrypt and you get the key:


Encrypted Key: csawissohard__:(

I won’t get into details as to how I patched it: used a combination of IDA and hexedit to do so(yeah I’ve a long way to go in reversing).

PS: Eindbazen has a much more elegant solution than mine. Visit http://eindbazen.net/2012/09/csaw-2012-reversing-400/ for more.

CSAW CTF: Reversing 300

Binary available at http://repo.shell-storm.org/CTF/CSAW-2012/Reversing/300/.

Yet another .NET binary. Run it and it’s similar to Reversing 200: prints a line, read a line and exits. Decompiling using ILSpy and we get main. It’s too long so I’ll post only relevant bits here.

private static void Main(string[] args)
{
    Console.WriteLine("Do you really just run random binaries given to you in challenges?");
    Console.ReadLine();
    Environment.Exit(0);
    MD5CryptoServiceProvider mD5CryptoServiceProvider = new MD5CryptoServiceProvider();
    AesCryptoServiceProvider aesCryptoServiceProvider = new AesCryptoServiceProvider();
    foreach (string current in Directory.EnumerateDirectories(Program.target))
    {
        byte[] first = mD5CryptoServiceProvider.ComputeHash(Encoding.UTF8.GetBytes(current.Replace(Program.target, "")));
        if (first.SequenceEqual(Program.marker))
        {
            byte[] rgbKey = mD5CryptoServiceProvider.ComputeHash(Encoding.UTF8.GetBytes("sneakyprefix" + current.Replace(Program.target, "")));
            ICryptoTransform cryptoTransform = aesCryptoServiceProvider.CreateDecryptor(rgbKey, new byte[]... //Truncated to save space
            byte[] bytes = cryptoTransform.TransformFinalBlock(Program.data, 0, Program.data.Length);
            Console.Write(Encoding.UTF7.GetString(bytes));
        }
    }
}

The program creates an MD5 object, AES object and start iterating over all directories the target directory C:\Program Files. It computes the MD5 hash of each child directory’s name and then checks if it equals marker. If it equals, then “sneakyprefix” is prefixed to the directory name and used as the key for the encryption that follows.

After playing with marker, I realize that it is an MD5 sum and so I search the online databases of MD5 sums to find that it is the hash of “Intel”. So, the program checks if there is a directory named “Intel” in the target and if so, it proceeds with the decryption. I quickly modify the .NET code, removing references to the target directories and run it in compilify(loved it a lot-my favourite handy .NET compiler) and voila I get the flag

That was pretty easy, wasn't it? \key{6a6c4d43668404041e67f0a6dc0fe243}

CSAW CTF: Reversing 200

Binary available at http://repo.shell-storm.org/CTF/CSAW-2012/Reversing/200/.

We’re given a .NET binary in this challenge. It merely prints a string and exits instantly. Decompiling it using ILSpy and we see the main routine as follows.


private static void Main(string[] args)
{
    Console.WriteLine("Okay, going to compute the key. Have to remember to write it out at the end! I keep forgetting!");
    string arg = "";
    byte[] array = Program.encrypted;
    for (int i = 0; i < array.Length; i++)
    {
        byte b = array[i];
        arg += Convert.ToChar((int)(b ^ 255));
    }
    Console.ReadLine();
}

Simple stuff! I wrote a python script to reverse it.


>>> cipher_text = [171, 151, 154, 223, 148, 154, 134, 223, 150, 140, 223, 198, 156, 207, 198, 153, 199, 203, 206, 201, 158, 205, 205, 207, 201, 205, 205, 206, 154, 202, 207, 157, 198, 199, 154, 204, 203, 201, 207, 203, 200, 157, 200]
 >>> plain_text = ""
 >>> for char in cipher_text:
 ... plain_text += chr(char ^ 255)
 ...
 >>> plain_text
 'The key is 9c09f8416a2206221e50b98e346047b7'

CSAW CTF: Reversing 100

Binary available at http://repo.shell-storm.org/CTF/CSAW-2012/Reversing/100/

We’re given a PE32 executable file. On executing it, it displays some encrypted key. So basically, the program encrypts the key and we(or something else :P) should decrypt it.

Pop it into IDA. On seeing the disassembly of main, we see something interesting:

lea eax, [ebp+var_18]
push eax
call encrypt

The more hardcore(and difficult) way of doing it would be to reverse engineer the encrypt method(it’s easy if you have hexrays probably) but I did something far easier.

I noticed a method decrypt was also defined in the binary which should be able to decrypt it. So, I modified the call above to

call decrypt

with the help of Olly, using the memory location available from IDA and voila! We get the flag “welcome_to_csaw”!