DLL calculates self-crc then crc of part of code - espacially entry_point and crucial parts of code where you need to avoid software breakpoints (they modify the code by replacing it by CC byte).
Rambo -> CC Collateral damage makes an ability to debug it.

The correct return value from d00.dll D00CRC is E39D9CF2393276F2

If DLLInit short crc check fails, DLLInit returns FALSE and a00.exe failes to run.

If any part of a bigger checked part of a code of a DLL is corrupted, then D00CRC return value is 0.

If there is a software breakpoint at the instruction following call qword [D00CRC], then D00CRC return value is 0 - it is typically when using Trace Over (F8) with CC Collateral Damage turned off.

It is an analogy of the method when primary process runs more threads and each one of them watches others for modifying (modifying the code by craks, modifying the code during debugging by putting SW BP on stepping).

operating system does these steps:

1.
create_process a00.exe

2.
load_dll d00.dll
dll_init of d00.dll calculates short self crc, if the CRS is compromissed, the dll_init procedure returns FALSE and the whole initialization of a00.exe fails

3. call qword [D00CRC] returns correct E39D9CF2393276F2 or bad 0 which may be used for a00.exe code self decrypting. The principle is that call qword [D00CRC] has smaller opcode than mov rax,E39D9CF2393276F2, so a00.exe can't be patched because good assembler binary doesn't leave unnecessary code (instead of high level languages like mov eax,eax etc).
The exe can even calculate self-crc whether the opcode calling this API wasn't patched by a crack or software breakpoint of a debugger.

-----

a01.exe and d01.dll are a bit more sofisticated, d01.dll checks in DLLInit whether a01.exe hasn't the instruction at the entry point replaced with a software breakpoint.
It can be improved so D01CRC may calculate crc of bigger part of exe.
A small trick is used there, because a01.exe is at 100000000h and d01.dll at 200000000h and hInstance (=handle_of_Instance=this_address) is 1st input parameter (in RCX) at DLLInit.
Perhaps it can be searched in some certain windows internals structures instead of the hacking trick shr rcx,1
Perhaps GS mov rax,[00000030] and then scan in rax ?

The correct return value from d01.dll D01CRC is 8EAC4F890A0969FB

Please note that if you don't set Rambo -> CC Collateral damage, then
a01.exe fails to load under debugger because D01.dll detects SW BP at exe entry point.

-----

Epilogue how to debug DLLInit routine:
Perhaps there is a official way by microsoft itself, but no one hasn't been known to me yet.
So, my "hackers" method is:
Ctrl+E (Debuggee -> Open executable) -> Alt+E (uncheck "run over ntdll.DbgBreakPoint and halt on exe EntryPoint") -> Double click on executable (or select executable -> Open)
If you know the address of your DLLInit procedure, you can put breakpoint there (SW BP or HW BP) and execute run (F9) or everything in only 1 fast step - Execute to (Alt+F9) (e.g. for both D00.DLL as well D01.DLL it is 200001000h)
If you don't know the address, use this method:
Explore -> Imports -> ntdll.dll -> croll down and double click on RtlActivateActivationContextUnsafeFast -> Done.
Go to Log MDI child window -> double click on address of the above API (=the last thing in Log) -> Ctrl+C (copy) (in XP64SP2 it is 0000000077EF49A0).
Breakpoint -> Hardware breakpoint -> select No. 0, then go to address, press Ctrl+V (paste), then leave e/r/w=executable, leave uncheck the "permanent" checkbox) -> Done.
F9 (run)
Grab retrun address from the stack window (the topst qword) by double clicking on it and pressing Ctrl+C (copy) - in XP64SP2 it is 0000000077EDE991.
Put permanent hardware breakpoint at that address: Breakpoint -> Hardware breakpoint -> select No. 0, then go to address, press Ctrl+V (paste), then leave e/r/w=executable, Alt+P (or check "permanent") -> Done.
F9 (run)
Step few single steps (F7).
DLLInit in XP64SP2 is call rsi at 0000000077EDE9B1.

This way may change in next versions of w64.
In case of changing, use this method:
1. patch the dll entry point with CC byte using hexa editor.
2. launch executable loading dll with checked "run over ntdll.DbgBreakPoint and halt on exe EntryPoint".
3. restore the original byte at DLL entry point (double click on raw opcode and write original byte there and then press Enter).
4. look into Stack MDI child window, the qword at rsp is the return address from DLLInit - so double click on it, then press Ctrl+C
5. double click a address somewhere close to the bottom (to see preceeding instructions) in Code 1st, double click on it again (address stays selected), then press Ctrl+V and then press Enter, you are just after the call DLLInit, so watch few preceeding instructions.
