Reverse Engineering Team Board

Reverse Engineering Team Board (http://www.reteam.org/board/index.php)
-   .NET Reverse Engineering (http://www.reteam.org/board/forumdisplay.php?f=28)
-   -   .NET Reactor discussion (http://www.reteam.org/board/showthread.php?t=801)

karlranseier 04-13-2008 01:15 PM

sounds good but what do you think about .net reactor? it seems to offer more protection techniques but costs less.

LibX 04-16-2008 04:37 AM

Quote:

Originally Posted by karlranseier (Post 6538)
sounds good but what do you think about .net reactor? it seems to offer more protection techniques but costs less.

.NET Reactor is fully build on stolen on GPL code (code u can't use in a closed source project) on top of that its the most crappy packer i have ever seen.

karlranseier 04-16-2008 06:09 AM

could you proof it?
i am interested in the protection technique. you could you post links the the source code .net reactor is based of?

Andu 04-16-2008 06:09 AM

Hello folks,

my question also regards .net Reactor. First I agree that the application mode protection is crap because it has been shown many times that it is possible to circumvent the protection in less than 5 minutes!

I have also seen a paper which seems to describe the basic principle, which .net Reactor seems to be based on (don't know if you refer to this paper with the gpl code, a link is very much appreciated).

But the Reactor offers two protection modes: application (which is easy to crack) and library mode, which I'm not shure off.

As I haven't seen any crackmes regarding library-mode-protected assemblies or tutorials on that topic my question is if anyone has tried to break this protection with activated necro bit. It seems to be tougher at first glance.
And a second thing: .net Reactor also offers a strong name removal protection. What do the experts think about this?

Regards,

Andu

LibX 04-16-2008 06:47 AM

Quote:

Originally Posted by karlranseier (Post 6608)
could you proof it?
i am interested in the protection technique. you could you post links the the source code .net reactor is based of?

Its using code from Mono.Cecil, old versions uses code from first releases of .NET Reflector, it has a copy of the hurricane cipher in it also opensource (its a delphi unit), also QuickLZ is used and more .

LibX 04-16-2008 06:47 AM

Quote:

Originally Posted by Andu (Post 6609)
Hello folks,

my question also regards .net Reactor. First I agree that the application mode protection is crap because it has been shown many times that it is possible to circumvent the protection in less than 5 minutes!

I have also seen a paper which seems to describe the basic principle, which .net Reactor seems to be based on (don't know if you refer to this paper with the gpl code, a link is very much appreciated).

But the Reactor offers two protection modes: application (which is easy to crack) and library mode, which I'm not shure off.

As I haven't seen any crackmes regarding library-mode-protected assemblies or tutorials on that topic my question is if anyone has tried to break this protection with activated necro bit. It seems to be tougher at first glance.
And a second thing: .net Reactor also offers a strong name removal protection. What do the experts think about this?

Regards,

Andu

About the strong name protection i managed to remove it once, after that i lost interest in reversing since its more of the same every time with just minor changes

Andu 04-16-2008 06:53 AM

Thanks for your answers. What's about library mode contra the weak application mode?

LibX 04-16-2008 06:56 AM

Quote:

Originally Posted by Andu (Post 6613)
Thanks for your answers. What's about library mode contra the weak application mode?

Its just as crappy ;) specialy the so called necrobits protection is the biggest joke of all

Andu 04-16-2008 06:59 AM

Could you please expand on this? Is there a tutorial available?

What's the point with necroBit after all? How does it help to protect the assembly?

LibX 04-16-2008 07:09 AM

Quote:

Originally Posted by Andu (Post 6615)
Could you please expand on this? Is there a tutorial available?

What's the point with necroBit after all? How does it help to protect the assembly?

I don't have time to write any tutorial sorry i hardly have some free time left for myself

and about the necrobits they restore function pointer at runtime, so basicly it doesn't help at all
its just a decoy

Andu 04-16-2008 07:16 AM

Thanks LibX!

One last question: What do you think is the best or most advanced protector or protection method for .net assemblies?

LibX 04-16-2008 07:27 AM

Quote:

Originally Posted by Andu (Post 6618)
Thanks LibX!

One last question: What do you think is the best or most advanced protector or protection method for .net assemblies?

For regular protection: Just use a obfuscator, sure it won't help against cracking but nothing will realy ;) if u want it cracked u can do it at least they don't have ur source code then my favorite over all is smartassembly, its fast and i never had a single protected output that was not working (would be nice though if it was a little more tunable)

And for hardcore protection: I think the method iam working on is pretty good but far from finished, its based on dynamic encrypted code with a source level implementation with a mixture of native code (still fully non unsafe compilation) and debugger protection, but its far from finished, and ofcource a fully custom VM to run code in is the perfect sollution but there are no fully working implementations of that yet.
Also i think SecureLM from microsoft is pretty good but also its not doing everything that they promise, iam sure i can get the original code back (no iam not going to publish details since i don't want a witch hunt ;p)

Regards
LibX

Kurapica 04-17-2008 07:00 PM

Quote:

Originally Posted by karlranseier (Post 6673)
What tool do you guys use for dumping and assembly from memory to harddisk?
and how can i view the obfuscated sourcecode of .net reactor protected assemblies? when i open it with lutz roeders .net reflector, i get exception from roeders reflector.

thanks

You can find a nice tutor on .NET Reactor in rongchaua site or follow this link

http://rongchaua.net/content/view/109/30/

karlranseier 04-18-2008 08:30 AM

Quote:

Originally Posted by Kurapica (Post 6674)
You can find a nice tutor on .NET Reactor in rongchaua site or follow this link

http://rongchaua.net/content/view/109/30/

these articles are vietnamese. do you have any other information?

rongchaua 04-18-2008 08:41 AM

@karlranseier:
Here is the link. They are written in English. Please register, login to view the article. I have problem with Google so I must private all links.
http://rongchaua.net/tip/how-to-unpa...actor-3.6.html

Andu 04-21-2008 07:12 AM

A question for the pros:

Are there any plans on writing a .net Reactor deprotector especially for library mode?
I'll not believe it's defeated before there is a deprotector or tutorial for library mode ;)

Regards,

Andu

LibX 04-21-2008 08:02 AM

Quote:

Originally Posted by Andu (Post 6770)
A question for the pros:

Are there any plans on writing a .net Reactor deprotector especially for library mode?
I'll not believe it's defeated before there is a deprotector or tutorial for library mode ;)

Regards,

Andu

Yes and when people are done writing this u can send the result to:

S********* 35
S*******, D-00000, DE
phone: +00 000000000

Andu 04-21-2008 08:10 AM

Ok, seems I have to look for something else ;)

LibX 04-21-2008 08:19 AM

Quote:

Originally Posted by Andu (Post 6772)
Ok, seems I have to look for something else ;)

Not funny if someon is posting ur home address isn't it Denis Mierzwiak? ;)

(for the people who just missed the point Andu is the developer of .NET Reactor)

Andu 04-21-2008 08:40 AM

No, I'm not :D

I'm just a concerned developer who wants to protect his property as good as possible and evaluating my options.

I whish however that Mr. Mierzwiak is reading this and makes his protection better.

Or that you write the mega Protector (maybe even open source and free ;) ).

(Don't know what makes you think that I'm the developer. Please read my posts again and you'll see that I'm fair and neutral (well, at least I tried to be).

Regards,

Andu

LibX 04-21-2008 08:47 AM

Quote:

Originally Posted by Andu (Post 6774)
(maybe even open source and free ;) )

<-- u mean so Mr. Mierzwiak can steal my code also, no thank u

Andu 04-21-2008 08:52 AM

lol :D

Do you already have marketing plans?
If so, in what price segment will be your solution and when will it be available (aprox.)?

Regards,

Andu

bigmouse 04-21-2008 09:10 AM

Quote:

Originally Posted by Andu (Post 6770)
A question for the pros:

Are there any plans on writing a .net Reactor deprotector especially for library mode?
I'll not believe it's defeated before there is a deprotector or tutorial for library mode ;)

