6

See Update below.

I got an email from Logitech that they are End of Lifing their Harmony Link product (see https://community.logitech.com/s/question/0D55A0000745EkCSAU/harmony-link-eos-or-eol).

So I took it upon myself to start taking it apart. Peeling back the sticky pads on the bottom revealed 4 solder points. Two of which happen to UART connections.

Here is the info when booting:

++NAND: RCSR=54200900
Searching for BBT table in the flash ...
.
Found version 1 Bbt0 at block 1023 (0x7fe0000)
Total bad blocks: 0
.[Warning] FEC not connect right PHY: ID=fffffc
FEC: [ FULL_DUPLEX ] [ connected ] [ 100M bps ]:
Ethernet mxc_fec: MAC address sn:ip:ped:fr:om:vu
No IP info for device!
Unrecognized chip: 0xf8!!!
hardware reset by POR

Clock input is 24 MHz
RedBoot(tm) bootstrap and debug environment [ROMRAM]
Non-certified release, version FSL 200904 - built 21:32:37, Jul  5 2011

Platform: Logitech Baby (i.MX25 )  PASS 1.0 [x32 DDR]
System type 2070 revision 6
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
Copyright (C) 2003, 2004, 2005, 2006 eCosCentric Limited

RAM: 0x00000000-0x03f00000, [0x00095250-0x03ef1000] available
FLASH: 0x00000000 - 0x8000000, 1024 blocks of 0x00020000 bytes each.
== Executing boot script in 3.000 seconds - enter ^C to abort
RedBoot> ubi attach -f 0x80000 -l 0x07EC0000 -w 0x800 -e 0x20000 -s 0x200
scanning 1014 PEBs
........................................................................................................................................d
RedBoot> ubi load -b 0x100000 kernel%{os_backup}
RedBoot> exec -c %{os_cmdline}entry=0x80008000, target=0x80008000
Using base address 0x00100000 and length 0x0013a6d4
Uncompressing Linux..................................................................................... done, booting the kernel.

So it is running a booter called RedBoot. This seems to show the individual image files:

RedBoot> ubi info
Volumes count:                           8
Logical eraseblock size:                 129024
Total amount of logical eraseblocks:     1014 (130830336 bytes)
Amount of available logical eraseblocks: 337 (43481088 bytes)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  10
Current min/mean/max erase counter:      2/5/9
Minimum input/output unit size:          2048 bytes
VID header offset:                       512
-----------------------------------
Volume ID:   0
Type:        static
Alignment:   1
Size:        17 LEBs (2228224 bytes)
Used:        10 LEBs (1287892 bytes)
State:       OK
Name:        kernel
-----------------------------------
Volume ID:   1
Type:        static
Alignment:   1
Size:        114 LEBs (14942208 bytes)
Used:        92 LEBs (11862016 bytes)
State:       OK
Name:        cramfs
-----------------------------------
Volume ID:   4
Type:        dynamic
Alignment:   1
Size:        25 LEBs (3276800 bytes)
State:       OK
Name:        mfgdata
-----------------------------------
Volume ID:   5
Type:        dynamic
Alignment:   1
Size:        261 LEBs (34209792 bytes)
State:       OK
Name:        storage
-----------------------------------
Volume ID:   6
Type:        static
Alignment:   1
Size:        25 LEBs (3276800 bytes)
Used:        10 LEBs (1287892 bytes)
State:       OK
Name:        kernel_sm
-----------------------------------
Volume ID:   7
Type:        static
Alignment:   1
Size:        114 LEBs (14942208 bytes)
Used:        102 LEBs (13033472 bytes)
State:       OK
Name:        cramfs_sm
-----------------------------------
Volume ID:   8
Type:        dynamic
Alignment:   1
Size:        25 LEBs (3276800 bytes)
State:       OK
Name:        usrconf
-----------------------------------
Volume ID:   9
Type:        dynamic
Alignment:   1
Size:        82 LEBs (10747904 bytes)
State:       OK
Name:        logitech
-----------------------------------
Volume ID:   2147479551
Type:        dynamic
Alignment:   0
Size:        0 LEBs (0 bytes)
State:       OK
Name:

Here's the question: Can anyone help me make use of this info? How can I best get the info off the device via this UART cable? I've toyed with the dump command to various levels of success but that is pretty cumbersome just showing typical hex text in the form of 00139E70: F8 13 90 C7 98 3B 7B CF 04 9F 80 E1 9A FF 8B 68 |.....;{........h| which is hard to do anything with. So, any ideas as to how I should proceed? Many thanks.

Update: I've managed to dump (I think) the entire memory, but haven't gotten much out of it with Binwalk. In case anyone else wants to take a look, here it is. https://www.dropbox.com/s/pxpugqpptqc3ph9/data-complete.bin

justin
  • 475
  • 6
  • 13

3 Answers3

2

If you are able to get hex output of the partition data, you can store it in a text file and then convert to a binary. On Linux, the following commands may help:

cat data.txt | cut -d' ' -f2-18 | sed s/\\s//g | tr -d '\n' | xxd -r -p > data.bin
Vladislav Ivanov
  • 619
  • 1
  • 4
  • 14
  • That's much easier than what I was doing but is there an easy way you know of to output that? That's the part I'm having a harder time with. – justin Oct 03 '17 at 15:28
  • What do you mean? You said you have access to dump command; start any terminal client, save the output (example: https://stackoverflow.com/a/11420381/7303703), dump the whole partition to a text file, remove a few first lines and pass that file to a snippet I posted. – Vladislav Ivanov Oct 04 '17 at 06:15
  • I guess I was more trying to figure out if there's a better command than just spewing it on the screen, which takes a considerable amount of time, and if I should just start at 0x000000 and pick some arbitrary number, or if based on what I already pasted there's a way to specifically target i.e. Volume ID 4. – justin Oct 05 '17 at 01:34
  • Have you tried looking for dump command options, like offset and size? The whole storage size in this device can't be that big – Vladislav Ivanov Oct 05 '17 at 06:14
  • It took 18 hours to dump, but I think I got it all.. https://www.dropbox.com/s/pxpugqpptqc3ph9/data-complete.bin binwalk doesn't get much useful info tho, sadly. – justin Oct 22 '17 at 02:43
  • @justin from a quick look I wasn't able to understand partition scheme either, but there are a lot of strings and ARM (LE) function in there, I'd start with loading this whole file into a disassembler – Vladislav Ivanov Oct 22 '17 at 22:17
1

Have you been able to mount any portion of this dump as ubifs ?

$ strings data-complete.bin | grep -i ubi
"console=ttymxc1,115200 noinitrd init=/linuxrc ubi.mtd=1 root=/dev/mtdblock:cramfs%{os_backup} %{os_cmdargs}"
ubi attach -f 0x80000 -l 0x07EC0000 -w 0x800 -e 0x20000 -s 0x200
ubi load -b 0x100000 kernel%{os_backup}
"console=ttymxc1,115200 noinitrd init=/linuxrc ubi.mtd=1 root=/dev/mtdblock:cramfs%{os_backup} %{os_cmdargs}"
ubi attach -f 0x80000 -l 0x07EC0000 -w 0x800 -e 0x20000 -s 0x200
ubi load -b 0x100000 kernel%{os_backup}
*** invalid 'ubi' command: %s
ubi 
*** UBI is not attached
*** UBI is already attached
UBI start address
UBI length
Attach Unsorted Block Image [UBI]
[-f <ubi_addr> -l <ubi_length> -w <write_size> -e <erase_size> -s <subpage_size>]
Detach Unsorted Block Image [UBI]
Display contents of Unsorted Block Image [UBI]
Load image from Unsorted Block Image [UBI] into RAM
Erase an Unsorted Block Image [UBI]
Format using a UBI image
Manage UBI images
node with incompatible UBI version found: this UBI version is %d, image version is %d
this UBI version is %d, image version is %d
bad UBI magic %08lx, should be %08x
ubi attach -f 0x80000 -l 0x07EC0000 -w 0x800 -e 0x20000 -s 0x200
ubi load -b 0x100000 kernel%{os_backup}
"console=ttymxc1,115200 noinitrd init=/linuxrc ubi.mtd=1 root=/dev/mtdblock:cramfs%{os_backup} %{os_cmdargs}"

See for reference:

tibar
  • 375
  • 4
  • 18
0

Until a better solution is found, Perhaps the 'EOL' process can be avoided by blocking this device from access to the outside internet (by blocking it at your router/gateway).

I have done this for an internet-enabled device that I don't trust to access the internet (it still works usefully on my LAN)

Eliot Blennerhassett
  • 1