I believe I have narrowed it even closer.

During the check, it loads a resource "VR" , 97h or 151 dec. (ResourceHack)

Here you see a bunch of encrypted hex data. This is what I believe it is comparing it to.

This is the routine that loads the resource data and is what looks like the first time data changes between original exe and modded exe.

Snippet:
41D250 MOV EAX,DWORD PTR SS:[ESP+4] ; start of find resource
41D254 MOV ECX,DWORD PTR SS:[ESP+8]
41D258 PUSH ESI
41D259 PUSH EDI
41D25A MOV EDI,DWORD PTR SS:[ESP+18] ; VR, 97
41D25E PUSH EAX ; /ResourceType
41D25F PUSH ECX ; |ResourceName
41D260 PUSH EDI ; |hModule
41D261 CALL DWORD PTR DS:[<&KERNEL32.FindResour>; \FindResourceA
41D267 MOV ESI,EAX
41D269 TEST ESI,ESI
41D26B JE SHORT Alien_Re.0041D297
41D26D PUSH EBX
41D26E MOV EBX,DWORD PTR SS:[ESP+18]
41D272 TEST EBX,EBX
41D274 JE SHORT Alien_Re.0041D280
41D276 PUSH ESI ; /hResource
41D277 PUSH EDI ; |hModule
41D278 CALL DWORD PTR DS:[<&KERNEL32.SizeofReso>; \SizeofResource
41D27E MOV DWORD PTR DS:[EBX],EAX
41D280 PUSH ESI ; /hResource
41D281 PUSH EDI ; |hModule
41D282 CALL DWORD PTR DS:[<&KERNEL32.LoadResour>; \LoadResource
41D288 TEST EAX,EAX
41D28A POP EBX
41D28B JE SHORT Alien_Re.0041D297
41D28D PUSH EAX ; /nHandles
41D28E CALL DWORD PTR DS:[<&KERNEL32.LockResour>; \SetHandleCount
41D294 POP EDI
41D295 POP ESI
41D296 RETN
41D297 POP EDI
41D298 XOR EAX,EAX
41D29A POP ESI
41D29B RETN

I've attached the code from the resource below as an attachement.

Here is THE code that does all the calling:
41449A PUSH Alien_Re.004030D0 ; ASCII "VR"
41449F CALL Alien_Re.00415A60
4144A4 ADD ESP,0C
4144A7 TEST EAX,EAX
4144A9 JE SHORT Alien_Re.00414525 ; good: no jump
4144AB PUSH EDI
4144AC MOV EDI,Alien_Re.00402FF8
4144B1 OR ECX,FFFFFFFF
4144B4 XOR EAX,EAX
4144B6 REPNE SCAS BYTE PTR ES:[EDI] ; EDI = 403014 (MODDED) 403000 (CLEAN)
4144B8 LEA EAX,DWORD PTR SS:[EBP-134] ; EAX = 13FB54
4144BE NOT ECX ; this routine moves most into stack
4144C0 PUSH EAX ; /Arg3
4144C1 PUSH ECX ; |ecx = 8 with clean exe, 1C with modded exe
4144C2 PUSH Alien_Re.00402FF8 ; |Arg1 = 00402FF8
4144C7 CALL Alien_Re.00420050 ; \Alien_Re.00420050
4144CC ADD ESP,0C
4144CF MOV ECX,DWORD PTR SS:[EBP-14] ; ECX == 1A800
4144D2 MOV EDX,DWORD PTR SS:[EBP-10] ; EDX == 43A500
4144D5 PUSH ECX
4144D6 PUSH EDX
4144D7 MOV ECX,Alien_Re.00426858
4144DC MOV BYTE PTR SS:[EBP-4],1
4144E0 CALL Alien_Re.0040D660
4144E5 MOV EAX,DWORD PTR DS:[426860] ; EAX == 1A800
4144EA MOV ECX,DWORD PTR DS:[426864] ; ECX == D4FFC0
4144F0 LEA EDX,DWORD PTR SS:[EBP-134]
4144F6 PUSH EDX ; /Arg3
4144F7 PUSH EAX ; |Arg2 => 00000000
4144F8 PUSH ECX ; |Arg1 => 00000000
4144F9 CALL Alien_Re.0042009D ; \Alien_Re.0042009D
4144FE MOV EAX,DWORD PTR DS:[426864] ; EAX == ptr ASCII "MZP" with clean, nothing with modded
414503 ADD ESP,0C
414506 PUSH EAX ; /Arg1 => 00000000
414507 CALL Alien_Re.0041E290 ; \Alien_Re.0041E290
41450C MOV DWORD PTR DS:[426884],EAX ; ^--- calls virtual Alloc = crash

It appears that it's not just a CRC check... it appears that ultimately the crash is due to an unknown address. There are 2 instances where Sicilia and MZP are listed with the clean version, but with the modded one, neither show up.

And again for reference, here is where the exception is thrown - ala crash.

41E299 MOV EAX,DWORD PTR SS:[EBP+8]
41E29C MOV ESI,DWORD PTR DS:[EAX+3C]
41E29F ADD ESI,EAX
41E2A1 PUSH 4 ; /Protect = PAGE_READWRITE
41E2A3 PUSH 1000 ; |AllocationType = MEM_COMMIT
41E2A8 MOV EAX,DWORD PTR DS:[ESI+50] ; crash is here, ptr = ???
41E2AB PUSH EAX ; |Size
41E2AC PUSH 0 ; |Address = NULL
41E2AE CALL <JMP.&KERNEL32.VirtualAlloc> ; \VirtualAlloc

*Removed attachment... see last post