1

I've followed the tutorial found at: http://www.devttys0.com/2011/05/reverse-engineering-firmware-linksys-wag120n/

I've loaded the uboot image into IDA, but I'm not sure how to determine the load address. I've looked through start.S for a general idea of how things work, but was unable to apply that when looking at the image.

I found another tutorial describing how to determine the load address (https://sviehb.wordpress.com/2011/09/09/reverse-engineering-an-obfuscated-firmware-image-e02-analysis/) but could not find the corresponding memory address of the .bss initialization loop in the uboot image.

Any help would be greatly appreciated! If you have any tips on determining the load address that would be awesome too.

Thanks

4

Download link: WAG120N Downloads

Firmware binary:

$ md5sum WAG120N-EU-ANNEXB-ETSI-1.00.19-code.bin
52d6fa830e31ff96289f8aa41ac713af  WAG120N-EU-ANNEXB-ETSI-1.00.19-code.bin

Version: Annex B - Version: 1.00.19 (ETSI) Latest Date: 11/17/2014

Signature scan output:

$ binwalk WAG120N-EU-ANNEXB-ETSI-1.00.19-code.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
9660          0x25BC          U-Boot version string, "U-Boot 1.1.5-2.0 (Jul 22 2009 - 14:05:28)"
9708          0x25EC          CRC32 polynomial table, big endian
11012         0x2B04          uImage header, header size: 64 bytes, header CRC: 0xF5170888, created: 2009-07-22 06:05:29, image size: 47540 bytes, Data Address: 0x80400000, Entry Point: 0x80400000, data CRC: 0x84EF8694, OS: Linux, CPU: MIPS, image type: Firmware Image, compression type: lzma, image name: "u-boot image"
11076         0x2B44          LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 147212 bytes
65434         0xFF9A          Sercomm firmware signature, version control: 1, download control: 256, hardware ID: "YQZ", hardware version: 0x0, firmware version: 0x9, starting code segment: 0x100, code size: 0x7300
65497         0xFFD9          Sercomm firmware signature, version control: 0, download control: 0, hardware ID: "", hardware version: 0x0, firmware version: 0x2700, starting code segment: 0x1A9C, code size: 0x3D0
72028         0x1195C         Sercomm firmware signature, version control: 29184, download control: 24933, hardware ID: "d ok..!!", hardware version: 0x7266, firmware version: 0x2578, starting code segment: 0xA78, code size: 0x0
196608        0x30000         uImage header, header size: 64 bytes, header CRC: 0xED45C533, created: 2014-11-04 09:41:33, image size: 577083 bytes, Data Address: 0x80002000, Entry Point: 0x801B2040, data CRC: 0x5AFA7402, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS Linux-2.4.31-Amazon_SE-3.6.]"
196672        0x30040         LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 1986560 bytes
851968        0xD0000         Squashfs filesystem, big endian, lzma compression, version 2.1, size: 2991870 bytes, 748 inodes, blocksize: 65536 bytes, created: 2014-11-04 09:42:21

According to the signature scan, the u-boot image is of image type: Firmware Image and data address and entry point is 0x80400000.

How should this information be interpreted? Let us begin with a description of U-Boot image formats: U-Boot Image formats

From include/image.h:

On line 230:

* "Firmware Images" are binary images containing firmware (like
*      U-Boot or FPGA images) which usually will be programmed to
*      flash memory.

The image header:

/*
 * Legacy format image header,
 * all data in network byte order (aka natural aka bigendian).
 */
typedef struct image_header {
    __be32      ih_magic;       /* Image Header Magic Number    */
    __be32      ih_hcrc;        /* Image Header CRC Checksum    */
    __be32      ih_time;        /* Image Creation Timestamp     */
    __be32      ih_size;        /* Image Data Size              */
    __be32      ih_load;        /* Data  Load  Address          */
    __be32      ih_ep;          /* Entry Point Address          */
    __be32      ih_dcrc;        /* Image Data CRC Checksum      */
    uint8_t     ih_os;          /* Operating System             */
    uint8_t     ih_arch;        /* CPU architecture             */
    uint8_t     ih_type;        /* Image Type                   */
    uint8_t     ih_comp;        /* Compression Type             */
    uint8_t     ih_name[IH_NMLEN];  /* Image Name               */
} image_header_t;

Image info:

typedef struct image_info {
    ulong       start, end;             /* start/end of blob */
    ulong       image_start, image_len; /* start of image within blob, len of image */
    ulong       load;                   /* load addr for the image */
    uint8_t     comp, type, os;         /* compression, type of image, os type */
    uint8_t     arch;                   /* CPU architecture */
} image_info_t;

Information about the load address is stored in the uImage header and this is what is output in a signature scan by binwalk. In this case it is 0x8040000.

see also:

Reverse Engineering MIPS Bootloader

MIPS Address Space

Reverse Engineering VxWorks Firmware: WRT54Gv8

Unpacking and repacking U-Boot uImage files

A Handy U-Boot Trick

MIPS Bootstrapping

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.