Segmentation fault when trying to execute recovered filesystem in a digital video tuner

Let me introduce where this thing comes from. A few years ago I got a digital video tuner, which had a closed source version of Linux. The manufacturers of this device didn't want to share the source code of the OS, neither I was able to find it on internet. The SoC is a Celestial/Cavium CSM1800. Doing some dubious things, I accidentally executed the update procedure and wiped the NAND flash. Luckily, I had dumped the contents of the mtd partitions (there are 2 mapped to this NAND flash, Kernel 3M and the rest is a JFFS2 partition). This board has U-Boot loaded on another memory (a 1MB SPI), so "it wasn't totally bricked" because of the NAND wipe.

Back to the thing. I had a corrupt (dunno how it got corrupted) dump of the kernel, but after a lot of tinkering, I extracted the vmlinux (i.e. not gzip compressed) from the zImage. It seems the gzip unpack algorithm was bad, really weird.

After creating a new uImage using the vmlinux previously unpacked, I used the "fatload" command to load it and the thing booted, but of course it couldn't find the JFFS2 partition.

Then I tried writing the raw dump of the JFFS2 which I got from /dev/mtdblockX into the NAND, in the originally specified partition (after the 3M of the original kernel). After booting, the kernel spit out a lot of errors concerning bad magics, empty flash, etc.

Well, after this I tried unpacking the JFFS2 in a Mint Virtual Machine, and I could extract the files. Since this tuner has an USB, I formatted a usb stick in ext2 and copied the files from the unpacked JFFS2 filesystem. After crafting some bootargs to run from the usb stick instead of the NAND, I got the typical "Kernel panic - not syncing: Attempted to kill init!".

I quickly tried to specify the sh command in init via the bootargs. Same thing. So I downloaded a static linked binary version of busybox. I copied it to the /bin/ (where the original one resided), marked as executable, and tried again. This time, I got a shell!

The thing is, when I try to run ANY of the original applications, I got a "Segmentation fault" and nothing else. Besides this, the /proc is not filled with anything, and I really don't have a clue why! Other files, like text files or plain text files were OK, but im not discarding the possibility of a corrupted dump.

Finally, I tried to chroot to the unpacked JFFS2 in the Mint VM. Same "Segmentation fault" errors, but at least a core dump is created. I tried gdb-multiarch in that core dump, but only 2 frames appear, and since there are no symbols, nothing useful is shown there. (In fact, only the 2 frames addresses are only shown).

Some usefull (or not?) things: binwalk of the vmlinux image

104288 0x19760 ASCII cpio archive (SVR4 with no CRC), file name: "/dev", file name length: "0x00000005", file size: "0x00000000"

104404 0x197D4 ASCII cpio archive (SVR4 with no CRC), file name: "/dev/console", file name length: "0x0000000D", file size: "0x00000000"

104528 0x19850 ASCII cpio archive (SVR4 with no CRC), file name: "/root", file name length: "0x00000006", file size: "0x00000000"

104644 0x198C4 ASCII cpio archive (SVR4 with no CRC), file name: "TRAILER!!!", file name length: "0x0000000B", file size: "0x00000000"

1856733 0x1C54DD Certificate in DER format (x509 v3), header length: 4, sequence length: 1284

1856853 0x1C5555 Certificate in DER format (x509 v3), header length: 4, sequence length: 1288

2597693 0x27A33D Certificate in DER format (x509 v3), header length: 4, sequence length: 1292

2597797 0x27A3A5 Certificate in DER format (x509 v3), header length: 4, sequence length: 1292

2598317 0x27A5AD Certificate in DER format (x509 v3), header length: 4, sequence length: 5380

2598397 0x27A5FD Certificate in DER format (x509 v3), header length: 4, sequence length: 5380

3292029 0x323B7D Certificate in DER format (x509 v3), header length: 4, sequence length: 1292

3292033 0x323B81 Certificate in DER format (x509 v3), header length: 4, sequence length: 1304

3292037 0x323B85 Certificate in DER format (x509 v3), header length: 4, sequence length: 1308

3469469 0x34F09D Certificate in DER format (x509 v3), header length: 4, sequence length: 3

3701960 0x387CC8 Linux kernel version "2.6.32.36-SDK-1.1 (ylei@software) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #7 PREEMPT Wed Feb 15 14:12:59 CST 2012"

3705492 0x388A94 gzip compressed data, maximum compression, from Unix, last modified: 2012-01-18 04:15:11

3930268 0x3BF89C CRC32 polynomial table, little endian

4692111 0x47988F Unix path: /S70/S75/505V/F505/F707/F717/P8

readelf output of an executable file (rw_eeprom_byte). It's in spanish, but you could get the idea. http://pastebin.com/H0ZZcAaf (in pastebin so it keeps the spaces and it's more readeable).

uname:

Linux (none) 2.6.32.36-SDK-1.1 #7 PREEMPT Wed Feb 15 14:12:59 CST 2012 armv5tejl GNU/Linux

Original boot (with the original filesystem and kernel): http://pastebin.com/YL2d2HYj

Any hints? Maybe another firmware that has the same SoC where I can extract the filesystem? Thanks! PS1: English is not my native language, so forgive any errors you might see. PS2: I'm not an expert in Linux, and my strong area is programming embedded devices (withouth linux :P).