two card monte with the kernel? A new possibility for hacking the HDVR2 w/o prom mods

[Dr. Phil]

Originally posted by MuscleNerd
The boot prom doesn't accept any ol' value as the boot partition. It's either 3 or 6.

I stand corrected. Guys, don't use hda15 as your jerkoff kernel partition if you want your box to boot. Thanks Muscle.

[embeem]

-

[Hamsterman]

Originally posted by embeem
The updatekernel will see that it's booting from /dev/hda3 and install the new kernel to /dev/hda6 and attempt to flip which kernel is bootable and which is the alternate. The good news is that the new kernel is installed in the correct place, bad news is that now the system wants to boot the wrong kernel -- A bootpage wrapper will probably be needed at this point to avoid changing the boot kernel.

So, after fixing up the bootpage we're left with the following

hda2 = (same)
hda3 = (same) exploitable kernel
hda4 = unused
hda5 = (same) fake root
hda6 = new kernel
hda7 = new root

boot params:
root=/dev/hda5 real_root=/dev/hda7 BASH_ENV=$(mount$(IFS)/dev/hda2$(IFS)/mnt;/mnt/initmonte)

system boots hda3
hda2 gets mounted
initmonte gets run
monte boots kernel from hda6, root=/dev/hda2 real_root=/dev/hda7
hda2 then mounts /dev/hda7 on /tivo and runs the chroot

(ie everything comes back up again with no user interaction, all hacks still in place on hda2)


.. thoughts?

Great idea. Until now, I didn't know I could mess with the hda2 and hda5 partitions. I was thinking on the order of having the u5 software perform the update, requring manual intervention, but this may be better.

If both hda3 and hda6 have an exploitable kernel, then it won't matter which kernel is booted from.

Ideally, the updatekernel would put the new kernel as a file on the hda2 partition. If that's not practical, it could be dd'd from its partition and an exploitable kernel put in its place before a reboot. Not changing which kernel is booted from isn't much of an option, since the next update will clobber the other kernel partition.

The new kernel would still have to be patched and named properly in order to work seamlessly.

Hamsterman

[alldeadhomiez]

Originally posted by Hamsterman
If both hda3 and hda6 have an exploitable kernel, then it won't matter which kernel is booted from.

You're gonna care which kernel gets booted if hda3 has 2.4.4 and hda6 has 2.4.18.

Ideally, the updatekernel would put the new kernel as a file on the hda2 partition. If that's not practical, it could be dd'd from its partition and an exploitable kernel put in its place before a reboot. Not changing which kernel is booted from isn't much of an option, since the next update will clobber the other kernel partition.

IIRC, embeem has mentioned that a fresh updatekernel script comes with each software upgrade, and this script invokes the bootparm binary on the system. Although the process of overwriting bootpage with a wrapper may be somewhat clumsy, it could be a reasonably "future-proof" way to compromise the new kernel (and new bootpage binary) installed during an upgrade and to ensure that a kernel consistent with the new software version gets written to hda6 each time.

I will give this a shot once I get my hands on the 3.1.0 HDVR2 upgrade slices.

[embeem]

http://alt.org/forum/index.php?t=msg&th=74#msg_488

[citivolus]

Originally posted by geowar
Looking thru citivolus steps I didn't see where he stripped (or nulled, etc.) the initrd from the kernel.img that he's going to monte to. Is that necessary? If the sig checking initrd is still there won't it still fail?

you're right, I forgot to include that part! I updated my post accordingly.

[d7o]

Ok, it took some work but I successfully got the monte trick to work. It took some trial and error.

Here's what I did that worked, and here's what I did that didn't.

I originally had an installation of U5 on my 160 gig hd with all my recordings. Not wanting to loose those recordings I tried somewhat in vain to convert my U5 to 151 prior to doing the monte. This completelyl failed, although it may be possible for someone else.

That said, I ended up starting from a scratch image and this is an outline of what I did. I would suggest reading this thread, this thread over at alt.org and it would hurt to brush up by reading the main post on this tivocommunity thread.

Ok, what you'll need:

An HDVR2 (this may apply to other S2 but obviously I haven't tried them).
An image, or HD, containing the 3.1.0 OS.
An image, or HD, containing the 3.1.U5 OS.
The monte itself. Download from the alt.org forum linked above.
killinitrd. Available from sourceforge.
The mfstools iso burned to CD.

In this example, I'm assuming that your attached tivo hd is on hdc (secondary master), the cdrom is on hdb (primary slave) and the temporary storage drive (fat32, ext2/3, reiserfs partition), is on hda (primary master).

We'll assume that you have already removed the tivo's drive. If not, follow the instructions on tivocommunity.

1) We first need to get a backup of the 3.1.0 OS. If you already have an image of it, skip to instruction 6. Otherwise, insert the drive into the (off) computer as secondary master and boot up to the mfstools cd. As soon as you're at the # prompt you're ready for step 2.

