Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 2 3 [4] 5 6 ... 21

Author Topic: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B  (Read 191153 times)

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #45 on: February 03, 2012, 01:09:22 AM »

Bit of an update..

The squashfs root file system of the ECI can be decompressed and extracted, with the exception of just two data blocks of ~20kBytes each. [1]

Code: [Select]
$ sudo ./unsquashfs ecirootfs2
Reading a different endian SQUASHFS filesystem on ecirootfs2
err -22
sqlzma_un: LZMA Unknown error 18446744073709551594
err -22
sqlzma_un: LZMA Unknown error 18446744073709551594

created 612 files
created 83 directories
created 118 symlinks
created 31 devices
created 0 fifos

$

A tarball of the uncompressed file system contents for the ECI, including those two corrupted blocks, can be found at [1].

The extraction requires a one line patch to the read_data_block() function of the unsquashfs tool. The patch is simply to stop it aborting on error:

Code: [Select]
int read_data_block(long long start, unsigned int size, char *block) {
int res;
unsigned long bytes = block_size;
int c_byte = SQUASHFS_COMPRESSED_SIZE_BLOCK(size);

TRACE("read_data_block: block @0x%llx, %d %s bytes\n", start,
              SQUASHFS_COMPRESSED_SIZE_BLOCK(c_byte),
              SQUASHFS_COMPRESSED_BLOCK(c_byte) ? "compressed" : "uncompressed");
if(SQUASHFS_COMPRESSED_BLOCK(size)) {
enum {Src, Dst};
struct sized_buf sbuf[] = {
{.buf = (void *)data, .sz = c_byte},
{.buf = (void *)block, .sz = bytes}
};

if(read_bytes(start, c_byte, data) == FALSE)
return 0;

res = sqlzma_un(&un, sbuf + Src, sbuf + Dst);
if (res) {
            TRACE("read_data_block: abort() because res = sqlzma_un = %08x\n", res);
// abort();
        }
bytes = un.un_reslen;
return bytes;
} else {
if(read_bytes(start, c_byte, block) == FALSE)
return 0;

return c_byte;
}
}
  (the code is from the squashfs-3.3-lzma version [2])

This is an unsatisfactory hack. And it still doesn't explain why the decompression of 2 data blocks is failing while decompression of the remaining 150+ blocks is successful.

There are three principal configuration parameters to LZMA Decode. These are the number of literal context bits (lc), the position bits (pb) and the literal position bits (lp) where  0<=lc<=8, 0<=pb<=4, 0<=lp<=4.  I won't pretend to understand their role but in total, there are 225 (9*5*5) parameter options for the LZMA decoder.

The decoder was tested with every one of those 225 combinations against those two errant blocks. Yet no combination would work.  It is likely that the unpublished modification to the LZMA code, whatever it involves, is subtle to cause this obscure incompatibility.

An authority on compression algorithms is David Salomon. He is author of the book, Data Compression: The Complete Reference (3rd 4th Edition).  It is available from Amazon and as a PDF.   Chapter Three is dedicated to Dictionary-based compression schemes, of which LZMA is one. [3]

Chapter Three runs to ~80 pages, so it will take some digesting.   In the interim, a request has been filed with ECI for the publication of *all* the GPL'ed and LGPL'ed source code for this device.

Igor Pavlov, who originally designed LZMA, and graciously made his code open source is very accommodating to questions. Whatever it is that ECI-Lantiq-AlphaNetworks have done to nobble LZMA in this device, Pavlov may hopefully help us to find out.  [4]

Another leading light in his field is Armijn Hemel.  Hemel is the co-founder of the Binary Analysis Tool (BAT) project. [5]   BAT is a forensic tool for discovering violations in software licensing, such as those we have uncovered in this ECI equipment.   The BAT project is studying the use of file system tweaks to lock an embedded device.  BAT documents the squashfs tweaks used by several manufacturers, including Realtek, RaLink and Broadcom. The ECI tweak is sadly not amongst those documented (but watch this space!)

Armijn Hemel is also lead compliance engineer at gpl-violations.org, an organisation that actively pursues errant corporations that have stolen others' software for their own enrichment. [6]

Hemel and colleagues take particular interest in securing the Intellectual Property Rights of the BusyBox project. BusyBox is an efficient, multi-function utility for embedded hardware.  ECI, like many other router manufacturers, has misappropriated BusyBox for the firmware to this FTTC device. BusyBox is GPL licensed, and the terms of that licence are perfectly clear.

ECI publishes a glossy brochure affirming its Corporate Responsibilities. One of those commitments is to abide by international treaties and obligations as well as local law.

ECI must put those solemn words into practice. That means no less than the full publication of all source code for all (L)GPL'ed licensed software used in this device.  In the past, ECI had a poor track record for GPL Compliance. It is time to rectify that. Today, General Counsel (and Vice President) for ECI is Arnie Taragin.

So Cough up the Code, Arnie!


[1] https://docs.google.com/leaf?id=0B6wW18m..
[2] http://code.google.com/p/firmware-mod-kit/source/browse/trunk/trunk/src/others/?r=282
[3] http://www.amazon.com/Data-Compression-Reference-David-Salomon/dp/0387406972
[4] https://sourceforge.net/projects/sevenzip/forums/forum/45797
[5] http://www.binaryanalysis.org/en/home
[6] http://www.nytimes.com/2010/09/26/business/26ping.html
« Last Edit: February 14, 2012, 11:34:14 PM by asbokid »
Logged

Orbixx

  • Just arrived
  • *
  • Posts: 7
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #46 on: February 03, 2012, 06:44:51 PM »

Been rummaging through your filesystem dump to look for scripts configuring the modem to be 'locked down'. No dice. Would put money on said files being in that block you can't get to.

That, or it's configured by some arbitrary binary that I've overlooked.

Edit: Also, quite an amusing and bemusing "default" response by Mr Pavlov over at Sourceforge where you raised the issue. But it does indeed look like there are no licensing issues arising from providing a mangled LZMA filesystem due to the LZMA SDK being released into the public domain.
« Last Edit: February 03, 2012, 07:02:55 PM by Orbixx »
Logged

