5

Mac 下安装 PHP 扩展 vld & xhprof


最近因为经常离线调试,所以开始重新在本机搭环境,还好 原本就自带了

[515][MacBookPro: /tmp]$ which php
/usr/bin/php
[516][MacBookPro: /tmp]$ php --version
PHP 5.3.3 (cli) (built: Aug 22 2010 19:41:55)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

既然有 php 那就先试试直接用 pecl 来安装。

sudo pecl install -f 
sudo pecl install -f 

不过安装 xhprof 时提示说要在扩展的目录里,查了一下 PECL Bug #16438 里面说是 pecl 里 xhprof 包的问题。那么问题也就很好解决了,直接把源码包下载下来安装即可。

wget http://pecl.php.net/get/xhprof-0.9.2.tgz
tar zxf xhprof-0.9.2.tgz
cd xhprof-0.9.2/extension
phpize
./configure
make
make install

然后修改 /etc/php.ini 如果没有这个文件就 sudo cp /etc/php.ini.default /etc/php.ini。
在 php.ini 中增加 extension=vld.so 和 extension=xhprof.so 和针对这两个扩展的详细配置,这个可以在网上搜到。

然后在 ~/.bash_profile 里增加 alias phpo=’php -dvld.active=1′
以后再打 phpo xxxx.php 就可以看到 vld 的效果了。

0

require_once 和 require 的性能比较


之前大家都是在程序里写上简单的 require_once 和 require 然后直接跑一遍 ab 来看时间,这回 Konstantin Rozinon 在 apache 模式下看了一下 lstat64 的操作数量,对比结果说 require_once 和 require 在时间上相关非常非常小,但是在读文件时是用绝对路径还是相对路径对性能还是有一些影响,因为绝对路径会少一些 stat。

引用原文:
- When using absolute_path there are fewer stat() system calls.
- When using relative_path there are more stat() system calls because it has to start stat()ing from the current directory back up to / and then to the include/ directory.

个人习惯上还是推荐用 require_once,并且这个不是显示的写在各个文件中,而是在中心的 loader 里统一负责根据 5 的 __call 这个特性来去 require_once 相应的文件,一些性能上的损耗可以通过其它方式来弥补。比如 APC、XCache、Eacc 这些,opcode 现在成了 的必需品了。

原文:点击进入

btw: zend studio 7 beta 真慢……

0

管理者,请你远离产品开发/设计部门[转]


先说一个身边真正发生过的故事,可能大家会对故事情节感觉非常熟悉。

一家小型电子商务公司,管理者就是公司的创始人,他有些技术开发背景。因为产品面向海外市场,他也比较关注产品设计与可用性。由于他对自己的技术、设计能力的自信,总是对开发部与设计部成员的能力持怀疑态度,经常插手他们的工作。

一次,开发人员就新产品需求、设计文档的要求,提出开发方案A。这位管理者看后,以其经验判断认为不理想,并给出方案B。开发人员觉得方案B有些问题,但一时又没有找到有说服力的例证,无奈只好以此方案进行开发。

果然,在开发过程中,由于管理者仓促间所提出方案,在设计上确实存在不合理的疏漏,导致项目出现了一些问题。当开发人员想方设法将问题一一解决后,突然发现,这个DEBUG后的开发方案B,已经变得与他们最初提出的方案A并无二致。

而此时,该项目已经严重超期,那位管理者还为此非常不满,认为是开发人员能力的问题导致的。此后,管理者对开发工作的介入变得更多,而开发人员也开始变
化,一部分对领导的这种超权行为越来越不满意,矛盾变得更加激化,后面工作中的沟通变得更加困难;另一部分则变得越来越没有积极性,领导要求怎么做就怎么
做。

刚好看到UCDChina.com中的一篇文章《管理者不应直接参与产品的开发与设计》,感觉说得太有道理了。上面这个故事,可以用来充实文章的论据。

其实团队管理者关注团队产品的成败,是非常正常的心态。他们插手设计、开发工作,无非是希望把产品更得更好,动机是无庸质疑的。尽管如此,还是不建议管理
者过多的介入具体的开发与设计工作,即使是领域专家型的管理者,过多的插手具体设计、开发工作,也得不到预期的结果,可能对于项目来说,往往事与愿违,由
此产生的恶性干扰多于良性的指导,这是得不偿失的。

为什么会这样?原因很多:

1、因为管理者与团队成员的权重不同,有管理者参与的项目,往往不能非常公平地对待其它项目涉众。尽管,管理者本意是以其对项目的理解和自身的经验,为设
计、开发团队提供一些指导和建议,至少也会增加一种思路。但往往事与愿违,管理者介入后,一般会导致所有项目涉众的思维模式,会被管理者所左右,就因为他
是团队的管理者。

大家想想,是否经常遇到这样的情况,设计、开发人员深思熟虑后形成的方案,经常因为管理者的一点儿质疑,而被否决;而管理者的灵光一闪,都可能形成一个决
策,如果其它团队成员想到推翻它,必须经过周密、详实的举证与论述,这本就不公平,对项目也绝对没有好处,这会影响到团队成员的思路,甚至导致他们逐渐推
动思考的动力。

2、因为技术背景与对项目的关注点不同,管理者与设计、开发人员会处在不同层面,看问题角度肯定是不同的。其实,能从多个不同角度看待产品,这本来是好事,可以把问题考虑得更全面一些。但如果以管理者的角度,去干扰设计、开发中的问题,那就是另外一码儿事了。

《论语•泰伯》:“子曰:不在其位,不谋其政。”

这句话说得非常好,这不是推卸责任意思,而恰恰是出于更负责的角度考虑。为了便于理解,这里把“位”理解为“职位”。

每个职位有不同的职责,职责会影响人的立场,不同立场、知识背景的人理解、处理同一个问题,其结果肯定是不一样的。也许管理者认为自己可以做到“换位思考
”,即便如此也是搁靴搔痒的状态,其结果绝对差强人意。比如,管理者明白不能让UI设计师去考虑代码优化的问题,那又为什么自己去犯同样的错误呢?

正所谓术业有专攻,专业的工作还是让专业的人去做,那才可能达到令人满意的结果。

3、有人说,在IT行业,许多管理者都是优秀程序员或策划、设计师出身,这种领域专家型的管理者插手做具体设计、开发工作,应该有对项目、对团队成员有帮助。

其实不然,前面提到的两点问题,对于这样的管理者也依然存在。而且,文章开头提到的那位管理者也曾经是开发人员,本身也是位不错的产品设计师。为什么团队成员在他的指导下,项目进展依然不顺利呢?

从事过产品设计、程序开发工作的朋友应该很清楚,这样的工作需要投入大量的时间与精力,这是一个反复尝试与迭代的过程。好的设计与优秀的编码,绝对不是通
过纸上谈兵或灵光一闪就可以得到的(当然,这个世界是有天才存在的,也许他们拍拍脑袋就可以把产品设计得非常完美,程序编码也可以没有任何BUG,但毕竟
这种天才少得没有说服力)。有的时候,即使写好伪代码,也不能百之百的确保业务逻辑没问题。

而团队的管理者,往往事务缠身,他们没有精力(也不应该)深入于其中任何一项具体工作,那样就会犯下过于关注细节的管理大忌。而浅尝辄止的心态,恰恰又是做好设计与开发工作的大忌。这样看来,管理者兼顾设计、开发工作,并取得好的结果,根本是一项不可能完成的任务。

当然,领域专家型的管理者是可遇而不可求的,他丰富的经验与思路都是对团队成员有帮助的,但仅此而已,具体的设计、开发工作还是应该让设计师和程序员来做。

基于上面分析,如果管理者仍执意要插手设计与开发工作,就必须保证自己的观点(或决策)是100%准确与全面的,这样才不会对项目有负面影响。

当然,这样的要求是不合理的,也没有人敢做此承诺,所以,管理者们还去做好本职工作吧,那里才是发挥你们特长的地方。好的管理者,要懂得放权,要对团队成员应该有足够的信任,相信他们的工作能力,也相信他们的工作态度。正所谓:用人不疑,疑人不用。

如果管理者实在想参与设计、开发工作,那就干脆转行吧。

转自:http://.sina.com.cn/s/_564cabe30100bxmb.

0

解决 Zend Studio for Eclipse 6.x.x 启动时的 bug


在 Zend Studio for Eclipse 时会有显示 Building Project 的错误,解决的办法很简单,在 preference 里的 General 中设置 Startup and Shutdown ,把 Advanced Debugger UI Plug-in 和 PDT Daemon Plug-in 的对号去掉既可。

0

终于找到在 firefox 下替代 httpwatch 的软件了, httpfox


一直不放弃 ie 就在 ff 上没有找到哪几个插件能代替我的无敌 组合 debugbar + compain.JS + httpwatch + iedevtoolbar

现在可以用 firebug + httpwatch + yslow + developer 来取代 ie 了,太爽了 httpfox 还是免费的,哈。

httpwatch

0

[分享] 某知名手机平台的XML Parser源代码


    今天心情不错~ 分享一下小弟06年在某手机公司写的XML .
虽然当时脑子里还没有FSM的概念, 但代码逻辑还算清晰, 颇有成就感!
结构比较简单, 按DOM方式把指定文件解析成节点树, 另外提供几个简单的查找函数.
部分功能等完善, 过段时间再发一份功能比较完善的C++版本.

PLX_XMLParser.h

#if _MSC_VER > 1000
#pragma once
#endif

#ifndef __XMLPARSE_H
#define __XMLPARSE_H

#include

//////////////////////////////
// Configure

#define USE_INLINE_FUNCTION
#define USE_FILEBUFFER

//////////////////////////////
// Constants

typedef enum {
XMLERR_OK       = 0×0,
XMLERR_EFILE,       // failed to open file
XMLERR_ALRDOPEN,    // already opened
XMLERR_EDOC,
XMLERR_EPARSE,
} XMLERR;

typedef enum {
NODETYPE_UNKN    = 0×0,
NODETYPE_ELEM   = 0×1,
NODETYPE_TEXT   = 0×2,
NODETYPE_COMM   = 0×4,
NODETYPE_INST   = 0×8, // Not support
//NODETYPE_USEFUL = NODETYPE_ELEM|NODETYPE_TEXT,
//NODETYPE_ALL    = NODETYPE_ELEM|NODETYPE_TEXT|NODETYPE_COMM|NODETYPE_INST,
} NODETYPE;

typedef enum {
DSTAT_UNOPEN    = 0×0,
DSTAT_OPENED    = 0×1,
} DOCSTAT;

typedef enum {
ISTAT_STOP      = 0×0,
ISTAT_CONTINUE  = 0×1,
ISTAT_PASS      = 0×2,
} ITERSTAT;

enum {    MAXLEN_BSTR    = 256 };

//////////////////////////////
// Structures

struct tagBString
{
LONG    m_lLength;
union   {
CHAR    m_paStr[1];
LPCSTR  m_pszStr;
};
};

typedef struct tagBString       BSTRING;
typedef struct tagBString       *LPBSTRING;
typedef struct tagBString const *LPCBSTRING;

struct tagXMLAttrib;
typedef struct tagXMLAttrib            XMLATTRIB;
typedef struct tagXMLAttrib            *LPXMLATTRIB;
typedef struct tagXMLAttrib    const    *LPCXMLATTRIB;

struct tagXMLAttrib
{
LPBSTRING   m_pbstrName;
LPBSTRING   m_pbstrValue;
LPXMLATTRIB    m_pNext;
};

struct tagXMLNode;
typedef struct tagXMLNode       XMLNODE;
typedef struct tagXMLNode       *LPXMLNODE;
typedef struct tagXMLNode const *LPCXMLNODE;

struct tagXMLNode
{
NODETYPE    m_eNodeType;
LONG        m_lDepth;

LPBSTRING   m_pbstrTag;

LONG        m_lChildNum;
LONG        m_lChildNum_Elem;

LPXMLNODE    m_pRoot;
LPXMLNODE   m_pParent;
LPXMLNODE   m_pFirstChild;
LPXMLNODE   m_pLastChild;
LPXMLNODE   m_pPrevSibling;
LPXMLNODE   m_pNextSibling;

LONG        m_lAttribNum;
LPXMLATTRIB m_pFirstAttrib;
};

struct tagXMLDocument
{
DOCSTAT     m_eDocStat;
LPXMLNODE   m_lpRootNode;
};

typedef struct tagXMLDocument       XMLDOCUMENT;
typedef struct tagXMLDocument       *LPXMLDOCUMENT;
typedef struct tagXMLDocument const *LPCXMLDOCUMENT;

//////////////////////////////
// Types

typedef ITERSTAT    (CALLBACK *LPFNNODEPROC)( LPCXMLNODE pNode, LPVOID pvParam );

//////////////////////////////
// Macros

#if    defined(USE_INLINE_FUNCTION)

#define BSTR_C( pBStr )                     (&((pBStr)->m_paStr[0]))
#define BSTR_CAST( pvAnyType )              ((LPBSTRING)pvAnyType)
#define    BSTR_LEN( pBStr )                   ((pBStr)->m_lLength)
#define BSTR_ALLOC( pszStr )                AllocBString( pszStr, (NULL != (pszStr) ? ((LONG)strlen(pszStr)) : (0L)) )
#define BSTR_ALLOCEX( pszStr, nLen )        AllocBString( pszStr, (LONG)nLen )
#define BSTR_FREE( pBStr )                  free( pBStr )
#define BSTR_SAFEFREE( pBStr )              if ( NULL != pBStr ) { free( pBStr ); pBStr = NULL; }
#define BSTR_EQUAL( pBStrL, pBStrR ) \
( (BSTR_LEN(pBStrL) == BSTR_LEN(pBStrR) && 0 == strcmp(BSTR_C(pBStrL), BSTR_C(pBStrL))) ? \
TRUE : FALSE )
#define BSTR_EQUAL_STATIC( pBStr, szStatic ) \
( (BSTR_LEN(pBStr) == (LONG)(sizeof(szStatic) – 1) && 0 == strcmp(BSTR_C(pBStr), szStatic)) ? \
TRUE : FALSE )
#define BSTR_EQUAL_CSTR( pBStr, pszStr ) \
( (BSTR_LEN(pBStr) == (LONG)strlen(pszStr) && 0 == strcmp(BSTR_C(pBStr), pszStr)) ? \
TRUE : FALSE )

#define    _GetRootNode( pDoc )             ((NULL == (pDoc) || (pDoc)->m_eDocStat != DSTAT_OPENED) ? NULL : (pDoc)->m_lpRootNode)
#define    XML_GetNodeType( pNode )             (NULL != (pNode) ? (pNode)->m_eNodeType : NODETYPE_UNKN)
#define    XML_GetNodeDepth( pNode )            (NULL != (pNode) ? (pNode)->m_lDepth : (-1L))
#define    XML_GetNodeParent( pNode )             (NULL != (pNode) ? (pNode)->m_pParent : NULL)
#define    XML_GetNodeFirstChild( pNode )         (NULL != (pNode) ? (pNode)->m_pFirstChild : NULL)
#define    XML_GetNodeLastChild( pNode )         (NULL != (pNode) ? (pNode)->m_pLastChild : NULL)
#define    XML_GetNodeChildNum( pNode )         (NULL != (pNode) ? (pNode)->m_lChildNum : (0L))
#define    XML_GetNodeChildNum_Elem( pNode )     (NULL != (pNode) ? (pNode)->m_lChildNum_Elem : (0L))
#define    XML_GetNodePrevSibling( pNode )     (NULL != (pNode) ? (pNode)->m_pPrevSibling : NULL)
#define    XML_GetNodeNextSibling( pNode )     (NULL != (pNode) ? (pNode)->m_pNextSibling : NULL)
#define    XML_GetNodeTagName( pNode )         (NULL != (pNode) ? (pNode)->m_pbstrTag : NULL)
#define    XML_GetNodeAttribNum( pNode )         (NULL != (pNode) ? (pNode)->m_lAttribNum : (0L))
#define    XML_GetNodeFirstAttrib( pNode )     (NULL != (pNode) ? (pNode)->m_pFirstAttrib : NULL)
#define    XML_GetNodeNextAttrib( pAttr )         (NULL != (pAttr) ? (pAttr)->m_pNext : NULL)
#define XML_GetAttribValueBString( pAttr )  (NULL != (pAttr) ? (pAttr)->m_pbstrValue) : NULL)
#define XML_GetAttribValueCString( pAttr )  (NULL != (pAttr) ? BSTR_C((pAttr)->m_pbstrValue) : NULL)
#define XML_GetAttribValueLong( pAttr )     (NULL != (pAttr) ? (LONG)strtol(BSTR_C((pAttr)->m_pbstrValue), NULL, 0) : (0L))
#define XML_GetAttribValueInt( pAttr )      (NULL != (pAttr) ? (int)strtol(BSTR_C((pAttr)->m_pbstrValue), NULL, 0) : (0))

#endif

//////////////////////////////
// Function prototypes

#if defined(__cplusplus)
extern “C” {
#endif

size_t      strlen_when( LPCSTR lpszStr, CHAR ch );
size_t        strlen_notin( LPCSTR lpszStr, LPCSTR lpszSet );
LPCSTR        strchr_notin( LPCSTR lpszStr, LPCSTR lpszSet );
LPCSTR        strchr_skipws( LPCSTR lpszStr );

LPBSTRING   AllocBString( LPCSTR lpszStr, LONG lLen );

XMLERR      XML_OpenDocument( LPXMLDOCUMENT pDoc, LPCSTR lpszFileName, DWORD dwReserve );
XMLERR      XML_CloseDocument( LPXMLDOCUMENT pDoc );
LPXMLNODE    XML_GetNode( LPXMLDOCUMENT pDoc, LPXMLNODE pStartPoint, LPCSTR lpszTag, LONG lLen );
LPXMLATTRIB    XML_GetNodeAttrib( LPXMLNODE pNode, LPCSTR lpszAttr, LONG lLen );
LPXMLNODE    XML_GetNodeSibling( LPXMLNODE pNode, LPCSTR lpszTag, LONG lLen, BOOL IncludeThis );
LONG         XML_ForEachNode( LPXMLDOCUMENT pDoc, LPXMLNODE pStartPoint, LPFNNODEPROC pfnNodeProc, LPVOID pvParam );

#if defined(__cplusplus)
}   // extern “C” {
#endif

#endif // #ifndef __XMLPARSE_H

PLX_XMLParser.c

#include <assert.h>
#include <fcntl.h>
#include <io.h>
#if defined() || defined(_)
#include <stdio.h>
#endif

#include “XMLParse.h”

//#pragma warning(disable:4305)

//////////////////////////////
// Configure

//#define  USE_MEMORY_HEAP

#ifdef  USE_FILEBUFFER  // Whether use file system with os-layer buffer

#define INVALID_FILE_HANDLE         ((int)-1)
#define FILE_HANDLE                 int

#define MODE_RDONLY                 (O_RDONLY)
#define FILE_OPEN(pszFile,mode)     open( pszFile, mode )
#define FILE_READ(hFile,pbuf,size)  read(hFile, (LPVOID)pbuf, size)
#define FILE_SEEK(hFile,off,pos)    lseek( hFile, off, pos )
#define FILE_CLOSE(hFile)           close( hFile )

#else

#define INVALID_FILE_HANDLE         ((FILE *)NULL)
#define FILE_HANDLE                 FILE *

#define MODE_RDONLY                 (“r”)
#define FILE_OPEN(pszFile,mode)     fopen( pszFile, mode )
#define FILE_READ(hFile,pbuf,size)  fread((LPVOID)pbuf, size, 1, hFile)
#define FILE_SEEK(hFile,off,pos)    fseek( hFile, off, pos )
#define FILE_CLOSE(hFile)           fclose( hFile )

#endif

//////////////////////////////
// Constants

enum {    MAXLEN_READBUF    = 1024 };

typedef enum {
PSTAT_STOP      = 0×0,
PSTAT_INITIAL,
PSTAT_FINAL,
PSTAT_DECL_BEG,
PSTAT_DECL_END,
PSTAT_ELEM_BEG,
PSTAT_ELEM_END,
PSTAT_TEXT_BEG,
PSTAT_TEXT_END,
PSTAT_CDATA_BEG,
PSTAT_CDATA_END,
PSTAT_COMM_BEG,
PSTAT_COMM_END,
PSTAT_ERROR,
} PARSESTAT;

//////////////////////////////
// Macros

#define ZERO_MEMORY(p, size) \
( memset((LPVOID)(p), 0×0, (size_t)size) )

#define is_WhiteSpace(ch)   (((ch) == ‘ ‘  || (ch) == ‘\t’) ? TRUE : FALSE)
#define is_LineBreak(ch)    (((ch) == ‘\r’ || (ch) == ‘\n’) ? TRUE : FALSE)
#define is_LeftBracket(ch)    ((ch) == ‘<’ ? TRUE : FALSE)
#define is_RightBracket(ch)    ((ch) == ‘>’ ? TRUE : FALSE)

#define is_BufferEmpty(ps)  ((ps)->m_lReadCursor >= (ps)->m_lReadSize ? TRUE : FALSE)
#define get_BufferChar(ps)  ((CHAR)((ps)->m_aReadBuf[(ps)->m_lReadCursor]))

