This is just a preferred address. Windows can load the binary at almost any address and rebase it to this new location.
ImageBase: The preferred address of the first byte of image when loaded into memory; must be a multiple of 64 K. The default for DLLs is 0x10000000. The default for Windows CE EXEs is 0x00010000. The default for Windows NT, Windows 2000, ...
This is the so-called "Rich header", added by Microsoft's link.exe (you can see the text "Rich" at the end of the mysterious block). It contains information about the versions of compilers and other tools which participated in producing the code of the executable. Some references:
Finding the Needle: A Study of the PE32 Rich Header and Respective Malware ...
While sdb files was created to translate imports that are referenced by ordinal instead of by name (see "Exporting Functions from a DLL by Ordinal Rather Than by Name"), pdb files are something entirely different.
Program Database (PDB) file or DBG file are produced by the compiler. PDB files are used by developers to debug their program ...
SDB stands for String Database.
sdb is a simple string key/value database based on cdb disk
storage and supports JSON and arrays introspection.
You can see the SDB commands listed with the k command,
|Usage: k[s] [key[=value]]Sdb Query
| k foo=bar set value
| k foo show value
| k list keys
Delayed imports are not processed by the system loader, so the programmer can put into it any kind of data, as long as they're prepared to handle it. By convention (mostly because Visual C++ did it), delayed imports are expected to use the same format as "normal" imports, but since this is not enforced by the OS it's not a requirement, and a specific program ...
Windows loader does not care about section names, so the name does not really matter, but usually this section contains the pointer to the indirect call guard check (___guard_check_icall_fptr). The pointer to it is stored in the GuardCFCheckFunctionPointer field of the load configuration directory.
I guess in the newer files it may contain some additional ...
In case of programs you'd also have to watch out for TLS callbacks. These run prior to the entry point, but I have only ever seen those on .exe files, never on DLLs. Still, Peter Ferrie stated that TLS callbacks exist for DLL files. I'd trust his expertise on this, even though I've never seen one of those myself, when reverse engineering a DLL.
The most useful reference I've seen about this section is in this Adobe source comment:
// Allocate xyz in the .00cfg so that it is implicitly merged into the
// import section of the binary (which is read-only).
// Indirect calls using this pointer do not have the guard check function,
// and so will not fail the CFG check.
The code appears to add ...
int 1 is not a part of the SEH setup, that's done by the third instruction. However, int is intercepted by Windows and is translated into an exception which is then dispatched to the handler that has been set up by the previous instructions. So basically here it serves as a sort of "invoke handler" macro.
In practice, any privileged instruction (e.g. hlt ...
The page you linked states that the ENCODING directive in the cfg file only applies to 1-byte-per-unit (1bpu) encodings, which this is not. UTF-16 is a 2bpu format.
The ENCODING directive is important because 1bpu characters are encoded differently depending on your culture. The values in the character table between 32 and 126 are usually the same, matching ...
you need to parse the section table, figure out to which section your address belongs (using their VirtualAddress and VirtualSize), then calculate the offset from the section start and add it to the section's physical offset. E.g.:
SectionOffset = addr - section[i].VirtualAddress
offset = SectionOffset + section[i].PointerToRawData
A directory does not ...
You can't load 32bit Dlls in 64bit Processes
Solution: build a 32bit App or write an external 32bit prozess(yes a EXE) that loads the DLL and communication with that process using Pipes or TCP/IP from your 64bit app
btw: the first Dlls name is FileAnalyzer.dll, in the Code is FileDataCtrl.dll?
Turned out it was just a trick inserted in the code to distract us. What can I say, it was very successful haha. I ended up asking my teacher and he told me to try and avoid getting into that part of the code and after that I was able to see my mistake. Definitely learned something by falling into that trap