Disassembing ST20 data

[smeghead]

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 :D )

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.

[kowesoft]

Look at the file in a hex editor and you might notice an odd pattern. This will help you.

[smeghead]

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 :)

[BigDog]

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.

[lcreech]

I've heard they're database files and not binary executables.

[BubbaJ]

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

[lcreech]

How nice things look at 18 bytes/row. Simular to an eprom file.

[BubbaJ]

try 9 and then go through the file till it starts to misalign and find out why..

[BigDog]

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

[Cloak]

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/foldoc.cgi?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!

[BigDog]

Cloak,

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

[docpaul]

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.

[Thorvald]

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.

[rd001]

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.

[onyx00]

Anyone made any progress on this?

[BubbaJ]

yeah.. .. :D


since it's not terribly relevant any more, here are some tools..

you may need runtimes for these that you don't have..

[BubbaJ]

I will only answer questions about these tools that I deem relevant.., so, no stupid questions .. :D


If anyone is actually interested in using these, I'll make modifications and suport them..

[onyx00]

Thanks Bubba.

Have you looked here: http://216.131.76.129/STI5500/

It has a DisAssembler. I tried using yours with the segments I got after converting from BTL and I get a type mismatch error. Am I doing something wrong?

[BubbaJ]

Cool hadn't looked at that site before.. (though I know one of the people mentioned...)


no idea about the type mismatch.. .. oh you MUST put a value in the base address. (0 is fine)

[Silverdude]

On second thought... No. The disassembly for the st20 is unbelievable!!! Makes programming H cards look like a dream! First thing i have to figure out is how the absolute and relitive jumps work, after an hour i read this:

--------------------------------------------------
Several primary instructions have an operand that is an offset between the current
value of the instruction pointer and some other part of the code. Generating the
optimal prefix sequence to create the instruction data value for one of these
instructions is more complicated. This is because two, or more, instructions with offset
operands can interlock so that the minimal prefix sequences for each instruction is
dependent on the prefixing sequences used for the others.
For example consider the interlocking jumps below which can be prefixed in two
distinct ways. The instructions j and cj are respectively jump and conditional jump.
These are explained in more detail later. The sequence:
cj +16; j -257
can be coded as
pfix 1; cj 0; pfix 1; nfix 0; j 15
but this can be optimized to be
cj 15; nfix 15; j 1
which is the encoding for the sequence
cj +15; j -255
This is because when the two offsets are reduced, their prefixing sequences take 1
byte less so that the two interlocking jumps will still transfer control to the same
instructions as before. This compaction of non-optimal prefix sequences is difficult to
perform and a better method is to slowly build up the prefix sequences so that the
optimal solution is achieved.
-----------------------------------------------------------------

Its almost like some one is playing a terrible joke.
0003C946 2128289A call sub_3E1D4

In the St20 manual there is no code "21 28". And the jump from 3c946 (3c94a) to 3e1d4 is 188a.
----------------------------------------------------------------

SD :mad:

[BubbaJ]

I used followup stuff to generate jumplists and such.. I was working on a much better disassembler when I got sidetracked by life..
oh well.. :)

actually, since there's an st20 emulator out, I could probably use it to make a path of execution disassembler pretty easily..

[psyton]

Silverdude,
Its easier than it appears. In the example you give:

----------------------------------------------------------------
Its almost like some one is playing a terrible joke.
0003C946 2128289A call sub_3E1D4

In the St20 manual there is no code "21 28". And the jump from 3c946 (3c94a) to 3e1d4 is 188a.
----------------------------------------------------------------

the 212828 are pfix opcodes, calculating the offset to the subroutine. Look at the byte as 2 groups of 4 bits, the upper 4 being the function and lower 4 being the operand. In the case of the 3 pfix opcodes, the upper four bits are 0x2 (pfix opcode) and lower 4 are parts of the operands. To calculate the operand of the pfix opcode, take:
(operand + (<byte> & 0xf)) << 4.

