killhdinitrd 0.9.x Support Thread

[MuscleNerd]

Just looking for a little wisdom on the "risks" since my understanding is that this method is different from what has been done before.

The method is a little different, but the risks and consequences are the same. What happens to /var is independent of this too (i.e. you have an equally likely chance of trashing /var on any sudden reboot).

Probably a worst case scenario would be the same: you've been running a hacked tivo with LBA48 support in the kernel, and a TiVo-initiated "upgrade" puts you into a non-LBA48 kernel. That would be bad.

But the most common result would just be the need to reinstall your boot-time hooks.

[rung]

Is there a simple description of the vulnerability and how it was exploited? Can someone explain what "kernel entry address handling" is and what the "Uma2c board" does?

Let me know if I am getting close. The hack takes advantage of the fact that the memory location when the kernel starts running can be changed without the PROM noticing. Also, you can stuff a few bytes in at the end of the kernel that is loaded and that goes unnoticed as well. So, then the trick is to design some code that modifes the kernel that has already been loaded into memory, but hasn't run yet, such that it ignores the initrd. After modifing those memory locations, it then branches to the original kernel start location.

I guess the Uma2c board must be a new motherboard design where this vulnerability has been fixed.

Question - Can this hole be closed without a new prom?

Thanks,
Rung

[Logandros]

MuscleNerd has added 4.x kernel compatability - thanks man!

some time for testing, update the readme, yada yada yada...

prolly be available this weekend

That was taken from the devs thread ...

curious if anyone reads this as I do .. this will allow a straight boot of a 4.01b on an HD 10-250?

If so how do you modify it to allow for LBA48 support?

Unless the only way to use this on an 10-250 is using a smaller drive. Someone clear up for me where I'm stooopid.

[alldeadhomiez]

Let me know if I am getting close. The hack takes advantage of the fact that the memory location when the kernel starts running can be changed without the PROM noticing. Also, you can stuff a few bytes in at the end of the kernel that is loaded and that goes unnoticed as well. So, then the trick is to design some code that modifes the kernel that has already been loaded into memory, but hasn't run yet, such that it ignores the initrd. After modifing those memory locations, it then branches to the original kernel start location.

I guess the Uma2c board must be a new motherboard design where this vulnerability has been fixed.

Question - Can this hole be closed without a new prom?

Since the PROM is not writable and they can't control what kernel you tell it to boot, the hole can't be "closed" per se.

However, your use of this exploit could be detected by a future (or maybe even current) software version. The same holds true for using the 2.4.4/3.1.U5 kernel with BASH_ENV and monte, which has caused no ill effects so far.

The PROM code on the newer (Uma2c?) boards checks the entry address against a new "TCD1" section in the signed part of the image, and refuses to transfer control if the addresses do not match. Thus, both the PROM code and the kernel image format were modified several months ago, during development of the new boards, to close this hole.

[redstone]

STEP1 - Make a backup
The syntax for that is...

