Page 4 of 43 FirstFirst ... 2345614 ... LastLast
Results 46 to 60 of 638

Thread: killhdinitrd 0.9.x Support Thread

  1. #46
    Join Date
    May 2002
    Posts
    314
    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.

  2. #47
    Join Date
    Jan 2003
    Posts
    388
    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

  3. #48
    Join Date
    Feb 2002
    Posts
    130
    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.
    Of course I'm only using logic since I don't have the knowledge ... and of course I DONATED !

  4. #49
    Join Date
    Jan 2002
    Posts
    1,778
    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.

  5. #50
    Join Date
    Jun 2004
    Location
    Planet Earth
    Posts
    235
    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.

  6. #51
    Join Date
    Sep 2001
    Posts
    459
    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?

  7. #52
    Join Date
    Mar 2002
    Posts
    1,339
    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

  8. #53
    Join Date
    Jun 2003
    Posts
    55
    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?

  9. #54
    Join Date
    Feb 2002
    Posts
    130
    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
    Last edited by Logandros; 08-07-2004 at 03:29 PM.
    Of course I'm only using logic since I don't have the knowledge ... and of course I DONATED !

  10. #55
    Join Date
    Jan 2002
    Posts
    1,778
    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.

  11. #56
    Join Date
    Jun 2003
    Posts
    55

    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?

  12. #57
    Join Date
    Feb 2002
    Posts
    130
    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
    Of course I'm only using logic since I don't have the knowledge ... and of course I DONATED !

  13. #58
    Join Date
    May 2002
    Posts
    314
    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
    ....
    Last edited by MuscleNerd; 08-08-2004 at 12:57 AM.

  14. #59
    Join Date
    May 2004
    Posts
    108
    Quote Originally Posted by jteloh
    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.

  15. #60
    Join Date
    Jun 2003
    Posts
    55
    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.
    Last edited by Fletch319; 08-08-2004 at 11:05 AM. Reason: Update

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •