FreeAgent Theater and GoFlexTV

[ssybesma]

Hello all,

This 1.55 version looks to be quite a bit different (I've heard because of the Netflix stuff in it). I have to admit, I did buy my device with Netflix in mind

but didn't realize I had to give Netflix exclusive use of my box to do that. (I didn't knowingly say they could have it.)

Got my live Debian lenny CD going and was able to download the 1.55 version, unzip the image file, and then un-tar it.

This is the result I came up with (there are two more items total than what was shown by Playdude on the standard 1.26 firmware version - the 3

yaffs image files are not there but there are 5 other items besides for a total of 17); items in bold are new as compared to the older versions:

==========

./video_firmware.install.bin
./package2
./package2/usr.local.etc.tar.bz2
./package2/bluecore.audio.aes
./package2/squashfs3.img.aes
./package2/squashfs1.img.aes
./package2/vmlinux.develop.avhdd.mars.nand.bin.aes
./package2/bootloader.tar
./package2/video_firmware.bin.aes
./nandwrite
./mkyaffs2image
./mkfs.jffs2
./install_a
./flash_erase
./configuration.xml
./audio_firmware.install.bin
./arial.ttf

==========

Note on two AES files above in bold...these are encrypted using AES Crypt...see: http://www.aescrypt.com/

So, trying to mod 1.55  could be a nearly hopeless endeavor unless someone has the encryption key.

==========

For the "configuration.xml" file (below) I see several references to "rsa" that I didn't see at all in the 1.26 version of that file (again, dealing with encryption):

<?xml version="1.0" encoding="ISO-8859-1" ?>
<packageFile>
    <info>
        <company>Realtek Semiconductor Corp.</company>
        <description>This image file contains 2 Mars packages. One is for AVHDD on NOR and the other is for AVHDD on NAND.</description>
        <version>0.0.1</version>
        <releaseDate>04/03/10 00:28</releaseDate>
        <signature>MARS AVHDD on NOR or NAND</signature>
    </info>
    <installerAP>
        <fileName>install_a</fileName>
    </installerAP>
    <package secureboot="y">
        <info>
            <description>This is Mars AVHDD on NAND</description>
            <version>N/A</version>
        </info>
        <nand>
            <image type="linuxKernel">
                <fileName>package2/vmlinux.develop.avhdd.mars.nand.bin.aes</fileName>
                <targetAddress>0x80100000</targetAddress>
                <version>SVN:</version>
                <marssha1_rsa_hashValue>7583340ca3ea34018342755fd7b795b67217e6c9ce4a912dd719f241bbc0de952c2a06ca60d55d764bce0a65025dc9bef9ca67af18d9cbb675ccf0b0c3fdf8b1100c1d59de548500d44f98b06bece64a61867a77ad80322914214408dea62c2b1555e
72a55f2bbd3c0833b499bf95747e4e7bc1ff8fa3e965a0ce8a424c34889</marssha1_rsa_hashValue>
            </image>
            <image type="audioKernel">
                <fileName>package2/bluecore.audio.aes</fileName>
                <targetAddress>0x81b00000</targetAddress>
                <version>N/A</version>
                <marssha1_rsa_hashValue>134490850fd2d48cd4a9428e0f745c04c54a267af5916ac9994ce89d43b11337207b49a92cc626a1729f7532dc3c2d5741cca75ff11fa5e77a210c14dccf2ca7706bf93354a5399c0d96d93bc7d3ad7168942b252aeb5bfd98bf1a3188efa19a33768
ff901298bd4640926a9472e05abef68c0f1ff8d523bd1132c4f0aa0c1b8</marssha1_rsa_hashValue>
            </image>
            <image type="videoKernel">
                <fileName>package2/video_firmware.bin.aes</fileName>
                <targetAddress>0x81d80000</targetAddress>
                <version>N/A</version>
                <marssha1_rsa_hashValue>c33e5e25a9d330b16e72a74514a3f830db8a03e908fb405552c1cf377a0a45175021dc64b42e044fb5e84e4424c8030fde6cd8cf58e2ffae46cd427b51cee2abd554a3c588c7da31b609c4ddd4793752b26bf73a7f396181be74220f24f9e52b6f3e7
2b8cd203289cbdcb7c7f87741d4d5d8b0f4a6461a5e647db11870ea0f74</marssha1_rsa_hashValue>
            </image>
            <image type="bootloader">
                <fileName>package2/bootloader.tar</fileName>
                <version>N/A</version>
            </image>
            <image type="squash">
                <fileName>package2/squashfs1.img.aes</fileName>
                <mountPoint>/</mountPoint>
                <marssha1_rsa_hashValue>5aa0a5e3df883ea499deb590aa9e89481166f0be93253d0191a59e064deb364b70b561f2edf2ed010932f95d594a5900d643808ad631a95a6aa3ec9108ea98d39e783ce30324180e1f69a0af7c7dd95f6a2fa440fc50015abb54737f8c24d14868b44
6fe846f19bbcf8cb787efc6583b0caba5435784e93c4f4c85dc280359a2</marssha1_rsa_hashValue>
            </image>
            <image type="yaffs2">
                <fileName>package2/usr.local.etc.tar.bz2</fileName>
                <mountPoint>/usr/local/etc</mountPoint>
                <sizeBytesMin>0x3C00000</sizeBytesMin>
            </image>
            <image type="squash">
                <fileName>package2/squashfs3.img.aes</fileName>
                <mountPoint>/usr/local/Resource</mountPoint>
            </image>
        </nand>
    </package>
</packageFile>

==========

I came to the conclusion the modded 1.45 versions might be the last there will ever be.

There could be a way to edit the shell script file in his to force the flashing command to backflash from 1.55 to 1.45

