Do you already have marketing plans?
If so, in what price segment will be your solution and when will it be available (aprox.)?
also can be unpack by jithook.
i'll open a new thread for this test.
For the people who are interested here is a copy of the REZiriz unpacker sourcecode
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?)
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.
Huh? .Net Reactor is insecure by nature. Censoring any unpacking methods for it will do nothing to contribute to its security.
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.
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
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,
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
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
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
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 :)
|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.