uklad

  • Member
  • **
  • Posts: 55
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #47 on: February 03, 2012, 07:09:00 PM »

Been rummaging through your filesystem dump to look for scripts configuring the modem to be 'locked down'. No dice. Would put money on said files being in that block you can't get to.

That, or it's configured by some arbitrary binary that I've overlooked.

Edit: Also, quite an amusing and bemusing "default" response by Mr Pavlov over at Sourceforge where you raised the issue.

I have been working on this at the moment, I have only just got in from work right now so i cannot elaborate, but it appears the Lan Port 2 is disabled on boot up then put on a Vlan 102 and bridged with the VDSL (i think) not only that the telnet http servers are disabled on boot, I found a script that enables the http server and telnet, but i have been unable to reactivate lan 2..
Logged

uklad

  • Member
  • **
  • Posts: 55
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #48 on: February 03, 2012, 07:11:22 PM »

This is an unsatisfactory hack. And it still doesn't explain why the decompression of 2 data blocks is failing while decompression of the remaining 150+ blocks is successful.

Is it possible I have done a bad NAND dump ?
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #49 on: February 03, 2012, 11:06:33 PM »

Hi Orbixx!

Been rummaging through your filesystem dump to look for scripts configuring the modem to be 'locked down'. No dice. Would put money on said files being in that block you can't get to.

That, or it's configured by some arbitrary binary that I've overlooked.

Indeedy.  It's not all bad news though. All the web resources are accessible, and we now know there's a telnet daemon in the firmware.

Quote
Edit: Also, quite an amusing and bemusing "default" response by Mr Pavlov over at Sourceforge where you raised the issue.

Mr Pavlov seems unfamiliar with these file system locks which are built upon his own compression scheme.[1]  Whoever is designing those locks for various manufacturers must have a deep working knowledge of the LZMA compression scheme.

Quote
But it does indeed look like there are no licensing issues arising from providing a mangled LZMA filesystem due to the LZMA SDK being released into the public domain.

Hmm... I ain't no lawyer (so please ignore at your pleasure) but Phillip Lougher released his squashfs Linux kernel device driver under the GNU GPL. As such, the LZMA patch to squashfs is a "derived" or "derivative" work.  So the LZMA squashfs patch is surely GPL'ed, too.. This case is re-inforced when the squashfs code is compiled into the kernel image, as it is in the ECI firmware.

At least that's how I read it.   But then I'm not a lawyer!

cheers, a

[1] https://tjaldur.nl:8443/repos/gpltool/trunk/bat-extratools/
« Last Edit: February 15, 2012, 12:27:02 AM by asbokid »
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #50 on: February 03, 2012, 11:10:14 PM »

This is an unsatisfactory hack. And it still doesn't explain why the decompression of 2 data blocks is failing while decompression of the remaining 150+ blocks is successful.

Is it possible I have done a bad NAND dump ?

You done good :-)

cheers, a
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #51 on: February 12, 2012, 11:27:40 PM »

Not an update as such, just some links to material that may interest others.

David Salomon is the author of the book Data Compression - The Complete Reference. The book is now in its fourth edition.  A small excerpt from the chapter on Dictionary Methods of compression is attached.  The Dictionary-based LZMA scheme used to compress the root file system in the ECI is briefly addressed in those excerpted pages.

Igor Pavlov has kindly replied to inquiries about the tweaking of LZMA as a locking mechanism for embedded file systems.  [1]

He suggests that perhaps the headers of the two corrupted data blocks from the ECI root file system and, specifically the header field containing the uncompressed size of those data blocks, may have been corrupted in some way.

This theory has yet to be tested. However, the two corrupted blocks happen to be in the middle of two files, rather than at the ends of them. It's difficult to see how corrupting the header in this way would work.

Pavlov points to a thread from 2010 from the squashfs mailing list where a similar problem was discussed.  Phillip Lougher, who designed squashfs, and Lasse Collin who designed XZ, an updated compression tool, discuss the backward compatibility of LZMA(1).  [2]

In that thread, Lougher helpfully lists the different tools offering LZMA decompression. This codebase includes Pavlov's LZMA SDK,  Collin's liblzma, and the lzma1 decompressor from the Linux kernel.

Surprisingly, the Wikipedia entry for LZMA has a reasonably coherent article on the algorithm. [3]

In the manual for LZip which is a "simplified version of the LZMA algorithm", the author of LZip, Antonio Diaz Diaz, briefly describes the range encoder that is the engine at the heart of the LZMA compression scheme.   [4]

cheers, a

[1] http://sourceforge.net/projects/sevenzip/forums/forum/45797/topic/4994244
[2] http://old.nabble.com/Squashfs-4.1-creates-invalid-.lzma-streams-td30217833.html
[3] http://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Markov_chain_algorithm
[4] http://lzip.nongnu.org/manual/lzip_manual.html#Algorithm
« Last Edit: February 13, 2012, 02:02:55 AM by asbokid »
Logged

uklad

  • Member
  • **
  • Posts: 55
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #52 on: February 13, 2012, 04:12:27 PM »

maybe a stupid question but do you get the same decompression issue with the file safe firmware
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #53 on: February 13, 2012, 07:58:31 PM »

Hi uklad,

Both of the squashfs-lzma file systems found in the ECI firmware (identified below as ecirootfs1 and eciroofs2) cause the LZMA decoder to throw an error:

Code: [Select]
$ cd ~/Documents/btinfinity/eci_asbo001/squashfs-3.3-lzma-asbo001/squashfs3.3/squashfs-tools

$ ls -ln ecirootfs*
-rw-r--r--  1 1000 1000 2641669 Feb 14  2011 06:44 ecirootfs1
-rw-r--r--  1 1000 1000 2642454 Aug  9  2011 04:31 ecirootfs2

Here is ecirootfs1, which is the older of the two file systems. As such it is the slave, or the 'fail-safe':

Code: [Select]
$ sudo ./unsquashfs -d ./ecirootfs1-squashfs-root/ ecirootfs1
Reading a different endian SQUASHFS filesystem on ecirootfs1
err -22: sqlzma_un: LZMA Unknown error 18446744073709551594
err -22: sqlzma_un: LZMA Unknown error 18446744073709551594

