.Net Reactor Unpacker, (for library mode only)

[Andu]

I think we talk at cross purposes.

It is not my intention to offend or bitch someone at this board. If that should have happened then I'm sorry.

but what if a simple patch is still killing your licensing system in just 5 mins?

Let's say there would be a packer that hasn't been cracked then this should not be possible in my understanding (which may be wrong!).

My question to you is: What do you mean by a good security system if sourcecode is open and changeable (patchable)? It makes no sense for me to have any security system inside OS code and I think that you mean that I shall code my own packer/protector or something like this. Is that right?

I really hope you are going to understand what i mean

I think what you mean is
a) there is no real protection
b) I shall code my own security system

What's unclear for me: How does a security system you are talking about looks like?

I hope I got you right this time and once again: I'm here to learn and not to argue.

Thank you!

[LibX]

Originally Posted by Andu

It is not my intention to offend or bitch someone at this board. If that should have happened then I'm sorry.

No u didn't iam just stunned by the way your looking at application security

Originally Posted by Andu

Let's say there would be a packer that hasn't been cracked then this should not be possible in my understanding (which may be wrong!).

Well in this case you are wrong, since u don't need to break a packer to make a patch or a memory load, its even easier then breaking the packer itself i hope u understand that now

Originally Posted by Andu

My question to you is: What do you mean by a good security system if sourcecode is open and changeable (patchable)? It makes no sense for me to have any security system inside OS code and I think that you mean that I shall code my own packer/protector or something like this. Is that right?

Golden rule: U can ALWAYS modifiy the code no meter what packer or protector u use u can always make a normal or a inline patch or a memory loader (modifies the application in memory for example to make the good guy/bad guy jump)

The only possible protection is obfuscation, this doesn't prevent modifying the code its only to prevent people from being able to easily decompile and use your code, this same applies for packers/protectors.

Your task is to code a licensing system that once its obfuscated is hard to analyze, another possibility is to only provide people with a down loadable DEMO copy accept of a trial and provide a retail (Full and also with a good licensing system) when someone buys your software.
Another possibility is buying a commercial licensing system, but again u should extend this with self made checks or code otherwise is far to easy to analyze.

And this licensing system should make use of public key encryption (RSA-1024 or ECC crypto for example) otherwise u basically provide the cracker with the encryption key needed to keygen the software.

I hope this helps you understand the situation
There is really no need in putting so much time in picking a obfuscator or a protecor

Regards
LibX

[Andu]

Thanks LibX,

I think I see clear now. Using an asymmetric licensing system and having muliple checks is out of question. The missing piece is just how I protect the protection system. And there are only two choices: a protector or an obfuscator (or something that does both). However, the protection strength of these tools is obviously different and so I think it's not bad to ask which one does a good job and that's my aim here.

Thanks for all your help and patience (I think this won't be my final post although it may sound like that )

And on one thing I have to insist: I'm definitly not wasting my time here

Regards,

Andu

[LibX]

Originally Posted by Andu

However, the protection strength of these tools is obviously different and so I think it's not bad to ask which one does a good job and that's my aim here.

Well since iam a commercial .NET developer myself i can tell u what i use myself:
Smartassembly, cheap, easy to use, no shit i dont need anyway or can get for free (like a decompiler) and the obfuscation is simply perfect never had a exe/dll that didn't run after protection.

Regards
LibX

[karlranseier]

the same thing i can say about .net reactor in library mode. never had problems with it. the application mode sometimes requires adaptions on you project.

is the library-mode protection weaker than the smartassembly protection?

.net reactor is much cheapter than smartassembly. so why do you use smartassembly over .net reactor?

is it you natural aversion against the developer cause .net reactor contains stolen code?

[LibX]

Originally Posted by karlranseier

is it you natural aversion against the developer cause .net reactor contains stolen code?

Well didnt even think of that but yes that would make a point also, not that i would take something else just becouse if this.

But smartassembly is the most compatible obfuscator i know, i NEVER had a single assembly that didn't work after obfuscation.

Also the 'protection' applied by .net reactor slows down the application also since its using overrated protection methods like the necrobits for example there is realy no need for such protections since they are easy enough to simply remove leaving the code decompilable again.

And if u google a bit u will find articals about .net reactor written by developers also, and again they have no good word for this protection. (don't ask me where but i read 3 of them about a year ago)

Regards
LibX

[rongchaua]

Hi LibX,
if it is not big secret, would you please to explain briefly how you know the way .Net Reactor merges the assemblies. I saw the source code which you posted. But until now I can not understand how you know that you should go that way to extract the assemblies to seperate files.

[LibX]

Originally Posted by rongchaua

Hi LibX,
if it is not big secret, would you please to explain briefly how you know the way .Net Reactor merges the assemblies. I saw the source code which you posted. But until now I can not understand how you know that you should go that way to extract the assemblies to seperate files.

Well iam parsing the first extractable file in the archive and check if its the crypto dll eziriz normaly uses in multi file packages, if its that files il continue extracting the config file and then parse that to find all file offsets

[karlranseier]

there is a new beta of .net reactor available. the changelog says that the library protection core has changed. anyone tested unpacking yet?

[bigmouse]

Originally Posted by karlranseier

there is a new beta of .net reactor available. the changelog says that the library protection core has changed. anyone tested unpacking yet?

only Obfuscation changed.