Results 1 to 12 of 12

Thread: A quick look at the S2 PROM

  1. #1
    Join Date
    Jan 2002
    Posts
    1,777

    A quick look at the S2 PROM

    I recently took a short break from other projects to take a look at the S2 firmware, in the hopes of making it a bit more user-friendly. My main interests were in making it boot more quickly, setting it up to allow me to override boot parameters, and enabling debug output. Getting rid of that horrible password prompt was also a bit of a priority.

    I will first give you a quick, maybe-semi-accurate overview of the boot process, so that you can easily explore the areas that the patches affect. Please feel free to post any of your own findings here as well as additions or corrections to the posted material. It should be easy enough to use this information to produce a decent disassembly with IDA, especially because GOT-indexed addressing is not used.

    The PROM appears to be mapped to bfc00000 in the MIPS memory space. Sometimes it seems like it might be somewhere else; it may or may not be getting remapped somewhere. I haven't really taken the time to look.

    This post is in reference to the 1.18 firmware.

    Execution begins at bfc00000 and jumps to bfc004b0. 0x314 bytes from bfc01604 are copied to RAM at a1fe0000, then the code jumps and resumes execution at a1fe0064. This code copies 0x1dbc0 bytes from bfc01918 to 81dc0000 and verifies that they are copied correctly. It should be noted that this "81dc0000" block will contain pretty much all of the interesting parts of the PROM so this is the part you want to disassemble.

    The code then calls 81dc0498, which calls 81dc0000 (apparently the SHA-160 function) and then compares the 160-bit hash of the PROM. It prints "sha failed" and locks up on failure, otherwise it transfers control to 81dc0c50. MuscleNerd's first patch at 81dc04dc (offset 0x1df4) forces this check to succeed.

    The 81dc0c50 routine calls all sorts of interesting functions. Here are most of my guesses on important functions and data areas invoked by this part of the code, in no particular order:

    81dc0cd8 - main entry into the "What is password?" user interface

    81dd269c - flag that is set by the serial port checker at 81dc7090 to tell the main function to drop into the interactive UI

    81dd2698 - flag that enables verbose debugging messages on the serial port

    81dc7090 - this function is called frequently to check for the double-enter on the serial port

    81dc54bc - this appears to clear memory and maybe do some hardware init. it is essential to call this before booting

    81dc77c4 - this might be the function that loads in the kernel image

    81dc717c - printf?

    81dc1cbc - this might be a conditional/debug only printf

    81dc84bc - this code bugs you for the password and won't leave until you give it up. I believe it reads a hash from the crypto chip and compares that with the SHA-160 of what you enter. might be interesting to see whether or not the passwords are unique and brute force one or two to see if they are real words

    81dc0000 - the SHA-160 function

    81dc5660 - this appears to be a memory test. it is VERY slow (20+ seconds) so the fastboot patch gets rid of it

    So, without further ado, here are the S2 PROM patches I currently have (specified in offsets into the file; add (0x81dc0000 - 0x1918) to see where they are in the 81dc0000 section):

    1df4: 14830004 -> 14840004 - ignores the PROM SHA-160 check. This is MuscleNerd's patch and it is only here for reference.

    2b40: 1043000c -> 1042000c - ignores the kernel signature check. This is MuscleNerd's patch and it is only here for reference.

    27a4: 0c771598 00000000 0440ff90 -> 0c77152f 00000000 24020000 - this takes 20+ seconds off the boot time by skipping the memory check (?) and invoking the minimal hw init function instead. It does not appear to have any ill effects but testers/troubleshooters are always welcome.

    a9d8: 0c77212f -> 24020001 - skips the password check. Press enter twice during POST and it will drop you into the PROM service menu. This is pretty handy if you mess up your bootpage, because you can temporarily or permanently override the kernel command line. You can also netboot if you have a pegasus USB adapter but I have not tried this. (I wonder if they used GPL code to write the driver.)

    8838: 10400014 -> 00000000 - enables debug output unconditionally. This lets you see the PCI bus scan and a couple of other interesting boot messages. Remember to keep your terminal at 115200 8N1.

    1944: 0c7700c2 -> 10000047 - skips the SHA-160 calculation altogether. This might not save you a noticeable amount of time.

    Feedback and additions are always welcome.

  2. #2
    Join Date
    Jan 2002
    Posts
    1,777
    Another patch:

    3474: 1040000e -> 00000000 - this forces the system to consider netboot first. If no compatible device is found it immediately falls back to disk boot. If a suitable network interface is found, it tries 45 times to boot and then dumps you into the PROM UI if it fails. I have verified that it blasts bootp requests at my LAN but my DHCP server does not seem to be doing anything with them.

    I have tested the fastboot patch with six different drives from Seagate, Maxtor, and Western Digital. All but one worked fine. My OEM Seagate ST380021A 80GB at firmware rev 3.04 was sensitive to the probing that happened before it finished spinning up, and this caused the drive to lock up once in a while before boot.
    Last edited by alldeadhomiez; 09-14-2003 at 02:46 AM.

  3. #3
    Join Date
    May 2002
    Posts
    314
    Originally posted by alldeadhomiez
    3474: 1040000e -> 00000000 - this forces the system to consider netboot first.
    Just FYI, even without the patch, netboot will be considered first if the netboot kernel name is not set to an empty string. That name can be set/queried via the bootpage command.
    a9d8: 0c77212f -> 24020001 - skips the password check.
    Also FYI, the password can be set to whatever you want via the crypto command.

  4. #4
    Join Date
    Sep 2001
    Location
    West of Bermuda
    Posts
    1,017
    musclenerd, i think i tried that using the old "crypto -u -srp factory" deal and it didn't work. is the command different, or did i just screw it up (always possible)

    edit: ack, i screwed it up. i just tried again and it worked. my bad!

    ronny
    Last edited by ronnythunder; 09-17-2003 at 08:39 PM.

  5. #5
    Join Date
    Jan 2002
    Posts
    1,777
    Originally posted by MuscleNerd
    Just FYI, even without the patch, netboot will be considered first if the netboot kernel name is not set to an empty string. That name can be set/queried via the bootpage command.

    Also FYI, the password can be set to whatever you want via the crypto command.
    My hope was that this would allow recovery from a corrupted bootpage without opening the case.

    Were you able to brute force the password on your box and/or netboot?

  6. #6
    Join Date
    Sep 2001
    Location
    West of Bermuda
    Posts
    1,017
    here's what i did:
    Code:
    bash-2.02# crypto -u -srp factory
    bash-2.02# sync
    bash-2.02#
    bash-2.02# reboot
    Restarting system.
    
    Output enabled
    Ram size = 64
    Service number is 1010000C0xxxxxx.
    What is password? factory
    Build target  = TiVo p0
    Build version = 1.18
         reset -
      ememtest -
      identify -
          boot - [ -skip ] [ -3 | -6 ] [ <boot string> ]
       netboot - [ -skip ] [ -f <file> ] [ <boot string> ]
         param - [ <new boot args> ]
          help -
    What? boot
    Attempting to disk load partition 3
    Kernel signed by 'Kernel release key'
    Hashing kernel... done
    Checking signature... done.
    Signed, valid for release
    Loading R5432 MMU routines.
    ...
    it was just a normal boot after that.

    ronny

  7. #7
    Join Date
    May 2002
    Posts
    314
    I never did discover what the password was, before setting it to something on my own. By the way, there is a default password hash within the bootrom, but that is only used if the password hash in the crypto chip hasn't been set (it normally would be set at the factory).

    The netboot stuff works fine for me...I have a bootp server on my network though.

    Also, I believe I spotted a stack overflow vulnerability in the password input routine.

  8. #8
    Join Date
    Sep 2001
    Location
    West of Bermuda
    Posts
    1,017
    Originally posted by MuscleNerd
    I never did discover what the password was, before setting it to something on my own.
    this might provide a clue: the logs on my dsr7k as shipped contained some interesting leftovers from some kind of testing at the factory. if i grep for "srp", here's what i get:
    Code:
    $ strings messages | grep srp
    Mar 28 01:52:08 (none) rshd[189]: root@10.1.1.1 as root: cmd='/tvbin/crypto -u -srp factory ; echo $? > /var/tmp/status.1975'
    Mar 28 02:12:41 (none) rshd[189]: root@10.1.1.1 as root: cmd='/tvbin/crypto -u -srp factory ; echo $? > /var/tmp/status.2641'
    Mar 28 02:27:54 (none) rshd[756]: root@10.1.1.1 as root: cmd='/tvbin/crypto -u -srp 8or5maGPi ; echo $? > /var/tmp/status.3214'
    Jan  1 01:24:16 (none) rshd[188]: root@10.1.1.1 as root: cmd='/tvbin/crypto -u -srp factory ; echo $? > /var/tmp/status.4693'
    Aug  6 13:18:33 (none) rshd[814]: root@10.1.1.1 as root: cmd='/tvbin/crypto -u -srp hCHfvwq17 ; echo $? > /var/tmp/status.5301'
    edit: finishing my thought, it's obvious that the password is set to something random if it's not "factory", however, if you have those logs, you might be able to find out what the random string is.

    ronny
    Last edited by ronnythunder; 09-18-2003 at 09:58 AM.

  9. #9
    Join Date
    May 2002
    Posts
    314
    My HDVR2s didn't have such commands logged in /var/log when shipped from the factory. But if other people did, and post what they found, maybe a pattern would emerge.

  10. #10
    Join Date
    Feb 2006
    Posts
    64
    I tried porting to prom version 2.14 on my HR10-250 and with the changes I made, the disk still spins up and sounds like it is being accessed, but no video appears on the composite output at all (and probably not on the HDMI nor component output either). Also, nothing appears on the serial port at either 115200 or 9600 baud.

    Here are the patch locations I used:
    patch location 0x3984
    0C771C58 00000000 0440FF96 -> 0C771C1B 00000000 24020000
    this takes 20+ seconds off the boot time by skipping
    the memory check (?) and invoking the minimal hw init
    function instead.

    patch location 0xb630
    0C77258F -> 24020001
    skips the password check. Press enter twice during
    POST and it will drop you into the PROM service
    menu.

    patch location 0x266C
    10400014 -> 00000000 - enables debug output
    unconditionally. This lets you see the PCI bus scan
    and a couple of other interesting boot messages.
    Remember to keep your terminal at 115200 8N1.

    patch location 0x15DC
    0C7700BE -> 10000045
    skips the SHA-160 calculation altogether

  11. #11
    Join Date
    Feb 2006
    Posts
    64
    I tried the 2.14 patches one at a time and found that they all work except the one that skips the SHA-160 calculation.

    By applying the other three patches to my 2.14 prom on my HR10-250 I cut 48 seconds off the boot time. I should be able to save even more time by not using killhdinitrd.

  12. #12
    Join Date
    Feb 2006
    Posts
    64
    I've reviewed the 1.18 disassembly and I see that the function at 0xA1FE0064 actually is performing two copy operations from PROM to memory. The first is copying 0xDBC0 (NOT 0x1DBC0) bytes with the source start address at 0xBFC01918 and the destination address at 0x81DC0000. The second block being copied has a source start address of 0xBFC0F4D8 and destination start address of 0x81DCDBC0 and a length of 0x4370 bytes. You may notice that the two copy operations could have been combined into a single operation since the blocks being copied are contiguous. The first block contains code and the second block contains data.
    Last edited by woracan; 04-25-2014 at 05:18 PM.

Posting Permissions

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