Need an encryption product for NAV2013 R2 - does one exist?!

boywonder

As per title, willing to pay for such a product that will enable C/AL code to be hidden/encrypted. Artcount had a good solution for 2009 but don't have anything for 2013 due to the architecture changes.

Is one out there yet? Thanks

vremeni4

Hi,

As far as I know because of the technical reasons this is not possible any more. And frankly speaking this is good so.
See http://www.mibuso.com/forum/viewtopic.php?f=23&t=44914&hilit=code+protection
for more reason why the code should be visible.

The best way to protect you code is to register an Add-On by Microsoft and to get a specific Object ID range assigned.
In that case you code will not be visible to the partners or clients.
It will also be protected as an Add-on, so you do not need to fear that someone may use your solution.

I hope this helps.
Thanks.

mdPartnerNL

Your addon is NOT protected with that range.

boywonder

I was speaking to a colleague in the UK who said the Nav payroll reseller use encryption, so it is possible & I want to buy a product for this...

vremeni4

Your addon is NOT protected with that range.

I do not understand what you mean. If you get an Object range assigned by Microsoft for your add-on, then the code in that add-on range is not accessible.
If you try to open such object you get the error message "The object is not in your permission range ...."
On the VOICE you can set the option that Objects can only be executed or indirect permissions.

Thanks.

SiSt

It is pretty easy to open objects protected by the add on range.

It is still possible to hide the code in the development environment, but with the same disadvantages like before and it is possible to extract the source code from the. Net code. But it is possible is to obfuscate the code so that you cannot read it anymore. I've a working prototype that is already used by a partner. Feel free to write me an IM if you want to get more information.

vremeni4

I was speaking to a colleague in the UK who said the Nav payroll reseller use encryption, so it is possible & I want to buy a product for this...

Hmm, the biggest reseller of NAV Payroll in the UK is Miraclepay (and probably the only one), but they are not on NAV 2013 R2, as far as I know.
The code is protected in NAV 2009 R2 but not in the later versions.

So it would be interesting if you colleague from the UK could tell us more.

Thanks.

faludigabor

Hi ,

It is against the partner agreement to encrypt the code and the tools is no longer available either.

I suggest you look for an addon range or legally protect IP.

g.

Marije_Brummel

I've always disliked encrypting code, but I do understand why people want it.

However, with the introduction of the RTC/Service tier, al AL code is kept in two places.

1. In the C/Side objects
2. As comment in the C# generated code

You can still encrypt 1 as far as I know, but you cannot prevent anyone from activating #2.

However, it is a lot of work to gerenerate code from #2 to real AL code. So if someone is willing to invest that time, I am guessing the orriginal owner of the IP has messed up so badly that, I guess, well, you know what I mean.

rdebath

It is very difficult to hide the source code in 2013R2.
The source is now stored in (at the last count) three different locations.

The licensing limitations on viewing the objects have always been a basic block, but not an insurmountable one. The deletion of the source code that Miracle do was reasonably effective in V5 but could still be reversed if anyone believed it was worth the effort. (Because Nav byte code was never obfuscated).

With 2013R2 deleting the source code from the FOB objects does not delete even a significant part of the code.
The code is saved as comments in the C# code and directly for the debugger.

But the major problem with RTC is that it has to regenerate the C# code from the C/AL code if there is a significant difference in version number between the database an object is exported from and the database it's imported into. For 2013R2 'significant difference' appears to mean any difference in version number.

Technically this means that a company that deletes the source code from the FOB files has to keep a database for every single hotfix version of the executables that any of their customers may have. Or specifically limit the versions that their code will run on, either forcing their customers to upgrade to a specific hotfix, or worse, blocking their customers from upgrading to a Microsoft hotfix that may fix an operational issue like the recent data dictionary corruption and data loss scenarios.

For Nav2013 there are significant and ongoing barriers to hiding your source code which are only likely to get worse.

