Code scrambling in Nav-2009

subhaster wrote:

Hi,
I came across a scenario, where the code inside the diffrent objects (tables, forms, codeunits, reports) need to be scrambled/ encrypted. For example think of the following code :-
Customer.get(custno); where
Customer refers to a Record type vairable pointing to Customer table and
CustNo refers to cust. code.
Now we have to encrypt the code scriptlet in such a way that the functionality remains intact, but the meaning becomes un-decodable/un-readable/un-understandable.
For ex- the above code could be rounded to ''YURDM$ED.ROY(CSRTMY) ;
Is there any way to achive this?
Please suggest.

There is no sensible reason to do this. Best is that if you don't trust that people will steal your code, that you get out of the industry.

subhaster wrote:

Its not about my truting people; its a client requirement and the challange is to hide the code/ abstract it from from any outsider.

Better is to not allow outsider to read the data or even to connect. If you will set correctly permissions and other things, you do not need to scramble some code...

It can only be read by people anyway who have access to a username/password of the superuser or any other login set up with the appropriate permissions. (And have a developer licence.)

So what I'd do is to explain to the customer that the code is just like the data in their database: confidential, yes, to be protected, yes, but protected by usernames/passwords/permissions. They do not normally scramble their other confidential data like customer accounts, they restrict access to them.

Explain them that it's not not like any normal .NET application. It's data in the Object table in the database, compiled into a BLOB field, not different than any other confidential data in their database.

Yes I know often it's very hard to convince people of things like that, but this should not be an impossible case, "understand that it's just another kind of data in your database" is a fairly strong argument.

craigbarbs wrote:

Hi,

While it is not normal to protect or hide NAV code it is possible to do so. One of the partners has written an add-on to remove the source code from the complied objects (I think I came across it on Mibuso - Brught Consulting) This is possible because the binary version of the object and the text version of the object are stored in different fields.

If you choose to go this route it is imperative that keep the source protection outside of the development environment because once the code is removed it is lost forever.

The issue is whether it will work in 2009. I will not touch or implement any database that would have this modification

If at any point in time you need to debug, you can just import the same objects with the source code. Doing this will allow you to debug.

I do not think it does. The code onsite at a customer's would be scrambled. Only in cases when one needs to debug would you unscamble it temporarily. Once you have resolved the issue you would then fix the issue in the development environment and follow the normal process, which would ultimately result in the objects being scrambled again.

Also what happens when you try to compile (F11) the object, or export them?

It is a source code removal tool.

Regarding the ethics around this - I feel it would be ethical if the customer was aware of it and they were not tied to you. In other words, the customer could still own the source code it just would not be in the production database. The original request was a customer not wanting people to be able to view their code. If this is the case, then I see this as a solution that could work. My personal opinion is that if a partner were to retain the source code to tie a customer to them then that would not be a good situation for the customer or the partner. The customer should want to stay with the partner.

Regarding the F9 compile - I will not work once the source code is removed. However, I feel that this should not be done in the production database.

Anyway, everyone is entitled to their own opinions and I really feel I've said enough on this topic.