#define is_FirstChild(pn)    ((pn)->m_pPrevSibling == NULL ? TRUE : FALSE)
#define is_LastChild(pn)    ((pn)->m_pNextSibling == NULL ? TRUE : FALSE)

//////////////////////////////
// Structures

struct tagXMLParseStat
{
PARSESTAT   m_eParseStat;
LONG        m_lDepth;
LPXMLNODE    m_pRootNode;
LPXMLNODE    m_pLastNode;

FILE_HANDLE    m_hOpenFile;
LONG        m_lFileCursor;
LONG        m_lFileLength;

LONG        m_lLineNo;
LONG        m_lReadCursor;
LONG        m_lReadSize;
BYTE        m_aReadBuf[MAXLEN_READBUF];
};
typedef struct tagXMLParseStat            XMLPARSESTAT;
typedef struct tagXMLParseStat            *LPXMLPARSESTAT;
typedef struct tagXMLParseStat    const    *LPCXMLPARSESTAT;

struct tagXMLIterator
{
LONG            m_lCount;
LPFNNODEPROC    m_pfnProc;
LPVOID          m_pvParam;
LPXMLNODE       m_pStation;
};
typedef struct tagXMLIterator       XMLITERFATOR;
typedef struct tagXMLIterator       *LPXMLITERFATOR;
typedef struct tagXMLIterator const *LPCXMLITERFATOR;

/*struct tagMemoryPage
{
LONG    lGranu ;
LONG    lSize;
LPVOID  pvPage;
BYTE    bUseFlags[1];
};
typedef struct tagMemoryPage        MEMORYPAGE;
typedef struct tagMemoryPage        *LPMEMORYPAGE;
typedef struct tagMemoryPage const  *LPCMEMORYPAGE;*/

//////////////////////////////
// Function prototypes

