All language subtitles for [English] Malware development 101_ Your first ever DLL Injector [DownSub.com]

This is part 2 of our malware development series,
go ahead and watch part 1 first, if you haven’t

already to get the most out of this video.
Leet cipher: hey sed, what the hell you

doin'? NOOOOOOO!!!
Leet cipher: why,

why did you do that???
Sed: I didn't know it's

going to work the first time.
Leet cipher: It did, and now

all of my projects are gone.
Sed: I'm sorry, man!

Leet cipher: You know what,
that's it, I had enough of

your s**t...

Hey there passwiper77,
I read a comment of yours

on a YouTube video claiming that the
saturnians have the most advanced

quantum forensics tools, do you know a
way with which I can reach out to them?

Regards,
Leet cipher

Hi eet cipher,

Please, do not email me in English,
I only understand Japanese.

Regards,
Passwiper77

Hey there a**wiper77,

I don't care if you understand English or not
just use Google translate you stupid motherf@$k3#

Leet cipher:

Hey sed, wake up, we're going to space.
Sed: what is it?

Leet cipher: we're going to space
Sed: what for?

Leet cipher: To fix your f**k up
Sed: Alright, let's go!

Hahaha, didn't know that saturnian jokes
are that funny. Alright guys thanks a

lot for everything. Safe travels. Goodbye.
Anyways, let’s start this video up and talk about

DLLs, but before that, I just want to mention that
some of you told me that I work for the FBI or I’m

an undercover FBI agent and all of that, well...
Sed: hey leet I found your badge

Hey, wtf...I believe, we didn’t
get the FBI’s attention so far,

but I’m pretty sure by the end of this
series, we will be on their watchlist,

so watch your backs. FBI OPEN UP!!!
Anyways, Alright, now, first things first,

let’s talk about DLLs, DLL is an abbreviation for
“Dynamic link library”, A DLL is like a special

file that contains code and data that programs can
use. If you happen to work on big coding projects,

most of the time, you’ll find yourself writing
a function or a block of code repeatedly in your

app, and since we have to follow the “dry” or
“don’t repeat yourself” principle in programming,

we take these functions and put them in a
separate file so whenever we need them we

can just include them and that’s all. DLLs
work the same way, you can think of it as

a collection of mini-programs or functions
that can be shared among larger programs.

Also keep in mind that a DLL is also considered
a portable executable, we can confirm that by

examining the “DOS” header in a hex editor
for both an executable such as “calc.exe”

and a DLL file like “kernel32.dll”. We can
see that they both share the same exact

“DOS” header. But still if we run the file
command on “calc.exe” and “kernel32.dll”,

we can see that “clalc.exe” is identified as “GUI”
executable and “kernel32.dll” is identified as a

DLL, but if that’s the case then how does the
operating system differentiate between the two?

Knowing that they both share the same dos header.
Well, if we load those two files in a “pe” parser

tool like “pe bear”, we can see in the “File
Header” section, the “characteristics” member has

an additional flag set for “kernel32.dll” which is
“File is a DLL”, so whenever the operating system

loads a portable executable, it first checks the
“characteristics” member to determine whether

this file is a “DLL” or a normal “executable”.
This is just a quick explanation so that you

don’t get confused when you see a DLL file has
the same header as a portable executable file.

From here, we will be talking about stuff
such as the windows api and the structure

of the memory space inside running processes,
so I highly recommend that you first watch the

previous video in which I explained these
concepts in detail and then come back here.

Now, to understand how DLL injection works,
we first need to understand how an executable

loads DLLs at runtime. When a process is run or
executed, the operating system dynamically links

all the necessary DLLs that the process will need
at runtime. These DLLs contain the windows APIs

that the process needs for its functionality.
We can use a tool such as process hacker to

confirm that by inspecting the loaded DLLs
in the memory space of a running process.

Everything so far until here is legit
and nothing is suspicious with it. Now,

if we want to abuse this behavior, we will have
to first create a malicious DLL and inject it

into the memory space of the target process.
But we still have a problem though, you see,

all of these loaded DLLs, the process uses them
for its functionality and if that's the case,

how are we supposed to execute our malicious
code that is inside this DLL, if the target

process is not using any code at all from it?
Well, there are 4 DLL callbacks that we can

abuse to execute code. “DLL_PROCESS_ATTACH”,
“DLL_PROCESS_DETACH”, “DLL_THREAD_ATTACH” and

