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)

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


All times are GMT -4. The time now is 11:06 AM.

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