created 612 files
created 83 directories
created 118 symlinks
created 31 devices
created 0 fifos
$

And now ecirootfs2, the newer of the two squashfs images from the ECI firmware:

Code: [Select]
$ sudo ./unsquashfs -d ./ecirootfs2-squashfs-root/ ecirootfs2
Reading a different endian SQUASHFS filesystem on ecirootfs2
err -22: sqlzma_un: LZMA Unknown error 18446744073709551594
err -22: sqlzma_un: LZMA Unknown error 18446744073709551594

created 612 files
created 83 directories
created 118 symlinks
created 31 devices
created 0 fifos
$

We should check whether the decompression errors are occurring in the same block numbers in those two different file systems.  This could give a better insight into the locking mechanism, and its implementation.

For curiosity's sake, here is a diff of the two root file systems - the main and the slave - from the ECI firmware. We can see that there are binary differences in the busybox binary. This causes diffs for all symlinks to busybox (e.g. /bin/cat, /bin/chmod, etc.).  Once those duplicate diffs are ignored, the two file systems are very similar.

Noteworthy is that there are differences in the Lantiq DSP hardware driver blob (xcpe_hw.bin)

Code: [Select]
$ diff -r ecirootfs*-squ*
Binary files ecirootfs1-squashfs-root/bin/busybox and ecirootfs2-squashfs-root/bin/busybox differ
Binary files ecirootfs1-squashfs-root/bin/cat and ecirootfs2-squashfs-root/bin/cat differ
Binary files ecirootfs1-squashfs-root/bin/chmod and ecirootfs2-squashfs-root/bin/chmod differ
Binary files ecirootfs1-squashfs-root/bin/cp and ecirootfs2-squashfs-root/bin/cp differ
Binary files ecirootfs1-squashfs-root/bin/date and ecirootfs2-squashfs-root/bin/date differ
Binary files ecirootfs1-squashfs-root/bin/dd and ecirootfs2-squashfs-root/bin/dd differ
Binary files ecirootfs1-squashfs-root/bin/df and ecirootfs2-squashfs-root/bin/df differ
Binary files ecirootfs1-squashfs-root/bin/echo and ecirootfs2-squashfs-root/bin/echo differ
Binary files ecirootfs1-squashfs-root/bin/egrep and ecirootfs2-squashfs-root/bin/egrep differ
Binary files ecirootfs1-squashfs-root/bin/false and ecirootfs2-squashfs-root/bin/false differ
Binary files ecirootfs1-squashfs-root/bin/fgrep and ecirootfs2-squashfs-root/bin/fgrep differ
Binary files ecirootfs1-squashfs-root/bin/grep and ecirootfs2-squashfs-root/bin/grep differ
Binary files ecirootfs1-squashfs-root/bin/gunzip and ecirootfs2-squashfs-root/bin/gunzip differ
Binary files ecirootfs1-squashfs-root/bin/gzip and ecirootfs2-squashfs-root/bin/gzip differ
Binary files ecirootfs1-squashfs-root/bin/kill and ecirootfs2-squashfs-root/bin/kill differ
Binary files ecirootfs1-squashfs-root/bin/ln and ecirootfs2-squashfs-root/bin/ln differ
Binary files ecirootfs1-squashfs-root/bin/login and ecirootfs2-squashfs-root/bin/login differ
Binary files ecirootfs1-squashfs-root/bin/ls and ecirootfs2-squashfs-root/bin/ls differ
Binary files ecirootfs1-squashfs-root/bin/mkdir and ecirootfs2-squashfs-root/bin/mkdir differ
Binary files ecirootfs1-squashfs-root/bin/mknod and ecirootfs2-squashfs-root/bin/mknod differ
Binary files ecirootfs1-squashfs-root/bin/more and ecirootfs2-squashfs-root/bin/more differ
Binary files ecirootfs1-squashfs-root/bin/mount and ecirootfs2-squashfs-root/bin/mount differ
Binary files ecirootfs1-squashfs-root/bin/msh and ecirootfs2-squashfs-root/bin/msh differ
Binary files ecirootfs1-squashfs-root/bin/mv and ecirootfs2-squashfs-root/bin/mv differ
Binary files ecirootfs1-squashfs-root/bin/ping and ecirootfs2-squashfs-root/bin/ping differ
Binary files ecirootfs1-squashfs-root/bin/ps and ecirootfs2-squashfs-root/bin/ps differ
Binary files ecirootfs1-squashfs-root/bin/pwd and ecirootfs2-squashfs-root/bin/pwd differ
Binary files ecirootfs1-squashfs-root/bin/rm and ecirootfs2-squashfs-root/bin/rm differ
Binary files ecirootfs1-squashfs-root/bin/sed and ecirootfs2-squashfs-root/bin/sed differ
Binary files ecirootfs1-squashfs-root/bin/sh and ecirootfs2-squashfs-root/bin/sh differ
Binary files ecirootfs1-squashfs-root/bin/sleep and ecirootfs2-squashfs-root/bin/sleep differ
Binary files ecirootfs1-squashfs-root/bin/touch and ecirootfs2-squashfs-root/bin/touch differ
Binary files ecirootfs1-squashfs-root/bin/true and ecirootfs2-squashfs-root/bin/true differ
Binary files ecirootfs1-squashfs-root/bin/umount and ecirootfs2-squashfs-root/bin/umount differ
Binary files ecirootfs1-squashfs-root/bin/uname and ecirootfs2-squashfs-root/bin/uname differ
Binary files ecirootfs1-squashfs-root/bin/usleep and ecirootfs2-squashfs-root/bin/usleep differ
Binary files ecirootfs1-squashfs-root/bin/zcat and ecirootfs2-squashfs-root/bin/zcat differ

[..snipped - errors from missing symlinks and from reading device nodes..]

