C++ DLL编译后如何防止未授权访问内部成员？

Your proposed approach of only applying __declspec(dllexport) to public API elements is absolutely valid and effective. Here’s a breakdown of why it works, plus other robust alternatives:

1. Selective Export via __declspec(dllexport) or .def Files #

When compiling your DLL, only symbols explicitly marked with __declspec(dllexport) (or listed in a .def file) are added to the import library (.lib) and made accessible to external callers.

• Even if someone modifies your header to change a private member to public, the linker will fail to resolve that symbol because it was never exported. The import library simply doesn’t contain an entry for it.
• For classes: If you mark an entire class with __declspec(dllexport), all its public members are exported by default. To restrict access further, avoid exporting the entire class and instead export only specific public methods (or use a factory pattern to return instances of internal classes via interfaces).
• .def files are a more granular alternative: They let you explicitly list which symbols to export, including controlling name mangling (by specifying undecorated names) or assigning ordinals. This is equivalent to selective dllexport but gives you more control over the exported symbol names.

2. Abstract Interface + Pimpl Idiom #

This is a widely used pattern to completely hide implementation details from public headers:

• Expose only a pure virtual abstract class (interface) in your public header.
• The actual implementation lives inside the DLL, never exposed to users.
• Provide an exported factory method to create instances of the implementation class, returning them as pointers to the interface.

Example code:

// Public header (distributed with DLL)
class IMyLibraryAPI {
public:
    virtual void DoPublicWork() = 0;
    static IMyLibraryAPI* CreateInstance(); // Exported factory method
    virtual ~IMyLibraryAPI() = default;
};

// DLL internal code (not distributed)
class MyLibraryImpl : public IMyLibraryAPI {
private:
    void InternalPrivateMethod() { /* hidden logic */ }
public:
    void DoPublicWork() override { 
        InternalPrivateMethod(); 
        // public implementation
    }
};

// Export this factory method
__declspec(dllexport) IMyLibraryAPI* IMyLibraryAPI::CreateInstance() {
    return new MyLibraryImpl();
}

Even if users modify the public header, they can’t access InternalPrivateMethod—it’s not present in the interface, and the implementation is entirely hidden inside the DLL.

3. Symbol Hiding with Compiler Flags #

Use compiler settings to hide all symbols by default, then explicitly export only your public API:

• For MSVC: Use __declspec(dllexport) for public symbols (as you proposed) and ensure no unintended symbols are exported. You can also use the /EXPORT linker flag to explicitly list exports.
• For GCC/Clang: Compile with -fvisibility=hidden to hide all symbols by default, then mark public symbols with __attribute__((visibility("default"))).

This ensures that any internal symbols (even if accidentally declared public in code) are not visible outside the DLL, making header tampering ineffective.

4. Anonymous Namespaces for Internal Code #

Wrap all internal functions, classes, and data in anonymous namespaces in your DLL source files. This makes them local to the translation unit, so they won’t be exported or visible to external callers at all. Even if someone tries to declare these symbols in a modified header, the linker will never find them.

5. Runtime Integrity Checks (For Sensitive Use Cases) #

If you need to block runtime access via pointer casting or memory manipulation (a more edge case), you can add lightweight checks:

• Validate object layout or magic numbers in private fields to detect tampering.
• Use encrypted data structures for sensitive internal state.

This is overkill for most libraries but useful if you’re protecting sensitive logic or data.

To confirm again: Your initial idea of selective __declspec(dllexport) is a solid, practical solution. It directly addresses your concern by ensuring only intended symbols are accessible, regardless of header modifications.

内容的提问来源于stack exchange，提问作者Spring E. Thing