“DLL_THREAD_DETACH”. These are called callbacks or
I would rather say event listeners. If you happen

to work with an awesome programming language
such as javascript, you’re probably familiar

with event listeners such as “onclick, onhover,
ondrag, ondrop…etc”. These event listeners listen

for the event to occur and then execute code
accordingly. For example, we can add an “onclick”

event listener on a certain button in a web page
which when clicked the code here is executed.

The same thing goes for these 4 callbacks or
event listeners. The “DLL_PROCESS_ATTACH” event

is triggered when the DLL is loaded or injected
into the memory space of a certain process, The

“DLL_PROCESS_DETACH” event is triggered when the
DLL is unloaded or freed from the memory space of

a certain process, The “DLL_THREAD_ATTACH” event
is triggered when a thread is created after the

DLL is loaded. And lastly the “DLL_THREAD_DETACH”
event is triggered when a thread is terminated.

Will go through each callback in detail
and how to execute it with code, just in

case you didn’t understand the process here,
but before that let’s first create our DLL.

Our quote and quote malicious
DLL here is fairly simple,

in the “DLLMain” function which is similar
to the main function in a standard C program,

we check which callback was invoked, and in
each of the four callbacks or event listeners

we discussed, we call the “MessageBox”
Windows API with a different message to

indicate which callback was triggered.
Make sure to set the compile mode to

release and the architecture to x64, same as
our DLL injector which we will create next.

Alright, now, similar to the previous video, we
will first inject this DLL into the memory space

of our local process and after that, we’ll get
nerdier and inject it into the memory space of

any running process of our choosing, sounds
good? Sounds great, alright, good, let’s do

this. Alright, sed, bring out the code, not this
one, the other one, the other other one, the other

other other one, there you go, well done, you can
go now, I’ll take it from here, still can see you,

anyways, this code is fairly simple to understand,
we first include the windows header to be able to

use WinAPI functions in our code. Again, we
talked about the windows API in detail in the

previous video, so, please, go and watch that one
first so that you can see the bigger picture here.

next the “stdio” header for input and output
operations. Here we have four windows APIs that

make this local injection happen, first, we use
the “LoadLibrary” API to load our malicious DLL

into the memory space of our process from disk.
If the call succeeds, it will trigger the

“DLL_PROCESS_ATTACH” callback which executes
our malicious code or the “MessageBox” API in

this case. Now, to trigger the next callback
which is the “DLL_THREAD_ATTACH” we use the

“CreateThread” API. Basically, the idea here
is that in order to trigger this callback,

we need to create a thread that does absolutely
anything, and for that we use the “CreateThread”

API and we pass to it a dummy function such
as this one, if this API runs successfully,

the second “MessageBox” API will be executed.
The last two callbacks are fairly simple,

we just need to wait till the thread terminates
and then we unload or free our malicious DLL.

So to trigger the “DLL_THREAD_DETACH” callback,
we use the “WaitForSingleObject” API, this API

halts the execution flow of the program until the
specified thread returns or terminates, once the

thread terminates, the callback will be triggered
and its “MessageBox” API will run. Finally, we use

the “FreeLibrary” API to unload our malicious
DLL and trigger the last callback. We can even

comment out this API since the process will free
all loaded modules or DLLs when it’s about to

terminate which will trigger this callback for
us. Now, before you run this program, make sure

the architecture is the same as the malicious DLL
then build the solution in release mode. After the

build is complete, run the program and give it the
full path to the malicious DLL. We can see here

our malicious DLL is loaded and the first callback
is triggered, and we can even confirm that our

malicious DLL is residing in the memory of our
process by inspecting the loaded modules inside

its memory space using process hacker. Moving
on, we can see the rest of the callbacks are

executed successfully without any issues, just,
you know, legit stuff as usual. NEXT! COME ON!

Alright, cool, now, before we proceed to create
our DLL Injector, we need to understand the

difference between two Windows APIs, “LoadLibrary”
and “GetModuleHandle”, both of these APIs return a

handle to a specified module or DLL, you might
be asking now, if that’s the case that means,

I can replace this “LoadLibrary” API with
“GetModuleHandle” and the code will still

work just fine, right? Well, no, it’s not going to
work. What “LoadLibrary” does is that it loads a

DLL from Disk and takes care of some stuff behind
the scenes such as resolving the Import Address

