File: README.txt ------------------------------------------------------------

(c) 2010, Hans-Werner Hilse , http://twitter.com/hilse
All text stuff licenced under CC-BY-SA:
http://creativecommons.org/licenses/by-sa/2.0/

Programs published here are under various licenses. If those licenses require
to publish source code, the sources will either be provided here in the
download section or - this generally means I left them unmodified from their
upstream versions - I'll happily provide you upon request. Just drop me a
mail (see email address above).

Everything here is private and non-commercial. Some of the product and
company descriptions here may contain trademarks. I do not claim any
of these, they belong to their respective owners.

If you were directed directly to the README.txt, you will be missing the
download section. Simply go to http://hilses.de/vip1710 then!
         - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


Hi there!

This is my private file store for things regarding hacking a VOD set top box,
to be more specific: This is all about the VIP 1710, a product by Kreatel
and/or Motorola.

More information about the device might be found here:
http://www.mikrocontroller.net/articles/MOTOROLA_VIP1710 (german)

There's a discussion thread here:
http://www.mikrocontroller.net/topic/pollin-motorola-vip1710


As I got to buy a pair of these for 5 EUR each, I was eager to start hacking.
Now that I finally found some time, I'll share my results here for those
who are interested.

All of this will change when I learn more about this device. But after some
first inspections, I already got very far, I think.


Contents:
=========

1. Make it boot your way
1.1. Preface
1.2. Boot procedure
1.3. getsettingsvalue
1.4. A warning
1.5. The shellcode
1.6. Using the stuff
1.7. Boot flow
1.8. C&P: Making your device USB-bootable (kind of...)
1.9. Overlaying the "real" settings2.xml

2. Taming halserver

3. NFS mounts

4. The native build environment
4.1. Installing
4.2. Using it
4.3. Software provided

5. A LIRC driver for the UIRT
5.1. Driver info
5.2. Usage

6. Notes on the platform

X. Misc stuff

DISCLAIMER / HAFTUNGSAUSSCHLUSS

DOWNLOAD SECTION

                ------------------------------------------


1. Make it boot your way

1.1. Preface

When I started playing with the box, I soon realized that I got one of those
which have onboard flash to store its firmware. Nice, I thought, I can change
it to make it what I want it to be. But that turned out to be (almost!)
impossible, since the box uses some bootloader techniques to ensure a
cryptographic signature for the firmware.

So the flash cannot be touched... Flash is entirely secured by the Bootloader.
Well, not entirely... One small village of indomitable Gauls -- err, no,
different story. What I wanted to say is: there is some space for runtime
configuration data which is preserved and _is_ user-accessible:

The directories /flash (JFFS2) and /flash2.

1.2. Boot procedure

The device uses a classic busybox environment and the init it provides.
This is reading /etc/inittab, which basically does this:

(1) for system initialization, it starts /etc/rc.sysinit
(2) it starts a respawning /bin/sh, I guess on the serial console
(3) it starts the telnet daemon
(4) after system initialization, /usr/bin/start_platform.sh is run

1.3. getsettingsvalue

When examining (1) and therefore /etc/rc.sysinit, there is in fact one single
line which reads configuration from the aforementioned persistent config space:


	# Set time zone
	timezone=""
	if [ -f /flash/settings2.xml ]; then
	  timezone=$(getsettingsvalue /flash/settings2.xml config.timezone)
	fi
	if [ -z "$timezone" ]; then
	  echo "No time zone setting, using UTC"
	  timezone="UTC"
	else
	  echo "Setting time zone $timezone"
	  ln -sf /usr/share/zoneinfo/$timezone /etc/localtime
	fi


Note the line where it's calling "getsettingsvalue".
This is where we will get into things. Soon.

I played a lot around with this binary, peeked and poked, and finally found out
it is some C code, obviously written in a hurry and - lucky us - it's buggy. It
is prone to stack buffer overflows which brings us in the situation to smash
its stack by handing over a carefully crafted /flash/settings2.xml.

Reading such a file will make getsettingsvalue overwrite a return address which
it stored on the stack. After executing its tasks, it will read the address
back and jump there. This is where we get in the way.

1.4. A warning

Please be warned: The following describes modifications that allow for a
permanent change in the boot process of the device. As this happens at an early
stage, it is possible that you make modifications which will effectively brick
the device. This would be the case when you manage to interrupt the boot flow
permanently. This happens easily: Just have anything waiting for input and
that's it. So be very, very careful and _always_ test your scripts before
making them permanent!

