Error

首先要對源碼包里邊的INSTALL.W32不恐懼，然后要明白o(hù)penssl在windows上的編譯對perl依賴

其次 no-asm 這個(gè)選項(xiàng)記住就好。。。


通過configure以后的代碼應(yīng)該是可以直接用vc編譯的，有時(shí)間了給整理出一個(gè)cmake版本來，，，

使用CMake生成MFC項(xiàng)目的時(shí)候，需要用到在共享DLL中使用 MFC，需要在CMakeLists文件中加上如下的代碼：

ADD_DEFINITIONS(-D_AFXDLL)
SET(CMAKE_MFC_FLAG 2)
ADD_EXECUTABLE(detect WIN32 ${DIR_SRCS})

CMAKE_MFC_FLAG參數(shù)的意思是這樣解釋的：

To use MFC, the CMAKE_MFC_FLAG variable must be set as follows:

0: Use Standard Windows Libraries
1: Use MFC in a Static Library
2: Use MFC in a Shared DLL

CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

PROJECT(testProject)

FIND_PACKAGE(MFC REQUIRED)

MESSAGE(STATUS "MFC_FOUND: " ${MFC_FOUND})

//發(fā)送映射
const BYTE g_SendByteMap[256]=
{
    0x70,0x2F,0x40,0x5F,0x44,0x8E,0x6E,0x45,0x7E,0xAB,0x2C,0x1F,0xB4,0xAC,0x9D,0x91,
    0x0D,0x36,0x9B,0x0B,0xD4,0xC4,0x39,0x74,0xBF,0x23,0x16,0x14,0x06,0xEB,0x04,0x3E,
    0x12,0x5C,0x8B,0xBC,0x61,0x63,0xF6,0xA5,0xE1,0x65,0xD8,0xF5,0x5A,0x07,0xF0,0x13,
    0xF2,0x20,0x6B,0x4A,0x24,0x59,0x89,0x64,0xD7,0x42,0x6A,0x5E,0x3D,0x0A,0x77,0xE0,
    0x80,0x27,0xB8,0xC5,0x8C,0x0E,0xFA,0x8A,0xD5,0x29,0x56,0x57,0x6C,0x53,0x67,0x41,
    0xE8,0x00,0x1A,0xCE,0x86,0x83,0xB0,0x22,0x28,0x4D,0x3F,0x26,0x46,0x4F,0x6F,0x2B,
    0x72,0x3A,0xF1,0x8D,0x97,0x95,0x49,0x84,0xE5,0xE3,0x79,0x8F,0x51,0x10,0xA8,0x82,
    0xC6,0xDD,0xFF,0xFC,0xE4,0xCF,0xB3,0x09,0x5D,0xEA,0x9C,0x34,0xF9,0x17,0x9F,0xDA,
    0x87,0xF8,0x15,0x05,0x3C,0xD3,0xA4,0x85,0x2E,0xFB,0xEE,0x47,0x3B,0xEF,0x37,0x7F,
    0x93,0xAF,0x69,0x0C,0x71,0x31,0xDE,0x21,0x75,0xA0,0xAA,0xBA,0x7C,0x38,0x02,0xB7,
    0x81,0x01,0xFD,0xE7,0x1D,0xCC,0xCD,0xBD,0x1B,0x7A,0x2A,0xAD,0x66,0xBE,0x55,0x33,
    0x03,0xDB,0x88,0xB2,0x1E,0x4E,0xB9,0xE6,0xC2,0xF7,0xCB,0x7D,0xC9,0x62,0xC3,0xA6,
    0xDC,0xA7,0x50,0xB5,0x4B,0x94,0xC0,0x92,0x4C,0x11,0x5B,0x78,0xD9,0xB1,0xED,0x19,
    0xE9,0xA1,0x1C,0xB6,0x32,0x99,0xA3,0x76,0x9E,0x7B,0x6D,0x9A,0x30,0xD6,0xA9,0x25,
    0xC7,0xAE,0x96,0x35,0xD0,0xBB,0xD2,0xC8,0xA2,0x08,0xF3,0xD1,0x73,0xF4,0x48,0x2D,
    0x90,0xCA,0xE2,0x58,0xC1,0x18,0x52,0xFE,0xDF,0x68,0x98,0x54,0xEC,0x60,0x43,0x0F
};