[with the Tivo drive as Secondary master, hence referred to as hdc (hard drive c) and the backup drive as Primary slave, hence hdb. So dd runs as...

dd if=/dev/hdb of=/dev/hdc

Just a heads up. You have mistyped the command backwards in your post and someone will clobber their TIVO disk if executed.

The syntax is dd if=INFILE of=OUTFILE

In your setup, the TIVO drive is hdc so it should be the INFILE.

[Juppers]

I know this allows access to the file system, but what about the kernel? Will the various kernel patches work when using killhdinitrd or does this just get past the initrd and the kernel still has to pass it's sig check? Any kind person want to send me a 3.1.5 kernel?

[rc3105]

I know this allows access to the file system, but what about the kernel? Will the various kernel patches work when using killhdinitrd or does this just get past the initrd and the kernel still has to pass it's sig check? Any kind person want to send me a 3.1.5 kernel?

if the initial kernel itself is modified it won't pass the prom verification

if you need to use a modified kernel for lba48 or whatnot boot a killhdinitrd kernel then monte

that's not as bad as it sounds though, monte can accept a kernel image from the root filesystem instead of an alternate partition. no romfs / bootparm hoopla required

[Fletch319]

ADH posted in the killhdinitrd development thread this (when refereing to 4.0 support)

"it will not work on the kernels shipped with 4.0.1, 4.0.1b, etc."

Can someone explain why? Is there a technical limitation? or is it just that no one has ported the hack to those versions of the kernel?

[Logandros]

I have been trying to restore a 4.0 backup image to a Maxtor 250GB Hard drive. I keep getting errors regarding compression where the compression % goes well over 100%.

Originally I thought I was using a boot CD that does not support LBA48, I have tried the following:

MFSTOOLS2 w/LBA48
MFSTOOLS2 modified
Knoppix Lite 3.3


All same results, I can confirm that the machine Im using detects the Hard Drive correctly during POST. So I'm stuck with what it may be ...

mfsrestore -xzpi /cdrom/40.mfs /dev/hdc

EDIT: It was a cable issue .. thanx anyway

[alldeadhomiez]

ADH posted in the killhdinitrd development thread this (when refereing to 4.0 support)

"it will not work on the kernels shipped with 4.0.1, 4.0.1b, etc."

Can someone explain why? Is there a technical limitation? or is it just that no one has ported the hack to those versions of the kernel?

killhdinitrd changes the "px header" so that your entry point is somewhere in the compressed initrd data instead of in the kernel code. The entry point is selected to be an "effectively unconditional" branch like "beq $zero,$zero,xxx", so that it immediately jumps to a location within a few blocks of the end of the kernel image.

Obviously, since each version's initrd/linuxrc includes a different signature file, the compressed initrd will look very different, so the entry point used on 4.0 will probably not exist anywhere on 4.0.1b.

Regardless, since the kernel itself (not the initrd) is probably identical between 4.0 and 4.0.1b, there is no need to port it to 4.0.1b except for fun.

[Fletch319]

has anyone else tried killhdinitrd on the 4.0 kernel? All i get is a constant reboot cycle after applying the patch. Powering up screen -> reboot over and over. To be sure i didn't mess anything else up i reimaged the drive with a known good 4.0 image (i use it on all my tivo's). The patch says it is applied sucessfully. Any ideas? Has anyone else tried it on 4.0 yet? am i doing something wrong?

[Logandros]

has anyone else tried killhdinitrd on the 4.0 kernel? All i get is a constant reboot cycle after applying the patch. Powering up screen -> reboot over and over. To be sure i didn't mess anything else up i reimaged the drive with a known good 4.0 image (i use it on all my tivo's). The patch says it is applied sucessfully. Any ideas? Has anyone else tried it on 4.0 yet? am i doing something wrong?

I had same issue. I tried it with 4.0 as well

[MuscleNerd]

I did test in on my 4.0 box, and it worked fine.

If you could supply a text capture of the tivo booting, that would *really* help. You'll have to capture via the serial port of course.

As a reference, here's my boot sequence. I've highlighted the two important parts. The red part shows that the kernel signature was there and valid. The blue part shows that the initrd was never mounted to "clean" things up before handing control off to /sbin/init.

