Converting IDA DB to VxWorks .sym

Interrupt Labs is often asked to undertake dynamic analysis of stripped closed-source binaries. Even after recovering a lot of information through static analysis (often with IDA), the lack of symbols makes dynamic analysis challenging (using IDA’s debugging features isn’t always possible). In one particular case, we were presented with a stripped VxWorks image and managed to recover many symbols statically but were unable to use them to debug outside of IDA. I was aware that GDB could load symbols from .sym files and wondered if it was possible to extract the information from an IDA Database (.idb or .i64) into a .sym file. This post details my journey into the internals of these two file formats and will cover:

• What a .sym file is.
• What information needed to create a .sym file.
• What challenges arise in extracting that information from an IDA Database.
• What challenges arise in creating a .sym file with the extracted information.
• How the resultant .sym file was tested.
• A detailed appendix with information about the IDA Database format.

The tool created as a result of this research is available here

What's a .sym?

My first challenge was working out what a VxWorks .sym file is. I wasn’t provided with any examples and could find no decisive documentation. After some searching I discovered the following from the “VxWorks Kernel Programmer Guide 6.2”:

• A vxWorks.sym file is created during image building if INCLUDE_STANDALONE_SYM_TBL is not set (otherwise the symbols are bundled with the image).
• objcopy somehow has the ability to create .sym files.

With this knowledge, I began searching GitHub and eventually found a repository with VxWorks build tools. This enabled me to find the link between
INCLUDE_STANDALONE_SYM_TBL and objcopy:

ifneq   ($(findstring INCLUDE_NET_SYM_TBL, $(COMPONENTS)),)
define MAKE_SYM
	$(BINXSYM) $@ $@.sym
endef
define MAKE_SYM_CVT
	$(LDOUT_SYMS) $@.sym
endef
endif