To start, operand = 0 after a valid function has been executed
After processing the 1st (0x21), the operand is 0x10
(0 + (0x21 & 0xf)) << 4 = 0x10
After processing the 2nd (0x28), the operand is 0x180
After processing the 3rd (0x28), the operand is 0x1880

Now we hit the call opcode (0x9a) - upper 4 bits (0x9) is call opcode, take the operand value of the instruction (0x9a & 0xf) to get the 0xa, and add this to the running operand value calculated from the pfix instructions, and you get 0x188a (the offset you correctly determined).

The only difference from the pfix and nfix opcodes (0x2 and 0x6) is nfix complements the data the full 32 bits - it can't be easily seen from the byte values because, for instance, nfix 5 (0x65) becomes operand 0xffffffa0 (!5 << 4)

It all deals with the risc architecture of the ST20, there are 16 primary opcodes, of which a single byte could represent both the function _and_ its operand, and the secondary opcodes don't take operands, therefore, they are determined by the same pfix/nfix codes, except the running operand is not an operand, but the secondary opcode, which is then processed when the opr opcode (0xf) is hit, so you'll see nfix and/or pfix operations before the opr opcode, which in turn, translates into the secondary opcode function. The amount of secondary opcodes that could be supported is 0xffffffff

I should know better than to try to talk this technical before bed, I made this sound clear as mud, huh? :) Read the ST20 docs out there, paying attention to the opening chapters - it explains this a lot clearer than I.

Good luck!

[BubbaJ]

Excellent Explanation Pyston..

The ST20 is really VERY easy to disassemble.. even easier if you write a disassembler :)

[Silverdude]

Thanks for the explanation psyton, but thats f*ed! There is no need for that amount of complexity. Engineers! Some **** stayed up nights trying to make that as cryptic as possible.

I was looking for something to burn up some hours, not devote a life too. There is always the 8051 to play with....

SD

[captron]

I've been sitting here this morning drinking coffee and trying to follow along with you guys. Pretty impressive. I was a computer science major many many years ago and you guys make me realize how much I've forgotten! Anyway, keep up the good work and I'm looking forward to a no-zkt mod. Wish I could help.

[GITM]

Edit: Never mind, I figured it out.

[Silverdude]

This is as far as i got.

Get a copy of the rom for a 420re RCA IRD that is pre wink and get a copy of a 420re rom that has the NoZKT mod. Compare the code. They should be the same except for the changes that made it NoZKT (There are only 3, the last one doesnt seem to fit). Search the Tivo rom and look for the code.

The way the programming works was beyond me. Hope that helps.

SD

[captron]

Silverdude,

Good post.

I just started messing with this on Monday by playing around with the st20 disassembler and comparing the H card mod file. It's been over 15 years since I took VAX assembler programming in college but I start 5 weeks of vacation this Saturday so I'm going to dig in to this. Drop me a PM if you want to share ideas.

[Silverdude]

Sharing ideas sounds like a good idea, but my last message summmed up my total knowledge.:rolleyes:

SD

[eBruce]

There are alot of us out here who are very interested in this. Alas, i don't have near the technical expertise that some of you posesses, so offering any suggestions is beyond me.

But I would be very interested to hear of any progress that is made in this area.

Thanks to everyone who is working on this!!!!!

//eBruce

[eBruce]

^

anyone make any progress on this??

[GITM]

Check out www.interesting-devices.com (http://www.interesting-devices.com). In the forums there is a topic called unwink (HINT: it's very big, try reading it backwards).

All the info you need is in this topic and the one over at ID.

I'm sorry, I won't tell you more. The majority here thinks it's a bad idea and I'm just cattle (MOOOOO).

-GITM

P.S. - Thanks to all those that spend the time and effort to figure this stuff out first so that us lazy asses don't have to think too hard :).

[kriskz]

HI EVERYONE!
THE OVERPUNCH to PERFECT FIRMWARE VANTAGE X101S.
20 YEARS BACK WROTE FOR 8080 And Z80.
NECESSARY ST20DIS FOR STi5518.
THE DESCRIPTION ST20 SEARCH for.