Question about legacy RATs for Windows OS

[frog]

So most of the old RATs for Windows(namely sub7, bo2k, beast) have the ability to build their own executable with custom features. I have speculated about this endlessly(how it works I mean), and the best thing I can come up with is that the application is building a portable executable(PE) binary from scratch, bit by bit using specific data structures that conform to the PE format.

The problem: how do you build a binary when you still need compiled code objects to put in the binary? How do you compile them? Putting inline assembly in the original C code? Anybody familiar with the compilation process of a C/assembly program knows what I'm talking about.

How is a running executable able to build another one with arbitrary functionality?

I'm lost as to how this is actually being achieved, and it might be more simple that I think. Anybody have some USEFUL insight?

[frog]

Pretty good example of making a builder:


http://www.xylibox.com/2013/01/how-to-hex-malware-and-make-builder.html


Honestly it's not hard, you create the standard malware binary and then patch it in-line to add/remove whatever features you want.

Ok I see the original program is loaded in a debugger and using a push instruction right before the call to the messagebox, we are pushing what onto the stack? nullbytes?


I've read over the vb/asm program and in the Patch function you come to the point where the bytes are written to the offset as follows:

Code: (asm) [Select]

invoke WriteFile, hTarget, addr WBuffer, 64, addr
This is what is being written:

Code: (asm) [Select]

WBuffer        db  256 dup(00)256 nullbytes, which is puzzling..


What exactly is being patched at 0x403043? I'm confused. I understand the objective(to change the message in the msg box) but I don't see the path from point A to B.

[Ming]

is easier when your builder and your malware have the same structure and builder saves the structure filled with data  in the end of the malware and the malware read end of itself

[frog]

I want to see example in code, with a good explanation. This example in the link is poor as it contradicts itself and was written by somebody who speaks English as a second language.

The author summarizes  that he will be putting his text in an EXISTing section of nullbytes, not adding nullbytes. Then the code example adds nullbytes and leaves no explanation why this was done. Fuck.

Did you read the example?

I will undoubtedly offend somebody because I'm paying extreme attention to details. When the details are inconsistent, I lose trust in the source material.

In the example the executable is never being run, the patching program(a seperate entity) reads and writes to the original file. Run-time(on-the-fly) patching implies that instructions are being executed, and that asm opcodes are being changed on-the-fly. In the linked example a file is being modified so that when it is run(eventually) you will see the code changes. This is not the same thing as run-time patching.

See where I'm going with this? I know there's more than one way to skin a cat, but I'm frustrated by the inconsistency of what is linked, and what is being said.

[vezzy]

Most of the time it's actually far more obvious than you think.

Example: https://programmers.stackexchange.com/questions/221093/how-does-customized-executable-generation-work

[frog]

Most of the time it's actually far more obvious than you think.

Example: https://programmers.stackexchange.com/questions/221093/how-does-customized-executable-generation-work

I know, that's the fun part of hacking; realizing what you were looking for was in your face the whole time.

That's a good example vezzy, assuming you're working with the source code making substitions of text before compilation. Very basic.

What if I wanted to include the binary generation as a feature in an already compiled .exe? Something that would generate a binary with arbitrary variables/settings and then save to a separate file. Assume that I wanted to generate a binary from scratch as a function of the original binary(a user-friendly server-program generator). So I say I want these features/that features and then it assembles into a separate executable.

[frog]

As long as you include the functionality into the compiled executable that you build from your initial builder it shouldn't matter

That still doesn't answer my question. How would one program the executable to build the binary? I'm looking for specific information regarding functions and system calls.

The objective is to get a program to build another one with arbitrary functionality. Straight and narrow.

How would you make a program that builds another binary?

[Deque]

How would you make a program that builds another binary?

That's what (almost) every compiler does. Just look how compilers do it?
Or use a compiler in your program?
Modifying high level language code snippets and subsequently compiling them, shouldn't be a problem.

[frog]

That's what (almost) every compiler does. Just look how compilers do it?
Or use a compiler in your program?
Modifying high level language code snippets and subsequently compiling them, shouldn't be a problem.

My objective is to write a c program that has the ability to create another file(an executable) while it's running.

[Deque]

My objective is to write a c program that has the ability to create another file(an executable) while it's running.

I know. So what's the problem?

[frog]

I know. So what's the problem?

I'm looking for a standalone(no 'code snippets' in sight, no compilers abroad) solution. One executable already compiled; programmed to build another one without any other files. All the functionality to get the job done will be built into the original .exe. No other source files, compilers; NOTHING.

