Search:  
NamespacesDiscussions.NET v1.1Feedback
Managed EXE DLL Injection
Messages   Related Types
This message was discovered on microsoft.public.dotnet.framework.clr.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.
Post a new message to this list...

Nadav (VIP)
Hi,

I am writing some kind of an encryptor for.NET assemblies, This require me:
A. To encrypt the IL code ( done successfully )
B. To enable transparent means of decrypting the IL code on run-time in a
way that the encrypted DLL will stay independent.

Concerning the latter issue, to achieve custom functionality upon EXE
startup I am trying to inject a DLL to an existing PE image, this is done by
adding an additional DLL import dependency to the existing PE ( e.g. editing
the already existing PE sections ), to achieve what was just described I am
reconstructing the IMPORT, IAT and RELOC tables: adding custom DLL import
dependency ( in addition to mscoree.dll )… BUT it doesn’t seem to work, the
loader produce STATUS_INVALID_IMAGE_FORMAT (0xC000007B) error, when
reconstructing the tables only with a dependency for ‘mscoree.dll‘ everything
works fine, at the minute I add an additional DLL, the loader fails… doing
some research I have stumbled upon peverify.exe of the sscli, assuming the
loader do the same verification done by ‘peverifier.exe’ I have tried the
following things:
I have used peverify.exe on my injected EXE ( with a debugger attached ) I
got the same results: ‘[IL]: Error: Unverifiable PE Header/native stub.’,
when breaking with the debugger I get to the following line:
Peverifier.cpp:
// There should be only one entry in this table.
if (IMAGE_IMPORT_DESC_FIELD(pID[1], Characteristics) != 0)
{
Log("IMAGE_IMPORT_DESCRIPTOR[1] should be NULL\n");
return FALSE;
}
Peverifier.exe ‘verifies’ that there is no more then one file dependency,
SOoo… adding an additional import dependency causes it to report error
preventing addition of functionality this way… there are some other ‘strange’
verifications such as:
// Check if mscoree.dll is the import dll name.
static const CHAR s_szDllName[] = "mscoree.dll";
…
if (CompareStringAtRVA(VAL32(pID[0].Name),
(CHAR*)s_szDllName,
LENGTH_OF_DLL_NAME) == FALSE)
{
…
}
The imported DLL can be no other then ‘mscoree.dll’…
And there is much more… code segment is mixed with the AIT table: share a
common address in the PE that is being used for execution as-well as for
relocation… and there is even more…

Anyhow I am really desperate, I need my encrypted EXE to be independent and
this require me to add some unmanaged functionality to the existing managed
PE… any advice remark or some insight on the process I have described would
be appreciated…

Thanks in advance,
Nadav,
http://www.ddevel.com
Reply to this message...
 
    
Arne Janning
"Nadav" <Click here to reveal e-mail address> schrieb

Hi Nadav,

sorry I can't help you with solving your problem directly but this seems to
be one of the problems the guys at
http://discuss.develop.com are waiting for. If you don't get an answer in
this NG you might try asking the ADVANCED-DOTNET or DOTNET-CLR list.

Cheers

Arne Janning
Reply to this message...
 
    
Valery Pryamikov
Nadav,
This would not be an answer to your question, but rather it will be counter
question + some info. Do you know that academic research has shown that code
encryption is one of the most inefficient forms of code obfuscation? It
combines high cost with very low resilience. Christian Collberg and Chenxi
Wang are two most active obfuscation researchers, if you search for their
names on http://citeseer.ist.psu.edu/cis you can find plenty interesting
research matterial. Another thing is that even so general black-box code
obfuscation was prooven to be not possible (see Barak, Goldreich, Sahai),
however Amit Sahai has presented interesting work on EUROCRYPT 2004 (which
you can also find on citeseer) with prove that there are classes of
(relaxed) obfuscators that are possible (esp. when it concern to the complex
access control obfuscators).

-Valery.
http://www.harper.no/valery

"Nadav" <Click here to reveal e-mail address> wrote in message
news:Click here to reveal e-mail address...
[Original message clipped]
Reply to this message...
 
 




Ad
MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT
 
 Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com