killhdinitrd 0.9.x Support Thread

Printable View

Show 40 post(s) from this thread on one page

08-05-2004, 10:11 PM
MuscleNerd

Quote:

Originally Posted by Cheezmo

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.
08-06-2004, 04:00 PM
rung

Quote:

Originally Posted by 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
08-06-2004, 06:00 PM
Logandros

Quote:

Originally Posted by rc3105

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.
08-06-2004, 06:31 PM
alldeadhomiez

Quote:

Originally Posted by rung

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.
08-06-2004, 08:47 PM
redstone

Quote:

Originally Posted by MarkZ

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.
08-06-2004, 09:30 PM
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?
08-06-2004, 10:12 PM
rc3105

Quote:

Originally Posted by 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?

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
08-07-2004, 12:28 PM
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?
08-07-2004, 12:47 PM
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
08-07-2004, 01:03 PM
alldeadhomiez

Quote:

Originally Posted by 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?

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.
08-07-2004, 11:52 PM
Fletch319

4.0 question

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?
08-08-2004, 12:22 AM
Logandros

Quote:

Originally Posted by 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?

I had same issue. I tried it with 4.0 as well
08-08-2004, 12:38 AM
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.

Code:

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 ....
08-08-2004, 02:57 AM
mikemav

Quote:

Originally Posted by jteloh

I just want to thank the HDteam for such a cool and simple hack. :D
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.
08-08-2004, 10:13 AM
Fletch319

Quote:

Originally Posted by 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.

Code:

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.

Show 40 post(s) from this thread on one page