## Create Process - observation

### Experiment confirming that before the first thread was resumed, most of the DLLs are not loaded:

1. With the help of CMake, generate a Visual Studio project of the `create_process` application:
+ `create_process32` - for 32 bit
+ `create_process64` - for 64 bit
2. Open the Visual Studio Project, and take a look at the code.
+ The application creates a suspended process of a given application
+ it reads and displays the context of the main thread of the newly created application. It waits for a button to be pressed.
+ After the button was pressed, it finally it resumes the thread
3. Compile the application (32 and 64 bit version)
4. Run it, supplying a path to a demo application from the compilation exercise.
+ Observe with Process Hacker: what are the modules loaded in the memory when the process is suspended?
+ What are the modules in the memory when the process resumes?

###  Experiment confirming that before the first thread in the process is resumed, we can find its PEB and Entry Point in the registry

1. Verify that the displayed Entry Point was valid:
+ Open Process Hacker - see where the main module was loaded and write down its address
+ Open the run executable by PE-bear, see the Entry Point
+ Add the module base to the Entry Point, see it it is the same as the one displayed on the screen
2. Verify if the displayed PEB was valid
+ Open WinDbg, choose: File -> Attach to a process. Write the PID of the created process
+ Display all the threads by `~`
+ Display TEB of the first thread (thread 0) which is the main thread:
`
dt nt!_TEB <TEB address>
`
+ Find the address of the PEB. Copy this address, ad compare it with the one that was displayed (from the registers)
