PDA

View Full Version : 11.0k starting to roll out



djl
02-14-2011, 10:41 PM
There's a software update labeled 11.0k.E1-01-2-652 on my HD today (2/14). Anyone know anything about this one?

djl
02-18-2011, 08:13 AM
Evidently, it has a couple of bug fixes: one for Netflix, the other for tuning adapters:
http://www.tivocommunity.com/tivo-vb/showthread.php?p=8384666#post8384666

AlphaWolf
02-18-2011, 06:36 PM
That E1 suggests you have a beta copy.

djl
02-19-2011, 11:11 AM
It is, that. Crud, off to see if anyone ported "No Thanks" for 11.0j...


That E1 suggests you have a beta copy.

ScanMan
02-19-2011, 09:44 PM
Had some time so here are some quick tivoapp patches for 11.0k.E1-01-2-648. Tivoapp md5 checksum
2377b61ae3b547223c70eb86eb4c1ed6These patches were originally ported for tivo BETA release 11.0k.E1. However psxboy has confirmed that they are identical for the final s/w release 11.0k and has posted additional patches below.

11.0k.E1
0x005d2dec "104000aa 100000aa" //noencryption
0x006562a0 "30b000ff 00008021" //cci1
0x006562c4 "00e08821 24110000" //cci2
0x00774f74 "00008021 24100001" //backdoors
0x01046970 "30b000ff 00008021" //cci3The bufferhack patch is identical in the 11.0k release as well, but use the code in psxboy's post below which has the correct s/w version identified; I'm leaving this here for posterity's sake. ;)

set sys(11.0k.E1)
[list 0x114536 0x114202 0x6c 0x1bca4a 30344396 325F14DAA33CC105AD841D8F73E3E67B7A85EDBF]

ScanMan
02-20-2011, 08:39 AM
Update from post above. I took the upgrade, using Jamie's custom kernel, all is well. Applied the patches posted and all looks good. Bufferhack lightly tested but looks good.

EDIT: Uploaded new tvapppatches for final 11.0k release version which appears to be in full rollout mode.

It includes:
//noencryption
//cci1
//cci2
//backdoors
//cci3
//deletethisrecording?
//nopauseads

Thanks to psxboy for finishing and verifying all the patches for the 11.0k final! As always, feel free to add/delete specific patches as you wish...

psxboy
02-22-2011, 03:14 PM
If anyone really wants it, the "No thanks!" patch for 11.0j should be:


Offset (VMA) Original Value New Value
0x007c5890 10400008 10000008

Please note, I HAVE NOT TESTED THIS MYSELF. Use at your own peril.

-psxboy

djl
02-22-2011, 06:41 PM
+1, thanks ScanMan


Update from post above. I took the upgrade, using Jamie's custom kernel, all is well. Applied the patches posted and all looks good. Bufferhack lightly tested but looks good.

lgkahn
02-27-2011, 09:29 AM
strange this rollout must have never really happened.. it has been awhile and none of my 3 boxes have it?

ScanMan
02-27-2011, 10:32 AM
strange this rollout must have never really happened.. it has been awhile and none of my 3 boxes have it?I don't think the beta pre-release is complete; there's no chatter about it. I only have it one of my machines as well. I had no experience with the bugs it purports to fix so I can't comment on that. We'll probably see a full rollout starting within the next few weeks.

whitepelican
03-01-2011, 01:58 PM
Could someone more intelligent than me (read: everyone else here) help out by porting the "nopauseads" patch to 11.0k.E1 if possible? I don't really know what I'm looking for, but I can't seem to find the same hex string in this tivoapp as in the 11.0j one, so I'm kind of stuck. I probably would have never taken the update if I knew I would lose that functionality.

psxboy
03-01-2011, 02:13 PM
My Tivo just downloaded the official 11.0k & the patch locations that ScanMan posted for the E1 are the same for the final release, plus the other standard patches:


11.0k
0x005d2dec "104000aa 100000aa" //noencryption
0x006562a0 "30b000ff 00008021" //cci1
0x006562c4 "00e08821 24110000" //cci2
0x00774f74 "00008021 24100001" //backdoors
0x01046970 "30b000ff 00008021" //cci3
0x009b3b20 "12400003 10000003" //deletethisrecording?
0x00b8f910 "14400026 10400026" //30secskip
0x00b93eb8 "0c2e5325 00000000" //nopauseads

I would assume that the bufferhack patch location is also the same, but I'll double-check.
The bufferhack patch is the same as the E1 version also:

set sys(11.0k)[list 0x114536 0x114202 0x6c 0x1bca4a 30344396 325F14DAA33CC105AD841D8F73E3E67B7A85EDBF]

Some notes:

I've omitted the nopromos patch since it breaks the video on demand stuff. If anyone really wants it let me know & I'll port it.
The 30secskip patch is no longer necessary - once you enable it via the remote it stays enabled, even across reboots & software upgrades. I've only included it here so the Aussies can find & port it to their software version (where 30secskip is intentionally disabled).


And here's the NoMEK patches for 11.0k. It replaces the generic noencryption patch to allow MRV of existing encrypted recordings.


11.0k NoMEK
0x005d2de8 "92220024 27a40028"
0x005d2dec "104000aa 0c156af0"
0x005d2df0 "27a40028 00000000"
0x005d2df4 "0c156af0 0c424796"
0x005d2dfc "8fa20020 106000aa"
0x01091e30 "27bdfec8 03e00008"
0x01091e34 "afb40128 24020001"
0x01091e58 "00a0a021 8e230040"
0x01091e5c "0c1b61e6 10600002"
0x01091e60 "00602821 00000000"
0x01091e64 "00408021 8c630000"
0x01091e68 "1200000a 03e00008"
0x01091e6c "00001021 8fa20020"


And a couple of miscellaneous patches:


0x007c5140 "10400008 10000008" //nothanks
0x0056a3a4 "1200ffaf 1000ffaf" //ignoredrmsig1
0x00598024 "1200ff87 1000ff87" //ignoredrmsig2

-psxboy

whitepelican
03-01-2011, 02:50 PM
Awesome, thanks. That was fast. I think you've got a typo on the "nopauseads" line, though. I believe you've got the letter O instead of a zero.

psxboy
03-01-2011, 03:07 PM
Awesome, thanks. That was fast. I think you've got a typo on the "nopauseads" line, though. I believe you've got the letter O instead of a zero.

You're right... fixed. I also verified that the bufferhack patch is the same as well.

-psxboy

psxboy
03-01-2011, 06:11 PM
I've updated my post above to include the NoMEK and some other miscellaneous patches.

-psxboy

Heartbreaker
03-03-2011, 07:42 AM
Update from post above. I took the upgrade, using Jamie's custom kernel, all is well. Applied the patches posted and all looks good. Bufferhack lightly tested but looks good.

Thanks, ScanMan for being so on top of it.. Just got the "upgrade" message so waiting for it to reboot so I can telnet into the TiVo and apply the patch 11.k.E1.

Question tho: I got rid of promos with routerplus... did the upgrade nuke that or something?

kmt
03-03-2011, 10:01 AM
I'm confused.

My HDTivo rebooted the other night, and I see it is now running 11.0k-01-2-652. It was running 'j' before. However, its still running off the same root partition as before, and still has my mods.

The reboot occurred 28 hours ago, at about 6am in the morning. The logs have rolled past the point where I can see the reboot.

It looks like the unmounted root partition is newer based on date of tivoapp.

I do have reboot commented out in installSw.itcl, but that would keep it from rebooting not from booting to the same root partition.

So is this what happened:

I got the software update. It prepared the new partition, swapped the parameter that tells it what kernel partition for boot, didn't swap the root partition parameter, didn't reboot because of my installSw.itcl, and later rebooted for some unrelated reason?

ScanMan
03-03-2011, 10:01 AM
Thanks, ScanMan for being so on top of it.. Just got the "upgrade" message so waiting for it to reboot so I can telnet into the TiVo and apply the patch 11.k.E1.

Question tho: I got rid of promos with routerplus... did the upgrade nuke that or something?I'm assuming you received the 11.0k final version not the E1 beta release. Did you block updates with bootpage parameters? If so, you'll need to do a manual upgrade or otherwise rehack before applying patches. Not sure about the nopromos thing, you may have to nuke them again.

psxboy
03-03-2011, 10:47 AM
I got the software update. It prepared the new partition, swapped the parameter that tells it what kernel partition for boot, didn't swap the root partition parameter, didn't reboot because of my installSw.itcl, and later rebooted for some unrelated reason?

That's not quite how the upgrade works. The new software consists of a series of gzipped slice files which your Tivo downloads during it's daily call. These files are then imported as-is into MFS and the box goes into the "pending restart" state. While in this state it will reboot around 2am in order to install the new software. This "pending restart" reboot is not dependent on the installSw.itcl file - commenting out the reboot line in that file does not prevent the 2am reboot.

Anyway, what normally happens is: download the software, reboot at 2am, invoke installSw.itcl which exports the gzipped slices from MFS and proceeds to build the new filesystem on the alternate partition, writes the new kernel partition, flips the bootpage & reboots (again) into the new software.

So basically your Tivo is in an in-between state. It has completed the 2am reboot & installed the new software but hasn't completed the final reboot. At this point you should mount the other partition and copy your hacks over and neuter the new kernel. Then when you reboot it will boot into the new, already hacked partition.

You should also take this opportunity to set "upgradesoftware=false" in your bootpage parameters. THAT will prevent the Tivo from invoking installSw.itcl and installing the new software next time, but your box will still reboot every night at 2am after it downloads the new software. To prevent THAT, apply the nothanks tivoapp patch.

-psxboy

Heartbreaker
03-03-2011, 12:50 PM
I'm assuming you received the 11.0k final version not the E1 beta release. Did you block updates with bootpage parameters? If so, you'll need to do a manual upgrade or otherwise rehack before applying patches. Not sure about the nopromos thing, you may have to nuke them again.

Just downloaded the final right now. I'm assuming with the "bootpage paramets you mean this:
bootpage -P "root=/dev/hda7 dsscon=true console=1,115200 upgradesoftware=false" ...if so, then no. Looks like yet ANOTHER manual re-hack for me. LOL. I needed to anyhow to get some shows back off the original Tivo copy I had. I was always a little confused with when to run/write the bootpage parameter (if that is even the correct one you are referring to). I mean is it once you have telnet to your tivo's IP you run the line or is it something you write in VI in your iptables or rc.sysinit.author file, etc?

Thinkdiff
03-03-2011, 01:18 PM
11.0k is sitting on my TiVo HD. My other unhacked TiVos have not received the update yet.

ScanMan
03-03-2011, 01:29 PM
Just downloaded the final right now. I'm assuming with the "bootpage paramets you mean this: ...if so, then no. Looks like yet ANOTHER manual re-hack for me. LOL. I needed to anyhow to get some shows back off the original Tivo copy I had. I was always a little confused with when to run/write the bootpage parameter (if that is even the correct one you are referring to). I mean is it once you have telnet to your tivo's IP you run the line or is it something you write in VI in your iptables or rc.sysinit.author file, etc?Yes, those are the parameters I was referring to. You can either issue the command from a telnet session or from the MFSLive boot cd with the drive attached to you PC. However, once the upgrade is installed (automatically at 2:00AM) or if you reboot manually before that, you'll lose telnet, etc., and have to pull the drive and re-hack.

Heartbreaker
03-03-2011, 01:33 PM
haha... yeah I learned that late last night the hard way

kmt
03-04-2011, 08:21 PM
It's been a while since I patched tivoapp directly on the tivo. Where can find the script to do the dd's from the posted changes? The one I was using was meant for intel and had the byte order wrong.