//接收映射
const BYTE g_RecvByteMap[256]=
{
    0x51,0xA1,0x9E,0xB0,0x1E,0x83,0x1C,0x2D,0xE9,0x77,0x3D,0x13,0x93,0x10,0x45,0xFF,
    0x6D,0xC9,0x20,0x2F,0x1B,0x82,0x1A,0x7D,0xF5,0xCF,0x52,0xA8,0xD2,0xA4,0xB4,0x0B,
    0x31,0x97,0x57,0x19,0x34,0xDF,0x5B,0x41,0x58,0x49,0xAA,0x5F,0x0A,0xEF,0x88,0x01,
    0xDC,0x95,0xD4,0xAF,0x7B,0xE3,0x11,0x8E,0x9D,0x16,0x61,0x8C,0x84,0x3C,0x1F,0x5A,
    0x02,0x4F,0x39,0xFE,0x04,0x07,0x5C,0x8B,0xEE,0x66,0x33,0xC4,0xC8,0x59,0xB5,0x5D,
    0xC2,0x6C,0xF6,0x4D,0xFB,0xAE,0x4A,0x4B,0xF3,0x35,0x2C,0xCA,0x21,0x78,0x3B,0x03,
    0xFD,0x24,0xBD,0x25,0x37,0x29,0xAC,0x4E,0xF9,0x92,0x3A,0x32,0x4C,0xDA,0x06,0x5E,
    0x00,0x94,0x60,0xEC,0x17,0x98,0xD7,0x3E,0xCB,0x6A,0xA9,0xD9,0x9C,0xBB,0x08,0x8F,
    0x40,0xA0,0x6F,0x55,0x67,0x87,0x54,0x80,0xB2,0x36,0x47,0x22,0x44,0x63,0x05,0x6B,
    0xF0,0x0F,0xC7,0x90,0xC5,0x65,0xE2,0x64,0xFA,0xD5,0xDB,0x12,0x7A,0x0E,0xD8,0x7E,
    0x99,0xD1,0xE8,0xD6,0x86,0x27,0xBF,0xC1,0x6E,0xDE,0x9A,0x09,0x0D,0xAB,0xE1,0x91,
    0x56,0xCD,0xB3,0x76,0x0C,0xC3,0xD3,0x9F,0x42,0xB6,0x9B,0xE5,0x23,0xA7,0xAD,0x18,
    0xC6,0xF4,0xB8,0xBE,0x15,0x43,0x70,0xE0,0xE7,0xBC,0xF1,0xBA,0xA5,0xA6,0x53,0x75,
    0xE4,0xEB,0xE6,0x85,0x14,0x48,0xDD,0x38,0x2A,0xCC,0x7F,0xB1,0xC0,0x71,0x96,0xF8,
    0x3F,0x28,0xF2,0x69,0x74,0x68,0xB7,0xA3,0x50,0xD0,0x79,0x1D,0xFC,0xCE,0x8A,0x8D,
    0x2E,0x62,0x30,0xEA,0xED,0x2B,0x26,0xB9,0x81,0x7C,0x46,0x89,0x73,0xA2,0xF7,0x72
};
// MapSend
desData = g_SendByteMap[(BYTE)(srcData+m_cbSendRound)];
m_cbSendRound += 3;
// MapRecv
desData = g_RecvByteMap[cbData] - m_cbRecvRound;
m_cbRecvRound += 3;

映射加密原理分析：
約定srcData表示準(zhǔn)備加密的數(shù)據(jù)desData表示加密后的數(shù)據(jù)，sendMap表示發(fā)送Map，recvMap表示接收Map；
就以上代碼中恒有:
推導(dǎo)：
if desData == sendMap[srcData + offset]
then srcData == recvMap[desData] - offset
這個(gè)公式可以自己取一個(gè)[0, 255]之間的值，帶到上面兩個(gè)map中去算，，，
分析：
BYTE可能的值是0到255，正好是map的索引。
sendMap提供把實(shí)際值變成recvMap的索引的能力。
recvMap提供把recvMap索引還原成真實(shí)值的能力。
offset的引入是為了加強(qiáng)破解難度，唯一可能疑惑的問題是BYTE溢出，這個(gè)可以參考計(jì)算機(jī)組成原理前幾章。
我們可以這樣山寨：
class CSendMapper;
class CRecvMapper;
很顯然sendMap是和CSendMapper類緊耦合的，recvMapper和CRecvMapper類緊耦合
所以：
class CSendMapper
  ;
class CRecvMapper
  static const BYTE[256] ms_recvMap;
