Posted: January 6, 2011 at 11:26 am | Tags: debug, mac, php, vld, xhprof
最近因为经常离线调试,所以开始重新在本机搭环境,还好 Mac 原本就自带了 PHP 。
[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 vld
sudo pecl install -f xhprof
不过安装 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 的效果了。
Posted: July 8, 2009 at 5:15 pm | Tags: cache, class, debug, html, php
之前大家都是在程序里写上简单的 require_once 和 require 然后直接跑一遍 ab 来看时间,这回 Konstantin Rozinon 在 apache debug 模式下看了一下 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 里统一负责根据 php5 的 __call 这个特性来去 require_once 相应的文件,一些性能上的损耗可以通过其它方式来弥补。比如 APC、XCache、Eacc 这些,opcode cache 现在成了 PHP 的必需品了。
原文:点击进入
btw: zend studio 7 beta 真慢……
Posted: January 12, 2009 at 9:03 pm | Tags: blog, debug, html, 优化, 开发, 技术
先说一个身边真正发生过的故事,可能大家会对故事情节感觉非常熟悉。
一家小型电子商务公司,管理者就是公司的创始人,他有些技术开发背景。因为产品面向海外市场,他也比较关注产品设计与可用性。由于他对自己的技术、设计能力的自信,总是对开发部与设计部成员的能力持怀疑态度,经常插手他们的工作。
一次,开发人员就新产品需求、设计文档的要求,提出开发方案A。这位管理者看后,以其经验判断认为不理想,并给出方案B。开发人员觉得方案B有些问题,但一时又没有找到有说服力的例证,无奈只好以此方案进行开发。
果然,在开发过程中,由于管理者仓促间所提出方案,在设计上确实存在不合理的疏漏,导致项目出现了一些问题。当开发人员想方设法将问题一一解决后,突然发现,这个DEBUG后的开发方案B,已经变得与他们最初提出的方案A并无二致。
而此时,该项目已经严重超期,那位管理者还为此非常不满,认为是开发人员能力的问题导致的。此后,管理者对开发工作的介入变得更多,而开发人员也开始变
化,一部分对领导的这种超权行为越来越不满意,矛盾变得更加激化,后面工作中的沟通变得更加困难;另一部分则变得越来越没有积极性,领导要求怎么做就怎么
做。
刚好看到UCDChina.com中的一篇文章《管理者不应直接参与产品的开发与设计》,感觉说得太有道理了。上面这个故事,可以用来充实文章的论据。
其实团队管理者关注团队产品的成败,是非常正常的心态。他们插手设计、开发工作,无非是希望把产品更得更好,动机是无庸质疑的。尽管如此,还是不建议管理
者过多的介入具体的开发与设计工作,即使是领域专家型的管理者,过多的插手具体设计、开发工作,也得不到预期的结果,可能对于项目来说,往往事与愿违,由
此产生的恶性干扰多于良性的指导,这是得不偿失的。
为什么会这样?原因很多:
1、因为管理者与团队成员的权重不同,有管理者参与的项目,往往不能非常公平地对待其它项目涉众。尽管,管理者本意是以其对项目的理解和自身的经验,为设
计、开发团队提供一些指导和建议,至少也会增加一种思路。但往往事与愿违,管理者介入后,一般会导致所有项目涉众的思维模式,会被管理者所左右,就因为他
是团队的管理者。
大家想想,是否经常遇到这样的情况,设计、开发人员深思熟虑后形成的方案,经常因为管理者的一点儿质疑,而被否决;而管理者的灵光一闪,都可能形成一个决
策,如果其它团队成员想到推翻它,必须经过周密、详实的举证与论述,这本就不公平,对项目也绝对没有好处,这会影响到团队成员的思路,甚至导致他们逐渐推
动思考的动力。
2、因为技术背景与对项目的关注点不同,管理者与设计、开发人员会处在不同层面,看问题角度肯定是不同的。其实,能从多个不同角度看待产品,这本来是好事,可以把问题考虑得更全面一些。但如果以管理者的角度,去干扰设计、开发中的问题,那就是另外一码儿事了。
《论语•泰伯》:“子曰:不在其位,不谋其政。”
这句话说得非常好,这不是推卸责任意思,而恰恰是出于更负责的角度考虑。为了便于理解,这里把“位”理解为“职位”。
每个职位有不同的职责,职责会影响人的立场,不同立场、知识背景的人理解、处理同一个问题,其结果肯定是不一样的。也许管理者认为自己可以做到“换位思考
”,即便如此也是搁靴搔痒的状态,其结果绝对差强人意。比如,管理者明白不能让UI设计师去考虑代码优化的问题,那又为什么自己去犯同样的错误呢?
正所谓术业有专攻,专业的工作还是让专业的人去做,那才可能达到令人满意的结果。
3、有人说,在IT行业,许多管理者都是优秀程序员或策划、设计师出身,这种领域专家型的管理者插手做具体设计、开发工作,应该有对项目、对团队成员有帮助。
其实不然,前面提到的两点问题,对于这样的管理者也依然存在。而且,文章开头提到的那位管理者也曾经是开发人员,本身也是位不错的产品设计师。为什么团队成员在他的指导下,项目进展依然不顺利呢?
从事过产品设计、程序开发工作的朋友应该很清楚,这样的工作需要投入大量的时间与精力,这是一个反复尝试与迭代的过程。好的设计与优秀的编码,绝对不是通
过纸上谈兵或灵光一闪就可以得到的(当然,这个世界是有天才存在的,也许他们拍拍脑袋就可以把产品设计得非常完美,程序编码也可以没有任何BUG,但毕竟
这种天才少得没有说服力)。有的时候,即使写好伪代码,也不能百之百的确保业务逻辑没问题。
而团队的管理者,往往事务缠身,他们没有精力(也不应该)深入于其中任何一项具体工作,那样就会犯下过于关注细节的管理大忌。而浅尝辄止的心态,恰恰又是做好设计与开发工作的大忌。这样看来,管理者兼顾设计、开发工作,并取得好的结果,根本是一项不可能完成的任务。
当然,领域专家型的管理者是可遇而不可求的,他丰富的经验与思路都是对团队成员有帮助的,但仅此而已,具体的设计、开发工作还是应该让设计师和程序员来做。
基于上面分析,如果管理者仍执意要插手设计与开发工作,就必须保证自己的观点(或决策)是100%准确与全面的,这样才不会对项目有负面影响。
当然,这样的要求是不合理的,也没有人敢做此承诺,所以,管理者们还去做好本职工作吧,那里才是发挥你们特长的地方。好的管理者,要懂得放权,要对团队成员应该有足够的信任,相信他们的工作能力,也相信他们的工作态度。正所谓:用人不疑,疑人不用。
如果管理者实在想参与设计、开发工作,那就干脆转行吧。
转自:http://blog.sina.com.cn/s/blog_564cabe30100bxmb.html
Posted: November 14, 2008 at 11:54 am | Tags: debug, php
在 Zend Studio for Eclipse 时会有显示 Building PHP Project 的错误,解决的办法很简单,在 preference 里的 General 中设置 Startup and Shutdown ,把 Advanced Debugger UI Plug-in 和 PDT Debug Daemon Plug-in 的对号去掉既可。
Posted: October 5, 2008 at 7:20 pm | Tags: debug, web
一直不放弃 ie 就在 ff 上没有找到哪几个插件能代替我的无敌 debug 组合 debugbar + compain.JS + httpwatch + iedevtoolbar
现在可以用 firebug + httpwatch + yslow + web developer 来取代 ie 了,太爽了 httpfox 还是免费的,哈。

httpwatch
Posted: November 25, 2007 at 2:21 pm | Tags: debug, parser, ror, xml, 平台, 手机, 源代码
今天心情不错~ 分享一下小弟06年在某手机公司写的XML parser.
虽然当时脑子里还没有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 XML_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(DEBUG) || defined(_DEBUG)
#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
Posted: September 28, 2007 at 4:03 pm | Tags: cache, debug, fastcgi, java, lighttpd, mobile, php, server, web
终于配置上 XCache 和 XDebug 了,可惜的是 php-java-bridge 一直没搞好,只有双击运行 JavaBridge 后才行,唉,要是能内置到 PHP 里就好了。
继续研究 FastCGI & Lighttpd
如果说之前在 UUSee 是向上研究,既“抽象”、“架构”的话,那么来 IMobile 之后研究方向则是向下,研究底层,研究以前没注意到的更细节的地方了。
:)
Good days, good luck.
Posted: May 24, 2007 at 3:50 pm | Tags: class, debug, html, linux, lua, php, ror, server, windows
转至: 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 Windows 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 { WORD e_magic; WORD e_cblp; WORD e_cp; WORD e_crlc; WORD e_cparhdr; WORD e_minalloc; WORD e_maxalloc; WORD e_ss; WORD e_sp; WORD e_csum; WORD e_ip; WORD e_cs; WORD e_lfarlc; WORD e_ovno; WORD e_res[4]; WORD e_oemid; WORD e_oeminfo; WORD e_res2[10]; LONG e_lfanew; } 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 |
| Debug 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­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:
#define IMAGE_DIRECTORY_ENTRY_EXPORT 0#define IMAGE_DIRECTORY_ENTRY_IMPORT 1#define IMAGE_DIRECTORY_ENTRY_RESOURCE 2#define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3#define IMAGE_DIRECTORY_ENTRY_SECURITY 4#define IMAGE_DIRECTORY_ENTRY_BASERELOC 5#define IMAGE_DIRECTORY_ENTRY_DEBUG 6#define IMAGE_DIRECTORY_ENTRY_ARCHITECTURE 7#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR 8#define IMAGE_DIRECTORY_ENTRY_TLS 9#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG 10#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT 11#define IMAGE_DIRECTORY_ENTRY_IAT 12#define IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT 13#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:
- Registers viewer.
| EAX |
| ECX |
| EDX |
| EBX |
| ESP |
| EBP |
| ESI |
| EDI |
| EIP |
|
o d t s z a p c
|
- 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
|
- 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………….. |
- 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 …. …. |
- 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 ;DWORD OEP_VA = image_nt_headers-> OptionalHeader.ImageBase + OEP_RVA ;
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 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 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 DWORD_TYPE(DYN_LOADER_START_DATA1)_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 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+1Ch],EAX POPAD PUSH EAX XOR EAX, EAX RETN 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 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 POPAD CALL _OEP_Jump DWORD_TYPE(0xCCCCCCCC)_OEP_Jump: PUSH EBP MOV EBP,ESP MOV EAX,DWORD PTR [ESP+3Ch] MOV DWORD PTR [ESP+4h],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 ... 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 { __asm { INT 3 }}__except( ..., EXCEPTION_CONTINUE_SEARCH ){}
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 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+10h],EAX LEA EAX,[EBP+_except_handler1_OEP_Jump] MOV DWORD PTR [ESP+1Ch],EAX POPAD PUSH EAX XOR EAX, EAX PUSH DWORD PTR FS:[0] MOV DWORD PTR FS:[0],ESP DWORD_TYPE(0xCCCCCCCC) _except_handler1_OEP_Jump: PUSH EBP MOV EBP,ESP MOV EAX,DWORD PTR SS:[EBP+010h] PUSH EDI MOV EDI,DWORD PTR DS:[EAX+0C4h] PUSH DWORD PTR DS:[EDI] POP DWORD PTR FS:[0] ADD DWORD PTR DS:[EAX+0C4h],8 MOV EDI,DWORD PTR DS:[EAX+0A4h] MOV DWORD PTR DS:[EAX+0B8h],EDI 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:
typedef HGLOBAL (*importFunction_GlobalAlloc)(UINT, SIZE_T);...importFunction_GlobalAlloc __GlobalAlloc;HINSTANCE hinstLib = LoadLibrary("Kernel32.dll");if (hinstLib == NULL){ }__GlobalAlloc = (importFunction_GlobalAlloc)GetProcAddress(hinstLib, "GlobalAlloc");if (addNumbers == NULL){ }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; DWORD FirstThunk; } 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: 0001F041: 00 00 0001F050: 00 00 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: 0001F041: 00 00 0001F050: 00 00 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 );ImportTableMaker->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] mov esi,eax lea edi, @"GetModuleHandleA"push edipush esimov eax,offset _p_GetProcAddresscall [ebp+eax]
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] pop ecx mov esi,eax 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 call [ebp+eax] pop ecx mov [ebx],eax mov [ecx],ebx 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 _it_fixup_get_lib_address_loop: mov eax,[ebx+00Ch] test eax,eax jz _it_fixup_end mov ecx,[ebx+010h] add ecx,esi mov [ebp+_p_dwThunk],ecx mov ecx,[ebx] test ecx,ecx jnz _it_fixup_table mov ecx,[ebx+010h]_it_fixup_table: add ecx,esi mov [ebp+_p_dwHintName],ecx add eax,esi push eax mov eax,offset _p_LoadLibrary call [ebp+eax] test eax,eax jz _it_fixup_end mov edi,eax_it_fixup_get_proc_address_loop: mov ecx,[ebp+_p_dwHintName] mov edx,[ecx] test edx,edx jz _it_fixup_next_module test edx,080000000h jz _it_fixup_by_name and edx,07FFFFFFFh jmp _it_fixup_get_addr_it_fixup_by_name: add edx,esi inc edx inc edx _it_fixup_get_addr: push edx push edi mov eax,offset _p_GetProcAddress call [ebp+eax] mov ecx,[ebp+_p_dwThunk] mov [ecx],eax add dword ptr [ebp+_p_dwThunk], 004h add dword ptr [ebp+_p_dwHintName],004h jmp _it_fixup_get_proc_address_loop_it_fixup_next_module: add ebx,014h 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();
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:
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 call _main_1_main_1: pop ebp sub ebp,offset _main_1 _support_dll_0: jmp _support_dll_1 jmp _support_dll_2_support_dll_1: ... mov edi,[ebp+_p_dwImageBase] add edi,[edi+03Ch] mov ax,word ptr [edi+016h] test ax,IMAGE_FILE_DLL jz _support_dll_2 mov ax, 9090h 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] mov ebx,[esp+30h] 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.
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] mov ebx,[ebx+034h] sub edx,ebx 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] 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] push edx mov edx,eax shr eax,00Ch mov esi,[ebp+_p_dwImageBase] and dx,00FFFh add esi,[ebx] add esi,edx pop edx_reloc_fixup_HIGH: dec eax jnz _reloc_fixup_LOW mov eax,edx shr eax,010h jmp _reloc_fixup_LOW_fixup_reloc_fixup_LOW: dec eax jnz _reloc_fixup_HIGHLOW movzx eax,dx _reloc_fixup_LOW_fixup: add word ptr [esi],ax jmp _reloc_fixup_next_entry_reloc_fixup_HIGHLOW: dec eax jnz _reloc_fixup_next_entry add [esi],edx _reloc_fixup_next_entry: inc edi inc edi 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...
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)
Posted: May 24, 2007 at 9:31 am | Tags: blog, debug, html, windows
转至: 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斑竹所说,我知道自己进阶了。把过程和大家共享,希望大家可以跨过入门的门槛,共同进步。
Posted: March 24, 2007 at 9:39 pm | Tags: class, debug, ror, server, shell, windows, 开发, 类, 缓存
外壳扩展(Shell Extention)是一个能向Windows外壳(资源管理器)添加一些功能的COM对象。这有很多的内容,但是却很少有关于它们的易懂的文档告诉我们如何去编写这些外壳(Shell)程序。如果你想做对外壳很深入的了解,我极力向你推荐Dino Esposito 的非常好的一本书《Visual C++ Windows Shell Programming》。但是对于那些没有这本书并且仅仅关心如何去编写外壳扩展的人,我写的一指南将会令你非常惊讶,如果并非如此的话也能给你理解如何编写外壳扩展提供很好的帮助。要阅读这一指南,确保你对COM和ATL要相当熟悉。
第一部分包括了对外壳扩展的概要的介绍,并提供了一个上下文菜单扩展的例程来使你对以后的部分中充满兴趣。
什么是外壳扩展呢?
这有两部分,外壳和扩展(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 。在向导中保持所有默认选项,单击完成。我们现在就有了一个空的将会生成DLL的ATL项目,但是我们必须添加自己的外壳扩展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>
class 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个菜单项目分别使用命令ID为5、7和8。它的返回值将是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或者2。uFlags是另一个标志组。我将会在后面进行描述。我们可以忽略pwReserved。pszName 是一个指向一个被外壳所拥有的缓存的指针,该缓存保存被显示的帮助字符串。cchMax 是缓存的大小。返回值是HRESULT常量,例如S_OK或E_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函数中。在上面的代码中,我使用了T2CW和T2CA 分别将TCHAR字符串转换为Unicode和ANSI。在函数头部的USES_CONVERSION 宏声明了一个变换宏使用的局部变量。
一个需要注意的重要事项是lstrcpyn()API函数保证了目标字符串是以null结束的。这是它和CRT函数strncpy()的不同之处。如果源字符串的长度大于或等于cchMax时, strncpy() 并不添加结束符null。我建议你总是使用lstrcpyn(),这样你就不用不得不在strncpy()之后添加检查来保证字符串是null结束的。
执行用户的选择
最后一个IContextMenu方法是InvokeCommand()。这个方法将在用户单击我们添加的那个菜单项目时被调用。它的原型如下:
HRESULT IContextMenu::InvokeCommand ( LPCMINVOKECOMMANDINFO pCmdInfo );
CMINVOKECOMMANDINFO 结构里有很多的信息,但是根据我们现在的意图,我们只需要关心lpVerb和hwnd 。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),到Debug栏,在"Executable for debug session"编辑框中输入资源管理器的全路径,例如:"C:\windows\explorer.exe"。如果你使用的是NT或2000,而且你已经设置过了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/ 找到。例子代码,原文也可以从那儿找到。我的email是mefish@163.net,头一次翻译,做得不好,任何意见、建议、鲜花、掌声、石头、带酒的啤酒瓶都将受到热烈欢迎……
Previous Page