2) We need to mount the partition where we're going to store the image.
mount /dev/hda1 /mnt/c

3) Now we're going to create the backup.
mfsbackup -f 4138 -6so /mnt/c/tivo-s2.bak /dev/hdc

4) Once thats done, and it'll take a little bit, unmount the storage partition.
umount /mnt/c

5) reboot and then power off the computer.

6) Now we need to extract a few partitions from the U5 image. If you already have this on a drive, attach the drive as secondary master, boot up to the CD, and skip to step 11. If you have this as an image, install as secondary master the drive where the monte install is going to go and we'll use it temporarily.

7) Boot to the CD and get to the # prompt.

8) We need to restore the U5 image onto this drive so that we can extract a few partitions from it. We're assuming here that your U5 image is already on the storage drive so lets mount it.
mount /dev/hda1 /mnt/c

9) Do the actual restore.
mfsrestore -s 127 -xzpi /mnt/c/<U5 image name> /dev/hdc

10) unmount and reboot (to the CD).
umount /mnt/c
reboot

11) At the prompt, we need to remount the storage drive and this time we're also going to mount the cdrom.
mount /dev/hda1 /mnt/c
mount /dev/hdb /cdrom

12) The U5 image I used had the the bootkernel at /dev/hda6 and the FS at /dev/hda7. Alternatively the kernel could be at /dev/hda3 and the FS at /dev/hda4. To find out, we'll run bootpage.
/cdrom/bootpage -p /dev/hdc

This will tell us where the root FS is. It should say something like root=/dev/hda7 or root=/dev/hda4. The kernel is always in the partition just prior to the root FS so if root=/dev/hda7 then the kernel is at /dev/hda6. If root=/dev/hda4, then the kernel is at /dev/hda3. My U5 image said that the root was at /dev/hda7 so my instructions will follow from there. Also, the tivo drive isn't connected as primary master so instead of use hda, we'll be using hdc.

13) Backup the U5 kernel
dd if=/dev/hdc6 of=/mnt/c/U5kern.img

14) Backup the U5 FS
dd if=/dev/hdc7 of=/mnt/c/U5fs.img

15) We now need to have the drive we're going to install the monte onto. If that drive is already attached (because we we're using it to temporarily restore the U5 image or because your U5 image is already on that drive), skip to step 20.

16) Unmount everything
umount /cdrom
umount /mnt/c

17) reboot
reboot

18) After it reboots, power off the machine and install the drive you want to install monte onto as secondary master. Boot up to the CD and get to the # prompt.

19) Mount the storage drive
mount /dev/hda1 /mnt/c

Due to post size limitations, continued in next post...

[d7o]

Continued from previous post...

20) Ok, its time to install everything on your new big HD.
mfsrestore -s 127 -xzpi /mnt/c/tivo-s2.bak /dev/hdc

21) After that has finished, we need to reboot so we can pick up the partition table changes.
umount /mnt/c
reboot

22) After you have rebooted, you'll need to scroll back up to check the partitions tables. Read step 12 of the tivocommunity posting above. You need to scroll back and find the last hdcXX in the partition scan. This will probably be hdc16. This is where you are going to store a ROMFS (that later). At any rate, you need to find that last partition and remember its value.

23) We need to mount everything
mount /dev/hda1 /mnt/c
mount /dev/hdb /cdrom

24) We need to find out the root FS on the new hd. It may not be the same as it was with the U5 image!
/cdrom/bootpage -p /dev/hdc

25) As before you should either get either root=/dev/hda7 or root=/dev/hda4. We are going to be installing U5 kernel and FS in the opposite location! If you got root=/dev/hda7, then you'll be installing U5 kernel into /dev/hdc3 and U5 FS into /dev/hdc4. If you got root=/dev/hda4, you'll then be installing U5 kernel into /dev/hdc6 and U5 FS into /dev/hdc7. For me, I got root=/dev/hda7 so I'll be installing U5 into /dev/hdc3 and /dev/hdc4.