Regards,

Andu

it can be unpack by reflection.
also can be unpack by jithook.

i'll open a new thread for this test.

LibX 04-21-2008 09:46 AM

For the people who are interested here is a copy of the REZiriz unpacker sourcecode

http://download.yousendit.com/65788BB11A144456

karlranseier 04-21-2008 12:41 PM

i guess releasing it as open source would endanger the security of this protector.
it would be cool if you release it for a low price or for free (maybe for members of this forum?)

Andu 04-21-2008 01:06 PM

It depends. If the solution is really secure it could be released as open source like cryptographical algorithms. But in the case of .net Protectors I think that closed source is better, too.

rendari 04-21-2008 04:06 PM

Huh? .Net Reactor is insecure by nature. Censoring any unpacking methods for it will do nothing to contribute to its security.

karlranseier 04-21-2008 04:24 PM

Quote:

Originally Posted by Andu (Post 6788)
It depends. If the solution is really secure it could be released as open source like cryptographical algorithms. But in the case of .net Protectors I think that closed source is better, too.

you can use aproved algorithms like AES but you still have to hide the key somewhere. and once the key is entered (by user or the program uses the hidden key itself) the whole assembly lies unprotected in memory.

i don't know a single exe protector (native or .net) which has not been broken.

i don't know if it is realistic but i think the only secure way to protect source code is a new layer of the operating system which encrypts the whole RAM with a unique key that is generated at the installation of the OS. only the programs which stores data in ram (and maybe also system processes) can read their own data.