BINXSYM		= $(ENV_BIN)$(

EXTRACT_SYM_FLAG= --extract-symbol

Here is the relevant section from objcopy‘s man page:

--extract-symbol
    Keep the file's section flags and symbols but remove all section data.
    Specifically, the option: 
    *<removes the contents of all sections;>
    *<sets the size of every section to zero; and >
    *<sets the file's start address to zero.>
    This option is used to build a  .sym file for a VxWorks kernel.

This suggested that a .sym file was really just an ELF file with the non-debugging stuff removed. Now I just needed to find some examples for confirmation and reference.

I set out searching GitHub again and eventually wrote a Python script to download all files named vxworks.sym.

After deduplication, I ended up with 64 examples. Here is the readelf -S output for one of them:

  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             PROGBITS        00000000 0000c0 000000 00  AX  0   0 64
  [ 2] .wrs_build_vars   PROGBITS        00000000 0000c0 000000 00  WA  0   0  1
  [ 3] .sdata2           PROGBITS        00000000 0000c0 000000 00  AX  0   0  8
  [ 4] .data             PROGBITS        00000000 0000c0 000000 00  WA  0   0  8
  [ 5] .tls_data         PROGBITS        00000000 0000c0 000000 00  WA  0   0  1
  [ 6] .tls_vars         PROGBITS        00000000 0000c0 000000 00  WA  0   0  1
  [ 7] .sdata            PROGBITS        00000000 0000c0 000000 00  WA  0   0  8
  [ 8] .sbss             NOBITS          00000000 0000c0 000000 00  WA  0   0  8
  [ 9] .bss              NOBITS          00000000 0000c0 000000 00  WA  0   0 16
  [10] .boot             PROGBITS        00000000 0000c0 000000 00      0   0  1
  [11] .reset            PROGBITS        00000000 0000c0 000000 00      0   0  1
  [12] .debug_frame      PROGBITS        00000000 0000c0 000000 00      0   0  1
  [13] .PPC.EMB.apuinfo  PROGBITS        00000000 0000c0 000000 00      0   0  1
  [14] .shstrtab         STRTAB          00000000 0000c0 000090 00      0   0  1
  [15] .symtab           SYMTAB          00000000 0003f8 01e460 10     16 3271  4
  [16] .strtab           STRTAB          00000000 01e858 01fa38 00      0   0  1

• .shstrtab – Contains strings for section names.
• .symtab – Contains the symbol table.
• .strtab – Contains strings for symbol names.

My next task was working out what I needed to extract from the IDA Database file to create the .sym file. Luckily the ELF format is very well documented. Every symbol should have:

• A name (stored in .strtab).
• A value (address).
• A type (either STT_OBJECT for a variable or STT_FUNC for a function).
• A section reference (an index into the ELF’s section header table).

This meant that I needed to extract section information to create the section header table, along with function and variable information for the symbols themselves.

• NAM – Contains the addresses of names. Has a simple array structure.
• ID0 – Contains almost all other useful information. Has a complex B-tree structure.

Whilst parsing NAM was simple, parsing ID0 required many steps:

.sym Creation

The final problem was the creation of the .sym file. Building a program to read and write ELF files was fairly easy thanks to extensive documentation and copious examples. The challenge came from the difference between IDA section metadata and ELF section metadata.

• For flags:
• Start with any that can be inferred from the section name.
• Add SHF_ALLOC if the section name is not recognised.
• Add SHF_WRITE if the section’s write flag is set (or it has no flags set).
• Add SHF_EXECINSTR if the section’s execute flag is set (or it has no flags set).
• For type:
• If it can be inferred from the section name, use that.
• Otherwise use SHF_PROGBITS.

#include <stdio.h>
int number = 0;
void or() {
    number |= 1;
    printf("Number: %d\n", number);
}
void shift() {
    number <<= 1;
    printf("Number: %d\n", number);
}
int main() {
    or();
    shift();
    return 0;
}

gcc test.c -no-pie -s -o test

Next, I had an IDA Database created for the program with the global variable number and function or labelled. I then used the tool to convert the database to a .sym file:

python -m sc -i test.i64 -s test.sym -e little --type EXEC --machine X86_64

(gdb) symbol-file test.sym 
Reading symbols from test.sym...
(No debugging symbols found in test.sym)
(gdb) b or
Breakpoint 1 at 0x401136
(gdb) r
Starting program: /mnt/hgfs/symbols-converter/vxworks/test 
Breakpoint 1, 0x0000000000401136 in ?? ()
(gdb) p (int) number
$1 = 0
(gdb) si 10
0x000000000040115f in ?? ()
(gdb) p (int) number
$2 = 1

Which shows that the .sym file can be loaded and allows debugging as expected.

• An option to include automatic (sub_) function names.
• An option to input from a Ghidra XML export rather than an IDA Database.
• An option to export to JSON or text rather than a .sym file.

This appendix will talk about the structure of an IDA Database (.idb or .i64 file. IDA databases can contain up to six sections:

• ID0 – Contains most useful information.
• ID1 – Contains flags for each byte in the binary.
• NAM – Contains addresses of names.
• SEG – Unknown.
• TIL – Contains information about data types.
• ID2 – Unknown.

Only ID0 and NAM will be covered here.

ID0

page_size - 0x1c bytes of padding follow the header.

The contents of ID0 are laid out as a B-tree. A B-tree is similar to a binary search tree except that each page (collection of records) may have more than two children. Each record has a key (shown in the diagram below) and a value.

After this, there is a count length array of record meta structures.

N<string_node_id>

<node_idd>N

node_id is big-endian with a size matching file’s word size (see Header). The record’s value gives the name.

.<node_id>N

Both node_idand index are big-endian with sizes matching the file’s word size.

• Up to two bytes (T):
• If the first byte begins with 0b11, the value is stored in the following two bytes.
• Else if the first byte begins with 0b1, the value is stored in the remainder of the first byte and the following byte.
• Else the value is stored in the first byte.
• Up four bytes (U):
• If the first byte begins with 0b111, the value is stored in the following four bytes.
• Else if the first byte begins with 0b11, the value is stored in the remainder of the first byte and the following four bytes.
• Else if the first byte begins with 0b1, the value is stored in the remainder of the first byte and the following byte.
• Else the value is stored in the first byte.
• Up to eight bytes (V) – Stored as two consecutive Us. The firstU is the lower four bytes, and the second is the upper four bytes.
• Up to word size (W) – U if the word size if the file’s word size is 32-bits and V if it is 64-bits.

Segment information is found in the $ funcs net node. Every record with the tag S has the format:

The $ segstrings net node has a record with tag S at index 0. This is an array of:

<string_length><string>

Function information is found in the $ funcs net node. Every record with the tag S begins with:

NAM

If the file’s word size is 32-bits then 0x1fe4 bytes of padding follow the header and if it is 64-bits then 0x1fe0 bytes of padding follow it.

A name_count array of integers matching the file’s word size. To resolve the integers to strings see Name.