接下來是offset，在網(wǎng)狐的代碼中每次都有如下操作：m_cbSendRound += 3;
所以offset是和Mapper對象耦合的，同時(shí)也是上下文相關(guān)的，這樣也倒置mapper是上下文相關(guān)的。
class CSendMapper
  static const BYTE[256] ms_sendMap;
  ;
class CRecvMapper
  static const BYTE[256] ms_recvMap;
  BYTE m_btOffset;

這樣，只要是offset匹配的recv和send協(xié)作就能實(shí)現(xiàn)數(shù)據(jù)加解映射了，，，

最后的測試代碼如下（MAP函數(shù)被實(shí)現(xiàn)的時(shí)候改了，返回值的做法寫起來是方便了，但是優(yōu)化的時(shí)候比較麻煩）：

nf6602::CSendMapper sendMapper;
_el::TBYTE btTem = 0;
sendMapper.SendMap(0, btTem);
if (0x70 != btTem)
{
    std::cout << "sendMapper.SendMap faild!" << std::endl;
}

nf6602::CRecvMapper recvMapper;
btTem = 0;
recvMapper.RecvMap(0, btTem);
if (0x51 != btTem)
{
    std::cout << "recvMapper.RecvMap faild!" << std::endl;
}

//if desData == sendMap[srcData]
//then srcData == recvMap[desData]
for (int i = 0; i < _EL_MAX_TBYTE*10; i++)
{
    _el::TBYTE btSrcData = i;
    _el::TBYTE btDesData = 0;
    sendMapper.SendMap(btSrcData, btTem);
    recvMapper.RecvMap(btTem, btDesData);
    if (btSrcData != btDesData)
    {
        std::cout << "if desData == sendMap[srcData] then srcData == recvMap[desData] faild!" << std::endl;
    }
    else
    {
        int j = 0 ;
    }
}

原因：

1.文檔不夠完善

2.熟悉程度不夠，學(xué)習(xí)曲線比較陡峭，直接用有可能失控

3.實(shí)現(xiàn)太過復(fù)雜，還需要mpl庫的支持

4.如果使用，iostreams將成為底層，整個(gè)項(xiàng)目都會對其依賴，有風(fēng)險(xiǎn)

5.說白了，還是能力不夠，不過了解了一些iostreams歸納出來的concepts也是非常有收貨。

6.網(wǎng)上的一句歸納：

//////////////////////////////////////////////

Device Concepts

The most important Device concepts are these:

• Device: Base for all Device concepts, provides associated character type and category.
• Source: Provides read-only access to a sequence of characters.
• Sink: Provides write-only access to a sequence of characters.
• BidirectionalDevice: Provides access to two separate sequences of characters, one for reading and the other for writing.
• SeekableDevice: Provides read-write access to a single sequence of characters, with a single repositionable read/write head.

Filter Concepts

The most important Filter concepts are these:

• Filter: Base for all Filter concepts, provides associated character type and category.
• InputFilter: Filters characters read from a Source.
• OutputFilter: Filters characters written to a Sink
• BidirectionalFilter: Filters two separate character sequences, one read from a Sink and the other written to a Sink.
• SeekableFilter: Filters a single characters sequence, controlled by a SeekableDevice, providing filtered input, output and random access with a single repositionable read/write head

Optional Behavior

Boost.Iostreams prvides several concepts corresponding to optional behavior that a Filter or Device might implement:

• Blocking: A Device which blocks when it receives a read or write request until all requested characters are available, or until the end of a stream is reached.
• Direct: A Device which provides access to its controlled sequences as regions of memory rather than via a socket-like interface.
• Closable: A Filter or Device which receives notifications immediately before a stream is closed.
• Flushable A Filter or Device which receives notifications when a stream is flushed.
• Localizable: A Filter or Device which receives notifications when the locale of a stream or stream buffer is set using basic_ios::imbue or basic_streambuf::pubimbue.
• Multi-Character: A Filter which provides access to its controlled sequences several characters at a time, via a socket-like interface.
• OptimallyBuffered A Filter or Device which will be fitted with a buffer of custom size if no buffer size is explicitly requested by the user.
• Peekable: A source which allows characters to be put back to the input sequence.
• Pipable: A Filter which can appear in pipelines.