ScanMan
03-04-2011, 08:53 PM
It's been a while since I patched tivoapp directly on the tivo. Where can find the script to do the dd's from the posted changes? The one I was using was meant for intel and had the byte order wrong.
Here are the 'dd' commands for you hardcore types (where's lgkahn when you need him?) tvapppatch is so much easier, but to each his own...:rolleyes:

I have not tested these myself. Basically you subtract 400000 from the offsets and convert to decimal for the seek=value; they should be right, but make a virgin copy of your tivoapp jic.

In the following order:
//noencryption
//cci1
//cci2
//backdoors
//cci3
//deletethisrecording?
//nopauseads


11.0k
echo -ne "\x10\x00\x00\xaa" | dd conv=notrunc of=tivoapp bs=1 seek=1912300
echo -ne "\x00\x00\x80\x21" | dd conv=notrunc of=tivoapp bs=1 seek=2450080
echo -ne "\x24\x11\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=2450116
echo -ne "\x24\x10\x00\x01" | dd conv=notrunc of=tivoapp bs=1 seek=3624820
echo -ne "\x00\x00\x80\x21" | dd conv=notrunc of=tivoapp bs=1 seek=12872048
echo -ne "\x10\x00\x00\x03" | dd conv=notrunc of=tivoapp bs=1 seek=5978912
echo -ne "\x00\x00\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=7945912

Heartbreaker
03-04-2011, 09:33 PM
Hm. Just thought about something. So.. I ran the command
mv tvapppatches-110k.tcl tvapppatches.tcl
reboot
And once my Tivo came back online, the software still says 11.0j with a "pending restart" status. Now I know we have talked about the Pending Restart in the past but I thought me rebooting would cause it to upgrade before 2am. Is that not the case? Also, did I apply the 11.0k patch too soon?

ScanMan
03-04-2011, 09:56 PM
The 'mv' command just renames the file. The new s/w should install upon restart. You could get telnet and manually kick it off with the command
tivosh /tvbin/installSw.itcl

lgkahn
03-05-2011, 08:19 AM
Here are the 'dd' commands for you hardcore types (where's lgkahn when you need him?) tvapppatch is so much easier, but to each his own...:rolleyes:

I have not tested these myself. Basically you subtract 400000 from the offsets and convert to decimal; pretty sure they are right, but make a virgin copy of your tivoapp jic.

In the following order:
//noencryption
//cci1
//cci2
//backdoors
//cci3
//deletethisrecording?
//nopauseads


11.0k
echo -ne "\x10\x00\x00\xaa" | dd conv=notrunc of=tivoapp bs=1 seek=1912300
echo -ne "\x00\x00\x80\x21" | dd conv=notrunc of=tivoapp bs=1 seek=2450080
echo -ne "\x24\x11\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=2450116
echo -ne "\x24\x10\x00\x01" | dd conv=notrunc of=tivoapp bs=1 seek=3624820
echo -ne "\x00\x00\x80\x21" | dd conv=notrunc of=tivoapp bs=1 seek=12872048
echo -ne "\x10\x00\x00\x03" | dd conv=notrunc of=tivoapp bs=1 seek=5978912
echo -ne "\x00\x00\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=7945912

thanks will test.. i am here but didnt get updates on all my boxes till last night so you beat me too it.

double checked your math all ok.. only takes 5 minutes. i go into the calculator in windows put it in programer mode.. go into hex model put 400000 in and put it in memory..

then just cut and past the offset in hex from post here.. paste in calculator and then do subtract memory recall, then click binary..
anyway i like to patch an change tivoapp while i am patching all in a terminal window then reboot and just apply bufferhack..
here is the missing 30 sec skip if anyone wants it so you dont have to much with the key presses. thanks

echo -ne "\x10\x40\x00\x26" | dd conv=notrunc of=tivoapp bs=1 seek=7928080

also here is modified bufferhack for those that dont want to bother editing it.

Kayle
03-05-2011, 08:47 PM
There is a typo in the NoMEK patch (seems to have been around for awhile)




11.0k NoMEK
0x005d2de8 "92220024 27a40028"
0x005d2dec "100040aa 0c156af0"
0x005d2df0 "27a40028 00000000"
0x005d2df4 "0c156af0 0c424796"
...



That bolded line should be:



0x005d2dec "1040000aa 0c156af0"


Found this because I wrote my own patcher scriupt and it checks the existing value before patching.

Thinkdiff
03-06-2011, 05:04 AM
Here are the NoMEK dd commands:



echo -ne "\x27\xa4\x00\x28" | dd conv=notrunc of=tivoapp bs=1 seek=1912296
echo -ne "\x0c\x15\x6a\xf0" | dd conv=notrunc of=tivoapp bs=1 seek=1912300
echo -ne "\x00\x00\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=1912304
echo -ne "\x0c\x42\x47\x96" | dd conv=notrunc of=tivoapp bs=1 seek=1912308
echo -ne "\x10\x60\x00\xaa" | dd conv=notrunc of=tivoapp bs=1 seek=1912316
echo -ne "\x03\xe0\x00\x08" | dd conv=notrunc of=tivoapp bs=1 seek=13180464
echo -ne "\x24\x02\x00\x01" | dd conv=notrunc of=tivoapp bs=1 seek=13180468
echo -ne "\x8e\x23\x00\x40" | dd conv=notrunc of=tivoapp bs=1 seek=13180504
echo -ne "\x10\x60\x00\x02" | dd conv=notrunc of=tivoapp bs=1 seek=13180508
echo -ne "\x00\x00\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=13180512
echo -ne "\x8c\x63\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=13180516
echo -ne "\x03\xe0\x00\x08" | dd conv=notrunc of=tivoapp bs=1 seek=13180520
echo -ne "\x8f\xa2\x00\x20" | dd conv=notrunc of=tivoapp bs=1 seek=13180524


Here's a little bash script I threw together to convert tvapppatch style to dd style. Unfortunately it doesn't run on the TiVo because it relies on "bc" to do the HEX conversion and subtraction. If anybody knows of a built-in tivo command that can handle hex conversion, let me know.

It waits for input on stdin, outputs the corresponding dd command and then loops. To exit, just type "exit". You can also feed it the list of commands in a text file and it will convert them:


macbook-pro:~ Td$ cat patches.txt | ./patchconvert
echo -ne "\x10\x00\x00\xaa" | dd conv=notrunc of=tivoapp bs=1 seek=1912300
echo -ne "\x00\x00\x80\x21" | dd conv=notrunc of=tivoapp bs=1 seek=2450080
echo -ne "\x24\x11\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=2450116
echo -ne "\x24\x10\x00\x01" | dd conv=notrunc of=tivoapp bs=1 seek=3624820
echo -ne "\x00\x00\x80\x21" | dd conv=notrunc of=tivoapp bs=1 seek=12872048
echo -ne "\x10\x00\x00\x03" | dd conv=notrunc of=tivoapp bs=1 seek=5978912
echo -ne "\x10\x40\x00\x26" | dd conv=notrunc of=tivoapp bs=1 seek=7928080
echo -ne "\x00\x00\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=7945912


Does no error checking and could have some bugs, use at own risk, etc, etc, etc.

leeclarke
03-06-2011, 05:09 PM
I'm in that in between state too. bootpage -p says root in hda4.
When I do:
dd if=vmlinux-Gen06-netopt-ext3.px of=/dev/sda63
I get this error message
dd: /dev/sda3: No such device or address

Tia...

Heartbreaker
03-06-2011, 05:14 PM
I'm in that in between state too. bootpage -p says root in hda4.
When I do:
dd if=vmlinux-Gen06-netopt-ext3.px of=/dev/sda63
I get this error message
dd: /dev/sda3: No such device or address

Tia...

dd if=vmlinux-Gen06-netopt-ext3.px of=/dev/sda3 worked for me.

leeclarke
03-06-2011, 06:23 PM
Sorry for the typos. I did do:
dd if=vmlinux-Gen06-netopt-ext3.px of=/dev/sda3

I still get:
dd: /dev/sda3: No such device or address

Is there a mount I must do first?

lrhorer
03-06-2011, 08:20 PM
It's been a while since I patched tivoapp directly on the tivo. Where can find the script to do the dd's from the posted changes? The one I was using was meant for intel and had the byte order wrong.


I have not tested these myself. Basically you subtract 400000 from the offsets and convert to decimal; pretty sure they are right, but make a virgin copy of your tivoapp jic.

Um, hang on. Unless I am much mistaken, one does NOT subtract 400000 from the offsets if one is patching on the TiVo, right? Kmt is talking about patching in a telnet session to the TiVo.

Thinkdiff
03-06-2011, 08:31 PM
Um, hang on. Unless I am much mistaken, one does NOT subtract 400000 from the offsets if one is patching on the TiVo, right? Kmt is talking about patching in a telnet session to the TiVo.

With regards to the dd method, it doesn't matter if you're patching on the TiVo or a MFSLive CD. You still subtract 0x00400000 and then convert to decimal. The patch locations don't change when you modify the file directly on the tivo.

lrhorer
03-06-2011, 08:33 PM
Here's a little bash script I threw together to convert tvapppatch style to dd style. Unfortunately it doesn't run on the TiVo because it relies on "bc" to do the HEX conversion and subtraction. If anybody knows of a built-in tivo command that can handle hex conversion, let me know.
BASH can do hex calculations. In the sample script I created here (http://dealdatabase.com/forum/showthread.php?p=297738&), I simply input the offset and do the math in BASH. I haven't tried it on a TiVo, and I suppose it's possible the version of BASH on the TiVo might be too old to handle the calculations properly, as I haven't tried it, but I think it would work.


echo Getting the hacking parameters for tivoapp
fail=1
while read line
do
offset=$(( $(echo $line | cut -d" " -f1) - 0x00400000 ))
oldword=$(echo $line | cut -d" " -f2 | sed s'/"//g')
newword=$(echo $line | cut -d" " -f3 | sed s'/"//g')
echo $oldword $newword $offset
B1=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c11-12 )
B2=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c9-10 )
B3=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c16-17 )
B4=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c14-15 )
testword=$B1$B2$B3$B4
echo $testword
# Check to make sure the bytes match
if [ "$testword" == "$oldword" ];
then
echo Updating tivoapp $( echo $line | cut -d" " -f4)
# Convert the string into a 4 byte number expression
escape="\x"
H1=${newword:0:2}
H2=${newword:2:2}
H3=${newword:4:2}
H4=${newword:6:2}
newword=$escape$H1$escape$H2$escape$H3$escape$H4
echo -ne "$newword" | dd conv=notrunc of=$SaveFile bs=1 seek=$offset
else
echo Failed for $oldword $newword $offset Old value: $testword
echo Exiting
test -e $SaveFile && rm $SaveFile
exit 1
fi
done < $HackFile

Edit: Yeah, I just tried it on one of my S3 TiVos, and it works:


HD_Theater:/# line="0x005d353c 104000aa 100000aa //noencryption"
HD_Theater:/# offset=$(( $(echo $line | cut -d" " -f1) - 0x00400000 ))
HD_Theater:/# echo $offset
1914172

lrhorer
03-06-2011, 09:10 PM
With regards to the dd method, it doesn't matter if you're patching on the TiVo or a MFSLive CD. You still subtract 0x00400000 and then convert to decimal. The patch locations don't change when you modify the file directly on the tivo.
Oh, I see. OK, nevermind.

lrhorer
03-06-2011, 10:48 PM
Sorry for the typos. I did do:
dd if=vmlinux-Gen06-netopt-ext3.px of=/dev/sda3

I still get:
dd: /dev/sda3: No such device or address

Is there a mount I must do first?

No. Well, the directory containing vmlinux-Gen06-netopt-ext3.px has to be mounted, of course, and you must be in that directory when you issue the command, or else dd won't find it. Are you doing this on a TiVo, though? On the TiVo, the target will be /dev/hda, not /dev/sda. Depending on the version of udev used by your Linux distro, it might be /dev/hda on a PC, as well. Try:

ls -l /dev/sd*

Does it report any block devices? If not, try:

ls -l /dev/hd*

Do the bock devices show up there?