1.5. The shellcode

I wrote some shellcode (I learned about MIPS assembler language when I was
examining getsettingsvalue) and crafted a settings2.xml file that does basically:

	execve("/bin/sh", [ "/bin/sh", "/flash2/myrc", NULL ], NULL);

And while it was a ride through hell debugging this stuff on the device (cache
coherency issues were everywhere), I now have a version that is working
reliably. You can find it below among the downloads.

BTW, you can try to test it before bringing it into place. Just download it to
your box and execute "getsettingsvalue /path-to-downloaded-settings.xml test".
It should execute /flash2/myrc then. But you might as well get a signaled abort,
signal would then be SIGILL, i.e. illegal instruction. This is due to cache
coherency issues. It has a tendency to break when the box is otherwise idle.
If you really want to test it out, make the box busy - it's working best when
the box is doing lots of context switches (i.e. userland->kernel->userland)
since this blows out the cache lines more easily. Luckily, upon boot there is
a lot of activity and the exploit has been 100% reliable for me there.

1.6. Using the stuff

In order to use it, just copy it to /flash/settings2.xml. You might need to
delete an existing file and might want to backup it beforehand.

It is of bigger size than nominally fits into /flash, but this is actually not
true because /flash is on a compressed file system. So it should fit. I don't
use /flash for anything else, so it's just this file there.

I also have a corresponding /flash2/myrc shell script. This script is being
called by the shellcode and can do anything I'd like to.

Below you can find an example script that I will use for now for debugging.
It has some dependencies: You need to put kernel modules scsi_mod.o, sd_mod.o
and usb-storage.o into /flash2/modules.

It will load them at boot time, wait 5 seconds for devices to appear (usb
storage devices in case you did not realize from the modules). If there is a
storage device, it will try to mount the first partition to /mnt. It will then
look for a file named "plugrc" and if it exists, /bin/sh is executed with this
script.

This way you can use usb storage devices as a kind of "boot floppy". This
allows to have a flexible boot process, have application-specific storage
devices and boot accordingly. If there's no usb storage device present, the
boot will just continue as usual (so the box will do DHCP and offer telnet
access).

1.7. Boot flow

After execution of /flash2/myrc, /etc/rc.sysinit will just continue the usual
boot process. So you can use this mechanism to make some adaptions to the ram
based root filesystem before the whole kaboodle kicks in (halserver, X server,
browser, ...) and then just let it continue. On the other hand, you can
permanently intercept the boot process by not returning from your script. But
be very, very careful that you keep access to the device, otherwise it will be
bricked. This is why I implemented the "usb storage device way" outlined above.

1.8. C&P: Making your device USB-bootable (kind of...)

The following should make you device usb-bootable (i.e. it will exec 
/plugrc with /bin/sh in early boot process), carefully check if errors
are spewn out and stop by the earliest sign that something might be wrong
(actually compare those MD5SUMs!):

---snip

$ telnet 


BusyBox v1.01 (2007.01.11-16:43+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.


/ # wget http://hilses.de/vip1710/usb-storage-modules.tar
Connecting to hilses.de[62.75.159.166]:80
usb-storage-modules. 100% |**********************************|   187 KB    00:00 ETA
/ # wget http://hilses.de/vip1710/settings-xml--stack-overflow-exploit.bin
Connecting to hilses.de[62.75.159.166]:80
settings-xml--stack- 100% |**********************************|   128 KB    00:00 ETA
/ # wget http://hilses.de/vip1710/myrc                                    
Connecting to hilses.de[62.75.159.166]:80
myrc                 100% |**********************************|   1059      00:00 ETA
/ # md5sum usb-storage-modules.tar 
c9a1422e8b1ad4cd1ac8e8af0732f7d2  usb-storage-modules.tar
/ # md5sum settings-xml--stack-overflow-exploit.bin 
84d6f170d81c4633e6e5623aa986bd3b  settings-xml--stack-overflow-exploit.bin
/ # md5sum myrc 
62dbb9bf6feabe701a8c3785dcbe74bf  myrc
/ # tar -xv -f usb-storage-modules.tar -C /flash2 
modules
modules/scsi_mod.o
modules/sd_mod.o
modules/usb-storage.o
/ # cp myrc /flash2/
/ # mkdir /flash2/flash-overlay
/ # cp /flash/settings2.xml /flash2/flash-overlay/settings2.xml
/ # cp settings-xml--stack-overflow-exploit.bin flash/settings2.xml 
/ # sync
/ #

---snip

Give the box a bit of grace time to really make sure changes are written to
flash. Reset the box, start without any usb storage media plugged in. If you
see a 0-sized file /yes-sir-we-can-boogie then everything went well!

1.9. Overlaying the "real" settings2.xml

I've added a feature to myrc (the version I provide below) that allows to
have the exploited settings2.xml in place during boot up and then having
/flash point to a different place afterwards. This way, you can now
create a directory /flash2/flash-overlay which is bind-mounted to /flash
by the myrc script. You can just put your old settings2.xml into this
directory (i.e. /flash2/flash-overlay) and toish & Co will continue to
work just fine.

I've added the relevant commands to the C&P section in section 1.8. (the
"mkdir /flash2/flash-overlay" and the following "cp")


                ------------------------------------------

