Results 1 to 13 of 13

Thread: Series2.5 initial compromise: support thread (was: walkthrough for initial hack...)

  1. #1
    Join Date
    Nov 2004
    Posts
    10

    walkthrough for initial hack on series 2.5?

    Is this something that exists or someone would consider doing?

  2. #2
    Join Date
    Jun 2001
    Posts
    3,108
    Quote Originally Posted by diskus
    Is this something that exists or someone would consider doing?
    hmmm, lets see:

    1) remove prom from motherboard
    2) rip image from chip
    3) apply patches to image to turn off signature checks
    4) resolder the prom
    5) hack using any modified kernel you want, or use a stock kernel with replace_initrd
    Step one: search button!
    Silly Wabbit, guides are for kids

  3. #3
    Join Date
    Nov 2004
    Posts
    10
    OK well thats not going to happen, yikes


    thanks for the reply

  4. #4
    Join Date
    Jul 2004
    Location
    TN, USA
    Posts
    101
    Mr Black you make it sound too easy.

  5. #5
    Join Date
    Jun 2001
    Posts
    3,108
    Quote Originally Posted by CroW
    Mr Black you make it sound too easy.
    it is quite easy with the proper tools. the hot air rework station i got over the summer proved that to me very quickly. granted, its not for everyone, not for the faint of heart, but to say its rocket science would certainly be a stretch.
    Step one: search button!
    Silly Wabbit, guides are for kids

  6. #6
    Join Date
    Jan 2002
    Posts
    1,778
    I have posted custom kernels for Series2.5 owners to play with:

    http://www.dealdatabase.com/forum/sh...493#post193493

    This should make step 5 even easier.

    PROM 2.25 patches (step 3), rc.sysinit contents, and everything else you need to know for the software side of Series2.5 hacking is in the same thread.

    For steps 1 and 4, Sleeper has demonstrated that PLCC extraction and replacement is well within the reach of an average user.

    Hint: practice on a few old video cards before you risk destroying your TiVo. In my experience, the worst case scenarios are: a) lifting pads, or b) nearby components (particularly the battery holder and the BCM7317) melting or falling off due to unwanted reflowing of their joints. Solder bridges can cause fireworks, but they are less common and more visible on a PLCC32 because the pins are not very close together.

    As for step 2 - if you already have a hacked TiVo, you can use it with getprom, flash39, or homieflash as a makeshift PROM burner.
    Last edited by alldeadhomiez; 11-12-2004 at 03:49 PM.

  7. #7
    Join Date
    Jul 2003
    Posts
    7
    I socketed the PROM in my Series 1 (SA) a few years back.

    Would the following work...

    1) Get the old Series 1 SA machine running.
    2) Hot-swap the existing SST-39 with a fresh one.
    3) Using getprom, "-Update" it with the modified 2.25 bin.
    4) Remove the PROM and place it in my new Series 2.5 machine.

    Sorry!! it just seemed like more fun than using a programmer...
    Last edited by The_Cable_Guy; 12-28-2004 at 02:52 AM.

  8. #8
    Join Date
    Jan 2002
    Posts
    1,778
    Quote Originally Posted by The_Cable_Guy
    I socketed the PROM in my Series 1 (SA) a few years back.

    Would the following work...

    1) Get the old Series 1 SA machine running.
    2) Hot-swap the existing SST-39 with a fresh one.
    3) Using getprom, "-Update" it with the modified 2.25 bin.
    4) Remove the PROM and place it in my new Series 2.5 machine.

    Sorry!! it just seemed like more fun than using a programmer...
    Yes, if you update the SHA1 hash on the modified image. (IIRC, getprom will tell you what hash it is expecting to see, if there is a mismatch.)

  9. #9
    Join Date
    Jul 2003
    Posts
    7
    FYI... It sure sounded like a good idea, but it didn't work.

    In order for "getprom -Update" to write the data to the new SST-39 in the SV-2000, I changed the first 4 bytes to "TiVo" (0x5469566f) to pass the "Bad Magic Number" message. Then I changed the the final 3 bytes to "0xbe870b" to satisfy the "Bad Reset Vector" message. After that, "getprom -Update" wrote everything on the PROM past x0380 properly.

    I put the new flash in the TCD540040 and it wouldn't even boot.

    I dragged out a programmer and got the job done right. It worked like a charm. Thanks "ADH" and "mrblack51"!!


    TCG

  10. #10
    Join Date
    Dec 2004
    Posts
    2
    Am I correct in understanding that the SST37 in the SA2.5 can be replaced with an SST39? What are the benefits of doing this if it is possible?

    I have been trying to locate some SST37s to preserve my original. Mouser seems to have them. They quote a 2 week factory lead time on them. Is that only applicable if you are ordering more than what they have in stock?
    Last edited by dledeaux; 01-14-2005 at 10:42 AM.

  11. #11
    Join Date
    Jul 2003
    Posts
    7
    dledeaux,

    Look at the data sheets on both. The 37 needs 12 volts to erase/write and the 39 needs 3.3 volts. The 37 has to be programmed out of circuit with a programmer, but the 39 can be reflashed at anytime in-circuit with the utilities that have been written and posted here. A much better solution for any other changes you want to make down the road.

    Mouser seems to have them in stock:

    Mouser Part #: 804-39VF0107INH (SST39VF010-70-4I-NH)
    Mouser Part #: 804-39VF0107CNH (SST39VF010-70-4C-NH)

    For $ .32 more the "I" (industrial) version has a wider operating temperature range than the "C" (commercial) version.

    Did you see ADH's post about upgrading the memory of the unit too?


    TCG

  12. #12
    Join Date
    Jan 2002
    Posts
    1,778
    Quote Originally Posted by The_Cable_Guy
    FYI... It sure sounded like a good idea, but it didn't work.

    In order for "getprom -Update" to write the data to the new SST-39 in the SV-2000, I changed the first 4 bytes to "TiVo" (0x5469566f) to pass the "Bad Magic Number" message. Then I changed the the final 3 bytes to "0xbe870b" to satisfy the "Bad Reset Vector" message. After that, "getprom -Update" wrote everything on the PROM past x0380 properly.
    Good to know. I don't think tampering with the bytes at the end would hurt anything, but the first 4 bytes (0bf0xxxx) make up a rather important jump instruction.

    To skip these checks, you'll want to edit the getprom binary (untested):

    Code:
     1800de4:       3c 00 54 69     lis     r0,21609
     1800de8:       60 00 56 6f     ori     r0,r0,22127
     1800dec:       7c 89 00 00     cmpw    cr1,r9,r0
     1800df0:       41 86 00 20     beq-    cr1,0x1800e10
    offset df0: 41860020 -> 48000020 (skip magic number check)

    Code:
     1800e10:       3d 3e 00 02     addis   r9,r30,2
     1800e14:       80 09 ff fc     lwz     r0,-4(r9)
     1800e18:       6c 09 4b fe     xoris   r9,r0,19454
     1800e1c:       69 29 20 24     xori    r9,r9,8228
     1800e20:       31 49 ff ff     addic   r10,r9,-1
     1800e24:       7d 2a 49 10     subfe   r9,r10,r9
     1800e28:       6c 00 4b ff     xoris   r0,r0,19455
     1800e2c:       68 00 e0 04     xori    r0,r0,57348
     1800e30:       31 40 ff ff     addic   r10,r0,-1
     1800e34:       7c 0a 01 10     subfe   r0,r10,r0
     1800e38:       7d 2a 00 39     and.    r10,r9,r0
     1800e3c:       41 82 00 20     beq-    0x1800e5c
    offset e3c: 41820020 -> 48000020 (skip reset vector check)

    This was from the 3.1.0d getprom binary. Offsets on other versions may vary.

    but the 39 can be reflashed at anytime in-circuit with the utilities that have been written and posted here.
    BTW, I have not tried this yet on a Series2.5 system. However, I do know that the flash is mapped to the same physical address range, so it might work.

  13. #13
    Join Date
    Mar 2004
    Posts
    6
    I know this is dragging up an old thread, but I have a requirement to program some SST39 chips and the only hardware I have available is a boat load of old S1 TiVo's, so I have socketed the main board of one to use as a test bed for programming.

    I made the adjustments from post 12 to getprom to skip the "Bad Magic Number" and "Bad Reset Vector" errors as suggested by alldeadhomiez and they did indeed work, props to alldeadhimiez on posting that blind, its only taken 7 years for someone to confirm .

    Although getprom proceeded to erase and flash the chip fine, it does balk at the end when it tries to report the version number, but I figured that would be ok because getprom is probably trying to report on a rigid S1 firmware and I'm putting in a different firmware from a completely different machine (S3 TiVo).

    However, to be thorough, I thought it best to dump the written image back out and compare it to original BIN with a "getprom -dump flashedversion.bin" . When I compare the flashedversion.bin the original BIN in a hex editor, the first 304 bytes are different, the rest is a perfect match to the original.

    So I think I'm nearly there, I just don't know why the first 304 bytes are not the same.
    I've done a fair bit of reading and I know there were developments afterwards, including new tools written like homieflash, but that was written for mips hardware (S2 Tivo onwards), I only have the S1 PPC hardware to hand so I'm keen to get this solution working if at all possible!

    Any tips would be greatly appreciated.....thanks.
    Last edited by healeydave; 06-16-2012 at 09:31 AM.

Posting Permissions

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