topic VMS C decompiler in Operating System - OpenVMS

VMS C decompiler

Nicolas Dumeige — Tue, 20 Sep 2005 04:17:49 GMT

Hello everyone,

A manager ask me if I can help :
- we have a C based binary that works nice
- we don't have the source code for that version, but an older one that is no satisfactory.

Is there a chance to get even ugly or non working C looking source code from the binary ?

Thanks all for your help,

Nicolas

Re: VMS C decompiler

Volker Halle — Tue, 20 Sep 2005 04:43:14 GMT

Nicolas,

what is the problem you're trying to solve ?

In general, you can't decode machine instructions back into C code.

Depending on the operating system and architecture (are you talking about OpenVMS VAX, OpenVMS Alpha or OpenVMS IA64 ?), you could decode the binary instruction stream using SDA (or PATCH) and get back machine code. On VAX, you can get some idea, what the machine code is doing (especially if you have the machine code listing from an older version of the same module), but on Alpha or Itanium, it's much harder or near impossible.

If you just want to run your existing 'nicely working' C binary on another OpenVMS architecture, there are binary translators available for OpenVMS VAX to Alpha and Alpha to Itanium, which will take your existing binary and produce a new binary to be run on the target platform.

Volker.

Re: VMS C decompiler

Ian Miller. — Tue, 20 Sep 2005 04:44:02 GMT

There are ways to disassemble images to produce assembly language on VAX, Alpha and Itanium VMS systems. However I don't think you can get back to the original C code as much of the data need is not present.

Why do you wish to have the source code for this application?

Re: VMS C decompiler

Nicolas Dumeige — Tue, 20 Sep 2005 05:19:34 GMT

REM : the application code is our, no hacking there.

The migration is from VMS on alpha to Solaris on Sparc : is there a way to get a working binary on Sun from the one on VMS ?

Re: VMS C decompiler

Volker Halle — Tue, 20 Sep 2005 05:24:20 GMT

Nicolas,

