Operating System - OpenVMS
1748252 Members
3920 Online
108760 Solutions
New Discussion юеВ

Debug application without source code

 
SOLVED
Go to solution
Jenwae
Advisor

Debug application without source code

We develop application for customers, and we would like to deliver the executables without the source code to them.

How do we keep debugging info, INCLUDING able to look at the source code itself (that is, go to that line number and see actual code) in our case? This is needed so that we can remotely support our customers' system when it crashes, and we can instruct them to do debugging step-by-step.
11 REPLIES 11
Hoff
Honored Contributor
Solution

Re: Debug application without source code

My first reaction here would be one of an ill-considered approach. Guiding customers through debugging? Unless your target customer audience for this package involves OpenVMS programmers and you have source code, such a strategy seems aimed for failure.

As for what you can do, you can perform a remote SET SOURCE (assuming DECnet is available between the target system and the source pool) and gain access to your debugging in the target environment. But this gets ugly. This also does not benefit from compiler optimizations.

You could compile and link with debugging (though with the debugging disabled during image activation), and then drop the source code onto the system if/when needed. This does not benefit from the compiler optimizations.

Here, I would embed debugging mechanisms into the target application (such as capturing and logging failures in your signal handler, possibly with a self-throttling restart), would embed logging capabilities, would set up to acquire a process dump, and would also maintain the requisite source listings and map files so that you can field support calls in your environment and can debug the code in sutu. The listings (with machine code) and maps allow you to go from the raw binary process dump back to the source file.

Here is some related reading material on this area:

http://64.223.189.234/node/861
http://64.223.189.234/node/800
http://64.223.189.234/node/848
http://64.223.189.234/node/654

The other extreme is to ship full source code, and toss the whole problem over onto the target system. But you probably don't want to do that.

If you are seriously considering this, I might suggest you actually try it. Work with somebody with a skill level of your target customers here, and walk that person through a debugging session.

Most software houses here use the compiler listings and linker maps for this purpose. And integrated debugging.

Stephen Hoffman
HoffmanLabs LLC

Jenwae
Advisor

Re: Debug application without source code

Hi Hoff,

thank you for your reply and suggestions.

The deal is, in the past, we used to ship source code together with application to our customers based in Asia. Because they require almost zero-level downtime tolerance, they have a bunch of OpenVMS and Fortran programmers who will assist us in debugging on target environment whenever application crashes. We give instructions over phone. So, the source code is important so that they can read the offending source line to us almost immediately.

However, at the same time, we want to protect and preserve the proprietary rights of the application/software we develop.

Hope this explains the approach. We are open to any other approaches you can suggest.

Thank you.
Jenwae
ITS
Hoff
Honored Contributor

Re: Debug application without source code

Ah, software copy protection. An approach that has been being tried and has been failing for, well, decades now. You're trying to do what many media and content providers have sought to implement, and have failed. (HD DVD and BD security was cracked, for instance.)

There's no magic elixir here, and there's no way available within OpenVMS to embed the source code into an executable.

Obfuscating the source code has most definitely been tried by many folks, and hasn't been found particularly effective. Or you can ship an encrypted archive. And once decrypted, there's no protection against replication. Which means this is a one-shot source code protection scheme. Which quickly reaches the "why bother" stage.

You can run this in-house (with built-in debugging assists in your code and source access), or you set up a DECnet path to allow remote access into your source code servers from the client boxes, or you run with the sources available in the client environment.

John Gillings
Honored Contributor

Re: Debug application without source code

Jenwae,

Look carefully at all the available debugging options. You can separate the debug information from your image using /DSF. You can also use process dumps, so if there's a problem, the customer can send you the dump, which you can analyze on your system (which has DSF and sources).

You may also be able to move the sources to the client system when/if required, perform your debugging, then scrub them away afterwards.

See also the SET IMAGE command to turn debugging on or off.

At an architectural level, you could use one or more logical names to enable and control application tracing and logging. Build yourself a shareable image with calls to log events or state changes. It can control ir and where messages are written.
A crucible of informative mistakes
kari salminen
Advisor

Re: Debug application without source code

If the customer has a problem with one program, he just needs the source code/listing + map for the failing part, not the complete source code.


Wim Van den Wyngaert
Honored Contributor

Re: Debug application without source code

You could deliver the save set encrypted and dexcrypt it when you need the listings. See
http://h71000.www7.hp.com/doc/83final/6048/6048pro_021.html#startsubcommand_121 in /encrypt.

Not very safe but a beginning.

Wim
Wim
Jenwae
Advisor

Re: Debug application without source code

Hi everyone, thanks for your input.

Hi Hoff,

thanks for the clarification. Looks like there is no effective way to do what is required.

Hi John,
Yes, the DSF provides the symbols on a file. I believe the same can be done by using /DEBUG which will store symbols with image itself. Sending the DUMP is one option considered, but because our intention is to resolve the problem at the target environment as soon as possible over the phone, this limits its effectiveness.

Hi Kari,
from what I understand, I will still require the source to be delivered. We never know which program section the system will crash real-time in the future.

Hi Wim,
that's an idea too, again, like you said, not very safe. Once decrypted, customers have full access to source. At the moment, we do not have remote control of the target system, something we are thinking to do in the future.

Hoff
Honored Contributor

Re: Debug application without source code

To the folks that have suggested encrypting single files or small groups of files, might I suggest considering what that might entail? You have to encrypt individual files or small groups or directories and pass out the individual keys if you're going to expose the decryption key(s) to the end-customer programmers, and then structure the pieces for unpacking and for deletion. And any debug pass of a non-trivial program is going to involve include files and a variety of other pieces related to the failing source modules.

Sure, it's possible.

It gets really, really ugly. Really quickly.

And any code that's exposed is gone.

Plus you leave a very bad taste lingering in your customer base.

The other obvious approaches here are to crash less (yep, my stranglehold grip on the obvious), and to automate the receipt and processing of known fixes, to automate detection of crash-prone code, and to respond to downtime within the customer's window.

(There are ways to fully automate crash processing. That goal is at the core of the CLUE CRASH stuff, for instance.)

To eliminate the need to distribute the source code in all but the most extreme cases.

Jon Pinkley
Honored Contributor

Re: Debug application without source code

I have to agree with Hoff here. What you want to do, specifically debugging code without remote access to the system, is not very effective. And encryption of the source code is not an effective solution if the purpose is to prevent the customer from getting access. Even if it were possible to encrypt the source code in such a way that it was only visible from the debugger (i.e. the decryption was somehow done by a plug in to the debugger), even that wouldn't protect the source from being seen with the debugger's list command.

This is a similar in scope to attempting to limit what a privileged process can do, for example granting one a "single" privilege in the "ALL" class and thinking that the process will be limited to what is suggested by the privilege name.

If you can't do the debugging needed using the process dump facility, then you really need to get remote access to the system. You may be able to remotely mount a disk at your site using an encrypted connection, but that is not going to be transparent. It would give you the least exposure, as the disk would only be available while the link was up. It would be a very low performance "disk", but for debugging purposes, it would probably be acceptable, and it would also make it a bit harder for the customer to copy the data (at least in a way that was not detectable).

But as Hoff also said, the best solution is to write robust code that doesn't need to be debugged at the customer's location.

Good Luck,

Jon
it depends