shared.cpp

Question

我有一些遗留代码，它们围绕着指向内部数据结构的指针传递，该库用于处理和检查状态变量。考虑到重构此代码，我好奇是否创建一堆仅在我的库内部使用的类会引起安全隐患。其他人可以链接他们自己的这些方法的实现吗？假设我有一个Config类，该类读取加密的许可证并正确设置设置。可以以某种方式操纵此类吗？

这是我为尝试初步可行性而编写的一些代码

shared.cpp

#include "shared.h"


Config::Config() : max_clients()
{
}

Config::~Config()
{
}

int Config::getMaxClients() const
{
    return max_clients;
}

void Config::setMaxClients(int num)
{
    max_clients = num;
}

我将其编译为共享库

g++ -c shared.cpp -fpic
g++ -shared -o libshared.so shared.o

编译后，我们可以在库中看到其他人对我们的Config类的了解。

$ nm -C libshared.so
0000000000201030 B __bss_start
0000000000201030 b completed.7696
                 w __cxa_finalize
0000000000000780 t deregister_tm_clones
0000000000000810 t __do_global_dtors_aux
0000000000200e20 t __do_global_dtors_aux_fini_array_entry
0000000000201028 d __dso_handle
0000000000200e58 d _DYNAMIC
0000000000201030 D _edata
0000000000201038 B _end
00000000000008f8 T _fini
0000000000000850 t frame_dummy
0000000000200e18 t __frame_dummy_init_array_entry
0000000000000a50 r __FRAME_END__
0000000000201000 d _GLOBAL_OFFSET_TABLE_
                 w __gmon_start__
0000000000000910 r __GNU_EH_FRAME_HDR
0000000000000720 T _init
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
00000000000007c0 t register_tm_clones
0000000000201030 d __TMC_END__
                 U operator delete(void*, unsigned long)
00000000000008de T Config::setMaxClients(int)
000000000000085a T Config::Config()
000000000000085a T Config::Config()
00000000000008a0 T Config::~Config()
0000000000000882 T Config::~Config()
0000000000000882 T Config::~Config()
00000000000008cc T Config::getMaxClients() const
0000000000200e48 V typeinfo for Config
0000000000000908 V typeinfo name for Config
0000000000200e28 V vtable for Config
                 U vtable for __cxxabiv1::__class_type_info

可能还有很多我不知道的分析。

mal.cpp

借助这些信息，我们可以对setMaxClients上的返回类型进行一些猜测，并创建我们自己的实现。

#include <iostream>

class Config {
public:
    Config() {}
    void setMaxClients(int num);
};

void Config::setMaxClients(int num)
{
    std::cout << "do something bad" << std::endl;
}

我使用以下文件编译了该文件

g++ -c mal.cpp -fpic
g++ -shared -o libmal.so mal.o

main.cpp

class Config {
public:
    Config();
    virtual ~Config();
    int getMaxClients();
    void setMaxClients(int num);
};

int main()
{
    Config config;
    config.setMaxClients(4);

    return 0;
}

最后，我编译main.cpp时先链接我的mal库，然后再链接shared

g++ main.cpp -lmal -lshared

这产生了一个二进制文件，运行时我得到了

$ LD_LIBRARY_PATH=. ./a.out
do something bad
*** stack smashing detected ***: <unknown> terminated
[1]    7842 abort (core dumped)  LD_LIBRARY_PATH=. ./a.out

是的，它崩溃了，但是我对接下来要去的地方没有更多的经验。这是否出于安全考虑，因为您不知道成员变量，因此实际上无法更改任何类字段？还是这里需要C ++的最佳实践？

Answer 1

理想情况下，您的替代班级人数应与原始班级人数相同。 main.cpp中的配置有一个虚拟dtor，而mal.cpp中的没有。这将导致后者大8个字节（假设使用64位OS），并且总是会导致类破坏的问题。如果这是一个真正的问题，则简单的下一步是对dll执行校验和，并在运行时进行验证（如果校验和不匹配，请退出）。对于一个真正在乎的人来说，这不会有什么帮助。如果您对asm足够了解，通常可以使用一些no-op修补二进制exe，直到检查返回true。

人们能否利用自己的实现劫持已编译的库？

shared.cpp

mal.cpp

main.cpp

1 个答案: