Page 1 of 3 123 LastLast
Results 1 to 15 of 33

Thread: Disassembing ST20 data

  1. #1
    Join Date
    Nov 2001
    Posts
    64

    35 Disassembing ST20 data

    There are a few interesting files on my DTivo unit that I assume are ST20 assembly code in some format or other. However, when trying to disassemble these files in IDA PA, very little of the file is made sense of.

    Is the file encoded in some transfer packaging, or do I need to know the entry point in order to get a decent disassembly?

    I'm anxious to get to the bottom of this file, since I've already found it to be useful to me Has anyone successfully disassmbled this stuff? (I know it's rather large, but I'm hoping that a fair chunk of it is binary data )

    BTW, I have some interesting ideas about how to disable writes to the SST39 flash device, having gleaned some useful info on how it is accessed. If anyone is also looking at this or is interested in collaboration, please PM me.

    thanks,

    Arnold J.
    "Smoke me a kipper, I'll be back for breakfast"

  2. #2
    Join Date
    Jan 2002
    Posts
    11
    Look at the file in a hex editor and you might notice an odd pattern. This will help you.

  3. #3
    Join Date
    Nov 2001
    Posts
    64

    Thumbs up

    Thanks kowesoft - I managed to figure it out shortly after I posted, and with some insights from a couple of friendly gurus I now have what I need to get the job done
    "Smoke me a kipper, I'll be back for breakfast"

  4. #4
    Join Date
    Feb 2002
    Posts
    38
    I'm at the same point as smeghead, except that I haven't figured out the pattern. I do see it, but don't understand it.

    Smeghead, if you still want someone to colaborate with, I'm interested.

    I'm not that smart, but I'm motivated.

    It sucks having a great program like IDA pro and knowing it means you have the keys to the answer. Then you realize that you can't find the lock.

  5. #5
    Join Date
    Feb 2002
    Posts
    109
    I've heard they're database files and not binary executables.

  6. #6
    Join Date
    Sep 2001
    Posts
    889
    hmm.. they're definitely NOT database files.. and they're definitely NOT binary executables..

    BigDog, you see the pattern.. seperate the chaff from the wheat

  7. #7
    Join Date
    Feb 2002
    Posts
    109
    How nice things look at 18 bytes/row. Simular to an eprom file.

  8. #8
    Join Date
    Sep 2001
    Posts
    889
    try 9 and then go through the file till it starts to misalign and find out why..

  9. #9
    Join Date
    Feb 2002
    Posts
    38
    It seems like there are two datasets in one file. I'm hoping that by studying the 420 hack, I can unlock the keys to this one.

    Thanks for the help professor BubbaJ

  10. #10
    Join Date
    Feb 2002
    Posts
    3
    Its important to study up on the oslink bootstrap part of the sti5505 documents, thanks BubbaJ. (look at http://216.131.76.129/STI5500/ aka The Omega Code, some decent tools and good refs. I can't seem to get the DASMST20 disassembler working so I decided to just write my own)

    Working with the boot299.btl file in 2.5:
    You'll notice that there is a 0 every 9 bytes for the first 2106 bytes. This is due to oslink bootloading, the zero is the control byte, when zero it specifies a poke. The next 4 bytes are the memory location, followed by the data to poke. This is setting up bootstrap information.

    The 2107th byte (once again a control byte) is > 1, which denotes the number of following bytes to load starting at memstart. After those bytes are loaded, the code starts executing at memstart. These 29 bytes just jump to the start of the code poked previously (0x80000250)

    The 0x80000250 code essentially polls for data much like the oslink bootstrap.

    2106(original bytes that were poked) + 1(control byte) + 29 (length of bootstrap) = 2136

    If you start interpretting data from offset 2136, you'll find that the data once again has the bootstrap properties. 1st byte is 0, signifying poke, next 4 are memory location, next 4 are data. Make sure you recognize the data is little endian (this catches everyone http://www.instantweb.com/foldoc/fol...?little-endian) And start browing away. If you are using a hexeditor, look at the ascii side of things every once in a while, you'll find interesting information. Some hacks can even be produced by just changing the ascii response value of commands.

    Hope this helps!
    Last edited by Cloak; 03-09-2002 at 01:13 AM.

  11. #11
    Join Date
    Feb 2002
    Posts
    38
    Cloak,

    Thanks!! That was the most informative helpfull post I've read in a long time. I sure hope you stick around here.

  12. #12
    Join Date
    Feb 2002
    Posts
    2

    FYI..

    Here's the spec sheets and general info on the Silicon Storage flash located in the DirecTivo:

    http://www.sst.com/products/pdf/

    http://www.sst.com/products/39sf010a_020a_040.html

    I had initially wondered to myself whether there was a brute force way of disabling writes to the flash.

  13. #13
    Join Date
    Feb 2002
    Posts
    14
    Acutally we're working on the two hacks for the DTivo right now. I've disabled CAM ID check, which of course was quite simple to perform (now an H card can work in a DTivo... course who cares but it was a start).

    Now we're trying to get the nozkt mod applied. This works great in the RCA 420's and 440's for stopping the 745 errors we used to get upon startup. Now they run clean as a whistle, hence why we want this in our Tivo's.

    Unfortunately the disassem's I've found for the ST20 seem to suck large, however, may just take a little more work.

    If anyone is also working on the nozkt and wants to exchange ideas/hacks, drop me a PM. Please only people that know what they are doing (i.e. if you think a register is something they put cash in...heh), save the "Me too's" for once the hack is figured out and working cleanly.

  14. #14
    Join Date
    Mar 2002
    Posts
    290

    the .tbl files

    I'm starting disassembly on the .tbl files. Judging by what I've read elsewhere and what is in the rc.sysinit file, I'm focusing my attention on the boot299.tbl file.

    However, the rc.sysinit indicates that others can be loaded. The boot199.tbl file might run on one or both tuners and so can the boot299.tbl file. They can also be mixed (199 on 1 tuner and 299 on the other tuner) and either file can be on either tuner.

    Also, the ndsboot299.tbl file is present on my system. It seems that the script allows for the use of a ndsboot199.tbl file as well but it is not present. I think that ndsboot299.tbl is the modified "prom" code, like that which can be flashed on normal fifth gen IRDs. The ndsboot299.tbl file is about 70 bytes larger than the regular boot299.tbl. I haven't checked yet but I think the ndsboot299.tbl file was generated after I started using 25xtreme.

    I have some ideas of what these files do but I was hoping someone woud provide a complete explanation of these files and when and how they are used to initialize the DTV tuners.

  15. #15
    Join Date
    Mar 2002
    Posts
    321
    Anyone made any progress on this?

Posting Permissions

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