I'm convinced that that can be done. It's all in how the flasher is executed. I used to do the same thing with IBM firmware packages

I used to put together for their servers where I had to have a command line force the firmware back to an earlier version.

Then if I want to use Netflix, I would have to reflash to 1.55, then back to 1.45 if I want to take advantage

of the extra capabilities again...kind of a messy solution, but at least I could have the best of both worlds.

More to come...

[wig_out]

I am glad you are looking into all of this. Perhaps you'll find something new.

Since the earliest firmware, Seagate has been encrypting their video firmware, audio firmware and the kernel.

With the latest firmware Seagate encrypted their Resource directory and the root filesystem.

They also changed the rescue kernel, and perhaps settings and/or portions of the Realtek Rom Monitor (a significantly cut down, modified YAMON Rom Monitor). That's what's happening with the bootloader.tar section.

What this means is that from here on out, there's three principle hopes for getting into firmware 1.55 flashed fat+:

1. Some breakthrough on the serial cable connection. As of now, the serial console remains locked to input, meaning that while you can "watch" the serial console, you cannot enter any commands there.
2. Someone reverses the stock password from the /etc/passwd file: $1$CYIUjf8S$qmFTebTkQEEyoRreGEq4S . Here's the entire line for good measure: root:$1$CYIUjf8S$qmFTebTkQEEyoRreGEq4S/:0:0:root::/bin/sh .
3. Someone tricks fw 1.55 into accepting a new firmware update- by altering the configuration.xml file, swapping out the install_a, etc., AND/OR utilizing some liveupdate url based workaround to accomplish the same.

The most hopeful one is the last, based on the fact that two people mentioned downgrading from fw 1.55 by way the liveupdate url- one was a brand new person who seemed otherwise rather competent, but as he/she was new and never returned, there's some question about which firmware was actually downgraded from... who can say what the precise details were there. The other came a member who'd shown that he knew he was way around the fat+ and other devices. Presumably he knew what he was talking about when he said he downgraded from fw 1.55, but as he firmly stated he wouldn't share details on it, that is apparently that.

Anyway, hope you have some luck. Oh, you might try your luck at some other forums, other eyes on the problems you know.

-wig_out

[ssybesma]

I apologize for editing my post this morning before I noticed that you replied. I changed the direction of it completely away from modding 1.55 to backflashing from it to 1.45.

[ssybesma]

Been working with the unyaffs application and opening up the img files in Playdude's last mod release.

I'm trying to find the ".sh" (shell script) file that executes the flash.

Does anyone know where this file is located or how the flashing mechanism works as a command?

I suspect that it executes from the installed firmware on the device unless the cold method is executed, then it executes off the image file on the USB.

But in order to backflash I have to find the script file on the flash drive to change the command line to force it, otherwise by default it will detect and

not override the newer version on the device.

When I extracted the "yaffs2_1.img" file, I found a boot.img file located in /usr/local/firmware that I suspect contains the shell script I'm looking for.

Just looking to see if I can open that file.

Thanks,

Steve

[wig_out]

You could find a lot of good background info over on: minimodding.com

Generally speaking, loader_a is the executable that starts the install process. It then hands things off to install_a from the firmware file, install.img which does most of the installation.

As for scripts, the configuration.xml file from the install.img hands off a lot of vital information to install_a-- however they are related to one another. Some changes to the configuration.xml will be rejected by the install_a, even though such changes may have worked with a previous firmware. In some cases, people have had success swapping out older install_a's, from previous firmwares, to accomplish their mods.

When you use the "cold boot" you're triggering the "rescue" kernel. That's a second, minimal kernel just to save your device when things go wrong. loader_a is running like a watchdog application when you boot up the rescue kernel, whenever you plug in a usb drive it will search its root directory for an install.img and get started with installing the firmware.

The latest firmware, 1.55, replaced the rescue kernel by way of the bootloader.tar. So, previously observed behaviour there may no longer be true.

I guess that's all I got.

Good luck,

wig_out

[ssybesma]

OK, thanks. So where is this "loader_a" application in all this?

Is there still a script involved where a flashing command line is executed (that could be easily edited) or is the command built into the binary?

Still seems like that stuff could be bypassed somehow and just go straight for some kind of boot.sh that handles flashing.

[wig_out]

/usr/sbin/loader_a

There's no simple script that I am aware of. It's all compiled as near as I can tell.

-wig_out

[ssybesma]

In the latest (1.45) modded INSTALL.IMG file, this is the path to the file I'm asking about...

(INSTALL.IMG opened with 7zip)

package2/yaffs2_1.img ...

...then, upon un-YAFFS'ing the above-mentioned IMG file, look in:

/usr/local/firmware/boot.img (160kB in size)

I would just like to know what format that BOOT.IMG file is in.

TrID (http://mark0.net/soft-trid-e.html) seems to think it's Macbinary. I don't know of any better utility to identify what the compression format of a file is.

Nothing I've tried to use so far can touch it.

It seems there could be something in there that would be useful to boot the FAT+, maybe more.

[ssybesma]

---

wig_out wrote:

/usr/sbin/loader_a

There's no simple script that I am aware of. It's all compiled as near as I can tell.

-wig_out

---

OK, thanks wig

[wig_out]

I've always wondered what that was. An examination of the strings of that file aren't terribly revealing to me. It seems like it's something to do with wireless network connections..... I don't think it's the answer. Of course I haven't found the answer yet so I wouldn't know it when I found it I suppose.

If you want to go done this road, you might examine the gpl source code released by Seagate and other manufacturers utilizing the rtd1073dd, or realtek 1073dd SoC.

Understand that all such gpl releases have been incomplete and often quite of date, however.....

-wigout