Table, and once it’s done, it returns a handle
to the loaded DLL. “GetModuleHandle” on the other

hand, just looks for the specified DLL in the list
of the loaded DLLs in the process memory, if the

DLL is found, it returns a pointer to the DLL base
address, which is what we call a handle. So here,

we used “LoadLibrary” because our malicious DLL is
loaded from disk straight to the process memory.

This is yet not the best way to load a malicious
DLL into memory, because most of the time, all of

these APIs are hooked and monitored by security
solutions. To get around this we would use a

technique called “Reflective DLL” which loads a
malicious DLL straight from memory, but that’s

a bit advanced and I don’t want to overwhelm you
with any more details. So now, Oh, crab, I forgot

to write the code. You know what, just give me
like 5 minutes and I’ll be done, this is jus...

Alright, this is the code that makes
the functionality for our DLL Injector.

It takes 2 parameters, the full path to our
malicious DLL and the process id into which

this DLL will be injected. Let’s assume that we
will inject into mspaint or microsoft paint. We

can obtain its process id by using a tool
such as process hacker or any similar tool,

or we can do the same thing we did in the previous
video which is to take a snapshot of all running

processes and search for mspaint and retrieve its
process id if it’s found. I didn’t implement that

here to reduce the complexity of the code and
only focus on the core functionality of this

DLL Injector. But you can do this yourself as
homework, but do not copy and paste anything.

Write the whole thing from scratch and implement
the processes enumeration functionality and pick

another process to inject into like notepad
or something. Anyways, let’s now visualize

what will happen in the memory when this code is
executed rather than explaining it line by line.

So, imagine this is the memory map of microsoft
paint. First things first, we get a handle

to this process using the “OpenProcess”
API, this api takes in three parameters:

the desired access to process object or the
access rights we want to have over the process,

Since we want access to all process resources,
we use the “PROCESS_ALL_ACCESS” flag.

The second parameter takes in a boolean
value, and we set it to “TRUE” if we want

to make the child processes created
by our process inherit this handle,

and since we’re not going to create any, we set
it to “FALSE”. The third parameter is the process

id which we want to access, which in our case
here will be the process id of mspaint. After

this handle is obtained, we use it to allocate
memory using “VirtualAllocEx”, this API takes in

5 parameters, the process handle, the base address
of the block of memory that we want to allocate,

since we don’t know exactly where should we
allocate this block of memory, will let the

operating system do that for us by setting this
parameter as “NULL”, the size of the memory that

we want to allocate and it’s set to the size of
the DLL path plus one, the extra byte here is

just for the terminating null byte of the string.
Next parameter is the allocation type. I explained

this parameter in great detail in the previous
video if you want to see the full explanation,

but in a nutshell, all what this parameter does
is that it tells the operating system to let us

write to this block of memory. Last parameter is
the page permissions, since we only want to read

and write to this block of memory, we set it to
“PAGE_READWRITE”. After our memory is allocated,

we use “WriteProcessMemory”, this api takes in
five parameters: the handle to the “microsoft

paint” process, a destination to write to, a
source to copy or read from, the size of the

copied data and the “number of bytes read” if
the function succeeds, will just set that one

to “NULL” since it’s not that important. Alright,
now, we have successfully written the full path

of the DLL into the allocated memory inside the
“mspaint” process. What we need to do now, is to

load the actual DLL into the memory space of this
process, and yes, you guessed right, we can do

that by using the “LoadLibrary” API, but the real
question here, how can we force this process to

execute “LoadLibrary” for us? Well, the answer is
pretty simple, we just need to obtain the virtual

address of the “LoadLibrary” API inside the memory
space of the “mspaint” process. We first need to

figure out which DLL has the “LoadLibrary” API.
From Microsoft documentation, we can see that it

resides in the “kernel32” DLL. So now, we get a
pointer to the base address of the “kernel32” DLL

using the “GetModuleHandle” API as we demonstrated
before, once we have the base address of this DLL,

we need to know the exact virtual address of the
“LoadLibrary” API relative to the base address

of the “kernel32” DLL, or in plain english, we
need to know how far is the “LoadLibrary” API

from the beginning of the “kernel32” DLL since
it has a ton of other APIs in it. So for that,

we use the “GetProcAddress” API, this API takes
in 2 parameters, the base address of the DLL and

