Comments
2 comments
-
Hi there,
I think the answer to your first question is probably no, based on what you've said, but the easy way to check is to open those assemblies in .NET Reflector and see if you can decompile anything useful.
As to the second question, that's definitely a no, although I wouldn't rule it out as something we might support in future.
Hope that helps.
Thanks, -
Being able to load reflector into any process would probably allow even novices to easily circumvent many protection schemes, and would put Reflector into the same class of hacking tools that are primiarly for the purpose of defeating protection schemes, which means that there could be legal issues under DCMA.
Add comment
Please sign in to leave a comment.
My decryption scheme can also use stack introspection to find out who is calling it, as an additional security check. The managed part of the scheme also generates and loads a dynamic assembly at runtime (via Reflection.Emit), that contains the code that makes the call to the native C++ component that does the actual decryption, as an additional level of obsfucation.
So, the simple quesiton is, can Reflector Pro circumvent this scheme and reveal the source of the encrypted assemblies (which are decrypted in-memory and never written to disk in unencrypted form) and/or the dynamic assemby that I generate and execute at runtime?
Another somewhat related question, is whether Reflector Pro can be loaded into any running managed process via its API, and be used to examine the in-memory assemblies that are loaded into the process's AppDomain, including dynamic assemblies generated on the fly?