bigmouse 04-21-2008 10:59 PM

Quote:

Originally Posted by karlranseier (Post 6792)
you can use aproved algorithms like AES but you still have to hide the key somewhere. and once the key is entered (by user or the program uses the hidden key itself) the whole assembly lies unprotected in memory.

i don't know a single exe protector (native or .net) which has not been broken.

i don't know if it is realistic but i think the only secure way to protect source code is a new layer of the operating system which encrypts the whole RAM with a unique key that is generated at the installation of the OS. only the programs which stores data in ram (and maybe also system processes) can read their own data.

as libx's protector implement at MSIL level, the runtime's

source code is still available to reversers.
there must be at least one unprotected method, which is needed

to decrypt and execute the first encrypted method.
so reversers can start with this method, step into...
after all runtime's method been decrypted, the protector is

defeated.

but at least, It would slow them down.

a better way ,is use a native layer to implement per method

protection. such as remotesoft protector, clisecure, maxtocode,

dnguard.

but remotesoft protector and clisecure only implement a simple

jit wrap, can be easily unpack by using jithook.
also clisecure not really encrypted the ilcode, so static unpack

is very possible.

maxtocode not only wraped jit, but also hooked into mscorwks.
but no matter for jithook.
the problem is it's runtime protected by themida, we must bypass

themida's anti.
maxtocode itself also implement anti-hook(especial for jithook),

so simple jithook would't work.
bypass it's anti , we can also unpack this by using jithook.
by reason of all it's antis, Re-Max 3.34 can't work on virtual

.net framework environment yet.

DNGuard seems to does better, it's not only a simple jit wrap,

but also implement some functions of jitter.
by using jithook, i can't get back full methoddata.
it's runtime eat part of methoddata,and process this part data

itself, never passed to original jitter.

i think it must be possible to get back this part data by hook

into it's runtime. how to hook and where to hook is another

subject, i'v no idea yet.

i never got any hvm protected samples, i'm not sure about HVM

Technology.
i guess it maybe implement more functions of jitter.

The biggest problem for those protectors is compatibility.
but for obfucators or protector like libx's,compatibility is

little problem.

LibX 04-22-2008 05:17 AM

Quote:

Originally Posted by bigmouse (Post 6796)
as libx's protector implement at MSIL level, the runtime's

source code is still available to reversers.
there must be at least one unprotected method, which is needed

to decrypt and execute the first encrypted method.
so reversers can start with this method, step into...
after all runtime's method been decrypted, the protector is

defeated.

but at least, It would slow them down.

a better way ,is use a native layer to implement per method

protection. such as remotesoft protector, clisecure, maxtocode,

dnguard.

but remotesoft protector and clisecure only implement a simple

jit wrap, can be easily unpack by using jithook.
also clisecure not really encrypted the ilcode, so static unpack

is very possible.

maxtocode not only wraped jit, but also hooked into mscorwks.
but no matter for jithook.
the problem is it's runtime protected by themida, we must bypass

themida's anti.
maxtocode itself also implement anti-hook(especial for jithook),

so simple jithook would't work.
bypass it's anti , we can also unpack this by using jithook.
by reason of all it's antis, Re-Max 3.34 can't work on virtual

.net framework environment yet.

DNGuard seems to does better, it's not only a simple jit wrap,

but also implement some functions of jitter.
by using jithook, i can't get back full methoddata.
it's runtime eat part of methoddata,and process this part data

itself, never passed to original jitter.

i think it must be possible to get back this part data by hook

into it's runtime. how to hook and where to hook is another

subject, i'v no idea yet.

i never got any hvm protected samples, i'm not sure about HVM

Technology.
i guess it maybe implement more functions of jitter.

The biggest problem for those protectors is compatibility.
but for obfucators or protector like libx's,compatibility is

little problem.