diff -r ecirootfs1-squashfs-root/etc/config/builddate ecirootfs2-squashfs-root/etc/config/builddate
1c1
< 2011-02-14 14:44
---
> 2011-08-09 11:31
diff -r ecirootfs1-squashfs-root/etc/config/buildno ecirootfs2-squashfs-root/etc/config/buildno
1c1
< b2ee
---
> b89b
diff -r ecirootfs1-squashfs-root/etc/config/buildrev ecirootfs2-squashfs-root/etc/config/buildrev
1c1
< 3067
---
> 3123
Binary files ecirootfs1-squashfs-root/etc/config/defaultvalue.gz and ecirootfs2-squashfs-root/etc/config/defaultvalue.gz differ
Binary files ecirootfs1-squashfs-root/ifx/vdsl2/drv_dsl_cpe_api.ko and ecirootfs2-squashfs-root/ifx/vdsl2/drv_dsl_cpe_api.ko differ
Binary files ecirootfs1-squashfs-root/ifx/vdsl2/drv_ifxos.ko and ecirootfs2-squashfs-root/ifx/vdsl2/drv_ifxos.ko differ
Binary files ecirootfs1-squashfs-root/ifx/vdsl2/xcpe_hw.bin and ecirootfs2-squashfs-root/ifx/vdsl2/xcpe_hw.bin differ
Binary files ecirootfs1-squashfs-root/lib/libsystem.so and ecirootfs2-squashfs-root/lib/libsystem.so differ
Binary files ecirootfs1-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/connector/cn.ko and ecirootfs2-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/connector/cn.ko differ
Binary files ecirootfs1-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/net/dummy.ko and ecirootfs2-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/net/dummy.ko differ
Binary files ecirootfs1-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/net/ifxmips_ppa/platform/vr9/e5/ifxmips_ppa_datapath_vr9_e5.ko and ecirootfs2-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/net/ifxmips_ppa/platform/vr9/e5/ifxmips_ppa_datapath_vr9_e5.ko differ
Binary files ecirootfs1-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/net/ifxmips_ppa/platform/vr9/e5/ifxmips_ppa_hal_vr9_e5.ko and ecirootfs2-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/net/ifxmips_ppa/platform/vr9/e5/ifxmips_ppa_hal_vr9_e5.ko differ
Binary files ecirootfs1-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/net/ifxmips_ppa/ppa_api/ifx_ppa_api.ko and ecirootfs2-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/net/ifxmips_ppa/ppa_api/ifx_ppa_api.ko differ
Binary files ecirootfs1-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/net/ifxmips_ppa/ppa_api/ifx_ppa_api_proc.ko and ecirootfs2-squashfs-root/lib/modules/2.6.20.19/kernel/drivers/net/ifxmips_ppa/ppa_api/ifx_ppa_api_proc.ko differ
Binary files ecirootfs1-squashfs-root/lib/modules/2.6.20.19/kernel/fs/configfs/configfs.ko and ecirootfs2-squashfs-root/lib/modules/2.6.20.19/kernel/fs/configfs/configfs.ko differ
Binary files ecirootfs1-squashfs-root/lib/modules/2.6.20.19/kernel/security/capability.ko and ecirootfs2-squashfs-root/lib/modules/2.6.20.19/kernel/security/capability.ko differ
Binary files ecirootfs1-squashfs-root/lib/modules/2.6.20.19/kernel/security/commoncap.ko and ecirootfs2-squashfs-root/lib/modules/2.6.20.19/kernel/security/commoncap.ko differ
Binary files ecirootfs1-squashfs-root/sbin/getty and ecirootfs2-squashfs-root/sbin/getty differ
Binary files ecirootfs1-squashfs-root/sbin/ifconfig and ecirootfs2-squashfs-root/sbin/ifconfig differ
Binary files ecirootfs1-squashfs-root/sbin/init and ecirootfs2-squashfs-root/sbin/init differ
Binary files ecirootfs1-squashfs-root/sbin/insmod and ecirootfs2-squashfs-root/sbin/insmod differ
Binary files ecirootfs1-squashfs-root/sbin/lsmod and ecirootfs2-squashfs-root/sbin/lsmod differ
Binary files ecirootfs1-squashfs-root/sbin/mdev and ecirootfs2-squashfs-root/sbin/mdev differ
Binary files ecirootfs1-squashfs-root/sbin/modprobe and ecirootfs2-squashfs-root/sbin/modprobe differ
Binary files ecirootfs1-squashfs-root/sbin/reboot and ecirootfs2-squashfs-root/sbin/reboot differ
Binary files ecirootfs1-squashfs-root/sbin/rmmod and ecirootfs2-squashfs-root/sbin/rmmod differ
Binary files ecirootfs1-squashfs-root/sbin/route and ecirootfs2-squashfs-root/sbin/route differ
Binary files ecirootfs1-squashfs-root/sbin/swapoff and ecirootfs2-squashfs-root/sbin/swapoff differ
Binary files ecirootfs1-squashfs-root/sbin/swapon and ecirootfs2-squashfs-root/sbin/swapon differ
Binary files ecirootfs1-squashfs-root/sbin/sysctl and ecirootfs2-squashfs-root/sbin/sysctl differ
Binary files ecirootfs1-squashfs-root/usr/bin/[ and ecirootfs2-squashfs-root/usr/bin/[ differ
Binary files ecirootfs1-squashfs-root/usr/bin/basename and ecirootfs2-squashfs-root/usr/bin/basename differ
Binary files ecirootfs1-squashfs-root/usr/bin/cut and ecirootfs2-squashfs-root/usr/bin/cut differ
Binary files ecirootfs1-squashfs-root/usr/bin/dirname and ecirootfs2-squashfs-root/usr/bin/dirname differ
Binary files ecirootfs1-squashfs-root/usr/bin/expr and ecirootfs2-squashfs-root/usr/bin/expr differ
Binary files ecirootfs1-squashfs-root/usr/bin/free and ecirootfs2-squashfs-root/usr/bin/free differ
Binary files ecirootfs1-squashfs-root/usr/bin/killall and ecirootfs2-squashfs-root/usr/bin/killall differ
Binary files ecirootfs1-squashfs-root/usr/bin/logger and ecirootfs2-squashfs-root/usr/bin/logger differ
Binary files ecirootfs1-squashfs-root/usr/bin/mpstat and ecirootfs2-squashfs-root/usr/bin/mpstat differ
Binary files ecirootfs1-squashfs-root/usr/bin/test and ecirootfs2-squashfs-root/usr/bin/test differ
Binary files ecirootfs1-squashfs-root/usr/bin/test_agent and ecirootfs2-squashfs-root/usr/bin/test_agent differ
Binary files ecirootfs1-squashfs-root/usr/bin/tftp and ecirootfs2-squashfs-root/usr/bin/tftp differ
Binary files ecirootfs1-squashfs-root/usr/bin/top and ecirootfs2-squashfs-root/usr/bin/top differ
Binary files ecirootfs1-squashfs-root/usr/bin/tr and ecirootfs2-squashfs-root/usr/bin/tr differ
Binary files ecirootfs1-squashfs-root/usr/bin/uptime and ecirootfs2-squashfs-root/usr/bin/uptime differ
Binary files ecirootfs1-squashfs-root/usr/bin/wc and ecirootfs2-squashfs-root/usr/bin/wc differ
Binary files ecirootfs1-squashfs-root/usr/bin/wget and ecirootfs2-squashfs-root/usr/bin/wget differ
Binary files ecirootfs1-squashfs-root/usr/bin/yes and ecirootfs2-squashfs-root/usr/bin/yes differ
Binary files ecirootfs1-squashfs-root/usr/sbin/cfm and ecirootfs2-squashfs-root/usr/sbin/cfm differ
$

The file /etc/config/defaultvalue.gz also looks interesting.  It is a compressed XML-based configuration file for the modem.

Note the XML element <activate> found under <lantiq_vr9_generic_asl56026><switch><port id="2"><activate>0</activate> in that config file.   Presumably, by setting that element value to 1, the second ethernet port on the modem is re-activated.  The element <lan_access_cpe_enable> probably needs to have a value of 1, as well.

Code: [Select]
$ cat ecirootfs2-squashfs-root/etc/config/defaultvalue.gz | gunzip

<lantiq_vr9_generic_asl56026>
<check>
<is_factory>factory</is_factory>
</check>
<vdsl2>
<infineon>
<fw_variant>VA</fw_variant>
<annex>A</annex>
<adsl_encaps>1</adsl_encaps>
<default_vpi_vci>1</default_vpi_vci>
<line_config>
<filter>0</filter>
<hw_hybrid>2</hw_hybrid>
<line_mode>102</line_mode>
</line_config>
</infineon>
</vdsl2>
<switch>
<bypass_mode>0</bypass_mode>
<lan_access_cpe_enable>0</lan_access_cpe_enable>
<discard_specific_pkt>1</discard_specific_pkt>
<igmp_queue>3</igmp_queue>
<port id="1">
<vid>101</vid>
<pri>2</pri>
<loopback>0</loopback>
<activate>1</activate>
<special_vlan>0</special_vlan>
</port>
<port id="2">
<vid>102</vid>
<pri>7</pri>
<loopback>0</loopback>
<activate>0</activate>
<special_vlan>0</special_vlan>
</port>
</switch>
<wan>
<physical_type>1</physical_type>
<enable_dhcp60>0</enable_dhcp60>
<dhcp_option60></dhcp_option60>
<enable_dhcp61>0</enable_dhcp61>
<dhcp_iaid></dhcp_iaid>
<dhcp_duid>0</dhcp_duid>
<enable_dhcp125>0</enable_dhcp125>
<dhcp_option125></dhcp_option125>
<enable_prepadt>0</enable_prepadt>
<dsl>
<defaultroute>1</defaultroute>
<inf id="1">
<mode>1</mode>
<enable>1</enable>
<atm>
<pvc>
<settings>
<vpi>8</vpi>
<vci>35</vci>
</settings>
</pvc>
</atm>
<ptm>
<vtag>
<settings>
<connection>connection1</connection>
<enable>1</enable>
<vid>301</vid>
<priority>5</priority>
<bt>
<enable>1</enable>
<wan_vid1>101</wan_vid1>
<wan_vid2>102</wan_vid2>
</bt>
</settings>
</vtag>
</ptm>
<dhcp>
<hostname></hostname>
<clonemac></clonemac>
<autodns>1</autodns>
<mtu>1500</mtu>
</dhcp>
<static>
<mode>1</mode>
<ip>5.60.39.51</ip>
<netmask>255.0.0.0</netmask>
<gateway>5.21.97.200</gateway>
<clonemac></clonemac>
<mtu>1500</mtu>
</static>
</inf>

[...snipped...]

</lantiq_vr9_generic_asl56026>

The decompressed modem config file from ecirootfs2 is attached below.

cheers, a
« Last Edit: February 15, 2012, 12:56:02 AM by asbokid »
Logged

uklad

  • Member
  • **
  • Posts: 55
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #54 on: February 14, 2012, 04:14:28 PM »

interesting i spent some time trying to get port 2 active with no luck..

do you know what files are failling during the decompression..
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #55 on: February 14, 2012, 07:46:51 PM »

Hi uklad,

interesting i spent some time trying to get port 2 active with no luck..

One trick is as follows:

Copy that file /etc/config/defaultvalue.gz from the squashfs read-only root file system to a read-write file system (e.g. a ramdisk).

Modify that read-writable copy with the desired configurations.

Re-mount the modified file over the top of the original in the read-only squashfs.

(See the Linux/busybox manpage for mount, and the --bind option.)

Force the config software - the firmware utility that actually reads the contents of that file - to re-load it.

Since this doesn't modify the squashfs system it is non-destructive.  The hack is described well by paul at sbrk.co.uk at [1].

Quote
do you know what files are failing during the decompression..

One of those two bad LZMA data blocks is in the middle of the 461,960 byte busybox binary.  It is block #7 of 8, @ 0x32edc in ecirootfs2

Igor Pavlov
's suggestions are currently under test.  His theory is that maybe just the data block headers are corrupted, while the data in those blocks is actually okay.

Each data block in the squashfs-lzma file system is prepended with a 13-byte LZMA header. This header contains an 8-bit field in which the lc, lp and pb parameters for the LZMA decoder are stored, as well as a 32-bit field to hold the dictionary size, and a 64-bit field for the uncompressed size of the block.

Below we can see the header from a good block (test1.lzma) and then the header of a bad block (test2.lzma).  Both headers are clearly identical.   Both have a decoder configuration of 0x5d, both use a dictionary size of 0x800000 (8Mbytes), and both blocks apparently uncompress to a size of 0x10000 (65,536) bytes.

Code: [Select]
$ cd ~/Documents/btinfinity/eci_asbo001/lzma439_asbo002/C/7zip/Compress/LZMA_C

$ xxd -l 13 test1.lzma
0000000: 5d00 0080 0000 0001 0000 0000 00         ]............

$ xxd -l 13 test2.lzma
0000000: 5d00 0080 0000 0001 0000 0000 00         ]............

