Types

One of the most wanted features for the RSoC was the support for 010-like templates. This is still planned, but there have been no recent movement on the topic.

But some of the basic cparse support has been implemented and I think it's time to get in touch with it in order to get ready for the integration with the rest of the analysis engine.

Current cparse is able to handle cpp and C syntax with support for enums, structs and nested structs. There's an ongoing discussion to define how function signatures should be stored in sdb.

Types are managed with the 't' command. By default it loads some basic ones like 'char *', 'unsigned int' or 'long'. The 't' command dumps the core->anal->sdb_types database which contains the following structure:

[0x00000000]> t
unsigned int=type  
unsigned char=type  
unsigned short=type  
int=type  
long=type  
void *=type  
char=type  
char *=type  
const char*=type  
type.unsigned int=i  
type.unsigned char=b  
type.unsigned short=w  
type.int=d  
type.long=x  
type.void *=p  
type.char=x  
type.char *=*z  
type.const char*=*z  

We can load a C include file with the 'to' command:

$ r2 -
[0x00000000]> cat test.h
#define uint32_t unsigned int
#define uint16_t unsigned short
#define uint8_t unsigned char

typedef struct name {  
        char first[40];
        char middle[40];
        char last[40];
} name_t;

typedef struct date {  
        uint8_t day;
        uint8_t month;
        uint16_t year;
} date_t;

typedef struct addr {  
        char street[127];
        char city[40];
        uint32_t zip;
} addr_t;

typedef struct dox {  
        addr_t address;
        name_t name;
        date_t bday;
} dox_t;

Note that the header have been tuned to rename some types to the ones supported by cparse (layer on top of libr_tcc).

[0x00000000]> to test.h

After this command the list of types found in 't' will be longer.

Displaying Types

Types are linked to 'pf' print format command, so the types specify the format char of 'pf' to display or modify it.

Types can be mapped at any address with the 'tl' command, and then using 'tf' it will show the data in there. This is used by the disasm loop to display inline structures.

[0x00000000]> tl addr 0x4000
[0x00000000]> tf 0x4000
struct addr {  
street : 0x00004000 = "Wallaby Way"  
  city : 0x00004000 = "Sydney"
   zip : 0x00004008 = 2000
}

To display the command that is being executed the 't' command accepts a type argument which we may use to get the format string and field names:

[0x00000000]> t addr
pf *z*zi street city zip  

Then we just use the magic of the r2 shell to interpret the command right there at the address we want:

[0x00000000]> .t addr @ 0x804840

Note the dot at the begining will execute every line of the output of the command as an r2 command. The '@' token, splits the line and evaluates the right expression. Then it does a temporal seek at this address runs the command and comes back.

If you want to learn more on Types. See the rest of the commands of 't?'. And if you feel brave don't esitate to checkout the source and send us a patch.

The future is cparse includes conditional structures and full write support for modifying struct fields.

--pancake

We were at PSES!

One of our resident contributor (jvoisin) was at PSES to do a talk in French, entitled Rétro-ingénierie avec radare2 - Parce que l'assembleur, c'est sympathique, aka Reversing with radare2 - Because assembly is sympathetic.

If you're interested in french terms (some of them are funny), you can watch the whole talk on youtube, and download the slides here

Since the audience was non-technical, the first part is a gentle introduction to reverse engineering, and the second one is composed of two (messies) demos of radare2 in action for a WAP54G pwnage, and also a quick and dirty crack for an old game.

Overall, people liked the talk, and we likely gained some new contributors.

Carving bins

Radare was initially developed as a forensic tool. Nowadays most people use it for static code analysis or binary patching, but the framework and the tools still provide functionalities for analyzing disk partitions or filesystems..

In this post I'm going to explain how to use r2 to extract some ELFs files from a raw memory dump or unknown format firmware image.

This kind of search is called 'carving' and there are already several tools that can do this automatically for free.

But this is not the place to talk about them. Let's open an r2 shell!

Searching the needle

$ r2 -n dump.bin

At this point we will get the r2 prompt opening the file without trying to understand its format (-n) at the offset 0. We want to search for ELF files, and the '/' command can do this search and store the results in flags.

[0x00000000]> / \x7fELF
Searching 4 bytes from 0x00000000 to 0x0000002d: 7f 45 4c 46
0x00001340 hit0_0
0x00001744 hit0_1
...

On every match we will get a flag pointing to the begining of the ELF files. We can then dump them all to disk with that oneliner:

[0x00000000]> b 1M
[0x00000000]> wt @@ hit0*

Note that 'wt' will require an argument (filename) if you are not using the latest version from git. This simplifies the process of naming every dumped portion.

We set the blocksize to 1MB because we don't expect to have bigger executables, but you may change this depending on your target.

Once we have dumped every ELF hit we may like to run rabin2 on them to identify the real size of the original executable by analyzing the file heaers. You can do this with rabin2 -Z

$ for a in dump.* ; do
sz=`rabin2 -Z $a`     # get RBin.filesize
r2 -wnqc"r $sz" $a  # resize file
done

This shellscript loop will truncate all the dumped files to the file size reported by RBin.

Looking for some magic

Another way for carving for known filetypes on memory is by using the libmagic functionality, while we ship a slightly modified code from OpenBSD.

The magic database has been shrinked to just contain the most common filetypes (to speedup search), but you may write or change that magic database to do your own searches and display some header information on every hit.

/m [magicfile]

The Yara plugin is also distributed with r2. It can be used as a replacement for libmagic and it's already being used for detecting file signatures to determine compiler types, shellcodes, protections and more.

Install latest yara and run :yara scan in your r2 shell.

Final words

As long as the IO layer is pluggable, r2 is able to perform those search&dump operations on process memory when attaching the debugger, raw hard disk image, remote files (rap, gdb..), and much more.