gh0st错误修改

  开始看 gh0st 源码，找来了一份比较纯净的官方代码来读，有点抓狂，听说使用很老的VC6.0写的，现在需要用 VS2010 重新创建工程，并拷贝代码过去，编译，分析整个执行流程，调试每一个遇到的bug，在这过程中学到了很多，记录下来，供后来参考：

SetPaneText 的崩溃问题

  这个应该属于多线程操作控件的问题，参见MFC不能多线程操作控件的原因 这里面讲解的比较深入了。
关于状态栏StatusBar有几点需要说明：
1）刚刚创建工程 CMainFrame 类里面就有一个 CMFCStatusBar m_wndStatusBar; 状态栏变量定义。在原版工程里面是CStatusBar m_wndStatusBar;
2）在这个类的 OnCreate 函数里面调用 m_wndStatusBar.SetPaneInfo(0, m_wndStatusBar.GetItemID(0), SBPS_STRETCH , 300); 设置每个状态栏分割宽度，后面两个参数 SBPS_STRETCH 表示 剩余的宽度都算在这个分割里面，300表示最小宽度，MSDN文档。
3）关于 CMFCStatusBar 使用方法可见 鸡啄米专栏 VS2010/MFC编程入门之三十八（状态栏的使用详解） 。
4）gh0st里面是这样使用 m_wndStatusBar 的：

void CIOCPServer::OnAccept()
{
        m_pNotifyProc((LPVOID) m_pFrame, pContext, NC_CLIENT_CONNECT);
}
void CALLBACK CMainFrame::NotifyProc(LPVOID lpParam, ClientContext *pContext, UINT nCode)
{
    g_pFrame->m_wndStatusBar.SetPaneText(1, str);
}

当异常的时候调用栈如下：

跟踪到异常位置来到系统代码：

        // should also be in the permanent or temporary handle map
        CHandleMap* pMap = afxMapHWND();
        ASSERT(pMap != NULL);

        CObject* p=NULL;
        if(pMap)
        {
            ASSERT( (p = pMap->LookupPermanent(m_hWnd)) != NULL ||
                    (p = pMap->LookupTemporary(m_hWnd)) != NULL);
        }

总之一句话，这个 SetPaneText 是从其它线程 ListenThreadProc 调用过来的，如果要正常使用可以修改为如下方式 ：

void CALLBACK CMainFrame::NotifyProc(LPVOID lpParam, ClientContext *pContext, UINT nCode)
{
    g_pFrame->PostMessageA(UpdatePane);
}

g_pFrame 是一个 CMainFrame 类型指针，在CMainFrame 类里面加入一个消息处理过程：

ON_MESSAGE(UpdatePane, &CMainFrame::OnUpdatepane)
afx_msg LRESULT CMainFrame::OnUpdatepane(WPARAM wParam, LPARAM lParam)
{
    m_wndStatusBar.SetPaneText(1, "test");
    return 0;
}

  在 ListenThreadProc 向 CMainFrame 类发送一个消息 PostMessage(UpdatePane)，然后在 CMainFrame 类里面处理这个消息，至此问题完美解决。
参考：
MFC中从一个类向其他类发送消息的方法

WSAIoctl 参数类型导致栈异常

以前gh0st代码如下：

    const char chOpt = 1;
    WSAIoctl
        (
        pContext->m_Socket, 
        SIO_KEEPALIVE_VALS,
        &klive,
        sizeof(tcp_keepalive),
        NULL,
        0,
        (unsigned long *)&chOpt,
        0,
        NULL
        );

WSAIoctl 原型声明如下：

int WSAAPI WSAIoctl(
    __in SOCKET s,
    __in DWORD dwIoControlCode,
    __in_bcount_opt(cbInBuffer) LPVOID lpvInBuffer,
    __in DWORD cbInBuffer,
    __out_bcount_part_opt(cbOutBuffer, *lpcbBytesReturned) LPVOID lpvOutBuffer,
    __in DWORD cbOutBuffer,
    __out LPDWORD lpcbBytesReturned,
    __inout_opt LPWSAOVERLAPPED lpOverlapped,
    __in_opt LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine
    );

  倒数第三个参数应当是 LPDWORD 类型，而且是输出，传入的仅仅是char类型，虽然因为对齐 char 也分配了4字节，不会导致栈覆盖，但是在debug模式下系统加入了严苛的栈检测机制：虽然分配了四字节，因为是char类型，所以剩余的三字节是不应该修改的，在release下就没有这问题。
