【導(dǎo)讀】化，然而邏輯距離卻在一天天縮小。同時(shí)，鑒于交通的繁忙，無紙辦公。和遠(yuǎn)程辦公的趨勢已然愈演愈烈！遠(yuǎn)程控制應(yīng)運(yùn)而生。式PC硬盤中的信息，甚至可以通過其臺(tái)式機(jī)PC訪問企業(yè)網(wǎng)絡(luò)資源。很多網(wǎng)絡(luò)管理員都采用這類軟件對局域網(wǎng)進(jìn)行管理或者在家中更。新自己網(wǎng)站的內(nèi)容。這類軟件對于出差在外的商務(wù)人員用處非常大，這。樣他們可以隨時(shí)提取自己家里計(jì)算機(jī)中的數(shù)據(jù)和資料。受到各方面的重視。本文主要分析了遠(yuǎn)程控制系統(tǒng)的一些基本功能和組。對應(yīng)用程序的實(shí)際開發(fā)實(shí)現(xiàn)作了介紹。達(dá)到了實(shí)時(shí)性和安全性，且應(yīng)用。同時(shí)簡單介紹了VisualC++編程環(huán)境和WinSocket. 算機(jī)的實(shí)時(shí)水平而設(shè)計(jì)的。遠(yuǎn)程控制包括多項(xiàng)內(nèi)容，本課題設(shè)計(jì)只是承

　　

