Wanted .DSF file format or .... may be disassembler for Alpha?

[Ruslan R. Laishev]

Hi All!

 I have s some re-eng task with old prog w/o source ... So, is there a way to create .DSF to help execution tracing under the DEBUG ?

TIA.

[Volker Halle]

Hi Ruslan,

DBG> SET STEP/INSTRUCTION and step through the program with STEP (=KP0)

And you can also examine the instruction stream with DBG> EXA/INS from_address:to_address

Volker.

[H.Becker]

On Alpha the .DSF is just a VMS specific file with debug information. To my knowledge the format was never published. And as far as I know, the known object/image tools can't format the debug records (neither in a .exe nor in a .dsf).

But there is a disassembler, which is known as SRM_CHECK: "$ srm_check -verbose -dump image.exe" should disassemble the code sections of the image. SRM_CHECK was/should be on the freeware CD.

[Ruslan R. Laishev]

Hello!

Thanks Volker! :-)

Thanks Backer too, found the srm_check in the sys$system ...

I found some reference in the OpenVMS source listing under [...LINKER] but there is not DSF's record structure . 

[John McL]

Ruslan,

Think about what would be in a .DSF file ...

- The name (or DID and FID) of the executable image

- The references that identify each line of the code

- I'm guessing the offsets and names for each symbol and each function within the code

Now maybe you can create some DSF files from known source code and figure out the DSF format from these but creating an synthesised DSF file for your program is going to be very difficult (eg. code line numbers)

Stepping through the code, displaying each instruction and figuring out what they mean might be your only way to reverse engineer it.  (I say "what they mean" because several instructions might be produced by a single line of source code.)  

[abrsvc]

Realize too that on the Alpha, code for a single line can be just about anywhere due to instruction scheduling.  If the image was compiled with optimization etc., the likelyhood of generating any meaningful higher level code is slim.  Also, without /DEBUG, equating register usage to actual variables vs constants will be difficult too.

Perhaps a different approach would be possible.  What exactly is the problem you are trying to resolve (other than recreating old code)?

[Ruslan R. Laishev]

I'm need to recreating  an alhorytm oh some non-lenear transformation on C or MACRO ...

[H.Becker]

>>> I'm need to recreating an alhorytm oh some non-lenear transformation on C or MACRO ...

Which I interpret (yeah, that's the real fun here in this forum :-) as a need for an entry point of a function/procedure and for disassembling from that entry point up to the end of the function/procedure, i.e its last return.

At the moment I don't see how a .DSF will help you, other than having some intermediate debug environment available, which contains the labels, symbols you assigned to code section/data already disassembled and identified.

Do  you know where the entry point is? Is the code in a shareable image? A shareable image could have some global symbols to start with.

As already mentioned by others, constructing either a MACRO or even a C source will be difficult, if the original source was compiled with optimization, something I would assume for such an algorithm. There is nothing in the image telling you how the sources were compiled. And even if you know that the source was compiled with /noopt, it is difficult to find out where in the code stream one high-level language line/statement starts or ends. To me it looks like, the best you can get is a Macro64 source. And if the function/procedure uses static data, you have to find that too.

PS: I don't know AEST good enough whether it can produce some information on what it found in an Alpha image, but looking at its documentation and what kind of information it can provide may be useful.

[Hoff]

Details such as the DSF data and the embedded string symbol data can provide good clues into the general organization and the purpose of specific routines within the code, when performing reverse-engineering.  

There's no means to create a matching DSF file from an existing image.  That's the whole point of the DSF file; it's somewhere for the LINKER to put this data, if it's not stored in the executable itself.

Start reversing the code, using a disassembler and "strings" and related tools.   Or figure out from the API documentation or from the input and output or whatever this particular tool is doing, and re-implement the code.

If you don't have the source listings, then ring up HP.  Ask for the DSF format.  But expect you're going to be spending a whole lot of time on the reverse-engineering.

There are some pretty good disassemblers available for more common operating systems — tools such as Hex-Rays and IDA Pro — but AFAIK there are no similar tools for OpenVMS.   SRM_CHECK and such is what's available.

[Ruslan R. Laishev]

Hoff, thanks for the answer.

Do you meant VMS-source listing ? I have V8.2 but did not found something about the .DSF file record structure/format.

[Hoff]

---

Do you meant VMS-source listing ? I have V8.2 but did not found something about the .DSF file record structure/format.

---

You'd need to rummage the Linker and Debugger facilities on the source listings kit for details of the DSF files and related processing, and for any related SDL definitions files that might be available.  The DSF-related SDL definitions might be in one of those facilities, or might be stored over in one of the common facilities.

I wouldn't expect a whole lot of enlightenment from the DSF files in general, and if you don't have the matching DSF files for the executables involved, then this whole approach is probably a rock-fetch; not really worth the effort.

If you don't have the DSF files that were associated with the executable or the shareable image you're working on here, then you're headed toward using strings on and reversing the binaries.  

Even with a matching DSF, you're still necessarily going to be spending a whole lot of time and effort reversing the binaries.  Or spending time replacing the binaries, based on knowledge of the transformations that the binaries are providing.   The DSF can make reversing a binary a little easier, but it's still a complex and detailed project.

[Ruslan R. Laishev]

Ok, Hoff! I'll continue seaching in the listings ...

SRM_CHECK produce instruction listing, but w/o lines numbering and symbols has been stored in the .EXE file. I can see entry proints symbolic names in the DEBUG ...

[Hoff]

---

@Ruslan R. Laishev wrote:

Ok, Hoff! I'll continue seaching in the listings ...

SRM_CHECK produce instruction listing, but w/o lines numbering and symbols has been stored in the .EXE file. I can see entry proints symbolic names in the DEBUG ...

---

Um, and with no disrespect intended, so?   None of this is a surprise.    

Reverse-engineering on VMS isn't documented anywhere that I've seen.

Reverse-engineering is time-consuming and tedious, too.

You're going to learn more about the Alpha instruction set, and about the Alpha executable format.

In particular, you're going to have to learning the image formats and data structures, and then work through the executable code.  This takes a while, and the scope of the reversing project increases commensurate with the size of the binary.

See the Internals and Data Structures Manual for some information on the Alpha image headers.  The Alpha image header and related definitions are in the system libraries.  See the debugger symbol table (DST) stuff mentioned earlier for any latent DST records that might be present in the binary.  

If you don't have the corresponding DSF that was created with the binary file that you're looking at, then any discussions of the DSF don't seem particularly relevant — DSFs aren't instantiated out of thin air, and DSFs cannot be generated from existing binaries.

See the Alpha architecture reference manual (ARM) or the System Reference Manual (SRM) for details on the instruction set.

[abrsvc]

I will again mention about the instruction interleaving that happens on Alpha.  Assembly language instructions that pertain to a particular "line" of code can exist many assembly lines away from what seems to make sense.  Optimization of register usage along with instruction streaming causes register usage that may not make sense at first.

If the application is old enough, you may have better luck dis-asssembling a VAX executable image into MACRO32.  At least this approach would be little more straightforward.

Good luck,

Dan