2. Taming halserver

This section is a bit shorter than the first :-)
When playing with your own hand-tailored userland, you will stumble upon some
missing bits and pieces.
Some of them, first and foremost: audio support, are provided by the

/usr/bin/halserver

program. It communicates with the Xilleon special device /dev/atyx2200 and
issues the proper commands. We will still have to reverse engineer these.

In the meantime, we can use halserver which knows about the special language of
the mentioned platform device - and provides some standard interfaces for us.
For the technically interested: it uses the "fusion" device, which is a technique
that has its origins at the designers of the directfb gfx lib. The "fusion"
device is a kernel-userland interface and can create further devices from kernel
space which you can then drive from userspace (i.e. userspace implementations
of read(), write(), ioctl(), open(), close()...). It does this for providing 
OSS compatible (except they don't like mono-channel audio) devices for sound
output, implementing the functionality in userspace. Basically it's a rather
ineffective wrapper that goes through at least one unnecessary userland->kernel->
userland step. But that's what we have until we know better how to drive
/dev/atyx2200 on our own behalf.

Unfortunately, halserver also drives the watchdog timer. I say "unfortunately",
because halserver expects a kind of "heartbeat" signal from the userland software
stack supervisor processes. But since this is about _not_ starting the full
userland, there will be no such heartbeat.

In the end, the easiest and quickest (and rather dirty) solution I came up with
was just overriding some libc functions by preloading my own library. In it, I
catch open() and ioctl() calls for the watchdog device and just drop them. This
way, halserver doesn't mess with the watchdog.

You find the library, prevent-halserver-watchdog.so, among the downloads below.
Load it onto your box, make sure it's executable and then start halserver, e.g.
in a script, like this:

   touch /tmp/halsocketname
   LD_PRELOAD=/path/to/prevent-halserver-watchdog.so /usr/bin/halserver -s /tmp/halsocketname &

You might also be interested in how to stop the currently running halserver
which got started during the boot process (if you didn't modify that).
In short, you can use this after logging in:

   killall -9 halserver procman; watchdog -t 5 /dev/misc/watchdog

This will kill halserver and procman (which also triggers reboots in my 
experience) and immediately start up a watchdog userland daemon which serves
the watchdog device.

That's it!


                ------------------------------------------


3. NFS mounts

In the download section you can also find a package nfs.tar.gz which contains
compiled modules and daemons (WARNING: a bit outdated version 1.0.10 of
nfs-utils! Will probably have its security flaws!) to get you going with
mounting NFS exports on the device. It has an initialization script which
loads the modules and starts the daemons. You should get the idea by reading
it. It's in /bin/start-nfs.sh.

To test it (on the device):

---snip

/ # wget http://hilses.de/vip1710/nfs.tar.gz
[...]
/ # tar xvzf nfs.tar.gz
[...]
/ # start-nfs.sh
[...]
/ # mkdir /nfs-mount
/ # mount -t nfs HOST:/export /nfs-mount

---snip



                ------------------------------------------


4. The native build environment

I've finished the boring work of building a native toolchain, running on the
device itself. You can find it in the download section.

4.1. Installing

To use the toolchain, you must use an external usb storage medium or use NFS,
e.g. using the kernel modules provided on this page. I will only explain the
usage of an external usb storage medium here, because I think you can figure
things out for NFS yourself if you managed to set it up :-) Just a short hint
for NFS users: check the "exports" man page for "root squashing" if you are
not yet used to the innards of NFS.

For those of you that decide to use an external USB storage medium, I will
describe the basic steps to get the native build environment running.
BTW, running from USB media has been faster than NFS for me.

First, select the media carefully. I recommend a (spinning) hard disk, not
flash storage. As the latter will certainly work, too, you may be wearing out
the medium if you do lots and lots of writes (and you are a hardcore developer,
right?). Plus, if you want to use swap, you will want this to be on a hard
disk, not flash (for the same reason, basically).

Note: the extracted build environment alone needs about 500 MByte of space.

Then there's bad news: You will need a partition formatted for this. So
what file system to chose? Personally, I went with ext2. This is easy, since
the kernel running on the box already has ext2 support. Another option would
be jfs. A jfs kernel module (to be put in /lib/modules and then insmod'ed
with "insmod jfs") is provided in the download section. Use this if you are
a lazy plug-puller and always forget to remount the drive read-only and sync
before pulling DC - you will be thankful for a logging file system.

Obviously, you will need to format the drive either from a running Linux
system (you could use a live CD, perhaps?) or with some obscure and unknown-
to-the-author other tools on your OS of choice.

Then you simple un'tar the archive file provided in the download section
onto the new filesystem (which you have mounted):

# mount /dev/sdb1 /mnt
# cd /mnt
# tar xvJf /home/user/downloads/vip1710-native-build-environment.tar.xz

That's it.

Note that if you use a harddisk, you should use the opportunity and create
a swap partition. OTOH, you can always create a swapfile later. How to use
a swap partition or file is beyond the scope of this document. But inform
yourself about "mkswap", "swapon", "swapoff" commands (and "losetup" if you
intend to use a swap file).

4.2. Using it

First: The build environment contains a few files that integrate with the
"myrc" provided on this page (also read its documentation above). You do not
have to use this "myrc", though. But if you do, here are some notes:
it will use the infrastructure consisting of plugrc{,.d,.conf} files. They
will make the box start up with just a minimal set of binaries running.
Also they will set the IP address according to the configuration in
"plugrc.conf". Make sure to give it a look and edit it to your needs!

Regardless of whether you use my "myrc", here is how it works:

$ telnet 
[...]

then, if you use my myrc, /mnt already is a read-only mount, you'll do:

# mount -o remount,rw,noatime /mnt

if OTOH you don't use my myrc, you might need to load jfs modules, then,
for jfs and ext2, do (adapt device/partition if needed):

# mount -o noatime,rw /dev/scsi/host0/bus0/target0/lun0/part1 /mnt

and then all you have to do is this

# /mnt/chroot.sh

You will then be in a chroot environment which provides you with gcc&Co.
Note that GNU Screen is provided for creating sessions which keep running
even if you log out of the box. After logging in again later, just call
the /mnt/chroot.sh script and then re-attach the Screen session. Read
about GNU Screen if you don't know it already - it helps in a lot of
cases.

Now "./configure; make; make install" as you like!

4.3. Software provided

Here is a list of software that is provided within the build environment.
I will add links to the project pages. Note that not a single source
was patched (all my work was starting the compiler, over and over again),
so if you're interested in the source, look up the project. Links on this
page is coming soon. If in doubt, look at GNU: most of the tools are GNU
tools. (Please note the comment on top of this page: If you want, you can
always drop me a mail and I can provide you with the source code!)

So here's the list, I've highlighted some things I considered important:
	apr-1.4.2
	apr-util-1.3.9
*	autoconf-2.66
*	automake-1.9.6
*	bash-4.1
	bc-1.06
*	binutils-2.20.1
	bison-2.4.2
	bzip2-1.0.5
*	ccache-3.0.1
	coreutils-8.5
	cpio-2.11
	curl-7.21.0
*	cvs-1.11.23
	diffutils-3.0
	ed-1.4
	expat-2.0.1
	findutils-4.2.29
	flex-2.5.35
	gawk-3.1.8
*	gcc-3.4.6
*	gdb-7.1
	gettext-0.18.1.1
*	git-1.7.2.1
	gmp-5.0.1
	grep-2.6.3
	gzip-1.4
	inetutils-1.8
	iproute2-2.6.34
*	iptables-1.4.8
*	jfsutils-1.1.14
	jpeg-8b
	less-418
	libelf-0.8.13
	libtool-2.2.10
	m4-1.4.9
*	make-3.81
	ncurses-5.7
*	openssh-5.5p1
*	openssl-1.0.0a
	patch-2.6.1
*	perl-5.12.1
	pkg-config-0.25
*	Python-2.7
	readline-6.1
*	scons-1.3.1
*	screen-4.0.3
*	SDL-1.2.14
	serf-0.6.1
	sharutils-4.9
	sqlite-3.7.0
*	subversion-1.6.12
	tar-1.23
	termcap-1.3.1
	termutils-2.0
	time-1.7
	unzip60
	util-linux-ng-2.18
*	vim72
	wget-1.12
	xz-4.999.9beta

Now, I hope I did not forget about something. Please notify me if you
think something is missing in this list!

Please respect the licenses of the software, included in the tarball.

Please note I used unmodified upstream sources. I also provide a download
mirror for them here: http://gpl.hilses.de/vip1710/upstream-mirrored but I
would suggest to use the current upstream sources. Include files and libraries
are contained within the build environment tarball anyway.


                ------------------------------------------


5. A LIRC driver for the UIRT

The VIP1710 has a built-in Infrared receiver. The ATI Xilleon platform
contains a "UIRT", a Universal Infrared Receiver/Transmitter. There are
ATI Xilleon platforms which have more of them, however. I do not have
access to such a platform, so the driver provided here will most probably
be broken on such devices. If you want to adapt the driver to such a
platform, feel free to contact me for discussing what would be needed.

The UIRT also provides means for transmitting IR, as the name indicates.
It would not be too hard to implement the transmission in the driver,
however I did not do that yet. So the driver is currently *RX only*!
This has a simple reason: The VIP1710, at least the model I have here,
does not provide a IR transmission diode. I did not yet investigate
whether contacts for soldering one are provided. Another possibility
would possibly be to use the status LED for this (of course we would
have to de-solder it and solder in a IR diode). However, this might never
work, so I chose to not bother yet with TX.

5.1. Driver info

As the sources for the kernel are currently Linux 2.4, I had to use
an outdated version of LIRC. So it's version 0.8.2, which is said to be
the last version which officially supported Linux 2.4.

The driver uses the lirc_dev framework, so you will have to compile
this driver too (or use the ready compiled module).

Then there's driver/lirc_xilleon which contains the Xilleon-specific
code. I followed the steps taken in the lirc_serial driver, but since
we will only do RX for now and the UIRT does RLE encoding of pulses and
spaces for us, it is much simpler.

The driver is interrupt-triggered. It will generate one interrupt per
N samples, where N is configurable. Also it knows a means to timeout,
but that isn't really used for now. You can however set those as
module parameters.

You can also set the duration of a single sample interval (note that
the UIRT returns RLE encoded values anyway, so it defaults to a fine
resolution of 50us currently).

Note that the source is provided as a patch against LIRC 0.8.2
(which is also provided in the ZIP, compressed with XZ). You will
need to run "aclocal; autoconf; automake --add-missing" in order
to rectify the autotools scripts (so you'll need autoconf/automake!).
In order to use it with libtools >= 2.0 I also had to switch
"libtool" and "ltmain.sh" to the system versions.

5.2. Usage

Note that in order to use this infrared driver, the vendor driver
must be unloaded! To do this, "rmmod 08ir" (and most probably you
will have no use for the "07kb" driver, either).

Install the modules and binaries, e.g. simply by downloading the
.tar.bz2 file below and un-tar it in the tmpfs root of the device.

Then just insmod lirc_dev and lirc_xilleon!

Use irrecord to learn codes, mode2 to print raw mode2 values,
lircd as the daemon etc. See the many HOWTOs on the Web.
For a fast check if it works, simply run "mode2 -d /dev/lirc/0" and
press a button on your IR remote control of choice.

lirc_xilleon also has module parameters:
debug:
	set this to 1 to generate lots of debug output
sample_div:
	this is the sample duration in N/48 us. Defaults 
	to 2400, which is 50us.
timeout:
	I could still not make sense of the unit this is in.
	Defaults to 1000 which seems to work here...
fifo_threshold:
	How many RLE samples in the FIFO to trigger interrupt,
	defaults to 4
                
Play with them as you like and have fun!


                ------------------------------------------


6. Notes on the platform

In this section I will collect some notes on the platform. Hopefully this
will help others to get started with hacking on it.

6.1. Streaming with the userland tools

The "toish" shell can invoke some Ipc calls to the vendor userland software
stack. For me the most important one is probably

  toish uri LoadUri  

Streaming needs a running X server, halserver, streamer, mediamanager and
maybe others.

Possible URIs are
- http://...  gets TS or PS via HTTP
- file://...  gets TS or PS (try name appendix ".ts", ".mpg") from file
              or from a named pipe (!)
- tcp://: gets TS or PES(?) or PS(?) from a raw TCP connection
              will auto-retry for a while when stream is cut
- udp://: listens for UDP packages containing TS data on a
              certain /
- igmp://: does probably the same. Don't know yet if it properly
              registers a IGMP multicast address, though. But listening
              on multicast addresses works.
- rtsp://: did not yet get it to work, but this will ask a
             RTSP server for an RTP stream
- more...?

Possible Mime-Types are
- video/mpeg is tested, works for MPEG data (TS/PS/PES)
- maybe others, there's a list of MIME-Types registered in tvvod by
  streamer, it's in /usr/application/vod, I think (TODO: verify).


                ------------------------------------------


X. Misc stuff

Audio:
(note that you will want to have halserver running, see above section 2!)

- There's a compiled esound for you, i.e. esd & co. It's from unmodified
  0.2.41.

- There's a compiled sox for you, i.e. sox, play, rec. It's from unmodified
  upstream version v14.3.1

Filesystem:

- There's a JFS file system kernel module for you. Note that it's untested,
  if it works for you, I'd like to hear about it!

- Upon a request, I compiled a version of the CIFS network filesystem for
  accessing Samba servers. It's a bit outdated (1.20c backport for Linux 2.4),
  but it works for me. In the archive, a version of mount.cifs is provided,
  too.

- I packaged Samba 3.5.4 and nfs-utils 1.2.2 as a convenience package.
  It's prepared to be used together with the settings2.xml exploit and
  will start Samba and NFS upon boot. Note that the samba executables are
  rather big. The package is called nas-vip1710.zip, and to use it, copy
  the contents of the contained "nas-vip1710" directory to the root of a vfat
  formatted partition on a USB hard disk (or flash stick).

Gaming:

- There's a joydev.o kernel module for you.

- gnuboy-1.0.3.directfb.tar.xz contains gnuboy-1.0.3 sources which are
  modified to also support directfb output and esound output. They contain
  a readily made dfbesdgnuboy executable which is capable of running on
  the VIP1710. Make sure you have halserver and esound running (see section
  on halserver above and have a look at the provided esound archive in the
  download section). Also you need to use the joydev kernel module and
  insmod it. Then run

  ./dfbesdgnuboy --joy_device=/dev/input/js0 --scale=3 

  I think it's still a bit too slow due to PAL refresh rates (the box only
  does 25 (!) fps when it comes to waiting for vertical retraces). When running,
  it takes about 50% CPU.

- For example purposes, I also built a "USB stick distro" of GnuBoy. You
  can download it below in the download section. Also its sources are provided,
  which you might be interested in if you need e.g. a working DFBTerm for
  your box (which I also made USB-gamepad ready!).

  For installing this mini-distro, you need to put only two files from the
  ZIP onto a USB stick or harddrive, which may be VFAT or ext2 formatted:
  "plugrc" and "hwsdist-root.tar.bz2". Also, you will want to create a
  directory for your ROMs, which must be named "roms-gnuboy". Put all your
  ROMs in there.

  The distro is meant to be used with the myrc script provided here.
  Just plug in a USB Hub with your gamepad and the prepared USB stick/HD and
  power on the device. It should eventually present a menu which you should
  be able to navigate using your game pad. You should still be able to log
  in using telnet, but it will not start the normal STB environment.

  If you're not using my myrc script, you should anyway be able to use the 
  provided programs by mounting the stick to /mnt, then run /mnt/plugrc and
  after that, run /usr/bin/start_platform.sh (which will be replaced by
  plugrc)

Various:

- I started writing a small app for toggling LED status which will possibly
  in the future also provide some other functionality. Thus the name
  "kboxctl". You can find it compiled and its C source in the archive
  kboxctl.tar.bz2

- Also, I started writing a VNC server for DirectFB. It is currently tailored
  for a 720x576 @ ARGB32 DirectFB framebuffer. It does not do any
  double-buffering and comes with a hack that will make all pixels transparent
  if a full black frame is sent by the server. This allows to use it as
  OSD display for VDR with the ffnetdev-plugin.
  You invoke it like this: "vipvnc server:port".
  It does not yet support input, maybe it never will. Thus it is only capable
  of displaying!

  For use with the ffnetdev-plugin, you should for now use the provided LIRC
  solution and use LIRC's client/server functionality. Works great for me.
  Then you can start the stream with
    toish uri LoadUri tcp://:20002 video/mpeg
  and fire up vipvnc for the OSD with
    vipvnc :20001
  However, the ffnetdev-plugin is old and it has been very unstable for me.
  Might be the network here, too, I'm not sure yet and this is definately
  an experimental WIP project which I might never finish.

  Oh, and one thing: I had to increase the amount of video data buffered
  by the streamer process, it can be configured in /etc/streamer_conf.xml
  and 500ms worked for me. (this applies to the video data, not VNC)

- I finished an early try to implement a plugin for VDR to have VDR run
  on the box itself. Combined with streamdev-client, this allows to watch
  TV, using some other VDR on the LAN to provide the actual DVB data
  (using streamdev-server).
  The plugin will use DirectFB to provide a full-color OSD, with perfect
  Alpha blending.
  It has been updated since initial publication and now supports playback
  of recordings, too. Said that, fast-forward and rewind is not supported yet,
  which means you have to use jumping instead.
  Setting of volume and setting of the Scart output's wide-screen signalling
  is supported now, too.

  You find a full minidistro (intended for use on USB media and with the
  settings2.xml hack together with the myrc file I provide) among the
  downloads below. Extract the ZIP and copy all files in the distro folder
  to the root of your USB media FS. Have it plugged in when booting the box.

  The Minidistro will load LIRC modules for the UIRT, but you need to set
  up a remote first. In order to do that, log in via telnet and do

    irrecord -d /dev/lirc/0 /mnt/etc/lirc.conf

  and follow the steps indicated. Then edit plugrc on the USB media and
  comment in the autostart procedure in the last line (if you want to
  autostart it, for testing issue the commands manually).

  You will most probably use this with the included (and automatically loaded)
  streamdev-client plugin. So you will have to configure this and copy a
  channels.conf file in /etc/vdr on the USB media. Copying over the
  channels.conf from the VDR that has the streamdev-server running should be
  sufficient. You can configure the IP of the remote server in the plugin
  settings within VDR.

  You can find the source for the plugin in the directory
  vdr-vip1710-minidistro.src in the download section below.

- For figuring out what the box' vendor software stack does, I wrote a
  small utility which can dump unix domain socket communication. This will
  allow you to see the messages the individual programs are passing to
  each other (they do IPC by these means). You can find it in the
  sockdump package, and its source is here: http://hilses.de/sockdump

- To issue IPC calls to the vendor software stack (or receive IPC calls from
  the vendor software stack) I wrote a C library, libvipipcstack. It's now
  in the folder libvipipcstack below and comes with a documentation on the
  IPC stack.


                ------------------------------------------


DISCLAIMER:

PLEASE NOTE THAT YOU MAY USE THESE FILES FOR WHATEVER YOU THING MIGHT FIT, BUT
I DO NOT GUARANTEE FOR ANYTHING. IF YOUR BOX WENT AFLAME, EXPLODED, BURNED YOUR
HOUSE DOWN: I WARNED YOU. THIS IS ALL DONE WITH GOOD WILL AND I DO NOT INTEND
EVIL, BUT I DO NOT GIVE ANY GUARANTEES.


HAFTUNGSAUSSCHLUSS:

DIE FOLGENDEN DATEIEN WERDEN VON MIR BEREITGESTELLT UND DUERFEN VERWENDET
WERDEN WOZU AUCH IMMER ES BELIEBT. ICH GARANTIERE ABER FUER NICHTS UND
SCHLIESSE AUSDRUECKLICH JEDE HAFTUNG AUS, SO WEIT MOEGLICH. DIESE DATEIEN
WURDEN NACH BESTEM WISSEN UND GEWISSEN ERSTELLT UND BEABSICHTIGEN KEINERLEI
SCHAEDIGUNG.