Reverse Engineering RET Homepage RET Members Reverse Engineering Projects Reverse Engineering Papers Reversing Challenges Reverser Tools RET Re-Search Engine Reverse Engineering Forum Reverse Engineering Links

Go Back   Reverse Engineering Team Board > Reverse Engineering Board > .NET Reverse Engineering
FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Display Modes
  #21  
Old 04-21-2008, 08:47 AM
LibX LibX is offline
Administrator
 
Join Date: Feb 2007
Location: The Netherlands
Posts: 118
Default

Quote:
Originally Posted by Andu View Post
(maybe even open source and free )
<-- u mean so Mr. Mierzwiak can steal my code also, no thank u
Reply With Quote
  #22  
Old 04-21-2008, 08:52 AM
Andu Andu is offline
Member
 
Join Date: Apr 2008
Posts: 46
Default

lol

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
Reply With Quote
  #23  
Old 04-21-2008, 09:10 AM
bigmouse bigmouse is offline
Senior Member
 
Join Date: Sep 2007
Posts: 125
Default

Quote:
Originally Posted by Andu View Post
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.
Reply With Quote
  #24  
Old 04-21-2008, 09:46 AM
LibX LibX is offline
Administrator
 
Join Date: Feb 2007
Location: The Netherlands
Posts: 118
Default

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

http://download.yousendit.com/65788BB11A144456
Reply With Quote
  #25  
Old 04-21-2008, 12:41 PM
karlranseier karlranseier is offline
Member
 
Join Date: Apr 2008
Posts: 12
Default

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?)
Reply With Quote
  #26  
Old 04-21-2008, 01:06 PM
Andu Andu is offline
Member
 
Join Date: Apr 2008
Posts: 46
Default

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.
Reply With Quote
  #27  
Old 04-21-2008, 04:06 PM
rendari rendari is offline
Member
 
Join Date: Aug 2007
Posts: 39
Default

Huh? .Net Reactor is insecure by nature. Censoring any unpacking methods for it will do nothing to contribute to its security.
Reply With Quote
  #28  
Old 04-21-2008, 04:24 PM
karlranseier karlranseier is offline
Member
 
Join Date: Apr 2008
Posts: 12
Default

Quote:
Originally Posted by Andu View Post
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.
Reply With Quote
  #29  
Old 04-21-2008, 10:59 PM
bigmouse bigmouse is offline
Senior Member
 
Join Date: Sep 2007
Posts: 125
Default

Quote:
Originally Posted by karlranseier View Post
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.
Reply With Quote
  #30  
Old 04-22-2008, 05:17 AM
LibX LibX is offline
Administrator
 
Join Date: Feb 2007
Location: The Netherlands
Posts: 118
Default

Quote:
Originally Posted by bigmouse View Post
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
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump





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