• [^] # maintenant la personne ayant ecrit ce virus (a lire le todo

    Posté par . En réponse à la dépêche Virus multiplate-formes Linux et Windows. Évalué à 3.

    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;; ---------------------- ;;
    ;; * Win32.MetaPHOR v1B * ;;
    ;; ---------------------- ;;
    ;; ;;
    ;; Metamorphic Permutating High-Obfuscating Reassembler ;;
    ;; ;;
    ;; Coded by The Mental Driller/29A ;;
    ;; ;;
    ;; ;;
    ;; I proudly present my very first metamorphic virus (in its version 1.1). ;;
    ;; ;;
    ;; This virus is only code. No tables, no indirect jumps, etc. etc. It ;;
    ;; doesn't uses the stack to construct strings, executable code or data: ;;
    ;; what I do is a reservation of 3'5 Mb of data (more or less) with ;;
    ;; VirtualAlloc and then use the decryptor to copy the decrypted virus there ;;
    ;; (or unencrypted, since it has a probability of 1/16 of being unencrypted, ;;
    ;; so the decryptor in that cases is in fact a copy routine). The reserved ;;
    ;; memory is organized in sections (as if it were a PE) where I do all the ;;
    ;; operations. VirtualAlloc will be retrieved by the decryptor if it's not ;;
    ;; imported by the host, and the host must import GetModuleHandleA/W and ;;
    ;; GetProcAddress to be infected. This functions will be used by the virus ;;
    ;; to get the needed APIs. ;;
    ;; ;;
    ;; The type of metamorphism followed is what I call the "accordion model": ;;
    ;; disassembly/depermutation -> shrinking -> permutation -> expansion -> ;;
    ;; -> reassembly, so the code can be bigger or smaller than the previous ;;
    ;; generation. ;;
    ;; ;;
    ;; The metamorphism in this virus is complete: even the result of the ;;
    ;; shrinking can't be used for detection, because is different in every ;;
    ;; generation. That's the point where I introduce a new concept: dimensions ;;
    ;; in recoding (I mean, code that only get shrinked on two or more ;;
    ;; generations, but not in the immediate following; this would be the ;;
    ;; "third" dimension). This makes the disassembly to have always a different ;;
    ;; shape from generation to generation, but, when stabilized, never growing ;;
    ;; uncontrolablely. ;;
    ;; ;;
    ;; I have added a genetic algorithm in certain parts of the code to make it ;;
    ;; evolve to the best shape (the one that evades more detections, the action ;;
    ;; more stealthy, etc. etc.). It's a simple algorithm based on weights, so ;;
    ;; don't expect artificial intelligence :) (well, maybe in the future :P). ;;
    ;; ;;
    ;; I tried to comment the code as cleanly as possible, but well... :) ;;
    ;; ;;
    ;; If the code isn't optimized (in fact, it's NOT optimized), it's because: ;;
    ;; ;;
    ;; 1) It's more clear to see the code that the internal engine will deal ;;
    ;; with (for example, many times I use SUB ECX,1 instead of DEC ECX, ;;
    ;; although the disassembler can deal with both opcodes). ;;
    ;; 2) What's the point for optimizing the code when in next generation it ;;
    ;; will be completely unoptimized/garbled? :) ;;
    ;; 3) The obfuscation in next generations is bigger (MUCH bigger). ;;
    ;; ;;
    ;; ;;
    ;; General sheet of characteristics: ;;
    ;; ;;
    ;; Name of the virus.............: MetaPHOR v1.0 ;;
    ;; Author........................: The Mental Driller / 29A ;;
    ;; Size..........................: On 1st generation: 32828 bytes ;;
    ;; On next ones: variable, but not less ;;
    ;; than 64 Kb ;;
    ;; Targets.......................: Win32 PE EXEs, supporting three types ;;
    ;; of infection: mid-infection (when ;;
    ;; .reloc is present), at last section ;;
    ;; but using the padding space between ;;
    ;; sections to store the decrytor/mover, ;;
    ;; or all at last section. ;;
    ;; It infects EXEs with a 50% of prob. in ;;
    ;; current directory and going up the ;;
    ;; directory three by three levels. It ;;
    ;; also retrieves the drive strings on ;;
    ;; the system and makes the same if they ;;
    ;; are fixed or network drives. ;;
    ;; It uses EPO patching ExitProcess. ;;
    ;; Stealth action................: It doesn't enter in directories that ;;
    ;; begin with 'W' (avoiding the windows ;;
    ;; directory) and doesn't infect files ;;
    ;; with a 'V' in the name or beginning ;;
    ;; with the letters 'PA', 'F-', 'SC', ;;
    ;; 'DR' or 'NO'. ;;
    ;; Genetic algorithm in the selection of ;;
    ;; the infection methods, the creation of ;;
    ;; of the decryptor and some more things ;;
    ;; to make it more resistant or more ;;
    ;; difficult to detect due to "evolution".;;
    ;; Encrypted.....................: Sometimes not. ;;
    ;; Polymorphic...................: Yes ;;
    ;; Metamorphic...................: Yes ;;
    ;; Payloads......................: 1) A message box on 17h March, June, ;;
    ;; September and December with a ;;
    ;; metamorphic message :). ;;
    ;; 2) On 14h May and on hebrew systems it ;;
    ;; displays a messagebox with the text: ;;
    ;; "Free Palestine!" ;;
    ;; Anti-debugging................: Implicit ;;
    ;; Release history...............: ;;
    ;; v1.0: 11-02-2002 (I just finished commenting the source code ;;
    ;; and correcting the bugs I found doing that). ;;
    ;; v1.1: 14-02-2002 ;;
    ;; ;;
    ;; ;;
    ;; To do in next versions: ;;
    ;; ;;
    ;; 1) ELF infection: I only have to add APIs and call one or another ;;
    ;; depending on the operating system, and add the ELF infection algorithm. ;;
    ;; 2) Reassembly for different processors: IA64, Alpha, PowerPC, etc. I only ;;
    ;; have to code a new disassembler/reassembler, since for every internal ;;
    ;; operation I use a self-defined pseudo-assembler with its own opcodes. ;;
    ;; 3) Plug-in injector ;;
    ;; 4) More things (of course!! :). ;;
    ;; ;;
    ;; ;;