Error

首先要对源码包里边的INSTALL.W32不恐惧，然后要明白openssl在windows上的编译对perl依赖

其次 no-asm 这个选项记住就好。。。


通过configure以后的代码应该是可以直接用vc编译的，有时间了给整理出一个cmake版本来，，，

使用CMake生成MFC项目的时候，需要用到在共享DLL中使用 MFC，需要在CMakeLists文件中加上如下的代码：

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

CMAKE_MFC_FLAG参数的意思是这样解释的：

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})

//发送映射
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表示准备加密的数据desData表示加密后的数据，sendMap表示发送Map，recvMap表示接收Map；
就以上代码中恒有:
推导：
if desData == sendMap[srcData + offset]
then srcData == recvMap[desData] - offset
这个公式可以自己取一个[0, 255]之间的值，带到上面两个map中去算，，，
分析：
BYTE可能的值是0到255，正好是map的索引。
sendMap提供把实际值变成recvMap的索引的能力。
recvMap提供把recvMap索引还原成真实值的能力。
offset的引入是为了加强破解难度，唯一可能疑惑的问题是BYTE溢出，这个可以参考计算机组成原理前几章。
我们可以这样山寨：
class CSendMapper;
class CRecvMapper;
很显然sendMap是和CSendMapper类紧耦合的，recvMapper和CRecvMapper类紧耦合
所以：
class CSendMapper
  ;
class CRecvMapper
  static const BYTE[256] ms_recvMap;
接下来是offset，在网狐的代码中每次都有如下操作：m_cbSendRound += 3;
所以offset是和Mapper对象耦合的，同时也是上下文相关的，这样也倒置mapper是上下文相关的。
class CSendMapper
  static const BYTE[256] ms_sendMap;
  ;
class CRecvMapper
  static const BYTE[256] ms_recvMap;
  BYTE m_btOffset;

这样，只要是offset匹配的recv和send协作就能实现数据加解映射了，，，

最后的测试代码如下（MAP函数被实现的时候改了，返回值的做法写起来是方便了，但是优化的时候比较麻烦）：

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.熟悉程度不够，学习曲线比较陡峭，直接用有可能失控

3.实现太过复杂，还需要mpl库的支持

4.如果使用，iostreams将成为底层，整个项目都会对其依赖，有风险

5.说白了，还是能力不够，不过了解了一些iostreams归纳出来的concepts也是非常有收货。

6.网上的一句归纳：

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

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: 使用一个character队列，用来输入
    output: 使用一个character队列，用来输出
    bidirectional: 使用两个character队列，分别用来输入、输出
    input-seekable: 使用一个character队列用来输入，包含一个读索引游标
    output-seekable: 使用一个character队列用来输出，包含一个写索引游标
    seekable: 使用一个character队列用来输入输出，包含一个读/写复用的索引游标
    dual-seekable: 使用一个character队列来输入输出，包含两个索引游标分别用来标识读写
    bidirectional-seekable: 使用两个character队列分别用来输入输出，同时每个队列包含一个各自的索引游标
    *blocking: 如果读请求永远比剩下的character少除了end情况，而且写请求需要的永远比现有的少。那就是一个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应该就了解traits技术（应该是技巧）

<boost/iostreams/traits.hpp>这里是boost::iostream库的traits

还有个模版元函数mod_of

在asio的异步指导思想下，所有的socket io操作都被分解了：

投递请求 –> 响应结果

投递请求是异步IO的发起动作，响应结果是异步IO的结果反馈动作。

具体到代码就是：async系列函数和Functor构成的handler

每一个操作对应一种handler

具体handler来说主要有两种模型：

一种是接收一个error和translateLen，这可个详情可以看文档。

主要能理解async和handler，和选择正确的handler

应该来说，原则上所有有数据传输的handler有应该选择能接收len的Functor，这样控制能力更加精确。

其他的细节有待分析，，，

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

#define BOOST_LIB_DIAGNOSTIC  // 输出会自动链接的lib名字

#define BOOST_ALL_NO_LIB  // 自动链接的开关

直白点说，就是对getaddrinfo()这个函数的适配。抽象点说就是解析器。

细节如下：

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;
}

上面的代码有这么几个类型：

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()需要的参数

boost::asio::ip::tcp::resolver::iterator抽象的是getaddrinfo()的结果

这整个体系是抽象winsock sdk到stl思想

原则上将会在处理完所有的异步请求以后返回，具体内部是某个变量控制的。

可以通过：

boost::asio::io_service io_service;

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

work构造以后会让io_service内部的某个控制变量自增这样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就会一直执行不会返回

...
spWork.reset();// reset会导致内部的work析构，析构以后io_service里边的控制量就会正常。run处理完所有异步请求就会返回了