Don't forget Joe Public

[garysargent]

I guess one potential option is to look at what unix services TiVo is running. Since these would be very old there may be some security exploits that could be used.

That is - change TiVo to use new dial up, once connected an exploit is used to gain root access to the TiVo box, and the scripts on the TiVo box are then modified to run a call omiting the decryption etc.

Slim chance of getting that to work though!

[LarryDavidJr]

I suppose its a long shot but does anyone know how many bits encryption it was using? If its at the lower end (no more than approx 56 bit) then brute force might not be out of the question ... esp with cloud availability (Amazon lets you have a free use of a micro linux instance).

[irrelevant]

I'm casting my mind back about six years now, when I last was poking about inside how the TiVo downloaded it's guide data, but just because the guide data is currently encrypted doesn't necessarily mean that it needs to be encrypted.

Certainly I think we might only need to support a subset of the server side of things: I don't think anybody is going to be wanting to collect and collate all the viewing data, etc.

To a large part it depends on how the conversation between client & server is conducted. I'll try and dig into this a bit today.

Edit: Certainly one of the first the tivo did after downloading an encrtyped file was decrypt it - I managed to hook into this at one point to capture the slice data for transfer to another machine.

[LarryDavidJr]

That's a good point. It might take unencrypted data if 'given' it in the right way so to speak.

This is all good theory, I just wish I had the time to investigate some of it myself :S

[swuk]

Regarding the crypto - it all depends on how they've implemented it. It might be a randomly generated session key, created for each dial-up session. The strength of which may even have changed over the years, if they could be bothered.

If it's a fixed shared key, then it's just a case of finding it.

Of course, that only needs to be broken if it's necessary to analyse the conversation with their servers.

[Ant]

FYI you can 100% definitely add a different phone number to the dial prefix and TiVo will call it just fine. We have done this in the past - when the 0800 number stopped working we could change to use an 0845 backup number by placing the whole number in the dial prefix field.

You'd need to make it dial a private dial-up service where you can have a server that has the same IP address as the TiVo one (or use something like NAT to translate the address to another one).

This would be the easiest route for non-techies, though as others have pointed out emulating the full service would be difficult - mainly because of the blowfish encryption.

If you can put a whole number in the prefix field then that sounds hopeful - does TiVo try to authenticate with a particular username/password, do you know? (In any case I assume that there are a few 0845 ISPs who accept whatever credentials you happen to specify.)

On the issue of TiVo wanting its guide data from a specific IP address, presumably this CAN be changed by an update down the line during the daily call - so if those instructions can be spoofed that opens two possible options, either of a 'new dialup number' which just connects to a closed system pretending to be the ISP and TiVo server in one, and is used by ALL users for ALL daily calls, OR a similar 'one shot' dialup number which could do nothing other than inform any connecting TiVos that the new daily call number is 0845-BT-Click and the new server address is 1.2.3.4. That would make it easier as it'd take the burden of handling potentially hundreds of daily calls away from the phone-connection side of any replacement system.

[irrelevant]

If you can put a whole number in the prefix field then that sounds hopeful - does TiVo try to authenticate with a particular username/password, do you know? (In any case I assume that there are a few 0845 ISPs who accept whatever credentials you happen to specify.)

Yes, as somebody else pointed out already, the username & password, and the IP addresses, are in /etc/tclientUK.conf

On the issue of TiVo wanting its guide data from a specific IP address, presumably this CAN be changed by an update down the line during the daily call - so if those instructions can be spoofed that opens two possible options, either of a 'new dialup number' which just connects to a closed system pretending to be the ISP and TiVo server in one, and is used by ALL users for ALL daily calls, OR a similar 'one shot' dialup number which could do nothing other than inform any connecting TiVos that the new daily call number is 0845-BT-Click and the new server address is 1.2.3.4. That would make it easier as it'd take the burden of handling potentially hundreds of daily calls away from the phone-connection side of any replacement system.

That does involve creating /two/ server services ... which might be an issue given the timescale. Quickest for /me/ would be to set up a ppp dial-up server on it's own subnet, and use a firewall box I have to redirect attempts to access the TiVo servers off to a new server. If I can find a 56K modem, I could do that right now.

[spitfires]

as far as I remember the slices are delivered in an encrypted form, and then decrypted on the TiVo box and processed.

Yes - here's an extract from my /var/log/tclient

Code: Select all