What Igor Pavlov is suggesting is that perhaps the value in the uncompressed size field of a bad block has been faked. When the LZMA decoder discovers at run-time that the uncompressed size is not what it expected, the decoder aborts with an error.   Igor Pavlov says that perhaps this is the method used for locking the squashfs file system in the ECI.

The easiest way to test that theory is to repeatedly feed the same bad data block through the LZMA decoder.  In each iteration, the uncompressed size field is increased.  This is repeated until an error is reported by the LZMA decoder.

That's what is shown below.   We can see that the compressed bitstream in the bad data block can be decoded up until byte 31,869.  Remember, however, that in the header of that data block, the uncompressed size of the block was recorded as 65,536 bytes.

This identifies one of two things. 

Either it reveals the genuine uncompressed size of the data block, or it reveals the point at which the compressed bitstream is corrupted (forcing the decoder to abort.)

Code: [Select]
$ ./lzmadec test2.lzma test2.bin
Opened test2.lzma
compressedSize = 17129
outSizeFull = 65536
Calling LzmaDecode(compressedSize = 17129, estimOutSize = 17079) : returned res = 0 (success) -- inProcessed = 7525, outProcessed = 17079
Calling LzmaDecode(compressedSize = 17129, estimOutSize = 17080) : returned res = 0 (success) -- inProcessed = 7525, outProcessed = 17080
Calling LzmaDecode(compressedSize = 17129, estimOutSize = 17081) : returned res = 0 (success) -- inProcessed = 7525, outProcessed = 17081
Calling LzmaDecode(compressedSize = 17129, estimOutSize = 17082) : returned res = 0 (success) -- inProcessed = 7525, outProcessed = 17082
Calling LzmaDecode(compressedSize = 17129, estimOutSize = 17083) : returned res = 0 (success) -- inProcessed = 7527, outProcessed = 17083
 [.. snipped ..]
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31866) : returned res = 0 (success) -- inProcessed = 12067, outProcessed = 31866
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31867) : returned res = 0 (success) -- inProcessed = 12067, outProcessed = 31867
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31868) : returned res = 0 (success) -- inProcessed = 12069, outProcessed = 31868
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31869) : returned res = 0 (success) -- inProcessed = 12069, outProcessed = 31869
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31870) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31871) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31872) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31873) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31874) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31875) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
 [.. snipped ..]

