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

Thread Tools Display Modes
Old 06-01-2010, 01:00 PM
kao kao is offline
Senior Member
Join Date: Sep 2007
Posts: 184

You guys have been busy! Sorry, I had to take a week off..

@bigmouse: LocalVarSigTok is index into StandAloneSig table. StandAloneSig table contains index into the Blob heap. Blob heap contains LocalVarSig.
DNGuard internally does not use LocalVarSigTok or StandAloneSig table from the protected assembly. For each procedure it stores encrypted offset of correct LocalVarSig in Blob heap. When needed, it decrypts index, allocates memory and copies correct LocalVarSig from Blob heap into allocated memory. This new copy of LocalVarSig is passed to JIT.
Advanced JIT hooker could use LocalVarSig passed to JIT and write new StandAloneSig tables and blob heap. It's not fun project but certainly doable.

@jacky: DNGuard 3.5 increased the level of obfuscation inside hvmruntm.dll, a desperate (and failed) attempt to stop analysis of their engine. They also changed some internal structures, but overall - protection is still crap.
Reply With Quote
Old 06-02-2010, 01:55 AM
jacky jacky is offline
Join Date: Sep 2007
Posts: 12

thanks kao. it seems at least they improved the ecryption of "High performance encryption method". but true, this ecryption method must be simple.
no one can stop others to analyse their app, they can only make it more time consuming.
Reply With Quote
Old 06-05-2010, 01:47 PM
bigmouse bigmouse is offline
Senior Member
Join Date: Sep 2007
Posts: 125

@kao: thanks, i'v noticed this yet and doing it.
now, i'm going to update my maxtocode unpacker.

@jacky: no doubt that they improved ecryption and added more Algorithms. that's very easy to do.

no fun in playing with their ecrytion, the only result was waste our time and help them to make their ecrytion more time consuming.
i prefer JIT hooking technology, the jit protection was more hard to change.
eg maxtocode, they used some Algorithms and their runtime was protected by themida, but their jit protection was broken. they update and changed protection many times, my original unpacker(based on the custom patched framework) still work on their new version. seems to they only able to add some special antis against the public unpacker.
interest in .NET Reverse Engineering.

.Net Assembly Rebuilder - a tool to rebuild dumped assemblies.
Re-Max - a tool to unpack maxtocode protected assemblies.
Reply With Quote
Old 03-19-2011, 02:24 PM
anyi anyi is offline
Junior Member
Join Date: Mar 2011
Posts: 1
Default then could you suggest any .Net protector which is not a crap

Hi, Guys,

I have read all these posts, and was planning to use DNGuard to protect my .net application. But now I lose confidence in DNGuard.

Could any one of you, please suggest any .Net protector which is not a crap? I am looking forward to your suggestion and thank you in advance.

Reply With Quote
Old 03-27-2011, 04:15 PM
Poma Poma is offline
Junior Member
Join Date: Apr 2010
Posts: 1

All protections are crap. I don't know much about reverse engineering but it seems that it's much easier to break protection than to build it. Anyway, there's no unbreakable generic protection. If your app is good than there will be crack to it on the internet. So just don't spend much time protecting your app; spend it to develop new features and to support customers, make better marketing.

For my own software I use DNGuard (any jit-hook protector works fine enough) but scrambled a bit. Also I've renamed all strings wich contain 'dnguard', 'zuxuan' etc. So kiddies that use third-party generic unpackers can't detect what protection it is and therefore can't use their scripts. Experienced crackers will still easily break this protection, but they always can no matter what I do to stop them

Also it's always good to obfuscate your code using for example Smartassembly. So once cracker obtained IL code he can't use reflector do decompile it to easy-readable C# and has to read MSIL.
Reply With Quote

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.