If this is being done on a PC, either you need a kernel which understands the TiVo partitioning, or else you need to run:

tivopart r <drive spec>

in order to register the partitions with the OS.

lrhorer
03-06-2011, 10:55 PM
That's not quite how the upgrade works. The new software consists of a series of gzipped slice files which your Tivo downloads during it's daily call. These files are then imported as-is into MFS
Into MFS? I thought they all went into /var/slices. I'm having trouble imagining why they would go into MFS, except possibly bits of video - which wouldn't be gzipped.

Thinkdiff
03-06-2011, 11:03 PM
Into MFS? I thought they all went into /var/slices. I'm having trouble imagining why they would go into MFS, except possibly bits of video - which wouldn't be gzipped.

The TiVo temporarily downloads them to /var/slices. Once it finishes the download, it inserts them into MFS as resources (MFS doesn't store only video - there's lots of stuff in there). After it's done inserting, it removes the slices (probably because /var is not considered a safe place to put things). The installSw.itcl script finds the resources in MFS, dumps them back into standard gzip format in a temporary directory, expands and then runs the install script from the software update.

Thinkdiff
03-06-2011, 11:04 PM
Edit: Yeah, I just tried it on one of my S3 TiVos, and it works:


HD_Theater:/# line="0x005d353c 104000aa 100000aa //noencryption"
HD_Theater:/# offset=$(( $(echo $line | cut -d" " -f1) - 0x00400000 ))
HD_Theater:/# echo $offset
1914172 Thanks! Didn't know you can just subtract things like that in bash.

lrhorer
03-07-2011, 12:06 AM
The TiVo temporarily downloads them to /var/slices. Once it finishes the download, it inserts them into MFS as resources (MFS doesn't store only video - there's lots of stuff in there). After it's done inserting, it removes the slices (probably because /var is not considered a safe place to put things). The installSw.itcl script finds the resources in MFS, dumps them back into standard gzip format in a temporary directory, expands and then runs the install script from the software update.
Yeah, I knew there were other things in MFS, such as all the settings the user specifies from the GUI.

This begs the question, however. If the user has inhibited upgrades by setting upgradesoftware=false and implemented the nothanks hack, will issuing the command:

echo mls /SwSystem | tivosh

accurately reflect a pending upgrade? I just yesterday hacked my last remaining unhacked TiVo and in doing so implemented an insitu hack utility for the first time. The other two TiVos are easy to hack, and so on them I have always simply pulled the primary (external) drive, took it over to a PC, and hacked the drive whenever the TiVo upgraded itself. The remaining TiVo, however, is extremely difficult (not to mention extremely physically painful) to upgrade, so insitu hacks are the only practical method of hacking this TiVo. The TiVo is still running 11.0k.E1, and there are a bunch of slices in /var/slices. Should I run installSw.itcl (neutered, of course) now, or wait for the mls command to show up a pending install set?

Thinkdiff
03-07-2011, 12:22 AM
upgradesoftware=false is read on start-up and prevents the installSw.itcl script from being run when "Pending Restart" is set.

The nothanks hack (I believe) just removes the command to restart the TiVo every day at 2AM (neutering the "Pending Restart" state).

Neither have any effect on what the TiVo OS does with slices. The slices are inserted into MFS by the code that does the daily call. If you have slices in /var/slices, then you've either implemented some hack to copy slices to that location and prevent them from being deleted or there was a problem inserting them into MFS. As soon as the daily call is over, those files are supposed to be deleted AFAIK.

If 11.0k-01-2-652 does not show up in SwSystem, installSw.itcl will not be able to upgrade. The only way it gets the slices is by extracting them using the SwSystem resource.

lrhorer
03-07-2011, 12:35 AM
Thanks! Didn't know you can just subtract things like that in bash.
Yeah. I also updated the post over in the other thread to add the syntax to be used when hacking tivoapp on a running TiVo. Since the bytes are not swapped when running on a TiVo, it only requires two lines and two variables to build the command, rather than four. Of course your version of the app will optionally accept input from the console, while mine requires a file from which to obtain the hacks.