However, there is a good side. The RTC client requires a service tier and it is now quite simple to integrate DotNET DLLs into Nav cleanly on the server side. This means that compiled (and obfuscated) DotNET code can be linked with C/AL on the server and have no client requirements beyond the Nav standard. This does not impact the ability to run using both the 'windows client' and the 'web client'. Using this your 'special' code can be compiled into one or more DotNET DLLs and only display and wrapping need have visible source code. Obviously this will mean that your code cannot be written in C/AL (though you may be able to extract and compile the C# translation into your DLL, or there are other Pascal like languages) but this shouldn't be too large a problem compared to the administrative issues otherwise.

mdPartnerNL

Actually the c# code is created by a special background service/task if im correct. The moment you import the fob or compile a fob a trigger is set and the meta data table is updated.

So this would suggest that obfuscated code can be imported into the meta data after importing the empty fob.

just guessing.

rdebath

The task is foreground, it appears to be a DotNET DLL (it starts up very slowly) and it runs as soon as you save an object before a prompt returns. It is run after the object is successfully saved and can die without any message (the C# code just isn't there) with a message or killing the client too.

When importing objects it's run during the "Processing Objects" phase. In V7 the "Tools->Build Server Application Objects" option will continue to create the C# code if the "Processing Objects" phase crashed or the object metadata (C# code) has been deleted.

If there is no visible "Processing Objects" phase then either you have "Enable for Microsoft Dynamics NAV Server" turned off (V6) or you are running the Native Client (V6) or the C# code stored in the FOB is acceptable to the client. Note: for early V6 clients 'acceptable' may not mean runnable. For V7 clients 'acceptable' appears to mean "exactly the same build number".

When the C# code needs to be run by the Service Tier, it will call the "csc.exe" program to convert the C# code into a DLL which is stored (temporarily) under the ProgramData tree on the server. Note: It is possible for these DLLs to be flagged as a virus by AV software, so, if installed, the AV software should be configured to exclude this directory.

The first phase (converting to C#) needs to dereference automation objects and DotNET variables to check the compile. This means that those DLLs MUST be installed on the client even if never run there. Only DLLs that are called to run server side need to be installed server side.

Beware the addition metadata in the 2013R2 database, stored in the "Object Metadata Snapshot" table makes removing tables from the "Object Metadata" table dangerous at best.

Before 2013R2 the "Development Environment" also handled the task of updating the SQL tables to match the Navision data dictionary (add and removing columns, indexes etc) With V7.1 this task has been handed over to the service tier. This means that for table changes you must have a service tier running and it must have access to the database to do this job.

This task is NOT done by the service tier in sync with the saving of the object; it is done when a client is started after saving the object. This BTW includes changing the collation of the database, with 2013R2 the database has to be put into single user mode to update the metadata but must be put back into multi-user mode to actually change the data.

The most recent hotfix rollup apparently has more changes in this area; I haven't looked yet though.

ppavuk

boywonder wrote:

I was speaking to a colleague in the UK who said the Nav payroll reseller use encryption, so it is possible & I want to buy a product for this...

Oh, yeah, i know them... Basically they compile everything on their DB, then remove a C/AL code by some tool, and then deploy a metadata using their custom-made tool. That all good, but starting from version 2013 the object metadata contain 3 new fields ("Metadata", where you got just XML definition of object, "User Code", where you got c# object definition and code of you object, and a "User AL Code" , where you got your C/AL code, used by debuger I believe). So their approach had worked with version 2009 r2, which had in metadata table only the c#, and it has been pretty weird to reverse it back to C/AL, but now, with 2013 you got everything at the plate

Anyway, obfuscation of a code is a certainly not a good way in NAV world, the proper way is to register your stuff with MS and get a range, which is not editable by other partners. But, from experience i may say, that all obfuscated code i ever seen never ever will pass MS requirements to register an add-on

mdPartnerNL

rdebath wrote:

The task is foreground, it appears to be a DotNET DLL (it starts up very slowly) and it runs as soon as you save an object before a prompt returns. It is run after the object is successfully saved and can die without any message (the C# code just isn't there) with a message or killing the client too.

When importing objects it's run during the "Processing Objects" phase. In V7 the "Tools->Build Server Application Objects" option will continue to create the C# code if the "Processing Objects" phase crashed or the object metadata (C# code) has been deleted.

If there is no visible "Processing Objects" phase then either you have "Enable for Microsoft Dynamics NAV Server" turned off (V6) or you are running the Native Client (V6) or the C# code stored in the FOB is acceptable to the client. Note: for early V6 clients 'acceptable' may not mean runnable. For V7 clients 'acceptable' appears to mean "exactly the same build number".

When the C# code needs to be run by the Service Tier, it will call the "csc.exe" program to convert the C# code into a DLL which is stored (temporarily) under the ProgramData tree on the server. Note: It is possible for these DLLs to be flagged as a virus by AV software, so, if installed, the AV software should be configured to exclude this directory.

The first phase (converting to C#) needs to dereference automation objects and DotNET variables to check the compile. This means that those DLLs MUST be installed on the client even if never run there. Only DLLs that are called to run server side need to be installed server side.

Beware the addition metadata in the 2013R2 database, stored in the "Object Metadata Snapshot" table makes removing tables from the "Object Metadata" table dangerous at best.

Before 2013R2 the "Development Environment" also handled the task of updating the SQL tables to match the Navision data dictionary (add and removing columns, indexes etc) With V7.1 this task has been handed over to the service tier. This means that for table changes you must have a service tier running and it must have access to the database to do this job.

This task is NOT done by the service tier in sync with the saving of the object; it is done when a client is started after saving the object. This BTW includes changing the collation of the database, with 2013R2 the database has to be put into single user mode to update the metadata but must be put back into multi-user mode to actually change the data.

The most recent hotfix rollup apparently has more changes in this area; I haven't looked yet though.

Wow thx for the info. If you find more info/links please add to this topic.

Miklos_Hollender

@ppavuk I think the idea is not really about making code not editable by others but not readable by others, as these businesses fear their ideas will be stolen, their add-ons will get a copy-paste competitor. You are right that this is neither possible nor legal (Microsoft forbids reverse engineering). The best idea is probably to put "secret" code into .NET assemblies - but then again shipping uncustomizable and undebuggable assemblies is not really a nice and not "navisionic" move as it ties the customer to one partner and they cannot provide fast support because they are overwhelmed or something then they are pretty much screwed.

But the desire understandable. This is basically similar to how NAV clients often want to prevent copy-pasting, because they are afraid an employee could steal their customer list.

The whole "culture of Navision" is basically a "high trust" culture and the real world is often not like that, that is the real issue. I remember how when I first started to work with Navision in 2002 they proudly showed me what a big advantage is that employees can find a lot of information in drill-downs and F9 stats, and I thought that most businesses I know think totally opposite - they want to hide information like margins from employees, so that they don't demand higher salaries, stuff like that...

kine

The difference is mainly based on history of each country. Most "western" countries are trusting people, because "why he would want to cheat me?". Most "eastern" countries are, based on history, not trusting, because it is "who is not robbing, robs his family" (common motto during communism). Of course, I am talking about Europe, but the groups "east" and "west" could be something else in other regions. It is just "trusting group" or "not trusting group".

Still, it is same like games copy protection. Companies throwing out big money on it but mostly what they save by copy protection is less than they put into it. Games without copy protections are more and more common... why? ;-)

Same for NAV partner - throwing out money on "code protection" is for me wasting, better to put them into making the product better to support/merge/extend.