Problems in NR 4.3.1.0

[raven]

I really like the new option to embed pre-protected assemblies.

However, version 4.3.1.0 introduces two problems not existent in
4.2.7.5:

- When protecting my main assembly (exe), .Net Reactor crashes every
time, when it encrypts/converts code. The crash seems to be caused by
method pre-jitting and does not occur if I don't use method pre-
jitting. (No problem here with previous version). This problem also
occurs if I protect the main assembly solely (without satellite
assemblies).

- When I protect a dll which contains a web-service only and use the
Necro Bit option to protect this dll, I cannot access it from the main
assembly anymore. There is no error message, just 100 % CPU
consumption and nothing happens. Again, this problem did not in with
4.2.7.5.

Please let me know what you think, Denis.

Regards,

raven

[SdB]

You may also want to contact the support E-Mail. I got a response this
weekend, so hurry ;-)

[raven]

I found a kinda strange workaround for problem 1), the protection of
the main assembly.

It works by protecting another assembly. Here is how:

- start reactor.
- protect another project with: necro bit + exe file + pre jit
- directly after, without restarting reactor, protect the main
assembly (which former crashed when pre-jitting was enabled)

That works. Even with satellite assemblies.

Dennis, I hope that makes some sense to you and maybe enables you to
fix it.

Still found no workaround for problem 2) though, which seems very
'generic' to me and should be easily reproducable.

Regards,

raven

[Glen Harvy]

Please ensure that you have reported this via an email to support as
there is no guarantee that Dennis will ever read this otherwise.

[Denis]

Hi Raven,

In case you can provide me with your affected application I am sure I
can fix the Pre-JIT issue. Please send it to sup...@eziriz.com.
Normally the Pre-JIT feature should work more reliable in the latest
version.

Regarding the NecroBit issue with your webservice. Please try v4.3.1.1
as this version fixes a NecroBit related issue:
http://www.eziriz.com/downloads/dotnet_reactor_setup_latest.exe

In case the problem persist, does it at least work in "NecroBit/
Reflection Compatibility Mode"?

Greetings

Denis

[raven]

Hi Denis,
so good to have you here. Please stay this time ;)

As for the NecroBit issue: Unfortunately 4.3.1.1 did not fix it.
Compatibility mode showed no effect.

As for the pre-jit issue: I'm sorry, but I can't provide you with the
source code of the application. I hoped that you could make something
out of the info that it works without problems after I prejitted
another application: I thought of some initialization issue or
something like that. The Windows error message mentiones MSVCR90.dll,
don't know if that helps?

Regarding pre-jitting: would it be possible to pre-jit larger sections
of code (not only getters and setters) if one is willing to sacrifice
cross platform compatibility (if the program is designed only for
windows anyway) or is this impossible because of reflection?

There is another issue I don't know you are aware of: when using a web
service inside a program and protecting it with native exe file
option, running the web service code fails. It seems like .net is
trying to create a temp assembly when accessing the web service, which
doesn't work. My workaround is to put web serices outside the main
assembly in seperate dlls for this reason. (However, now there is the
necroBit issue...)

Can you please tell me if you made any progres with encrypted/
protected sections feature?

Regards,
raven

[Denis]

Raven,

in case you can provide me with a stack trace it could help.

Regarding pre-Jit. Yes, nearly the whole code could be prejitted but
a .NET runtime update could break the functionality suddenly.
Therefore only the forward compatible code is used. The prejitted code
is compatible with reflection. In case you dynamically invoke a
specific method via reflection the prejitted code is automatically
called as well.

Regarding the web service issue. This is not a bug as the service must
be a managed file on HDD. Therefore if you use the protection presets
for window services the Native EXE File option is not enabled as well.

>> Can you please tell me if you made any progres with encrypted/protected sections feature?

In case a method (which is going to be compiled) refers one of your
marked methods, the marked method would often get compiled as well,
even in case it is not actually called. This is the reason why I
haven't implemented it so far. As you probably remember we talked
about declarative protection in this regard as well. For testing
purposes it is already implemented in the unofficial IntelliLock
update (http://www.eziriz.com/downloads/
intellilock_setup_latest.exe).

