I'm currently trying to make modifications to a router firmware: Swisscom Centro Grande - aka Pirelli Vx226N1, firmware version: 60200.

I've decompiled it successfully with FMK v0.99 and got the header.img, the rootfs.img and the footer.img image parts.

This is the binwalk of rootfs.img:

Squashfs filesystem, little endian, non-standard signature, version 4.0, compression:gzip, size: 2764423 bytes, 1145 inodes, blocksize: 65536 bytes, created: Fri Mar 15 00:33:08 2013

I decompiled the rootfs.img with unsquashfs successfully and got the system folders. I made some changes (enabled a shell on telnet) and tried to repack everything with the tools provided (the ./build-firmware.sh command).

The final firmware size was bigger than the original one. Tried to flash, nothing happened. I analyzed the firmware and especially the upgrade method to learn how to properly build the firmware.

I found the update.sh file which handles the upgrade process (analyzes the file provided by the user and flashes only if everything is correct, in order to prevent brick)

Here is the link to the pastebin of that file

I'm pretty sure that the original firmware files are parsed through the parse_yaps_image() function, so I tried adapting on my own to check the files but I noticed that there was an external check with a binary file called sig_verify

If the files doesn't exists another function is invoked, the problem is that the function provided isn't correct (it return a wrong validation token error even with original firmware!)

My goal is to analyze the sig_verify file and look for the algorithm, in order to understand the composition method and in order to flash my router in the proper way and finally get the root shell (and make modification on everything I want)

I uploaded all files on a Mega folder so the interested guys who want to help me could access any file needed.

I included in the folder 60208 the two scripts I used to check the files.

The result of the script I wrote (it's just the adaptation of the script in the router) is this:

denys@denys-pc:~/Documents/router/Vx226N1/images/modified/60208$ ./check_upgrade_yaps.sh 
Parsing YAPS format...
16+0 records in
16+0 records out
16 bytes (16 B) copied, 0.000843843 s, 19.0 kB/s
Error: wrong validation token (5b445d3b251d59753031c9d7a94ba4ab, 7d98668859855f1b9459256257fc3262)

And here is the binwalk of sig_verify file.

denys@denys-pc:~/Documents/router/Vx226N1/images/modified/60208$ binwalk sig_verify 

0           0x0         ELF 32-bit MSB executable, MIPS, version 1
1921        0x781       LZMA compressed data, properties: 0x01, dictionary size: 16777216 bytes, uncompressed size: 16777472 bytes

As you can notice it's a MIPS executable. I tried to run it under a MIPS environment (virtual machine, qemu-system-mips) without any success.

qemu-system-mips -M mips -kernel ./vmlinux-2.6.18-6-qemu -initrd ./initrd.gz -hda hda.img -append "root=/dev/ram console=ttyS0" -nographic

The kernel and the initrd were downloaded by http://archive.debian.org/debian/dists/etch/main/installer-mips/current/images/qemu/netboot/

Any help would be appreciated. If something isn't clear just let me know :)

  • While your question is on-topic here, you may get better answers on Reverse Engineering. Do not repost; if you think this question would work better on RE.SE, flag your question and ask a moderator to migrate it. Jan 18, 2015 at 19:58
  • Are you sure this is a Linux executable? Have you tried objdump? Is it statically or dynamically linked? Jan 18, 2015 at 20:00
  • The question is suitable to both of the sites, I really don't know which is better for this answer. Anyway, yes, it's a linux executable (it's executed by the upgrade.sh script from the router) and it should be dynamically linked. I haven't tried objdump yet, I'll try it in a few hours and let you know. (If you wanna do file analysis I included the mega folder link in the question, the sig_verify is also there) Jan 19, 2015 at 1:21
  • sig_verify: ELF 32-bit MSB executable, MIPS, MIPS32 version 1, dynamically linked (uses shared libs), corrupted section header size Jan 19, 2015 at 16:04
  • denys@denys-pc:~/Documents/router/Vx226N1/images/modified/60208$ objdump -f sig_verify sig_verify: file format elf32-big architecture: UNKNOWN!, flags 0x00000102: EXEC_P, D_PAGED start address 0x00400a80 Jan 19, 2015 at 16:05

1 Answer 1


First, you mean extracted or unpacked, not decompiled. More to the point, however, what you want is the qemu-user programs, not qemu-system. On Debian GNU/Linux for example, you merely need to install the qemu-user-binfmt package and then you can run tghese binaries like native ones.

The only complication is when these binaries need files in hardcoded locations (for example, uClibc in /lib). An easy way to work around this is to copy the relevant qemu-user (e.g. "qemu-mips") into the same path inside the extracted root directory:

cp /usr/bin/qemu-mips router-root/usr/bin

and then you should be able to chroot inside, using e.g. busybox as a shell:

chroot router-root bin/sh
chroot router-root bin/sig_verify ...

however, if sig_verify uses a good enough algorithm for the signature (e.g. rsa) then chances to sign your own files will be slim.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .