2010年3月1日
摘要: 利用Winsock實現(xiàn)HTTP協(xié)議的GET請求，得到一個HTML文件信息。
閱讀全文
2009年11月10日
最近搞一個協(xié)議，以實現(xiàn)隱蔽通道，其中需要使用CRC校驗算法，由于數(shù)據(jù)位數(shù)比較少，最后決定使用位的CRC校驗算法。
該算法主要就是實現(xiàn)一個模二運算，基本原理就是異或，移位。
模二運算的算法如下（C語言描述）：
模二運算
// CrcMOD2函數(shù)///////////////////////////////////////////////////////
// 作用：模2運算
// 參數(shù)說明；
// m —— 被除數(shù)
// p —— 除數(shù)
// 返回：余數(shù)
unsigned long CrcMOD2(unsigned long m, unsigned long p)
{
int m_bits = 0, p_bits = 0, a = 1, bit = 0, flag = 0;
unsigned long m_temp = m, p_temp = p;
unsigned long remainder = 0, andData = 0x00000001;
unsigned long dividend, divisor;
// 得到被除數(shù)位數(shù)
while (m_temp)
{
m_temp /= 2;
++m_bits;
}
// 得到除數(shù)位數(shù)
while (p_temp)
{
p_temp /= 2;
++p_bits;
}
// 如果被除數(shù)位數(shù)小于除數(shù)，則直接返回被除數(shù)作為余數(shù)
if (m_bits < p_bits)
return m;
// 在此開始第一次模2運算
m_temp = m >> (m_bits - p_bits); // 被除數(shù)右移相應的位數(shù)
dividend = m_temp; // 得到第一次進行運算的被除數(shù)
divisor = p; // 得到除數(shù)
remainder = dividend ^ divisor; // 得到模2運算的結果作為余數(shù)
m_bits -= p_bits; // 第一次計算完成，減去已經(jīng)計算過的位數(shù)
while (m_bits)
{
if (!flag)
{
dividend = (remainder << 1); // 上一次得到的余數(shù)作為這次被除數(shù)的高位
m_temp = m >> (m_bits - 1);
bit = andData & m_temp;
dividend |= bit; // 原被除數(shù)的某一位作為現(xiàn)在的被除數(shù)的最低位
}
else
{
dividend <<= 1;
m_temp = m >> (m_bits - 1);
bit = andData & m_temp;
dividend |= bit;
}
// 比較除數(shù)和被除數(shù)的最高位大小
if ((dividend & (andData << (p_bits - 1))) >= (divisor & (andData << (p_bits - 1))))
{
flag = 0;
remainder = dividend ^ divisor; // 得到模2運算的結果作為余數(shù)
}
else
{
// 需要借位
flag = 1;
}
--m_bits;
}
if (flag)
remainder = dividend;
return remainder;
} CrcGetCode函數(shù)獲原始數(shù)據(jù)和CRC生成多項式，利用模二運算得到新的數(shù)據(jù)。算法如下：
給數(shù)據(jù)加上校驗碼
// CrcGetCode函數(shù)///////////////////////////////////////////////////
// 作用：通過原始數(shù)據(jù)與CRC多項式，得到整個數(shù)據(jù)的編碼
// 參數(shù)說明：
// originalData —— 原始數(shù)據(jù)
// crcPolynomial —— CRC生成多項式
// 返回：原始數(shù)據(jù) + 校驗碼
int CrcGetCode(unsigned long originalData, unsigned long crcPolynomial)
{
unsigned long checkBits = 0, temp = crcPolynomial, m = originalData, fcs;
while (temp)
{
temp /= 2;
++checkBits; // 校驗位個數(shù)加一
}
-- checkBits; // 得到校驗位個數(shù)（比生成多項式少1位）
m <<= checkBits; // 得到模二運算的被除數(shù)
if (checkBits == 0)
return m;
fcs = CrcMOD2(m, crcPolynomial);
m |= fcs; // 加上FCS校驗子
return m; // 返回整個編碼
}
2009年8月14日
摘要: Windows上Ring3的HOOK導入表所用的類大同小異，本文改進了一個HOOK導入表的類，實現(xiàn)了HOOK延遲加載模塊的API和FreeLibaray的HOOK的實現(xiàn)。歡迎大家批評指正！
閱讀全文
2009年7月23日
轉載自：http://www.winu.cn/space-14160-do-blog-id-8104.html
在許多關于視頻的軟件(如視頻會議、可視電話等)開發(fā)中，都應用了視頻捕獲技術。微軟為軟件開發(fā)人員提供了一個專門用于視頻捕獲的VFW (Video for Windows) SDK。VFW SDK為在Windows系統(tǒng)中實現(xiàn)視頻捕獲提供了標準的接口，從而大大降低了程序的開發(fā)難度。由于VFW SDK只有VC和VB版，沒有Delphi版，因此需要在Delphi中一一聲明DLL中的各個函數(shù)和變量（可以參考MSDN中的VC的函數(shù)聲明以及變量定義）。本文分3部分介紹如何利用VFW在Delphi中開發(fā)視頻捕獲程序。
VFW簡介
VFW是微軟公司1992年推出的關于數(shù)字視頻的一個軟件包，它能使應用程序通過數(shù)字化設備從傳統(tǒng)的模擬視頻源得到數(shù)字化的視頻剪輯。VFW的一個關鍵思想是播放時不需要專用硬件，為了解決數(shù)字視頻數(shù)據(jù)量大的問題，需要對數(shù)據(jù)進行壓縮。它引進了一種叫AVI的文件標準，該標準未規(guī)定如何對視頻進行捕獲、壓縮及播放，僅規(guī)定視頻和音頻該如何存儲在硬盤上，以及在AVI文件中交替存儲視頻幀和與之相匹配的音頻數(shù)據(jù)。VFW使程序員能通過發(fā)送消息或設置屬性來捕獲、播放和編輯視頻剪輯。在Windows 9x系統(tǒng)中,當用戶在安裝VFW時，安裝程序會自動地安裝配置視頻所需要的組件，如設備驅動程序、視頻壓縮程序等。
VFW主要由以下6個模塊組成：
●AVICAP.DLL：包含執(zhí)行視頻捕獲的函數(shù)，它給AVI文件的I/O處理和視頻、音頻設備驅動程序提供一個高級接口；
●MSVIDEO.DLL：包含一套特殊的DrawDib函數(shù)，用來處理屏幕上的視頻操作；
●MCIAVI.DRV：包括對VFW的MCI命令解釋器的驅動程序；
●AVIFILE.DLL：包含由標準多媒體I/O（mmio）函數(shù)提供的更高的命令，用來訪問.AVI文件；
●壓縮管理器（ICM）：用于管理的視頻壓縮/解壓縮的編譯碼器（Codec）；
●音頻壓縮管理器ACM：提供與ICM相似的服務，適用于波形音頻。
開發(fā)步驟
AVICap窗口類支持實時的視頻流捕獲和單幀捕獲，并提供對視頻源的控制。雖然MCI也提供數(shù)字視頻服務(比如它為顯示.AVI文件的視頻提供了AVI VIDEO命令集)，為視頻疊加提供了Overlay命令集，但這些命令主要是基于文件的操作，它們不能滿足實時地從視頻緩存中取數(shù)據(jù)的要求， 對于使用沒有視頻疊加能力的捕獲卡的PC機來說， 用MCI提供的命令集是無法捕獲視頻流的。而AVICap窗口類在捕獲視頻方面具有一定的優(yōu)勢，它能直接訪問視頻緩沖區(qū)，不需要生成中間文件，實時性很強，效率很高。而且，它還可將數(shù)字視頻捕獲到一個文件中。
1.創(chuàng)建“捕獲窗”
在進行視頻捕獲之前必需要先創(chuàng)建一個“捕獲窗”，并以它為基礎進行所有的捕獲及設置操作。“捕獲窗”用AVICap窗口類的“CapCreateCaptureWindow”函數(shù)來創(chuàng)建，其窗口風格一般為WS_CHILD和WS_VISIBLE。
捕獲窗類似于標準控件（如按鈕、列表框等），并具有下列功能：
●將視頻流和音頻流捕獲到一個AVI文件中；
●動態(tài)地同視頻和音頻輸入器件連接或斷開；
●以Overlay或Preview模式對輸入的視頻流進行實時顯示；
●在捕獲時，可指定所用的文件名并能將捕獲文件的內容拷貝到另一個文件；
●設置捕獲速率；
●顯示控制視頻源、視頻格式、視頻壓縮的對話框；
●創(chuàng)建、保存或載入調色板；
●將圖像和相關的調色板拷貝到剪貼板；
●將捕獲的單幀圖像保存為DIB格式的文件。
2．關聯(lián)捕獲窗和驅動程序
單獨定義的一個捕獲窗是不能工作的，它必需與一個設備相關聯(lián)，這樣才能取得視頻信號。用函數(shù)CapDriverConnect可使一個捕獲窗與一個設備驅動程序相關聯(lián)。
3．設置視頻設備的屬性
通過設置TcaptureParms結構變量的各個成員變量，可以控制設備的采樣頻率、中斷采樣按鍵、狀態(tài)行為等等。設置好TCaptureParms結構變量后，可以用函數(shù)CapCaptureSetSetup使設置生效。之后還可以用CapPreviewScale、CapPreviewRate來設置預覽的比例與速度，也可以直接使用設備的默認值。
4．打開預覽
利用函數(shù)CapOverlay選擇是否采用疊加模式預覽，這樣占用系統(tǒng)資源小，并且視頻顯示速度快。然后用CapPreview啟動預覽功能，這時就可以在屏幕上看到來自攝像機的圖像了。
通過以上4步就可以建立一個基本的視頻捕獲程序。但如果想自已處理從設備捕獲到的視頻數(shù)據(jù)，則要使用捕獲窗回調函數(shù)來處理，比如一幀一幀地獲得視頻數(shù)據(jù)或以流的方式獲得視頻數(shù)據(jù)等等。
實例編程
下面以一個一幀一幀地從視頻設備上捕獲視頻數(shù)據(jù)的Delphi程序為例，來說明每個函數(shù)的作用以及開發(fā)過程。
該程序的功能是可以在屏幕上顯視捕獲到的視頻，并可以獲得每一幀的圖像數(shù)據(jù)。
新建一個工程，并將AVICAP32.PAS包含到USES中。
在Form1上放置一個TPanel控件，設Name為“gCapVideoArea”，該控件用于顯示視頻。再放置兩個TButton控件，一個Name為“Openvideo”，另一個Name為“Closevideo”。
定義全局變量：
var
//定義捕獲窗句柄
ghCapWnd: THandle;
//可以得到視頻數(shù)據(jù)指針的結構變量，用于回調函數(shù)中
VideoStr: LPVIDEOHDR;
//用于設置設備屬性的結構變量
CapParms: TCaptureParms;
在Name為“Openvideo”的TButton 的Click事件中寫入以下代碼：
procedure TForm1.OpenvideoClick(Sender: TObject);
begin
//使用Tpanel控件來創(chuàng)建捕獲窗口
ghCapWnd := CapCreateCaptureWindow
( PChar(‘KruwoSoft'), //捕獲窗口的名字
WS_CHILD or WS_VISIBLE,//窗口樣式
0, //X坐標
0, //Y坐標
gCapVideoArea.Width, //窗口寬
gCapVideoArea.Height, //窗口高
gCapVideoArea.Handle, //窗口句柄
0); //一般為0
{為了能夠捕獲視頻幀，要啟動一個捕獲幀回調函數(shù)VideoStreamCallBack。捕獲一個視頻流或當前設備狀態(tài)時分別使用以下函數(shù)：
//捕獲一個視頻流
CapSetCallbackOnVideoStream;
//得到一個設備錯誤
CapSetCallbackonError;
//得到一個設備狀態(tài)
CapSetCallbackOnStatus
}
//定義一個幀捕獲回調函數(shù)
CapSetCallbackOnFrame (ghCapWnd,LongInt(@VideoStreamCallBack));
//將一個捕獲窗口與一個設備驅程相關聯(lián)，第二個參數(shù)是個序號，當系統(tǒng)中裝有多個顯視驅動程序時，其值分別依次為0到總個數(shù)
CapDriverConnect(ghCapWnd, 0);
//設置設備屬性的結構變量
CapParms.dwRequestMicroSecPerFrame:=40000;
CapParms.fLimitEnabled := FALSE;
CapParms.fCaptureAudio := FALSE; // NO Audio
CapParms.fMCIControl := FALSE;
CapParms.fYield := TRUE;
CapParms.vKeyAbort := VK_ESCAPE;
CapParms.fAbortLeftMouse := FALSE;
CapParms.fAbortRightMouse := FALSE;
//使設置生效
CapCaptureSetSetup(ghCapWnd,LongInt(@CapParms),sizeof(TCAPTUREPARMS));
//設置預覽時的比例
CapPreviewScale(ghCapWnd, 1);
//設置預覽時的幀頻率
CapPreviewRate(ghCapWnd,66);
//如果要捕獲視頻流，則要使用函數(shù)指定不生成文件。否則將會自動生成AVI文件
CapCaptureSequenceNoFile(ghCapWnd);
//指定是否使用疊加模式，使用為1，否則為0
CapOverlay(ghCapWnd, 1);
//打開預覽
CapPreview(ghCapWnd, 1);
end;
在Name為“Closevideo”的TButton 的Click事件中寫入以下代碼：
procedure TForm1.ClosevideoClick(Sender: TObject);
begin
//停止捕獲
capCaptureAbort(ghCapWnd);
//將捕獲窗同驅動器斷開
capDriverDisconnect(ghCapWnd);
end;
定義捕獲幀回調函數(shù)：
function FrameCallBack(hWnd:HWND; lpVHdr:LongInt) :LongInt; stdcall;
var
DataPoint:^byte;
DibLen,RectWidth,RectHeight:integer;
begin
//轉換從回調函數(shù)中得到的指針
VideoStr:=LPVIDEOHDR(lpVHdr);
//得到返回的數(shù)據(jù)大小
DibLen:=VideoStr^.dwBufferLength;
GetMem(DataPoint,64000);
//將幀數(shù)據(jù)COPY到一個內存中，注意DATAPOINT要先分配空間
CopyMemory(DataPoint,VideoStr^.lpData,Diblen);
//一些其他處理
……
end;
靈活地使用AVICap窗口類的回調函數(shù)可以滿足各種不同的需求，但要注意從視頻卡中捕獲的視頻數(shù)據(jù)的格式和圖像的長寬要參考視頻卡的參數(shù)。而且有些視頻卡通過設置可支持多種的格式和圖像長寬，所以在還原圖像時要注意參考所用的視頻卡的參數(shù)。
2009年6月13日
前一階段重溫了Windows中的HOOK，由此參考了《Windows via C/C++》中的示例程序——DIPS，但是我發(fā)現(xiàn)了一個有趣的問題。
默認情況下，鏈接器并不會將支持XP或Vista的manifest鏈接到程序上，因此，生成的應用程序運行時的控件風格是經(jīng)典Windows樣式，此時，DIPS小工具運行正常。
但是，當加上如下這段代碼（適用于x86 CPU），問題就產(chǎn)生了。
#pragma comment(linker, "/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")
這意味著鏈接器將會把新的XP或Vista的manifest鏈接到程序上，使應用程序具有XP或Vista的控件樣式。這時，問題產(chǎn)生了。
這里我貼出程序的主函數(shù)代碼：
int WINAPI _tWinMain(HINSTANCE hInstExe, HINSTANCE, PTSTR pszCmdLine, int) {
// Convert command-line character to uppercase.
CharUpperBuff(pszCmdLine, 1);
TCHAR cWhatToDo = pszCmdLine[0];
if ((cWhatToDo != TEXT('S')) && (cWhatToDo != TEXT('R'))) {
// An invalid command-line argument; prompt the user.
cWhatToDo = 0;
}
if (cWhatToDo == 0) {
// No command-line argument was used to tell us what to
// do; show usage dialog box and prompt the user.
switch (DialogBox(hInstExe, MAKEINTRESOURCE(IDD_DIPS), NULL, Dlg_Proc)) {
case IDC_SAVE:
cWhatToDo = TEXT('S');
break;
case IDC_RESTORE:
cWhatToDo = TEXT('R');
break;
}
}
if (cWhatToDo == 0) {
// The user doesn't want to do anything.
return(0);
}
// The Desktop ListView window is the grandchild of the ProgMan window.
HWND hWndLV = GetFirstChild(GetFirstChild(
FindWindow(TEXT("ProgMan"), NULL)));
chASSERT(IsWindow(hWndLV));
// Set hook that injects our DLL into the Explorer's address space. After
// setting the hook, the DIPS hidden modeless dialog box is created. We
// send messages to this window to tell it what we want it to do.
chVERIFY(SetDIPSHook(GetWindowThreadProcessId(hWndLV, NULL)));
// Wait for the DIPS server window to be created.
MSG msg;
GetMessage(&msg, NULL, 0, 0); // 請注意這里
// Find the handle of the hidden dialog box window.
HWND hWndDIPS = FindWindow(NULL, TEXT("Wintellect DIPS"));
// Make sure that the window was created.
chASSERT(IsWindow(hWndDIPS));
// Tell the DIPS window which ListView window to manipulate
// and whether the items should be saved or restored.
BOOL bSave = (cWhatToDo == TEXT('S'));
SendMessage(hWndDIPS, WM_APP, (WPARAM) hWndLV, bSave);
// Tell the DIPS window to destroy itself. Use SendMessage
// instead of PostMessage so that we know the window is
// destroyed before the hook is removed.
SendMessage(hWndDIPS, WM_CLOSE, 0, 0);
// Make sure that the window was destroyed.
chASSERT(!IsWindow(hWndDIPS));
// Unhook the DLL, removing the DIPS dialog box procedure
// from the Explorer's address space.
SetDIPSHook(0);
return(0);
}
看到上面代碼中的GetMessage函數(shù)（加紅色注釋那行），該函數(shù)是在接收一個來自explorer.exe進程的消息，這個消息是在掛鉤DLL注入之后，由掛鉤過濾函數(shù)發(fā)送的。掛鉤過濾函數(shù)代碼如下：
LRESULT WINAPI GetMsgProc(int nCode, WPARAM wParam, LPARAM lParam) {
static BOOL bFirstTime = TRUE;
if (bFirstTime) {
// The DLL just got injected.
bFirstTime = FALSE;
// Uncomment the line below to invoke the debugger
// on the process that just got the injected DLL.
// ForceDebugBreak();
// Create the DIPS Server window to handle the client request.
CreateDialog(g_hInstDll, MAKEINTRESOURCE(IDD_DIPS), NULL, Dlg_Proc);
// Tell the DIPS application that the server is up
// and ready to handle requests.
PostThreadMessage(g_dwThreadIdDIPS, WM_NULL, 0, 0);
}
return(CallNextHookEx(g_hHook, nCode, wParam, lParam));
}
明顯地，這里發(fā)送了一個WM_NULL消息給DIPS進程，當使用經(jīng)典樣式的控件時一切安好，經(jīng)調試得到的MSG結構中的各個字段為正確的值。但是加上了上面那行鏈接命令后，調試得到的MSG結構的字段壓根就不是WM_NULL、0、0，而是一個數(shù)值為49211的消息，這樣導致了DIPS主線程喚醒，隨后的FindWindow可能會返回一個NULL，因為該消息并不是掛鉤過濾函數(shù)的發(fā)送的消息。當然，如果在這里Sleep一下，可以得到正確的窗口句柄，我在GetMessage函數(shù)上加了一個do-while循環(huán)，結果也的確是這樣，幾次循環(huán)之后可以收到消息為WM_NULL的消息，且參數(shù)均為0。
但是我不明白為什么加上了一條鏈接命令會這樣？不妨大家都試試看，我用的IDE是VS2005。
哪位高手可以來指導我一下呢？
2009年5月22日
前一階段閑著無聊，用遠程線程注入的方法把DLL注入到Explorer.exe進程實現(xiàn)音樂循環(huán)播放。
在DLL中的代碼是這樣的：
BOOL WINAPI DllMain(HINSTANCE hInstDll, DWORD fdwReason, PVOID fImpLoad)
{
static HANDLE hThread;
static DWORD dwThreadId;
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
g_hInstDll = hInstDll;
hThread = BEGINTHREADEX(NULL, 0, ThreadProc, (PVOID)hInstDll, 0, &dwThreadId);
if (hThread == NULL)
{
return FALSE;
}
break;
case DLL_PROCESS_DETACH:
SendMessage(g_hWnd, WM_CLOSE, 0, 0);
WaitForSingleObject(hThread, INFINITE); // 這里存在死循環(huán)
CloseHandle(hThread); // 執(zhí)行不到這里
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
default:
break;
}
return TRUE;
}
在DLL_PROCESS_ATTACH的時候創(chuàng)建了一個線程，這個線程中創(chuàng)建了一個隱藏的窗口，并利用MCI實現(xiàn)播放音樂，具體就不貼出了。然后在DLL_PROCESS_DETACH中停止和關閉設備。
但是在應用程序中，發(fā)現(xiàn)注入時無異常，在需要撤銷DLL映射時出現(xiàn)了問題，程序出現(xiàn)了死循環(huán)，在等待遠程線程執(zhí)行FreeLibaray完畢時不返回了。
注意上面代碼中DLL_PROCESS_DETACH的代碼，SendMessage用來關閉窗口，窗口會在WM_DESTROY通知下調用PostQuitMessage(0)使得線程的消息循環(huán)退出，從而線程退出。但是WaitForSingleObject函數(shù)無法返回。
后來發(fā)現(xiàn)這里存在死循環(huán)，因為執(zhí)行DllMain的線程是序列化的，必須等待一個線程執(zhí)行完畢之后另一個線程才能執(zhí)行。在SendMessage后，導致創(chuàng)建的線程即將退出，這時該線程會調用DllMain，并以DLL_THREAD_DETACH作為通知。可是調用SendMessage的線程調用DllMain時卻還在等待即將退出的線程結束，DllMain還沒有返回，因此存在了死循環(huán)。
因此，在DllMain中不適合調用WaitForSingleObject等函數(shù)來等待線程完畢。
以前都是在博客園的，發(fā)現(xiàn)博客園關注的是.Net技術，感覺和自己的興趣與特長關系不大，因此申請了C++博客。
原博客園博客地址：
http://www.cnblogs.com/wz19860913/