Protecting C/AL Code

Emosoft

Hi all,

I was wondering is there any reliable way to protect NAV code from being reused by other partners. I thought extension is the answer as object disappears. But when I try to debug, I'm able to see all the code in the extension. It's as easy as I created a tool to export licence file from NAV DB. So it appears the whole extension idea is useless at the beginning. Protection is zero...
I can remember I already used a "hack" tool that deletes code in compiled 2009 object, but I cannot find it. I made some tests in 2017 without a deep SQL profiler research and I was not able to delete/hide the code. So before doing any further tests I want to ask if somebody already knows any reliable way to protect a C/AL code?

Slawek_Guzek

The company who provided the 'hack', Navutilus, no longer offers this solutiuon. Myabe you will be able to find it somewhere in downloads at mibuso.

But the real question is not if it is possible and how, but if you should do it at all.

If I were to become a customer of yours and you did something like this, I would be locked to you forever. No one else would be able to help me if a bug in your code was hampering my system. If you became busy doing other things, or lost interested in NAV, I would be left with no support. For me it would be good enough reason to not to enter into contract with you in the first place.

Slawek

Emosoft

Slawek_Guzek wrote: »

The company who provided the 'hack', Navutilus, no longer offers this solutiuon. Myabe you will be able to find it somewhere in downloads at mibuso.

But the real question is not if it is possible and how, but if you should do it at all.

If I were to become a customer of yours and you did something like this, I would be locked to you forever. No one else would be able to help me if a bug in your code was hampering my system. If you became busy doing other things, or lost interested in NAV, I would be left with no support. For me it would be good enough reason to not to enter into contract with you in the first place.

Slawek

Thank you Slawek.

Your right about your concerns. But anyway nobody else can edit extensions, right?!? That's the idea, that's why MS do not show the object. So it's not supposed to be edited by somebody else.
As you can see I do not talk about customizations, I talk about an installable package. But the code is inside anyway (very professional security )
I already checked. Object table contains compressed code. I can damage it, I cannot revert or change it. But this is good enough. Object cannot open for Dev, but it's still runable.
The problem now is that Object Metadata table contains the compiled code but it includes C/AL code which is visible in the debugger. So compiled object in any form means 100% visible code.
The conclusion for now - we cannot protect out property. The whole idea of extensions fails.

JDVyska

Emosoft wrote: »

The whole idea of extensions fails.

That requires believing that the primary or even secondary point of extensions is protecting the source code.

I do get where you're coming from - if you come up with something very clever but simple, you're correct that you have little technical protection, only legal ones, and there you're going to have a tough time. I have not seen a significant amount of IP theft in this industry, though. So, maybe others could chime in if they've experienced it and what happens when it does?

Emosoft

Hello Jeremy,

Thanks. You're 100% right! I know the industry very well. That's why I want protection. Now only legal one.
If licensed objects and licensed users limit are protected only by law enforcement and legal terms, it's ok for me that extension code is not protected.

But let's focus on the topic. How we can work-around this bug.

JDVyska

If you go through the process of getting your Extensions approved by Microsoft for their marketspace, you'll get your own assigned object IDs and license controls like the old school ISV way, from what I understand. Long haul though, their requirements are pretty strict and process long.

Emosoft

Anyway, I've found a way to make run-able object (codeunit) without any source code.

But that does not solve the extension problem. Package + core.fob is not an idea at all. Going that way I can do it as I did before extensions - DotNet DLL. Current project was more suitable for C# (JSON Web Service two way sync.), but the idea was an extension and "keep it all in NAV".

I have not tested how about VSCode. I want it run in older versions.

Slawek_Guzek

What happens if you compile the runnable codeunit with stripped source code?

Emosoft

Nothing good, NAV just show error. Objects are left in the last compiled state.
Which means a codeunit should implement only core logic with parameters - zero references to other objects such tables.

Conclusion: Hard but not impossible. But this cannot be used with extensions. FOB export is also impossible. So it does not solve my issue.

Slawek_Guzek

Exactly. You could potentially build something in NAV which would strip the source code, make this a part of the upgrade codeunit but still it would not warrant that the code will be executed and objects 'protected'

Also your customers may want or may need to recompile all the objects, it could be even a part of security policy.

I've been through that subject (as a vendor) long time ago

A way to approach this imho is to make an Add-On, hide some small but crucial part of the logic in there. You could the tie up the add-on to specific license number or a combination of license number and some text - lets say passing in each call to your add on a SERIALNO, or/and a text 'This Add-On belongs to Company X' - and check the combination of both inside compiled code

I know, the add-on can still be copied and used but at least it is a blatant theft easilly visible in the code. No serious organisation would agree to accept a solution from a vendor which makes use of stolen property, and such a protection would make is very clear that the solution used is nicked from someone.

Slawek_Guzek

The other possible solution i can think of is obfuscation. Make all var, function and field names names in your objects and tables either very short (a1, a2, a3 and so on) or very long (use GUID for each name).

It would make it a real pain for potential competition to understand and debug your solution (as well as to your staff supporting your customers )

ara3n

With VS Code your code is hidden by default.

Emosoft