By way of reference, here is the output from the same test performed on the good data block.  We can see that it successfully decodes the block up until byte 65,536. That is correct insofar as it matches the uncompressed size reported in the block header.

Code: [Select]
$ ./lzmadec test1.lzma test1.bin
Opened test1.lzma
compressedSize = 25826
outSizeFull = 65536
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 25776) : returned res = 0 (success) -- inProcessed = 10700, outProcessed = 25776
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 25777) : returned res = 0 (success) -- inProcessed = 10701, outProcessed = 25777
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 25778) : returned res = 0 (success) -- inProcessed = 10701, outProcessed = 25778
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 25779) : returned res = 0 (success) -- inProcessed = 10701, outProcessed = 25779
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 25780) : returned res = 0 (success) -- inProcessed = 10702, outProcessed = 25780
 [.. snipped ..]
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65530) : returned res = 0 (success) -- inProcessed = 25824, outProcessed = 65530
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65531) : returned res = 0 (success) -- inProcessed = 25824, outProcessed = 65531
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65532) : returned res = 0 (success) -- inProcessed = 25824, outProcessed = 65532
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65533) : returned res = 0 (success) -- inProcessed = 25826, outProcessed = 65533
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65534) : returned res = 0 (success) -- inProcessed = 25826, outProcessed = 65534
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65535) : returned res = 0 (success) -- inProcessed = 25826, outProcessed = 65535
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65536) : returned res = 0 (success) -- inProcessed = 25826, outProcessed = 65536
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65537) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65538) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65539) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65540) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65541) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65542) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
Calling LzmaDecode(compressedSize = 25826, estimUncompSize = 65543) : returned res = 1 (fail) -- inProcessed = 0, outProcessed = 0
 [.. snipped ..]

It looks like the hack goes deeper than just faking the LZMA header fields. The compressed bitstream itself has been tweaked.

In those tests where the bad data block was repeatedly fed to the LZMA decoder, we can study the last good iteration before a decoding error occurred:

Code: [Select]
Calling LzmaDecode(compressedSize = 17129, estimUncompSize = 31869) : returned res = 0 (success) -- inProcessed = 12069, outProcessed = 31869

We can see that the decoder has only processed 12069 bytes out of 17129 bytes in the compressed datastream. For the hacked header theory to be correct, it would mean here that the compressed block has 5060 'dead' bytes of padding.  (17129-12069 = 5060).

If the hack just involved a header hack, there would be no point in doing that.  It would be unnecessary and wasteful. The uncompressed block size only needs to be faked by one byte. That will still cause a decode failure. There's no point in faking the size by 5060 bytes, and then padding the compressed datastream with all those pointless bytes.

It's still a working theory though, so there may be something in it.. :-)

cheers, a

[1] http://www.sbrk.co.uk/hw553/general/rofs.html
« Last Edit: February 15, 2012, 02:28:55 AM by asbokid »
Logged

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #56 on: February 15, 2012, 03:48:27 AM »

do you know what files are failing during the decompression..

