View previous topic :: View next topic |
Author |
Message |
absvm
Joined: 14 Dec 2017 Posts: 8
|
Posted: Mon Jan 01, 2018 12:35 pm Post subject: C# scripting (Microsoft.CodeAnalysis.Scripting) prob |
|
|
Hi,
I have an application that uses C# scripting (Roslyn, Microsoft.CodeAnalysis).
When using C# scripting with a host class together with NetEncryptor, the program will terminate with an error pointing out that the methods and members in the host class are not existing in the current context.
In the case of this example, the host class has a public function Square(), the calling of which in a script produces the following error:
Code: | error CS7012: The name 'Square' does not exist in the current context (are you missing a reference to assembly 'TestScriptingApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=94fdfcf678734431'?)" |
The use of a host class with Scripting is explained here:
https://blogs.msdn.microsoft.com/cdndevs/2015/12/01/adding-c-scripting-to-your-development-arsenal-part-1/
I made a small test solution (VS2017, .NET 4.6.1) to reproduce the problem:
https://github.com/absvm/NetEncryptorWithRoslyn.git
The example in this repository is based on the BootstrapAnyCPU sample project and the scripting test app is based on the code from the blog above.
In the same blog I read that Roslyn creates so called 'submissions' of the code - no doubt that this mechanism somehow interferes with the NetEncryptor inner mechanisms.
I would appreciate some help with this as the scripting is an essential part of the code that I want to secure.
best regards |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Wed Jan 03, 2018 11:10 am Post subject: |
|
|
Have you tried setting the INTEGRITY_LEVEL (passed to CheckProcessIntegrity) to 0. The anti-hooking code may possibly be interfering with the Scripting.
Another possibility is that the scripting engine may be relying on the entry executable containing the host class - but in this case the entry executable is the Bootstrap. If you can put together a small self contained project that demonstrates your problem and email it to support@infralution.com then we'd be happy to take a look and see if there is some way to work around this. _________________ Infralution Support |
|
Back to top |
|
|
absvm
Joined: 14 Dec 2017 Posts: 8
|
Posted: Thu Jan 04, 2018 10:16 am Post subject: |
|
|
I tried setting INTEGRITY_LEVEL to 0 but same result.
I have a self contained example project that demonstrates the problem here ready for download:
https://github.com/absvm/NetEncryptorWithRoslyn.git
It's a bit too big for emailing with all the CodeAnalysis packages and dependencies so it would be good if you guys could pick it up from GitHub.
Curious to know if this can be resolved somehow.
rgds |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Thu Jan 04, 2018 10:23 pm Post subject: |
|
|
Thanks - we will take a look and see if we can find a solution. _________________ Infralution Support |
|
Back to top |
|
|
Infralution
Joined: 28 Feb 2005 Posts: 5027
|
Posted: Thu Jan 04, 2018 11:33 pm Post subject: |
|
|
I found the following issue raised against Roslyn:
https://github.com/dotnet/roslyn/issues/6101
This seems to indicate that Roslyn can't use assemblies loaded from memory for the script host - which is the mechanism .NET Encryptor uses for loading assemblies.
I was able to get it to work by putting the ScriptHost class in a separate class library which is not encrypted (ie loaded from file) You have to make sure that the DLL containing the ScriptHost class (and all of the other CodeAnalysis DLLs) are copied into the bin directory for the Bootstrap project (since it doesn't reference these directly).
I don't know if doing the above is an option for you. _________________ Infralution Support |
|
Back to top |
|
|
absvm
Joined: 14 Dec 2017 Posts: 8
|
Posted: Sat Jan 06, 2018 2:26 pm Post subject: |
|
|
HI,
Good finding, that clears it up. I'll have to wait for the issue to fixed in Roslyn.
Yes, putting the host class in a separate not-encrypted dll is an option and since it's the only one I guess I'll use that. It's a potential vulnerability so I will keep my eyes open for a solution from the Roslyn side.
Thanks a lot for investigating. |
|
Back to top |
|
|
|