02/16:22:09:46: /tvbin/TClient:  Unbundling /var/packages/PC-DBS-p15021-v1426.slice.bnd
02/16:22:09:47: /tvbin/TClient:  Using type-1 Blowfish key SOFTWARE-199801
02/16:22:09:47: /tvbin/TClient:  Session key decrypted successfully
02/16:22:09:47: /tvbin/TClient:  Session unlocked
02/16:22:09:47: /tvbin/TClient:  Decrypting PC-DBS-p15021-v1426.slice.gz.bf to PC-DBS-p15021-v1426.slice.gz
02/16:22:09:47: /tvbin/TClient:  Decompressing PC-DBS-p15021-v1426.slice.gz to /var/packages/PC-DBS-p15021-v1426.slice
02/16:22:09:47: /tvbin/TClient:  Unbundling /var/packages/PG-0001172-d2-p15021.slice.bnd
02/16:22:09:49: /tvbin/TClient:  Using type-1 Blowfish key 0001172-199806
02/16:22:09:49: /tvbin/TClient:  Session key decrypted successfully
02/16:22:09:49: /tvbin/TClient:  Session unlocked
02/16:22:09:49: /tvbin/TClient:  Decrypting PG-0001172-d2-p15021.slice.gz.bf to PG-0001172-d2-p15021.slice.gz
02/16:22:09:53: /tvbin/TClient:  Decompressing PG-0001172-d2-p15021.slice.gz to /var/packages/PG-0001172-d2-p15021.slice
02/16:22:09:57: /tvbin/TClient:  Unbundling /var/packages/PG-BN18Ant-d2-p15021-t2.slice.bnd
02/16:22:09:57: /tvbin/TClient:  Using type-1 Blowfish key BN18Ant-199806
02/16:22:09:57: /tvbin/TClient:  Session key decrypted successfully
02/16:22:09:57: /tvbin/TClient:  Session unlocked
02/16:22:09:57: /tvbin/TClient:  Decrypting PG-BN18Ant-d2-p15021-t2.slice.gz.bf to PG-BN18Ant-d2-p15021-t2.slice.gz
02/16:22:09:57: /tvbin/TClient:  Decompressing PG-BN18Ant-d2-p15021-t2.slice.gz to /var/packages/PG-BN18Ant-d2-p15021-t2.slice
02/16:22:09:57: /tvbin/TClient:  DBLOAD_START_TIME = 1297894197
02/16:22:09:57: /tvbin/TClient:  DBLOAD_START_PERCENT = 0

("BN18" is my postcode!)

[garysargent]

From snippets of info obtained via Google it looks to me like there was a TiVo Service Emulator once upon a time.

Made for TiVo's in Canada, and then used in Oz.

See: http://www.linux.org.au/conf/2005/Paper ... _paper.pdf
(Chapter 5 - Emulating the TiVo Mothership)

Here is a guy in Norway attempting to setup a TiVo server: http://forums.oztivo.net/showthread.php ... -in-Norway

This is all going back a few years though and there are a lot of broken links, and I haven't seen any downloads anywhere.

[garysargent]

Suggest someone starts asking questions on this forum about how they have setup a New Zealand emulator...

http://forums.oztivo.net/forumdisplay.p ... eral-Forum

Their FAQ suggests it supports 2.5.5 UK:
http://forums.oztivo.net/showthread.php ... Emulator(s)-and-Setup

[irrelevant]

I've already PMd, via another forum - couldn't find a working email - the author of the Tivo Service Emulator written for TiVo Canada & OzTiVo, asking if a copy would be available, and pointing him here. I hope he's able to help.

See the thread in Work In Progress.

[Ant]

If I can find a 56K modem, I could do that right now.

A 28k/33.6k modem would do. 56k modems can only connect at the higher speed when the "ISP" side of the link is digital (i.e. racks of ISDN TAs, etc.)

28k modem-to-modem should definitely be good enough to test with, though. (Hell, any speed should do really, it's only a matter of how long it takes.) Linux is so totally not my skill, but as you say, presumably it should be possible to set up a machine to answer calls and accept PPP connections as a starting point.

[spitfires]

See also this stuff on Wktivoguide by said Warren Toomey

Wktivoguide - Generate Guide Data Slices File for TiVo
http://minnie.tuhs.org/Programs/Wktivoguide/index.html

Wktivoguide - Warren Toomey's Homegrown TiVo Slice Generator
http://minnie.tuhs.org/Programs/Wktivoguide/README.html


You will note that his server hosts the OzTivo mothership!

Suggest someone starts asking questions on this forum about how they have setup a New Zealand emulator...

I have asked recently on the Oz/Nz site for help but they didn't seem interested. Perhaps it was just cos it was me.

[Alek]

From Reading some of that it looks like there are uk boxes in use in Oz so that should be helpful

Alek

[swuk]

Yes - here's an extract from my /var/log/tclient

Yep, similar in mine, except with a different postcode. Makes sense. The guide data is going to be tied to regional variances... although I would imagine that these are less and less now with the merger of most of the ITV regions. Though they still exist.

The http log is interesting as well. It's possible that the session key is getting traced in the http response, or maybe it's a reference to a lookup table.

Some good news appears to be that if there's no digital signature on the slices, then it doesn't care.