I love wasting my time while my objective gets lost in translation; attempting to portray my idea specifically has proved to be an exercise in futility. No need for reply.

[vezzy]

The only way I can think of besides implementing your own metacompiler is to make use of reflection, which is enabled by typing systems that evaluate metadata and introspect data types at runtime (dynamic).

An amusing possibility that unfortunately does not conform to your standards is to make use of a quine, so that you're dealing with your source as output. Then pipe regexes plus a compiler into it.

It also appears that C# offers its own native metacompiler interface: http://www.codeproject.com/Articles/19288/SlideShowBuilder

[frog]

The only way I can think of besides implementing your own metacompiler is to make use of reflection, which is enabled by typing systems that evaluate metadata and introspect data types at runtime (dynamic).

An amusing possibility that unfortunately does not conform to your standards is to make use of a quine, so that you're dealing with your source as output. Then pipe regexes plus a compiler into it.

It also appears that C# offers its own native metacompiler interface: http://www.codeproject.com/Articles/19288/SlideShowBuilder

Thank you for the reply vezzy. This is more along the lines of what I want. You have provided me with some good info and I like your ideas, but what about generating a Portable Executable through C code? With existing code libraries, I think this could be a simple task.

[Deque]

I'm looking for a standalone(no 'code snippets' in sight, no compilers abroad) solution. One executable already compiled; programmed to build another one without any other files. All the functionality to get the job done will be built into the original .exe. No other source files, compilers; NOTHING.

I love wasting my time while my objective gets lost in translation; attempting to portray my idea specifically has proved to be an exercise in futility. No need for reply.

I don't see why you emphazise the difference of compiled code or not. There is no difference. Just take your own template with you. That's the simplest solution. No one says you have to put the template right besides in a file. Just put it in the resource section of the PE or hardcode it, even the overlay can be used or whatever suits you. You will still have a single executable and the application is not different from having non-compiled sources.

Building/compiling a PE on your own is not easy and also not necessary. I have been writing a PE reader for a year now. There is no editing, no compiling, no building, just reading and I am still not finished. So either you have a template of a PE that you modify or you make use of a compiler to create a PE out of source code. Building a PE from scratch is nuts, unless you want to put years of work into it. I also highly doubt that the RATs you mentioned build from scratch. They will as well just have a PE or source template that they carry with them. Maybe configuration data that they change. Look up the PE specification to get some ideas. At least with the WinAPI it is no problem to read and edit certain parts of a PE. You could put some configuration data in a PE section and the server acts according to it.

If that's still not what you want, make yourself more clear. I can only take into account what you tell me.

what about generating a Portable Executable through C code? With existing code libraries

This is compiling. What else shall that be?

[frog]

I don't see why you emphazise the difference of compiled code or not. There is no difference. Just take your own template with you. That's the simplest solution. No one says you have to put the template right besides in a file. Just put it in the resource section of the PE or hardcode it, even the overlay can be used or whatever suits you. You will still have a single executable and the application is not different from having non-compiled sources.

Building/compiling a PE on your own is not easy and also not necessary. I have been writing a PE reader for a year now. There is no editing, no compiling, no building, just reading and I am still not finished. So either you have a template of a PE that you modify or you make use of a compiler to create a PE out of source code. Building a PE from scratch is nuts, unless you want to put years of work into it. I also highly doubt that the RATs you mentioned build from scratch. They will as well just have a PE or source template that they carry with them. Maybe configuration data that they change. Look up the PE specification to get some ideas. At least with the WinAPI it is no problem to read and edit certain parts of a PE. You could put some configuration data in a PE section and the server acts according to it.

If that's still not what you want, make yourself more clear. I can only take into account what you tell me.

This is compiling. What else shall that be?

This is what I want. I don't want to take a compiler with me. That is my 'goal'.

With libraries like pelib; there's no necessity for a full understanding of the pe format. Inherently I can cut through most of the details and in regards of the end result I will have put in a minimal amount of work.

You make a good point; I can't verify your claim about the methods that the legacy trojans use to build the server program. I can say that discounting the possibility of re-constructing pe format is short-sighted. You may be right; truth is I haven't heard any better suggestions. I'm all about efficiency and minimal effort; as the age we live in implicates re-use and consideration of the best known methods.

Being born in the late-80's, I have a fetish for learning some of the more generic methods for accomplishment of certain tasks. This is the reason for my adamancy.

Truly I don't give a fuck whether the code is compiled or not as long as it runs. Let me clarify.

I want the original code compiled. I want the original program to generate runnable code that is completely different in purpose of the original executable. The reason is portability. I don't see why nobody gets this.