Why Is The PE Entry Point Not The Same As Main SEH and The _security_init_cookie [Patreon Unlocked]

In this tutorial we examine why the entry point for MSVC console applications is not the same as main. We also dive into understanding
the __security_init_cookie and __scrt_common_main_seh functions. Expand for more...
In this tutorial is part of our RE101 series on Patreon where we discuss basic reverse engineering concepts. The full tutorial article including links for further reading and self-study examples is here:
/ why-is-pe-entry-61343353
-----
OALABS DISCORD
/ discord
OALABS PATREON
/ oalabs
OALABS GITHUB
github.com/OALabs
UNPACME - AUTOMATED MALWARE UNPACKING
www.unpac.me/#/
-----

[@OALABS]

Full tutorial with self-study examples and some more links in on Patreon here: www.patreon.com/posts/why-is-pe-entry-61343353

[@BibendiYT]

Can't wait for the video on calling conventions

[@OALABS]

As FreeDomSy pointed out I may need that video more than anyone haha!

[@chrism8401]

Thank you for the breakdown!

[@dmitriydibenko5529]

I like your tutorials already, but could you pleeeease make font bigger at the beginning of every video?) It will save my eyes)

[@robbie2044]

Nice vid! It's a Visual Studio stub. If you take the same code that was written in VS and compile it with something else (not MSVC), the stub will not be there obviously or you will get something else. But it is good to know this so you can identify the compiler used and know what you should analyze and what is just a compiler code.

[@saultube44]

Added to my programming playlist

[@mytechnotalent]

Excellent as always!

[@FreeDomSy-nk9ue]

This has always confused me especially when the binary is virtualized. Great tutorial, like always

[@OALABS]

Exactly! Our next tutorial on Patreon is looking precisely at this with VMP 😉

[@tomysshadow]

Semi-related: you may have assumed that the code in main is the first code to run in the process. Obviously this video shows that's not true, but it's not the entire story either: there's also code that runs before the entry point, too. If you set x64dbg to break on the entry point and look at the stack, you'll see a return to KERNEL32.DLL on the top of the stack - because even before running the entry point, the Windows loader has to set up the Import Address Table, the TLS Index, etc. so that those things can be read from memory by the executable's code. So KERNEL32.DLL code runs before anything in the main executable file, a bit counterintuitively, and then it calls the entry point like a function pointer.
This fact is sometimes abused by IAT rebuilders in order to avoid calling LoadLibrary and GetProcAddress. The idea is if the code looks up in the stack to where the return to KERNEL32 would be, it can take that address and, knowing it's in KERNEL32 somewhere, keep looking backwards from that address until it finds the PE Header of KERNEL32 (by looking for its signature, "MZ.") Then it can manually traverse KERNEL32's export table to find the addresses of its exports. At this stage, you might use Toolhelp Snapshots to do the same for other DLLs. The return address can also be jumped to, as a way to exit the process without using any imports.

[@OALABS]

Ah you are describing the loader, the first part of PE code that is run is either the TLS callbacks, or entry point (DLLMain for dlls). You should join our discord, I think you would enjoy the topics there discord.gg/oalabs

[@FreeDomSy-nk9ue]

10:20 I think the moves are RCX, RDX, R8 R9 for the first 4 args on x64 and not R10

[@OALABS]

OMG 🤦‍♂️ I can't believe I didn't catch that hahah! My bad, yes RCX, RDX, R8, and R9. I don't do a lot with 64-bit so it's rusty... maybe I need to watch my own calling conventions tutorial 😆

[@FreeDomSy-nk9ue]

I'm guessing windows needs to do some fixing before it can call main, like setting up the heap etc...

[@SpiritualIconoclast]

Do you have any remote positions open for malware reverse engineers? I’ve been learning some stuff over the years from you and I think I’m ready 😤

[@OALABS]

Best place to find remote RE jobs is ninjajobs.org/. It's free, and I highly reccomend!

[@Pille_e]

Nice and useful video! (as alwys) Although I have a dumb question. The caller allocates "shadow space" only on x64 or it also does it in x86? I looked it at myself and my hypothesis is it's only a thing in x64 applications.

[@OALABS]

x86 doesn't use shadow space it's an x64 only feature (also it wouldn't make too much sense except for fascall calling conventions)

[@thatguy7595]

What do you think about switching the video thumbnails to dark mode?

[@OALABS]

lol I don't think about it 😂

[@SpiritualIconoclast]

Can you please go over how to analyze x86 ELF malware? I have not been able to analyze one. I use readelf, strace, ltrace, gdb for debugging and IDA for static code analysis. The symbols of binaries that I am looking at are stripped and I can’t tell what’s what. I figured I can try to catch every syscall using gdb, or look for int 80 instructions and look for the interesting syscalls I saw in strace and start analysis or something. Is that how you do it? I would like to know your methodology please.

[@OALABS]

I really don't look at ELF binaries very often so I don't have a specific Linux setup. The last ELF malware I had to analyze was some ransomware that was encrypting ESXi hosts. In that case I did the full analysis statically. Even with a stripped binary you can use Lumina or other custom solutions to label library code. If you are going to be analyzing a lot of ELF malware (is there a lot?) I would suggest investing some time in building out a good FLIRT db. There are a few open source attempts at this that might help get you started (github.com/push0ebp/sig-database).

[@tappineapple3381]

What's stopping malware dev from executing code before the main as a form of "obfuscation"?

[@OALABS]

If you compile with MSVC the options are limited, you can check out TLS callbacks though, those used to be a pretty common malware trick (isc.sans.edu/diary/How+Malware+Defends+Itself+Using+TLS+Callback+Functions/6655). Obviously the binary could be modified post-compilation or something custom setup maybe using mingw or another compiler but that's far out of the scope of the tutorial.

[@tomysshadow]

There's nothing stopping you from patching the compiled binary after the fact to hide something in CRT code, at least if you know what you're doing and avoid using the features that code sets up (such as floats, TLS, etc.) In fact, it'd be a pretty stealthy place to hide something since everyone just steps over that stuff (especially in a DLL.) It's a little high effort though.