Thank you for all ideas. Today we still don't have a good solution, but a temporary fix in the test environment (new live DB of a customer) where the code in the main codeunit is hidden. (The object is compiled, it still has table references, and events on 3 tables.) We deleted (broke) the code in 2 places in NAV's system tables with a new tool. Of course this change cannot pass timestamp - hashcheck of NAV, so Development Environment says very bad things about the object, while the in-client debugger just crashes when execution jumps to that codeunit.

Obfuscation is a very good technique, but its primary idea is to further confuse developers using disassembled code (including disassembling software).
About licensed objects - I work with different countries. In this particular case it's not a good solution as I have a reason to think that MS employees are corrupted. And so for everything in that country in terms of NAV "partners". It's a wild market. Of course it's a personal feeling and decision, and it depends on the conditions. Again good protection is not "dependable" by someone or something (MS, authorities and so). But if I start to discuss the whole design and security of NAV and customer data, it's going to be a very long topic and we're going nowhere. (Have you implemented NAV in a bank? I have... It was "funny".)
Despite all that Add-ons are times less secure than encrypted obfuscated DLL (with assembly name of the company). At least Add-ons could be debugged -> copy paste the source... and "game over".

If somebody is interested, I can send you the tool. It works on 2 fields:
1. Table "Object" field "BLOB Reference"
2. Table "Object Metadata" field "User AL Code"

p.s. "User AL Code" should be renamed to "Public AL Code"

Slawek_Guzek

I'd be more interested in learning what solution are you trying to protect to that extent

Emosoft

The solution is not so important.But more important is the idea. We want to move to a new level. Without proper protection that is not possible as current level is good enough but it does not require such quality standards.

This particular solution is not so big. Let's say 1000-1500 rows of code. Custom JSON encoders/decoders. The other part is an access to a buggy Web Service of another software system with 2 way sync. support. Everything is defined in a setup - truncate PKs, truncate fields, overwrite, 3 URLs for each different module communication... and 15-20 more settings. Insert/modify/delete triggers are catch by event functions. Delete queue table... I say that but the code is "high density". For example 15 rows are really cleaver solution for JSON tree decode (and tree of a tree), tested tenths of time till perfection. They're not just average 15 rows written for about 1-2 minutes. This applies for the whole solution as it took 3-4 times more than a normal only because of the quality standards and the density of the code where the structure is perfectly clean, readable and reliable. Even variable names are very carefully selected. The extension idea is exactly that, right? - "made it once, sell it hundreds of times". But we failed at the beginning with no real protection of the source code. I thought it should be a joke. But sadly it's not.

I would ask - And now what? No extensions for M$ ?!? We just don't have a choice...

Slawek_Guzek

Don't get me wrong please but you are probably barking at the wrong tree imho.

Companies don't buy the code. They buy a solution for a particular problem. While I am personally trying to polish my own code to the perfection, I also know that for the buyers it does not really make any difference if a particular function has been written in 30 or 300 lines, as long as the system handles required scenarios without throwing errors, and the code performs reasonably well.

From customer's perspective the idea and particular functionality solving business problem carry the most value, and not any particular coding. And the idea and solution come from the knowledge of the particular industry. While an idea or solution/code can be stolen the knowledge not, therefore protecting the particular coding is not that much important - especially if it, in fact, affects severely your ability to serve customers (can't debug protected solution).

The quality/compactness of the code counts the most when a problem happens and you need to address it, or when you need to change the functionality, be it to add/change functionality, or tune performance. But in those scenarios industry and solution knowledge is equally, or even more important.

Having said that I can see the MS is gently but steadily pushing vars channels out of way, trying to sell more and more cloud with relatively thin customisation layer on the top of the standard NAV. The 'app' shop and extensions concept goes against "traditional" NAV values - huge adaptability and close relations between partners and customers. In that model protecting the code may be much more important than it is now. Damaging object code will certainly not be allowed as a way of protection, but obscuring it might do. Or moving important/protected part of it into some 'Azure function' called from inside your app.

Astinia

Emosoft wrote: »

Thank you for all ideas. Today we still don't have a good solution, but a temporary fix in the test environment (new live DB of a customer) where the code in the main codeunit is hidden. (The object is compiled, it still has table references, and events on 3 tables.) We deleted (broke) the code in 2 places in NAV's system tables with a new tool. Of course this change cannot pass timestamp - hashcheck of NAV, so Development Environment says very bad things about the object, while the in-client debugger just crashes when execution jumps to that codeunit.

Obfuscation is a very good technique, but its primary idea is to further confuse developers using disassembled code (including disassembling software).
About licensed objects - I work with different countries. In this particular case it's not a good solution as I have a reason to think that MS employees are corrupted. And so for everything in that country in terms of NAV "partners". It's a wild market. Of course it's a personal feeling and decision, and it depends on the conditions. Again good protection is not "dependable" by someone or something (MS, authorities and so). But if I start to discuss the whole design and security of NAV and customer data, it's going to be a very long topic and we're going nowhere. (Have you implemented NAV in a bank? I have... It was "funny".)
Despite all that Add-ons are times less secure than encrypted obfuscated DLL (with assembly name of the company). At least Add-ons could be debugged -> copy paste the source... and "game over".

If somebody is interested, I can send you the tool. It works on 2 fields:
1. Table "Object" field "BLOB Reference"
2. Table "Object Metadata" field "User AL Code"

p.s. "User AL Code" should be renamed to "Public AL Code"

I am interested, could I have this tool?