Greetings

Denis

[raven]

Hi Denis,

> in case you can provide me with a stack trace it could help.

I would like to. However, debugging the crash leads directly into
native code and there is no stack trace as far as I can see. Error
message: "The Microsoft Visual C-Runtime Library has detected a fatal
error in dotNET_Reactor.exe".

> Regarding pre-Jit. Yes, nearly the whole code could be prejitted but
> a .NET runtime update could break the functionality suddenly.
> Therefore only the forward compatible code is used. The prejitted code
> is compatible with reflection. In case you dynamically invoke a
> specific method via reflection the prejitted code is automatically
> called as well.

Ok if such updates happen often, than it would be bad. Thanks for the
explanation.

> In case a method (which is going to be compiled) refers one of your
> marked methods, the marked method would often get compiled as well,
> even in case it is not actually called. This is the reason why I
> haven't implemented it so far.

Maybe you could create an empty clone of each protected method that
could be refered to by the framework as long as no decryption key
exists. And when the key is available, refer to and decrypt the real
method or something like that?

Regards,
raven

[raven]

>>When protecting my main assembly (exe), .Net Reactor crashes every
time, when it encrypts/converts code. The crash seems to be caused by
method pre-jitting and does not occur if I don't use method pre-
jitting. (No problem here with previous version). This problem also
occurs if I protect the main assembly solely (without satellite
assemblies). <<

Hi Denis,

if you could (inoficially) support declarative protection in .Net
Reactor, I may be able to track the problem down and can maybe even
provide an assembly that replicates the problem.

>>When I protect a dll which contains a web-service only and use the
Necro Bit option to protect this dll, I cannot access it from the main
assembly anymore. There is no error message, just 100 % CPU
consumption and nothing happens. Again, this problem did not in with
4.2.7.5. <<

Did you make any progress regarding the web service - necro bit issue?

Regards,
raven

[Denis]

Hi Raven,

Using declarative protection you would be able to find the affected
method but the problem persist. Without corresponding code (or other
helpful information) I can't fix this issue.

>> Did you make any progress regarding the web service - necro bit issue?

Do you mean web service - Native EXE File issue, right? As I already
tried to explain I can't fix this isssue as it is not a bug. The
native exe file is not compatible to services.

Greetings,

Denis

[raven]

Hi Denis,

> Using declarative protection you would be able to find the affected
> method but the problem persist. Without corresponding code (or other
> helpful information) I can't fix this issue.

Well, let's say I could exclude a class / method from being pre-jitted
and that would solve the problem (the 'right exclusion' should solve
the problem as it has something to do with my code, right?).

That would have to consequences:

1.) If you couldn't provide a fix (which I highly doubt), at least the
problem would be work-arounded for me at this point, which would be
nice :)

2.) If I know which class / classes / methods are responsible for the
crash, I might be able to create an assembly with the same behavior,
in consequence allowing you to fix the problem. Doesn't that sound
reasonable?

>Do you mean web service - Native EXE File issue, right?

The 'problem' you are referring to, is when a web service is inside an
exe and natively protected. I got that this is not a bug / problem
of .Net Ractor.

What I meant was protecting a dll that contains a web service (only),
which I call from the main program. If I protect this dll with necro
bit enabled and call it from the main program, there is just 100 % CPU
load and nothing happens (it works fine if I don't use necro bit,
compatibily mode changed nothing). Hope that makes some sense to
you :D

Regards,
raven

[Denis]

Ok, I will provide declarative protection for .NET Reactor. Of course
I want to find a solution to fix the issue in general as well.

Regarding the web service issue. Do you directly call classes of the
dll or do you use reflection related code?

Greetings,

Denis

[raven]

Hi Denis,

> Ok, I will provide declarative protection for .NET Reactor. Of course
> I want to find a solution to fix the issue in general as well.

Nice :)

> Regarding the web service issue. Do you directly call classes of the
> dll or do you use reflection related code?

I directly call clases. But in fact, the main process hangs as soon as
im initialising the 'web service dll'.

The 'web service dll' only contains a web reference.

Regards,
raven