no way from OpenVMS to Solaris ;-(

Everything is different, operating system interfaces and machine architecture. You could expect binary translators to only work on the same operating system, if that is available on machines with different architectures, as is OpenVMS from VAX to Alpha to Itanium.

Volker.

Re: VMS C decompiler

Ian Miller. — Tue, 20 Sep 2005 05:44:03 GMT

If you wish to downgrade your platform from VMS to solaris then you will have to reimplement the application on Solaris.

This will be one of many costs associated with this migration.

Re: VMS C decompiler

Peter Quodling — Tue, 20 Sep 2005 06:01:02 GMT

You haven't specified whether this is VAX or Alpha. VAX would be hard enough. Alpha, gets more complex as the Alpha compiler can "optimize" for different interations of Alpha Chips. THere is no guarantee that the images tht you have, are optimized for the platform that you have, particularly given that you have "lost" the source code.

Depending on how different the previous version you had, was from the version you are working with, you might be able to compile a version of the older and compare that with an SDA wander through the newer version, but you would be a braver person than most here to take on something like that.

Also, the move to solaris - there are plenty of "war stories" around that, that can come from here... I for one find that the Solaris C compiler has a propensity for memory leaks.

q

Re: VMS C decompiler

Jan van den Ende — Tue, 20 Sep 2005 11:05:20 GMT

Peter,

are you competing for
"Understatement of the year"?

Proost.

Have one on me.

jpe

Re: VMS C decompiler

Lawrence Czlapinski — Tue, 20 Sep 2005 13:53:31 GMT

Nicolas:
1. You can't translate binary to C. You can only translate binary to machine language or assembler if you have a translator. A VAX assembly language program would not work on a different type of hardware even an Alpha without a translator or emulation on the Alpha. The assembly language program would not be maintainable since no one would understand it. Even documented assembly language programs are easy to break and difficult to maintain.
2. You can't normally translate a binary from one vendor to another. Sometimes a vendor will provide translators from one hardware type to another another hardware type (like VAX to Alpha, VAX to Itanium, Alpha to Itanium.
3. If you don't have the C source, you either have to run as is or rewrite the application. It shows why Software Configuration Management and Software Quality Assurance are needed functions.
Lawrence

Re: VMS C decompiler

Lawrence Czlapinski — Tue, 20 Sep 2005 14:00:44 GMT

Nicolas: You can either start with the non-working C looking source code and document how much needs to be fixed. Then generate manhour and cost estimates for fixing and rewriting from scratch. Do you at least have functional and design specicifications?
Lawrence

Re: VMS C decompiler

Ken Robinson — Tue, 20 Sep 2005 14:46:21 GMT

If the source was compiled "/debug" and you still have the objects, you might be able to recover the soure from there.

Or you just tell your management that they can't migrate to Sun, since the source for a critical part of the system can't be found...

Ken

Re: VMS C decompiler

Peter Quodling — Tue, 20 Sep 2005 15:33:28 GMT

Hey Jan, "Understatement?" Hey anything is possible if you want to throw enough money and time at it.

q

Re: VMS C decompiler

John Gillings — Tue, 20 Sep 2005 20:35:10 GMT

I disagree that can't translate binary to C. It would be relatively simple (but extremely tedious!) to create a mapping from VAX, Alpha or even Itanium instructions into an equivalent C program. Of course it wouldn't make any sense, would be impossible to modify and probably wouldn't generate the original code when compiled. The biggest issue would be working out the routine linkages. Tricky, but again, not impossible.

In reality it would be MUCH easier to rewrite the application from scratch, based on the specs than attempt to take this path. (and in future, take better care of your source code?)

As for migrating from OpenVMS to Solaris... well, about the best I can offer is to wish you good luck. You'll need it.

Re: VMS C decompiler

John Gillings — Tue, 20 Sep 2005 20:37:21 GMT

re Ken:

>If the source was compiled "/debug"
>and you still have the objects, you
>might be able to recover the soure
>from there.

Sorry, that won't help. /DEBUG doesn't embed the source code into object module or executable image, it just inserts pointers back to the source files.

Re: VMS C decompiler

Stanley F Quayle — Wed, 21 Sep 2005 09:11:29 GMT

If this code is coming from a VAX, you could always run CHARON-VAX on a Windows system. That would at least get you off DEC hardware.

http://www.stanq.com/charon-vax.html

SRI test-compiled CHARON-VAX a few years ago on Solaris. But there wasn't any market for it.

[And yes, this is a Shameless Plug (tm) from a CHARON-VAX reseller.]

Re: VMS C decompiler

Lawrence Czlapinski — Wed, 21 Sep 2005 12:11:46 GMT

John Gillings:
1. Ok, if you write a translater, you can translate assembler instructions to C instructions. It's outside my skill set. There is no incentive for HP to write such a translator which would help move customers off their hardware. It would cost some amount of manhours to write such a translator, document it and test it.
2. The hardware specific parts of C would probably not run correctly on on other hardware if it ran at all. It is hard to know whether the original programmers separated hardware dependencies into separte routines or where in the generated C those depenencies would be.
3. The output from a translator to C would be just a bunch of C instructions. Without a frame of reference as to what function the instructions are performing or what interconnections there are, it would be extremely difficult for most C programmers to attempt to maintain the resulting C. Without documentation, I would tell management that it would be a waste of manhours to try and maintain it. It would be easy to break something. The C names would not give meaningful information about the context of what is being done or the intent.
Lawrence

Re: VMS C decompiler

Peter Quodling — Wed, 21 Sep 2005 18:09:25 GMT

Back in my early SW Development days, we used to refer to software projects as being SMOP's or SMOM's (Simple Matter of Programming) or (Simple Matter of Money). Smops can be coerced out of developers with Beer and Pizza or sutble comments that you don't think that they could do something like this (be careful of that one - it's a one shot only approach).

SMOMs on the other hand. How deep are your bosses pockets (and how big/complex is the application.)

q

Re: VMS C decompiler

John Gillings — Wed, 21 Sep 2005 23:55:16 GMT

Lawrence,

Yes, we're in "violent agreement" here. It would be fairly pointless to actually do it, but nevertheless, it is possible. A deterministic programm running on a Vonneumann type machine, expressed in any form of programming language can (in theory) be translated into any other programming language.

Whether the resulting program would be readable, efficient or at all useful is a different question.

Apart from the computer science theory, there is also the business case. Obviously it's not in HP's interests to create such a processor, if the objective is to move applications from HP hardware to Sun hardware.

Maybe Nicolas should be asking these questions in a Sun forum?

Re: VMS C decompiler

Peter Quodling — Thu, 22 Sep 2005 00:09:21 GMT

Sector 7, www.sector7.com do VMS to Solaris (et al) Migration services, however nothing on their web site indicates that they are capable of doing binary disassembling.

Also, if one digs back through the Decus/Encommpass archives, for an app called dism32, as I recall, it was a VAX disassembler - one could learn from it (Although alphas are less amenable to reverse engineering code, due to the Optimization that exists within some of the Alpha compilers (definitely in things like Bliss, don't know about C)

q

Re: VMS C decompiler

Nicolas Dumeige — Fri, 23 Sep 2005 07:43:43 GMT

Thanks every one for those valuable informations.

Cheers

Nicolas