Well basicly its not the biggest problem that u can get code back, as long as ur licensing system implementation combined with the protector is good it will be a insane job to crackit (i will post a crackme that needs patching later on ;))
DNGuard has been worked on for 2 years or more, my protector only 1 week its insane to put so much time into simple code protection when its easy to just patch a protected app afterwards.
my code protector isn't that good since its easy to use in memory reflection, but still it took u guys 3-4 days to come up with the solution and thats far longer than it would take to reverse obfuscated code

But thats just my optnion :)

regards
LibX

bigmouse 04-22-2008 08:17 AM

Quote:

Originally Posted by LibX (Post 6801)
Well basicly its not the biggest problem that u can get code back, as long as ur licensing system implementation combined with the protector is good it will be a insane job to crackit (i will post a crackme that needs patching later on ;))
DNGuard has been worked on for 2 years or more, my protector only 1 week its insane to put so much time into simple code protection when its easy to just patch a protected app afterwards.
my code protector isn't that good since its easy to use in memory reflection, but still it took u guys 3-4 days to come up with the solution and thats far longer than it would take to reverse obfuscated code

But thats just my optnion :)

regards
LibX

yes, your protector is better than obfucator, but also obfucation is necessary. without obfuscate, your protector can be easily reversed.

after i got your sample run on a xp machine, i spend several hours to get code back, it's much more hard than obfuscation.

waiting for your new crackme.

regards

Andu 04-22-2008 11:32 AM

Hi bigmouse,

interesting analysis of current protectors. Thank you.

At the moment I'm trying out Themida respectively WinLicense and it seems running nicely. However, do you (or other members of this forum) know something about the protection strength of this packer or its weaknesses?
I'm especially interested if it does something to the .net code so that the original code is not reproducable. There seems to be no obfuscation in place, which could prevent this.

Any information on this protection and its strength is highly appreciated.

Regards,

Andu

LibX 04-22-2008 11:38 AM

Quote:

Originally Posted by Andu (Post 6811)
Hi bigmouse,

interesting analysis of current protectors. Thank you.

At the moment I'm trying out Themida respectively WinLicense and it seems running nicely. However, do you (or other members of this forum) know something about the protection strength of this packer or its weaknesses?
I'm especially interested if it does something to the .net code so that the original code is not reproducable. There seems to be no obfuscation in place, which could prevent this.

Any information on this protection and its strength is highly appreciated.

Regards,

Andu

The runtime is protected with Themida, not the il code

bigmouse 04-22-2008 11:48 AM

Quote:

Originally Posted by Andu (Post 6811)
Hi bigmouse,

interesting analysis of current protectors. Thank you.

At the moment I'm trying out Themida respectively WinLicense and it seems running nicely. However, do you (or other members of this forum) know something about the protection strength of this packer or its weaknesses?
I'm especially interested if it does something to the .net code so that the original code is not reproducable. There seems to be no obfuscation in place, which could prevent this.

Any information on this protection and its strength is highly appreciated.

Regards,

Andu

themida/winlicense support .Net assemblies, but it use whole assembly encrypte protection.
so you know.......

but also like reactor's library mode.
it's wiped some peheader value.

Andu 04-22-2008 11:59 AM

So it is as bad as .net Reactor or did I get something wrong...?

bigmouse 04-22-2008 12:50 PM

Quote:

Originally Posted by Andu (Post 6815)
So it is as bad as .net Reactor or did I get something wrong...?

i'm not sure, maybe i remember something wrong.
at least, assemblies can be rebuild by using reflection.

LibX 04-22-2008 01:16 PM

Quote:

Originally Posted by bigmouse (Post 6813)
themida/winlicense support .Net assemblies, but it use whole assembly encrypte protection.
so you know.......

but also like reactor's library mode.
it's wiped some peheader value.

My own generic .net unpacker dumps it just fine, .net protection from themida/winlicense sucks bigtime

LibX 04-22-2008 01:18 PM

Quote:

Originally Posted by bigmouse (Post 6805)
yes, your protector is better than obfucator, but also obfucation is necessary. without obfuscate, your protector can be easily reversed.

after i got your sample run on a xp machine, i spend several hours to get code back, it's much more hard than obfuscation.

waiting for your new crackme.

regards

Final version will have build in control flow obfuscation also :)

karlranseier 04-22-2008 03:31 PM

Quote:

Originally Posted by LibX (Post 6819)
Final version will have build in control flow obfuscation also :)

any plans about pricing or a free version yet?

LibX 04-22-2008 06:16 PM

Quote:

Originally Posted by karlranseier (Post 6820)
any plans about pricing or a free version yet?

Iam not going to awnser any questions about this sorry, when its done its done, if its free its free


All times are GMT -4. The time now is 10:07 AM.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.