View Full Version : Series 2.5 EPROM Replacement
10-24-2011, 08:19 PM
Yes, newbie, but I've been reading, I swear!
I have a Humax DRT800 I replaced the hard drive in, using Instantcake, and a DCD649180, still stock. From what I've been reading, these are Series 2.5 Tivo's, and are 'unhackable' unless you replace the EPROM chip.
So correct me if I'm wrong, but it looks like in order to do this, you
-remove the original SST37 from the Tivo
-Use an EPROM programmer/reader/eraser to read the program off the SST37 chip and save as a BIN file
-Modify the program
-Burn the modified program to an SST39 chip
-Replace the chip in the TIVO
-TIVO is now hackable
Now I have a few questions:
-Is there a recommended programmer? I see a few Willems EPROM programmers on ebay that say they are compatible with the SST39SF010
-Is there a program to use to read, modify or burn the chip, or just use whatever comes with the programmer? With PIC chips, I usually write the program in a text editor, check it in MPLAB, and export the hex file to use with my PIC programmer's program to write to the chip.
-What exactly needs to be done to the original program? Erasing or modifying certain lines?
Thanks for any insight!
10-24-2011, 10:08 PM
Start here http://www.dealdatabase.com/forum/showthread.php?53722-FS-Full-Service-PROM-Modification
10-24-2011, 11:45 PM
Just read through all 30 pages of the link. Omikron's service would definitely be the way to go if I were just doing this to one unit, and wanted it over and done with. At $18 shipped it's even really cheap! However, I would like to figure out how to do it myself, since I love tinkering with stuff, and learning new skills. Being able to program another type of chip would be very helpful in some of my other hobbies.
On page 14 of the thread, Omikron includes a link to this thread:
which includes the modifications to make to each EPROM
v2.25 //Unpatched MD5 is c4c7eb11170777e8893e00c1d60a8715
0x958C: 14 83 00 04 -> 14 84 00 04 //Disable PROM SHA-160
0xA4C0: 10 43 00 0A -> 10 42 00 0A //Disable Kernel Check
v2.27.1 //Unpatched MD5 is 39708224a08491441a20bd41397c56c6
0x69A8: 14 83 00 04 -> 14 84 00 04 //Disable PROM SHA-160
0x78DC: 10 43 00 0A -> 10 42 00 0A //Disable Kernel Check
v2.28 //Unpatched MD5 is 8d78f4d6dafd5073412123710c673896
0x6A60: 14 83 00 04 -> 14 84 00 04 //Disable PROM SHA-160
0x7994: 10 43 00 0A -> 10 42 00 0A //Disable Kernel Check
v2.28.1 //Unpatched MD5 is 832470766286885cd3a72fccfc9ecaaa OR 825c84c86a6b95b9a0addb61b44fa971
0x6A70: 14 83 00 04 -> 14 84 00 04 //Disable PROM SHA-160
0x79A4: 10 43 00 0A -> 10 42 00 0A //Disable Kernel Check
So I would use the file the EPROM programmer extracts from the SST37 and check it's md5 checksum against whichever one I have, to make sure it copied correctly without errors. Then, go into the file, and find the two lines to modify, say at 0x6A70, change 14 83 00 04 to 14 84 00 04, which in the comment says it disables PROM SHA-160, as well as the disable kernel check line. So after this, burn the newly modified file to the SST39?
I'm guessing there's a reason whole modified or unmodified EPROMS aren't posted on the forum? Also, the more I look at the Willems programmer, the more I like. Anyone used one of the ebay cheapies?
10-25-2011, 02:05 AM
I was taking apart the DRT800 to get a closer look, and found it has TWO! 37VF010 chips. Interesting, huh? So I DID A SEARCH, and found the correct one to replace is the one labeled U34, next to the battery, closer to the front panel of the unit. The number on this chip is 0426045-A, the other is 0424228-A.
10-25-2011, 11:45 PM
I can't speak to your specific unit, but it sounds like you've got the concept right. Willem programmer is fine, but there are lots of variations - some probably better than others.
Chipquik (or another bismuth solder kit) is great for removing SMDs. Unless you're confident in your soldering skills, practice on something expendable first.
10-28-2011, 04:31 PM
The new chips and the programmer both came in today. Bought a Willems off eBay, and ordered the chips and sockets from Mouser.
I desoldered the chip from the DRT800, and placed it into the programmer. BUG - Programmer would not pass the hardware test unless I changed the box at the lower right to Printer Port: LPT3, even though in the device manager it's set to LPT1. Whatever.
Select SST37 from the menu
Device>EPROM Electrical Erase>SST37VFxxx (3.3V)>SST37VF010 (Vpe 12V)
Set the DIP switch pins according to the picture in the program, and from the menu select
It then reads the info on the chip. Go to
and save the file as a BIN file. I then used another md5 checker program, and the BIN file's MD5 checksum matched the one posted by Omikron. The notes in the program even identify it as 2.28. Nice! Now I have a backup file of the PROM chip.
Back in the Willems program, I pressed the 'Clear Buffer' button towards to top, and loaded the BIN file I checked the md5 checksum on. At the bottom of the program window is a button called 'Buffer' where you can view the BIN file line by line. I went to line 0x6A60 and modified it as above, changing the 83 to 84 - BUG - the editing window that pops up isn't big enough to see WHAT you're editing, and isn't resizeable. I just hit tab until the cursor was in the box, typed 84, and it changed in the Buffer. So it was still editable, and I could check it was edited. Also edited the other line the same way.
At this point I saved the file as SST39.bin and changed the device to
Device>Flash29/39/49 Flash rom>SST>SST39LF/VF010
and changed the DIP switches again. I inserted the new SST39 chip, and ran Action>Blank Check to make sure the chip was empty. After that was verified, I cleared the buffer, and loaded the SST39 BIN file, and wrote it to the chip.
That's where I stand right now. Need to clean up the board a little and solder the new socket to it, and see if the Tivo still works afterward.
10-28-2011, 05:28 PM
Well soldering the socket on didn't take nearly as long as removing the original chip. Got it on all nice and neat, put in the new chip, and put it back together. Plugged it in, and... blank screen. I let it sit for a few minutes, unplugged it, and plugged it in again. THIS time it fired right up as usual, and is working perfectly! Finally time to start messing with it.
Thanks to everyone who has posted about how to do this, especially Omikron!
10-28-2011, 07:08 PM
Working on the second Tivo, and I'm stuck: The BIN I read from the SST37 chip in the TCD649180 is
v1.06.3 //Unpatched MD5 is 06e9b92912025f45d1fb11ad0fc25950
0x8050: 04 40 00 12 -> 00 00 00 00 //Original Offset
0x2688: 10 43 00 0A -> 10 00 00 0A //Offset From gzip Image at 0xC91C
The MD5 checksum matches, and I found the info and edited it at 0x8050, but 10 43 00 0A doesn't exist anywhere in the file? The description says 'Offset from gzip Image' ? I tried opening the BIN with gzip on my Linux laptop, but it wants a gz file?
10-28-2011, 09:35 PM
There is a gz file embedded within the bin, apparently at offset 0xC91C, if that comment is right.
So you need to dd copy the gz image out of the bin, then decompress it, then patch it, then recompress it, then dd copy it back into the bin. More info here (http://www.dealdatabase.com/forum/showthread.php?50973-DualTuner-Prom-Hack-Released).
There's a cleverer way to do it (patch the code to patch the image in memory after it is decompressed), but the above approach is what people do.
10-28-2011, 11:51 PM
Ugh, I've been reading and reading and reading, and found about three threads that explained it just as cryptically. Cannot figure out how to get the encrypted data to open with gzip. I burned the unmodified BIN to a new chip, put it in the machine after adding the socket, and it works, so I can still use it.
10-29-2011, 10:43 AM
Ugh, I've been reading and reading and reading, and found about three threads that explained it just as cryptically. Cannot figure out how to get the encrypted data to open with gzip. I burned the unmodified BIN to a new chip, put it in the machine after adding the socket, and it works, so I can still use it.Have you looked at the dd man page (http://linux.die.net/man/1/dd)? Among other things, dd lets you copy data out of a file, starting at an offset. Here's the first couple of steps:
let "offset = 0xC91C"
dd if=tivo-1.06.3.bin bs=1 skip=$offset of=foo.gz
gunzip foo.gzIf you hex edit the resulting file "foo" and go to the specified patch point, you'll see this:
From there, patch the file, recompress, dd copy back into the .bin (hint, see the seek option of dd).
Is that enough to get you started?
10-29-2011, 09:06 PM
Okay, I used the above
let "offset = 0xC91C"
dd if=/home/user/Desktop/sst37b.bin bs=1 skip=$offset of=foo.gz
and this created the uncompressed foo file. I opened this with my chip burner's editing program, and found and edited the 10 43 00 0A line, changing the 43 to 00, and saved the result as editedfoo
So I went back to the command line and typed
gzip -9n /home/user/Desktop/editedfoo
and this created a file on the desktop editedfoo.gz If you double-click this file, It's like opening up a zipped file, the fullsize file is in there. If you open it from there, it's exactly the same as the unzipped file. However, if you rename it and change the .gz extension to .bin, you get a small BIN file. Is this the compressed file I post back into the original bin, replacing the code after 0xC91C ?
10-29-2011, 11:16 PM
That is the general idea. It should be similar in size to the foo.gz that you copied out in the earlier step.
Powered by vBulletin® Version 4.2.2 Copyright © 2016 vBulletin Solutions, Inc. All rights reserved.