VMS C decompiler

[Nicolas Dumeige]

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

[Volker Halle · Accepted solution]

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.

[Ian Miller.]

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?

[Nicolas Dumeige]

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 ?

[Volker Halle]

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.

[Ian Miller.]

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.

[Peter Quodling]

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

[Jan van den Ende]

Peter,

are you competing for
"Understatement of the year"?

Proost.

Have one on me.

jpe

[Lawrence Czlapinski]

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

[Lawrence Czlapinski]

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

[Ken Robinson]

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

[Peter Quodling]

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

q

[John Gillings]

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.

[John Gillings]

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.

[Stanley F Quayle]

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.]

[Lawrence Czlapinski]

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

[Peter Quodling]

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

[John Gillings]

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?

[Peter Quodling]

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

[Nicolas Dumeige]

Thanks every one for those valuable informations.

Cheers

Nicolas

[Nicolas Dumeige]

Thanks everyone for those valuable informations.

Cheers

Nicolas

[Nicolas Dumeige]

EOF ;)