One further note. mfsrestore creates /dev/hda3 (/dev/hdc3 boot up here where we've got the drive installed) as 2 megs in size. My original 3.1.0 drive had both /dev/hda3 and /dev/hda6 as 4 megs. I assume that's because Tivo wanted enough space in case things grew beyond 2 megs. All kernels currently released by Tivo are smaller than 2 megs. However, our U5 kernel is 4 megs only because we copied the full 4 megs of the partition from the backup. When we restore the U5 kernel to the 2 megs space (if you're restoring the kernel to /dev/hdc3) you will see an error message saying not everything was copied because of lack of space. This is OK. The first 2 megs were copied and thats what counts.

26) Restore the U5 kernel and U5 FS (in my case to /dev/hdc3 and /dev/hdc4 respectively)
dd if=/mnt/c/U5kern.img of=/dev/hdc3
dd if=/mnt/c/U5fs.img of=/dev/hdc4

27) We need to create a ROMFS image which will run the monte.
mkdir /mnt/c/img
cp /mnt/c/monte-tivo/kmonte.o /mnt/c/img
cp /mnt/c/monte-tivo/monte /mnt/c/img

28) We need to create a file that will run the monte
vi /mnt/c/img/runmonte

You may need to brush up on vi. If you don't like vi, have never used vi, don't know vi, etc, you can create the file as follows:
cat > /mnt/c/img/runmonte

and then type exactly the following:
#!/bin/bash

export -n BASH_ENV
BASH_ENV=

(
/sbin/insmod -f /mnt/kmonte.o
/mnt/monte /dev/hda6 "root=/dev/hda7 console=2,115200 dsscon=true"
) &

and then press 'ctrl-D' to finish the file. If using vi, type in the above and save the file and quit out of vi.

29) Now we need to create the romfs image.
/cdrom/genromfs -f /mnt/c/romfs.img -d /mnt/c/img/

30) We need to write the romfs image to the tivo drive. We use the partition we found in step 22. For me it was /dev/hdc16.
dd if=/mnt/c/romfs.img of=/dev/hdc16

31) Getting close...

32) We now need to update the bootpage. For the bootpage, we are going to be setting the root=/dev/hda4. This is the location where you stored the U5 fs. If you wrote your U5 fs to /dev/hdc4 then you'll set root=/dev/hda4. If you worte you U5 fs to /dev/hdc7, then you'll set root=/dev/hda7. Also, from step 22, you got your romfs partition. In the command below instead of using hdcXX we'll be using hdaXX. In my case, my romfs was written to /dev/hdc16 so in the command below I used /dev/hda16.

/cdrom/bootpage -P "root=/dev/hda4 BASH_ENV=\`mount\$IFS-n\$IFS/dev/hda16\$IFS/mnt;echo\$IFS/mnt/runmonte\`" -C /dev/hdc

Type in the above very carefully. Getting this wrong can cause problems.

33) Your bootpage is currently set to run the 3.1.0 OS. Since we installed the 3.1.U5 OS in the alternate boot location, we need to 'flip' the bootpage to boot to 3.1.U5.
/cdrom/bootpage -f -C /dev/hdc

34) One last thing to do. We need to killinitrd the 3.1.0 OS. Skipping this step will make you have to repeat the installation (yeah found out the hard way). You'll be reading and writing from the partition that contains your original kernel (not the U5 kernel we installed). If you wrote your U5 kernel to /dev/hdc3, then you'll be using /dev/hdc6 in this command. If you wrote your U5 kernel to /dev/hdc6, then you'll be using /dev/hdc3 in this command. I used /dev/hdc6.
dd if=/dev/hdc6 of=/mnt/c/CurrentKern.img
/mnt/c/killinitrd-s2-v3.x /mnt/c/CurrentKern.img
dd if=/mnt/c/CurrentKern.img of=/dev/hdc6

Yeah, continued in next post...

[d7o]

Continued from previous post...

35) Ok, we've got a monte installation but we really need to install some hacks. Mount the 3.1.0 FS. For me this was /dev/hdc7. It could be /dev/hdc4 if yours was backwards from mine.
mount /dev/hdc7 /mnt/tivo

36) What's hacking without a bash prompt
cat >> /mnt/tivo/etc/rc.d/rc.sysinit
/bin/bash </dev/ttyS2& >/dev/ttyS2&

end the above by typing 'ctrl-D'

If you are a vi person, you can do it your way instead of using cat.