#if defined(__cplusplus)
extern “C” {
#endif

static void        XML_FreeNodeTree( LPXMLNODE pNode );
static void        XML_FreeAttribList( LPXMLATTRIB pAttrib );
static void     XML_IterateTree( LPXMLNODE pTree, LPXMLITERFATOR pIterator );
static BOOL     XMLCmpNode_EqualTag( LPCXMLNODE pNode, LPVOID pvParam );

static BOOL        Parser_RoutineStart( LPXMLPARSESTAT pParseStat, LPXMLDOCUMENT pResult );
static int        Parser_GetTagString( LPXMLPARSESTAT pParseStat, LPSTR lpszBuf );
static BOOL        Parser_ReadStream( LPXMLPARSESTAT pParseStat );
static void        Parser_OnInitial( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static void        Parser_OnElemBegin( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static void        Parser_OnElemEnd( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static void        Parser_OnTextBegin( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static void        Parser_OnTextEnd( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static void        Parser_OnCDATABegin( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static void        Parser_OnCDATAEnd( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static void        Parser_OnCommBegin( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static void        Parser_OnCommEnd( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static void        Parser_OnDeclBegin( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static void        Parser_OnDeclEnd( LPXMLPARSESTAT pParseStat, LPSTR lpszTag );
static BOOL        Parser_OnFinal( LPXMLPARSESTAT pParseStat );
static BOOL        Parser_OnError( LPXMLPARSESTAT pParseStat );

//#if defined(USE_MEMORY_HEAP)
//static LPVOID   MemoryHeap_Create( LONG lInitialGranu, LONG lInitialSize );
//static BOOL     MemoryHeap_Destroy( LPVOID );
//static LPVOID   MemoryHeap_Alloc( void );
//static void     MemoryHeap_Free( LPVOID pvBlock );
//#endif

#if defined(__cplusplus)
}   // extern “C” {
#endif

//////////////////////////////
// Function implementations

#if defined(__cplusplus)
extern “C” {
#endif

/*********************************************************************\
* Function: strlen_when
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
size_t strlen_when( LPCSTR lpszStr, CHAR ch )
{
register size_t nLen;
assert( NULL != lpszStr );
for ( nLen = 0; *lpszStr != ch && *lpszStr != ‘\0′;    lpszStr++, nLen++ )
;
return nLen;
}

/*********************************************************************\
* Function: strlen_notin
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
size_t strlen_notin( LPCSTR lpszStr, LPCSTR lpszSet )
{
register size_t nLen;
assert( NULL != lpszStr );
for ( nLen = 0; *lpszStr != ‘\0′ && NULL == strchr(lpszSet, *lpszStr); lpszStr++, nLen++ )
;
return nLen;
}

/*********************************************************************\
* Function: strchr_notin
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
LPCSTR strchr_notin( LPCSTR lpszStr, LPCSTR lpszSet )
{
assert( NULL != lpszStr );
for ( ; *lpszStr != ‘\0′ && NULL == strchr(lpszSet, *lpszStr); lpszStr++ )
;
return lpszStr;
}

/*********************************************************************\
* Function: strchr_skipws
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
LPCSTR strchr_skipws( LPCSTR lpszStr )
{
assert( NULL != lpszStr );
for ( ; *lpszStr != ‘\0′ && is_WhiteSpace(*lpszStr); lpszStr++ )
;
return lpszStr;
}

/*********************************************************************\
* Function: AllocBString
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
LPBSTRING AllocBString( LPCSTR lpszStr, LONG lLen )
{
LPBSTRING pBStr = (LPBSTRING)malloc( sizeof(LONG) + lLen + 1 );
assert( NULL != pBStr );

pBStr->m_lLength = lLen;
strncpy( &pBStr->m_paStr[0], lpszStr, lLen );
pBStr->m_paStr[lLen] = ‘\0′;

return pBStr;
}

/*********************************************************************\
* Function: XML_OpenDocument
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
XMLERR XML_OpenDocument( LPXMLDOCUMENT pDoc, LPCSTR lpszFileName, DWORD dwReserve )
{
BOOL            bRet;
FILE_HANDLE        hFile;
XMLPARSESTAT    xmlParseStat;

assert( NULL != pDoc );
assert( NULL != lpszFileName );

if ( pDoc->m_eDocStat == DSTAT_OPENED )
return XMLERR_ALRDOPEN;

ZERO_MEMORY( &xmlParseStat, sizeof(XMLPARSESTAT) );

hFile = FILE_OPEN( lpszFileName, MODE_RDONLY );
if ( INVALID_FILE_HANDLE == hFile )
return XMLERR_EFILE;

xmlParseStat.m_hOpenFile    = hFile;
xmlParseStat.m_lFileCursor    = 0;
xmlParseStat.m_lFileLength    = FILE_SEEK( hFile, 0, SEEK_END );
FILE_SEEK( hFile, 0, SEEK_SET );

xmlParseStat.m_lDepth = 0;
xmlParseStat.m_lLineNo = 1;
bRet = Parser_RoutineStart( &xmlParseStat, pDoc );
if ( FALSE == bRet )
{
FILE_CLOSE( hFile );
return XMLERR_EPARSE;
}

pDoc->m_eDocStat    = DSTAT_OPENED;
pDoc->m_lpRootNode    = xmlParseStat.m_pRootNode;
FILE_CLOSE( hFile );
return XMLERR_OK;
}

/*********************************************************************\
* Function: XML_CloseDocument
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
XMLERR XML_CloseDocument( LPXMLDOCUMENT pDoc )
{
if ( NULL != pDoc && pDoc->m_eDocStat == DSTAT_OPENED )
{
XML_FreeNodeTree( pDoc->m_lpRootNode );
pDoc->m_lpRootNode = NULL;
pDoc->m_eDocStat = DSTAT_UNOPEN;
}
return XMLERR_OK;
}

/*********************************************************************\
* Function: Parser_GetTagString
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
int Parser_GetTagString( LPXMLPARSESTAT pParseStat, LPSTR lpszBuf )
{
int        nLen;
CHAR    ch;
CHAR    chTerm;
BOOL    bInclude;

// Should to ensure barket match Here!

nLen = 0;
for ( ;; )
{
if ( is_BufferEmpty(pParseStat) && FALSE == Parser_ReadStream(pParseStat) )
goto __RET;

ch = get_BufferChar(pParseStat);
if ( ch == ‘\n’ )
pParseStat->m_lLineNo++;

if ( !is_WhiteSpace(ch) && !is_LineBreak(ch) )
break;

pParseStat->m_lReadCursor++;
}

if ( is_LeftBracket(ch) )
{
chTerm = ‘>’;
bInclude = TRUE;
}
else
{
chTerm = ‘<’;
bInclude = FALSE;
}

for ( ;; )
{
if ( is_BufferEmpty(pParseStat) && FALSE == Parser_ReadStream(pParseStat) )
break;

ch = get_BufferChar(pParseStat);
if ( ch == ‘\n’ )
pParseStat->m_lLineNo++;

if ( ch == chTerm )
{
if ( FALSE != bInclude )
{
lpszBuf[nLen++] = chTerm;
pParseStat->m_lReadCursor++;
}
break;
}

lpszBuf[nLen++] = ch;
pParseStat->m_lReadCursor++;
}

__RET:
lpszBuf[nLen] = ‘\0′;
return nLen;
}

/*********************************************************************\
* Function: Parser_ReadStream
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
BOOL Parser_ReadStream( LPXMLPARSESTAT pParseStat )
{
size_t    nSize;

pParseStat->m_lReadCursor    = 0;
pParseStat->m_lReadSize    = 0;
nSize = FILE_READ( pParseStat->m_hOpenFile, (LPVOID)&pParseStat->m_aReadBuf[0], MAXLEN_READBUF );
if ( nSize <= 0 )
return FALSE;

pParseStat->m_lReadSize        = (LONG)nSize;
pParseStat->m_lFileCursor  += (LONG)nSize;
return TRUE;
}

/*********************************************************************\
* Function: Parser_RoutineStart
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
BOOL Parser_RoutineStart( LPXMLPARSESTAT pParseStat, LPXMLDOCUMENT pResult )
{
BOOL    bRet;
CHAR    szTag[256];

assert( NULL != pParseStat );

pParseStat->m_eParseStat = PSTAT_INITIAL;
while ( pParseStat->m_eParseStat != PSTAT_STOP )
{
switch ( pParseStat->m_eParseStat )
{
case PSTAT_INITIAL:     Parser_OnInitial( pParseStat, &szTag[0] );        break;

case PSTAT_DECL_BEG:    Parser_OnDeclBegin( pParseStat, &szTag[0] );    break;
case PSTAT_DECL_END:    Parser_OnDeclEnd( pParseStat, &szTag[0] );        break;

case PSTAT_ELEM_BEG:    Parser_OnElemBegin( pParseStat, &szTag[0] );    break;
case PSTAT_ELEM_END:    Parser_OnElemEnd( pParseStat, &szTag[0] );      break;

case PSTAT_TEXT_BEG:    Parser_OnTextBegin( pParseStat, &szTag[0] );    break;
case PSTAT_TEXT_END:    Parser_OnTextEnd( pParseStat, &szTag[0] );        break;

case PSTAT_CDATA_BEG:    Parser_OnCDATABegin( pParseStat, &szTag[0] );    break;
case PSTAT_CDATA_END:    Parser_OnCDATAEnd( pParseStat, &szTag[0] );        break;

case PSTAT_COMM_BEG:    Parser_OnCommBegin( pParseStat, &szTag[0] );    break;
case PSTAT_COMM_END:    Parser_OnCommEnd( pParseStat, &szTag[0] );        break;

case PSTAT_FINAL:        bRet = Parser_OnFinal( pParseStat );            break;
case PSTAT_ERROR:        bRet = Parser_OnError( pParseStat );            break;

default:
assert( !”Unknown parsing status!” );
break;
}
}
return bRet;
}

/*********************************************************************\
* Function: Parser_OnInitial
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnInitial( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
int     nLen;
assert( NULL != lpszTag );

lpszTag[0] = ‘\0′;

nLen = Parser_GetTagString( pParseStat, lpszTag );
if ( nLen <= 0 )
{
pParseStat->m_eParseStat = PSTAT_STOP;
return;
}

if ( lpszTag[0] == ‘<’  )
{
if ( lpszTag[1] == ‘?’)
{
pParseStat->m_eParseStat = PSTAT_DECL_BEG;
}
else if ( !strncmp(&lpszTag[1], “!–”, 3) )
{
pParseStat->m_eParseStat = PSTAT_COMM_BEG;
}
else if ( lpszTag[1] == ‘/’ )
{
pParseStat->m_eParseStat = PSTAT_ELEM_END;
}
else if ( isalpha(lpszTag[1]) )
{
pParseStat->m_eParseStat = PSTAT_ELEM_BEG;
}
else if ( !strncmp(&lpszTag[1], “![CDATA[", 8) )
{
pParseStat->m_eParseStat = PSTAT_CDATA_BEG;
}
else
{
pParseStat->m_eParseStat = PSTAT_ERROR;
}
}
else if ( NULL != pParseStat->m_pLastNode )
{
pParseStat->m_eParseStat = PSTAT_TEXT_BEG;
}
else
{
pParseStat->m_eParseStat = PSTAT_ERROR;
}
}

/*********************************************************************\
* Function: Parser_OnFinal
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
BOOL Parser_OnFinal( LPXMLPARSESTAT pParseStat )
{
pParseStat->m_eParseStat = PSTAT_STOP;
return TRUE;
}

/*********************************************************************\
* Function: Parser_OnError
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
BOOL Parser_OnError( LPXMLPARSESTAT pParseStat )
{
XML_FreeNodeTree( pParseStat->m_pRootNode );
pParseStat->m_pRootNode     = NULL;
pParseStat->m_eParseStat = PSTAT_STOP;
TRACE( "[Xml Parser]: Syntax error @ %s #%ld.\n”, “”, pParseStat->m_lLineNo);
return FALSE;
}

/*********************************************************************\
* Function: Parser_OnDeclBegin
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnDeclBegin( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
int nLenTag;

if ( NULL != pParseStat->m_pRootNode )
{
pParseStat->m_eParseStat = PSTAT_ERROR;
return;
}

lpszTag = (LPSTR)strchr_skipws( (LPCSTR)(lpszTag + 2) );
if ( lpszTag == ‘\0′ )
{
pParseStat->m_eParseStat = PSTAT_ERROR;
return;
}

nLenTag = (int)strlen_notin(lpszTag, ” \t\r\n>”);
if ( nLenTag == 3 && !strncmp(lpszTag, “xml”, 3) )
{
// Here, dispose version and coding infomation in XML document header
}
else if ( nLenTag == 14 && !strncmp(lpszTag, “xml-stylesheet”, 3) )
{
// Unsupport
}
else
{
// Unknown declaretion
}

pParseStat->m_eParseStat = PSTAT_INITIAL;
}

/*********************************************************************\
* Function: Parser_OnDeclEnd
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnDeclEnd( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
// Do noting
}

/*********************************************************************\
* Function: Parser_OnElemBegin
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnElemBegin( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
int         nLenTag;
int         nLenValue;
LPSTR       lpszValue;
LPXMLNODE   pNode;
LPXMLATTRIB    pAttrib;
LPXMLATTRIB pPrevAttr;

assert( is_LeftBracket(lpszTag[0]) );

// Multi-root node is not supproted
if ( 0 == pParseStat->m_lDepth && NULL != pParseStat->m_pRootNode )
goto __ERROR;

pNode = (LPXMLNODE)malloc(sizeof(XMLNODE));
if ( NULL == pNode )
goto __ERROR;

ZERO_MEMORY( pNode, sizeof(XMLNODE) );
pNode->m_eNodeType    = NODETYPE_ELEM;
pNode->m_lDepth        = pParseStat->m_lDepth;
if ( NULL != pParseStat->m_pLastNode )
{
assert( pNode->m_lDepth >= pParseStat->m_pLastNode->m_lDepth );
if ( pNode->m_lDepth > pParseStat->m_pLastNode->m_lDepth ) // new child
{
pNode->m_pParent = pParseStat->m_pLastNode;
pParseStat->m_pLastNode->m_pFirstChild = pNode;
}
else if ( pNode->m_lDepth == pParseStat->m_pLastNode->m_lDepth ) // new sibling
{
pNode->m_pParent = pParseStat->m_pLastNode->m_pParent;
pParseStat->m_pLastNode->m_pNextSibling = pNode;
pNode->m_pPrevSibling = pParseStat->m_pLastNode;
}

if ( NULL != pNode->m_pParent )
{
pNode->m_pParent->m_lChildNum++;
pNode->m_pParent->m_lChildNum_Elem++;
}
}

if ( NULL == pParseStat->m_pRootNode )
{
pParseStat->m_pRootNode = pNode;
}
pNode->m_pRoot = pParseStat->m_pRootNode;

pParseStat->m_pLastNode    = pNode;

lpszTag++;
nLenTag = (int)strlen_notin(lpszTag, ” \t\r\n>”);
if ( nLenTag <= 0 )
goto __ERROR;

pNode->m_pbstrTag = BSTR_ALLOCEX(lpszTag, nLenTag);
if ( NULL == pNode->m_pbstrTag )
goto __ERROR;

lpszTag = (LPSTR)(lpszTag + nLenTag);

for ( pPrevAttr = NULL;; )
{
lpszTag = (LPSTR)strchr_skipws( lpszTag );

if ( is_RightBracket(*lpszTag) )
{
pParseStat->m_lDepth++; // Move down one layer
pParseStat->m_eParseStat = PSTAT_INITIAL;
break;
}
else if ( !strncmp(lpszTag, “/>”, 2) )
{
//pParseStat->m_lDepth–; //
pParseStat->m_eParseStat = PSTAT_INITIAL;
break;
}

nLenTag = (int)strlen_when( lpszTag, ‘=’ );
if ( nLenTag <= 0 )
goto __ERROR;

lpszValue = strchr( (LPCSTR)(lpszTag + nLenTag), ‘\”‘ );
if ( NULL == lpszValue )
goto __ERROR;

lpszValue++;
nLenValue = (int)strlen_when( lpszValue, ‘\”‘ );

//if ( nLenValue <= 0 )
//    goto __ERROR;

pAttrib = (LPXMLATTRIB)malloc(sizeof(XMLATTRIB));
if ( NULL == pAttrib )
goto __ERROR;
ZERO_MEMORY( pAttrib, sizeof(XMLATTRIB) );

pAttrib->m_pbstrName    = BSTR_ALLOCEX( lpszTag, nLenTag );
pAttrib->m_pbstrValue    = BSTR_ALLOCEX( lpszValue, nLenValue );
if ( NULL == pAttrib->m_pbstrName || NULL == pAttrib->m_pbstrValue )
goto __ERROR;

if ( NULL == pNode->m_pFirstAttrib )
pNode->m_pFirstAttrib = pAttrib;

if ( NULL != pPrevAttr )
pPrevAttr->m_pNext = pAttrib;
pPrevAttr = pAttrib;

pNode->m_lAttribNum++;
lpszTag = lpszValue + nLenValue + 1;
}

return;

__ERROR:
XML_FreeNodeTree( pNode );
pParseStat->m_eParseStat = PSTAT_ERROR;
}

/*********************************************************************\
* Function: Parser_OnElemEnd
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnElemEnd( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
pParseStat->m_lDepth–;

if ( NULL != pParseStat->m_pLastNode )
{
if ( NULL != pParseStat->m_pLastNode->m_pParent )
pParseStat->m_pLastNode->m_pParent->m_pLastChild = pParseStat->m_pLastNode;

if ( pParseStat->m_pLastNode->m_lDepth > pParseStat->m_lDepth )
pParseStat->m_pLastNode = pParseStat->m_pLastNode->m_pParent;
}

if ( 0 == pParseStat->m_lDepth )
pParseStat->m_eParseStat = PSTAT_FINAL;
else
pParseStat->m_eParseStat = PSTAT_INITIAL;
}

/*********************************************************************\
* Function: Parser_OnTextBegin
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnTextBegin( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
LPXMLNODE pNode;

pNode = (LPXMLNODE)malloc(sizeof(XMLNODE));
if ( NULL == pParseStat->m_pLastNode )
goto __ERROR;

ZERO_MEMORY( pNode, sizeof(XMLNODE) );
pNode->m_eNodeType    = NODETYPE_TEXT;
pNode->m_lDepth        = pParseStat->m_lDepth;

if ( NULL != pParseStat->m_pLastNode )
{
assert( pNode->m_lDepth >= pParseStat->m_pLastNode->m_lDepth );
if ( pNode->m_lDepth > pParseStat->m_pLastNode->m_lDepth )
{
pNode->m_pParent = pParseStat->m_pLastNode;
pParseStat->m_pLastNode->m_pFirstChild = pNode;
}
else if ( pNode->m_lDepth == pParseStat->m_pLastNode->m_lDepth )
{
pNode->m_pParent = pParseStat->m_pLastNode->m_pParent;
pParseStat->m_pLastNode->m_pNextSibling = pNode;
pNode->m_pPrevSibling = pParseStat->m_pLastNode;
}

if ( NULL != pNode->m_pParent )
pNode->m_pParent->m_lChildNum++;

pNode->m_pRoot = pParseStat->m_pLastNode->m_pRoot;
}

pParseStat->m_pLastNode    = pNode;

pNode->m_pbstrTag = BSTR_ALLOC(lpszTag);
if ( NULL == pNode->m_pbstrTag )
goto __ERROR;

pParseStat->m_lDepth++; // Move down one layer
pParseStat->m_eParseStat = PSTAT_TEXT_END;
return;

__ERROR:
XML_FreeNodeTree( pNode );
pParseStat->m_eParseStat = PSTAT_ERROR;
}

/*********************************************************************\
* Function: Parser_OnTextEnd
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnTextEnd( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
// Move up one layer
pParseStat->m_lDepth–;

if ( NULL != pParseStat->m_pLastNode &&
pParseStat->m_pLastNode->m_lDepth > pParseStat->m_lDepth )
pParseStat->m_pLastNode = pParseStat->m_pLastNode->m_pParent;

pParseStat->m_eParseStat = PSTAT_INITIAL;
}

/*********************************************************************\
* Function: Parser_OnCommBegin
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnCommBegin( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
pParseStat->m_eParseStat = PSTAT_INITIAL;
}

/*********************************************************************\
* Function: Parser_OnCommEnd
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnCommEnd( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
}

/*********************************************************************\
* Function: Parser_OnCDATABegin
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnCDATABegin( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
pParseStat->m_eParseStat = PSTAT_INITIAL;
// Should convert to text here
}

/*********************************************************************\
* Function: Parser_OnCDATAEnd
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void Parser_OnCDATAEnd( LPXMLPARSESTAT pParseStat, LPSTR lpszTag )
{
}

/*********************************************************************\
* Function: XML_IterateTree
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void XML_IterateTree( LPXMLNODE pTree, LPXMLITERFATOR pIterator )
{
register ITERSTAT eStat;
if ( NULL != pTree )
{
pIterator->m_pStation = pTree;
eStat = pIterator->m_pfnProc( pTree, pIterator->m_pvParam );
if ( eStat == ISTAT_STOP )
return;
if ( eStat != ISTAT_PASS )
pIterator->m_lCount++;

XML_IterateTree( pTree->m_pFirstChild, pIterator );
XML_IterateTree( pTree->m_pNextSibling, pIterator );
}
}

/*********************************************************************\
* Function: XML_ForEachNode
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
LONG XML_ForEachNode( LPXMLDOCUMENT pDoc, LPXMLNODE pStartPoint, LPFNNODEPROC pfnNodeProc, LPVOID pvParam )
{
XMLITERFATOR    iter;

assert( NULL != pDoc );
assert( NULL != pfnNodeProc );

if ( pDoc->m_eDocStat == DSTAT_UNOPEN || (NULL != pStartPoint && pStartPoint->m_pRoot != pDoc->m_lpRootNode) )
return 0;

iter.m_lCount   = 0;
iter.m_pStation = NULL;
iter.m_pvParam  = pvParam;
iter.m_pfnProc  = pfnNodeProc;

pStartPoint = (NULL == pStartPoint ? pDoc->m_lpRootNode : pStartPoint);
XML_IterateTree( pStartPoint, &iter );
return iter.m_lCount;
}

/*********************************************************************\
* Function: XMLCmpNode_EqualTag
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
ITERSTAT XMLCmpNode_EqualTag( LPCXMLNODE pNode, LPVOID pvParam )
{
if ( FALSE != BSTR_EQUAL(pNode->m_pbstrTag, BSTR_CAST(pvParam)) )
return ISTAT_STOP;
else
return ISTAT_CONTINUE;
}

/*********************************************************************\
* Function: XML_GetNode
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
LPXMLNODE XML_GetNode( LPXMLDOCUMENT pDoc, LPXMLNODE pStartPoint, LPCSTR lpszTag, LONG lLen )
{
BSTRING         bStr;
XMLITERFATOR    iter;

assert( NULL != lpszTag );
assert( NULL != pDoc );

if ( pDoc->m_eDocStat == DSTAT_UNOPEN || pStartPoint->m_pRoot != pDoc->m_lpRootNode )
return NULL;

bStr.m_lLength  = lLen;
bStr.m_pszStr   = lpszTag;

iter.m_lCount   = 0;
iter.m_pfnProc  = &XMLCmpNode_EqualTag;
iter.m_pStation = NULL;
iter.m_pvParam  = (LPVOID)&bStr;

pStartPoint = (NULL == pStartPoint ? pDoc->m_lpRootNode : pStartPoint);
XML_IterateTree( pStartPoint, &iter );
return (iter.m_pStation);
}

/*********************************************************************\
* Function: XML_GetNodeAttrib
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
LPXMLATTRIB    XML_GetNodeAttrib( LPXMLNODE pNode, LPCSTR lpszAttr, LONG lLen )
{
BSTRING     bStr;
LPXMLATTRIB pAttrib;

assert( NULL != lpszAttr );
assert( NULL != pNode );
bStr.m_lLength  = lLen;
bStr.m_pszStr   = lpszAttr;

for ( pAttrib = XML_GetNodeFirstAttrib(pNode); NULL != pAttrib; pAttrib = XML_GetNodeNextAttrib(pAttrib) )
{
if ( FALSE != BSTR_EQUAL(pAttrib->m_pbstrName, &bStr) )
break;
}

return pAttrib;
}

/*********************************************************************\
* Function: XML_GetNodeSibling
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
LPXMLNODE XML_GetNodeSibling( LPXMLNODE pNode, LPCSTR lpszTag, LONG lLen, BOOL bIncludeThis )
{
BSTRING     bStr;

assert( NULL != lpszTag );
assert( NULL != pNode );
bStr.m_lLength  = lLen;
bStr.m_pszStr   = lpszTag;

if ( FALSE != bIncludeThis && FALSE != BSTR_EQUAL(pNode->m_pbstrTag, &bStr) )
return pNode;

for ( pNode = XML_GetNodeNextSibling(pNode); NULL != pNode; pNode = XML_GetNodeNextSibling(pNode) )
{
if ( FALSE != BSTR_EQUAL(pNode->m_pbstrTag, &bStr) )
break;
}

return pNode;
}

/*********************************************************************\
* Function: XML_FreeNodeTree
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void XML_FreeNodeTree( LPXMLNODE pNode )
{
if ( NULL != pNode )
{
BSTR_FREE( pNode->m_pbstrTag );

XML_FreeAttribList( pNode->m_pFirstAttrib );

if ( is_FirstChild(pNode) && NULL != pNode->m_pParent )
pNode->m_pParent->m_pFirstChild = pNode->m_pNextSibling;

if ( NULL != pNode->m_pNextSibling )
pNode->m_pNextSibling->m_pPrevSibling = pNode->m_pPrevSibling;
if ( NULL != pNode->m_pPrevSibling )
pNode->m_pPrevSibling->m_pNextSibling = pNode->m_pNextSibling;

XML_FreeNodeTree( pNode->m_pFirstChild );
XML_FreeNodeTree( pNode->m_pNextSibling );

free( pNode );
}
}

/*********************************************************************\
* Function: XML_FreeAttribList
* Purpose:
* Params:
* Return
* Remarks
**********************************************************************/
void XML_FreeAttribList( LPXMLATTRIB pAttrib )
{
LPXMLATTRIB pNext;

while ( NULL != pAttrib )
{
pNext = pAttrib->m_pNext;
BSTR_FREE( pAttrib->m_pbstrName );
BSTR_FREE( pAttrib->m_pbstrValue );
free( pAttrib );
pAttrib = pNext;
}
}

#if defined(__cplusplus)
}   // extern “C” {
#endif

0

XCache & XDebug on road


终于配置上 XCache 和 XDebug 了,可惜的是 --bridge 一直没搞好,只有双击运行 JavaBridge 后才行,唉,要是能内置到 里就好了。

继续研究 &

如果说之前在 UUSee 是向上研究,既“抽象”、“架构”的话,那么来 IMobile 之后研究方向则是向下,研究底层,研究以前没注意到的更细节的地方了。

:)

Good days, good luck.

0

[超长篇] Inject Your Code to a Portable Executable File


转至: http://www.codeguru.com/cpp/w-p/system/misc/article.php/c11393

Downloads

  • pemaker1.zip
  • pemaker2.zip
  • pemaker3.zip
  • pemaker4.zip
  • pemaker5.zip
  • peviewer.zip
  • test1.zip
  • Windows NT 3.51 (I mean, Win3.1, Win95, Win98 were not perfect OSs). The MS-DOS data causes that your executable file to have the performance inside MS-DOS and the MS-DOS Stub program lets it display: "This program can not be run in MS-DOS mode" or "This program can be run only in mode", or some things like these comments when you try to run a Windows EXE file inside MS-DOS 6.0, where there is no footstep of Windows. Thus, this data is reserved for the code to indicate these comments in the MS-DOS operating system. The most interesting part of the MS-DOS data is "MZ"! Can you believe, it refers to the name of "Mark Zbikowski", one of the first Microsoft programmers?

    0 Preface

    You might demand to comprehend the ways a virus program injects its procedure into the interior of a portable executable file and corrupts it, or you are interested in implementing a packer or a protector to encrypt the data of your portable executable (PE) file. This article is committed to represent a brief discussion to realize the performance that is accomplished by EXE tools or some kinds of mal-ware.

    You can employ this article’s source code to create your custom EXE builder. It could be used to make an EXE protector in the right way, or with the wrong intention, to spread a virus. However, my purpose of writing this article has been the first application, so I will not be responsible for the immoral usage of these methods.

    1 Prerequisites

    There are no specific mandatory prerequisites to follow the topics in this article. If you are familiar with a debugger and also the portable file format, I suggest you to drop to Sections 2 and 3; the whole of these sections has been made for people who don’t have any knowledge regarding the EXE file format or debuggers.

    2 Portable Executable File Format

    The Portable Executable file format was defined to provide the best way for the Windows Operating System to execute code and also to store the essential data that is needed to run a program—for example constant data, variable data, import library links, and resource data. It consists of MS-DOS file information, Windows NT file information, Section Headers, and Section images, as shown in Table 1.

    2.1 The MS-DOS data

    These data let you remember the first days of developing the Windows Operating System. You were at the beginning of a way to achieve a complete Operating System such as

    To me, only the offset of the PE signature in the MS-DOS data is important, so I can use it to find the position of the Windows NT data. I just recommend that you take a look at Table 1, and then observe the structure of IMAGE_DOS_HEADER in the <winnt.h> header in the <Microsoft Visual Studio .net path>\VC7\PlatformSDK\include\ folder or the <Microsoft Visual Studio 6.0 path>\VC98\include\ folder. I do not know why the Microsoft team has forgotten to provide some comment about this structure in the MSDN library!

    typedef struct _IMAGE_DOS_HEADER { // DOS .EXE header "MZ"    WORD   e_magic;                // Magic number    WORD   e_cblp;                 // Bytes on last page of file    WORD   e_cp;                   // Pages in file    WORD   e_crlc;                 // Relocations    WORD   e_cparhdr;              // Size of header in                                   // paragraphs    WORD   e_minalloc;             // Minimum extra paragraphs                                   // needed    WORD   e_maxalloc;             // Maximum extra paragraphs                                   // needed    WORD   e_ss;                   // Initial (relative) SS                                   // value    WORD   e_sp;                   // Initial SP value    WORD   e_csum;                 // Checksum    WORD   e_ip;                   // Initial IP value    WORD   e_cs;                   // Initial (relative) CS                                   // value    WORD   e_lfarlc;               // File address of relocation                                   // table    WORD   e_ovno;                 // Overlay number    WORD   e_res[4];               // Reserved words    WORD   e_oemid;                // OEM identifier                                   // (for e_oeminfo)    WORD   e_oeminfo;              // OEM information;                                   // e_oemid specific    WORD   e_res2[10];             // Reserved words    LONG   e_lfanew;               // File address of the new                                   // exe header  } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

    e_lfanew is the offset that refers to the position of the Windows NT data. I have provided a program to obtain the header information from an EXE file and to display it to you. To use the program, just try:

    PE Viewer


    (Full Size Image)


    (Full Size Image)

    This sample is useful for the whole of this article.

    Table 1: Portable Executable file format structure

    MS-DOS
    information
    IMAGE_DOS_
    HEADER
    DOS EXE Signature
    00000000  ASCII "MZ"00000002  DW 009000000004  DW 000300000006  DW 000000000008  DW 00040000000A  DW 00000000000C  DW FFFF0000000E  DW 000000000010  DW 00B800000012  DW 000000000014  DW 000000000016  DW 000000000018  DW 00400000001A  DW 00000000001C  DB 00b&b&0000003B  DB 000000003C  DD 000000F0
    DOS_PartPag
    DOS_PageCnt
    DOS_ReloCnt
    DOS_HdrSize
    DOS_MinMem
    DOS_MaxMem
    DOS_ReloSS
    DOS_ExeSP
    DOS_ChkSum
    DOS_ExeIPP
    DOS_ReloCS
    DOS_TablOff
    DOS_Overlay
    b&
    Reserved words
    b&
    Offset to PE signature
    MS-DOS Stub
    Program
    00000040  ..B:..B4.C!B8\LC!This program canno00000060  t be run in DOS mode....$.......
    Windows NT
    information

    IMAGE_
    NT_HEADERS

    Signature PE signature (PE)
    000000F0  ASCII "PE"
    IMAGE_
    FILE_HEADER
    Machine
    000000F4  DW 014C000000F6  DW 0003000000F8  DD 3B7D8410000000FC  DD 0000000000000100  DD 0000000000000104  DW 00E000000106  DW 010F
    NumberOfSections
    TimeDateStamp
    PointerToSymbolTable
    NumberOfSymbols
    SizeOfOptionalHeader
    Characteristics
    IMAGE_
    OPTIONAL_
    HEADER32
    MagicNumber
    00000108  DW 010B0000010A  DB 070000010B  DB 000000010C  DD 0001280000000110  DD 00009C0000000114  DD 0000000000000118  DD 000124750000011C  DD 0000100000000120  DD 0001400000000124  DD 0100000000000128  DD 000010000000012C  DD 0000020000000130  DW 000500000132  DW 000100000134  DW 000500000136  DW 000100000138  DW 00040000013A  DW 00000000013C  DD 0000000000000140  DD 0001F00000000144  DD 0000040000000148  DD 0001D7FC0000014C  DW 00020000014E  DW 800000000150  DD 0004000000000154  DD 0000100000000158  DD 001000000000015C  DD 0000100000000160  DD 0000000000000164  DD 00000010
    MajorLinkerVersion
    MinorLinkerVersion
    SizeOfCode
    SizeOfInitializedData
    SizeOfUninitializedData
    AddressOfEntryPoint
    BaseOfCode
    BaseOfData
    ImageBase
    SectionAlignment
    FileAlignment
    MajorOSVersion
    MinorOSVersion
    MajorImageVersion
    MinorImageVersion
    MajorSubsystemVersion
    MinorSubsystemVersion
    Reserved
    SizeOfImage
    SizeOfHeaders
    CheckSum
    Subsystem
    DLLCharacteristics
    SizeOfStackReserve
    SizeOfStackCommit
    SizeOfHeapReserve
    SizeOfHeapCommit
    LoaderFlags
    NumberOfRvaAndSizes
    IMAGE_
    DATA_DIRECTORY[16]
    Export Table
    Import Table
    Resource Table
    Exception Table
    Certificate File
    Relocation Table
    Data
    Architecture Data
    Global Ptr
    TLS Table
    Load Config Table
    Bound Import Table
    Import Address Table
    Delay Import Descriptor
    COM+ Runtime Header
    Reserved
    Sections
    information
    IMAGE_
    SECTION_
    HEADER[0]
    Name[8]
    000001E8  ASCII".text"000001F0  DD 000126B0000001F4  DD 00001000000001F8  DD 00012800000001FC  DD 0000040000000200  DD 0000000000000204  DD 0000000000000208  DW 00000000020A  DW 00000000020C  DD 60000020    CODE|EXECUTE|READ
    VirtualSize
    VirtualAddress
    SizeOfRawData
    PointerToRawData
    PointerToRelocations
    PointerToLineNumbers
    NumberOfRelocations
    NumberOfLineNumbers
    Characteristics
    b&
    b&
    b&
    IMAGE_
    SECTION_
    HEADER[n]
    00000210  ASCII".data"; SECTION00000218  DD 0000101C ; VirtualSize = 0x101C0000021C  DD 00014000 ; VirtualAddress = 0x1400000000220  DD 00000A00 ; SizeOfRawData = 0xA0000000224  DD 00012C00 ; PointerToRawData = 0x12C0000000228  DD 00000000 ; PointerToRelocations = 0x00000022C  DD 00000000 ; PointerToLineNumbers = 0x000000230  DW 0000     ; NumberOfRelocations = 0x000000232  DW 0000     ; NumberOfLineNumbers = 0x000000234  DD C0000040 ; Characteristics =                        INITIALIZED_DATA|READ|WRITE00000238  ASCII".rsrc"; SECTION00000240  DD 00008960 ; VirtualSize = 0x896000000244  DD 00016000 ; VirtualAddress = 0x1600000000248  DD 00008A00 ; SizeOfRawData = 0x8A000000024C  DD 00013600 ; PointerToRawData = 0x1360000000250  DD 00000000 ; PointerToRelocations = 0x000000254  DD 00000000 ; PointerToLineNumbers = 0x000000258  DW 0000     ; NumberOfRelocations = 0x00000025A  DW 0000     ; NumberOfLineNumbers = 0x00000025C  DD 40000040 ; Characteristics =                        INITIALIZED_DATA|READ
    SECTION[0]
    00000400  EA 22 DD 77 D7 23 DD 77  C*"C.wC.#C.w00000408  9A 18 DD 77 00 00 00 00  E!.C.w....00000410  2E 1E C7 77 83 1D C7 77  ..C.wF..C.w00000418  FF 1E C7 77 00 00 00 00  C?.C.w....00000420  93 9F E7 77 D8 05 E8 77  b.E8C'wC..C(w00000428  FD A5 E7 77 AD A9 E9 77  C=B%C'w&shy;B)C)w00000430  A3 36 E7 77 03 38 E7 77  B#6C'w.8C'w00000438  41 E3 E6 77 60 8D E7 77  AC#C&w`BC'w00000440  E6 1B E6 77 2B 2A E7 77  C&.C&w+*C'w00000448  7A 17 E6 77 79 C8 E6 77  z.C&wyC.C&w00000450  14 1B E7 77 C1 30 E7 77  ..C'wC.0C'wb&
    b&
    b&
    b&
    SECTION[n]
    b&0001BF00  63 00 2E 00 63 00 68 00  c...c.h.0001BF08  6D 00 0A 00 43 00 61 00  m...C.a.0001BF10  6C 00 63 00 75 00 6C 00  l.c.u.l.0001BF18  61 00 74 00 6F 00 72 00  a.t.o.r.0001BF20  11 00 4E 00 6F 00 74 00  ..N.o.t.0001BF28  20 00 45 00 6E 00 6F 00   .E.n.o.0001BF30  75 00 67 00 68 00 20 00  u.g.h. .0001BF38  4D 00 65 00 6D 00 6F 00  M.e.m.o.0001BF40  72 00 79 00 00 00 00 00  r.y.....0001BF48  00 00 00 00 00 00 00 00  ........0001BF50  00 00 00 00 00 00 00 00  ........0001BF58  00 00 00 00 00 00 00 00  ........0001BF60  00 00 00 00 00 00 00 00  ........0001BF68  00 00 00 00 00 00 00 00  ........0001BF70  00 00 00 00 00 00 00 00  ........0001BF78  00 00 00 00 00 00 00 00  ........

    2.2 The Windows NT data

    As mentioned in the preceding section, e_lfanew storage in the MS-DOS data structure refers to the location of the Windows NT information. Hence, if you assume that the pMem pointer relates the start point of the memory space for a selected portable executable file, you can retrieve the MS-DOS header and also the Windows NT headers by the following lines, which you also can perceive in the PE viewer sample (pelib.cpp, PEStructure::OpenFileName()):

    IMAGE_DOS_HEADER        image_dos_header;IMAGE_NT_HEADERS        image_nt_headers;PCHAR pMem;b&memcpy(&image_dos_header, pMem,       sizeof(IMAGE_DOS_HEADER));memcpy(&image_nt_headers,       pMem+image_dos_header.e_lfanew,       sizeof(IMAGE_NT_HEADERS));

    IMAGE_NT_HEADERS structure definition. It makes it possible to grasp what the image NT header maintains to execute a code inside the Windows NT OS. Now, you are conversant with the Windows NT structure; it consists of the "PE" Signature, the File Header, and the Optional Header. Do not forget to take a glimpse at their comments in the MSDN Library and in Table 1.

    It seems to be very simple, the retrieval of the headers information. I recommend inspecting the MSDN library regarding the

    One the whole, I consider merely, in most circumstances, the following cells of the IMAGE_NT_HEADERS structure:

    FileHeader->NumberOfSectionsOptionalHeader->AddressOfEntryPointOptionalHeader->ImageBaseOptionalHeader->SectionAlignmentOptionalHeader->FileAlignmentOptionalHeader->SizeOfImageOptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]              ->VirtualAddressOptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]              ->Size

    You can observe the main purpose of these values clearly, and their role when the internal virtual memory space allocated for an EXE file by the Windows task manager if you pay attention to their explanations in MSDN library, so I am not going to repeat the MSDN annotations here.

    I should make a brief comment regarding the PE data directories, or OptionalHeader-> DataDirectory[], because I think there are a few aspects of interest concerning them. When you come to survey the Optional header through the Windows NT information, you will find that there are 16 directories at the end of the Optional Header, where you can find the consecutive directories, including their Relative Virtual Address and Size. I just mention here the notes from <winnt.h> to clarify these information:

    // Export Directory#define IMAGE_DIRECTORY_ENTRY_EXPORT          0// Import Directory#define IMAGE_DIRECTORY_ENTRY_IMPORT          1// Resource Directory#define IMAGE_DIRECTORY_ENTRY_RESOURCE        2// Exception Directory#define IMAGE_DIRECTORY_ENTRY_EXCEPTION       3// Security Directory#define IMAGE_DIRECTORY_ENTRY_SECURITY        4// Base Relocation Table#define IMAGE_DIRECTORY_ENTRY_BASERELOC       5// Debug Directory#define IMAGE_DIRECTORY_ENTRY_DEBUG           6// Architecture Specific Data#define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE    7// RVA of GP#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR       8// TLS Directory#define IMAGE_DIRECTORY_ENTRY_TLS             9// Load Configuration Directory#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG    10// Bound Import Directory in headers#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT   11// Import Address Table#define IMAGE_DIRECTORY_ENTRY_IAT            12// Delay Load Import Descriptors#define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT   13// COM Runtime descriptor#define IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR 14

    The last one (15) was reserved for use in the future; I have not yet seen any purpose for it, even in PE64.

    For instance, if you want to perceive the relative virtual address (RVA) and the size of the resource data, it is enough to retrieve them by:

    DWORD dwRVA  = image_nt_headers.OptionalHeader->   DataDirectory[IMAGE_DIRECTORY_ENTRY_RESOURCE]->VirtualAddress;DWORD dwSize = image_nt_headers.OptionalHeader->   DataDirectory[IMAGE_DIRECTORY_ENTRY_RESOURCE]->Size;

    To comprehend more regarding the significance of data directories, I forward you to Section 3.4.3 of the Microsoft Portable Executable and the Common Object File Format Specification document by Microsoft, and furthermore Section 6 of this document, where you discern the various types of sections and their applications. You will see the section’s advantage subsequently.

    2.3 The Section Headers and Sections

    You currently observe how the portable executable files declare the location and the size of a section on a disk storage file and inside the virtual memory space allocated for the program with IMAGE_NT_HEADERS-> OptionalHeader->SizeOfImage by the Windows task manager, as well the characteristics to demonstrate the type of the section. To better understand the Section header as my previous declaration, I suggest having a brief look at the IMAGE_SECTION_HEADER structure definition in the MSDN library. For an EXE packer developer, VirtualSize, VirtualAddress, SizeOfRawData, PointerToRawData, and Characteristics cells have significant rules. When developing an EXE packer, you should be clever enough to play with them. There are somet hings to note when you modify them; you should take care to align the VirtualSize and VirtualAddress according to OptionalHeader->SectionAlignment, as well as SizeOfRawData and PointerToRawData in line with OptionalHeader->FileAlignment. Otherwise, you will corrupt your target EXE file and it will never run. Regarding Characteristics, I pay attention mostly to establish a section by IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE | IMAGE_SCN_CNT_INITIALIZED_DATA, I prefer that my new section has the ability to initialize such data during the running process, such as import table; besides, I need it to be able to modify itself by the loader with my settings in the section characteristics to read- and writeable.

    Moreover, you should pay attention to the section names; you can know the purpose of each section by its name. I will just forward you to Section 6 of the Microsoft Portable Executable and the Common Object File Format Specification documents. I believe it represents the totality of sections by their names; this is also included in Table 2.

    Table 2: Section names

    ".text" Code Section
    "CODE" Code Section of file linked by Borland Delphi or Borland Pascal
    ".data" Data Section
    "DATA" Data Section of file linked by Borland Delphi or Borland Pascal
    ".rdata" Section for Constant Data
    ".idata" Import Table
    ".edata" Export Table
    ".tls" TLS Table
    ".reloc" Relocation Information
    ".rsrc" Resource Information

    To comprehend the section headers and also the sections, you can run the sample PE viewer. With this PE viewer, you can realize only the application of the section headers in a file image, so to observe the main significance in the Virtual Memory, you should try to load a PE file by a debugger. The next section represents the main idea of using the virtual address and size in the virtual memory by using a debugger. The last note is about IMAGE_NT_HEADERS-> FileHeader->NumberOfSections, that provides a number of sections in a PE file. Do not forget to adjust it whenever you remove or add some sections to a PE file. I am talking about section injection!

    3 Debugger, Disassembler and some Useful Tools

    In this part, you will become familiar with the necessary and essential equipment to develop your PE tools.

    3.1 Debuggers

    The first essential prerequisite to become a PE tools developer is to have enough experience with bug tracer tools. Furthermore, you should know most of the assembly instructions. To me, the Intel documents are the best references. You can obtain them from the Intel site for IA-32, and on top of that IA-64; the future belongs to IA-64 CPUs, Windows XP 64-bit, and also PE64!

    To trace a PE file, SoftICE by Compuware Corporation, I knew it also as named NuMega when I was at high school, is the best debugger in the world. It implements process tracing by using the kernel mode method debugging without applying Windows debugging application programming interface (API) functions. In addition, I will introduce one perfect debugger in user mode level. It utilizes the Windows debugging API to trace a PE file and also attaches itself to an active process. These API functions have been provided by Microsoft teams, inside the Windows Kernel32 library, to trace a specific process, by using Microsoft tools, or perhaps, to make your own debugger! Some of those API functions inlude:

    3.1.1 SoftICE

    It was in 1987; Frank Grossman and Jim Moskun decided to establish a company called NuMega Technologies in Nashua, NH, to develop some equipment to trace and test the reliability of Microsoft Windows software programs. Now, it is a part of Compuware Corporation and its product has participated to accelerate the reliability in Windows software, and additionally in Windows driver developments. Currently, everyone knows the Compuware DriverStudio that is used to establish an environment for implementing the elaboration of a kernel driver or a system file by aiding the Windows Driver Development Kit (DDK). It bypasses the involvement of DDK to implement a portable executable file of kernel level for a Windows system software developer. For us, only one instrument of DriverStudio is important, SoftICE; this debugger can be used to trace every portable executable file, a PE file for user mode level or a PE file for kernel mode level.

    Figure 1: SoftICE Window

    EAX=00000000EBX=7FFDD000 ECX=0007FFB0 EDX=7C90EB94 ESI=FFFFFFFF EDI=7C919738 EBP=0007FFF0 ESP=0007FFC4 EIP=010119E0 o d i s z a p c
    CS=0008 DS=0023 SS=0010 ES=0023 FS=0030 GS=0000
    SS:0007FFC4=87C816D4F
    0023:01013000 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ……………. 0023:01013010 01 00 00 00 20 00 00 00-0A 00 00 00 0A 00 00 00 ……………. 0023:01013020 20 00 00 00 00 00 00 00-53 63 69 43 61 6C 63 00 ……..SciCalc. 0023:01013030 00 00 00 00 00 00 00 00-62 61 63 6B 67 72 6F 75 ……..backgrou 0023:01013040 6E 64 00 00 00 00 00 00-2E 00 00 00 00 00 00 00 nd…………..
    0010:0007FFC4 4F 6D 81 7C 38 07 91 7C-FF FF FF FF 00 90 FD 7F Om |8 b.| . 0010:0007FFD4 ED A6 54 80 C8 FF 07 00-E8 B4 F5 81 FF FF FF FF T . 0010:0007FFE4 F3 99 83 7C 58 6D 81 7C-00 00 00 00 00 00 00 00 Xm |…….. 0010:0007FFF4 00 00 00 00 E0 19 01 01-00 00 00 00 00 00 00 00 …. ….
    010119E0 PUSH EBP 010119E1 MOV EBP,ESP 010119E3 PUSH -1 010119E5 PUSH 01001570 010119EA PUSH 01011D60 010119EF MOV EAX,DWORD PTR FS:[0] 010119F5 PUSH EAX 010119F6 MOV DWORD PTR FS:[0],ESP 010119FD ADD ESP,-68 01011A00 PUSH EBX 01011A01 PUSH ESI 01011A02 PUSH EDI 01011A03 MOV DWORD PTR SS:[EBP-18],ESP 01011A06 MOV DWORD PTR SS:[EBP-4],0
    :_

    3.1.2 OllyDbg

    It was about four years ago that I first saw this debugger by chance. For me, it was the best choice; I was not wealthy enough to purchase SoftICE, and at that time, SoftICE only had good functions for DOS, Windows 98, and Windows 2000. I found that this debugger supported all kinds of Windows versions. Therefore, I started to learn it very fast, and now it is my favorite debugger for the Windows OS. It is a debugger that can be used to trace all kinds of portable executable files except a Common Language Infrastructure (CLI) file format in user mode level, by using the Windows debugging API. Oleh Yuschuk, the author, is one of worthiest software developers I have seen in my life. He is a Ukrainian who now lives in Germany. I should mention here that his debugger is the best choice for hacker and cracker parties around the world! It is freeware! You can try it from the OllyDbg Homepage.

     

    Figure 2: OllyDbg CPU Window


    (

    3.1.3 Which parts are important in a debugger interface?

    I have introduced two debuggers without talking about how you can employ them, and also which parts you should pay attention to. Regarding using debuggers, I refer you to their instructions in help documents. However, I want to explain briefly the important parts of a debugger; of course, I am talking about low-level debuggers, or in other words, machine-language debuggers of the x86 CPU families.

    All of low-level debuggers consist of the following subdivisions:

    1. Registers viewer.
      EAX
      ECX
      EDX
      EBX
      ESP
      EBP
      ESI
      EDI
      EIP

      o d t s z a p c

    2. Disassembler or Code viewer.
      010119E0 PUSH EBP010119E1 MOV EBP,ESP010119E3 PUSH -1010119E5 PUSH 01001570010119EA PUSH 01011D60010119EF MOV EAX,DWORD PTR FS:[0]010119F5 PUSH EAX010119F6 MOV DWORD PTR FS:[0],ESP010119FD ADD ESP,-6801011A00 PUSH EBX01011A01 PUSH ESI01011A02 PUSH EDI01011A03 MOV DWORD PTR SS:[EBP-18],ESP01011A06 MOV DWORD PTR SS:[EBP-4],0
    3. Memory watcher.
      0023:01013000 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ……………. 0023:01013010 01 00 00 00 20 00 00 00-0A 00 00 00 0A 00 00 00 ……………. 0023:01013020 20 00 00 00 00 00 00 00-53 63 69 43 61 6C 63 00 ……..SciCalc. 0023:01013030 00 00 00 00 00 00 00 00-62 61 63 6B 67 72 6F 75 ……..backgrou 0023:01013040 6E 64 00 00 00 00 00 00-2E 00 00 00 00 00 00 00 nd…………..

       

    4. Stack viewer.
      0010:0007FFC4 4F 6D 81 7C 38 07 91 7C-FF FF FF FF 00 90 FD 7F Om |8 b.| . 0010:0007FFD4 ED A6 54 80 C8 FF 07 00-E8 B4 F5 81 FF FF FF FF T . 0010:0007FFE4 F3 99 83 7C 58 6D 81 7C-00 00 00 00 00 00 00 00 Xm |…….. 0010:0007FFF4 00 00 00 00 E0 19 01 01-00 00 00 00 00 00 00 00 …. ….
    5. Command line, command buttons, or shortcut keys to follow the debugging process.
      Command SoftICE OllyDbg
      Run F5 F9
      Step Into F11 F7
      Step Over F10 F8
      Set Break Point F8 F2

    You can compare Figures 1 and 2 to distinguish the difference between SoftICE and OllyDbg. When you want to trace a PE file, you should mostly consider these five subdivisions. Furthermore, every debugger comprises of some other useful parts; you should discover them by yourself.

    3.2 Disassembler

    You can consider OllyDbg and SoftICE to be excellent disassemblers, but I also want to introduce another disassembler tool that is famous in the reverse engineering world.

    3.2.1 Proview disassembler

    Proview or PVDasm is an admirable disassembler by the Reverse-Engineering-Community; it is still under development and bug fixing. You can find its disassmbler source engine and employ it to create your own disassembler.

    3.2.2 W32Dasm

    W32DASM can disassemble both 16- and 32-bit executable file formats. In addition to its disassembling ability, you can employ it to analyze import, export, and resource data directories data.

    3.2.3 IDA Pro

    All reverse-engineering experts know that IDA Pro can be used to investigate, not only x86 instructions, but that of various kinds of CPU types like AVR, PIC, and so forth. It can illustrate the assembly source of a portable executable file by using colored graphics and tables, and is very useful for any newbie in this area. Furthermore, it has the capability to trace an executable file inside the user mode level in the same way as OllyDbg.

    3.3 Some Useful Tools

    A good PE tools developer is conversant with the tools that save his time, so I recommend that you select some appropriate instruments to investigate the base information under a portable executable file.

    3.3.1 LordPE

    LordPE by y0da is still the first choice to retrieve PE file information with the possibility to modify them.

    3.3.2 PEiD

    PE iDentifier is valuable to identify the type of compilers, packers, and cryptors of PE files. As of now, it can detect more than 500 different signature types of PE files.

    3.3.3 Resource Hacker

    Resource Hacker can be employed to modify resource directory information; icon, menu, version info, string table, and so on.

    3.3.4 WinHex

    WinHex, it is clear what you can do with this tool.

    3.3.5 CFF Explorer

    Eventually, CFF Explorer by Ntoskrnl is what you want to have as a PE Utility tool in your arsenal; it supports PE32/64, PE rebuild included Common Language Infrastructure (CLI) file. In other words, the .NET file, a resource modifier, and much more facilities which can not be found in others. Just try to discover every unimaginable option by hand.

    4 Add a New Section and Change the OEP

    You are ready to do the first step of making your project. I have provided a library to add a new section and rebuild the portable executable file. Before starting, I wnat you to get familiar with the headers of a PE file, by using OllyDbg. You should first open a PE file; that pops up a menu, View->Executable file. Again, you get a popup menu: Special->PE header. You will observe a scene similar to Figure 3. Now, come to the Main Menu View->Memory, and try to distinguish the sections inside the Memory map window.

    Figure 3

    00000000000000020000000400000006000000080000000A0000000C0000000E00000010000000120000001400000016000000180000001A0000001C0000001D0000001E0000001F000000200000002100000022000000230000002400000025000000260000002700000028000000290000002A0000002B0000002C0000002D0000002E0000002F000000300000003100000032000000330000003400000035000000360000003700000038000000390000003A0000003B0000003C

     4D 5A 9000 0300 0000 0400 0000 FFFF 0000 B800 0000 0000 0000 4000 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0000000
     ASCII "MZ" DW 0090 DW 0003 DW 0000 DW 0004 DW 0000 DW FFFF DW 0000 DW 00B8 DW 0000 DW 0000 DW 0000 DW 0040 DW 0000 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DB 00 DD 000000F0
     DOS EXE Signature DOS_PartPag = 90 (144.) DOS_PageCnt = 3 DOS_ReloCnt = 0 DOS_HdrSize = 4 DOS_MinMem = 0 DOS_MaxMem = FFFF (65535.) DOS_ReloSS = 0 DOS_ExeSP = B8 DOS_ChkSum = 0 DOS_ExeIP = 0 DOS_ReloCS = 0 DOS_TablOff = 40 DOS_Overlay = 0 Offset to PE signature

     

    I want to explain how you can plainly change the Offset of Entry Point (OEP) in your sample file, CALC.EXE of Windows XP. First, by using a PE Tool, and also using your PE Viewer, you find OEP, 0x00012475, and Image Base, 0x01000000. This value of OEP is the Relative Virtual Address, so the Image Base value is used to convert it to the Virtual Address.

    Virtual_Address = Image_Base + Relative_Virtual_Address

    DWORD OEP_RVA = image_nt_headers->   OptionalHeader.AddressOfEntryPoint ;// OEP_RVA = 0x00012475DWORD OEP_VA = image_nt_headers->   OptionalHeader.ImageBase + OEP_RVA ;// OEP_VA = 0x01000000 + 0x00012475 = 0x01012475

    PE Maker: Step 1

    Download pemaker1.zip and test1.zip from the files at the end of this article.

    DynLoader(), in loader.cpp, is reserved for the data of the new section—in other words, the Loader.

    DynLoader Step 1

    __stdcall void DynLoader(){_asm{//----------------------------------    DWORD_TYPE(DYN_LOADER_START_MAGIC)//----------------------------------    MOV EAX,01012475h // << Original OEP    JMP EAX//----------------------------------    DWORD_TYPE(DYN_LOADER_END_MAGIC)//----------------------------------}}

    Unfortunately, this source can only be applied for the sample test file. You should complete it by saving the value of the original OEP in the new section, and use it to reach the real OEP. I have accomplished it in Step 2 (Section 5).

    4.1 Retrieve and Rebuild PE file

    I have made a simple class library to recover PE information and to use it in a new PE file.

    CPELibrary Class Step 1

    //----------------------------------------------------------------class CPELibrary{private:    //-----------------------------------------    PCHAR                   pMem;    DWORD                   dwFileSize;    //-----------------------------------------protected:    //-----------------------------------------    PIMAGE_DOS_HEADER       image_dos_header;    PCHAR                   pDosStub;    DWORD                   dwDosStubSize, dwDosStubOffset;    PIMAGE_NT_HEADERS       image_nt_headers;    PIMAGE_SECTION_HEADER   image_section_header[MAX_SECTION_NUM];    PCHAR                   image_section[MAX_SECTION_NUM];    //-----------------------------------------protected:    //-----------------------------------------    DWORD PEAlign(DWORD dwTarNum,DWORD dwAlignTo);    void AlignmentSections();    //-----------------------------------------    DWORD Offset2RVA(DWORD dwRO);    DWORD RVA2Offset(DWORD dwRVA);    //-----------------------------------------    PIMAGE_SECTION_HEADER ImageRVA2Section(DWORD dwRVA);    PIMAGE_SECTION_HEADER ImageOffset2Section(DWORD dwRO);    //-----------------------------------------    DWORD ImageOffset2SectionNum(DWORD dwRVA);    PIMAGE_SECTION_HEADER AddNewSection(char* szName,DWORD dwSize);    //-----------------------------------------public:    //-----------------------------------------    CPELibrary();    ~CPELibrary();    //-----------------------------------------    void OpenFile(char* FileName);    void SaveFile(char* FileName);    //-----------------------------------------};

    In Table 1, the usage of image_dos_header, pDosStub, image_nt_headers, image_section_header [MAX_SECTION_NUM], and image_section[MAX_SECTION_NUM] is clear. You use OpenFile() and SaveFile() to retrieve and rebuild a PE file. Furthermore, AddNewSection() is employed to create the new section, the important step.


    4.2 Create data for the new section

    Full Size Image)

    You can comprehend the difference between incremental link and no-incremental link by looking at the following picture:

    To acquire the virtual address of DynLoader(), you obtain the virtual address of JMP pemaker.DynLoader in the incremental link, but by no-incremental link, the real virtual address is gained by the following code:

    DWORD dwVA= (DWORD) DynLoader;

    This setting is more critical in the incremental link when you try to find the beginning and ending of the Loader, DynLoader(), by CPECryptor::ReturnToBytePtr():

    void* CPECryptor::ReturnToBytePtr(void* FuncName, DWORD findstr){    void* tmpd;    __asm   {        mov eax, FuncName        jmp dfhjg:    inc eaxdf:     mov ebx, [eax]        cmp ebx, findstr        jnz hjg        mov tmpd, eax    }    return tmpd;}

    In pecrypt.cpp, I have represented another class, CPECryptor, to comprise the data of the new section. Nevertheless, the data of the new section is created by DynLoader() in loader.cpp, DynLoader Step 1. You use the CPECryptor class to enter this data in to the new section, and also some other stuff.

    CPECryptor Class Step 1

    //----------------------------------------------------------------class CPECryptor: public CPELibrary{private:    //----------------------------------------    PCHAR pNewSection;    //----------------------------------------    DWORD GetFunctionVA(void* FuncName);    void* ReturnToBytePtr(void* FuncName, DWORD findstr);    //----------------------------------------protected:    //----------------------------------------public:    //----------------------------------------    void CryptFile(int(__cdecl *callback) (unsigned int,                                           unsigned int));    //----------------------------------------};//----------------------------------------------------------------

    4.3 Some notes regarding creating a new PE file

    • Align the VirtualAddress and the VirtualSize of each section by SectionAlignment:
      image_section_header[i]->VirtualAddress=    PEAlign(image_section_header[i]->VirtualAddress,    image_nt_headers->OptionalHeader.SectionAlignment);image_section_header[i]->Misc.VirtualSize=    PEAlign(image_section_header[i]->Misc.VirtualSize,    image_nt_headers->OptionalHeader.SectionAlignment);
    • Align the PointerToRawData and the SizeOfRawData of each section by FileAlignment:
      image_section_header[i]->PointerToRawData =    PEAlign(image_section_header[i]->PointerToRawData,            image_nt_headers->OptionalHeader.FileAlignment);image_section_header[i]->SizeOfRawData =    PEAlign(image_section_header[i]->SizeOfRawData,            image_nt_headers->OptionalHeader.FileAlignment);
    • Correct the SizeofImage by the virtual size and the virtual address of the last section:
      image_nt_headers->OptionalHeader.SizeOfImage =   image_section_header[LastSection]->VirtualAddress +   image_section_header[LastSection]->Misc.VirtualSize;
    • Set the Bound Import Directory header to zero because this directory is not very important to execute a PE file:
      image_nt_headers->   OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT].  VirtualAddress = 0;image_nt_headers->   OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BOUND_                                IMPORT].Size = 0;

    4.4 Some notes regarding linking this VC Project

    • Set Linker->General->Enable Incremental Linking to No (/INCREMENTAL:NO).


      (

    5 Store Important Data and Reach the Original OEP

    Right now, we save the Original OEP and also the Image Base in order to reach to the virtual address of OEP. I have reserved a free space at the end of DynLoader() to store them, DynLoader Step 2.

    PE Maker – Step 2

    Download the pemaker2.zip source files from the end of the article.

    DynLoader Step 2

    __stdcall void DynLoader(){_asm{//------------------------------------    DWORD_TYPE(DYN_LOADER_START_MAGIC)//------------------------------------Main_0:    PUSHAD    // get base ebp    CALL Main_1Main_1:    POP EBP    SUB EBP,OFFSET Main_1    MOV EAX,DWORD PTR [EBP+_RO_dwImageBase]    ADD EAX,DWORD PTR [EBP+_RO_dwOrgEntryPoint]    PUSH EAX    RETN // >> JMP to Original OEP//----------------------------------    DWORD_TYPE(DYN_LOADER_START_DATA1)//----------------------------------//----------------------------------    DWORD_TYPE(DYN_LOADER_END_MAGIC)//----------------------------------}}_RO_dwImageBase:                DWORD_TYPE(0xCCCCCCCC)_RO_dwOrgEntryPoint:            DWORD_TYPE(0xCCCCCCCC)

    The new function, CPECryptor::CopyData1(), will implement the copy of the Image Base value and the Offset of Entry Point value into 8 bytes of free space in the loader.

    5.1 Restore the first register’s context

    It is important to recover the Original Context of the thread. You have not yet done it in the DynLoader Step 2 source code. You can modify the source of DynLoader() to repossess the first Context.

    __stdcall void DynLoader(){_asm{//------------------------------------    DWORD_TYPE(DYN_LOADER_START_MAGIC)//------------------------------------Main_0:    PUSHAD// Save the registers context in stack    CALL Main_1Main_1:    POP EBP// Get Base EBP    SUB EBP,OFFSET Main_1    MOV EAX,DWORD PTR [EBP+_RO_dwImageBase]    ADD EAX,DWORD PTR [EBP+_RO_dwOrgEntryPoint]    MOV DWORD PTR [ESP+1Ch],EAX // pStack.Eax <- EAX    POPAD // Restore the first registers context from stack    PUSH EAX    XOR  EAX, EAX    RETN // >> JMP to Original OEP//----------------------------------    DWORD_TYPE(DYN_LOADER_START_DATA1)//----------------------------------_RO_dwImageBase:                DWORD_TYPE(0xCCCCCCCC)_RO_dwOrgEntryPoint:            DWORD_TYPE(0xCCCCCCCC)//----------------------------------    DWORD_TYPE(DYN_LOADER_END_MAGIC)//----------------------------------}}

    5.2 Restore the original stack

    You also can recover the original stack by setting the value of the beginning stack + 0x34 to the Original OEP, but it is not very important. Nevertheless, in the following code, I have accomplished the loader code by a simple trick to reach the OEP in addition to redecorating the stack. You can observe the implementation by tracing using OllyDbg or SoftICE.

    __stdcall void DynLoader(){_asm{//----------------------------------    DWORD_TYPE(DYN_LOADER_START_MAGIC)//----------------------------------Main_0:    PUSHAD    // Save the registers context in stack    CALL Main_1Main_1:    POP EBP    SUB EBP,OFFSET Main_1    MOV EAX,DWORD PTR [EBP+_RO_dwImageBase]    ADD EAX,DWORD PTR [EBP+_RO_dwOrgEntryPoint]    MOV DWORD PTR [ESP+54h],EAX    // pStack.Eip <- EAX    POPAD    // Restore the first registers context from stack    CALL _OEP_Jump    DWORD_TYPE(0xCCCCCCCC)_OEP_Jump:    PUSH EBP    MOV EBP,ESP    MOV EAX,DWORD PTR [ESP+3Ch]    // EAX <- pStack.Eip    MOV DWORD PTR [ESP+4h],EAX     // _OEP_Jump RETURN pointer <- EAX    XOR EAX,EAX    LEAVE    RETN//----------------------------------    DWORD_TYPE(DYN_LOADER_START_DATA1)//----------------------------------_RO_dwImageBase:                DWORD_TYPE(0xCCCCCCCC)_RO_dwOrgEntryPoint:            DWORD_TYPE(0xCCCCCCCC)//----------------------------------    DWORD_TYPE(DYN_LOADER_END_MAGIC)//----------------------------------}}

    5.3 Approach OEP by structured exception handling

    try-except statement in C++ clarifies the operation of structured exception handling. Besides the assembly code of this code, it elucidates the structured exception handler installation, the raise of an exception, and the exception handler function.

    An exception is generated when a program falls into a fault code execution and an error happens, so in such a special condition, the program immediately jumps to a function called the exception handler from exception handler list of the Thread Information Block.

    The next example of a

    #include "stdafx.h"#include "windows.h"void RAISE_AN_EXCEPTION(){_asm{    INT 3    INT 3    INT 3    INT 3}}int _tmain(int argc, _TCHAR* argv[]){    __try    {        __try{            printf("1: Raise an Exception\n");            RAISE_AN_EXCEPTION();        }        __finally        {            printf("2: In Finally\n");        }    }    __except( printf("3: In Filter\n"), EXCEPTION_EXECUTE_HANDLER )    {        printf("4: In Exception Handler\n");    }    return 0;}
    ; main()00401000: PUSH EBP00401001: MOV EBP,ESP00401003: PUSH -100401005: PUSH 00407160; __try {; the structured exception handler (SEH) installation 0040100A: PUSH _except_handler30040100F: MOV EAX,DWORD PTR FS:[0]00401015: PUSH EAX00401016: MOV DWORD PTR FS:[0],ESP0040101D: SUB ESP,800401020: PUSH EBX00401021: PUSH ESI00401022: PUSH EDI00401023: MOV DWORD PTR SS:[EBP-18],ESP;     __try {00401026: XOR ESI,ESI00401028: MOV DWORD PTR SS:[EBP-4],ESI0040102B: MOV DWORD PTR SS:[EBP-4],100401032: PUSH OFFSET "1: Raise an Exception"00401037: CALL printf0040103C: ADD ESP,4; the raise a exception, INT 3 exception; RAISE_AN_EXCEPTION()0040103F: INT300401040: INT300401041: INT300401042: INT3;     } __finally {00401043: MOV DWORD PTR SS:[EBP-4],ESI00401046: CALL 0040104D0040104B: JMP 004010800040104D: PUSH OFFSET "2: In Finally"00401052: CALL printf00401057: ADD ESP,40040105A: RETN;     }; }; __except( 0040105B: JMP 004010800040105D: PUSH OFFSET "3: In Filter"00401062: CALL printf00401067: ADD ESP,40040106A: MOV EAX,1 ; EXCEPTION_EXECUTE_HANDLER = 10040106F: RETN;     , EXCEPTION_EXECUTE_HANDLER ); {; the exception handler funtion00401070: MOV ESP,DWORD PTR SS:[EBP-18]00401073: PUSH OFFSET "4: In Exception Handler"00401078: CALL printf0040107D: ADD ESP,4; }00401080: MOV DWORD PTR SS:[EBP-4],-10040108C: XOR EAX,EAX; restore previous SEH0040108E: MOV ECX,DWORD PTR SS:[EBP-10]00401091: MOV DWORD PTR FS:[0],ECX00401098: POP EDI00401099: POP ESI0040109A: POP EBX0040109B: MOV ESP,EBP0040109D: POP EBP0040109E: RETN

    Make a Win32 console project, and link and run the preceding C++ code, to perceive the result:

    1: Raise an Exception
    3: In Filter
    2: In Finally
    4: In Exception Handler
    _

    This program runs the exception expression, printf("3: In Filter\n");, when an exception happens—in this example, the INT 3 exception. You can employ other kinds of exception too. In OllyDbg, Debugging options->Exceptions, you can see a short list of different types of exceptions.

    5.3.1 Implement Exception Handler

    You want to construct a structured exception handler to reach OEP. Now, I think you have distinguished the SEH installation, the exception raise, and the exception expression filter, by foregoing the assembly code. To establish your exception handler approach, you need to comprise the following codes:

    • SEH installation:
      LEA EAX,[EBP+_except_handler1_OEP_Jump]PUSH EAXPUSH DWORD PTR FS:[0]MOV DWORD PTR FS:[0],ESP
    • An Exception Raise:
      INT 3
    • Exception handler expression filter:
      _except_handler1_OEP_Jump:   PUSH EBP   MOV EBP,ESP   ...   // EXCEPTION_CONTINUE_SEARCH = 0   MOV EAX, EXCEPTION_CONTINUE_SEARCH   LEAVE   RETN

    So, you yearn to make the ensuing C++ code in assembly language to inaugurate your engine to approach the Offset of the Entry Point by SEH.

    __try    // SEH installation{    __asm    {        INT 3    // An Exception Raise    }}__except( ..., EXCEPTION_CONTINUE_SEARCH ){}// Exception handler expression filter

    In assembly code…

        ; ----------------------------------------------------    ; the structured exception handler (SEH) installation    ; __try {    LEA EAX,[EBP+_except_handler1_OEP_Jump]    PUSH EAX    PUSH DWORD PTR FS:[0]    MOV DWORD PTR FS:[0],ESP    ; ----------------------------------------------------    ; the raise a INT 3 exception    INT 3    INT 3    INT 3    INT 3    ; }    ; __except( ...     ; ----------------------------------------------------    ; exception handler expression filter_except_handler1_OEP_Jump:    PUSH EBP    MOV EBP,ESP    ...    MOV EAX, EXCEPTION_CONTINUE_SEARCH ; EXCEPTION_CONTINUE_SEARCH = 0    LEAVE    RETN    ; , EXCEPTION_CONTINUE_SEARCH ) { }

    The exception value, __except(..., Value), determines how the exception is handled. It can have three values: 1, 0, -1. To understand them, refer to the try-except statement description in the MSDN library. You set it to EXCEPTION_CONTINUE_SEARCH (0), not to run the exception handler function; therefore, by this value, the exception is not recognized. It is simply ignored, and the thread continues its code execution.

    How the SEH installation is implemented

    As you perceived from the illustrated code, the SEH installation is done by the FS segment register. Microsoft Windows 32 bit uses the FS segment register as a pointer to the data block of the main thread. The first 0x1C bytes comprise the information of the Thread Information Block (TIB). Therefore, FS:[00h] refers to ExceptionList of the main thread, Table 3. In your code, you have pushed the pointer to _except_handler1_OEP_Jump in the stack and changed the value of ExceptionList, FS:[00h], to the beginning of the stack, ESP.

    Thread Information Block (TIB)

    typedef struct _NT_TIB32 {   DWORD ExceptionList;   DWORD StackBase;   DWORD StackLimit;   DWORD SubSystemTib;   union {      DWORD FiberData;      DWORD Version;   };   DWORD ArbitraryUserPointer;   DWORD Self;} NT_TIB32, *PNT_TIB32;

    Table 3: FS segment register and Thread Information Block

    DWORD PTR FS:[00h] ExceptionList
    DWORD PTR FS:[04h] StackBase
    DWORD PTR FS:[08h] StackLimit
    DWORD PTR FS:[0Ch] SubSystemTib
    DWORD PTR FS:[10h] FiberData / Version
    DWORD PTR FS:[14h] ArbitraryUserPointer
    DWORD PTR FS:[18h] Self
    5.3.2 Attain OEP by adjusting the Thread Context

    In this part, you effectuate your performance by accomplishing the OEP approach. You change the Context of the thread and ignore every simple exception handling, and let the thread continue the execution, but in the original OEP!

     

    When an exception happens, the context of the processor during the time of the exception is saved in the stack. Through

    MOV EAX, ContextRecordMOV EDI, dwOEP                   ; EAX <- dwOEPMOV DWORD PTR DS:[EAX+0B8h], EDI ; pContext.Eip <- EAX

    Win32 Thread Context structure

    #define MAXIMUM_SUPPORTED_EXTENSION     512typedef struct _CONTEXT {    //-----------------------------------------    DWORD ContextFlags;    //-----------------------------------------    DWORD   Dr0;    DWORD   Dr1;    DWORD   Dr2;    DWORD   Dr3;    DWORD   Dr6;    DWORD   Dr7;    //-----------------------------------------    FLOATING_SAVE_AREA FloatSave;    //-----------------------------------------    DWORD   SegGs;    DWORD   SegFs;    DWORD   SegEs;    DWORD   SegDs;    //-----------------------------------------    DWORD   Edi;    DWORD   Esi;    DWORD   Ebx;    DWORD   Edx;    DWORD   Ecx;    DWORD   Eax;    //-----------------------------------------    DWORD   Ebp;    DWORD   Eip;    DWORD   SegCs;    DWORD   EFlags;    DWORD   Esp;    DWORD   SegSs;    //-----------------------------------------    BYTE    ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];    //----------------------------------------} CONTEXT,*LPCONTEXT;

    Table 4: CONTEXT

    Context Flags 0×00000000 ContextFlags

    Context Debug Registers

    0×00000004 Dr0
    0×00000008 Dr1
    0x0000000C Dr2
    0×00000010 Dr3
    0×00000014 Dr6
    0×00000018 Dr7

    Context Floating Point

    0x0000001C FloatSave StatusWord
    0×00000020 StatusWord
    0×00000024 TagWord
    0×00000028 ErrorOffset
    0x0000002C ErrorSelector
    0×00000030 DataOffset
    0×00000034 DataSelector
    0×00000038

    0×00000087
    RegisterArea [0x50]
    0×00000088 Cr0NpxState
    Context Segments 0x0000008C SegGs
    0×00000090 SegFs
    0×00000094 SegEs
    0×00000098 SegDs
    Context Integer 0x0000009C Edi
    0x000000A0 Esi
    0x000000A4 Ebx
    0x000000A8 Edx
    0x000000AC Ecx
    0x000000B0 Eax
    Context Control 0x000000B4 Ebp
    0x000000B8 Eip
    0x000000BC SegCs
    0x000000C0 EFlags
    0x000000C4 Esp
    0x000000C8 SegSs
    Context Extended Registers

    0x000000CC

    0x000002CB

    ExtendedRegisters[0x200]

    By the following code, you have accomplished the main purpose of coming to OEP by the structured exception handler:

    __stdcall void DynLoader(){_asm{//----------------------------------    DWORD_TYPE(DYN_LOADER_START_MAGIC)//----------------------------------Main_0:    PUSHAD  // Save the registers context in stack    CALL Main_1Main_1:    POP EBP    SUB EBP,OFFSET Main_1 // Get Base EBP    MOV EAX,DWORD PTR [EBP+_RO_dwImageBase]    ADD EAX,DWORD PTR [EBP+_RO_dwOrgEntryPoint]    MOV DWORD PTR [ESP+10h],EAX    // pStack.Ebx <- EAX    LEA EAX,[EBP+_except_handler1_OEP_Jump]    MOV DWORD PTR [ESP+1Ch],EAX    // pStack.Eax <- EAX    POPAD  // Restore the first registers context from stack    //----------------------------------------------------    // the structured exception handler (SEH) installation    PUSH EAX    XOR  EAX, EAX    PUSH DWORD PTR FS:[0]       // NT_TIB32.ExceptionList    MOV DWORD PTR FS:[0],ESP    // NT_TIB32.ExceptionList <-ESP    //----------------------------------------------------    // the raise a INT 3 exception    DWORD_TYPE(0xCCCCCCCC)    //--------------------------------------------------------// -------- exception handler expression filter ----------_except_handler1_OEP_Jump:    PUSH EBP    MOV EBP,ESP    //------------------------------    MOV EAX,DWORD PTR SS:[EBP+010h]   // PCONTEXT: pContext <- EAX    //==============================    PUSH EDI    // restore original SEH    MOV EDI,DWORD PTR DS:[EAX+0C4h]    // pContext.Esp    PUSH DWORD PTR DS:[EDI]    POP DWORD PTR FS:[0]    ADD DWORD PTR DS:[EAX+0C4h],8    // pContext.Esp    //------------------------------    // set the Eip to the OEP    MOV EDI,DWORD PTR DS:[EAX+0A4h] // EAX <- pContext.Ebx    MOV DWORD PTR DS:[EAX+0B8h],EDI // pContext.Eip <- EAX    //------------------------------    POP EDI    //==============================    MOV EAX, EXCEPTION_CONTINUE_SEARCH    LEAVE    RETN//----------------------------------    DWORD_TYPE(DYN_LOADER_START_DATA1)//----------------------------------_RO_dwImageBase:                DWORD_TYPE(0xCCCCCCCC)_RO_dwOrgEntryPoint:            DWORD_TYPE(0xCCCCCCCC)//----------------------------------    DWORD_TYPE(DYN_LOADER_END_MAGIC)//----------------------------------}}

    6 Build an Import Table and Reconstruct the Original Import Table

    There are two ways to use the Windows dynamic link library (DLL) in Windows application programming:

    • Using Windows libraries by additional dependencies


      (

      Full Size Image)

    • Using Windows dynamic link libraries in run-time:
      // DLL function signaturetypedef HGLOBAL (*importFunction_GlobalAlloc)(UINT, SIZE_T);...importFunction_GlobalAlloc __GlobalAlloc;// Load DLL fileHINSTANCE hinstLib = LoadLibrary("Kernel32.dll");if (hinstLib == NULL){   // Error - unable to load DLL}// Get function pointer__GlobalAlloc =   (importFunction_GlobalAlloc)GetProcAddress(hinstLib,                                              "GlobalAlloc");if (addNumbers == NULL){    // Error - unable to find DLL function}FreeLibrary(hinstLib);

    When you make a Windows application project, the linker includes at least kernel32.dll in the base dependencies of your project. Without LoadLibrary() and GetProcAddress() of Kernel32.dll, you cannot load a DLL at run time. The dependencies information is stored in the import table section. By using Dependency Walker, it is not so difficult to observe the DLL module and the functions that are imported into a PE file.

    You attempt to establish your custom import table to conduct your project. Furthermore, you have to fix up the original import table at the end to run the real code of the program.

    PE Maker: Step 3

    Download the pemaker3.zip source files from the end of the article.

    6.1 Construct the Client Import Table

    I strongly advise that you to read Section 6.4 of the Microsoft Portable Executable and the Common Object File Format Specification document. This section contains the principal information to comprehend the import table performance. The import table data is accessible by a second data directory of the optional header from PE headers, so you can access it by using the following code:

    DWORD dwVirtualAddress = image_nt_headers->   OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].      VirtualAddress;DWORD dwSize = image_nt_headers->   OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].      Size;

    The VirtualAddress refers to structures by IMAGE_IMPORT_DESCRIPTOR. This structure contains the pointer to the imported DLL name and the relative virtual address of the first thunk.

    typedef struct _IMAGE_IMPORT_DESCRIPTOR {    union {        DWORD   Characteristics;        DWORD   OriginalFirstThunk;    };    DWORD   TimeDateStamp;    DWORD   ForwarderChain;    DWORD   Name;         // the imported DLL name    DWORD   FirstThunk;   // the relative virtual address of the                          // first thunk} IMAGE_IMPORT_DESCRIPTOR, *PIMAGE_IMPORT_DESCRIPTOR;

    When a program is running, the Windows Task Manager sets the thunks by the virtual address of the function. The virtual address is found by the name of the function. At first, the thunks hold the relative virtual address of the function name, as shown in Table 5; during execution, they are fixed up by the virtual address of the functions (see Table 6).

    Table 5: The Import Table in a file image

    IMAGE_IMPORT_
    DESCRIPTOR[0]
    OriginalFirstThunk    
    TimeDateStamp
    ForwarderChain
    Name_RVA ——> "kernel32.dll",0
    FirstThunk_RVA ——> proc_1_name_RVA ——> 0,0,"LoadLibraryA",0
      proc_2_name_RVA ——> 0,0,"GetProcAddress",0
    proc_3_name_RVA ——> 0,0,"GetModuleHandleA",0
       
    IMAGE_IMPORT_
    DESCRIPTOR[1]
     
    ...  
    IMAGE_IMPORT_
    DESCRIPTOR[n]
     

    Table 6: The Import Table in virtual memory

    IMAGE_IMPORT_DESCRIPTOR[0] OriginalFirstThunk  
    TimeDateStamp
    ForwarderChain
    Name_RVA ------> "kernel32.dll",0
    FirstThunk_RVA ------> proc_1_VA
      proc_2_VA
    proc_3_VA
    ...
    IMAGE_IMPORT_DESCRIPTOR[1]  
    ...  
    IMAGE_IMPORT_DESCRIPTOR[n]  

    You want to make a simple import table to import LoadLibrary(), and GetProcAddress() from Kernel32.dll. You need these two essential API functions to cover other API functions in run-time. The following assembly code shows how easily you can reach your solution:

    0101F000: 00000000 ; OriginalFirstThunk0101F004: 00000000 ; TimeDateStamp0101F008: 00000000 ; ForwarderChain0101F00C: 0001F034 ; Name;       ImageBase + 0001F034                                 -> 0101F034 -> "Kernel32.dll",00101F010: 0001F028 ; FirstThunk; ImageBase + 0001F028 -> 0101F0280101F014: 000000000101F018: 000000000101F01C: 000000000101F020: 000000000101F024: 000000000101F028: 0001F041 ; ImageBase + 0001F041 -> 0101F041                     -> 0,0,"LoadLibraryA",00101F02C: 0001F050 ; ImageBase + 0001F050 -> 0101F050                     -> 0,0,"GetProcAddress",00101F030: 000000000101F034: 'K' 'e' 'r' 'n' 'e' 'l' '3' '2' '.' 'd' 'l' 'l' 0001F041: 00 00 'L' 'o' 'a' 'd' 'L' 'i' 'b' 'r' 'a' 'r' 'y' 'A'0001F050: 00 00 'G' 'e' 't' 'P' 'r' 'o' 'c' 'A' 'd' 'd' 'r' 'e' 's'          's' 00 0000

    After running…

    0101F000: 00000000 ; OriginalFirstThunk0101F004: 00000000 ; TimeDateStamp0101F008: 00000000 ; ForwarderChain0101F00C: 0001F034 ; Name;       ImageBase + 0001F034                                 -> 0101F034 -> "Kernel32.dll",00101F010: 0001F028 ; FirstThunk; ImageBase + 0001F028 -> 0101F0280101F014: 000000000101F018: 000000000101F01C: 000000000101F020: 000000000101F024: 000000000101F028: 7C801D77 ; -> Kernel32.LoadLibrary()0101F02C: 7C80AC28 ; -> Kernel32.GetProcAddress()0101F030: 000000000101F034: 'K' 'e' 'r' 'n' 'e' 'l' '3' '2' '.' 'd' 'l' 'l' 0001F041: 00 00 'L' 'o' 'a' 'd' 'L' 'i' 'b' 'r' 'a' 'r' 'y' 'A'0001F050: 00 00 'G' 'e' 't' 'P' 'r' 'o' 'c' 'A' 'd' 'd' 'r' 'e' 's'          's' 00 0000

    I have prepared a class library to make every import table by using a client string table. The CITMaker class library in itmaker.h; it will build an import table by sz_IT_EXE_strings and also the relative virtual address of the import table.

    static const char *sz_IT_EXE_strings[]={    "Kernel32.dll",    "LoadLibraryA",    "GetProcAddress",    0,,    0,};

    You subsequently employ this class library to establish an import table to support DLLs and OCXs, so this is a general library to present all possible import tables easily. The next step is clarified in the following code.

    CITMaker *ImportTableMaker = new CITMaker( IMPORT_TABLE_EXE );...pimage_section_header=AddNewSection( ".xxx", dwNewSectionSize );// build import table by the current virtual addressImportTableMaker->Build( pimage_section_header->VirtualAddress );memcpy( pNewSection, ImportTableMaker->pMem,ImportTableMaker->dwSize );...memcpy( image_section[image_nt_headers->FileHeader.NumberOfSections-1],        pNewSection,        dwNewSectionSize );...image_nt_headers->OptionalHeader.  DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress  = pimage_section_header->VirtualAddress;image_nt_headers->OptionalHeader.  DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].Size  = ImportTableMaker->dwSize;...delete ImportTableMaker;

    The import table is copied at the beginning of the new section, and the relevant data directory is adjusted to the relative virtual address of the new section and the size of the new import table.

    6.2 Using other API functions at run time

    At this time, you can load other DLLs and find the process address of other functions by using LoadLibrary() and GetProcAddress():

    lea edi, @"Kernel32.dll"//-------------------push edimov eax,offset _p_LoadLibrarycall [ebp+eax] //LoadLibrary(lpLibFileName);//-------------------mov esi,eax    // esi -> hModulelea edi, @"GetModuleHandleA"//-------------------push edipush esimov eax,offset _p_GetProcAddresscall [ebp+eax] //GetModuleHandle=GetProcAddress(hModule, lpProcName);//--------------------

     LoadLibrary() and GetProcAddress() aid you in your effort to reach your intention.

    I want to have a complete imported function table similar in performance done in a real EXE file. If you look inside a PE file, you will discover that an API call is done by an indirection jump through the virtual address of the API function:

    JMP DWORD PTR [XXXXXXXX]

    ...0101F028: 7C801D77      ; Virtual Address of kernel32.LoadLibrary()...0101F120: JMP DWORD PTR [0101F028]...0101F230: CALL 0101F120 ;  JMP to kernel32.LoadLibrary...

    It makes it easy to expand the other part of your project by this performance, so you construct two data tables: the first for API virtual addresses, and the second for the JMP [XXXXXXXX].

    #define __jmp_api               byte_type(0xFF) byte_type(0x25)__asm{...//----------------------------------------------------------------_p_GetModuleHandle:             dword_type(0xCCCCCCCC)_p_VirtualProtect:              dword_type(0xCCCCCCCC)_p_GetModuleFileName:           dword_type(0xCCCCCCCC)_p_CreateFile:                  dword_type(0xCCCCCCCC)_p_GlobalAlloc:                 dword_type(0xCCCCCCCC)//----------------------------------------------------------------_jmp_GetModuleHandle:           __jmp_api   dword_type(0xCCCCCCCC)_jmp_VirtualProtect:            __jmp_api   dword_type(0xCCCCCCCC)_jmp_GetModuleFileName:         __jmp_api   dword_type(0xCCCCCCCC)_jmp_CreateFile:                __jmp_api   dword_type(0xCCCCCCCC)_jmp_GlobalAlloc:               __jmp_api   dword_type(0xCCCCCCCC)//----------------------------------------------------------------...}

    In the succeeding code, you have concluded your ambition to install a custom internal import table! (You cannot call it import table.)

        ...    lea edi,[ebp+_p_szKernel32]    lea ebx,[ebp+_p_GetModuleHandle]    lea ecx,[ebp+_jmp_GetModuleHandle]    add ecx,02h_api_get_lib_address_loop:        push ecx        push edi        mov eax,offset _p_LoadLibrary        call [ebp+eax]    //LoadLibrary(lpLibFileName);        pop ecx        mov esi,eax       // esi -> hModule        push edi        call __strlen        add esp,04h        add edi,eax_api_get_proc_address_loop:            push ecx            push edi            push esi            mov eax,offset _p_GetProcAddress            //GetModuleHandle=GetProcAddress(hModule, lpProcName);            call [ebp+eax]            pop ecx            mov [ebx],eax            mov [ecx],ebx    // JMP DWORD PTR [XXXXXXXX]            add ebx,04h            add ecx,06h            push edi            call __strlen            add esp,04h            add edi,eax            mov al,byte ptr [edi]        test al,al        jnz _api_get_proc_address_loop        inc edi        mov al,byte ptr [edi]    test al,al    jnz _api_get_lib_address_loop    ...

    6.3 Fix up the Original Import Table

    To run the program again, you should fix up the thunks of the actual import table; otherwise, you have a corrupted target PE file. Your code must correct all of the thunks the same as Table 5 to Table 6. Once more,

        ...    mov ebx,[ebp+_p_dwImportVirtualAddress]    test ebx,ebx    jz _it_fixup_end    mov esi,[ebp+_p_dwImageBase]    add ebx,esi             // dwImageBase + dwImportVirtualAddress_it_fixup_get_lib_address_loop:        mov eax,[ebx+00Ch]  // image_import_descriptor.Name        test eax,eax        jz _it_fixup_end        mov ecx,[ebx+010h]  // image_import_descriptor.FirstThunk        add ecx,esi        mov [ebp+_p_dwThunk],ecx    // dwThunk        mov ecx,[ebx]       // image_import_descriptor.Characteristics        test ecx,ecx        jnz _it_fixup_table            mov ecx,[ebx+010h]_it_fixup_table:        add ecx,esi        mov [ebp+_p_dwHintName],ecx    // dwHintName        add eax,esi  // image_import_descriptor.Name + dwImageBase = ModuleName        push eax     // lpLibFileName        mov eax,offset _p_LoadLibrary        call [ebp+eax]               // LoadLibrary(lpLibFileName);        test eax,eax        jz _it_fixup_end        mov edi,eax_it_fixup_get_proc_address_loop:            mov ecx,[ebp+_p_dwHintName]    // dwHintName            mov edx,[ecx]            // image_thunk_data.Ordinal            test edx,edx            jz _it_fixup_next_module            test edx,080000000h      // .IF( import by ordinal )            jz _it_fixup_by_name                and edx,07FFFFFFFh    // get ordinal                jmp _it_fixup_get_addr_it_fixup_by_name:            add edx,esi  // image_thunk_data.Ordinal                         // + dwImageBase = OrdinalName            inc edx            inc edx                  // OrdinalName.Name_it_fixup_get_addr:            push edx //lpProcName            push edi                 // hModule            mov eax,offset _p_GetProcAddress            call [ebp+eax]    // GetProcAddress(hModule, lpProcName);            mov ecx,[ebp+_p_dwThunk]    // dwThunk            mov [ecx],eax  // correction the thunk            // dwThunk => next dwThunk            add dword ptr [ebp+_p_dwThunk], 004h            // dwHintName => next dwHintName            add dword ptr [ebp+_p_dwHintName],004h        jmp _it_fixup_get_proc_address_loop_it_fixup_next_module:        add ebx,014h      // sizeof(IMAGE_IMPORT_DESCRIPTOR)    jmp _it_fixup_get_lib_address_loop_it_fixup_end:    ...

    7 Support DLL and OCX

    Now, you intend to include the dynamic link library (DLL) and OLE-ActiveX Control in your PE builder project. Supporting them is very easy if you pay attention to the two-time arrival into the Offset of Entry Point, the relocation table implementation, and the client import table.

    PE Maker: Step 4

      LoadLibrary(), or an OCX is registered by using LoadLibrary() and GetProcAddress() through calling DllRegisterServer(), the first of the OEP arrival is done.  
    hinstDLL = LoadLibrary( "test1.dll" );hinstOCX = LoadLibrary( "test1.ocx" );_DllRegisterServer = GetProcAddress( hinstOCX,                                     "DllRegisterServer" );_DllRegisterServer();    // ocx register

    Download the pemaker4.zip source files from the end of the article.

    7.1 Twice OEP approach

    The Offset of Entry Point of a DLL file or an OCX file is touched by the main program atleast twice:

    • Constructor: When a DLL is loaded by
    • Destructor: When the main program frees the library usage by FreeLibrary(), the second OEP arrival happens.

       

      FreeLibrary( hinstDLL );FreeLibrary( hinstOCX );

    To perform this, I have employed a trick that causes in the second time again, the instruction pointer (EIP) traveling towards the original OEP by the structured exception handler.

    _main_0:    pushad    // save the registers context in stack    call _main_1_main_1:    pop ebp    sub ebp,offset _main_1    // get base ebp    //---------------- support dll, ocx  -----------------_support_dll_0:    jmp _support_dll_1        // nop; nop;    // << trick                              // in the second time OEP    jmp _support_dll_2_support_dll_1:    //----------------------------------------------------    ...    //---------------- support dll, ocx  1 ---------------    mov edi,[ebp+_p_dwImageBase]    add edi,[edi+03Ch]            // edi -> IMAGE_NT_HEADERS    mov ax,word ptr [edi+016h]    // edi -> image_nt_headers->                                  // FileHeader.Characteristics    test ax,IMAGE_FILE_DLL    jz _support_dll_2        mov ax, 9090h // << trick        mov word ptr [ebp+_support_dll_0],ax_support_dll_2:    //----------------------------------------------------    ...    into OEP by SEH ...

    I hope you caught the trick in the preceding code, but this is not all of it. You have a problem in ImageBase, when the library has been loaded in different image bases by the main program. You should write some code to find the real image base and store it to use forward.

        mov eax,[esp+24h]    // the real imagebase    mov ebx,[esp+30h]    // oep    cmp eax,ebx    ja _no_dll_pe_file_0        cmp word ptr [eax],IMAGE_DOS_SIGNATURE        jne _no_dll_pe_file_0            mov [ebp+_p_dwImageBase],eax_no_dll_pe_file_0:

    This code finds the real image base by investigating the stack information. By using the real image base and the formal image base, you should correct all memory calls inside the image program!! Don't be afraid; it will be done simply by the relocating the table information.

    7.2 Implement relocation table

    To understand the relocation table better, you can take a look at Section 6.6 of the Microsoft Portable Executable and Common Object File Format Specification document. The relocation table contains many packages to relocate the information related to the virtual address inside the virtual memory image. Each package is comprised of an 8-byte header to exhibit the base virtual address and the number of data, demonstrated by the IMAGE_BASE_RELOCATION data structure.

    typedef struct _IMAGE_BASE_RELOCATION {   DWORD   VirtualAddress;   DWORD   SizeOfBlock;} IMAGE_BASE_RELOCATION, *PIMAGE_BASE_RELOCATION;

    Table 7 - The Relocation Table

    Block[1] VirtualAddress
    SizeOfBlock
    type:4 offset:12 type:4 offset:12
    type:4 offset:12 type:4 offset:12
    type:4 offset:12 type:4 offset:12
    ... ... ... ...
    type:4 offset:12 00 00
    Block[2] VirtualAddress
    SizeOfBlock
    type:4 offset:12 type:4 offset:12
    type:4 offset:12 type:4 offset:12
    type:4 offset:12 type:4 offset:12
    ... ... ... ...
    type:4 offset:12 00 00
    ...

     

    ...

     

    Block[n] VirtualAddress
    SizeOfBlock
    type:4 offset:12 type:4 offset:12
    type:4 offset:12 type:4 offset:12
    type:4 offset:12 type:4 offset:12
    ... ... ... ...
    type:4 offset:12 00 00

    Table 7 illustrates the main idea of the relocation table. Furthermore, you can upload a DLL or an OCX file in OllyDbg to observe the relocation table, the ".reloc" section through Memory map window. By the way, you find the position of the relocation table by using the following code in your project:

    DWORD dwVirtualAddress = image_nt_headers->  OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].  VirtualAddress;DWORD dwSize = image_nt_headers->  OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].Size;

    By OllyDbg, you have the same as the following for the ".reloc" section, by using the Long Hex viewer mode. In this example, the base virtual address is 0x1000 and the size of the block is 0x184.

    008E1000 : 00001000  00000184  30163000  30403028008E1010 : 30683054  308C3080  30AC309C  30D830CC008E1020 : 30E030DC  30E830E4  30F030EC  310030F4008E1030 : 3120310D  315F3150  31A431A0  31C031A8008E1040 : 31D031CC  31F431EC  31FC31F8  32043200008E1050 : 320C3208  32143210  324C322C  32583254008E1060 : 3260325C  32683264  3270326C  32B03274

    It relocates the data in the subsequent virtual addresses:

    0x1000 + 0x0000 = 0x10000x1000 + 0x0016 = 0x10160x1000 + 0x0028 = 0x10280x1000 + 0x0040 = 0x10400x1000 + 0x0054 = 0x1054...

    Each package performs the relocation by using consecutive 4 bytes form its internal information. The first byte refers to the type of relocation and the next three bytes are the offset that must be used with the base virtual address and the image base to correct the image information.

    type offset
    03 00 00 00

    What is the type?

    The type can be one of the following values:

    • IMAGE_REL_BASED_ABSOLUTE (0): No effect
    • IMAGE_REL_BASED_HIGH (1): Relocate by the high 16 bytes of the base virtual address and the offset
    • IMAGE_REL_BASED_LOW (2): Relocate by the low 16 bytes of the base virtual address and the offset
    • IMAGE_REL_BASED_HIGHLOW (3): Relocate by the base virtual address and the offset

    What is done in the relocation?

    By relocation, some values inside the virtual memory are corrected according to the current image base by the ".reloc" section packages.

    delta_ImageBase = current_ImageBase - image_nt_headers->OptionalHeader.ImageBase
    mem[ current_ImageBase + 0x1000 ] =   mem[ current_ImageBase + 0x1000 ] + delta_ImageBase ;mem[ current_ImageBase + 0x1016 ] =   mem[ current_ImageBase + 0x1016 ] + delta_ImageBase ;mem[ current_ImageBase + 0x1028 ] =   mem[ current_ImageBase + 0x1028 ] + delta_ImageBase ;mem[ current_ImageBase + 0x1040 ] =   mem[ current_ImageBase + 0x1040 ] + delta_ImageBase ;mem[ current_ImageBase + 0x1054 ] =  mem[ current_ImageBase + 0x1054 ] + delta_ImageBase ;...

    I have employed the following code from Morphine packer to implement the relocation.

        ..._reloc_fixup:    mov eax,[ebp+_p_dwImageBase]    mov edx,eax    mov ebx,eax    add ebx,[ebx+3Ch]    // edi -> IMAGE_NT_HEADERS    // edx ->image_nt_headers->OptionalHeader.ImageBase    mov ebx,[ebx+034h]    sub edx,ebx // edx -> reloc_correction    // delta_ImageBase    je _reloc_fixup_end    mov ebx,[ebp+_p_dwRelocationVirtualAddress]    test ebx,ebx    jz _reloc_fixup_end    add ebx,eax_reloc_fixup_block:    mov eax,[ebx+004h]          //ImageBaseRelocation.SizeOfBlock    test eax,eax    jz _reloc_fixup_end    lea ecx,[eax-008h]    shr ecx,001h    lea edi,[ebx+008h]_reloc_fixup_do_entry:        movzx eax,word ptr [edi]//Entry        push edx        mov edx,eax        shr eax,00Ch            //Type = Entry >> 12        mov esi,[ebp+_p_dwImageBase]//ImageBase        and dx,00FFFh        add esi,[ebx]        add esi,edx        pop edx_reloc_fixup_HIGH:              // IMAGE_REL_BASED_HIGH        dec eax        jnz _reloc_fixup_LOW            mov eax,edx            shr eax,010h        //HIWORD(Delta)            jmp _reloc_fixup_LOW_fixup_reloc_fixup_LOW:               // IMAGE_REL_BASED_LOW            dec eax        jnz _reloc_fixup_HIGHLOW        movzx eax,dx            //LOWORD(Delta)_reloc_fixup_LOW_fixup:            add word ptr [esi],ax// mem[x] = mem[x] + delta_ImageBase        jmp _reloc_fixup_next_entry_reloc_fixup_HIGHLOW:           // IMAGE_REL_BASED_HIGHLOW            dec eax        jnz _reloc_fixup_next_entry        add [esi],edx           // mem[x] = mem[x] + delta_ImageBase_reloc_fixup_next_entry:        inc edi        inc edi                 //Entry++        loop _reloc_fixup_do_entry_reloc_fixup_next_base:    add ebx,[ebx+004h]    jmp _reloc_fixup_block_reloc_fixup_end:    ...

    7.3 Build a special import table

    To support the OLE-ActiveX Control registration, you should present an appropriate import table to your target OCX and DLL file. Therefore, I have established an import table by the following string:

    const char *sz_IT_OCX_strings[]={   "Kernel32.dll",   "LoadLibraryA",   "GetProcAddress",   "GetModuleHandleA",   0,   "User32.dll",   "GetKeyboardType",   "WindowFromPoint",   0,   "AdvApi32.dll",   "RegQueryValueExA",   "RegSetValueExA",   "StartServiceA",   0,   "Oleaut32.dll",   "SysFreeString",   "CreateErrorInfo",   "SafeArrayPtrOfIndex",   0,   "Gdi32.dll",   "UnrealizeObject",   0,   "Ole32.dll",   "CreateStreamOnHGlobal",   "IsEqualGUID",   0,   "ComCtl32.dll",   "ImageList_SetIconSize",   0,   0,};

    Without these API functions, the library can not be loaded, and moreover the DllregisterServer() and DllUregisterServer() will not operate. In CPECryptor::CryptFile, I have distinguished between EXE files and DLL files in the initialization of the new import table object during creation:

    if(( image_nt_headers->FileHeader.Characteristics             & IMAGE_FILE_DLL ) == IMAGE_FILE_DLL ){    ImportTableMaker = new CITMaker( IMPORT_TABLE_OCX );}else{    ImportTableMaker = new CITMaker( IMPORT_TABLE_EXE );}

     

    8 Preserve the Thread Local Storage

    By using Thread Local Storage (TLS), a program is able to execute a multithreaded process, This performance mostly is used by Borland linkers: Delphi and C++ Builder. When you pack a PE file, you should take care to keep the TLS clean; otherwise, your packer will not support Borland Delphi and C++ Builder linked EXE files. To comprehend TLS, I refer you to Section 6.7 of the Microsoft Portable Executable and Common Object File Format Specification document. You can observe the TLS structure by IMAGE_TLS_DIRECTORY32 in winnt.h.

    typedef struct _IMAGE_TLS_DIRECTORY32 {   DWORD   StartAddressOfRawData;   DWORD   EndAddressOfRawData;   DWORD   AddressOfIndex;   DWORD   AddressOfCallBacks;   DWORD   SizeOfZeroFill;   DWORD   Characteristics;} IMAGE_TLS_DIRECTORY32, * PIMAGE_TLS_DIRECTORY32;

    MessageBox() from user32.dll.

    To keep the TLS directory safe, I have copied it in a special place inside the loader:

    ..._tls_dwStartAddressOfRawData:   dword_type(0xCCCCCCCC)_tls_dwEndAddressOfRawData:     dword_type(0xCCCCCCCC)_tls_dwAddressOfIndex:          dword_type(0xCCCCCCCC)_tls_dwAddressOfCallBacks:      dword_type(0xCCCCCCCC)_tls_dwSizeOfZeroFill:          dword_type(0xCCCCCCCC)_tls_dwCharacteristics:         dword_type(0xCCCCCCCC)...

    It is necessary to correct the TLS directory entry in the Optional Header:

    if(image_nt_headers->   OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_TLS].   VirtualAddress!=0){   memcpy(&pDataTable->image_tls_directory,          image_tls_directory,          sizeof(IMAGE_TLS_DIRECTORY32));   dwOffset=DWORD(pData1)-DWORD(pNewSection);   dwOffset+=sizeof(t_DATA_1)-sizeof(IMAGE_TLS_DIRECTORY32);   image_nt_headers->      OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_TLS].      VirtualAddress=dwVirtualAddress + dwOffset;}

    9 Inject Your Code

    You are ready to place your code inside the new section. Your code is a "Hello World!" message by

    ...push MB_OK | MB_ICONINFORMATIONlea eax,[ebp+_p_szCaption]push eaxlea eax,[ebp+_p_szText]push eaxpush NULLcall _jmp_MessageBox// MessageBox(NULL, szText, szCaption, MB_OK | MB_ICONINFORMATION) ;...

    PE Maker: Step 5

    Download the pemaker5.zip source files from the end of the article.

    10 Conclusion

    By reading this article, you have perceived how easily you can inject code to a portable executable file. You can complete the code by using the source of other packers, create a packer in the same way as Yoda's Protector, and make your packer undetectable by mixing up with Morphine source code. I hope that you have enjoyed this brief discussion of one part of the reverse engineering field. See you again in the next discussion!

     

    EXCEPTION_POINTERS, you have access to the pointer of ContextRecord. The ContextRecord has the CONTEXT data structure, as seen in Table 4. This is the thread context during the exception time. When you ignore the exception by EXCEPTION_CONTINUE_SEARCH (0), the instruction pointer, as well as the context, will be set to ContextRecord to return to the previous condition. Therefore, if you change the Eip of the Win32 Thread Context to the Original Offset of Entry Point, it will come clearly into OEP.Full Size Image)

    0

    Armadillo标准壳完全扫盲


    转至: http://hi.baidu.com/%CC%EC%CD%E2%C3%AB%B3%E6/blog

    【前言】
    本人初学脱壳,以前只会用自动脱壳器,手动只脱过upx的壳,实在是菜鸟一个。日前有幸拿到一个共享软件,用peid一查,Armadillo 1.xx – 2.xx -> Silicon Realms Toolworks [Overlay],俺出生牛犊不怕虎,见壳就有脱的冲动,用od载入一看,傻了眼,这壳和upx的完全不同,入口点和一般程序差不多嘛。遂知道自己水平不济,驱猫上看雪拜读各位前辈的文章。无奈本人水平实在有限,看了大半天还是没理清楚过程。想起马gg曾经说过,实践是检验真理的唯一标准,于是操起工具对该软件大卸七块。经过2天的仔细研习,终于悟得精要,成功把壳干掉了。鉴于感觉入门门槛确实有点高,因此特写此文以帮助菜鸟们迈过刀山火海,飞向光明之巅:D

    【术语解释】
    为什么我要写这一段呢?因为我发现看高手们的脱文,最难逾越的一关是术语。高手们脱文中的各种说法,并不能马上就明白过来究竟是什么东西。因此,希望在这里把Armadillo脱文经常遇到的几个术语稍作解释。本人水平有限,如果解释有误请指出。

    [OEP] 这个是Original Entry Point的缩写,中文字面意思就是程序的原入口地址。为什么叫“原”呢?通常加壳软件会把原来的程序编码存放,以防止静态反汇编分析,并在执行前先运行一段解码的程序。所以,加壳后的程序,其入口地址是直接指向解码部分的代码,而非原来的程序入口。我们脱壳所要做的工作,就是还原出原来的程序,并且每次执行时直接从原入口地址开始执行(而不需要再运行用于解码的“壳”),因此需要得知原入口地址是什么,即OEP。

    [Armadillo] 传说中的猛壳,因为拼写太长,也有人缩写为arm壳。它使用多种加密手段以防止脱壳,比如检测debugger、修改IAT、还有高级版本的stolen byte和双线程解码。

    [IAT] Import Address Table的缩写,也有叫输入表,引入表。它用来保存程序用到的API函数的入口地址。

    [RVA] Relative Virtual Address,相对虚拟地址。win32系统会把进程读入到内存中执行,所以存在着内存地址和文件偏移的转换关系。PE文件头里面会有一个内存基址base,原来在文件中偏移为x的内容,在内存里面的偏移就变成base+x。为了区分这两种地址偏移,通常叫文件中的偏移为RVA

    [magic jump](一般破文是按10多次或者20多次F9,就来到magicjump。我根本不知道怎么去判断一个新软件的magicjump在哪里,也不知道那个次数是怎么得来的,不怕,下面我会教一种我认为比较好的方法)其实所谓magic jump,是指跳过改写IAT的代码段。Armadillo的解壳过程有一个特点,就是会改写IAT。(这里我用的是“改写”而不是某些文章中的“破坏”是有原因的。曾经我在这里也困惑过,破坏带有不可恢复的意思,事实上IAT对应的地址并没有完全破坏,只是被改写成更难辨认的形式。这里举一个具体例子)

    00E6E0E1     mov edx,[EA01B8]     // ~= kernel32.dll/00D4/FindNextFileA
    00E6E0E7     add edx,64
    00E6E0EA     call edx
    00E6E0EC     mov edx,[EA0144]     // ~= kernel32.dll/016F/GetModuleFileNameW
    00E6E0F2     add edx,64
    00E6E0F5     mov ecx,5

    这个是被改写后的IAT指向的一端程序段。里面实际工作是作还原工作。先取出edx(这里对应一个假API),然后加上64偏移才得到真正的API,再进行函数调用。FindNextFileA后面的偏移64是GetTickCount,GetModuleFileNameW后面是GetModuleHandleA,所以上面的代码相当于
    call kernel32.GetTickCount
    nop

    call kernel32.GetModuleHandleA

    这样可以使得手动脱壳过程中把IAT表弄坏(因为无法识别出正确的API),但是加壳程序却可以正常运行。是不是很狡猾?解决办法也简单,在脱壳的过程中避开执行改写IAT表的代码段,只需要修改一条指令,这条指令,正是magic jump!

    能够坚持看到这里是否已经有点烦闷了?基本理论就这么多了。准备好工具了吗?让我们马上开始。

    【工具】OD、LordPE、ImportREC
    【过程】
    【Action 1】 明察暗访OEP
    OD载入程序,用插件隐藏OD,忽略所有异常,alt_m查看内存映射,在00401000处下内存读取断点,F9
    程序停下来了,看到没有,熟悉的开头。没有看到?肯定你遇到异常了,shift_F9试试?
    005E14E4      55               push ebp
    005E14E5      8BEC             mov ebp,esp
    005E14E7      83C4 E4          add esp,-1C

    我们找到OEP了,马上记下吧。Action 1目标完成:OEP=001E14E4
    等等,是不是打错字了?不是005E14E4吗?还记得RVA吗?通常来说,windows会把程序读到从00400000开始的连续内存空间(当然也不是一成不变,只是通常碰到的情况都是这样),也就是说你看到的OEP 005E14E4是内存的地址,它的RVA是001E14E4。明白了吗?

    【Action 2】攻下桥头堡
    运行到OEP预示着解码阶段的完成了。所以理论上现在内存中的是已解码的程序。先不要动OD,保持在OEP入口。运行LordPE,选刚刚运行的程序的线程,full dump,Action 2完成!

    先别对着dump出来的exe笑啊,如果现在那个是最终的脱壳结果,Armadillo就不叫猛壳了,我刚刚写的一堆理论也就白费劲。喝口水再继续吧。下面才到重点。

    【Action 3】扫清地雷阵
    OD没有关掉吧?恩,别动它,继续保持。运行ImportREC,选择程序进程,在下面的IAT Infos needed填入刚才拿到的OEP。AutoSearch,看到RVA框变了,那个就是IAT的地址和大小了。我这里找到的数值是001ED240
    回到OD,d 5ed240(还记得刚刚说过的内存偏移的换算关系吗?),看到什么了?那个就是IAT呀。记下它的样子。然后分别在第一个项目和最后一个项目下硬件写入断点。(为什么用硬件捏?因为它不影响速度,而且重新运行的时候不会没掉,呵呵)
    下面重新运行吧。F9,碰到硬件断点了。还记得IAT的样子吗?继续F9,直到第一个条目和你刚刚记下的一样。现在按page up,一直向上找GetModuleHandleA

    00E86AB1      6A 00            push 0
    00E86AB3      FF15 D400E900    call dword ptr ds:[E900D4]                ; kernel32.GetModuleHandleA
    00E86AB9      3985 90C4FFFF    cmp dword ptr ss:[ebp-3B70],eax
    00E86ABF      75 0F            jnz short 00E86AD0
    00E86AC1      C785 8CC4FFFF 8>mov dword ptr ss:[ebp-3B74],0E95180
    00E86ACB      E9 C4000000      jmp 00E86B94
    00E86AD0      83A5 68C2FFFF 0>and dword ptr ss:[ebp-3D98],0
    00E86AD7      C785 64C2FFFF C>mov dword ptr ss:[ebp-3D9C],0E957C0
    00E86AE1      EB 1C            jmp short 00E86AFF
    00E86AE3      8B85 64C2FFFF    mov eax,dword ptr ss:[ebp-3D9C]
    00E86AE9      83C0 0C          add eax,0C
    00E86AEC      8985 64C2FFFF    mov dword ptr ss:[ebp-3D9C],eax
    00E86AF2      8B85 68C2FFFF    mov eax,dword ptr ss:[ebp-3D98]
    00E86AF8      40               inc eax
    00E86AF9      8985 68C2FFFF    mov dword ptr ss:[ebp-3D98],eax
    00E86AFF      8B85 64C2FFFF    mov eax,dword ptr ss:[ebp-3D9C]
    00E86B05      8338 00          cmp dword ptr ds:[eax],0
    00E86B08      0F84 86000000    je 00E86B94
    00E86B0E      8B85 64C2FFFF    mov eax,dword ptr ss:[ebp-3D9C]
    00E86B14      8B40 08          mov eax,dword ptr ds:[eax+8]
    00E86B17      83E0 01          and eax,1
    00E86B1A      85C0             test eax,eax
    00E86B1C      74 25            je short 00E86B43
    00E86B1E      A1 2800EA00      mov eax,dword ptr ds:[EA0028]
    00E86B23      8B0D 2800EA00    mov ecx,dword ptr ds:[EA0028]
    00E86B29      8B40 20          mov eax,dword ptr ds:[eax+20]
    00E86B2C      3341 40          xor eax,dword ptr ds:[ecx+40]
    00E86B2F      8B0D 2800EA00    mov ecx,dword ptr ds:[EA0028]
    00E86B35      3341 28          xor eax,dword ptr ds:[ecx+28]
    00E86B38      25 80000000      and eax,80
    00E86B3D      85C0             test eax,eax
    00E86B3F      74 02            je short 00E86B43
    00E86B41    ^ EB A0            jmp short 00E86AE3
    00E86B43      8B85 68C2FFFF    mov eax,dword ptr ss:[ebp-3D98]
    00E86B49      8B0D 74B7E900    mov ecx,dword ptr ds:[E9B774]
    00E86B4F      8B15 2800EA00    mov edx,dword ptr ds:[EA0028]
    00E86B55      8B0481           mov eax,dword ptr ds:[ecx+eax*4]
    00E86B58      3342 24          xor eax,dword ptr ds:[edx+24]
    00E86B5B      8B0D 2800EA00    mov ecx,dword ptr ds:[EA0028]
    00E86B61      3341 28          xor eax,dword ptr ds:[ecx+28]
    00E86B64      8B0D 2800EA00    mov ecx,dword ptr ds:[EA0028]
    00E86B6A      3341 44          xor eax,dword ptr ds:[ecx+44]
    00E86B6D      8B0D 2800EA00    mov ecx,dword ptr ds:[EA0028]
    00E86B73      3341 6C          xor eax,dword ptr ds:[ecx+6C]
    00E86B76      3985 90C4FFFF    cmp dword ptr ss:[ebp-3B70],eax

    你看到的这段可能会跟我给出的有点差异,不过很好认,会有一段mov和xor交错出现的地方,并且mov语句是完全相同的。这里是00E86B1E-00E86B76

    向上找可以跳过这段代码的转跳语句,这里是
    00E86B08      0F84 86000000    je 00E86B94     ;magic jump!!!!!!!!

    我看到其他教程,这句是je short的,所以可能是Armadillo版本不同。不过道理都是一样,避开对IAT表的改写。
    把这句改成jmp,再按F9,遇到第二个硬件断点,这时IAT转换完成。这个可是没有被做过手脚的完整IAT啊~
    哦,这里别忘了,回到刚刚修改的jmp那里,改回je啊。不然后面的解码会出错导致程序异常终止了。(至少我脱的这个壳会这样。好像只有很少的脱文提到要恢复指令,反正恢复也没坏,多做一步吧,不然异常了可能还要重新来过)
    再bp 005e14e4,在OEP处下断,F9,运行到OEP

    【Action 4】长驱直入,胜利会师
    拿出ImportREC出来吧,重新选一下进程,autosearch,步骤应该都熟悉了。这次可以点Get Imports了。如果还有unresolved pointer,就点Show Invalid,Trace Level1试试,剩下的用Cut thunk全部干掉。然后fix dump,选择Action 2 dump出来的exe,应该就多出来一个文件名后面多带一个_的exe文件。这个是脱壳后独立运行的exe啊。试试能不能运行,不行的话,调整一下ImportREC的参数再试试,有些软件不能用Add new section的。把auto search的结果填到New Import Infos,去掉Add new section再试一遍。

    【Action 5】清除残余势力
    脱壳出来的程序很大,因为里面包含了很多已经没用的解码程序段。为了做到完美脱壳,我们可以把没用的代码清理掉。主要过程可以参考《脱壳后软件减肥大法》http://www.pediy.com/bbshtml/BBS6/pediy6313.htm,这里就不赘述了。不过调整.idata保证VA连续的那一步我不是按它的,不需要手动调整,直接用LordPE的rebuild PE就可以了,有现成工具干吗还要造轮子了?

    【后记】
    当我看到脱壳出来的程序正常运行时,有一种兴奋的感觉。也许我是脱壳菜鸟,这些对高手们确实不值得一提。可是正如fly斑竹所说,我知道自己进阶了。把过程和大家共享,希望大家可以跨过入门的门槛,共同进步。

    0

    Shell编程 – 傻瓜教程1


        外壳扩展( Extention)是一个能向外壳(资源管理器)添加一些功能的COM对象。这有很多的内容,但是却很少有关于它们的易懂的文档告诉我们如何去编写这些外壳(Shell)程序。如果你想做对外壳很深入的了解,我极力向你推荐Dino Esposito 的非常好的一本书《Visual C++ Windows Shell Programming》。但是对于那些没有这本书并且仅仅关心如何去编写外壳扩展的人,我写的一指南将会令你非常惊讶,如果并非如此的话也能给你理解如何编写外壳扩展提供很好的帮助。要阅读这一指南,确保你对COMATL要相当熟悉。

    第一部分包括了对外壳扩展的概要的介绍,并提供了一个上下文菜单扩展的例程来使你对以后的部分中充满兴趣。

    什么是外壳扩展呢?

    这有两部分,外壳和扩展(extension)。外壳指的是资源管理器(Explorer),而扩展是指当一个预订的事件(如:右键单击一个.doc文档)发生时,被资源管理器调用的你写的代码。所以以个外壳扩展是一个向资源管理器添加特色的COM对象。

    一个外壳扩展是一个进程中服务器,它实现了一些与资源管理器通信的借口。而在我看来,ATL是快速实现一个扩展并使它运行的最简单的方法,因为你不用为一遍又一遍的写QueryInterface()AddRef()而大伤脑筋。而且在Windows NT/2000下调试扩展也变得更为容易。

    有很多种的扩展,每种扩展在不同的事件发生时被调用。下面是一些比较通用的类型和它们被调用的情况:

    类型

    什么时候被调用

    可以做什么

    上下文菜单

    用户在文件或目录右键单击时。在外壳扩展4.71版本以上,在目录窗口的背景上右键单击也将被调用。

    向上下文菜单添加项目。

    属性单

    文件的属性单被显示时。

    向属性单添加一个属性页。

    拖扔

    用户右键拖动项目并把它扔在一个目录窗口活着桌面上时。

    添加项目至上下文菜单。

    用户拖一个项目并把它扔到一个文件上时。

    任何你想做的事。

    查询信息(外壳版本4.71+)

    用户鼠标在一个文件或像我的电脑一样的其他外壳对象上悬停时。

    返回一个资源管理器在工具条提示上的字符串。

    到现在为止你可能为什么一个扩展看起来想在资源管理器里。如果你安装了WinZip(有谁没有吗?),它就包括了许多种的外壳扩展,其中一个就是上下文句柄。下面世WinZip 8 为了压缩文件添加到上下文菜单的截图:

    WinZip包含了添加菜单项目的代码,并提供敏感帮助(显示在资源管理器状态条的文本),并在用户选择WinZip命令之一时起作用。

    WinZip还包含了拖和扔的句柄。这个类型和上下文菜单扩展非常类似,但是它仅仅在用户通过鼠标右键拖动一个文件时才被调用。下面是WinZip的拖扔句柄如何添加上下文菜单:

    还有很多种其他类型(微软一直往新版本的Windows里添加更多内容)。到现在,我们已经看到了上下文菜单扩展,因为它非常容易编写,我们将很容易的看到它的结果(很快就能满意)。

    在我们开始编码以前,有一些提示,它将使我们做起来更加容易。当你促成一个外壳扩展被资源管理器调用的时候,它将在内存中呆上一小会儿,从而使它不能立即被重建(rebuild)。为了使资源管理器更加频繁的卸载这些扩展,创建这个注册表键:

    HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\AlwaysUnloadDLL

    并把它的默认值设为”1”。在Windows 9x系列中,这是最好的方法。在NT/2000,到如下的键:

    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer

    创建一个叫做DesktopProcess的双字节值,使它的值为1。这使得桌面和任务栏运行在一个进程中,后发的资源管理器运行在它自己的进程里。这就意味着你可以使用一个单独的资源管理器窗口来调试,并且当你关掉它的时候,你的DLL也会自动的被卸载,避免了该文件仍然在使用得问题。要使得你的注册表修改生效的话,你必须注销并且重新登录。

    我将稍晚一些解释如何在Win 9x下进行调试。

    开始一个上下文菜单扩展它能做什么?

    让我们开始简单的做一个扩展,它仅仅弹出一个消息框表示它已经在工作了。我们将对扩展名为.txt的文件设置一个钩子,这样当用户右键单击一个文本文件的时候,我们的扩展就能被调用了。

    使用AppWizard 开始

    好了,现在是我们开始的时候了。那是什么?我还没有告诉你如何使用神秘的外壳扩展接口?不要担心,我将在接下来的过程中为你解释。我发现如果一个概念被解释,有一个例子更容易明白,通过例子代码你很快就能理解。我将会先解释任何东西,然后给出代码,但是我发现还是不容易吸收。总之,启动你的MSVC吧,我们要开始了。

    运行AppWizard ,做一个新的ATL COM wizard app。我们叫它SimpleExt 。在向导中保持所有默认选项,单击完成。我们现在就有了一个空的将会生成DLLATL项目,但是我们必须添加自己的外壳扩展COM对象。在ClassView树中,右键单击SimpleExt classes 项,选择New ATL Object

    ATL Object 向导,第一面板已经选择了Simple Object ,只要单击下一步就行了。在第二面板中,在Short Name 编辑控件中输入SimpleShlExt ,然后单击确定(面板中的其它的编辑框将会自动完成)。这就创建了一个类名为CSimpleShlExt 的类,它包含了实现一个COM对象的基本代码。我们将向这个类添加我们的代码。

    初始化接口

    当我们的外壳扩展被装载的时候,资源管理器调用我们的QueryInterface()函数获取一个指向IShellExtInit 接口的指针。这个接口只有一个方法,Initialize(),它的原型如下:

    HRESULT IShellExtInit::Initialize (
        LPCITEMIDLIST pidlFolder,
        LPDATAOBJECT pDataObj,
        HKEY hProgID );

    资源管理器使用这个方法给我们不同的信息。pidlFolder 是包含有正在被作用的文件的文件夹的PIDL(PIDL[pointer to an ID list]是唯一标志外壳中任一对象(无论是否是文件系统对象)的数据结构。pDataObj 是一个IDataObject 接口指针,通过它我们可以获得被作用的文件的文件名。hProgID 是一个打开的HKEY ,通过它我们可以访问包含有我们的DLL注册数据的注册表键。在这个简单的扩展中,我们只需要用到pDataObj参数。

    添加这个接口方法到我们的COM 对象中,先打开SimpleShlExt.h 文件,并添加如下用红色书写的代码行:

    #include <shlobj.h>
    #include <comdef.h>
     
     ATL_NO_VTABLE CSimpleShlExt : 
        public CComObjectRootEx<CComSingleThreadModel>,
        public CComCoClass<CSimpleShlExt, &CLSID_SimpleShlExt>,
        public IDispatchImpl<ISimpleShlExt, &IID_ISimpleShlExt, &LIBID_SIMPLEEXTLib>,
        public IShellExtInit
    {
    BEGIN_COM_MAP(CSimpleShlExt)
        COM_INTERFACE_ENTRY(ISimpleShlExt)
        COM_INTERFACE_ENTRY(IDispatch)
        COM_INTERFACE_ENTRY(IShellExtInit)
    END_COM_MAP()

    这个COM_MAP是说明了ATL如何实现它的QueryInterface()。这个列表告诉ATL其他使用QueryInterface()的程序可以从我们这儿获得什么。

    接着,在类的声明当中,添加Initialize()函数。此外,我们还需要一个保存文件名的变量:

    protected:
        TCHAR m_szFile [MAX_PATH];
     
    public:
        // IShellExtInit
        STDMETHOD(Initialize)(LPCITEMIDLIST, LPDATAOBJECT, HKEY);

    接下来,在SimpleShlExt.cpp 文件中,添加该函数的定义:

    HRESULT CSimpleShlExt::Initialize ( 
        LPCITEMIDLIST pidlFolder,
        LPDATAOBJECT pDataObj,
        HKEY hProgID )

    我们所要做的就是获得被右键单击的文件的文件名,并把它显示在一个消息框中。如果有很多个文件被选中,你可以通过pDataObj 接口指针访问它们。但是为了保持该例子的简单性,我只要获得第一个文件的文件名。

    文件名被保存为与你使用WS_EX_ACCEPTFILES样式拖和扔一个文件到窗口时用到的一个相同的格式。那就意味着,我们获得文件名使用了相同的API: DragQueryFile()。我们通过获得包含在IDataObject 中的数据的句柄开始这个函数:

    {
    FORMATETC fmt = { CF_HDROP, NULL, DVASPECT_CONTENT, -1, TYMED_HGLOBAL };
    STGMEDIUM stg = { TYMED_HGLOBAL };
    HDROP     hDrop;
     
        // Look for CF_HDROP data in the data object.
        if ( FAILED( pDataObj->GetData ( &fmt, &stg )))
            {
            // Nope! Return an "invalid argument" error back to Explorer.
            return E_INVALIDARG;
            }
     
        // Get a pointer to the actual data.
        hDrop = (HDROP) GlobalLock ( stg.hGlobal );
     
        // Make sure it worked.
        if ( NULL == hDrop )
            {
            return E_INVALIDARG;
            }

    要注意,错误检查是极其重要的,尤其是指针。因为我们的扩展运行在资源管理器的进程空间当中,如果我们的程序毁坏的话,同样会让资源管理器也毁坏的。在Win 9x下,这可能就意味着重新启动。

    现在,我们有了一个HDROP 句柄,我们可以获得我们需要的文件名了。

        // Sanity check – make sure there is at least one filename.
    UINT uNumFiles = DragQueryFile ( hDrop, 0xFFFFFFFF, NULL, 0 );
     
        if ( 0 == uNumFiles )
            {
            GlobalUnlock ( stg.hGlobal );
            ReleaseStgMedium ( &stg );
            return E_INVALIDARG;
            }
     
    HRESULT hr = S_OK;
     
        // Get the name of the first file and store it in our member variable m_szFile.
        if ( 0 == DragQueryFile ( hDrop, 0, m_szFile, MAX_PATH ))
            {
            hr = E_INVALIDARG;
            }
     
        GlobalUnlock ( stg.hGlobal );
        ReleaseStgMedium ( &stg );
     
        return hr;
    }

    如果我们返回E_INVALIDAR,在右键单击事件发生时,资源管理器将不会再调用我们的扩展。如果我们返回S_OK ,那么资源管理器将会再次调用QueryInterface()来获得我们将要添加的另一个接口指针:IContextMenu

    和上下文菜单交互的接口

    一旦资源管理器初始化了我们的扩展,它将会调用IContextMenu 的方法让我们添加菜单项目、敏感帮助并完成用户的选择。

    向我们的扩展中添加IContextMenu 接口和添加IShellExtInit相类似。打开SimpleShlExt.h并添加一下红颜色的代码:

    class ATL_NO_VTABLE CSimpleShlExt : 
        public CComObjectRootEx<CComSingleThreadModel>,
        public CComCoClass<CSimpleShlExt, &CLSID_SimpleShlExt>,
        public IDispatchImpl<ISimpleShlExt, &IID_ISimpleShlExt, &LIBID_SIMPLEEXTLib>,
        public IShellExtInit,
        public IContextMenu
    {
    BEGIN_COM_MAP(CSimpleShlExt)
        COM_INTERFACE_ENTRY(ISimpleShlExt)
        COM_INTERFACE_ENTRY(IDispatch)
        COM_INTERFACE_ENTRY(IShellExtInit)
        COM_INTERFACE_ENTRY(IContextMenu)
    END_COM_MAP()

    接着添加IContextMenu 方法的原型:

    public:
        // IContextMenu
        STDMETHOD(GetCommandString)(UINT, UINT, UINT*, LPSTR, UINT);
        STDMETHOD(InvokeCommand)(LPCMINVOKECOMMANDINFO);
        STDMETHOD(QueryContextMenu)(HMENU, UINT, UINT, UINT, UINT);

    更改上下文菜单

    IContextMenu 3个方法。第一个,QueryContextMenu(),让我们更改菜单。它的原型为:

    HRESULT IContextMenu::QueryContextMenu (
        HMENU hmenu,
        UINT  uMenuIndex, 
        UINT  uidFirstCmd,
        UINT  uidLastCmd,
        UINT  uFlags );

    hmenu 是上下文菜单的句柄。uMenuIndex 是我们开始添加我们的菜单项目的开始位置。 uidFirstCmd uidLastCmd 是我们可以给菜单项目使用的命令ID值的范围。uFlags 指出为什么资源管理器正在调用QueryContextMenu(),这我们将在以后看到。

    有关它的返回值你将会得到不同的答案,如果你问不同的人的话。Dino Esposito 的书上说它使被QueryContextMenu()添加的菜单项目的号码。MSDN上关于VC 6部分说它是最后一个被添加的菜单项目的命令ID加上1。最新的MSDN文档有如下说明:

    设置代码的值[HRESULT返回的]为被分配的最大的命令ID偏移加上1。例如,假定idCmdFirst被设置为5,你添加了3个菜单项目分别使用命令ID578。它的返回值将是MAKE_HRESULT(SEVERITY_SUCCESS, 0, 8 – 5 + 1)

    到我现在所写的所有代码中,我接受了Dino的解释,这样工作的很好。事实上,他的制作返回值的方法和在线MSDN的方法是相同的,在你使用uidFirstCmd开始添加你的菜单项目时开始计数,每添加一个增加1

    我们的简单的扩展将仅仅添加一个菜单项目,所以QueryContextMenu()函数相当简单:

    HRESULT CSimpleShlExt::QueryContextMenu (
        HMENU hmenu,
        UINT  uMenuIndex, 
        UINT  uidFirstCmd,
        UINT  uidLastCmd,
        UINT  uFlags )
    {
        // If the flags include CMF_DEFAULTONLY then we shouldn't do anything.
        if ( uFlags & CMF_DEFAULTONLY )
            {
            return MAKE_HRESULT ( SEVERITY_SUCCESS, FACILITY_NULL, 0 );
            }
     
        InsertMenu ( hmenu, uMenuIndex, MF_BYPOSITION, uidFirstCmd, _T("SimpleShlExt Test Item") );
     
        return MAKE_HRESULT ( SEVERITY_SUCCESS, FACILITY_NULL, 1 );
    }

    我们首先要做的就是检查uFlags。你可以在MSDN查询所有的标志列表,但是对于上下文菜单扩展来说,只有一样是重要的:CMF_DEFAULTONLY。这个标志告诉名字空间扩展仅仅添加默认菜单项目。如果这个标志在的话,外壳扩展将不会添加任何菜单项目。这就是为什么当CMF_DEFAULTONLY存在的时候我们立即返回0的原因。如果该标志不存在,我们更改菜单(使用hmenu 句柄),然后返回1告诉外壳我们添加了一个菜单项目。

    在状态条显示敏感帮助

    IContextMenu 中下一个可以调用的方法是GetCommandString()。如果用户在资源管理器窗口中右键单击了一个文本文件的时候,或者选中一个文本文件,然后单击“文件”菜单,状态条上将显示敏感帮助。我们的GetCommandString() 函数将会返回一个让资源管理器显示得字符串。

    GetCommandString()函数原型如下:

    HRESULT IContextMenu::GetCommandString (
        UINT idCmd,
        UINT uFlags,
        UINT *pwReserved,
        LPSTR pszName,
        UINT cchMax );

    idCmd 是一个基于0的指明哪个菜单项目被选中的数。因为我们仅仅添加了一个菜单项,idCmd 将总是为0。但是如果我们添加了,我是说,3个的话,idCmd 将会是0,1或者2uFlags是另一个标志组。我将会在后面进行描述。我们可以忽略pwReservedpszName 是一个指向一个被外壳所拥有的缓存的指针,该缓存保存被显示的帮助字符串。cchMax 是缓存的大小。返回值是HRESULT常量,例如S_OKE_FAIL

    GetCommandString()同样能被用来获得菜单项的“动词”。“动词”是一个标志作用于文件的动作的字符串,它是独立于语言的。有关ShellExecute()的文档作了更多的说明,有关“动词”的主题更适合在另一篇文章说明,这儿简要说明的是列在注册表中的动词(比如说”open””print”),或者那些有上下文菜单扩展动态创建的“动词”。这使得在外壳扩展中实现的行为可以被ShellExecute()调用。

    总之,我提及所有这些的原因是我们不得不确定为什么GetCommandString()被调用。如果资源管理器需要一个敏感帮助字符串的时候,我们就提供。如果资源管理器请求一个“动词”的话,我们将忽略它。这是uFlags起作用的地方。如果uFlags GCS_HELPTEXT 的位被设置的话,那么资源管理器将请求敏感帮助。附加的,如果GCS_UNICODE位被设置,我们必须返回一个Unicode字符串。

    我们的GetCommandString() 的代码看起来应该像下面这样:

    #include <atlconv.h>  // for ATL string conversion macros
     
    HRESULT CSimpleShlExt::GetCommandString (
        UINT  idCmd,
        UINT  uFlags,
        UINT* pwReserved,
        LPSTR pszName,
        UINT  cchMax )
    {
        USES_CONVERSION;
     
        // Check idCmd, it must be 0 since we have only one menu item.
        if ( 0 != idCmd )
            return E_INVALIDARG;
     
        // If Explorer is asking for a help string, copy our string into the
        // supplied buffer.
        if ( uFlags & GCS_HELPTEXT )
            {
            LPCTSTR szText = _T("This is the simple shell extension's help");
     
            if ( uFlags & GCS_UNICODE )
                {
                // We need to cast pszName to a Unicode string, and then use the
                // Unicode string copy API.
                lstrcpynW ( (LPWSTR) pszName, T2CW(szText), cchMax );
                }
            else
                {
                // Use the ANSI string copy API to return the help string.
                lstrcpynA ( pszName, T2CA(szText), cchMax );
                }
     
            return S_OK;
            }
     
        return E_INVALIDARG;
    }

    没什么奇特的;我只是把字符串编码并且把它转换为合适的字符集。如果你以前从来都没有使用过ATL变换宏,你干脆先看看它们,因为这将我使更容易理解传递一个Unicode字符串到COM方法和OLE函数中。在上面的代码中,我使用了T2CWT2CA 分别将TCHAR字符串转换为UnicodeANSI。在函数头部的USES_CONVERSION 宏声明了一个变换宏使用的局部变量。

    一个需要注意的重要事项是lstrcpyn()API函数保证了目标字符串是以null结束的。这是它和CRT函数strncpy()的不同之处。如果源字符串的长度大于或等于cchMax时, strncpy() 并不添加结束符null。我建议你总是使用lstrcpyn(),这样你就不用不得不在strncpy()之后添加检查来保证字符串是null结束的。

    执行用户的选择

    最后一个IContextMenu方法是InvokeCommand()。这个方法将在用户单击我们添加的那个菜单项目时被调用。它的原型如下:

    HRESULT IContextMenu::InvokeCommand ( LPCMINVOKECOMMANDINFO pCmdInfo );

    CMINVOKECOMMANDINFO 结构里有很多的信息,但是根据我们现在的意图,我们只需要关心lpVerbhwnd lpVerb 有双重的任务——它既可以是被调用的“动词”的名称,也可以是一个用以告诉我们哪个菜单项被选中地索引。hwnd 是资源管理器窗口的句柄,在那儿,用户调用了我们的扩展。

    我们检查lpVerb ,因为我们只添加了一个菜单项,所以如果它为0,则我们的菜单被点击了。我能想到的最简单的事就是弹出一个消息框,所以我们就这么做。这个消息框显示了选中的文件的文件名,证明它的确是在工作。

    HRESULT CSimpleShlExt::InvokeCommand ( LPCMINVOKECOMMANDINFO pCmdInfo )
    {
        // If lpVerb really points to a string, ignore this function call and bail out.
        if ( 0 != HIWORD( pCmdInfo->lpVerb ))
            return E_INVALIDARG;
     
        // Get the command index - the only valid one is 0.
        switch ( LOWORD( pCmdInfo->lpVerb ))
            {
            case 0:
                {
                TCHAR szMsg [MAX_PATH + 32];
     
                wsprintf ( szMsg, _T("The selected file was:\n\n%s"), m_szFile );
     
                MessageBox ( pCmdInfo->hwnd, szMsg, _T("SimpleShlExt"),
                             MB_ICONINFORMATION );
     
                return S_OK;
                }
            break;
     
            default:
                return E_INVALIDARG;
            break;
            }
    }

    注册外壳扩展

    到现在为止,我们已经实现了我们所有的COM接口。但是……如何使资源管理器使用我们的扩展呢?ATL自动生成了注册我们的DLL为一个COM服务器的代码,但是它仅仅是让其它程序来使用我们的DLL。为了告诉资源管理器我们的扩展存在,我们必须在保持文本文件的注册表键下注册它:

    HKEY_CLASSES_ROOT\txtfile

    在那个键下面,一个叫做ShellEx 的键保存了一个对于文本文件将被调用的外壳扩展列表。在ShellEx下,ContextMenuHandlers 键保存了一个上下文菜单扩展的列表。每一个扩展在ContextMenuHandlers下创建一个字键,并把他的默认值设置为它的GUID。所以,为我们的扩展,我们创建如下键:

    HKEY_CLASSES_ROOT\txtfile\ShellEx\ContextMenuHandlers\SimpleShlExt

    并把它的默认值设置为我们的GUID

    "{5E2121EE-0300-11D4-8D3B-444553540000}"

    然而,你不用自己做这件事。如果你在FileView页查看你得文件列表时,你会发现SimpleShlExt.rgs。这是一个由ATL解析的文本文件,它告诉ATL当这个服务器被注册时该添加什么键,当被反注册时又该删除什么键。下面我们指定了要添加的注册表入口:

    HKCR
    {
        NoRemove txtfile
        {
            NoRemove ShellEx
            {
                NoRemove ContextMenuHandlers
                {
                    ForceRemove SimpleShlExt = s '{5E2121EE-0300-11D4-8D3B-444553540000}'
                }
            }
        }
    }

    它以"HKCR"——HKEY_CLASSES_ROOT的缩写——开头,每一行是注册表键名称。关键词NoRemove 意味着当该服务器被反注册时该键不能被删除。最后一行有点复杂。关键词ForceRemove 意思是如果该键存在,那么在该键被写之前先删除它。这一行剩下的部分指定了一个将被保存在SimpleShlExt键的默认值中的字符串(那就是”s”的意思)

    在这儿,我需要说明一点。我们注册扩展时的键是HKCR\txtfile。然而,这个名称"txtfile" 并不是一个永久的或预先知道的。如果你查看一下HKCR\.txt ,那个键的默认值是这个名称被保存的地方。这就两个侧面效果:

    • 我们将不能可靠的使用RGS脚本,因为"txtfile"可能不是正确的键名。
    • 其他的一些文本编辑器可能被安装,它们同.TXT文件相关联。如果它们改变了 HKCR\.txt键的默认值,所有存在的外壳扩展都将会停止工作。

    看起来,这的确是我设计的缺陷。我想微软也在考虑同样的事,因为最近创建的扩展,像QueryInfo扩展,是在.txt键下注册的。

    好了,说明到这儿。有一个最终的注册细节。在Win NT/2000下,我们必须自己将我们的扩展方到一个“被认可的”扩展列表当中。如果我们不这么做的话,那些非管理员用户将不会壮在我们的扩展。这个列表被保存在:

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved

    在这个键下,我们创建一个字符串值它的名称是我们的GUID。字符串的内容可以是任何东西。做这些事情的代码在我们的DllRegisterServer()DllUnregisterServer()函数当中。我并不想把这些呆马列在这儿,因为这只是简单的注册表访问。你可以从本文的例子项目当中找到它们。

    调试外壳扩展

    最终,你写成了这个相当不容易的扩展,然后你将会调试它。打开你的项目设置(Project->Settings),到栏,在"Executable for debug session"编辑框中输入资源管理器的全路径,例如:"C:\windows\explorer.exe"。如果你使用的是NT2000,而且你已经设置过了DesktopProcess 注册表项,那么在你按F5开始调试的时候,会有一个新的资源管理器窗口打开。只要你在那个窗口工作,以后重建DLL时你将不会有问题,因为当你关掉窗口时,你的扩展也被卸载了。

    Windows 9x下,恐怕你不得不在调试之前关闭你的外壳。单击“开始”->“关闭系统”。按住Ctrl+Alt+Shift然后点击“取消”。这将关闭资源管理器,然后你看见任务栏消失了。切换到MSVC然后按F5开始调试。按Shift+F5关闭资源管理器停止调试。当你做完调试的时候,你可以运行Explorer重新正常启动你的外壳。

    它看起来是什么样的?

    下面是我们添加的项目看起来的样子:

    这就是我们的菜单!

    下面是有敏感帮助时资源管理器的状态栏的样子:

    而下面是消息框的样子,它显示了被选中的文件的文件名:

          本例程代码下载地址(11K)http://www.codeproject.com/shell/ShellExtGuide1/ShellExtGuide1_demo.zip

    下一部分……

    接着的第二部分,一个新的上下文菜单扩展将会告诉你如何同时对多个文件进行操作。

    你可以从下面的网址获得这个和其他文章的最新版本:http://home.inreach.com/mdunn/code/

     

    关于翻译:

          这是我第一次翻译文章,文章来自著名的http://www.codeproject.com/,翻译之前我看了csdn的开发文档,发现还是空白,所以就像把它翻译了,也许有对它感兴趣的人。文章总共有9个部分。我没有太多的时间,只翻译了第一部分,也许能起到抛砖引玉的作用,让那些对外壳扩展不了解的人入个门,入了门的多个参考。更多的文章大家可以从http://www.codeproject.com/shell/ 找到。例子代码,原文也可以从那儿找到。我的emailmefish@163.net,头一次翻译,做得不好,任何意见、建议、鲜花、掌声、石头、带酒的啤酒瓶都将受到热烈欢迎……

    Previous Page

    Random Posts Recent Comments

    • 女友糖尿病害我蛀牙 Says:

      汗一个…...

    • Htj06 Says:

      zhenyouchuangyi...

    • 电商圈 Says:

      试图该怎么建立啊,,怎在程序中是吸纳...

    • edward Says:

      看得人心旷神怡,好文,情不自禁的顶一下...

    • Daniel Says:

      我也在处理这个问题,没有找到好的方法。我用了楼上兄弟的方法,还是可以的。不知道您找到好的方法了吗、我暂时楼上兄弟的方法。...

    • 卡,卡 Says:

      弱弱问一句:博主,你博客的模板这样设计pv高吗?...

    • 站长工具 Says:

      博主,兔年快乐!...

    • health Says:

      great post!!I hope I can read more in your website....

    • pdu Says:

      好博文,支持分享...

    • 站长工具 Says:

      博主的文章很不错,我是站长工具-站长精灵的作者,一款专业的SEO工具软件(可以帮您提高博客的流量),想跟您交换个链接,不知可否...

    Tag Cloud

    arm audio blog brew cache class debug flash google html j2me java javascript Joke linux lua mobile mtk php python ror ruby server shell stream unix web windows 优化 动态加载 女人 女生 平台 开发 手机 技术 流媒体 测试 漫画 生活 男人 男生 缓存 芯片