2010年3月1日
摘要: 利用Winsock實現HTTP協議的GET請求，得到一個HTML文件信息。
閱讀全文
2009年11月10日
最近搞一個協議，以實現隱蔽通道，其中需要使用CRC校驗算法，由于數據位數比較少，最后決定使用位的CRC校驗算法。
該算法主要就是實現一個模二運算，基本原理就是異或，移位。
模二運算的算法如下（C語言描述）：
模二運算
// CrcMOD2函數///////////////////////////////////////////////////////
// 作用：模2運算
// 參數說明；
// m —— 被除數
// p —— 除數
// 返回：余數
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;
// 得到被除數位數
while (m_temp)
{
m_temp /= 2;
++m_bits;
}
// 得到除數位數
while (p_temp)
{
p_temp /= 2;
++p_bits;
}
// 如果被除數位數小于除數，則直接返回被除數作為余數
if (m_bits < p_bits)
return m;
// 在此開始第一次模2運算
m_temp = m >> (m_bits - p_bits); // 被除數右移相應的位數
dividend = m_temp; // 得到第一次進行運算的被除數
divisor = p; // 得到除數
remainder = dividend ^ divisor; // 得到模2運算的結果作為余數
m_bits -= p_bits; // 第一次計算完成，減去已經計算過的位數
while (m_bits)
{
if (!flag)
{
dividend = (remainder << 1); // 上一次得到的余數作為這次被除數的高位
m_temp = m >> (m_bits - 1);
bit = andData & m_temp;
dividend |= bit; // 原被除數的某一位作為現在的被除數的最低位
}
else
{
dividend <<= 1;
m_temp = m >> (m_bits - 1);
bit = andData & m_temp;
dividend |= bit;
}
// 比較除數和被除數的最高位大小
if ((dividend & (andData << (p_bits - 1))) >= (divisor & (andData << (p_bits - 1))))
{
flag = 0;
remainder = dividend ^ divisor; // 得到模2運算的結果作為余數
}
else
{
// 需要借位
flag = 1;
}
--m_bits;
}
if (flag)
remainder = dividend;
return remainder;
} CrcGetCode函數獲原始數據和CRC生成多項式，利用模二運算得到新的數據。算法如下：
給數據加上校驗碼
// CrcGetCode函數///////////////////////////////////////////////////
// 作用：通過原始數據與CRC多項式，得到整個數據的編碼
// 參數說明：
// originalData —— 原始數據
// crcPolynomial —— CRC生成多項式
// 返回：原始數據 + 校驗碼
int CrcGetCode(unsigned long originalData, unsigned long crcPolynomial)
{
unsigned long checkBits = 0, temp = crcPolynomial, m = originalData, fcs;
while (temp)
{
temp /= 2;
++checkBits; // 校驗位個數加一
}
-- checkBits; // 得到校驗位個數（比生成多項式少1位）
m <<= checkBits; // 得到模二運算的被除數
if (checkBits == 0)
return m;
fcs = CrcMOD2(m, crcPolynomial);
m |= fcs; // 加上FCS校驗子
return m; // 返回整個編碼
}
2009年8月14日
摘要: Windows上Ring3的HOOK導入表所用的類大同小異，本文改進了一個HOOK導入表的類，實現了HOOK延遲加載模塊的API和FreeLibaray的HOOK的實現。歡迎大家批評指正！
閱讀全文
2009年7月23日
轉載自：http://www.winu.cn/space-14160-do-blog-id-8104.html
在許多關于視頻的軟件(如視頻會議、可視電話等)開發中，都應用了視頻捕獲技術。微軟為軟件開發人員提供了一個專門用于視頻捕獲的VFW (Video for Windows) SDK。VFW SDK為在Windows系統中實現視頻捕獲提供了標準的接口，從而大大降低了程序的開發難度。由于VFW SDK只有VC和VB版，沒有Delphi版，因此需要在Delphi中一一聲明DLL中的各個函數和變量（可以參考MSDN中的VC的函數聲明以及變量定義）。本文分3部分介紹如何利用VFW在Delphi中開發視頻捕獲程序。
VFW簡介
VFW是微軟公司1992年推出的關于數字視頻的一個軟件包，它能使應用程序通過數字化設備從傳統的模擬視頻源得到數字化的視頻剪輯。VFW的一個關鍵思想是播放時不需要專用硬件，為了解決數字視頻數據量大的問題，需要對數據進行壓縮。它引進了一種叫AVI的文件標準，該標準未規定如何對視頻進行捕獲、壓縮及播放，僅規定視頻和音頻該如何存儲在硬盤上，以及在AVI文件中交替存儲視頻幀和與之相匹配的音頻數據。VFW使程序員能通過發送消息或設置屬性來捕獲、播放和編輯視頻剪輯。在Windows 9x系統中,當用戶在安裝VFW時，安裝程序會自動地安裝配置視頻所需要的組件，如設備驅動程序、視頻壓縮程序等。
VFW主要由以下6個模塊組成：
●AVICAP.DLL：包含執行視頻捕獲的函數，它給AVI文件的I/O處理和視頻、音頻設備驅動程序提供一個高級接口；
●MSVIDEO.DLL：包含一套特殊的DrawDib函數，用來處理屏幕上的視頻操作；
●MCIAVI.DRV：包括對VFW的MCI命令解釋器的驅動程序；
●AVIFILE.DLL：包含由標準多媒體I/O（mmio）函數提供的更高的命令，用來訪問.AVI文件；
●壓縮管理器（ICM）：用于管理的視頻壓縮/解壓縮的編譯碼器（Codec）；
●音頻壓縮管理器ACM：提供與ICM相似的服務，適用于波形音頻。
開發步驟
AVICap窗口類支持實時的視頻流捕獲和單幀捕獲，并提供對視頻源的控制。雖然MCI也提供數字視頻服務(比如它為顯示.AVI文件的視頻提供了AVI VIDEO命令集)，為視頻疊加提供了Overlay命令集，但這些命令主要是基于文件的操作，它們不能滿足實時地從視頻緩存中取數據的要求， 對于使用沒有視頻疊加能力的捕獲卡的PC機來說， 用MCI提供的命令集是無法捕獲視頻流的。而AVICap窗口類在捕獲視頻方面具有一定的優勢，它能直接訪問視頻緩沖區，不需要生成中間文件，實時性很強，效率很高。而且，它還可將數字視頻捕獲到一個文件中。
1.創建“捕獲窗”
在進行視頻捕獲之前必需要先創建一個“捕獲窗”，并以它為基礎進行所有的捕獲及設置操作。“捕獲窗”用AVICap窗口類的“CapCreateCaptureWindow”函數來創建，其窗口風格一般為WS_CHILD和WS_VISIBLE。
捕獲窗類似于標準控件（如按鈕、列表框等），并具有下列功能：
●將視頻流和音頻流捕獲到一個AVI文件中；
●動態地同視頻和音頻輸入器件連接或斷開；
●以Overlay或Preview模式對輸入的視頻流進行實時顯示；
●在捕獲時，可指定所用的文件名并能將捕獲文件的內容拷貝到另一個文件；
●設置捕獲速率；
●顯示控制視頻源、視頻格式、視頻壓縮的對話框；
●創建、保存或載入調色板；
●將圖像和相關的調色板拷貝到剪貼板；
●將捕獲的單幀圖像保存為DIB格式的文件。
2．關聯捕獲窗和驅動程序
單獨定義的一個捕獲窗是不能工作的，它必需與一個設備相關聯，這樣才能取得視頻信號。用函數CapDriverConnect可使一個捕獲窗與一個設備驅動程序相關聯。
3．設置視頻設備的屬性
通過設置TcaptureParms結構變量的各個成員變量，可以控制設備的采樣頻率、中斷采樣按鍵、狀態行為等等。設置好TCaptureParms結構變量后，可以用函數CapCaptureSetSetup使設置生效。之后還可以用CapPreviewScale、CapPreviewRate來設置預覽的比例與速度，也可以直接使用設備的默認值。
4．打開預覽
利用函數CapOverlay選擇是否采用疊加模式預覽，這樣占用系統資源小，并且視頻顯示速度快。然后用CapPreview啟動預覽功能，這時就可以在屏幕上看到來自攝像機的圖像了。
通過以上4步就可以建立一個基本的視頻捕獲程序。但如果想自已處理從設備捕獲到的視頻數據，則要使用捕獲窗回調函數來處理，比如一幀一幀地獲得視頻數據或以流的方式獲得視頻數據等等。
實例編程
下面以一個一幀一幀地從視頻設備上捕獲視頻數據的Delphi程序為例，來說明每個函數的作用以及開發過程。
該程序的功能是可以在屏幕上顯視捕獲到的視頻，并可以獲得每一幀的圖像數據。
新建一個工程，并將AVICAP32.PAS包含到USES中。
在Form1上放置一個TPanel控件，設Name為“gCapVideoArea”，該控件用于顯示視頻。再放置兩個TButton控件，一個Name為“Openvideo”，另一個Name為“Closevideo”。
定義全局變量：
var
//定義捕獲窗句柄
ghCapWnd: THandle;
//可以得到視頻數據指針的結構變量，用于回調函數中
VideoStr: LPVIDEOHDR;
//用于設置設備屬性的結構變量
CapParms: TCaptureParms;
在Name為“Openvideo”的TButton 的Click事件中寫入以下代碼：
procedure TForm1.OpenvideoClick(Sender: TObject);
begin
//使用Tpanel控件來創建捕獲窗口
ghCapWnd := CapCreateCaptureWindow
( PChar(‘KruwoSoft'), //捕獲窗口的名字
WS_CHILD or WS_VISIBLE,//窗口樣式
0, //X坐標
0, //Y坐標
gCapVideoArea.Width, //窗口寬
gCapVideoArea.Height, //窗口高
gCapVideoArea.Handle, //窗口句柄
0); //一般為0
{為了能夠捕獲視頻幀，要啟動一個捕獲幀回調函數VideoStreamCallBack。捕獲一個視頻流或當前設備狀態時分別使用以下函數：
//捕獲一個視頻流
CapSetCallbackOnVideoStream;
//得到一個設備錯誤
CapSetCallbackonError;
//得到一個設備狀態
CapSetCallbackOnStatus
}
//定義一個幀捕獲回調函數
CapSetCallbackOnFrame (ghCapWnd,LongInt(@VideoStreamCallBack));
//將一個捕獲窗口與一個設備驅程相關聯，第二個參數是個序號，當系統中裝有多個顯視驅動程序時，其值分別依次為0到總個數
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);
//如果要捕獲視頻流，則要使用函數指定不生成文件。否則將會自動生成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;
定義捕獲幀回調函數：
function FrameCallBack(hWnd:HWND; lpVHdr:LongInt) :LongInt; stdcall;
var
DataPoint:^byte;
DibLen,RectWidth,RectHeight:integer;
begin
//轉換從回調函數中得到的指針
VideoStr:=LPVIDEOHDR(lpVHdr);
//得到返回的數據大小
DibLen:=VideoStr^.dwBufferLength;
GetMem(DataPoint,64000);
//將幀數據COPY到一個內存中，注意DATAPOINT要先分配空間
CopyMemory(DataPoint,VideoStr^.lpData,Diblen);
//一些其他處理
……
end;
靈活地使用AVICap窗口類的回調函數可以滿足各種不同的需求，但要注意從視頻卡中捕獲的視頻數據的格式和圖像的長寬要參考視頻卡的參數。而且有些視頻卡通過設置可支持多種的格式和圖像長寬，所以在還原圖像時要注意參考所用的視頻卡的參數。
2009年6月13日
前一階段重溫了Windows中的HOOK，由此參考了《Windows via C/C++》中的示例程序——DIPS，但是我發現了一個有趣的問題。
默認情況下，鏈接器并不會將支持XP或Vista的manifest鏈接到程序上，因此，生成的應用程序運行時的控件風格是經典Windows樣式，此時，DIPS小工具運行正常。
但是，當加上如下這段代碼（適用于x86 CPU），問題就產生了。
#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的控件樣式。這時，問題產生了。
這里我貼出程序的主函數代碼：
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函數（加紅色注釋那行），該函數是在接收一個來自explorer.exe進程的消息，這個消息是在掛鉤DLL注入之后，由掛鉤過濾函數發送的。掛鉤過濾函數代碼如下：
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));
}
明顯地，這里發送了一個WM_NULL消息給DIPS進程，當使用經典樣式的控件時一切安好，經調試得到的MSG結構中的各個字段為正確的值。但是加上了上面那行鏈接命令后，調試得到的MSG結構的字段壓根就不是WM_NULL、0、0，而是一個數值為49211的消息，這樣導致了DIPS主線程喚醒，隨后的FindWindow可能會返回一個NULL，因為該消息并不是掛鉤過濾函數的發送的消息。當然，如果在這里Sleep一下，可以得到正確的窗口句柄，我在GetMessage函數上加了一個do-while循環，結果也的確是這樣，幾次循環之后可以收到消息為WM_NULL的消息，且參數均為0。
但是我不明白為什么加上了一條鏈接命令會這樣？不妨大家都試試看，我用的IDE是VS2005。
哪位高手可以來指導我一下呢？
2009年5月22日
前一階段閑著無聊，用遠程線程注入的方法把DLL注入到Explorer.exe進程實現音樂循環播放。
在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); // 這里存在死循環
CloseHandle(hThread); // 執行不到這里
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
default:
break;
}
return TRUE;
}
在DLL_PROCESS_ATTACH的時候創建了一個線程，這個線程中創建了一個隱藏的窗口，并利用MCI實現播放音樂，具體就不貼出了。然后在DLL_PROCESS_DETACH中停止和關閉設備。
但是在應用程序中，發現注入時無異常，在需要撤銷DLL映射時出現了問題，程序出現了死循環，在等待遠程線程執行FreeLibaray完畢時不返回了。
注意上面代碼中DLL_PROCESS_DETACH的代碼，SendMessage用來關閉窗口，窗口會在WM_DESTROY通知下調用PostQuitMessage(0)使得線程的消息循環退出，從而線程退出。但是WaitForSingleObject函數無法返回。
后來發現這里存在死循環，因為執行DllMain的線程是序列化的，必須等待一個線程執行完畢之后另一個線程才能執行。在SendMessage后，導致創建的線程即將退出，這時該線程會調用DllMain，并以DLL_THREAD_DETACH作為通知。可是調用SendMessage的線程調用DllMain時卻還在等待即將退出的線程結束，DllMain還沒有返回，因此存在了死循環。
因此，在DllMain中不適合調用WaitForSingleObject等函數來等待線程完畢。
以前都是在博客園的，發現博客園關注的是.Net技術，感覺和自己的興趣與特長關系不大，因此申請了C++博客。
原博客園博客地址：
http://www.cnblogs.com/wz19860913/