37) The default stuff in /bin is sorely lacking.
cp -p /mnt/cdrom/devbin-s2/* /mnt/tivo/bin

38) Install whatever other hacks into /mnt/tivo as you would like. Since we killinitrd'd the 3.1.0 kernel, it'll never get wiped. Nice, eh? The hack are more stable, permanent and natural. Also noticed, we never modified the /var partition. No more restoreing hacks to the wiped /var partition.

39) unmount everything
umount /mnt/tivo
umount /mnt/c
umount /cdrom

40) reboot
reboot

41) Power off you computer, yank out that tivo drive and put it back in your tivo. You should be running the full 3.1.0 OS with hacks installed.

Observations/Enhancements
-----------------------------------------

I didn't get a chance to try alldeadhomiez repartitioning trick. It seems it would be neat. Of particular interest, he has a stripped down U5 fs that only contains the stuff that is checked by the initrd. It supposedly makes booting faster. I definitely wanna try it out.

Prior to monte, I used kmem to unscramble video. All that really does is modify the kernel in memory. However, since the 3.1.0 kernel doesn't need to be signed we can modify the kernel directly. The kmem thread has instructions.

I expected the monte approach to be much slower booting. Suprisingly, it didn't add a great deal of time to the boot process. The reason: the second kernel doesn't have an initrd so it doesn't do the integrity scan. With alldeadhomiez stripped down U5 fs, it would probably be faster booting monte than it would be booting the regular signed 3.1.0 OS.

Summary
--------------------------------------------------
Monte is the way to go for hacking series 2. No question about it. You can run the latest goods while running the latest hacks. You can even make it boot faster. And did I mention no more running U5 menus???

There are bound to be errors in the above instructions. I wrote the instructions out by memory, although I have a pretty good memory. If you see mistakes post a comment and I'll correct it. This could be a completely automated process. Boot up a CD that autoconverts a drive. Someone wanna do it?

Hacking potentially turns your tivo into a brick. Be smart, keep your original tivo hard drive in a safe, stored location and you shouldn't do any permanent harm.

I didn't create monte. I certainly don't get any kudos. MuscleNerd, alldeadhomiez and all you other gurus out there doing the real hacking deserve serious props.

d7o

[CFC]

Thank you d7o for the How-To. And thanks to all who initiated the monte possibillitties !! That's awesome, this will benefit alot of folks.
I have a cool project for the weekend
I Have a DSR7000 so I will be able to confirm that it works with it also (though there is little doubt ...)
Thanks
CFC

Edit: it's d7"o" not "0" hehe

[embeem]

-

[MuscleNerd]

FWIW, here's my version of "runmonte". It has several features that can come in handy:

• The boot and root partitions for monte are determined automatically.
• You can supply additional boot params for monte via the "prom" bootparam, which happens to be one of those that TiVo's initrd doesn't filter out. For example, if you wanted to set FOO=bar and BAZ=bat as environment variables in the system loaded via monte, you would set prom=FOO=bar,BAZ=bat as a real bootparam on disk. This allows you to change certain things without having to generate a new ROMFS.
• If monte fails, or if handcraft=true is set as a real bootparam on disk, a bash shell is brought up instead of letting the U5 system continue to load.

#!/bin/bash

# Derive monte settings from the bootparams stored on disk
set -a
newboot=/dev/hda$(/sbin/bootpage -a /dev/hda)
case "$root" in
&nbsp;&nbsp;*4) newroot=/dev/hda7 ;;
&nbsp;&nbsp;*7) newroot=/dev/hda4 ;;
&nbsp;&nbsp; *) handcraft=true
esac

# Unless "handcraft" is set, immediately load the next kernel via monte.
#
# Extra bootparams for that kernel can be set via a comma-separated list
# stuffed into the original "prom" bootparam (e.g. prom=FOO=bar,BAZ=bat)
#
if [ ! "$handcraft" ]; then
&nbsp;&nbsp;/sbin/insmod -f /mnt/kmonte.o
&nbsp;&nbsp;/mnt/monte $newboot root=$newroot dsscon=true console=2,115200 \
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;upgradesoftware=false ${prom//,/ }
fi

# If this point is reached, either monte failed or was never run.
# Just continually spawn off bash shells on the serial port for debugging.
export -n BASH_ENV
BASH_ENV=
while true; do /bin/bash -login</dev/ttyS2&>/dev/ttyS2; sleep 5; done


And just to avoid cut-and-paste confusion, here's the above text attached as a txt file (rename it and chmod +x it).

[xgdfalcon]

used combination of d7o, MuscleNerd, and embeems post. Now, I'm stuck in "Welcome. Powering Up", with "What is password" on the console.

Any advice?

Thanks,

[nitrous]

If you have the serial cable connected during boot up, that error will occur. Don't put the serial cable in until the second screen appears.
N|trous

[alldeadhomiez]

Originally posted by nitrous
If you have the serial cable connected during boot up, that error will occur. Don't put the serial cable in until the second screen appears.
N|trous

Merely connecting the serial cable will not cause that, as there is usually no way in software to tell whether or not there is a cable connected.

Hitting "enter" at 115200bps before the kernel starts booting is a more likely cause. (Or perhaps using a brain-dead terminal program.)