You won't be able to see the red part unless you're booting from the bootprom menu (which means you've set its password already). But even if the red part isn't there, as long as you see the "Loading R5432 MMU routines" line, then that means the kernel passed signature verification. And so then focus on where the blue part should happen.

Kernel signed by 'Kernel release key'
Hashing kernel... done
Checking signature... done.
Signed, valid for release
Loading R5432 MMU routines.
CPU revision is: 00005430
Primary instruction cache 32kb, linesize 32 bytes.
Primary data cache 32kb, linesize 32 bytes.
Linux version 2.4.18 (build@buildmaster21) (gcc version 3.0) #6 Mon Mar 24 14:38:02 PST 2003
Determined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda7 dsscon=true console=2,115200 handcraft=true
Monotonic time calibrated: 81.00 counts per usec
Calibrating delay loop... 161.79 BogoMIPS
Contiguous region 0: 8388608 bytes
Contiguous region 1: 1048576 bytes
Contiguous region 2: 10485760 bytes
Contiguous region of 19922944 bytes reserved at 0x80d00000.
Memory: 43640k/65536k available (1174k kernel code, 21896k reserved, 77k data, 60k init)
Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode-cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
ttyS00 at iomem 0xb4100100 (irq = 79) is a 16550A
ttyS00 at port 0xbc010000 (irq = 133) is a unknown
ttyS00 at iomem 0xb4100140 (irq = 81) is a 16550A
ttyS00 at iomem 0xb4100120 (irq = 80) is a 16550A
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0xb4100100x (irq = 79) is a 16550A
ttyS01 at 0xbc010000 (irq = 133) is a unknown
ttyS02 at 0xb4100140x (irq = 81) is a 16550A
ttyS03 at 0xb4100120x (irq = 80) is a 16550A
block: 128 slots per queue, batch=32
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: Maxtor 2F040L0, ATA DISK drive
ide0 at 0x400-0x407,0x438 on irq 87
hda: 80293248 sectors (41110 MB) w/2048KiB Cache, CHS=79656/16/63
Partition check:
 hda: [mac] hda1 hda2 hda3 hda4 hda5 hda6 hda7 hda8 hda9 hda10 hda11 hda12 hda13 hda14
PPP generic driver version 2.4.1
PPP Deflate Compression module registered
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
ip_conntrack (512 buckets, 4096 max)
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 60k freed
## MIPS ## arch-specific shell functions defined
Starting rc.sysinit
Releasing /initrd and clearing ramdisk, if they exist
warning: can't open /var/mtab: No such file or directory
umount: /initrd: not mounted
Activating swap partitions
Adding Swap: 65532k swap-space (priority -1)
Loading i2c driver
Loading core system drivers
....

[mikemav]

I just want to thank the HDteam for such a cool and simple hack.
I yanked the disk at lunch and had it up and running with my hacks soon afterwards. I get my tivoweb and the wife gets her callerID.
Way cool. Thanks much!

Can someone verify that YAC or better yet, elseed-YAC works on the HD tivo? I want to get caller ID up and running, but I thought there might be an issue with the OSD and adding CID info since the HD box is running a higher resolution. If this works, great. I have a USB modem now being used only for a YAC server, and it is a big PITA. Would love to use the tivo modem for something good. BTW, this is a little OT, but does anyone know of a way to get CID info to a YAC or other CID server using Vonage? Seems like a tool they should provide since they are VoIP based and that should make it very easy.

[Fletch319]

I did test in on my 4.0 box, and it worked fine.

If you could supply a text capture of the tivo booting, that would *really* help. You'll have to capture via the serial port of course.

general exception
cause = 80008010 epc = 80179d24 status  = 00510002 badaddr = 4a2236b1
@epc-2 = 0790955c @epc-1 = 39ebebbf @epc = 54296234 @epc+1 = 9f89f660
r00 00000000  81dd0000  80179d24  000000ea
r04 81dd1f34  00000cea  5469566f  81dbfdd0
r08 0000004d  80004000  00000000  81dbe858
r12 81dbe708  fffffffc  2b797e9c  00000000
r16 00000cea  81dbfdc8  81dd1f34  00000000
r20 00000064  81dbfe28  81dbfdc8  00000000
r24 e61c0bce  00000001  bfc00000  a1fe0000
r28 4a224051  81dbfb90  09508250  81dc1308

This is all i get via serial. I'm not that familiar with bash over serial so maybe i'm not getting all the info. basically this is a freshly restored image (bootpage is not altered at all). All i did was run the killhdinitrd (which worked) and stick the drive in the tivo. If this isn't all the info do i need to add any other lines to the boot params? I seem to recall a few other entries in there dsscon, upgradesoftware etc.