In eciroofs1, the following two data blocks are failing to decompress. 

The first data block to fail in ecirootfs1 is @0x44e35. It is the first of nine blocks used to store the file drv_dsl_cpe_api.ko.  That file appears to be a character device driver providing a kernel interface to the DSL hardware (an unknown 32-bit DSP engine on the Lantiq VRX268 core). When uncompressed, that driver file should be 578,157 bytes in size, and the failed block should provide 65,536 bytes towards it when uncompressed.

The second bad data block in ecirootfs1 is @0x8e143. It is the first of twelve blocks that holds the file xcpe_hw.bin.  That file is the DSP hardware device driver blob.  It should be 767,376 bytes in size, and the failed block should provide 65,536 bytes when uncompressed.

Code: [Select]
Reading a different endian SQUASHFS filesystem on ecirootfs1

-rwxr-xr-x 505/users            578157 2011-02-14 06:44 squashfs-root/ifx/vdsl2/drv_dsl_cpe_api.ko
unsquashfs: dir_scan: name drv_dsl_cpe_api.ko, start_block 0, offset 7621, type 2
unsquashfs: create_inode: pathname squashfs-root/ifx/vdsl2/drv_dsl_cpe_api.ko
unsquashfs: create_inode: regular file, file_size 578157, blocks 9
unsquashfs: write_file: regular file, blocks 9
unsquashfs: read_data_block: block @0x44e35, 14351 compressed bytes
unsquashfs: read_bytes: reading from position 0x44e35, bytes 14351 (0x380f)

[...snipped...]

unsquashfs: read_data_block: block @0x4dffe, 18111 compressed bytes
unsquashfs: read_bytes: reading from position 0x4dffe, bytes 18111 (0x46bf)

00000000: 5d 00 00 80 00 00 00 01 00 00 00 00 00 00 13 af
00000010: 3c 06 45 13 7d b5 59 62 72 8f db b5 8f 8e f0 bb

[...snipped...]

000045a0: a3 d0 37 83 70 87 5c 82 2b 3a fd 66 9b d6 b6 0c
000045b0: b2 6e 0d d5 34 07 57
err -22: sqlzma_un: LZMA Unknown error 18446744073709551594
                               ea ae 66 04 51 9e 5e be 31
000045c0: 4c 0b 51 6f 16 63 d7 cb da 76 cb ce c5 00 69 8f

[...snipped...]

000046b0: 4d 78 5c af fa f7 81 18 0c f1 6d 19 6c 95 03

unsquashfs: read_data_block: abort() because res = sqlzma_un = ffffffea

[...snipped...]

-rwxr-xr-x 505/users            767376 2011-02-14 06:44 squashfs-root/ifx/vdsl2/xcpe_hw.bin
unsquashfs: read_fragment: reading fragment 10
unsquashfs: dir_scan: name xcpe_hw.bin, start_block 0, offset 8001, type 2
unsquashfs: create_inode: pathname squashfs-root/ifx/vdsl2/xcpe_hw.bin
unsquashfs: create_inode: regular file, file_size 767376, blocks 12
unsquashfs: write_file: regular file, blocks 12
unsquashfs: read_data_block: block @0x7af16, 40885 compressed bytes
unsquashfs: read_bytes: reading from position 0x7af16, bytes 40885 (0x9fb5)

[...snipped...]

unsquashfs: read_data_block: block @0x8e143, 40792 compressed bytes
unsquashfs: read_bytes: reading from position 0x8e143, bytes 40792 (0x9f58)

00000000: 5d 00 00 80 00 00 00 01 00 00 00 00 00 00 02 00
00000010: 09 91 c2 58 7c 6b 07 b7 bc e8 98 5f 1e 63 13 cc

[...snipped...]

00009d30: 44 e8 23 9d 7c 3c 87 30 50 9c da d2 d1 f5 84 e9
00009d40: fa f4 51 2c d8 fb 48 be 51 56 97 20 b5 e7 de 72
00009d5
err -22: sqlzma_un: LZMA Unknown error 18446744073709551594
       0: 73 e3 e1 51 75 8a 59 d1 b2 73 04 4a 9b 7f 89 28
00009d60: 90 61 9f b6 9c 9b 9b b3 5f 38 6a a5 90 d5 85 11

[...snipped...]

00009f50: c0 ae c7 10 5e 2a f0 94

unsquashfs: read_data_block: abort() because res = sqlzma_un = ffffffea

In ecirootfs2, the second squashfs file system in the ECI firmware, once again we find two bad blocks that won't decompress.  The first bad block is @0x32edc. That is the seventh of eight blocks storing the busybox binary. The busybox binary should be 461,960 bytes and when uncompressed, that block should hold 65,536 bytes of it.

The second bad block in ecirootfs2 is block @0x63bb1.  It is the first of six blocks holding another kernel device driver. This driver is named drv_ifxos.ko and it should be 357,839 bytes uncompressed. The bad block should provide 65,536 bytes of that.

Code: [Select]
Reading a different endian SQUASHFS filesystem on ecirootfs2

-rwxrwxr-x 505/users            461960 2011-08-09 04:31 squashfs-root/bin/busybox
unsquashfs: dir_scan: name busybox, start_block 0, offset 936, type 2
unsquashfs: create_inode: pathname squashfs-root/bin/busybox
unsquashfs: create_inode: regular file, file_size 461960, blocks 8
unsquashfs: write_file: regular file, blocks 8
unsquashfs: read_data_block: block @0x10de0, 24250 compressed bytes
unsquashfs: read_bytes: reading from position 0x10de0, bytes 24250 (0x5eba)

[...snipped...]

unsquashfs: read_data_block: block @0x32edc, 17142 compressed bytes
unsquashfs: read_bytes: reading from position 0x32edc, bytes 17142 (0x42f6)

00000000: 5d 00 00 80 00 00 00 01 00 00 00 00 00 00 31 19
00000010: 40 06 32 0a 09 7e e1 df 4a af 79 8a 22 ec c1 75

[...snipped...]

