Protecting source code

[Former Member]

Hi,

I would like to ask if anyone knows of any reliable existing approaches for protecting ABAP source code?

As a supplier of 3rd party software, it is a concern that there is no protection over visibility, let alone maintenance of code (ie. READ/INSERT REPORT).  This allows for intellectual property to be copied and server-based licensing mechanisms to be bypassed.

Alternatively, is anyone aware of moves by SAP to support this capability in the NetWeaver stack - given its hoped for wider audience in the development community?

I saw in a recent Business One presentation that it is not possible to access the source code, so perhaps the capability is already in NetWeaver, just not generally available?

Regards,

Scott

[Peter_Inotai]

I haven't played with it, but once I copied this from SAPFANS...none of them is an elegant solution...just a workaround:

Incho

"In SAP releases upto 4.6C you can place the special character sequence *@#@@[SAP] on the first line of an ABAP

to hide the source code - it will still run and behave as normal. To bring the code back to visible you must upload it

again from a file or put it into a Transport - release it, then edit the transport file and remove the character string.

For 4.6C you can look at table: D010SINF  This table includes a field SQLX. When this field is set to "X" the program

source will not be viewable as for program: SAPMSYST."

[Former Member]

On our 4.6C DEV box we have 112064 programs where D010SINF-SQLX = "X", including SAPMSYST. I can view the source code for most of them, but not for SAPMSYST.

This may not be the proper solution for hiding the source code...

Gabor

[dirk_feeken]

Sorry, there's no official support for protecting ABAP source code.

The existing more or less dirty tricks to supress the visibility of the sources in the editor (some start sequence of special characters in the first line) are probably not what you are asking for, because it would be still possible to get the sources if you really want it.

That the sources in other languages seem to be more protected is usually not an intended feature but the result that you usually distribute only the compiled binaries - with a lot of drawbacks on the other side.

The ABAP sources of an SAP application are needed for technical reasons. It's not possible to ship just the binaries because recompilations are neccessary at the runtime, for example after installing support packages. Only the availability of the sources allow real remote support and the absolutely neccessary extensibilty by our customers. Practically every R/3 customer has at least some small changes in the code. An application consisting of only static binaries acting like a black box wouldn't be flexible enough to run real business applications.

It would be possible, of course to build a framework around ABAP that allows shipping the sources in some encrypted format which is decrypted for rebuilding, remote support or extensions. But this requires that there's a decrypter in the system somehow, and some technology that prohibits the misuse of it. How can it be avoided that customers see the code when they want (realistic scenario) to make only small enhancements in all "interesting" parts of the software? Such a technolgy would increase the complexity and limit the flexibility.

Last but not least stealing intelectual property by copying ABAP code hasn't been a big problem for SAP in the last decades. Maybe because <speculation> the typical ABAP coding reflects the standard business scenarious which are known anyway while more secret technical algorithms ( memory management, database access,...) are part of the kernel written in C. </speculation>.

But I admit that this topic might be more serious for software partners and it is discussed internally. A discussion here about the importance is welcome!

regards,

Dirk

BTW: Business One is not written in ABAP.

[Former Member]

Hi Dirk,

I think the importance of the discussion really depends on:

1) how you manage the pre-sales evaluation cycle.

2) size of the solution.

It doesn't surprise me at all that IP stealing has not been an issue for SAP, given the complexity and pre-sales manner.  But if one were to distribute much less complex (and cheaper) evaluation software more freely, then it does become more of an issue.

I fully understand your points about re-compilation, however I got the impression that the D010SINF flag Peter pointed out just prevented access to the source code, rather than omitting it.  But of course I really have no idea.

Anyway, thanks for your detailed reply.

Cheers,

Scott

BTW: I'm surprised about Business One, but then I don't really know anything about it.

[Former Member]

Hi Scott,

to the best of my knowledge up to SAP 4.6c there was no technique to distribute ABAP programs without the source code. There were some solutions that had a more or less sophisticated mechanism to hide the source, but any experienced Basis person could retrieve the code. I think the main reason is, that you possibly have to regenerate the byte code from the source (as far as I understood the compiled ABAP byte code is machine dependent as opposed to e.g. Java class files, but maybe somebody could comment here in more detail).

I followed for quite a while similar discussions in Java forums. There you have the same problem, since class files can easily be dis-assembled. The only protection you have is to use code obfuscation (that might be something you'd like to look into for a somehow superficial protection) and supply the software with detailed licenses. It's then a matter of the company's laywers filing law suits against any persons violating the license...

As you've pointed out, it also depends on the type of software you're distributing. Personally I think that one of the biggest advantages in SAP is their open source code (if we skip the functions implemented in the kernel). It's a big advantage being able to debug ABAP programs and often gives important insights (e.g. those mysterious error messages that no functional consultant can explain, until a Techie debugs the whole program).

Best wishes, harald

[Former Member]

If I remember rightly, it was when I started ABAP / SAP, a part of the license for R/3 stated, Any code developed in SAP could be copied and distributed by SAP. So check the legal position of this before you disribute your software.

The only alternative I would suggest is, write the application in C, and have a small ABAP program to call C-Function. This is the same way that SAP interface with the Kernel.

[WolfgangJanzen]

Well, you cannot do it exactly the same way since you cannot implement any C functions in the kernel. But you might consider to ship an external RFC server program (where you are free to choose the development language of your choice) only as binary file (but then you'll have to support multiple platforms ...) and invoke RFC calls from ABAP to that external RFC server program.

But you better make up your mind:

do you want to make use of the platform-independence of Java and/or ABAP - where you have to accept that source code cannot be protected reliably. Or do you emphasize on protecting your source code (at all costs)? Well, in that case I'd suggest to host the application offering only web service-based access. Because even a compiled binary can be reverse-engineered. Every program you ship out can be analysed - it's just a matter of effort and smartness.

Wolfgang

[Peter_Inotai]

Another dirty way:

http://searchsap.techtarget.com/tip/1,289483,sid21_gci541317,00.html

Incho

[Former Member]

Hi Peter,

Thanks for your interesting suggestions.

Scott