修改为 LONG 类型即可解决问题：

    unsigned long chOpt;
    *((char *)&chOpt)   = 1;

CIniFile 构造函数导致异常

系统自动定义的一个对象

// 唯一的一个 ChostApp 对象
ChostApp theApp;

这个构造函数应该是在最早执行的，在 ChostApp 里面有一个成员

CIniFile    m_IniFile;

所以要首先调用 CIniFile 的构造函数

CIniFile::CIniFile(void)
{
    char szAppName[MAX_PATH];
    int  len;
    HINSTANCE   hinst;
    //hinst = AfxGetInstanceHandle();
    ::GetModuleFileName(GetModuleHandle(NULL), szAppName, sizeof(szAppName));
    len = strlen(szAppName);
}

因为 AfxGetInstanceHandle() 调用导致异常。
具体可见CSDN论坛讨论。

栈上对象多线程，析构函数导致程序崩溃

  打开主控端。开启被控端， 此时主控端显示上线。

  在server端点击桌面管理可以正常显示被控端桌面，然后关闭远程桌面，此时被控端出现一个错误：
TestDll.exe 中的 0x5950cc6f (server.dll) 处有未经处理的异常: 0xC0000005: 读取位置 0x02ecfca4 时发生访问冲突

nRet = m_pClient->Send((LPBYTE)lpData, nSize);
5950CC64  mov         eax,dword ptr [ebp+0Ch]  
5950CC67  push        eax  
5950CC68  mov         ecx,dword ptr [ebp+8]  
5950CC6B  push        ecx  
5950CC6C  mov         edx,dword ptr [ebp-18h]  
5950CC6F  mov         ecx,dword ptr [edx+4]  

此时执行到的指令位置是 5950CC6F

对应的源代码是

int CManager::Send(LPBYTE lpData, UINT nSize)
{
  int  nRet = 0;
  try
  {
    nRet = m_pClient->Send((LPBYTE)lpData, nSize);
  }catch(...){};
  return nRet;
}

寄存器edx的数值是 edx 0x02ecfca0 unsigned long

  奇怪的是在关闭远程桌面以前这个函数执行了很多次，都没有出现这个问题。现在在关闭远程桌面之后就这样。通过对比发现 出现访问异常的内存 在关闭远程桌面之后数值出现了变化。

可以在关闭远程桌面之后 vs2010下内存访问断点，edx + 4 的位置

          调试  ->  新建断点   ->    新建内存断点

此时按F5发现中断在manager类的析构函数里面：

CManager::~CManager()
{
  CloseHandle(m_hEventDlgOpen);
}

再看堆栈窗口 是从 Loop_ScreenManager 函数结尾调用而来的：

DWORD WINAPI Loop_ScreenManager(SOCKET sRemote)
{
  CClientSocket  socketClient;
  if (!socketClient.Connect(CKernelManager::m_strMasterHost,  CKernelManager::m_nMasterPort))
    return -1;

  CScreenManager  manager(&socketClient);

  socketClient.run_event_loop();

  return 0;
}

  这样就大概分析出执行流程：

  在上面函数中定义了一个CScreenManager类的对象manager，这个对象在栈中。CScreenManager基类是 CManager
当在主控端把远程桌面关闭之后run_event_loop 会返回，这样这个函数也就返回了，对象manager也就开始调用自己的析构函数，以前能访问的现在也就不能访问了。 所以就会出现上面的问题。

  其实在运行的时候CScreenManager类的构造函数中创建了2个线程ControlThread ，WorkThread,当正常运行没有调试器中断的时候当函数 Loop_ScreenManager 执行完之后ControlThread 这个线程还未完全退出，不知道这样会产生什么意外后果？？

  经过试验在 函数 Loop_ScreenManager结束之前加入 sleep(20) 可以解决这个问题。

注：14年有段时间看过这个源码，发现了这个问题，发表在看雪论坛。这里转载过来。