00004180: 12 55 4f b3 18 02 b9 38 8d 36 1b 65 cd 44 43 f2
err -22
sqlzma_un: LZMA Unknown error 18446744073709551594
00004190: 8d f9 4a 51 0d 4a 8f 85 2d c4 95 5c 07 a9 6e e3

[...snipped...]

000042e0: 50 71 26 6b 9d 15 b9 f0 b8 bc ab 34 65 9a e4 86
000042f0: 6e f7 89 92 48 ae

unsquashfs: read_data_block: abort() because res = sqlzma_un = ffffffea

[...snipped...]

-rwxr-xr-x 505/users            357839 2011-08-09 04:31 squashfs-root/ifx/vdsl2/drv_ifxos.ko
unsquashfs: dir_scan: name drv_ifxos.ko, start_block 0, offset 7689, type 2
unsquashfs: create_inode: pathname squashfs-root/ifx/vdsl2/drv_ifxos.ko
unsquashfs: create_inode: regular file, file_size 357839, blocks 6
unsquashfs: write_file: regular file, blocks 6
unsquashfs: read_data_block: block @0x63bb1, 25245 compressed bytes
unsquashfs: read_bytes: reading from position 0x63bb1, bytes 25245 (0x629d)

00000000: 5d 00 00 80 00 00 00 01 00 00 00 00 00 00 3f 91
00000010: 45 84 68 34 8a 09 0a 41 50 57 af 46 76 b3 d7 96

[...snipped...]

00006200: 07 3b e0 a3 cb 88 2d 62 b0 6f 1e 6c 26 47 da b5
0000
    err -22: sqlzma_un: LZMA Unknown error 18446744073709551594
    6210: e8 90 91 68 22 96 49 a8 9f 06 19 d7 b7 50 71 2e

[...snipped...]

00006280: 4b 29 9c 2d 1f 9b 5f 33 49 de 42 43 03 45 f2 42
00006290: 1f ba 76 8a d3 b5 72 d7 34 8c f9 62 32

unsquashfs: read_data_block: abort() because res = sqlzma_un = ffffffea


I'm not sure what any of that proves.. except that there are exactly two bad blocks per file system, and they are in different places in each file system.

cheers, a
« Last Edit: February 15, 2012, 03:53:18 AM by asbokid »
Logged

uklad

  • Member
  • **
  • Posts: 55
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #57 on: February 15, 2012, 10:29:30 AM »

Hi uklad,

interesting i spent some time trying to get port 2 active with no luck..

One trick is as follows:

Copy that file /etc/config/defaultvalue.gz from the squashfs read-only root file system to a read-write file system (e.g. a ramdisk).

Modify that read-writable copy with the desired configurations.

Re-mount the modified file over the top of the original in the read-only squashfs.

(See the Linux/busybox manpage for mount, and the --bind option.)

Force the config software - the firmware utility that actually reads the contents of that file - to re-load it.

Since this doesn't modify the squashfs system it is non-destructive.  The hack is described well by paul at sbrk.co.uk at [1].

I'm away all week training :( but i will try and find some time to try this at the weekend ...
Logged

burakkucat

  • Global Moderator
  • Senior Kitizen
  • *
  • Posts: 34873
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #58 on: February 15, 2012, 02:22:46 PM »

Quote
I'm not sure what any of that proves.. except that there are exactly two bad blocks per file system, and they are in different places in each file system.

May be just pointless caterwauling on my part but if those two sqashfs' are supposed to be identical, with two defects in different places in them both, then surely a controlled merge of both will give you one complete file system.  :-\

Hmm . . . am I yowling from the wrong tree-top?  ???
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

asbokid

  • Kitizen
  • ****
  • Posts: 1286
    • Hacking the 2Wire
Re: Hacking the ECI model B-FOCuS V-2FUb/I Rev.B
« Reply #59 on: February 15, 2012, 08:47:47 PM »

Quote
I'm not sure what any of that proves.. except that there are exactly two bad blocks per file system, and they are in different places in each file system.

May be just pointless caterwauling on my part but if those two squashfs' are supposed to be identical, with two defects in different places in them both, then surely a controlled merge of both will give you one complete file system.  :-\

Hmm . . . am I yowling from the wrong tree-top?  ???

Hi Burakkucat.

Sure. We can certainly do that and it could help to discover how the LZMA code in the ECI kernel has been modified.   

The main problem still exists, though.  Even with those two file systems merged to make one good one,  the squashfs driver in the pre-built kernel of the ECI is still expecting to read a file system image that has been tweaked in some way.

That fs kernel driver will perform an 'un-tweak' operation on specific 'tweaked' compressed blocks. The 'un-tweak' must be performed before those blocks are passed to the LZMA decoder for decompression.  However, when the driver performs an 'un-tweak' on a data block that we have already un-tweaked (from our controlled merge), that second un-tweak will effectively corrupt the block.  When the block is passed to the LZMA decoder, its decompression will subsequently fail.

Two possibilities spring to mind for overcoming this..

a) re-build the kernel with a squashfs driver that is not tweaked in any way, so that it can work with a 'clean' squashfs file system.  Currently that is no mean feat since ECI/Lantiq/AlphaNetworks have shown no interest in abiding by the terms of the GPL licence, and we would need the kernel build configs to do this; or

b) try to re-make the file system so that those two tweaked blocks remain unallocated by the file system or else are masked-off in "lost+found" inodes or something similar.

We don't strictly need to do a controlled merge, since uklad has shell access to the device. He could obtain the decompressed form of any regular file in the squashfs file system.  Those decompressed files would be dumped over the serial connection and chopped into blocks of 65,536 bytes (or less). Then they would be re-compressed with the LZMA encoder.  In theory, those re-compressed data blocks could be inserted back into the squash file system image.

I'm a bit stuck here, since I haven't got an ECI modem to hack about with things like that.

Also it's a lot of faffing around.  There are others interested in this issue of squashfs tweaking, not least for legal reasons since their code has been purloined in these firmwares.  Hopefully in the dueness of time, some better ideas and suggestions will percolate out of the ether!

cheers, a
« Last Edit: February 15, 2012, 10:52:48 PM by asbokid »
Logged
Pages: 1 2 3 [4] 5 6 ... 21
 

anything