lrhorer
03-07-2011, 12:59 AM
Neither have any effect on what the TiVo OS does with slices. The slices are inserted into MFS by the code that does the daily call. If you have slices in /var/slices, then you've either implemented some hack to copy slices to that location and prevent them from being deleted or there was a problem inserting them into MFS. As soon as the daily call is over, those files are supposed to be deleted AFAIK.
Hmm. Oh, I think I see what it is. I implemented a variation of the hacks posted by mike_s in this (http://dealdatabase.com/forum/showthread.php?t=62603) thread. With his hacks, the /var/slices directory is automatically created (by rc.sysinit.author) if it does not exist, and this entry in crontab:


* * * * * ln /var/packages/*.slice.* /var/slices/

creates hard links to the files in /packages when they show up. So it looks like the slices are normally kept in /var/packages, not /var/slices like I thought. The hard links would alllow the files to be copied and removed via `rm` or some similar utility, but the inodes don't get released because there are still hard links to them in the /var/slices directory.


If 11.0k-01-2-652 does not show up in SwSystem, installSw.itcl will not be able to upgrade. The only way it gets the slices is by extracting them using the SwSystem resource.

Well, that still leaves me a bit puzzled. If the slices were downloaded, then why doesn't 11.0k-01 show up? If not, then what is all that in the /var/slices directory?


HD_LivingRoom:/# ll /var/slices
total 400
-rw-r--r-- 1 0 0 92190 Mar 6 04:15 AD-TAP_AdContentSet_taylor1101.xml-v8.slice.gz
-rw-r--r-- 1 0 0 96763 Mar 6 04:15 AD-TAP_AdContentSet_tlc1103.xml-v6.slice.gz
-rw-r--r-- 1 0 0 4303 Mar 6 04:15 MI-TAP_MenuItem_ally_Ally_2011_PP_PMI_726494_PP_2.xml-v7.slice.gz
-rw-r--r-- 1 0 0 4306 Mar 6 04:15 MI-TAP_MenuItem_ally_Ally_2011_PP_PMI_726494_PP_3.xml-v7.slice.gz
-rw-r--r-- 1 0 0 4285 Mar 6 04:15 MI-TAP_MenuItem_ally_Ally_2011_PP_PMI_726494_PP_4.xml-v7.slice.gz
-rw-r--r-- 1 0 0 4244 Mar 6 04:15 MI-TAP_MenuItem_ally_Ally_2011_PP_PMI_726494_PP_5.xml-v7.slice.gz
-rw-r--r-- 1 0 0 4108 Mar 6 04:15 MI-TAP_MenuItem_ally_Ally_2011_PP_PMI_726494_PP_6.xml-v4.slice.gz
-rw-r--r-- 1 0 0 2426 Mar 6 04:15 MI-TAP_MenuItem_ally_Ally_Pause1_726495_IPA.xml-v8.slice.gz
-rw-r--r-- 1 0 0 2403 Mar 6 04:15 MI-TAP_MenuItem_ally_Ally_Pause1_726495_IPA_2.xml-v8.slice.gz
-rw-r--r-- 1 0 0 2404 Mar 6 04:15 MI-TAP_MenuItem_ally_Ally_Pause1_726495_IPA_3.xml-v8.slice.gz
-rw-r--r-- 1 0 0 2403 Mar 6 04:15 MI-TAP_MenuItem_ally_Ally_Pause1_726495_IPA_4.xml-v8.slice.gz
-rw-r--r-- 1 0 0 8307 Mar 6 04:15 MI-TAP_MenuItem_taylor_TaylorMade_PP_726195_PP.xml-v10.slice.gz
-rw-r--r-- 1 0 0 8332 Mar 6 04:15 MI-TAP_MenuItem_taylor_TaylorMade_PP_726195_PP_2.xml-v10.slice.gz
-rw-r--r-- 1 0 0 8315 Mar 6 04:15 MI-TAP_MenuItem_taylor_TaylorMade_PP_726195_PP_3.xml-v10.slice.gz
-rw-r--r-- 1 0 0 8212 Mar 6 04:15 MI-TAP_MenuItem_taylor_TaylorMade_PP_726195_PP_4.xml-v10.slice.gz
-rw-r--r-- 1 0 0 8046 Mar 6 04:15 MI-TAP_MenuItem_taylor_TaylorMade_PP_726195_PP_5.xml-v8.slice.gz
-rw-r--r-- 1 0 0 2632 Mar 6 04:15 MI-TAP_MenuItem_taylor_TaylorMade_PRGAD_PMI_726196_IPA.xml-v9.slice.gz
-rw-r--r-- 1 0 0 2650 Mar 6 04:15 MI-TAP_MenuItem_taylor_TaylorMade_PRGAD_PMI_726196_IPA_2.xml-v9.slice.gz
-rw-r--r-- 1 0 0 2627 Mar 6 04:15 MI-TAP_MenuItem_taylor_TaylorMade_PRGAD_PMI_726196_IPA_3.xml-v9.slice.gz
-rw-r--r-- 1 0 0 2542 Mar 6 04:15 MI-TAP_MenuItem_taylor_TaylorMade_PRGAD_PMI_726196_IPA_4.xml-v7.slice.gz
-rw-r--r-- 1 0 0 2400 Mar 6 04:15 MI-TAP_MenuItem_taylor_TaylorMade_PRGAD_PMI_726196_IPA_5.xml-v7.slice.gz
-rw-r--r-- 1 0 0 1569 Mar 6 04:15 MI-TAP_MenuItem_tivoigui_20110304Weekend_726692.xml-v6.slice.gz
-rw-r--r-- 1 0 0 11735 Mar 6 04:15 MI-TAP_MenuItem_tlc_TLC_Sister_Wives_PP_PMI_726419_PP.xml-v6.slice.gz
-rw-r--r-- 1 0 0 11709 Mar 6 04:15 MI-TAP_MenuItem_tlc_TLC_Sister_Wives_PP_PMI_726419_PP_2.xml-v6.slice.gz
-rw-r--r-- 1 0 0 11674 Mar 6 04:15 MI-TAP_MenuItem_tlc_TLC_Sister_Wives_PP_PMI_726419_PP_3.xml-v6.slice.gz
-rw-r--r-- 1 0 0 11623 Mar 6 04:15 MI-TAP_MenuItem_tlc_TLC_Sister_Wives_PP_PMI_726419_PP_4.xml-v6.slice.gz
-rw-r--r-- 1 0 0 2638 Mar 6 04:15 MI-TAP_MenuItem_tlc_TLC_Sister_Wives_PRGAD_PMI_726420_IPA.xml-v6.slice.gz
-rw-r--r-- 1 0 0 2612 Mar 6 04:15 MI-TAP_MenuItem_tlc_TLC_Sister_Wives_PRGAD_PMI_726420_IPA_2.xml-v6.slice.gz
-rw-r--r-- 1 0 0 2483 Mar 6 04:15 MI-TAP_MenuItem_tlc_TLC_Sister_Wives_PRGAD_PMI_726420_IPA_3.xml-v6.slice.gz
-rw-r--r-- 1 0 0 56764 Mar 6 04:15 SC-tlc_TLC_Sister_Wives_TiVo719106-e15055-r15039-v6.slice.gz

Thinkdiff
03-07-2011, 01:20 AM
None of those are software slices - they all seem to be Ads or program guide updates.

System slices would have names like:

swsystem*.slice.*
utils*.slice.*
GZkernel*.slice.*
GZcore*.slice.*
etc

swinokur
03-07-2011, 01:53 AM
is it just me or is there now something running on Tivo called 'nccpapp' - I think it just showed up with this update...

psxboy
03-07-2011, 07:25 PM
There is a typo in the NoMEK patch (seems to have been around for awhile)

Doh! You're right - I've corrected my post. Thanks for catching that.

-psxboy

mike_s
03-08-2011, 07:58 AM
is it just me or is there now something running on Tivo called 'nccpapp' - I think it just showed up with this update...Seems to have to do with Netflix, including this string inside: https://moviecontrol.netflix.com/nccp/controller, which makes me think that "nccp" may be a Netflix specific acronym.

Do a "strings /tvbin/nccpapp | grep Netflix"

leeclarke
03-08-2011, 09:57 AM
Thanks for the help. I managed to hose the Tivo, so that it was stuck at the "almost there" screen. So I took the drive out, hooked it up the my computer, and restored the bootpage and kernel using Winmfs. That fixed the Tivo so it now boots as it should and all my shows are there. I still have bash, too, which seems strange, since I was restoring from unhacked 11.0j kernel/bootpage. Also, the Tivo shows 11.0k as active. And now bootpage -p shows my root is hda7 (it was hda4 before I made whatever mistake I made). I know this is all low-level for you wizards, but I'd sure appreciate some advice on what to do, while I still have telnet. As ever, thanks.

AlphaWolf
03-10-2011, 12:43 PM
Here are the 'dd' commands for you hardcore types (where's lgkahn when you need him?) tvapppatch is so much easier, but to each his own...:rolleyes:

I tend to think dd is easier, just paste them into a terminal, and you're done.

lrhorer
03-11-2011, 12:11 AM
I prefer neither one. The problem I have with tvapppatch.tcl is one must edit a script file with somewhat more information than just the patches. The problem with the dd method is one must calculate the offsets from the information usually given here and add a bunch of additional command parameters. That's why I wrote my own versions that convert the raw data as usually displayed here. Thus, I simply highlight a patch spec and paste it to a file named hacks.fil like so:


0x005d2dec "104000aa 100000aa" //noencryption
0x006562a0 "30b000ff 00008021" //cci1
0x006562c4 "00e08821 24110000" //cci2
0x00774f74 "00008021 24100001" //backdoors
0x01046970 "30b000ff 00008021" //cci3
0x009b3b20 "12400003 10000003" //deletethisrecording?
0x00b8f910 "14400026 10400026" //30secskip
0x00b93eb8 "0c2e5325 00000000" //nopauseads

Then if I am hacking on a PC I run the following script:


#!/bin/bash
SaveFile=/hack/Saved_Apps/tivoapp.tmp
Archive=/hack/Saved_Apps/tivoapp.sav
HackFile=/hack/hacks.fil
dstring=`date +%m-%d-%y`
cd /tivo/tvbin
echo Creating temporary tivoapp
cp tivoapp $SaveFile

echo Getting the hacking parameters for tivoapp
fail=1
while read line
do
offset=$(( $(echo $line | cut -d" " -f1) - 0x00400000 ))
oldword=$(echo $line | cut -d" " -f2 | sed s'/"//g')
newword=$(echo $line | cut -d" " -f3 | sed s'/"//g')
echo $oldword $newword $offset
B1=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c11-12 )
B2=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c9-10 )
B3=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c16-17 )
B4=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c14-15 )
testword=$B1$B2$B3$B4
echo $testword
# Check to make sure the bytes match
if [ "$testword" == "$oldword" ];
then
echo Updating tivoapp $( echo $line | cut -d" " -f4)
# Convert the string into a 4 byte number expression
escape="\x"
H1=${newword:0:2}
H2=${newword:2:2}
H3=${newword:4:2}
H4=${newword:6:2}
newword=$escape$H1$escape$H2$escape$H3$escape$H4
echo -ne "$newword" | dd conv=notrunc of=$SaveFile bs=1 seek=$offset
elif [ "$testword" == "$newword" ];
then
echo Failed for $oldword $newword $offset
echo Tivoapp already has patch at this location.
test -e $SaveFile && rm $SaveFile
exit 1
else
echo Failed for $oldword $newword $offset Old value: $testword
echo Exiting
test -e $SaveFile && rm $SaveFile
exit 1
fi
done < $HackFile
echo Saving old tivoapp
test -e $Archive.$dstring && mv $Archive.$dstring $Archive.$dstring.safety
cp tivoapp $Archive.$dstring
mv $SaveFile tivoapp
echo
echo Done!

Or if I am hacking on the TiVo as part of a scripted upgrade (thanks, again mike_s for your scripts), I have this section in my upgrade script:


echo "Attempting to patch tivoapp..."
SaveFile=/var/hack/Saved_Apps/tivoapp.tmp
Archive=/var/hack/Saved_Apps/tivoapp.sav
HackFile=/var/hack/hacks.fil
dstring=`date +%m-%d-%y`
cd $nrpath/tvbin
echo Creating temporary tivoapp
cp tivoapp $SaveFile

echo "Getting the hacking parameters for tivoapp..."
Failure=1
while read line
do
offset=$(( $(echo $line | cut -d" " -f1) - 0x00400000 ))
oldword=$(echo $line | cut -d" " -f2 | sed s'/"//g')
newword=$(echo $line | cut -d" " -f3 | sed s'/"//g')
echo $oldword $newword $offset
B1=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c9-12 )
B2=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c14-17 )
testword=$B1$B2
echo $testword
# Check to make sure the bytes match
if [ "$testword" == "$oldword" ];
then
echo Updating tivoapp $( echo $line | cut -d" " -f4)
# Convert the string into a 4 byte number expression
escape="\x"
H1=${newword:0:2}
H2=${newword:2:2}
H3=${newword:4:2}
H4=${newword:6:2}
newword=$escape$H1$escape$H2$escape$H3$escape$H4
echo -ne "$newword" | dd conv=notrunc of=$SaveFile bs=1 seek=$offset
elif [ "$testword" == "$newword" ];
then
echo Failed for $oldword $newword $offset
echo Tivoapp already has patch at this location.
test -e $SaveFile && rm $SaveFile
exit 1
else
echo Failed for $oldword $newword $offset Old value: $testword
test -e $SaveFile && rm $SaveFile
exit 1
fi
done < $HackFile
echo Saving old tivoapp
test -e $Archive.$dstring && mv $Archive.$dstring $Archive.$dstring.safety
mv tivoapp $Archive.$dstring
mv $SaveFile tivoapp
echo
echo Done!

where $nrpath has been defined as the mount point for the standby root partition. No offense to anyone, but I've never quite seen the point of being able to patch variably different tivoapp files and patchfiles, or of specifying a patch version to use. OTOH, my method checks to make sure the patch is actually the one I should be applying by inspecting the word about to be patched, aborting the process if the expected value is not found at the specified location, or if the location has already been patched. All I personally have to do, however, is cut-and-paste the patch file and then run the appropriate script.

lrhorer
03-11-2011, 12:37 AM
Thanks for the help. I managed to hose the Tivo, so that it was stuck at the "almost there" screen. So I took the drive out, hooked it up the my computer, and restored the bootpage and kernel using Winmfs. That fixed the Tivo so it now boots as it should and all my shows are there. I still have bash, too, which seems strange, since I was restoring from unhacked 11.0j kernel/bootpage. Also, the Tivo shows 11.0k as active. And now bootpage -p shows my root is hda7 (it was hda4 before I made whatever mistake I made). I know this is all low-level for you wizards, but I'd sure appreciate some advice on what to do, while I still have telnet. As ever, thanks.
I suspect the lack of response in the thread to your request stems from the fact what you are reporting makes no more sense to us than to you. I respectfully submit you have confused yourself as to what was actually done. I know of no way an unhacked kernel would ever allow a modified TiVo to boot, not even AFAIK the simple variation of adding the telnet daemon to rc.sysinit.author. OTOH, once a kernel has been neutered, an ftp server copied to the hard drive, and the telnet server added to rc.sysinit.author, one has a system to which all the other hacks can be applied remotely.

leeclarke
03-11-2011, 10:18 AM
First, Irhorer: Mea culpa re: post 53. My bad.

Second, I've plugged in the patch locations (from post#12), to create a tvapppatches.tcl. Uploaded tvapppatch.tcl and tvapppatches.tcl, run /tivo-bin/dos2unix against both files (to be safe). But I get the following error message:

Verifying patch locations...
Abort: expected 0x10400008 but got 0x25080001 @ 0x007c5140

Content of tvapppatches.tcl (not the top stuff):
array set patch_11.0k {
0x005d2dec "104000aa 100000aa"
0x006562a0 "30b000ff 00008021"
0x006562c4 "00e08821 24110000"
0x00774f74 "00008021 24100001"
0x01046970 "30b000ff 00008021"
0x009b3b20 "12400003 10000003"
0x00b93eb8 "0c2e5325 00000000"
0x007c5140 "10400008 10000008"

}

array set desc_11.0k {
0x005d2dec "noencryption"
0x006562a0 "cci1"
0x006562c4 "cci2"
0x00774f74 "backdoors"
0x01046970 "cci3"
0x009b3b20 "deletethisrecording?"
0x00b93eb8 "nopauseads"
0x007c5140 "nothanks"

}

mike_s
03-11-2011, 12:56 PM
I get the following error message:

Verifying patch locations...
Abort: expected 0x10400008 but got 0x25080001 @ 0x007c5140

Content of tvapppatches.tcl (not the top stuff):
array set patch_11.0k {
...
0x007c5140 "10400008 10000008"
}

array set desc_11.0k {
...
0x007c5140 "nothanks"
}
tvapppatch.tcl is saving you from trashing your tivoapp. The line 0x007c5140 "10400008 10000008" says, at location 0x007c5140, you should find the value of 10400008; change it to 10000008. The message you're getting says it found something else, so it's not going to mess with it.

Either that patch is bad, or you're running tvapppatch against the wrong version of tivoapp. That could happen if the "top stuff" you didn't show has a comparision which matches both beta and final tivoapp versions, but the patch only works on one of them.

Post that "top stuff," plus the output of the command
cat /etc/build-version

leeclarke
03-11-2011, 01:13 PM
Top stuff:
#
# tvapppatches.tcl is not meant to be run directly.
# it is sourced by tvapppatch, and contains patches to be
# applied to tivoapp. The format is as below, with the name set
# to "patch_"+sw version, followed by the patch location, the
# expected original contents, and the new value.
#
# If the original contents field is set to "dontcare", it will
# not be checked.
#
# input: sw (software version)
# output: patcha (array name for patch)
#

if { [regexp {^11\.0k-01-2} $sw] } {
set patcha "patch_11.0k"
set patchd "desc_11.0k"

cat/etc/build-version:
b-11-0-mr @412723 2010.08.25-0931 release-mips [] ARM_IDL_FREEZE CDDB_QUERY DCT_SERIAL DSS_SERIAL
HPK IDL_FREEZE IRBLAST LOCAL_CALYPSO_SERVER LOCAL_MP3_PLAYER LOCAL_MUSIC_PLAYER LOCAL_PHOTO_VIEWER
LOCAL_WMA_PLAYER MACROVISION MULTI_ROOM_VIEWING PERF_LOGGER PERF_LOGGER_USER_STATS PTHREADS_TMK
REQUIRE_PRODUCTION_SPIGOT_LINEAGE
SANITIZE_LOGS STRONG_CRYPTO T2KSOURCE US_CABLE_AUTO_DETECT WMDRMPD
2010.08.25-0931 11.0j-01-2

echo mls | SwSytem | tivosh:
Name Type FsId Date Time Size
---- ---- ---- ---- ---- ----
11.0k-01-2-652 tyDb 777954 03/04/11 07:09 908
ACTIVE tyDb 777954 03/04/11 07:09 908

mike_s
03-11-2011, 01:30 PM
Top stuff:

if { [regexp {^11\.0k-01-2} $sw] } {
set patcha "patch_11.0k"
set patchd "desc_11.0k"

cat/etc/build-version:
...
2010.08.25-0931 11.0j-01-2

echo mls | SwSytem | tivosh:
Name Type FsId Date Time Size
---- ---- ---- ---- ---- ----
11.0k-01-2-652 tyDb 777954 03/04/11 07:09 908
ACTIVE tyDb 777954 03/04/11 07:09 908My guess is, your system isn't fully upgraded. You have version 11.0k in MFS, but your root partition seems to have 11.0j. That explains why the 11.0k patching failed - your tivoapp is 11.0j. tvapppatch.tcl looks in MFS to determine the the version to patch.

11.0k is probably on the alternate kernel/root, but unhacked. Simply changing bootparms will likely leave you with an unhacked system.

lrhorer
03-11-2011, 05:32 PM
First, Irhorer: Mea culpa re: post 53. My bad.
No worries. It's easy to get confused about exactly what steps one has taken and their implications, especially when one is new at something. If you please, however, it is LRhorer, not IRhorer.

mike_s
03-11-2011, 07:48 PM
11.0j-01-2

echo mls | SwSytem | tivosh:
Name Type FsId Date Time Size
---- ---- ---- ---- ---- ----
11.0k-01-2-652 tyDb 777954 03/04/11 07:09 908
ACTIVE tyDb 777954 03/04/11 07:09 908I looked up in the thread, and see you restored the root partition...you say your current root is /dev/hda7. You can verify that with the mount command
tivo3:~$ mount
/dev/hda4 on / type ext2 (ro)
/dev/hda9 on /var type ext2 (rw)
/proc on /proc type proc (rw)
Mine is running on /dev/hda4, as shown. You can check what's in the alternate root with this (you'd use /dev/hda4 with the mount command):

tivo3:~$ mkdir /var/otherroot
tivo3:~$ mount /dev/hda7 /var/otherroot
tivo3:~$ cat /var/otherroot/etc/build-version
b-11-0-mr @412723 2010.08.25-0931 release-mips [] ARM_IDL_FREEZE CDDB_QUERY DCT_SERIAL DSS_SERIAL HPK IDL_FREEZE IRBLAST LOCAL_CALYPSO_SERVER LOCAL_MP3_PLAYER LOCAL_MUSIC_PLAYER LOCAL_PHOTO_VIEWER LOCAL_WMA_PLAYER MACROVISION MULTI_ROOM_VIEWING PERF_LOGGER PERF_LOGGER_USER_STATS PTHREADS_TMK REQUIRE_PRODUCTION_SPIGOT_LINEAGE SANITIZE_LOGS STRONG_CRYPTO T2KSOURCE US_CABLE_AUTO_DETECT WMDRMPD
2010.08.25-0931 11.0j-01-2
tivo3:~$ umount /var/otherroot
tivo3:~$ rmdir /var/otherroot
tivo3:~$
I'm running 11.0k, so my alternate has the previous 11.0j in it, as shown above.

leeclarke
03-12-2011, 04:14 PM
This is helpful. Thanks. My current version is 11.0j and current root is /dev/hda7. My alternate version and root are 11.0k and hda4. So I should be able to copy hacks, iptables, rc.sysinit.author, etc. from hda7 to hda4. Then dd my Jamie kernel to /dev/hda3. Then reboot (or possibly even use Scanman's manualupgrade.tcl). Or does one run installSw.itcl to have the system reboot. Is that correct?

ScanMan
03-12-2011, 05:49 PM
This is helpful. Thanks. My current version is 11.0j and current root is /dev/hda7. My alternate version and root are 11.0k and hda4. So I should be able to copy hacks, iptables, rc.sysinit.author, etc. from hda7 to hda4. Then dd my Jamie kernel to /dev/hda3. Then reboot (or possibly even use Scanman's manualupgrade.tcl). Or does one run installSw.itcl to have the system reboot. Is that correct?On your current root you want to edit installSw.itcl to change the reboot line to exit 0. Then run it; it will install the upgrade on the alternate root and then exit (not reboot). Then copy over the hacks, rc.sysinit.author, iptables, bcmenet.o (for custom kernel) over to the new root and dd your kernel into the new boot. Then manually reboot into the upgraded system. It's just as easy to do it by hand; I'm afraid my script could trip you up as it really is tuned to my setup. If you want to try it, I attached a stripped down version that I just use now for Series 3 and Tivo HD (the other one could do S2.5, DT). I just used it to upgrade a Series 3; read through it first and make sure you start clean (for ex: if you already edited installSw.itcl, it will screw up the script). Follow along with the output:

bash-2.02# echo mls /SwSystem | tivosh
Directory of /SwSystem starting at ''

Name Type FsId Date Time Size
---- ---- ---- ---- ---- ----
11.0k-01-2-648 tyDb 996399 03/10/11 20:55 884
11.0k.E1-01-2-648 tyDb 942524 02/20/11 12:49 916
ACTIVE tyDb 942524 02/20/11 12:49 916

bash-2.02# cd /var/hacks
bash-2.02# ls
S3Upgrade.tcl
TivoWebPlus
bcmenet.o
tvapppatch.tcl
tvapppatches-11.0k.tcl
vmlinux-Gen05-netopt-ext3.px.gz
bash-2.02#
bash-2.02# ./S3Upgrade.tcl
Your hardware generation is 648
Do you want this script to automatically edit and run /tvbin/installSw.itcl for you? [y/n]:
y
Remounting root as read-write.
Backing up original installSw.itcl to installSw.itcl.bak.
Replacing original installSw.itcl with modified one.
Remounting root as read-only.
Running modified installSw.itcl...
03/12:22:27:53: ./S3Upgrade.tcl: Installing "11.0k-01-2-648".
Installing module utils
03/12:22:27:53: ./S3Upgrade.tcl: Executing updateroot /dev/hda /install /var/packages 11.0k-01-2-648
Path prefix is /var/utils/
Sha1hash passed for updatekernel
Sha1hash passed for checkkernel.tcl
Sha1hash passed for messagelib.tcl
Sha1hash passed for buildskeleton
Sha1hash passed for SwInstall.tcl
Sha1hash passed for builddev

Searching /etc/fstab for current root

Old root is on /dev/hda7, new one goes on /dev/hda4

Creating new filesystem on /dev/hda4

Mounting new root filesystem on /install

Installing module core
Installing module hpk-Gen05
Installing module locale-en_US
Installing module eiger
Installing module kernel-Gen05
Building basic filesystem skeleton on /install


Checking /install/etc/fstab

newroot is 4, leaving fstab alone
Creating symlinks for /install/etc files
Dismounting /install and checking its integrity


Initializing First Activation Date


Modifying bootparams to point to /dev/hda4

Creating upgrade messages
upgrade_73_ptcm.msg does not apply to 648
upgrade_73_mb.msg does not apply to 648
Flipping root, setting boot parameters to 'root=/dev/hda4 dsscon=true console=1,115200 upgradesoftware=false'

OK, reboot the system to use the new root filesystem

03/12:22:30:09: ./S3Upgrade.tcl: Attempting reboot...
installSw.itcl should have completed without error. If so, do you want to continue? [y/n]:
y
Determining active boot partition.
Your new bootpath is /dev/hda3
Your new rootpath is /dev/hda4
Mounting /dev/hda4 at /mnt.

Choose one of the following kernel options:

1. Install custom (i.e. Jamie) kernel
2. Replace stock kernel with null-initrd
3. Do nothing and continue

1
Checking for custom kernel...
vmlinux-Gen05-netopt-ext3.px.gz found. Proceeding...
Unzipping kernel...
Installing vmlinux-Gen05-netopt-ext3.px kernel to /dev/hda3.
This may take a minute, be patient...
1653248+0 records in
1653248+0 records out
gzipping vmlinux-Gen05-netopt-ext3.px, just a few more seconds...
Generation 648 with a custom kernel requires bcmenet.o to use
built-in ethernet port. Do you want to install bcmenet.o? [y/n]:
y
Checking for bcmenet.o...
File found. Backing up original bcmenet.o to bcmenet.o.bak
Copying custom bcmenet.o to /mnt/platform/lib/modules
Copying rc.sysinit.author.
Do you want to replace iptables with an "exit 0" dummy script? [y/n]:
y
Checking for /etc/profile...
Copying /etc/profile.
Checking for /etc/passwd
/etc/passwd not found.
Checking for /etc/group
/etc/group not found.
Checking for /hack
/hack not found.
Checking for /hacks
Copying /hacks to /mnt.
Checking for /mfs_ftp
/mfs_ftp not found.
Checking for /tivowebplus
/tivowebplus not found.
Checking for /TivoWebPlus
/TivoWebPlus not found.
Checking for /busybox
/busybox not found.
Checking for /tivo-bin
/tivo-bin not found.
Checking for /devbin
/devbin not found.
Checking for /tivotool
/tivotool not found.
Checking for /tivotools
/tivotools not found.
The script has completed your manual upgrade. You may reboot into your upgraded system.
bash-2.02#
bash-2.02# mount
/dev/hda7 on / type ext2 (ro)
/dev/hda9 on /var type ext2 (rw)
/proc on /proc type proc (rw)
/dev/hda4 on /mnt type ext2 (rw)
bash-2.02#
bash-2.02# ./tvapppatch.tcl -p ./tvapppatches-11.0k.tcl -t /mnt/tvbin/tivoapp

tvapppatch.tcl 1.6, 1/11/2008 ("tvapppatch.tcl -help" for instructions)

We will be patching /mnt/tvbin/tivoapp.
Patching active TiVo Software version 11.0k-01-2-648
Looking for patches in ./tvapppatches-11.0k.tcl...
patch_11.0k found!...OK

Make sure you've backed up your tivoapp!
Ready to patch (Y/N)? y

Verifying patch locations...OK
Patching tivoapp...OK
bash-2.02# reboot

mike_s
03-12-2011, 09:48 PM
This is helpful. Thanks. My current version is 11.0j and current root is /dev/hda7. My alternate version and root are 11.0k and hda4. So I should be able to copy hacks, iptables, rc.sysinit.author, etc. from hda7 to hda4. Then dd my Jamie kernel to /dev/hda3. Then reboot (or possibly even use Scanman's manualupgrade.tcl). Or does one run installSw.itcl to have the system reboot. Is that correct?You shouldn't have to run installSw.itcl. It builds the new root, and it looks like your's is already done. Just type "reboot" to reboot after making appropriate changes to the new root and copying the kernel.

Thinkdiff
03-13-2011, 04:53 AM
You shouldn't have to run installSw.itcl. It builds the new root, and it looks like your's is already done. Just type "reboot" to reboot after making appropriate changes to the new root and copying the kernel.

He'll also have to run bootpage a few times to flip the kernel partition and the root partition, ie:

bootpage -f
bootpage -p "root=/dev/hda4 upgradesoftware=false"

leeclarke
03-13-2011, 02:29 PM
On flipping, assuming current root is hda4, are both of these necessary?

bootpage -f /dev/hda4
bootpage -f /dev/hda3

mike_s
03-13-2011, 03:04 PM
Neither. In fact, it may even screw up your partitions. You run bootpage on the drive (/dev/hda), not on a partition (/dev/hda[1-n]). Do a single
bootpage -f /dev/hdaThat should change it to boot from the other partition. To check, do a
bootpage -p /dev/hdaNote, that's a lower case "p." I grabbed this from somone's post, probably around here:

The TiVo uses a utility called bootpage to set parameters in the boot disk's boot block. Since there's no documentation on this, I whipped up the following quick usage info for my own benefit. Perhaps others will find it useful as well.
usage: /sbin/bootpage options... device

-p dev - print existing args
-P string dev - set args to "string"
-D dev - create default boot page on dev
-B num - set primary boot to partition num
-A num - set alternate boot to partition num
-b dev - print current value of primary boot
-a dev - print current value of alternate boot
-f dev - swap (flip) values of primary and alternate boot partitions
-q dev - ???

leeclarke
03-13-2011, 03:11 PM
bootpage -p shows the same "root=dev/hda4" before and after bootpage -f /dev/hda

The commands above come from here, I think:
http://www.courtesan.com/tivo/bootpage.html

mike_s
03-13-2011, 04:19 PM
Doh. It's been a while, since I've automated things. Check bootpage with
bootpage -b /dev/hdaIt should say 3 or 6. If you want to boot from the 3/4 pair, and it says 6, do a "bootpage -f /dev/hda" Then when you check again, it should return 3. That takes care of which kernel you're booting from. Then, you need to set the boot string to match. That's done with

bootpage -p /dev/hdato get your current one, then

bootpage -P "root=/dev/hda4 dsscon=true console=1,115200 upgradesoftware=false"note: capital P, and the quotes are necessary. root will point to either 4 or 7, to match a kernel in 3 or 6. The rest of the string should match what you already have - the "console=..." may be different depending on model.

leeclarke
03-14-2011, 11:59 AM
Thanks to all, particularly for your patience......

Anzio
03-14-2011, 10:04 PM
Thanks ScanMan and others,

I used your S3Upgrade script to upgrade my TiVoHD tonight and it worked great!! It makes the upgrades a breeze.

Regards
Anzio

djl
03-15-2011, 11:58 AM
Just curious: has anyone else installed Thinkdiff's OpenVPN kernel? I tried it when I did the upgrade to the final version of 11.0k, but couldn't get it to boot (just went to a grey screen.) I didn't have enough time to do any decent troubleshooting so I reinstalled Jamie's Gen06-netopt-ext3.
If I have a chance I'll get out the serial cable, etc and try again.

Thinkdiff
03-15-2011, 06:55 PM
Just curious: has anyone else installed Thinkdiff's OpenVPN kernel? I tried it when I did the upgrade to the final version of 11.0k, but couldn't get it to boot (just went to a grey screen.) I didn't have enough time to do any decent troubleshooting so I reinstalled Jamie's Gen06-netopt-ext3.
If I have a chance I'll get out the serial cable, etc and try again.

I believe I'm still running the OpenVPN kernel on 11.0k (I just dd'd the old kernel partition to the new one).

I'll double check with the kernel I posted when I get back to that TiVo on thursday (spring break! woo! ;))

djl
03-15-2011, 08:17 PM
Hey thanks, but I doubt the difference between the 11.0k.E1 and the final version was the problem. It wasn't booting at all. I'm trying to figure out what might be different about my setup, and the only thing I've come up with is that I run routerplus in place of router.o. Maybe that's incompatible with your kernel?

I believe I'm still running the OpenVPN kernel on 11.0k (I just dd'd the old kernel partition to the new one).

I'll double check with the kernel I posted when I get back to that TiVo on thursday (spring break! woo! ;))

Sbmocp
03-25-2011, 08:23 PM
I've omitted the nopromos patch since it breaks the video on demand stuff. If anyone really wants it let me know & I'll port it.
The 30secskip patch is no longer necessary - once you enable it via the remote it stays enabled, even across reboots & software upgrades. I've only included it here so the Aussies can find & port it to their software version (where 30secskip is intentionally disabled).


-psxboy

I'm surprised that no one's figured out how to separate the nopromos and VOD patches. I take it that that code is "TiVo proprietary" and not published anywhere?

Soapm
11-30-2011, 04:05 AM
Here is what I ran


0x005d353c "104000aa 100000aa" //noencryption
0x006562a0 "30b000ff 00008021" //cci1
0x006562c4 "00e08821 24110000" //cci2
0x00774f74 "00008021 24100001" //backdoors
0x01046970 "30b000ff 00008021" //cci3
0x00b8f910 "14400026 10400026" //30secskip

And I got


Getting the hacking parameters for tivoapp
104000aa 100000aa 1914172 08250100
Failed for 104000aa 100000aa 1914172 Old value: 08250100

Could it be tivo changed tivoapp from the original release?

psxboy
11-30-2011, 12:55 PM
Those are the patches for version 11.0j. I assume you have the latest version, 11.0k? The correct patches for that version are in post #12 (http://www.dealdatabase.com/forum/showthread.php?64081-11-0k-starting-to-roll-out&p=310041#post310041) on the first page of this thread.

-psxboy

Soapm
11-30-2011, 01:15 PM
Those are the patches for version 11.0j. I assume you have the latest version, 11.0k? The correct patches for that version are in post #12 (http://www.dealdatabase.com/forum/showthread.php?64081-11-0k-starting-to-roll-out&p=310041#post310041) on the first page of this thread.

-psxboy

I tried the first set of code from that post with the same results and my encryption is still active;


11.0k
0x005d2dec "104000aa 100000aa" //noencryption
0x006562a0 "30b000ff 00008021" //cci1
0x006562c4 "00e08821 24110000" //cci2
0x00774f74 "00008021 24100001" //backdoors
0x01046970 "30b000ff 00008021" //cci3
0x009b3b20 "12400003 10000003" //deletethisrecording?
0x00b8f910 "14400026 10400026" //30secskip
0x00b93eb8 "0c2e5325 00000000" //nopauseads

Results


Getting the hacking parameters for tivoapp
104000aa 100000aa 1912300
4010aa00
Failed for 104000aa 100000aa 1912300 Old value: 4010aa00

That post also has other codes that I didn't try because I don't know what they do and because I didn't know what NoMEK meant. I am trying to be selective about which patches I apply since I like having the delete this recording warning and the last time I patched 11.0k I noticed all the shows I transferred from my premier to my TivoHD would be blank. No video or sound. Just files...


11.0k NoMEK
0x005d2de8 "92220024 27a40028"
0x005d2dec "104000aa 0c156af0"
0x005d2df0 "27a40028 00000000"
0x005d2df4 "0c156af0 0c424796"
0x005d2dfc "8fa20020 106000aa"
0x01091e30 "27bdfec8 03e00008"
0x01091e34 "afb40128 24020001"
0x01091e58 "00a0a021 8e230040"
0x01091e5c "0c1b61e6 10600002"
0x01091e60 "00602821 00000000"
0x01091e64 "00408021 8c630000"
0x01091e68 "1200000a 03e00008"
0x01091e6c "00001021 8fa20020"

Then there was this code but again, what is no thanks and ignoredrmsig???


0x007c5140 "10400008 10000008" //nothanks
0x0056a3a4 "1200ffaf 1000ffaf" //ignoredrmsig1
0x00598024 "1200ff87 1000ff87" //ignoredrmsig2

psxboy
11-30-2011, 01:52 PM
Failed for 104000aa 100000aa 1912300 Old value: 4010aa00

You're either trying to patch a tivoapp that isn't version 11.0k or else the tivoapp is corrupted in some way. The error is basically saying it checked the existing value at the address it's supposed to patch & it doesn't match what is supposed to be there, so it stopped running to prevent damage to the tivoapp file.


That post also has other codes that I didn't try because I don't know what they do and because I didn't know what NoMEK meant. I am trying to be selective about which patches I apply since I like having the delete this recording warning and the last time I patched 11.0k I noticed all the shows I transferred from my premier to my TivoHD would be blank. No video or sound. Just files...

As I explained in the original post: "[The NoMEK patch] replaces the generic noencryption patch to allow MRV of existing encrypted recordings." If you don't have any existing encrypted recordings on the drive that you want to be able to MRV to another Tivo at some later point in time, you don't need it.


Then there was this code but again, what is no thanks and ignoredrmsig???

The "no thanks" patch prevents the pending restart state & nightly reboots when the Tivo downloads an updated software install. It's for people who want to wait on an upgrade but don't want to deal with the daily reboots. You still need "upgradesoftware=false" in your bootpage though to prevent the install after an accidental reboot. And the ignoredrmsig patches cause the Tivo to bypass the checks on a recording's DRM signatures. This allows you to selectively remove values from the DRM MFS object for a recording (of particular interest, the CCI bytes). Normally that would invalidate the signature but with these patches in place the Tivo should ignore the signature all together.

-psxboy

Soapm
11-30-2011, 02:08 PM
I figured it out, it has to do with the patcher I was using. I included both patcher's, the one that worked is second and the first is the one causing the error. I was probably doing something wrong with it.

7365
7366

ps... These are the patches I ran which disabled my encryption but when I try to watch shows from my premier on my TivoHD they are again coming in blank. I wonder if Tivo added a hitch in my git along or if one of these patches is causing this to happen. I put the original Tivoapp back and rebooted and the phenomenon went away so it has something to so with tivoapp...


if { [regexp {^11\.0k-01-2} $sw] } {
set patcha "patch_11.0k"
set patchd "desc_11.0k"
}

array set patch_11.0k {
0x005d2dec "104000aa 100000aa"
0x006562a0 "30b000ff 00008021"
0x006562c4 "00e08821 24110000"
0x00774f74 "00008021 24100001"
0x01046970 "30b000ff 00008021"
}

array set desc_11.0k {
0x005d2dec "noencryption"
0x006562a0 "cci1"
0x006562c4 "cci2"
0x00774f74 "backdoors"
0x01046970 "cci3"
}

psxboy
11-30-2011, 02:18 PM
You can't MRV between a hacked Tivo with encryption disabled and an unhacked Tivo. Your Premiere is certainly not hacked because there are no public methods for bypassing the PROM check (yet) so unless you forgo disabling encryption on your TivoHD you will be unable to transfer recordings between the two.

-psxboy

Soapm
11-30-2011, 02:49 PM
You can't MRV between a hacked Tivo with encryption disabled and an unhacked Tivo. Your Premiere is certainly not hacked because there are no public methods for bypassing the PROM check (yet) so unless you forgo disabling encryption on your TivoHD you will be unable to transfer recordings between the two.

-psxboy

Oh??? Yea, that's what I was trying to say!

J/K... Thanks, didn't realize that... No biggie since I will soon be getting rid of the premier. The wife and daughter find Tivo to complicated to operate and want Tivo-less TV watching back for them...

jmartz
12-04-2011, 12:18 PM
Hey so I have to upgrade to this version. It seems the media access key is no longer valid. Anyway, I have to copy the hacks to the new partition. My tivo is "pending restart" again, so from what I have read that means the new file system is ready to go, the tivo just wants to change my boot partition. I am not letting it execute the update script via the bootpage "noupdate" command.

I am using partitions 6 and 7 right now.

I just want to confirm what I think I have found on this forum since stuff is all over the place and everyone seems to have a different way of either automating stuff or doing it manually.

1. I need to copy my current modified kernel from partition 6 to partition 3.
2. I need to copy "rc.sysinit.author" file from "hda7/etc/rc.d" to "hda4/etc/rc.d"
3. After that's done I can execute installSw.itcl and let the tivo reboot into the new software.
4. Go back into Telnet (assuming it still works) and modify the tivoapp using the DD commands listed above in this same thread.

Is it OK to modify the software once the Tivo is booting into it? All I want is for it to ignore copy protection.

Soapm
12-04-2011, 01:34 PM
You have the basics of it correct but application gets a little more involved. Do you have a linux machine where you can attach the drive? Now that I have one I see this can be more easily explained since you'll have a good visual of the entire drive.

If not there are upgrade scripts such as the one ScanMan posted that will do the job for you. I believe lrhorer has a good one also but I can't find it right now. These scripts give you the basic steps that must be followed if you want to do the upgrade manually.

http://www.dealdatabase.com/forum/showthread.php?48925-Manual-upgrade-to-7-2-2&p=288733#post288733

If you go up a few post you will see where the guys ran it down to me some years ago.

The basics are this, any directories you created outside of var has to be copies to the new partitions to include what your using for busybox (utils, tivo-bin etc...). It might be easier just to nueter your new kernel or if you're using Jamies customs I just insert a fresh one but you can copy over the one you're using easy enough. If you're using a nuetered stock kernel then I would suggest nuetering the new one as opposed to reusing the previous since it went with the provious OS. Jamies customs should still work.

In the link I provided this is what ScanMan wrtoe in post 44...

The critical pieces of any hack are:
1. kernel
2. network drivers
3. rc.sysinit.author
4. iptables
Any one of those borked will result in reboot loops. Oh yeah and make sure you've got the serial working for console bootlog captures.

jmartz
12-04-2011, 04:22 PM
I was not able to get anything working other than the telnet when I first hacked this thing. I have Ubuntu on a laptop, so you seem to be suggesting that plugging the drive into Ubuntu directly might make things easier? Will it show me the drive visually as opposed to using the terminal? If thats the case, I think I will just force the reboot to the new OS and just rehack from scratch. -- Which makes me wonder if I should even bother hacking the new version (thats not really new anymore). Maybe I should just wait until 11.L comes out or whatever is next and then hack that one.

Soapm
12-04-2011, 04:45 PM
Yes, it helped me a great deal being able to visually see the drive in Linux.

You will need to search for a file called "tivopart" and put that on your linux machine so it can see your Tivo drive...

Once you attach the drive to your linux machine do a fdisk -l and find out where the drive loaded. Lets say the tivo drive is sdb, then you would run tivo part by using "tivopart r /dev/sdb" (be sure to include the path to tivopart).

After that you can go into your disk manager and mount the two root partitions and var then pull them up and visually look at them.

I mount mine as root1 and root2. This means moving the directories for me is typing "cp /media/root1/hack /media/root2/hack".

This will make more sense once you visually see the drive...

lrhorer
12-04-2011, 10:58 PM
Hey so I have to upgrade to this version. It seems the media access key is no longer valid.
Unless the account has hanged on tivo.com, the MAK should not have changed. That said, the MAK is not required for hacking the TiVo. What makes you think the MAK has changed or that it is relevant to hacking the TiVo?


Anyway, I have to copy the hacks to the new partition. My tivo is "pending restart" again, so from what I have read that means the new file system is ready to go, the tivo just wants to change my boot partition.
Maybe you alreacy know this, but typically the installer will change both the root and boot partitions.


1. I need to copy my current modified kernel from partition 6 to partition 3.
That may not be the best idea. TiVo made some changes to their kernel a version or two ago. Among other things, they added support for the BlueTooth remote. I would recommend either using one of Jamie's custom kernels or neutering the new kernel.


2. I need to copy "rc.sysinit.author" file from "hda7/etc/rc.d" to "hda4/etc/rc.d"
Well, logically that is more or less correct, but it is certainly not how it is accomplished. /dev/hda4 and /dev/hda7 are block device files. One cannot copy a file into them. Ordinary copying requires the file system residing in the locations pointed to by the device files to be mounted on directories. Once the partitions are mounted, then one can simply use the `cp` command, or something similar.

It's likely you want to transfer a lot more than just /etc/rc.sysinit.author, though. At a bare minimum you also want to transfer an ftp client, a hacked iptables, and probably a great deal more. That's why for the script linked in my signature I created a single tarball with all the hack files in it. If one is re-hacking by removing the drive, it is the fastest and easiest approach, IMO. If one is going to attempt to re-hack the TiVo from within a running TiVo, I recommend something more like mike_s' approach to scripted upgrades. This involves enlarging the unused partitions 2 and 5 and creating a file system on them. One can then keep the bulk of all the hacks on those two partitions, and the upgrade software won't touch them, or at least not one of them. This leaves only the kernel, tivoapp, and rc.sysinit.author about which to worry:


TiVo_HD:/# pdisk -l /dev/hda

stat: mode = 060660, type=Block
size = 0, blocks = 0
HDIO_GETGEO: heads=255, sectors=63, cylinders=56065, start=0, total=900684225
Partition map (with 512 byte blocks) on '/dev/hda'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1 ( 31.5K)
2: Ext2 Hack 1 524288 @ 64 ( 256.0M)
3: Image Kernel 1 8192 @ 524352 ( 4.0M)
4: Ext2 Root 1 524288 @ 532544 ( 256.0M)
5: Ext2 Hack 2 524288 @ 1056832 ( 256.0M)
6: Image Kernel 2 8192 @ 1581120 ( 4.0M)
7: Ext2 Root 2 524288 @ 1589312 ( 256.0M)
8: Swap Linux swap 262144 @ 2113600 ( 128.0M)
9: Ext2 /var 524288 @ 2375744 ( 256.0M)
10: MFS MFS application region 589824 @ 2900032 ( 288.0M)
11: MFS MFS media region 137630712 @ 3489856 ( 65.6G)
12: MFS MFS application region 2 589824 @ 141120568 ( 288.0M)
13: MFS MFS media region 2 171919990 @ 141710392 ( 81.9G)
14: MFS MFS App by Winmfs 2048 @ 313630382 ( 1.0M)
15: MFS MFS Expanded by Winmfs 1639874560 @ 313632430 ( 781.9G)

TiVo_HD:/# df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/hda7 248M 145M 90M 62% /
/dev/hda9 248M 52M 183M 22% /var
/dev/hda2 248M 79M 156M 34% /var/hack

TiVo_HD:/# mount
/dev/hda7 on / type ext2 (ro)
/dev/hda9 on /var type ext2 (rw)
/proc on /proc type proc (rw)
/dev/hda2 on /var/hack type ext2 (rw)

TiVo_HD:/# ls /var/hack
Saved_Apps lost+found
TivoWebPlus null-linuxrc.img.gz
etc tivowebplus-v2.1.b3-090404.tar
hacks.fil utils
hackt.tar

TiVo_HD:/# ls /var/hack/utils/
NowShowing hostname pipe_progress
Superpatch67Standby.tcl hush postinstall
TuikHelper.tcl ifconfig ps
[ ipcalc read-only
[[ kill read-write
ash locate replace_initrd.mips
awk ls replace_initrd.mips.tar
bunzip2 lsmod reset
busybox md5sum sdiff
bzcat mfs_bitmap sed
cat mfs_burstcmds seq
chroot mfs_dump setsid
ciphercheck mfs_dumpobj strings
clear mfs_dumpschema swversion
cmp mfs_export tail
crond mfs_findzero tar
cut mfs_fsidtype telnet
date mfs_getslice test
dbload mfs_import tivoftpd
diff mfs_info top
dos2unix mfs_ls touch
drmcheck.tcl mfs_poke traceroute
e2fsck mfs_purge true
echo mfs_stream tserver
env mfs_streams tty
expr mfs_tarstream unix2dos
false mfs_tmfstream unzip
find mfs_tzoffset uptime
free mfs_uberexport vi
ftpget mkswap vplay
ftpput more vserver
fuser msh watch
getopt netstat wget
gunzip nohup which
gzip patch xargs
head pidof yes
hexdump ping zcat

TiVo_HD:/# ls /var/hack/etc
npf.txt npfauto.txt rootfiles

TiVo_HD:/# ls /var/hack/etc/rootfiles/
crontabs iptables profile termcap
group passwd rc.sysinit.author vt100


3. After that's done I can execute installSw.itcl and let the tivo reboot into the new software.
No, you want to run installSw.itcl before updating your hacks. If you are going to pull the drive, then go ahead and run installSw.itcl, reboot the Tivo to finalize the upgrade, and then pull the drive. If you want to re-hack the TiVo without pulling the drive, then you need to neuter installSw.itcl so it does not automatically reboot, run it, copy your changes over, and then reboot.


4. Go back into Telnet (assuming it still works) and modify the tivoapp using the DD commands listed above in this same thread.
Well, it's a bit more difficult than that on an active TiVo. When the TiVo is active, tivoapp is running, and the file is open. This means you can't just change the file. You must move the file to a new name (like tivoapp.sav), make a copy of the file with the old name, hack the inactive copy, and then reboot. In addition, rather than typing all those `dd` commands, you can use one of the scripts some of us have created to simplify the task. I believe one is named tivoapp_patch.tcl, or some such. There is also the one I call hack_tivoapp in the link in my signature. By replacing the five lines I note in the post with the two below it, one can use the script on an inactive copy of tivoapp on a running TiVo.


Is it OK to modify the software once the Tivo is booting into it? All I want is for it to ignore copy protection.
Yeah, surely. Once the kernel is neutered, the system will no longer erase any hacks that are applied to it. I think at a minimum you will need busybox in order to effect a hack on a TiVo that has nothing other than a neutered kernel on it. While ftp is perhaps not absolutely required, it certainly can make things much easier. That's an awful lot of work - potentially required several more times - that can be alleviated with a little bit of preparation. It's much like preferring to use a dull axe to chop down a tree rather than taking just a little time before hand to sharpen the axe.

jmartz
12-04-2011, 11:00 PM
*** I WAS TYPING THIS AT THE SAME TIME Irhorer WAS TYPING HIS POST ABOVE!! *** Thanks for the information above!! It does make sense. I will rename the active file, copy that, modify it, then put it back and reboot. But I still need to get FTP active. The thread I used to get the upgrade done is here: http://www.dealdatabase.com/forum/showthread.php?48925-Manual-upgrade-to-7-2-2&highlight=upgrade+telnet

MY ORIGINAL POST BELOW--

So I found instructions from like 2006 or 2007 that had information about how to apply the update manually through the Telnet connection. Unfortunately since I don't have FTP enabled, there was no way for me to copy the file from the Tivo to edit it so I ended up having to pull the drive anyway. With that said, I used MFS Live. I mounted the drive, modified the installSw.itcl file and saved it. I then put the drive back into the tivo, booted it up, went back into telnet and executed the modified script. It installed the file system, and exited before rebooting. I then copied the necessary files and rebooted. The Tivo is now running 11.0K.

My next problem is applying the hacks. Since the OS is in use, it will not let me write to the TIVOAPP file. Guess that makes sense. So I will be pulling the drive out tomorrow morning and applying the hacks through MFS Live.

I think I also figured out why the FTP service will not start. In my .authors file, I don't have a space between the path to the file and the ./ command to execute the file... I'm crossing my fingers that it was really THAT stupid of a mistake.......... but at least the Tivo is talking to the Tivo servers again... it only took them 9 months to lock me out! Guess I must have gotten lucky...

Soapm
12-04-2011, 11:31 PM
That's why for the script linked in my signature I created a single tarball with all the hack files in it. .

I looked all over for your script and forgot you have it linked in your signature... Doh!!!

lrhorer
12-04-2011, 11:38 PM
*** I WAS TYPING THIS AT THE SAME TIME Irhorer
That's LRhorer, if you please. It happens.


Thanks for the information above!!
You're welcome.


But I still need to get FTP active.
I would say at a minimum, yeah.


With that said, I used MFS Live. I mounted the drive, modified the installSw.itcl file and saved it. I then put the drive back into the tivo, booted it up, went back into telnet and executed the modified script. It installed the file system, and exited before rebooting. I then copied the necessary files and rebooted. The Tivo is now running 11.0K.
The problem I have with using a live CD is it takes a fair bit more in the way of manual intervention to get things working, and then once one does get things working, one is faced with doing much of it all over a again in six months' time. By that time, I will usually have forgotten at least one or two critical details. By using a regular boot system (which can be used for many other things in addition to hacking TiVos), one can make permanent changes to the environment, and not risk forgetting something. What's more, when one does need to tweak the process a bit, having a fully functional system allows one to manage the process easily, backing everything up before proceeding. Moving from external upgrades to a variations of mike_s' scripted upgrades was much easier to accomplish by editing everything on the active system, for example. It also allows one to have a browser up, which makes downloading and cut-and-paste much easier.


My next problem is applying the hacks. Since the OS is in use, it will not let me write to the TIVOAPP file. Guess that makes sense.
Well, it can be done. After one changes the root file system to read-write, one moves the tivoapp to a new name, makes a copy of the running app, and hacks it, as I mentioned above.


So I will be pulling the drive out tomorrow morning and applying the hacks through MFS Live.
If you insist. Even the CCI byte hack requires three edits to tivoapp, and the edits must be perfect. I know I make a lot of typos, and doing such things manually always gives me the willies. Doing them over and over again just makes me weary. Of course, having three TiVos makes it triply so.


I think I also figured out why the FTP service will not start. In my .authors file, I don't have a space between the path to the file and the ./ command to execute the file
I don't know what you mean. ./ IS a path to a file, and there should never be any spaces in a pathname unless quotes are used. Secondly, if telnet is working and you already have the ftpd binary on the TiVo, then you don't have to have ftpd run in rc.sysinit.author. Just run it from the telnet session. The command (in or out of rc.sysinit.author) should be something like:


/var/hack/utils/tivoftpd

It's a daemon, so it gets detached from the parent process and attached to init, which means you can continue to do things in your telnet session without stopping the ftpd daemon and the daemon will persist in memory after you kill the telnet session until the next reboot.


... I'm crossing my fingers that it was really THAT stupid of a mistake.......... but at least the Tivo is talking to the Tivo servers again... it only took them 9 months to lock me out! Guess I must have gotten lucky...
Does the amount of time you waited to upgrade and re-hack the TiVo have anything to do with how manual you have forced the process to be by using a live CD? 'That and possibly the fact it has been nine months since you worked in a Linux environment? 'Just an observation.

lrhorer
12-04-2011, 11:53 PM
Results


Getting the hacking parameters for tivoapp
104000aa 100000aa 1912300
4010aa00
Failed for 104000aa 100000aa 1912300 Old value: 4010aa00


You're either trying to patch a tivoapp that isn't version 11.0k or else the tivoapp is corrupted in some way. The error is basically saying it checked the existing value at the address it's supposed to patch & it doesn't match what is supposed to be there, so it stopped running to prevent damage to the tivoapp file.

Hmm. Wait a minute, that is byte-swapped: 10 40 00 aa vs. 40 10 aa 00

That looks to me like the wrong version of the code was run. On an x86 platform, the script needs to do the following to convert from the "human readable" file format to hexadecimal code to be inserted into the tivoapp binary:


B1=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c11-12 )
B2=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c9-10 )
B3=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c16-17 )
B4=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c14-15 )
testword=$B1$B2$B3$B4

Where $B1, $B2, etc. are the four bytes to be written to tivoapp, and $testword is the whole string of four bytes. On a MIPS platform, the byte pairs returned by hexdump are in reverse order to that required on the x86 platform, so when running on the TiVo the script needs to be:


B1=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c9-12 )
B2=$( dd if=tivoapp skip=$offset bs=1 count=4 2> /dev/null | hexdump | grep 0000000 | cut -c14-17 )
testword=$B1$B2
Looking at the .zip file you posted above, that code is to be used on an external PC only. To use the script on the TiVo, the five lines in the code above need to be changed to the three lines below.

lrhorer
12-05-2011, 12:47 AM
And the ignoredrmsig patches cause the Tivo to bypass the checks on a recording's DRM signatures. This allows you to selectively remove values from the DRM MFS object for a recording (of particular interest, the CCI bytes). Normally that would invalidate the signature but with these patches in place the Tivo should ignore the signature all together.
Well, it doesn't ignore them, entirely, at least I don't think it does. When I downloaded a movie from Amazon, the TiVo erased the movie after I watched it. Isn't that based on the DRM signature, and in particular the CCI byte? What's more, in order to transfer the content, one does need to remove the values from the DRM signature using RemoveCpiAll.tcl after the hack is applied to tivoapp.

psxboy
12-05-2011, 12:18 PM
You're missing the point... it ignores the SIGNATURE. Once you get it to do that, you can then modify/remove values from the DRM object without causing tivoapp to object. Otherwise, it would compare the values to the signature and invalidate the recording if they don't match. But simply causing the signature to be ignored without making any changes does nothing at all.

Also, stuff you download from other sources (Amazon, VOD, etc) has an additional layer of encryption & rules applied to it that your regular recorded stuff does not. I've not examined the effect of changing DRM values on those types of recordings.

And finally, on another note... I don't know why people are so keen to remove the Tivo drive or otherwise connect it to a PC in order to complete an upgrade. You can do the same thing from a telnet session while the Tivo is running without ever touching the drive. I posted a high-level overview of how I handle upgrades here (http://www.dealdatabase.com/forum/showthread.php?59567-9-4-on-S3-HD/page2&p=298035#post298035).

-psxboy

Soapm
12-05-2011, 07:02 PM
Hmm. Wait a minute, that is byte-swapped: 10 40 00 aa vs. 40 10 aa 00

That looks to me like the wrong version of the code was run. On an x86 platform, the script needs to do the following to convert from the "human readable" file format to hexadecimal code to be inserted into the tivoapp binary:.

I knew it was something I was doing since I thought I was using the same file you previously used. I guess it wasn't...

Soapm
12-05-2011, 07:17 PM
And finally, on another note... I don't know why people are so keen to remove the Tivo drive or otherwise connect it to a PC in order to complete an upgrade. You can do the same thing from a telnet session while the Tivo is running without ever touching the drive. I posted a high-level overview of how I handle upgrades here (http://www.dealdatabase.com/forum/showthread.php?59567-9-4-on-S3-HD/page2&p=298035#post298035).

-psxboy

Maybe it's a good excuse to blow the dust out with canned air :)

Seriously, after reading your steps I can confidently say I don't have your skill set (especially modifying the partition table???)..

jmartz
12-05-2011, 10:33 PM
I did the tivoapp hacks by renaming the file in telnet, creating a copy of that file with the tivoapp name, editing that new file and rebooting. (being that I pretty much use windows, it's not normally possible to rename a working file while it's active... then creating a copy of the working file with the old name [now inactive so it can be edited], just never crossed my mind!) The hacks work fine.

I needed to pull the drive because I had no way to load MFS_FTP or Tivotools. Once I had the .RAR files in the proper places, I booted the tivo and went back into telnet and did the rest from there. I can now FTP into the tivo root and download/upload and modify the files that way.

I also "kind of" have MFS_FTP working. I can connect, list, but the second I try to download it kills the connection. So I have to figure out what is wrong with that. But that's for another topic, I think I am getting closer to the solution. This morning I couldn't even connect. Once I get that working and can download shows, I want to try and install TivowebPlus. But progress in small steps. And at least next time I can use the terminal to get the shell access, and FTP to edit/upload whatever needs to be edited.

And yes, being that I haven't worked in the Linux environment for nearly a year probably made things a bit more challenging.

lrhorer
12-05-2011, 11:19 PM
You're missing the point... it ignores the SIGNATURE. Once you get it to do that, you can then modify/remove values from the DRM object without causing tivoapp to object. Otherwise, it would compare the values to the signature and invalidate the recording if they don't match. But simply causing the signature to be ignored without making any changes does nothing at all.
OK, I see.


Also, stuff you download from other sources (Amazon, VOD, etc) has an additional layer of encryption & rules applied to it that your regular recorded stuff does not. I've not examined the effect of changing DRM values on those types of recordings.
...and even if you had, talking about it here would be verboten.


And finally, on another note... I don't know why people are so keen to remove the Tivo drive or otherwise connect it to a PC in order to complete an upgrade.
Well, before I employed mike_s' fine methods for scripted upgrades, I used to pull the drive for several reasons:

1. It was easier. With the primary drives being external to the TiVos and a tarball with all the hacks just sitting and waiting to transfer, it only took a minute to re-hack the Tivo by pulling the drive, plus boot times, of course.

2. Sometimes /var gets wiped. In or outside of an upgrade, having a ready-and-waiting tarball made replacing /var oh so much easier, and increased the attractiveness of #1 as a side benefit.

3. Before I increased the size of the partitions in order to implement mike_s' suggestions, it was not uncommon for me to run out of space on the root partition when upgrading, especially when hacking tivoapp.

4. It is fairly difficult to over-estimate the value of having a full blown Linux machine managing the drive when upgrading it rather than the highly limited OS found on the TiVo.


You can do the same thing from a telnet session while the Tivo is running without ever touching the drive.
Of course. Indeed, the changes I just made to the hack_tivoapp script make that proposition considerably easier, I would hope.

lrhorer
12-05-2011, 11:24 PM
Seriously, after reading your steps I can confidently say I don't have your skill set (especially modifying the partition table???)..
Using tivopart, it's really not very difficult, at all, just tedious and a bit nervewracking. When expanding and moving the partitions on my three TiVos, I know I must have wiped one or more partitions at least five times on each TiVo before I had it rght. Even then, it wasn't "right". I forgot to increase the size of the swap partition on all three TiVos. :mad:

psxboy
12-08-2011, 02:00 PM
Well, before I employed mike_s' fine methods for scripted upgrades, I used to pull the drive for several reasons:

Hehe... I know. We've had this argument before. But no matter how you slice it, doing the upgrade via telnet with a single reboot at the end is always gonna be faster (and for me, easier) than pulling the drives and doing it from a PC. But to each his own - whatever works for you.


2. Sometimes /var gets wiped. In or outside of an upgrade, having a ready-and-waiting tarball made replacing /var oh so much easier, and increased the attractiveness of #1 as a side benefit.

You're right, and that's why I keep my /var backup tarballs in my custom hda1. Just mount it, restore /var & you're done. All on the Tivo via telnet. And btw, /var only gets wiped if it exceeds 40% capacity (or something close to that - I'm going from memory) or if it fails the fsck twice at boot time.

-psxboy

lrhorer
12-08-2011, 06:31 PM
Hehe... I know. We've had this argument before. But no matter how you slice it, doing the upgrade via telnet with a single reboot at the end is always gonna be faster (and for me, easier) than pulling the drives and doing it from a PC. But to each his own - whatever works for you.
Surely, and of course now what I do myself is a scripted upgrade from the running TiVo, so there's no way I am arguing pulling the drive is inherently better. It's just there can be valid reasons one might choose to hack by pulling the drive.


You're right, and that's why I keep my /var backup tarballs in my custom hda1.
Yeah, me too, except I keep it and the scripts, etc. in /dev/hda2 with an identical copy in /dev/hda5, just in case.


Just mount it, restore /var & you're done. All on the Tivo via telnet. And btw, /var only gets wiped if it exceeds 40% capacity (or something close to that - I'm going from memory) or if it fails the fsck twice at boot time.
Right, and since I moved all the hacks out of /var itself and into a mounted filesystem under /var, there is less chance of filling up or corrupting /var. Maybe one of these days I should expand /var a bit, too:


HD_Theater:/# pdisk -l /dev/hda

stat: mode = 060660, type=Block
size = 0, blocks = 0
HDIO_GETGEO: heads=255, sectors=63, cylinders=46593, start=0, total=748516545
Partition map (with 512 byte blocks) on '/dev/hda'
#: type name length base ( size )
1: Apple_partition_map Apple 63 @ 1 ( 31.5K)
2: Ext2 Hack 1 524288 @ 64 ( 256.0M)
3: Image Kernel 1 4096 @ 524352 ( 2.0M)
4: Ext2 Root 1 524288 @ 528448 ( 256.0M)
5: Ext2 Hack 2 524288 @ 1052736 ( 256.0M)
6: Image Kernel 2 4096 @ 1577024 ( 2.0M)
7: Ext2 Root 2 524288 @ 1581120 ( 256.0M)
8: Swap Linux swap 262144 @ 2105408 ( 128.0M)
9: Ext2 /var 524288 @ 2367552 ( 256.0M)
10: MFS MFS application region 589824 @ 2891840 ( 288.0M)
11: MFS MFS media region 216747008 @ 3481664 ( 103.3G)
12: MFS Second MFS application region 589824 @ 220228672 ( 288.0M)
13: MFS Second MFS media region 268617728 @ 220818496 ( 128.0G)
14: MFS New MFS Application 1024 @ 489436224 ( 512.0K)
15: MFS New MFS Media 1465647104 @ 489437248 ( 698.8G)
16: Apple_Free Extra 1951944816 @ 1955084352 ( 930.7G)

Heartbreaker
01-10-2012, 08:10 PM
Is there an 11.0L?I noticed my Tivo isn't connecting to the Tivo Central anymore...

lrhorer
01-11-2012, 01:16 AM
No, 11.0k is the most recent.