AltEPG

Excuse the scrabby format of this post; it is being written as I find things, rather than being an actual narrative. Whilst I've been waiting until I can get back upstairs to have a go at swapping disc images and version numbers, I've been having a poke about inside the tivo software from the comfort of my laptop..!

So ... Some notes on how 2.5.5 communicates with the server, EPG responses, etc.

On the TiVo end, operations seem to be run from /tvlib/tcl/tv/SvrResp.itcl

The http posts to /tivo-service/TCD411.cgi and /tivo-service/HServer.cgi (include the software version number, among other things.

The response to the latter includes a parameter SW_LIST=&url chksum#0x00..00|&url chksum#0x00..00 etc

Checksums can be omitted and SvrResp.itcl will cope.

On a standard daily call, this is a list of slices and scripts.. It can also include system messages, etc. The tivo connects to each URL in turn and fetches the files. (&url = GET from url, @url = POST url. See CmdStr.itcl)

Scripts end .runme, and come with a .sig file. These are run first before anything else is processed.

.sigs are the signature that is passed to the tivo crypto prog. if it doesn't pass, script is not executed
(SvrResp line 1280)
Crypto prog is /tvbin/crypto
Public key is at /tvlib/misc/service-v3-s.pub
(These are identical on my two networked tivos, but they share a history so this is not conclusive)

If slice files have .sigs they are checked against keyfiles, but no fault is raised if they do not have them.

So it seems "runme" scripts are the only downloaded things require signing.

Now. How to get something onto the tivo that can be run but is not signed.

If a file is downloaded that has the .bnd extension, it is unbundled first (line 1318)

The unbundle code (/tvlib/tcl/tv/unbundler.tcl) runs the file through cpio to do this. (line 47)

cpio supports absolute path names in the archive.

I think this means that by supplying a .bnd archive to the tivo that includes an absolute pathname it is possible to place a file anywhere on the tivo.

I have tested this by running cpio with the same parameters from the bash shell, dropping files into /var/tmp

Can anybody testing the replacement server construct a suitable bundle file and test this?

One complication is that cpio as it's used will not overwrite an existing file.
- unless it's newer?

However a file can be dropped into anywhere that scripts are run from.

My first thought was to just drop in an /etc/rc.d/rc.sysinit.author (as unmodified boxes will not have this) but / will not be writable. So need to find somewhere else that we can put a file that will be run at some point.

/var (and /proc) are the only partitions mounted writeable. Must be something else in there that scans and runs things!

Lots more scripts to peruse ... but has anybody else had a look at this side of things?

Food for thought:


First off: the big problem here is un-modded boxes. However, the initial people signing up are likely to be those who have tweaked their boxes in some way.

One method I've used in the past is to have a master script (i.e. a call from rc.sysinit.author to another script). The secondary script looks too see if there are other items to run. If there are, it runs them and then removes them if they've been successful. This means that the update only has to plonk files in the "third" area for the secondary script to run.

For example:

rc.sysinit.author
-------------------
:
/var/hack/CheckForOtherThings
:


/var/hack/CheckForOtherThings
---------------------------------------
Look in /var/NewEPG/ScriptedUpdates
If there are files there, run them one by one
Remove each file that was successful.


Daily update just dumps a file in /var/NewEPG/ScriptedUpdates. Benefit here is that the "secondary script" can be updated itself by updates as well.

In the implementations I've done before there are also sequencing and sanity conventions - for example, run A->B->C. Stop if B fails and make A rollback what it's done.

Yups. That's the way to do it.

The tricky bit is, as you say, to get code onto an unmodified box - I'm thinking of ways to introduce a script that does the software mods required on a daily call: The couple of attempts I've made in trying to get TiVo to send me an update haven't worked yet, but that was on the unsubbed box. I want to try it from the subbed one as soon as I can get the time upstairs again, but in the meantime I was just poking about via telnet to see what might be going on. I'm a little worried that the upgrade system will be signed like the runme files are, which will be a bugger. I was looking for alternatives that didn't involve trying to brute-force the key..

The modified boxes are not an issue at all, it's handling an unhacked box that's the problem.

I can think of only two ways of doing it. Either:

- drop a file somewhere (e.g. /var/tmp) and execute it. But how can it be executed? Would need to edit rc.sysinit. Or find out how the TiVo runs downloaded files.

- get a bash shell running. This can then be used from the serial port for file injection/execution.


Does an unhacked tivo run rc.sysinit.author? If so then if we can drop that file (containing run bash) then we're in But as you say root is read-only so...

I don't suppose TiVo would be willing to sign one script for us? That is all we would need!

If they would sign a script, I would probably make it a replacement for /tvlib/tcl/tv/SvrResp.itcl which would add another signed script file extension, with a signing key under our control.

Any chance TiVo would support our effort to keep our TiVo's running enough to sign that one script with their key?

I asked them if they would allow us a system message but I got a polite "No"
but maybe something more discrete like that might work?

Sorted !!!!

I can send a standard TiVo any random unsigned script, and get it to execute it!

...Now, it's up to somebody to write a script that will do the necessary updates to a standard tivo to make it work with the new server...

Oh my, that is sweet. Time to try that on our machines. Even just being able to push out timezone file changes makes that so cool.

Cool. So how does this work in practice then?

tyVO connects to new epg server and a .bnd file is downloaded as part of the daily slice, which is then automatically executed?

What does the downloaded file contain - the above code?

It's even easier than that - you just add the script you want to the list of files that are to be downloaded, but add the relevant commands to the end of the URL to force it's execution ..


I've had a concerned PM from somebody worried that TiVo Inc might push out an update to block this. This is a concern. What I don't know is if this vulnerability exists in all versions of the software (they are quite a few versions in front now, on current US models) or if they already fixed it, nor if they are interested in these old boxes running unfixed versions. Remember it can only be instigated by the server, not run on the boxes themselves.

I could remove the details in my post, of course, but don't have access to moderate the quotes.. Dave? What do you think?

Probably a good call, after-all, the tivo hacking ethos has always been about providing tools and hacks to allow us to achieve all sorts of things with the exception of Service circumvention.

healeydave wrote:Probably a good call, after-all, the tivo hacking ethos has always been about providing tools and hacks to allow us to achieve all sorts of things with the exception of Service circumvention.

OK. Pulled the full and exciting details from my blog as well...

@irrelevant

Nice work. That's a pretty amazing "hole" (I saw the post before you cleared it).

Once I know what we need to do to "convert" a TiVo, I can have a tinker with a script. I'd quite enjoy doing that.

@irrelevant - do you have your own server acting as a mothership to test this? I'd love to do some pre-testing to get some basic scripts together (as per my earlier post).

I just had a fantasy five minutes of getting hacks onto non-hacked TiVos via a screen menu system.