If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Problem with S3

I finally took the plunge with my S3 and hacked it. Prior to this, I had only hacked my TiVo HD (and of course my S1). The S3 is having a couple of problems, however. In the first place, when I used `tivopart r /dev/sdc` to rescan the partitions, it complained about /dev/sdc16. Since sdc16 is an MFS partition, I really didn't pay too much attention, especially since I was able to mount the root and /var with no apparent trouble. I neutered the kernel, copied all the files over, disabled iptables, and patched tivoapp with the NoCSO hack. I put everything back together and rebooted. I'm able to telnet in, and ftp and TiVoWebPlus are both working. The regular functioning of the TiVo seems fine. When I run ciphercheck, however, I get:

Hmm. This is going to complicate maintaining the units just a bit. There are several relatively simple things I can do manually, but as usual I would prefer to automate the process as much as possible. Do you know of a file on the hard drive I can inspect to determine which flavor of TiVo is being modified? If I can get that automatically in the script, then I can easily choose between two archives to dump onto the drive.

Hmm. This is going to complicate maintaining the units just a bit. There are several relatively simple things I can do manually, but as usual I would prefer to automate the process as much as possible. Do you know of a file on the hard drive I can inspect to determine which flavor of TiVo is being modified? If I can get that automatically in the script, then I can easily choose between two archives to dump onto the drive.

On the tivo, check $SerialNumber or the output of `crypto -gsn`.

Off the tivo, it's a bit harder. The root file systems are identical, except what is in /platform. So you could look in /platform for something that distinguishes the two systems. The kernels are also different, so you could also look for an identifying string there.

Perhaps the best idea would be to check the MFS magic number. For mfs32:

Off the tivo, it's a bit harder. The root file systems are identical, except what is in /platform. So you could look in /platform for something that distinguishes the two systems. The kernels are also different, so you could also look for an identifying string there.

Perhaps the best idea would be to check the MFS magic number. For mfs32:

Hmm. I finally (over a year later!!) got around to trying to implement this, having finally gotten tired of manually arranging the hacks. I'm getting something different than you posted, however. From one of my S3 TiVos, I get:

Note the byte swapping. Was your output obtained from a live TiVo? I'm doing this from a TiVo drive mounted in a Linux PC. Is that why the bytes are swapped? Telnetting to a live THD and running the command gets the same result you show for the 64 bit.

....
Note the byte swapping. Was your output obtained from a live TiVo? I'm doing this from a TiVo drive mounted in a Linux PC. Is that why the bytes are swapped? Telnetting to a live THD and running the command gets the same result you show for the 64 bit.

Seems you've answered this on your own, but, yes, it is an endianness issue.