what API to look for. This API will do some magic
and return the virtual address of the specified

API. It’s not really magic, it will just access
something called the “export directory” within

the DLL and look up the export table to retrieve
the address of the API. But we can call it magic

for now, just for the sake of simplicity.
You’re now might be like: wait a second,

the virtual address returned by “GetProcAddress”
is the virtual address of the “LoadLibrary” API

but only within the address space of our
“dll-injector” process, will this address

(of the “LoadLibrary” API) be the same within the
address space of the “microsoft paint” process,

since we will create a thread to run this API
within its address space? The answer is yes,

the addresses are identical in both processes. The
reason for that is because the windows operating

system knows that this “kernel32” file is a DLL
file. So, it just loads it somewhere in memory

and makes it accessible by all processes that
might need it, without the need to re-allocate

each DLL for each running process, which in
return saves much computing time and increases

performance. We can confirm that a DLL such as
“kernel32” is loaded in the same virtual address

by checking the loaded modules for any 2 processes
using the “process hacker” tool. So now, since we

are certain that we have the right virtual address
of the “LoadLibrary” API, we just need to create

a remote thread to execute this API within
the “microsoft paint” process, and for that,

we use the “CreateRemoteThread” API, this API
takes in 7 parameters, will set all parameters

to the default values except for 3, the process
handle, the address of the function to be run by

the thread and the parameter that will be passed
to the function. So essentially, what is actually

happening here is that the thread that will be
created, will execute the API in this address

which in this case is the “LoadLibrary” API and
we pass to it the allocated memory that stores the

full path to our DLL as a parameter. This typecast
as demonstrated before in the previous video,

converts this address to an entry point address
or in simple words, tells the created thread

that this address is the start of the code
that must be executed. Now, the last thing we

need to do is to wait for the thread to finish
execution using the “WaitForSingleObject” API,

this API takes in the handle to the thread and how
long to wait for the thread to return, we set that

to “INFINITE” since we want to completely halt the
execution flow until the thread returns. After it

returns, we close the handle to the process using
“CloseHandle”. After building this solution, you

will find the executable in “x64” then “Release”.
I already went ahead and copied our malicious DLL

in the same directory along with our DLL Injector.
Now, open a command prompt, make sure microsoft

paint is running to obtain its process id using
“process hacker” and then run the DLL Injector and

supply to it, the name of the DLL and the process
id. Running this, we can see the DLL callbacks

were triggered. We can even force the program
to trigger the “DLL_THREAD_ATTACH and DETACH”

callbacks by using any functionality in the
program that would create a thread such as opening

a file or a new window. Finally, once the program
is terminated, our malicious DLL will be freed and

the “DLL_PROCESS_DETACH” callback is triggered.
You can also find where exactly our DLL is loaded

in memory by checking the modules of the “mspaint”
process using process hacker. So yeah, that

concludes our DLL Injector, we did it, everyone.
Now, As an exercise or homework for you,

I want you to implement the whole thing from the
ground up and add to it the process enumeration

functionality, so that when you run it, you
supply the process name instead of the process id,

and if you get stuck, just watch the previous
video. You’ll find the code along with the

executables in my github, link in the description
below. I also wanted to apologize for my absence

for the past 6 to 7 months. This video should
have been up way sooner thatn that, I promise,

there was a lot I mean a lot going on in my
life, but hopefully now things are settled,

and I’m already working on the next video which
is going to be really on fire, so watch out for

this one. In the previous video, I told you let’s
get to 10k and now, we’re over 30, so yeah, that’s

really great, but you still need to subscribe
though, especially, when over 95% of you guys

aren’t, so yeah, subscribe really really I mean
it like like you need to subscribe now, so please

subscribe. If you made it this far,
umm thank you, I really appreciate you,

you’re awesome, you’re my hero.
If this content was beneficial to

you in any way and learned a thing or two from
it, you can buy me a coffee and keep the show

going. It’s only one man with his computer.
Lastly, I want to thank my saturnian friends

for restoring my projects and files. Really don’t
know what I would do without you guys. Perhaps,

I’ll start by replacing you,
Sed: me?

yeah you, I’m getting a new assistant, maybe
someone with a higher IQ level than yours,

or maybe, I can shoot you again now,
so that you don…wait, where’s my gun?

sed: you’re looking for this.
No, wait, no, NOOOOOOOOOOOOOOOOOOO.