mode（模式？）：
    input: 使用一個(gè)character隊(duì)列，用來輸入
    output: 使用一個(gè)character隊(duì)列，用來輸出
    bidirectional: 使用兩個(gè)character隊(duì)列，分別用來輸入、輸出
    input-seekable: 使用一個(gè)character隊(duì)列用來輸入，包含一個(gè)讀索引游標(biāo)
    output-seekable: 使用一個(gè)character隊(duì)列用來輸出，包含一個(gè)寫索引游標(biāo)
    seekable: 使用一個(gè)character隊(duì)列用來輸入輸出，包含一個(gè)讀/寫復(fù)用的索引游標(biāo)
    dual-seekable: 使用一個(gè)character隊(duì)列來輸入輸出，包含兩個(gè)索引游標(biāo)分別用來標(biāo)識讀寫
    bidirectional-seekable: 使用兩個(gè)character隊(duì)列分別用來輸入輸出，同時(shí)每個(gè)隊(duì)列包含一個(gè)各自的索引游標(biāo)
    *blocking: 如果讀請求永遠(yuǎn)比剩下的character少除了end情況，而且寫請求需要的永遠(yuǎn)比現(xiàn)有的少。那就是一個(gè)blocking。
The Blocking concept does not apply to filters. Instead, filters are required to be blocking-preserving, which means that

a read request never produces fewer characters than requested unless end-of-stream has been reached or unless a read request to a downsteam Source produces fewer characters than requested, and
a write request never consumes fewer characters than requested unless a write request to a downsteam Sink consumes fewer characters than requested.

*如果熟悉stl應(yīng)該就了解traits技術(shù)（應(yīng)該是技巧）

<boost/iostreams/traits.hpp>這里是boost::iostream庫的traits

還有個(gè)模版元函數(shù)mod_of

在asio的異步指導(dǎo)思想下，所有的socket io操作都被分解了：

投遞請求 –> 響應(yīng)結(jié)果

投遞請求是異步IO的發(fā)起動作，響應(yīng)結(jié)果是異步IO的結(jié)果反饋動作。

具體到代碼就是：async系列函數(shù)和Functor構(gòu)成的handler

每一個(gè)操作對應(yīng)一種handler

具體handler來說主要有兩種模型：

一種是接收一個(gè)error和translateLen，這可個(gè)詳情可以看文檔。

主要能理解async和handler，和選擇正確的handler

應(yīng)該來說，原則上所有有數(shù)據(jù)傳輸?shù)膆andler有應(yīng)該選擇能接收len的Functor，這樣控制能力更加精確。

其他的細(xì)節(jié)有待分析，，，

#define BOOST_ALL_DYN_LINK  // 使用dll方式鏈接

#define BOOST_LIB_DIAGNOSTIC  // 輸出會自動鏈接的lib名字

#define BOOST_ALL_NO_LIB  // 自動鏈接的開關(guān)

直白點(diǎn)說，就是對getaddrinfo()這個(gè)函數(shù)的適配。抽象點(diǎn)說就是解析器。

細(xì)節(jié)如下：

boost::asio::ip::tcp::resolver resolver(asioService);
boost::asio::ip::tcp::resolver::query queryEndpoints(boost::asio::ip::host_name(),"80");
boost::asio::ip::tcp::resolver::iterator endpoint_iterator = resolver.resolve(queryEndpoints);
;
for(boost::asio::ip::tcp::resolver::iterator iterNull;
    endpoint_iterator != iterNull;
    endpoint_iterator++)
{
    std::cout << endpoint_iterator->endpoint() << std::endl;
}

上面的代碼有這么幾個(gè)類型：

boost::asio::ip::tcp::resolver

boost::asio::ip::tcp::resolver::query

boost::asio::ip::tcp::resolver::iterator

resolver抽線的是getaddrinfo()動作

boost::asio::ip::tcp::resolver::query抽象的是getaddrinfo()需要的參數(shù)

boost::asio::ip::tcp::resolver::iterator抽象的是getaddrinfo()的結(jié)果

這整個(gè)體系是抽象winsock sdk到stl思想

原則上將會在處理完所有的異步請求以后返回，具體內(nèi)部是某個(gè)變量控制的。

可以通過：

boost::asio::io_service io_service;

boost::asio::io_service::work work(io_service);

work構(gòu)造以后會讓io_service內(nèi)部的某個(gè)控制變量自增這樣run就不會返回了。

可以通過類似這樣的技巧更漂亮的控制：

boost::asio::io_service asioService;
//boost::asio::io_service::work work(asioService);
boost::scoped_ptr<boost::asio::io_service::work> spWork(new boost::asio::io_service::work(asioService));
asioService.run();  // 這樣run就會一直執(zhí)行不會返回

...
spWork.reset();// reset會導(dǎo)致內(nèi)部的work析構(gòu)，析構(gòu)以后io_service里邊的控制量就會正常。run處理完所有異步請求就會返回了