【正文】 屏幕操作 文件操作 注冊表操作 服務(wù)操作 進(jìn)程操作 發(fā)送結(jié)果 顯 示結(jié)果 是否退出？ 退出系統(tǒng) 是 否 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 21 3 遠(yuǎn)程通信與控制程序設(shè)計(jì) 經(jīng)過需求分析階段，在軟件需求分析階段已經(jīng)弄清楚了各種需求，較好地解決了所開發(fā)的系統(tǒng) “ 做什么 ” 的問題，并已在軟件需求說明書和數(shù)據(jù)要求說明書中詳盡和充分地闡明了這些需求以后，下一步就要著手對軟件系統(tǒng)的結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、用戶界面等進(jìn)行設(shè)計(jì)。 系統(tǒng)設(shè)計(jì)使用工具 本系統(tǒng)采用 Visual C++ 作為開發(fā)工具， Visual C++ 源代碼編輯器功能強(qiáng)大，使用非常方便。它提供了語句自動(dòng)完成功能，編輯輸入源程序時(shí)能自動(dòng)顯示當(dāng)前對象的成員變量和成員函數(shù)，并表明函數(shù)的參數(shù)類型。 調(diào)試使用 VMware Workstation 虛擬機(jī) 搭建實(shí)驗(yàn)環(huán)境，分別開啟客戶端主機(jī)和服務(wù)端主機(jī) 。 系統(tǒng)模塊的設(shè)計(jì) 模塊設(shè)計(jì) 本系統(tǒng)面向的對象有兩種，一種是服務(wù)端，一種是客戶端。服務(wù)端只要是向客 戶端發(fā)送操作命令，客戶端解析命令后執(zhí)行相應(yīng)操作，然后將結(jié)果返回給服務(wù)端，服務(wù)端再將結(jié)果顯示出來。 屏幕監(jiān)控模塊設(shè)計(jì) 屏幕監(jiān)控，也就是將客戶端的屏幕截圖，然后發(fā)送給服務(wù)端。由于截圖圖片格式為 BMP，一幀圖像數(shù)據(jù)量很大，因此在此模塊中引用第三方開源類庫 CxImage，和壓縮庫 zlib，將截圖在內(nèi)存中壓縮成 JPEG網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 22 格式，然后再調(diào)用 zlib 的壓縮函數(shù)進(jìn)一步對 JPEG 壓縮，最后再發(fā)送給服務(wù)端。鼠標(biāo)和鍵盤的操作則是通過模擬來實(shí)現(xiàn)，在服務(wù)端捕獲鼠標(biāo)鍵盤操作后，服務(wù)端的命令連接就會(huì)將捕獲的結(jié)果發(fā)送到客戶端，客戶 端再通過調(diào)用 mouse_event 和 keybd_event 這兩個(gè) API 函數(shù)進(jìn)行模擬鼠標(biāo)鍵盤操作。該模塊大致流程圖如圖 所示： 圖 屏幕監(jiān)控 大致 流程圖 發(fā)送截屏命令 解析命令 截屏 圖片壓縮 添加數(shù)據(jù)包尾 發(fā)送數(shù)據(jù) 接收數(shù)據(jù) 是數(shù)據(jù)包尾嗎？ 模擬鼠標(biāo)點(diǎn)擊移動(dòng) 模擬鍵盤操作 是 否 數(shù)據(jù)包解壓 顯示圖片 服務(wù)端 客戶端 發(fā)送鍵盤鼠標(biāo)命令 停止傳輸嗎？ 開始屏幕傳輸 停止屏幕傳輸 是 否 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 23 文件操作模塊設(shè)計(jì) 文件操作，包括文件上傳、文件下載、刪除文件、執(zhí)行遠(yuǎn)程程序。當(dāng)然本系統(tǒng)還需要通過判斷客戶對文件圖標(biāo)的不同操作來判斷操作人對文件所作的不同操作，然后根據(jù)判斷結(jié)果執(zhí)行命令。該模塊大致流程圖如圖 所示： 圖 文件操作大致 流程圖 注冊表操作模塊設(shè)計(jì) 注冊表是為 Windows NT 和 Windows95 中所有 32 位硬件 /驅(qū)動(dòng)和 32 位應(yīng)用程序設(shè)計(jì)的數(shù)據(jù)文件。 16 位驅(qū)動(dòng)在 Winnt 下無法工作，所以所有設(shè)備都通過注冊表來控制，一般這些 是通過 BIOS來控制的。在 Win95 下， 16位驅(qū)動(dòng)會(huì)繼續(xù)以實(shí)模式方式設(shè)備工作，它 們使用 。 16位應(yīng)用程序會(huì)工作在 NT或者 Win95 下，它們的程序仍然會(huì)參考 和 文件獲得信息和執(zhí)行遠(yuǎn)程程序 發(fā)送命令 文件傳輸 顯示結(jié)果 服務(wù)端 解析命令 客戶端 刪除文件 文件傳輸 發(fā)送結(jié)果 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 24 控制。在沒有 注冊表的情況下，操作系統(tǒng)不會(huì)獲得必須的信息來運(yùn)行和控制附屬的設(shè)備和應(yīng)用程序及正確響應(yīng)用戶的輸入。 注冊表操作屬于命令操作，命令操作傳輸?shù)臄?shù)據(jù)量小，響應(yīng)快 。 為了客戶端程序能正常對進(jìn)程、服務(wù)等操作，還必須對客戶端進(jìn)程進(jìn)行提升權(quán)限操作。 發(fā)送信息模塊設(shè)計(jì) 對于信息的發(fā)送，本系統(tǒng)設(shè)計(jì)得相對簡單，僅發(fā)送一些文字信息?？蛻舳送ㄟ^編輯框編輯好將要發(fā)送的信息內(nèi)容，確認(rèn)發(fā)送后，產(chǎn)生windows 消息，然后系統(tǒng)通過建立的 Socket 套接字傳輸文字信息及編輯時(shí)的相應(yīng)的字體格式等。服務(wù)端接收后按照客戶端編輯的信息條件將 文字信息打印在屏幕上方。屏幕未刷新時(shí)，文字信息將一直留在屏幕上方，屏幕 刷新后，文字信息消失。 API HOOK模塊設(shè)計(jì) 本系統(tǒng)采用 API HOOK 技術(shù)對客戶端進(jìn)程進(jìn)行守護(hù)，達(dá)到防止客戶端進(jìn)程被惡意結(jié)束的目的。該功能采用了微軟的開源類庫 detours，對 OpenProcess 和 TerminateProcess 這兩個(gè)系統(tǒng) API 進(jìn)行 HOOK，從而實(shí)現(xiàn)對客戶端進(jìn)程進(jìn)行守護(hù)的目的。 客戶端與服務(wù)器連接設(shè)計(jì) CAsyncSocket 重載了 SOCKET 連接和斷開的消息事件，用戶可以在這些事件中判斷 SOCKET 的連接情況，但是斷開消息事件在一種情況下無法觸發(fā)，也就是網(wǎng)線被拔掉或其中一方斷電時(shí)，為了解決這種情況，可以在服務(wù)端和客戶端中都添加一個(gè)連接時(shí)鐘，周期性的給對方發(fā)送一個(gè)心跳包，如果發(fā)送失敗則表示對方已經(jīng)斷開連接，此時(shí)則進(jìn)入斷開重連狀態(tài)。 對于異步非阻塞的 SOCKET 來說，連接成功與否是在其 OnConnect事件里判斷的，該事件函數(shù)原型為： void OnConnect(int nErrorCode) ，網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 25 傳進(jìn)的參數(shù)如果等于 0，則表示連接成功。 相關(guān)代碼如下： void CSocketMsg::OnConnect(int nErrorCode) { if (nErrorCode == 0)//如果連接成功 { pMainWndKillTimer(CLOCKGETIP)。 char chName[1024]。 DWORD dwCount = 1024。 CString csSend = connect|。 csSendBuff = 。 dwCurSend = 0。 ::GetComputerName(chName, amp。dwCount)。//取計(jì)算機(jī)名 chName[dwCount] = 0。 csSend += chName。 csSend = csSend + | + pMainWndm_RemoFace + | + pMainWndm_RemoGruop + |。 dwCount = 1024。 ::GetUserName(chName, amp。dwCount)。//取登陸用戶名 chName[dwCount] = 0。 csSend += chName。 MySendTo(csSend)。//發(fā)送登陸信息 } CAsyncSocket::OnConnect(nErrorCode)。 } 系統(tǒng)主要模塊實(shí)現(xiàn) 屏幕監(jiān)控模塊 服務(wù)端向客戶端第一次發(fā)送獲取屏幕命令時(shí)，客戶端并非立刻截屏 ， 考慮到多個(gè)客戶端的屏幕分辨率大小不一致的情況下，客戶端首次網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 26 收到服務(wù)端的屏幕監(jiān)控命令后，應(yīng)先將客戶端當(dāng)前屏幕分辨率發(fā)送給服務(wù)端，服務(wù)端在窗口上創(chuàng)建一個(gè)矩形區(qū)域用于顯示客戶端桌面圖片，然后才是屏幕數(shù)據(jù)的傳輸，由于客戶端不停的發(fā)送屏幕數(shù)據(jù)，為了能使服務(wù)端區(qū)分每一幀的屏幕，客戶端在發(fā)送屏幕數(shù)據(jù)前，在屏幕數(shù)據(jù)尾部添加 10 個(gè)字節(jié)自定義的數(shù) 據(jù)包，服務(wù)端 在每次接收數(shù)據(jù)后都會(huì)檢驗(yàn)數(shù)據(jù)包尾部是不是自定義的數(shù)據(jù)包，如果是，則 表示一幀圖片傳輸完畢。 服務(wù)端接收到客戶端桌面圖片數(shù)據(jù)后，此時(shí)還不能將圖片直接畫到窗口上，因?yàn)閳D片數(shù)據(jù)發(fā)送前是經(jīng)過壓縮的，因此應(yīng)先解壓，再將解壓后的圖片畫 到窗口上，然后再發(fā)送請求下一幀桌面圖片的請求 。整個(gè)屏幕傳輸流程圖如圖 ： 圖 屏幕傳輸流程圖 發(fā)送截屏命令 解析命令 截屏 使用 CxImage 庫將 BMP 數(shù)據(jù)轉(zhuǎn)換成 JPEG 使用 zlib 庫將JPEG 圖片進(jìn)一步壓縮 在壓縮后的數(shù)據(jù)尾部添加 10 個(gè) 自定義數(shù)據(jù)包 發(fā)送數(shù)據(jù) 接收數(shù)據(jù) 是數(shù)據(jù)包尾嗎？ 是 否 使用 zlib 庫將 數(shù)據(jù)包解壓 顯示圖片 服務(wù)端 客戶端 停止傳輸嗎？ 停止傳輸 是 否 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 27 文件操作模塊 CAsyncSocket 是異步非阻塞類，在文件傳輸過程中， Send()函數(shù)一調(diào)用就立刻返回， 因此發(fā)送端常常無法知道接收端是否已經(jīng)接收到完整數(shù)據(jù)，在此算法設(shè)計(jì)中，可以將接收端當(dāng)前接收的總數(shù)據(jù)量大小發(fā)送給發(fā)送端，發(fā)送端則可以用此來比較客戶端是否已經(jīng)接收完全。 注冊表操作模塊 對于注冊表的操作，首先通過調(diào)用 RegOpenKey 函數(shù)打開某一注冊表項(xiàng)，然后執(zhí)行 RegSetValueEx 或 RegQueryValueEx 進(jìn)行對該注冊表項(xiàng)的讀寫。枚舉客戶端注冊表核心代碼如下： CString MyGetAllRegKeyValue(HKEY MainKey, CString KeyName) { DWORD dwIndex = 0, dwSize = 1024, dwType = REG_SZ。 char chKeyName[1024]。 CString csRes = 。 HKEY hkKey。 if (::RegOpenKey(MainKey, KeyName, amp。hkKey) != ERROR_SUCCESS) return 。 while(::RegEnumValue(hkKey, dwIndex, chKeyName, amp。dwSize, 0, amp。dwType, NULL, NULL) == ERROR_SUCCESS) { char chKeyValue[1024]。 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 28 DWORD dwTxtSize = 1024。 if (::RegQueryValueEx(hkKey, chKeyName, NULL, amp。dwType, (LPBYTE)chKeyValue, amp。dwTxtSize) == ERROR_SUCCESS) { if (dwType == REG_SZ || dwType == REG_EXPAND_SZ) { if (dwTxtSize = 0) { chKeyValue[0] = 39。 39。 chKeyValue[1] = 0。 } else chKeyValue[dwTxtSize] = 0。 csRes = csRes + chKeyName + char(3) + s + char(3) + chKeyValue + char(2)。 } else if (dwType == REG_DWORD) { byte* bTemp = (LPBYTE)chKeyValue。 CString csTemp。 DWORD dwTemp = (DWORD)(bTemp[3] * pow(256,3) + bTemp[2] * pow(256,2) + bTemp[1] * 256 + bTemp[0])。 (%d, dwTemp)。 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 29 csRes = csRes + chKeyName + char(3) + w + char(3) + csTemp + char(2)。 } } dwIndex++。 dwSize = 1024。 } ::RegCloseKey(hkKey)。 return csRes。 } API HOOK模塊 API HOOK 就是通過修改系統(tǒng) API 函數(shù)入口地址，將該地址指向新的自定義的函數(shù)，這樣就可以達(dá)到修改系統(tǒng) API 函數(shù)功能的目的。然而如果僅僅把 HOOK 代碼寫到程序中，那只是局部 HOOK，也就是只在本程序中起到 HOOK 作用，而外部程序還是調(diào)用原來的 API，這樣的話就達(dá)不到守護(hù)客戶端進(jìn)程的目的。安裝鉤子函數(shù)原型為： HHOOK SetWindowsHookEx( int idHook, HOOKPROC lpfn, HINSTANCE hMod, DWORD dwThreadId )。 參數(shù) int idHook 則表明安裝鉤子的類型，由于是對 API 函數(shù)的HOOK，所以該參數(shù)的值為 WH_CALLWNDPROC，通過 detours 庫，將自己定義的 API 函數(shù) NewOpenProcess、 NewTerminateP