【正文】 方面給用戶和 網(wǎng)絡(luò)管理員工作帶了很大的方便，另一方面也給一些居心不良者留下后門。這種技術(shù)支持方式盡管被普遍采用，但效率不高而且大大增加了技術(shù)支持成本。此外，如果通過電話不能解決問題，那么 在 技術(shù)人員親自到用戶現(xiàn)場解決問題之前，計算機將 無法繼續(xù) 使用 ，導(dǎo)致工作延誤 。此外，有的遠程控制軟件還支持通過串口、并口、紅外端口來對遠程機進行控制（不過這里說的遠程電腦，只能是有限距離范圍內(nèi)的電腦了）。你不可能使用 TCP 協(xié)議的軟件從某一家公司的電腦，控制另外一家公司的內(nèi)部電腦，或者從網(wǎng)吧、賓館里控制你辦公室的電腦，因為他們 處于不同的內(nèi)網(wǎng)中。最關(guān)鍵的是：使用 UDP 協(xié)議可以利用 UDP 的打洞原理（ UDP Hole Punching 技術(shù)）穿透內(nèi)網(wǎng)。你會發(fā)現(xiàn)使用穿透內(nèi)網(wǎng)的遠程控制軟件無需做端口映射即可實現(xiàn)連接，這類軟件都需要一臺服務(wù)器協(xié)助程序進行通訊以便實現(xiàn)內(nèi)網(wǎng)的穿透。實際上，使用遠程 控制 工具的技術(shù)人員能夠做到解答疑難問題，安裝和配置軟件，把軟件下載到用戶計網(wǎng)絡(luò)遠程通信與控制程序設(shè)計 4 算機上，配置應(yīng)用程序和系統(tǒng)軟件設(shè)置并可通過實際操作培訓(xùn)用戶。 它以擁有 “ 語法高亮 ” ， IntelliSense（自動編譯功能）以及高級除錯功能而著稱。這些特征明顯縮短程式編輯、編譯及連結(jié)的時間花費，在大型軟件計劃上尤其顯著。 但產(chǎn)品名 “ Visual C++” 也容易誤導(dǎo)人，讓人認為自己使用的是一個與 Microsoft Visual Basic 類似的完全可視化的系統(tǒng)。 MFC 是 Win API 與 C++的結(jié)合 ,API,即微軟提供的 Windows下應(yīng)用程序的 編程語言 接口 ,是一種軟件編程的規(guī)范 ,但不是一種程序開發(fā)語言本身 ,可以允許用戶使用各種各樣的第三方 (如我是一方 ,微軟是一方 ,Borland 就是第三方 )的編程語言來進行對Windows 下應(yīng)用程序的開發(fā) ,使這些被開發(fā)出來的應(yīng)用程序能在Windows 下運行 ,比如 VB,VC++,JAVA,Delhpi 編程語言 函數(shù) 本質(zhì)上全部源于 API,因此用它們開發(fā)出來的應(yīng)用程序都能工作在Windows 的 消息機 制 和繪圖里 ,遵守 Windows 作為一個 操作系統(tǒng) 的內(nèi)部實現(xiàn) ,這其實也是一種必要 ,微軟如果不提供 API,這個世上對Windows 編程的工作就不會存在 ,微軟的產(chǎn)品就會迅速從時尚變成垃圾 ,上面說到 MFC 是微軟對 API 函數(shù)的專用 C++封裝 ,這種結(jié)合一方面讓用戶使用微軟的專業(yè) C++ SDK 來進行 Windows 下應(yīng)用程序的開發(fā)變得容易 ,因為 MFC 是對 API 的封裝 ,微軟做了大量的工作 ,隱藏了好多程序開發(fā)人員在 Windows 下用 C++ amp。 windows 作為一個提供功能強大的應(yīng)用程序接口 編程的操作系統(tǒng)，的確方便了許多 程序員 ，傳統(tǒng)的win32 開發(fā)（直接使用 windows 的 接口函數(shù) API）對于程序員來說非常的困難，因為， API 函數(shù)實在太多了，而且名稱很亂，從零構(gòu)架一個窗口動輒就是上百行的代碼。類庫是可在應(yīng)用程序中使用的有關(guān) C++類的集合。使用 MFC 類庫構(gòu)建應(yīng)用程序具有以下優(yōu)點 。 MFC 封裝了 Win32 SDK 中的幾乎所有函數(shù)，網(wǎng)絡(luò)遠程通信與控制程序設(shè)計 7 能實現(xiàn) Win32 系統(tǒng)的任何功能。除封裝了大部分的 Win32 SDK 函數(shù)外， MFC 還提供了應(yīng)用程序本身的數(shù)據(jù)和操作及 ActiveX、 OLE、 Inter、WinSock、 DAO（ Data Access Objects）、 ODBC（ Open DataBase Connectivity）等操作類。 MFC的消息映射 在使用 Visual C++進行 Win32 程序設(shè)計時，消息映射是一個非常重要的概念。消息的基本格式如下： Message wParam lParam Message 是消息名稱； wParam是與消息相關(guān)的 Word 型參數(shù)； lParam是與消息相關(guān)的 Long 型參數(shù)。 網(wǎng)絡(luò)遠程通信與控制程序設(shè)計 8 控制通知消息：控制或子窗口傳給父窗口的 WM_COMMAND 通知的消息。消息處理函數(shù)是某些類（通常是窗口類）的成員函數(shù)和程序員在其中編寫響應(yīng)消息時應(yīng)進行操作的代碼。在源代碼 中，消息映射開始于 BEGIN_MESSAGE_MAP 宏，結(jié)束于 END_MESSAGE_MAP 宏，中間由一系列預(yù)定義的被稱為 “ 條目宏 ” 的宏組成。 Windows 消息的處理函數(shù)在 CWnd 類中進行了預(yù)定義，類庫以消息名為基礎(chǔ)定義這些處理函數(shù)的名稱，且 MFC 要求所有消息處理函數(shù)聲明為 afx_msg 類型。 ClassWizard 將在生成的處理函數(shù)中建議是否應(yīng)調(diào)用父類的消息處理函數(shù)及調(diào)用的次序。 兩層結(jié)構(gòu)， 它由兩部分構(gòu)成 ， 前端是客戶機，通常是 PC，主要完成用戶界面顯示，接受數(shù)據(jù)輸入，校驗數(shù)據(jù)有效性，向后臺數(shù)據(jù)庫發(fā)請求，接受返回結(jié)果，處理應(yīng)用邏輯；后端是服務(wù)器，運行 DBMS，提 供數(shù)據(jù)庫的查詢和管理。基于三層結(jié)構(gòu)的應(yīng)用系統(tǒng)不但具備了大型機系統(tǒng)穩(wěn)定、安全和處理能力高等特性，同時擁有開放系統(tǒng)成本低、可擴展性強、開發(fā)周期短等優(yōu)點。 網(wǎng)絡(luò)遠程通信與控制程序設(shè)計 11 圖 Client/Server 的 通信流程 C/S 結(jié)構(gòu)的優(yōu)點 Client/Server 技術(shù)在目前程序開發(fā)中得到了廣泛的應(yīng)用，這種技 術(shù)的優(yōu)點在于它將處理工作按照一定的比例分配到客戶端和服務(wù)器上去執(zhí)行，這樣減少了網(wǎng)絡(luò)傳輸?shù)墓ぷ髁?，從而合理地利用了資源，提高了應(yīng)用程序開發(fā)的效率。鉤子實際上是一個處理消息 的程序段，通過系統(tǒng)調(diào)用，把它掛入系統(tǒng)。 API HOOK 技術(shù)并不是計算機病毒專有技術(shù)，但是計算機病毒經(jīng)常使用這個技術(shù)來達到隱藏自己的目的 。最初有些人對某些 api 函數(shù)的功能不太滿意，就產(chǎn)生了如何修改這些 api，使之更好的服務(wù)于程序的想法，這樣 API hook 就自然而然的出現(xiàn)了。 Windows 系統(tǒng)下的編程，消息 Message 的傳遞是貫穿其始終的。今天隨著控件， STL等高效 編程技術(shù)的出現(xiàn)，API的使用概率在普通的用戶程序上就變得越來越小了?；镜姆椒ň褪峭ㄟ^ Hook“ 接網(wǎng)絡(luò)遠程通信與控制程序設(shè)計 13 觸 ” 到需要修改的 API函數(shù)入口點，改變它的地址指向新的自定義的函數(shù)。 CAsyncSocket::Create()有一個參數(shù)指明了 使用者想 要處理哪些 Socket事件， 使用者 關(guān)心的事件被指定以后，這個 Socket默認就被用作了異步方式。 因此 可以 在程序中 等待，等它連接成功為止，于是許多程 序 員 就 在 調(diào) 用 Connect() 之 后 ， Sleep(0) ， 然 后 不 停 地 用WSAGetLastError()或者 CAsyncSocket::GetLastError()查看 Socket返回的錯誤，直到返回成功為止。 Accept( *pSocket )。建立Socket的 WSAStartup過程和 bind過程被簡化成為 Create過程， IP地址類型轉(zhuǎn)換、主機名和 IP地址轉(zhuǎn)換的過程 中許多復(fù)雜的變量類型都被簡化成字符串和整數(shù)操作，特別是 CAsyncSocket類的異步特點，完全可以替代繁瑣的線程操作。傳統(tǒng)的遠程控制軟件一般使用 NETBEUI、 NETBIOS、 IPX/SPX、 TCP/IP等協(xié)議來實現(xiàn)遠程控制，不過，隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，目前很多遠程控制軟件提供通過 Web 頁面以 Java 技術(shù)來控制遠程電腦，這樣可以實現(xiàn)不同操作系統(tǒng)下的遠程控制 隨著計算機技術(shù)的不斷發(fā)展，人們要處理的任務(wù)也越來越多，工作地點也有可能是多個，在計算機使用的過程中就會遇到這樣那樣的問題，從而使得工作變得更加繁重。 遠程控制和木馬有很大的相似之處 ,譬如說現(xiàn)在的 灰鴿子遠程控制軟件〔企業(yè)版〕 ,它具有 兩種遠程控制形式：服務(wù)端自動上線連接型和客戶端主動連接控制型，同時擁有兩者的所有功能。 網(wǎng)絡(luò)遠程通信與控制程序設(shè)計 16 ? 隱藏機制不同： 木馬一般注冊為系統(tǒng)服務(wù)，偽裝為類似系統(tǒng)進程的程序，用戶不能輕易關(guān)閉它；而遠程控制服務(wù)端可以按其應(yīng)用考慮是否隱藏和是否能夠被關(guān)閉。 遠程控制的主要應(yīng)用如下： ? 遠程辦公： 這種遠程的辦公方式不僅大大緩解了城市交通狀況，減少了環(huán)境污染，還免去了人們上下班路上奔波的辛勞，更可以提高企業(yè)員工的工作效率和工作興趣。 ? 遠程教學： 教師和學生之間可以利用這種遠程控制技術(shù)實現(xiàn)教學問題的交流，學生可 以不用見到老師，就得到老師手把手的輔導(dǎo)和講授。 可行性分析實質(zhì)上是要進行一次大大壓縮簡化了的系統(tǒng)分析和設(shè)計的過程，也就是在較高層次上以 較抽象的方式進行的系統(tǒng)分析和設(shè)計的過程。 技術(shù)可行性 本課題設(shè)計 所用到的一系列的技術(shù)已是累積了幾十年的技術(shù)，這些技術(shù)在這么多年的發(fā)展中并沒有被淘汰，反而是越來越來熱門。 操作可行性 根據(jù)系統(tǒng)的操作是否簡單易懂，是否為用戶所接受，從操作的角度研究系統(tǒng)的可行性。 根據(jù)對 一般的遠程協(xié)助 的調(diào)查了解， 該系統(tǒng)應(yīng)該至少包含以下幾個功能 ： 服務(wù)端對客戶端的屏幕監(jiān)控 遠程協(xié)助系統(tǒng)就是要解決那些難以用語言描述的軟件問題，協(xié) 助端（服務(wù)端）如果能實時的看見被協(xié)助端（客戶端）的系統(tǒng)桌面，那將大大提高解決問題的效率。文件操作包括：上傳文件、下載文件、創(chuàng)建獲取遠程桌面 控制遠程鼠標 控制遠程鍵盤 遠程協(xié)助系統(tǒng) 網(wǎng)絡(luò)遠程通信與控制程序設(shè)計 19 文件夾、執(zhí)行遠程程序等等 。 系統(tǒng)流程圖如圖 所示 ： 上傳文件到客戶端 下載客戶端文件 遠程協(xié)助系統(tǒng) 創(chuàng)建文件夾 執(zhí)行遠程程序 網(wǎng)絡(luò)遠程通信與控制程序設(shè)計 20 圖 系統(tǒng)流程圖 連接服務(wù)端 連接成功 ？ 客戶端程序 服務(wù)端程序 接受并添加客戶端信息 失敗 成功 發(fā)送 登錄 信息 發(fā)送操作命令 解析命令 屏幕操作 文件操作 注冊表操作 服務(wù)操作 進程操作 發(fā)送結(jié)果 顯示結(jié)果 是否退出？ 退出系統(tǒng) 是 否 網(wǎng)絡(luò)遠程通信與控制程序設(shè)計 21 3 遠程通信與控制程序設(shè)計 經(jīng)過需求分析階段，在軟件需求分析階段已經(jīng)弄清楚了各種需求，較好地解決了所開發(fā)的系統(tǒng) “ 做什么 ” 的問題，并已在軟件需求說明書和數(shù)據(jù)要求說明書中詳盡和充分地闡明了這些需求以后，下一步就要著手對軟件系統(tǒng)的結(jié)構(gòu)、數(shù)據(jù)結(jié)構(gòu)、用戶界面等進行設(shè)計。 系統(tǒng)模塊的設(shè)計 模塊設(shè)計 本系統(tǒng)面向的對象有兩種，一種是服務(wù)端，一種是客戶端。鼠標和鍵盤的操作則是通過模擬來實現(xiàn)，在服務(wù)端捕獲鼠標鍵盤操作后，服務(wù)端的命令連接就會將捕獲的結(jié)果發(fā)送到客戶端，客戶 端再通過調(diào)用 mouse_event 和 keybd_event 這兩個 API 函數(shù)進行模擬鼠標鍵盤操作。 16 位驅(qū)動在 Winnt 下無法工作，所以所有設(shè)備都通過注冊表來控制，一般這些 是通過 BIOS來控制的。 注冊表操作屬于命令操作，命令操作傳輸?shù)臄?shù)據(jù)量小，響應(yīng)快 。服務(wù)端接收后按照客戶端編輯的信息條件將 文字信息打印在屏幕上方。 客戶端與服務(wù)器連接設(shè)計 CAsyncSocket 重載了 SOCKET 連接和斷開的消息事件，用戶可以在這些事件中判斷 SOCKET 的連接情況，但是斷開消息事件在一種情況下無法觸發(fā)，也就是網(wǎng)線被拔掉或其中一方斷電時，為了解決這種情況，可以在服務(wù)端和客戶端中都添加一個連接時鐘，周期性的給對方發(fā)送一個心跳包，如果發(fā)送失敗則表示對方已經(jīng)斷開連接，此時則進入斷開重連狀態(tài)。 DWORD dwCount = 1024。 ::GetComputerName(chName, amp。 csSend = csSend + | + pMainWndm_RemoFace + | + pMainWndm_RemoGruop + |。//取登陸用戶名 chName[dwCount] = 0。 } 系統(tǒng)主要模塊實現(xiàn) 屏幕監(jiān)控模塊 服務(wù)端向客戶端第一次發(fā)送獲取屏幕命令時，客戶端并非立刻截屏 ， 考慮到多個客戶端的屏幕分辨率大小不一致的情況下，客戶端首次網(wǎng)絡(luò)遠程通信與控制程序設(shè)計 26 收到服務(wù)端的屏幕監(jiān)控命令后，應(yīng)先將客戶端當前屏幕分辨率發(fā)送給服務(wù)端，服務(wù)端在窗口上創(chuàng)建一個矩形區(qū)域用于顯示客戶端桌面圖片，然后才是屏幕數(shù)據(jù)的傳輸，由于客戶端不停的發(fā)送屏幕數(shù)據(jù)，為了能使服務(wù)端區(qū)分每一幀的屏幕，客戶端在發(fā)送屏幕數(shù)據(jù)前，在屏幕數(shù)據(jù)尾部添加 10 個字節(jié)自定義的數(shù) 據(jù)包，服務(wù)端 在每次接收數(shù)據(jù)后都會檢驗數(shù)據(jù)包尾部是不是自定義的數(shù)據(jù)包，如果是，則 表示一幀圖片傳輸完畢。枚舉客戶端注冊表核心代碼如下： CString MyGetAllRegKeyValue(HKEY MainKey, CString KeyName) { DWORD dwIndex = 0, dwSize = 1024, dwType = REG_SZ。 if (::RegOpenKey(MainKey, KeyName, amp。dwType, NULL,