CODEWITHSUNDEEP
windowsvisual-studiodriverkmdf
iouvxz
iouvxz

Reputation: 163

How to solve LNK2019 unresolved external symbol DriverEntry referenced in function GsDriverEntry?

While I was compiling this project https://github.com/namazso/hdd_serial_spoofer

I got the error message above ,how can I solve this ? I'm using vs 2017 and wdk 10 .

(Must compile in release ,debug mode is not supported .There is no DriverEntry function in this project ,the EntryPoint(void* ntoskrn, void* image, void* alloc) function in hwid.cpp is the real entry point .)

I did a lot of research but still failed to get it work .I'm a noob in kernel mode driver development .

Upvotes: 6

Views: 9120

Answers (5)

Rohan
Rohan

Reputation: 39

Just use extern "C" ahead of NTSTATUS return value like this:

extern "C" NTSTATUS
DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) {
 //your driver code
}

Upvotes: 1

Carl
Carl

Reputation: 131

There are several causes that generate the problem. In my case, a try/except in the code, which compiles on x64, but doesn't compile on x86.

Linker Tools Error LNK2019 https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-error-lnk2019?view=msvc-170

Upvotes: 0

KeyC0de
KeyC0de

Reputation: 5277

Don't use .cpp source files to write your driver. Change them to .c and it should work. That was the case for me.

I know it looks trivial, or unlikely but remember Windows Kernel code is C code and Visual Studio makes various assumptions given the file extension of your source files.

Upvotes: 3

Hans Passant
Hans Passant

Reputation: 942040

This is not a normal driver, the kind that WDF directly supports. It is a "driverless driver", it uses an undocumented hack that is appealing to the kind of programmers that write rootkits for fun and profit. The DriverEntry() function is not actually the entrypoint for a driver, it is callback. Much like the WinMain() function is not actually the entrypoint for a native Win32 program. The EntryPoint() function in the project's source code is the replacement for the native driver entrypoint. Beware that the project appears to have rootkitty-like behavior, designed to fool a simplistic copy-protection scheme that checks a drive serial number.

The GsDriverEntry() function is the real entrypoint in a normal KMDF driver. It performs essential initialization to support the /GS compiler option, designed to detect buffer overflow. After that's done it calls DriverEntry(). The project replaces this entrypoint with EntryPoint().

This project was written with an old version of the Visual Studio project template. Several changes are necessary to get it to build properly:

  • C/C++ > Code Generation > Security Check. Must be "Disable security check (/GS-)", the original project file got this right.
  • Same property page > Control Flow Guard. Must be set to "No" to prevent a linker error. This option adds additional security checks that cannot work and must be disabled.
  • C/C++ > General > SDL checks. Use the dropdown arrow to override to "inherit from parent" so the option appears blank. More security checks that needs to be disabled, suppresses a warning that sdl- is incompatible with /gs-.
  • Same property page > Warning level. Override to "Level3 (/W3)", suppresses warnings about function arguments not being used.
  • Linker > Input > Additional Dependencies. Click the dropdown arrow > Edit. Untick the "Inherit from parent" checkbox and change to $(DDK_LIB_PATH)ntoskrnl.lib. Note the $(KernelBufferOverflowLib) entry in the Inherited values listbox, resolves to bufferoverflowfastfailk.lib, that is the one that contains GsDriverEntry() and produced the linker error.
  • Linker > Advanced > Entry Point. Must be "EntryPoint", the original project template got that right.

After this it builds clean. I did not test the resulting hwid.sys, looks a bit too evil to expose my machine to it.

Upvotes: 5

mksteve
mksteve

Reputation: 13085

The project uses (an apparently ignored) option

<EntryPointSymbol> to define EntryPoint as the entry.

This is documented here, but current documentation appears to mean this is really only for .exe and .dll projects.

The form of the mesage called from the Windows driver system

NTSTATUS DriverInitialize(
  _DRIVER_OBJECT *DriverObject,
  PUNICODE_STRING RegistryPath
)

Is incompatible with the EntryPoint in the project 

EntryPoint(void* ntoskrn, void* image, void* alloc)

This is not so bad, as none of the parameters which are called for EntryPoint are used.

So the simplest implementation would be 

extern "C"
{
    DRIVER_INITIALIZE DriverEntry;
    _Use_decl_annotations_
        NTSTATUS
        DriverEntry(
            struct _DRIVER_OBJECT  *DriverObject,
            PUNICODE_STRING  RegistryPath
        )
    {
        EntryPoint(NULL, NULL, NULL);
        return STATUS_SUCCESS;
    }
}

Kernel development is not for the faint hearted, and running invalid kernel code on your computer could make it difficult to boot, or in extream cases damage the computer. I did not review any of the code in the project for correctness.

Please run the code in a virtual machine (vmware, virtualbox, hyper-v) to limit the damage it could do

Upvotes: 7

Related Questions