bats3c/DarkLoadLibrary

it doesn't work in VS2019 release x64

timwhitez opened this issue ยท 10 comments

it doesn't work in VS2019 release x64

and work well in VS2019 debug x64

SolomonSklash:master work well in release

+1

Debug example does work indeed. Release crashes with 0x000000005 exception (access denied?)

Faulting application name: DarkLoadLibrary.exe, version: 0.0.0.0, time stamp: 0x6171bdca
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0000000000000000
Faulting process id: 0x2250
Faulting application start time: 0x01d7c6b19c4d1f6e
Faulting application path: C:\Users\User\DarkLoadLibrary\DarkLoadLibrary\x64\Release\DarkLoadLibrary.exe
Faulting module path: unknown
Report Id: cbaa98f7-be77-4ddd-bf66-ee0c54bc06fd
Faulting package full name: 
Faulting package-relative application ID: 
Fault bucket , type 0
Event Name: BEX64
Response: Not available
Cab Id: 0

Problem signature:
P1: DarkLoadLibrary.exe
P2: 0.0.0.0
P3: 6171bdca
P4: StackHash_ac46
P5: 0.0.0.0
P6: 00000000
P7: PCH_70_FROM_ntdll+0x000000000009D8C4
P8: c0000005
P9: 0000000000000008
P10: 

Attached files:

These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_DarkLoadLibrary._d0f42ef13f7f86865f5326afe68f1da7f353066_c8712af1_b6f39a43-4741-400d-8def-ad90a721e094

Analysis symbol: 
Rechecking for solution: 0
Report Id: cbaa98f7-be77-4ddd-bf66-ee0c54bc06fd
Report Status: 4196
Hashed bucket: 
Cab Guid: 0

Crash happening in pebutils.c below. In Release mode pmbstowcs is underfined/zeroed, which causes address violation exception:

HMODULE IsModulePresentA(
	char* Name
)
{
	MBSTOWCS pmbstowcs = (MBSTOWCS)GetFunctionAddress(IsModulePresent(L"ucrtbased.dll"), "mbstowcs");

	wchar_t wtext[500];
	pmbstowcs(wtext, Name, strlen(Name) + 1);
	return IsModulePresent(wtext);
}

What a stupid bug. The debug CRT (ucrtbased.dll) does not get loaded in release mode obviously. Of course this fails, because people don't know how to check error codes. Why does this even use the CRT, when there is an equivalent in the Windows API itself? Who ever wrote this junk should be fucking lynched. I'll fix it in a few.

Oops

What a stupid bug. The debug CRT (ucrtbased.dll) does not get loaded in release mode obviously. Of course this fails, because people don't know how to check error codes. Why does this even use the CRT, when there is an equivalent in the Windows API itself? Who ever wrote this junk should be fucking lynched. I'll fix it in a few.

There were a few more instances of using ucrtbased.dll (just in case)

Yeah the idea is to not call functions directly to allow DarkLoadLibrary to run before address resolution, we could just implement those simple functions or find a reference in a library that is always loaded

The dynamic function resolution is not the issue, the issue is the function used and the lack of error code checking (leading to crashes in edge cases, not good)

Issue is fixed in #13

The PR has been merged, issue should be fixed now. Thanks @hypervis0r