【正文】 安裝鉤子函數(shù)原型為： HHOOK SetWindowsHookEx( int idHook, HOOKPROC lpfn, HINSTANCE hMod, DWORD dwThreadId )。 } API HOOK 模塊 API HOOK 就是通過(guò)修改系統(tǒng) API 函數(shù)入口地址，將該地址指向新的自定義的函數(shù)，這樣就可以達(dá)到修改系統(tǒng) API 函數(shù)功能的目的。 } ::RegCloseKey(hkKey)。 } } dwIndex++。 (%d, dwTemp)。 CString csTemp。 csRes = csRes + chKeyName + char(3) + s + char(3) + chKeyValue + char(2)。 chKeyValue[1] = 0。dwTxtSize) == ERROR_SUCCESS) { if (dwType == REG_SZ || dwType == REG_EXPAND_SZ) { if (dwTxtSize = 0) { chKeyValue[0] = 39。 if (::RegQueryValueEx(hkKey, chKeyName, NULL, amp。dwType, NULL, NULL) == ERROR_SUCCESS) { char chKeyValue[1024]。 while(::RegEnumValue(hkKey, dwIndex, chKeyName, amp。 if (::RegOpenKey(MainKey, KeyName, amp。 CString csRes = 。枚舉客戶端注冊(cè)表核心代碼如下： CString MyGetAllRegKeyValue(HKEY MainKey, CString KeyName) { DWORD dwIndex = 0, dwSize = 1024, dwType = REG_SZ。整個(gè)屏幕傳輸流程圖如圖 ： 圖 屏幕傳輸流程圖 發(fā)送截屏命令 解析命令 截屏 使用 CxImage 庫(kù)將 BMP 數(shù)據(jù)轉(zhuǎn)換成 JPEG 使用 zlib 庫(kù)將JPEG 圖片進(jìn)一步壓縮 在壓縮后的數(shù)據(jù)尾部添加 10 個(gè) 自定義數(shù)據(jù)包 發(fā)送數(shù)據(jù) 接收數(shù)據(jù) 是數(shù)據(jù)包尾嗎？ 是 否 使用 zlib 庫(kù)將 數(shù)據(jù)包解壓 顯示圖片 服務(wù)端 客戶端 停止傳輸嗎？ 停止傳輸 是 否 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 27 文件操作模塊 CAsyncSocket 是異步非阻塞類，在文件傳輸過(guò)程中， Send()函數(shù)一調(diào)用就立刻返回， 因此發(fā)送端常常無(wú)法知道接收端是否已經(jīng)接收到完整數(shù)據(jù)，在此算法設(shè)計(jì)中，可以將接收端當(dāng)前接收的總數(shù)據(jù)量大小發(fā)送給發(fā)送端，發(fā)送端則可以用此來(lái)比較客戶端是否已經(jīng)接收完全。 } 系統(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ù)包，如果是，則 表示一幀圖片傳輸完畢。 MySendTo(csSend)。//取登陸用戶名 chName[dwCount] = 0。 ::GetUserName(chName, amp。 csSend = csSend + | + pMainWndm_RemoFace + | + pMainWndm_RemoGruop + |。//取計(jì)算機(jī)名 chName[dwCount] = 0。 ::GetComputerName(chName, amp。 csSendBuff = 。 DWORD dwCount = 1024。 相關(guān)代碼如下： void CSocketMsg::OnConnect(int nErrorCode) { if (nErrorCode == 0)//如果連接成功 { pMainWndKillTimer(CLOCKGETIP)。 客戶端與服務(wù)器連接設(shè)計(jì) CAsyncSocket 重載了 SOCKET 連接和斷開的消息事件，用戶可以在這些事件中判斷 SOCKET 的連接情況，但是斷開消息事件在一種情況下無(wú)法觸發(fā)，也就是網(wǎng)線被拔掉或其中一方斷電時(shí)，為了解決這種情況，可以在服務(wù)端和客戶端中都添加一個(gè)連接時(shí)鐘，周期性的給對(duì)方發(fā)送一個(gè)心跳包，如果發(fā)送失敗則表示對(duì)方已經(jīng)斷開連接，此時(shí)則進(jìn)入斷開重連狀態(tài)。 API HOOK模塊設(shè)計(jì) 本系統(tǒng)采用 API HOOK 技術(shù)對(duì)客戶端進(jìn)程進(jìn)行守護(hù)，達(dá)到防止客戶端進(jìn)程被惡意結(jié)束的目的。服務(wù)端接收后按照客戶端編輯的信息條件將 文字信息打印在屏幕上方。 發(fā)送信息模塊設(shè)計(jì) 對(duì)于信息的發(fā)送，本系統(tǒng)設(shè)計(jì)得相對(duì)簡(jiǎn)單，僅發(fā)送一些文字信息。 注冊(cè)表操作屬于命令操作，命令操作傳輸?shù)臄?shù)據(jù)量小，響應(yīng)快 。 16位應(yīng)用程序會(huì)工作在 NT或者 Win95 下，它們的程序仍然會(huì)參考 和 文件獲得信息和執(zhí)行遠(yuǎn)程程序 發(fā)送命令 文件傳輸 顯示結(jié)果 服務(wù)端 解析命令 客戶端 刪除文件 文件傳輸 發(fā)送結(jié)果 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 24 控制。 16 位驅(qū)動(dòng)在 Winnt 下無(wú)法工作，所以所有設(shè)備都通過(guò)注冊(cè)表來(lái)控制，一般這些 是通過(guò) BIOS來(lái)控制的。當(dāng)然本系統(tǒng)還需要通過(guò)判斷客戶對(duì)文件圖標(biāo)的不同操作來(lái)判斷操作人對(duì)文件所作的不同操作，然后根據(jù)判斷結(jié)果執(zhí)行命令。鼠標(biāo)和鍵盤的操作則是通過(guò)模擬來(lái)實(shí)現(xiàn)，在服務(wù)端捕獲鼠標(biāo)鍵盤操作后，服務(wù)端的命令連接就會(huì)將捕獲的結(jié)果發(fā)送到客戶端，客戶 端再通過(guò)調(diào)用 mouse_event 和 keybd_event 這兩個(gè) API 函數(shù)進(jìn)行模擬鼠標(biāo)鍵盤操作。 屏幕監(jiān)控模塊設(shè)計(jì) 屏幕監(jiān)控，也就是將客戶端的屏幕截圖，然后發(fā)送給服務(wù)端。 系統(tǒng)模塊的設(shè)計(jì) 模塊設(shè)計(jì) 本系統(tǒng)面向的對(duì)象有兩種，一種是服務(wù)端，一種是客戶端。它提供了語(yǔ)句自動(dòng)完成功能，編輯輸入源程序時(shí)能自動(dòng)顯示當(dāng)前對(duì)象的成員變量和成員函數(shù)，并表明函數(shù)的參數(shù)類型。 系統(tǒng)流程圖如圖 所示 ： 上傳文件到客戶端 下載客戶端文件 遠(yuǎn)程協(xié)助系統(tǒng) 創(chuàng)建文件夾 執(zhí)行遠(yuǎn)程程序 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 20 圖 系統(tǒng)流程圖 連接服務(wù)端 連接成功 ？ 客戶端程序 服務(wù)端程序 接受并添加客戶端信息 失敗 成功 發(fā)送 登錄 信息 發(fā)送操作命令 解析命令 屏幕操作 文件操作 注冊(cè)表操作 服務(wù)操作 進(jìn)程操作 發(fā)送結(jié)果 顯示結(jié)果 是否退出？ 退出系統(tǒng) 是 否 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 21 3 遠(yuǎn)程通信與控制程序設(shè)計(jì) 經(jīng)過(guò)需求分析階段，在軟件需求分析階段已經(jīng)弄清楚了各種需求，較好地解決了所開發(fā)的系統(tǒng) “ 做什么 ” 的問(wèn)題，并已在軟件需求說(shuō)明書和數(shù)據(jù)要求說(shuō)明書中詳盡和充分地闡明了這些需求以后，下一步就要著手對(duì)軟件系統(tǒng)的結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、用戶界面等進(jìn)行設(shè)計(jì)。 系統(tǒng)流程圖 首先運(yùn)行服務(wù)器端，然后安裝客戶端后，客戶端安裝好之后就會(huì)不斷的嘗試連接服務(wù)器，連接成功后就會(huì)想服務(wù)器端發(fā)送消息表明已經(jīng)登錄了，接著服務(wù)器端就會(huì) 發(fā)送命令給客戶端，客戶端根據(jù)服務(wù)端發(fā)送的命令執(zhí)行屏幕、文件注冊(cè)表、服務(wù)、進(jìn)程等操作。文件操作包括：上傳文件、下載文件、創(chuàng)建獲取遠(yuǎn)程桌面 控制遠(yuǎn)程鼠標(biāo) 控制遠(yuǎn)程鍵盤 遠(yuǎn)程協(xié)助系統(tǒng) 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 19 文件夾、執(zhí)行遠(yuǎn)程程序等等 。系統(tǒng)服務(wù)端 桌面監(jiān)控 的用例圖如圖 所示： 圖 屏幕控制用例圖 服務(wù)端對(duì)客戶端文件操作 服務(wù)端如果僅僅能監(jiān)控客戶端桌面，那幫助也許沒那么大，比 如客戶端要修復(fù)一些文件，而在客戶端本地硬盤中又沒有相應(yīng)的修復(fù)工具，此時(shí)服務(wù)端也是無(wú)能為力的。 根據(jù)對(duì) 一般的遠(yuǎn)程協(xié)助 的調(diào)查了解， 該系統(tǒng)應(yīng)該至少包含以下幾個(gè)功能 ： 服務(wù)端對(duì)客戶端的屏幕監(jiān)控 遠(yuǎn)程協(xié)助系統(tǒng)就是要解決那些難以用語(yǔ)言描述的軟件問(wèn)題，協(xié) 助端（服務(wù)端）如果能實(shí)時(shí)的看見被協(xié)助端（客戶端）的系統(tǒng)桌面，那將大大提高解決問(wèn)題的效率。 綜合以上三 方面的可行性分析，本課題設(shè)計(jì)的操作 是可行的。 操作可行性 根據(jù)系統(tǒng)的操作是否簡(jiǎn)單易懂，是否為用戶所接受，從操作的角度研究系統(tǒng)的可行性。網(wǎng)絡(luò)流量的問(wèn)題是造成所有通信程序的不穩(wěn)定性的罪魁禍?zhǔn)住? 技術(shù)可行性 本課題設(shè)計(jì) 所用到的一系列的技術(shù)已是累積了幾十年的技術(shù)，這些技術(shù)在這么多年的發(fā)展中并沒有被淘汰，反而是越來(lái)越來(lái)熱門。 經(jīng)濟(jì)可行性 本課題設(shè)計(jì) 成本低廉，要的只是兩個(gè) ISP 分發(fā)的 IP 地址，而且這也多用于局域網(wǎng)或企業(yè)網(wǎng)等內(nèi)網(wǎng)，就更談不上成本上的問(wèn)題。 可行性分析實(shí)質(zhì)上是要進(jìn)行一次大大壓縮簡(jiǎn)化了的系統(tǒng)分析和設(shè)計(jì)的過(guò)程，也就是在較高層次上以 較抽象的方式進(jìn)行的系統(tǒng)分析和設(shè)計(jì)的過(guò)程。 ? 遠(yuǎn)程維護(hù)和管理： 網(wǎng)絡(luò)管理員或者普通用戶可以通過(guò)遠(yuǎn)程控制技術(shù)為遠(yuǎn)端的電腦安裝和配置軟件、下載并安裝軟件修補(bǔ)程序、配置應(yīng)用程序和進(jìn)行系統(tǒng)軟件設(shè)置。 ? 遠(yuǎn)程教學(xué)： 教師和學(xué)生之間可以利用這種遠(yuǎn)程控制技術(shù)實(shí)現(xiàn)教學(xué)問(wèn)題的交流，學(xué)生可 以不用見到老師，就得到老師手把手的輔導(dǎo)和講授。許多用戶對(duì) 電腦 知道得很少，然而當(dāng)遇到問(wèn)題時(shí)，他們必須向無(wú)法看到電腦屏幕的技術(shù)人員描述問(wèn)題的癥狀。 遠(yuǎn)程控制的主要應(yīng)用如下： ? 遠(yuǎn)程辦公： 這種遠(yuǎn)程的辦公方式不僅大大緩解了城市交通狀況，減少了環(huán)境污染，還免去了人們上下班路上奔波的辛勞，更可以提高企業(yè)員工的工作效率和工作興趣。 遠(yuǎn)程控制因?yàn)檫M(jìn)一步克服了由于地域性差異所造成的不便性，所以在網(wǎng)絡(luò)管理、遠(yuǎn)程技術(shù)支持、遠(yuǎn)程交流、遠(yuǎn)程辦公等領(lǐng)域有著非常廣泛的應(yīng)用。 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 16 ? 隱藏機(jī)制不同： 木馬一般注冊(cè)為系統(tǒng)服務(wù)，偽裝為類似系統(tǒng)進(jìn)程的程序，用戶不能輕易關(guān)閉它；而遠(yuǎn)程控制服務(wù)端可以按其應(yīng)用考慮是否隱藏和是否能夠被關(guān)閉。但如果 客戶端為主動(dòng)方式連接服務(wù)端時(shí)，服務(wù)端可以接受多個(gè)客戶連接，所以視頻、語(yǔ)音的發(fā)送 可以實(shí)現(xiàn)遠(yuǎn)程 教學(xué)，遠(yuǎn)程協(xié)助等功能。 遠(yuǎn)程控制和木馬有很大的相似之處 ,譬如說(shuō)現(xiàn)在的 灰鴿子遠(yuǎn)程控制軟件〔企業(yè)版〕 ,它具有 兩種遠(yuǎn)程控制形式：服務(wù)端自動(dòng)上線連接型和客戶端主動(dòng)連接控制型，同時(shí)擁有兩者的所有功能。尋求一種方便、 高效的方法對(duì)出現(xiàn)故障的系統(tǒng)進(jìn)行修復(fù)已經(jīng)成為人們的迫切需要。傳統(tǒng)的遠(yuǎn)程控制軟件一般使用 NETBEUI、 NETBIOS、 IPX/SPX、 TCP/IP等協(xié)議來(lái)實(shí)現(xiàn)遠(yuǎn)程控制，不過(guò)，隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，目前很多遠(yuǎn)程控制軟件提供通過(guò) Web 頁(yè)面以 Java 技術(shù)來(lái)控制遠(yuǎn)程電腦，這樣可以實(shí)現(xiàn)不同操作系統(tǒng)下的遠(yuǎn)程控制 隨著計(jì)算機(jī)技術(shù)的不斷發(fā)展，人們要處理的任務(wù)也越來(lái)越多，工作地點(diǎn)也有可能是多個(gè)，在計(jì)算機(jī)使用的過(guò)程中就會(huì)遇到這樣那樣的問(wèn)題，從而使得工作變得更加繁重。 網(wǎng)絡(luò)遠(yuǎn)程通信與控制程序設(shè)計(jì) 15 2 遠(yuǎn)程通信與控制系統(tǒng)分析 系統(tǒng)基本情況描述 電腦中的遠(yuǎn)程控制技術(shù)，始于 DOS 時(shí)代，只不過(guò)當(dāng)時(shí)由于技術(shù)上沒有什么大的變化，網(wǎng)絡(luò)不發(fā)達(dá)，市場(chǎng)沒有更高的要求，所以遠(yuǎn)程控制技術(shù)沒有引起更多人的注意。建立Socket的 WSAStartup過(guò)程和 bind過(guò)程被簡(jiǎn)化成為 Create過(guò)程， IP地址類型轉(zhuǎn)換、主機(jī)名和 IP地址轉(zhuǎn)換的過(guò)程 中許多復(fù)雜的變量類型都被簡(jiǎn)化成字符串和整數(shù)操作，特別是 CAsyncSocket類的異步特點(diǎn)，完全可以替代繁瑣的線程操作。當(dāng)然 pSocket是和客戶 端 通信的服務(wù) 端 ，它不會(huì)觸發(fā)OnAccept()事件，因?yàn)樗皇潜O(jiān)聽 Socket。 Accept( *pSocket )。事實(shí)上，可以在 Connect()調(diào)用之后等待 CAsyncSocket::OnConnect()事件被觸發(fā)， CAsyncSocket::OnConnect()是要表明 Socket要么連接成功了，要么連接徹底失敗了。 因此 可以 在程序中 等待，等它連接成功為止，于是許多程 序 員 就 在 調(diào) 用 Connect() 之 后 ， Sleep(0