1. 屏幕取词
“鼠标屏幕取词”技术是在电子字典中得到广泛地应用的,如四通利方和金山词霸等软件,这个技术看似简单,其实在WINDOWS系统中实现却是非常复杂的,总的来说有两种实现方式:
第一种:采用截获对部分GDI的API调用来实现,如TextOut,TextOutA等。
第二种:对每个设备上下文(DC)做一分Copy,并跟踪所有修改上下文(DC)的操作。
第二种方法更强大,但兼容性不好,而第一种方法使用的截获WindowsAPI的调用,这项技术的强大可能远远超出了您的想象,毫不夸张的说,利用WindowsAPI拦截技术,你可以改造整个操作系统,事实上很多外挂式Windows中文平台就是这么实现的!而这项技术也正是这篇文章的主题。
截WindowsAPI的调用,具体的说来也可以分为两种方法:
第一种方法通过直接改写WinAPI 在内存中的映像,嵌入汇编代码,使之被调用时跳转到指定的地址运行来截获;第二种方法则改写IAT(Import Address Table 输入地址表),重定向WinAPI函数的调用来实现对WinAPI的截获。
第一种方法的实现较为繁琐,而且在Win95、98下面更有难度,这是因为虽然微软说WIN16的API只是为了兼容性才保留下来,程序员应该尽可能地调用32位的API,实际上根本就不是这样!WIN 9X内部的大部分32位API经过变换调用了同名的16位API,也就是说我们需要在拦截的函数中嵌入16位汇编代码!
我们将要介绍的是第二种拦截方法,这种方法在Win95、98和NT下面运行都比较稳定,兼容性较好。由于需要用到关于Windows虚拟内存的管理、打破进程边界墙、向应用程序的进程空间中注入代码、PE(Portable Executable)文件格式和IAT(输入地址表)等较底层的知识,所以我们先对涉及到的这些知识大概地做一个介绍,最后会给出拦截部分的关键代码。
先说Windows虚拟内存的管理。Windows9X给每一个进程分配了4GB的地址空间,对于NT来说,这个数字是2GB,系统保留了2GB到 4GB之间的地址空间禁止进程访问,而在Win9X中,2GB到4GB这部分虚拟地址空间实际上是由所有的WIN32进程所共享的,这部分地址空间加载了共享Win32 DLL、内存映射文件和VXD、内存管理器和文件系统码,Win9X中这部分对于每一个进程都是可见的,这也是Win9X操作系统不够健壮的原因。
Win9X中为16位操作系统保留了0到4MB的地址空间,而在4MB到2GB之间也就是Win32进程私有的地址空间,由于 每个进程的地址空间都是相对独立的,也就是说,如果程序想截获其它进程中的API调用,就必须打破进程边界墙,向其它的进程中注入截获API调用的代码,这项工作我们交给钩子函数(SetWindowsHookEx)来完成,关于如何创建一个包含系统钩子的动态链接库,《电脑高手杂志》已经有过专题介绍了,这里就不赘述了。
所有系统钩子的函数必须要在动态库里,这样的话,当进程隐式或显式调用一个动态库里的函数时,系统会把这个动态库映射到这个进程的虚拟地址空间里,这使得DLL成为进程的一部分,以这个进程的身份执行,使用这个进程的堆栈,也就是说动态链接库中的代码被钩子函数注入了其它GUI进程的地址空间(非GUI进程,钩子函数就无能为力了),当包含钩子的DLL注入其它进程后,就可以取得映射到这个进程虚拟内存里的各个模块(EXE和DLL)的基地址,如:
HMODULE hmole=GetMoleHandle(“Mypro.exe”);
在MFC程序中,我们可以用AfxGetInstanceHandle()函数来得到模块的基地址。EXE和DLL被映射到虚拟内存空间的什么地方是由它们的基地址决定的。它们的基地址是在链接时由链接器决定的。当你新建一个Win32工程时,VC++链接器使用缺省的基地址0x00400000。可以通过链接器的BASE选项改变模块的基地址。EXE通常被映射到虚拟内存的0x00400000处,DLL也随之有不同的基地址,通常被映射到不同进程的相同的虚拟地址空间处。
系统将EXE和DLL原封不动映射到虚拟内存空间中,它们在内存中的结构与磁盘上的静态文件结构是一样的。即PE (Portable Executable) 文件格式。我们得到了进程模块的基地址以后,就可以根据PE文件的格式穷举这个模块的IMAGE_IMPORT_DESCRIPTOR数组,看看进程空间中是否引入了我们需要截获的函数所在的动态链接库,比如需要截获“TextOutA”,就必须检查“Gdi32.dll”是否被引入了。
说到这里,我们有必要介绍一下PE文件的格式,如右图,这是PE文件格式的大致框图,最前面是文件头,我们不必理会,从PE File Optional Header后面开始,就是文件中各个段的说明,说明后面才是真正的段数据,而实际上我们关心的只有一个段,那就是“.idata”段,这个段中包含了所有的引入函数信息,还有IAT(Import Address Table)的RVA(Relative Virtual Address)地址。
说到这里,截获WindowsAPI的整个原理就要真相大白了。实际上所有进程对给定的API函数的调用总是通过PE文件的一个地方来转移的,这就是一个该模块(可以是EXE或DLL)的“.idata”段中的IAT输入地址表(Import Address Table)。在那里有所有本模块调用的其它DLL的函数名及地址。对其它DLL的函数调用实际上只是跳转到输入地址表,由输入地址表再跳转到DLL真正的函数入口。
具体来说,我们将通过IMAGE_IMPORT_DESCRIPTOR数组来访问“.idata”段中引入的DLL的信息,然后通过IMAGE_THUNK_DATA数组来针对一个被引入的DLL访问该DLL中被引入的每个函数的信息,找到我们需要截获的函数的跳转地址,然后改成我们自己的函数的地址……具体的做法在后面的关键代码中会有详细的讲解。
讲了这么多原理,现在让我们回到“鼠标屏幕取词”的专题上来。除了API函数的截获,要实现“鼠标屏幕取词”,还需要做一些其它的工作,简单的说来,可以把一个完整的取词过程归纳成以下几个步骤:
1. 安装鼠标钩子,通过钩子函数获得鼠标消息。
使用到的API函数:SetWindowsHookEx
2. 得到鼠标的当前位置,向鼠标下的窗口发重画消息,让它调用系统函数重画窗口。
使用到的API函数:WindowFromPoint,ScreenToClient,InvalidateRect
3. 截获对系统函数的调用,取得参数,也就是我们要取的词。
对于大多数的Windows应用程序来说,如果要取词,我们需要截获的是“Gdi32.dll”中的“TextOutA”函数。
我们先仿照TextOutA函数写一个自己的MyTextOutA函数,如:
BOOL WINAPI MyTextOutA(HDC hdc, int nXStart, int nYStart, LPCSTR lpszString,int cbString)
{
// 这里进行输出lpszString的处理
// 然后调用正版的TextOutA函数
}
把这个函数放在安装了钩子的动态连接库中,然后调用我们最后给出的HookImportFunction函数来截获进程对TextOutA函数的调用,跳转到我们的MyTextOutA函数,完成对输出字符串的捕捉。
HookImportFunction的用法:
HOOKFUNCDESC hd;
PROC pOrigFuns;
hd.szFunc="TextOutA";
hd.pProc=(PROC)MyTextOutA;
HookImportFunction (AfxGetInstanceHandle(),"gdi32.dll",&hd,pOrigFuns);
下面给出了HookImportFunction的源代码,相信详尽的注释一定不会让您觉得理解截获到底是怎么实现的很难,Ok,Let’s Go:
///////////////////////////////////////////// Begin ///////////////////////////////////////////////////////////////
#include <crtdbg.h>
// 这里定义了一个产生指针的宏
#define MakePtr(cast, ptr, AddValue) (cast)((DWORD)(ptr)+(DWORD)(AddValue))
// 定义了HOOKFUNCDESC结构,我们用这个结构作为参数传给HookImportFunction函数
typedef struct tag_HOOKFUNCDESC
{
LPCSTR szFunc; // The name of the function to hook.
PROC pProc; // The procere to blast in.
} HOOKFUNCDESC , * LPHOOKFUNCDESC;
// 这个函数监测当前系统是否是WindowNT
BOOL IsNT();
// 这个函数得到hMole -- 即我们需要截获的函数所在的DLL模块的引入描述符(import descriptor)
PIMAGE_IMPORT_DESCRIPTOR GetNamedImportDescriptor(HMODULE hMole, LPCSTR szImportMole);
// 我们的主函数
BOOL HookImportFunction(HMODULE hMole, LPCSTR szImportMole,
LPHOOKFUNCDESC paHookFunc, PROC* paOrigFuncs)
{
/////////////////////// 下面的代码检测参数的有效性 ////////////////////////////
_ASSERT(szImportMole);
_ASSERT(!IsBadReadPtr(paHookFunc, sizeof(HOOKFUNCDESC)));
#ifdef _DEBUG
if (paOrigFuncs) _ASSERT(!IsBadWritePtr(paOrigFuncs, sizeof(PROC)));
_ASSERT(paHookFunc.szFunc);
_ASSERT(*paHookFunc.szFunc != '\0');
_ASSERT(!IsBadCodePtr(paHookFunc.pProc));
#endif
if ((szImportMole == NULL) || (IsBadReadPtr(paHookFunc, sizeof(HOOKFUNCDESC))))
{
_ASSERT(FALSE);
SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);
return FALSE;
}
//////////////////////////////////////////////////////////////////////////////
// 监测当前模块是否是在2GB虚拟内存空间之上
// 这部分的地址内存是属于Win32进程共享的
if (!IsNT() && ((DWORD)hMole >= 0x80000000))
{
_ASSERT(FALSE);
SetLastErrorEx(ERROR_INVALID_HANDLE, SLE_ERROR);
return FALSE;
}
// 清零
if (paOrigFuncs) memset(paOrigFuncs, NULL, sizeof(PROC));
// 调用GetNamedImportDescriptor()函数,来得到hMole -- 即我们需要
// 截获的函数所在的DLL模块的引入描述符(import descriptor)
PIMAGE_IMPORT_DESCRIPTOR pImportDesc = GetNamedImportDescriptor(hMole, szImportMole);
if (pImportDesc == NULL)
return FALSE; // 若为空,则模块未被当前进程所引入
// 从DLL模块中得到原始的THUNK信息,因为pImportDesc->FirstThunk数组中的原始信息已经
// 在应用程序引入该DLL时覆盖上了所有的引入信息,所以我们需要通过取得pImportDesc->OriginalFirstThunk
// 指针来访问引入函数名等信息
PIMAGE_THUNK_DATA pOrigThunk = MakePtr(PIMAGE_THUNK_DATA, hMole,
pImportDesc->OriginalFirstThunk);
// 从pImportDesc->FirstThunk得到IMAGE_THUNK_DATA数组的指针,由于这里在DLL被引入时已经填充了
// 所有的引入信息,所以真正的截获实际上正是在这里进行的
PIMAGE_THUNK_DATA pRealThunk = MakePtr(PIMAGE_THUNK_DATA, hMole, pImportDesc->FirstThunk);
// 穷举IMAGE_THUNK_DATA数组,寻找我们需要截获的函数,这是最关键的部分!
while (pOrigThunk->u1.Function)
{
// 只寻找那些按函数名而不是序号引入的函数
if (IMAGE_ORDINAL_FLAG != (pOrigThunk->u1.Ordinal & IMAGE_ORDINAL_FLAG))
{
// 得到引入函数的函数名
PIMAGE_IMPORT_BY_NAME pByName = MakePtr(PIMAGE_IMPORT_BY_NAME, hMole,
pOrigThunk->u1.AddressOfData);
// 如果函数名以NULL开始,跳过,继续下一个函数
if ('\0' == pByName->Name[0])
continue;
// bDoHook用来检查是否截获成功
BOOL bDoHook = FALSE;
// 检查是否当前函数是我们需要截获的函数
if ((paHookFunc.szFunc[0] == pByName->Name[0]) &&
(strcmpi(paHookFunc.szFunc, (char*)pByName->Name) == 0))
{
// 找到了!
if (paHookFunc.pProc)
bDoHook = TRUE;
}
if (bDoHook)
{
// 我们已经找到了所要截获的函数,那么就开始动手吧
// 首先要做的是改变这一块虚拟内存的内存保护状态,让我们可以自由存取
MEMORY_BASIC_INFORMATION mbi_thunk;
VirtualQuery(pRealThunk, &mbi_thunk, sizeof(MEMORY_BASIC_INFORMATION));
_ASSERT(VirtualProtect(mbi_thunk.BaseAddress, mbi_thunk.RegionSize,
PAGE_READWRITE, &mbi_thunk.Protect));
// 保存我们所要截获的函数的正确跳转地址
if (paOrigFuncs)
paOrigFuncs = (PROC)pRealThunk->u1.Function;
// 将IMAGE_THUNK_DATA数组中的函数跳转地址改写为我们自己的函数地址!
// 以后所有进程对这个系统函数的所有调用都将成为对我们自己编写的函数的调用
pRealThunk->u1.Function = (PDWORD)paHookFunc.pProc;
// 操作完毕!将这一块虚拟内存改回原来的保护状态
DWORD dwOldProtect;
_ASSERT(VirtualProtect(mbi_thunk.BaseAddress, mbi_thunk.RegionSize,
mbi_thunk.Protect, &dwOldProtect));
SetLastError(ERROR_SUCCESS);
return TRUE;
}
}
// 访问IMAGE_THUNK_DATA数组中的下一个元素
pOrigThunk++;
pRealThunk++;
}
return TRUE;
}
// GetNamedImportDescriptor函数的实现
PIMAGE_IMPORT_DESCRIPTOR GetNamedImportDescriptor(HMODULE hMole, LPCSTR szImportMole)
{
// 检测参数
_ASSERT(szImportMole);
_ASSERT(hMole);
if ((szImportMole == NULL) || (hMole == NULL))
{
_ASSERT(FALSE);
SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);
return NULL;
}
// 得到Dos文件头
PIMAGE_DOS_HEADER pDOSHeader = (PIMAGE_DOS_HEADER) hMole;
// 检测是否MZ文件头
if (IsBadReadPtr(pDOSHeader, sizeof(IMAGE_DOS_HEADER)) ||
(pDOSHeader->e_magic != IMAGE_DOS_SIGNATURE))
{
_ASSERT(FALSE);
SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);
return NULL;
}
// 取得PE文件头
PIMAGE_NT_HEADERS pNTHeader = MakePtr(PIMAGE_NT_HEADERS, pDOSHeader, pDOSHeader->e_lfanew);
// 检测是否PE映像文件
if (IsBadReadPtr(pNTHeader, sizeof(IMAGE_NT_HEADERS)) ||
(pNTHeader->Signature != IMAGE_NT_SIGNATURE))
{
_ASSERT(FALSE);
SetLastErrorEx(ERROR_INVALID_PARAMETER, SLE_ERROR);
return NULL;
}
// 检查PE文件的引入段(即 .idata section)
if (pNTHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress == 0)
return NULL;
// 得到引入段(即 .idata section)的指针
PIMAGE_IMPORT_DESCRIPTOR pImportDesc = MakePtr(PIMAGE_IMPORT_DESCRIPTOR, pDOSHeader,
pNTHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT].VirtualAddress);
// 穷举PIMAGE_IMPORT_DESCRIPTOR数组寻找我们需要截获的函数所在的模块
while (pImportDesc->Name)
{
PSTR szCurrMod = MakePtr(PSTR, pDOSHeader, pImportDesc->Name);
if (stricmp(szCurrMod, szImportMole) == 0)
break; // 找到!中断循环
// 下一个元素
pImportDesc++;
}
// 如果没有找到,说明我们寻找的模块没有被当前的进程所引入!
if (pImportDesc->Name == NULL)
return NULL;
// 返回函数所找到的模块描述符(import descriptor)
return pImportDesc;
}
// IsNT()函数的实现
BOOL IsNT()
{
OSVERSIONINFO stOSVI;
memset(&stOSVI, NULL, sizeof(OSVERSIONINFO));
stOSVI.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
BOOL bRet = GetVersionEx(&stOSVI);
_ASSERT(TRUE == bRet);
if (FALSE == bRet) return FALSE;
return (VER_PLATFORM_WIN32_NT == stOSVI.dwPlatformId);
}
/////////////////////////////////////////////// End //////////////////////////////////////////////////////////////////////
不知道在之前,有多少朋友尝试过去实现“鼠标屏幕取词”这项充满了挑战的技术,也只有尝试过的朋友才能体会到其间的不易,尤其在探索API函数的截获时,手头的几篇资料没有一篇是涉及到关键代码的,重要的地方都是一笔代过,MSDN更是显得苍白而无力,也不知道除了IMAGE_IMPORT_DESCRIPTOR和IMAGE_THUNK_DATA,微软还隐藏了多少秘密,好在硬着头皮还是把它给攻克了,希望这篇文章对大家能有所帮助。
2. 有开源的java屏幕取词程序吗
这样问得确不是很正确,语言没有开不开源的说法,语言只是提供给大家一种写代码要遵循的语法,当然这些语法肯定是公开的,不然大家怎么学呀。
至于用java这个语法写的代码是否是开源的,那每个项目都不同,有开源的也有商业的;
如果你想问的是java的基本类库是否开源,那答案是是的,你安装完jdk后目录下会有src.zip,里面就是源代码;
3. 拜求一个VC++/MFC编写的屏幕取词的程序,就是像金山词霸取词的那种~~用HOOK写的
1.用detour实现hook。非常的简单依样画葫芦就可以劫持本进程的api
http://blog.csdn.net/evi10r/article/details/6659354
2.windows核心编程那本书里有进程注入,你可以下载源码,详见inject和eject的例子,可以把一个dll注入进一个进程
以前做过的,就这样就行。但是现在那个工程没了= =。你hook textout系列函数,然后将消息发回服务器即可,加油。
4. IE窗口中的文字是哪个API绘出来的
这里假设读者了解一点点屏幕取词的技术背景。屏幕取词一般都是Hook了ExtTextOut、ExtTextOut函数,然后对屏幕指定部分进行InvalidateRect,就会得屏幕要更新的内容,然后根据屏幕坐标计算鼠标指的词。IE的屏幕取词稍稍不同。通过调试,你会发现对IE屏幕取词时,GetDCOrgEx返回DC的坐标原点都是0,0。郁闷。其实细想起来,DC是分2种的,还有一种是内存DC,应用程序为了提高绘制效率,减少屏幕闪动,都会使用内存DC做缓存,先在内存DC中绘制内容,然后到屏幕上。做个试验,对IE通过ExtTextOut获得的DC使用WindowFromDC,哈哈,返回是NULL,说明这个DC是个内存DC。找到问题的根源了,现在还需要多Hook一个API,就是BitBlt。IE就是使用BitBlt把内存DC中的内容,到屏幕上的。程序的流程大概是这样的,先从ExtTextOut获得的DC计算每个词的相对RECT,存入一个队列中,再在BitBlt中通过GetDCOrgEx获得实际目标DC的原点坐标,计算每个词的相对屏幕的RECT,剩下的就是判断鼠标在哪个RECT中了。似乎麻烦了点,没办法啊。谁让国内用户的口味高呢-_-
5. 金山词霸的屏幕取词是什么原理
一.基础知识
首先想编这种程序需要一些基础知识。
会用Vc++,包括16/32位。
精通Windows API特别是GDI,KERNEL部分。
懂汇编语言,会用softice调试程序,因为这种程序最好用softice调试。
二.基本原理
在Window 3.x时代,windows系统提供的字符输出函数只有很少的几个。
TextOut
ExtTextOut
DrawText
......
其中DrawText最终是用ExtTextOut实现的。
所以Windows的所有字符输出都是由调用TextOut和ExtTextOut实现的。因此,如果你可以修改这两个函数的入口,让程序先调用你自己的一个函数再调用系统的字符输出,你就可以得到Windows所有输出的字符了。
到了Windows95时代,原理基本没变,但是95比3.x要复杂。开始的时候,一些在windows3.x下编写的取词软件仍然可以是使用。但是后来出了个IE4,结果很多词典软件就因为不支持IE4而被淘汰了,但同时也给一些软件创造了机会,如金山词霸。其实IE4的问题并不复杂,只不过它的输出的是unicode字符,是用TextOutW和ExtTextOutW输出的。知道了这一点,只要也截取就可以了。不过实现方法复杂一点,以后会有详细讲解。现在又出了个IE5,结果词霸也不好用了,微软真是#^@#$%$*&^@#@..........
我研究后找到了一种解决办法,但还有些问题,有时会取错,正在继续研究,希望大家共同探讨。
另外还有WindowsNT,原理也是一样,只是实现方法和95下完全不同。
三.技术要点
要实现取词,主要要解决以下技术问题。
1.截取API入口,获得API的参数。
2.安全地潜入Windows内部,良好地兼容Windows的各个版本
3.计算鼠标所在的单词和字母。
4.如果你在Window95下,做32位程序,还涉及Windows32/16混合编程的技术。
今天先到这里吧!最好准备一份softice for 95/98和金山词霸,让我们先来分析一下别人是怎么做的。
欢迎与我联系
E-Mail:[email protected]
主题 屏幕取词技术系列讲座(二)
作者 亦东
很抱歉让大家久等了!
我看了一些人的回帖,发现很多人对取词的原理还是不太清楚。
首先我来解释一下hook问题。词霸中的确用到了hook,而且他用了两种hook其中一种是Windows标准hook,通过SetWindowHook安装一个回调函数,它安装了一个鼠标hook,是为了可以及时响应鼠标的消息用的和取词没太大关系。
另一种钩子是API钩子,这才是取词的核心技术所在。他在TextOut等函数的开头写了一个jmp语句,跳转到自己的代码里。
你用softice看不到这个跳转语句是因为它只在取词的一瞬间才存在,平时是没有的。
你可以在TextOut开头设一个读写断点
bpm textout
再取词,就会找到词霸用来写钩子的代码了。
/**********************************
所以我在次强调,想学这种技术一定要懂汇编语言和熟练使用softice.
**********************************/
至于从cjktl95中mp出来的未公开函数是和Windows32/16混合编程有关的,以后我会提到他们。
我先来讲述取词的过程,
0 判断鼠标是否在一个地方停留了一段时间
1 取得鼠标当前位置
2 以鼠标位置为中心生成一个矩形
3 挂上API钩子
4 让这个矩形产生重画消息
5 在钩子里等输出字符
6 计算鼠标在哪个单词上面,把这个单词保存下来
7 如果得到单词则摘掉API钩子,在一段时间后,无论是否得到单词都摘掉API钩子
8 用单词查词库,显示解释框。
很多步骤实现起来都有一些难度,所以在中国可以做一个完善的取词词典的人屈指可数。
其中0,1,2,7,8比较简单就不提了。
先说如何挂钩子:
所谓钩子其实就是在WindowsAPI入口写一个JMP XXXX:XXXX语句,跳转到自己的代码里。
步骤如下:
1.取得Windows API入口,用GetProcAddress实现
2.保存API入口的前五个字节,因为JMP是0xEA,地址是4个字节
3.写入跳转语句
这步最复杂
Windows的代码段本来是不可以写的,但是Microsoft给自己留了个后门。
有一个未公开函数是AllocCsToDsAlias,
UINT WINAPI ALLOCCSTODSALIAS(UINT);
你可以取到这个函数的入口,把API的代码段的选择符(要是不知道什么是选择符,就先去学学保护模式编程吧)传给他,他会返回一个可写的数据段选择符。这个选择符用完要释放的。用新选择符和API入口的偏移量合成一个指针就可以写windows的代码段了。
这就是取词技术的最核心的东东,不止取词,连外挂中文平台全屏汉化都是使用的这种技术。现在知道为什么这么简单的几句话却很少知道了吧?因为太多的产品使用他,太多的公司靠他赚钱了。
这些公司和产品有:中文之星,四通利方,南极星,金山词霸,实达铭泰的东方快车,roboword,译典通,即时汉化专家等等等等。。。。还有至少20多家小公司。他们的具体实现虽然不同,但大致原理是相同的。
我这些都是随手写的,也没有提纲之类的东西,以后如果有机会我会整理一下,大家先凑合着看吧!xixi...
?
主题 关于屏幕取词的讨论(三)
作者 亦东
让大家久等,很抱歉,前些时候工作忙硬盘又坏了,太不幸了。
这回来点真格的。
咱们以截取TextOut为例。
下面是代码:
//截取TextOut
typedef UINT (WINAPI* ALLOCCSTODSALIAS)(UINT);
ALLOCCSTODSALIAS AllocCsToDsAlias;
BYTE NewValue[5];//保存新的入口代码
BYTE OldValue[5];//API原来的入口代码
unsigned char * Address=NULL;//可写的API入口地址
UINT DsSelector=NULL;//指向API入口的可写的选择符
WORD OffSetEntry=NULL;//API的偏移量
BOOL bHookAlready = FALSE; //是否挂钩子的标志
BOOL InitHook()
{
HMODULE hKernel,hGdi;
hKernel = GetMoleHandle("Kernel");
if(hKernel==NULL)
return FALSE;
AllocCsToDsAlias = (ALLOCCSTODSALIAS)GetProcAddress(hKernel,"AllocCsToDsAlias");//这是未公开的API所以要这样取地址
if(AllocCsToDsAlias==NULL)
return FALSE;
hGdi = GetMoleHandle("Gdi");
if(hmGdi==NULL)
return FALSE;
FARPROC Entry = GetProcAddress(hGdi,"TextOut");
if(Entry==NULL)
return FALSE;
OffSetEntry = (WORD)(FP_OFF(Entry));//取得API代码段的选择符
DsSelector = AllocCsToDsAlias(FP_SEG(Entry));//分配一个等同的可写的选择符
Address = (unsigned char*)MK_FP(DsSelector,OffSetEntry);//合成地址
NewValue[0]=0xEA;
*((DWORD*)(NewValue+1)) = (DWORD)MyTextOut;
OldValue[0]=Address[0];
*((DWORD*)(OldValue+1)) = *((DWORD*)(Address+1));
}
BOOL ClearHook()
{
if(bHookAlready)
HookOff();
FreeSelector(DsSelector);
}
BOOL HookOn()
{
if(!bHookAlready){
for(int i=0;i<5;i++){
Address[i]=NewValue[i];
}
bHookAlready=TRUE;
}
}
BOOL HookOff()
{
if(bHookAlready){
for(int i=0;i<5;i++){
Address[i]=OldValue[i];
}
bHookAlready=FALSE;
}
}
//钩子函数,一定要和API有相同的参数和声明
BOOL WINAPI MyTextOut(HDC hdc,int nXStart,int nYStart,LPCSTR lpszString,UINT cbString)
{
BOOL ret;
HookOff();
ret = TextOut(hdc,nXStart,nYStart,lpszString,cbString);//调原来的TextOut
HookOn();
return ret;
}
上面的代码是一个最简单的挂API钩子的例子,我要提醒大家的是,这段代码是我凭记忆写的,我以前的代码丢了,我没有编译测试过
因为我没有VC++1.52.所以代码可能会有错。
建议使用Borland c++,按16位编译。
如果用VC++1.52,则要改个选项
在VC++1.52的Option里,有个内存模式的设置,选大模式,和"DS!=SS DS Load on Function entry.",切记,否则会系统崩溃。
6. 如何用VC(也可以使用VC.NET或C#)实现金山词霸那样的取词功能
屏幕取词技术揭密(讨论稿)
?
主题 屏幕取词技术系列讲座(一)
作者 亦东
很多人对这个问题感兴趣。
原因是这项技术让人感觉很神奇,也很有商业价值。
现在词典市场金山词霸占了绝对优势,所以再做字典也没什么前途了。我就是这么认为的,所以我虽然掌握了这项技术,却没去做字典软件。只做了一个和词霸相似的软件自己用,本来想拿出来做共享软件,但我的词库是“偷”来的,而且词汇不多,所以也就算了,词库太小,只能取词有什么用呢?而且词霸有共享版的。
但既然很多人想了解这项技术,我也不会保留。我准备分多次讲述这项技术的所有细节。
大约每周一两次。想知道的人就常常来看看吧!
一.基础知识
首先想编这种程序需要一些基础知识。
会用Vc++,包括16/32位。
精通Windows API特别是GDI,KERNEL部分。
懂汇编语言,会用softice调试程序,因为这种程序最好用softice调试。
二.基本原理
在Window 3.x时代,windows系统提供的字符输出函数只有很少的几个。
TextOut
ExtTextOut
DrawText
......
其中DrawText最终是用ExtTextOut实现的。
所以Windows的所有字符输出都是由调用TextOut和ExtTextOut实现的。因此,如果你可以修改这两个函数的入口,让程序先调用你自己的一个函数再调用系统的字符输出,你就可以得到Windows所有输出的字符了。
到了Windows95时代,原理基本没变,但是95比3.x要复杂。开始的时候,一些在windows3.x下编写的取词软件仍然可以是使用。但是后来出了个IE4,结果很多词典软件就因为不支持IE4而被淘汰了,但同时也给一些软件创造了机会,如金山词霸。其实IE4的问题并不复杂,只不过它的输出的是unicode字符,是用TextOutW和ExtTextOutW输出的。知道了这一点,只要也截取就可以了。不过实现方法复杂一点,以后会有详细讲解。现在又出了个IE5,结果词霸也不好用了,微软真是#^@#$%$*&^@#@..........
我研究后找到了一种解决办法,但还有些问题,有时会取错,正在继续研究,希望大家共同探讨。
另外还有WindowsNT,原理也是一样,只是实现方法和95下完全不同。
三.技术要点
要实现取词,主要要解决以下技术问题。
1.截取API入口,获得API的参数。
2.安全地潜入Windows内部,良好地兼容Windows的各个版本
3.计算鼠标所在的单词和字母。
4.如果你在Window95下,做32位程序,还涉及Windows32/16混合编程的技术。
今天先到这里吧!最好准备一份softice for 95/98和金山词霸,让我们先来分析一下别人是怎么做的。
欢迎与我联系
E-Mail:[email protected]
主题 屏幕取词技术系列讲座(二)
作者 亦东
很抱歉让大家久等了!
我看了一些人的回帖,发现很多人对取词的原理还是不太清楚。
首先我来解释一下hook问题。词霸中的确用到了hook,而且他用了两种hook其中一种是Windows标准hook,通过SetWindowHook安装一个回调函数,它安装了一个鼠标hook,是为了可以及时响应鼠标的消息用的和取词没太大关系。
另一种钩子是API钩子,这才是取词的核心技术所在。他在TextOut等函数的开头写了一个jmp语句,跳转到自己的代码里。
你用softice看不到这个跳转语句是因为它只在取词的一瞬间才存在,平时是没有的。
你可以在TextOut开头设一个读写断点
bpm textout
再取词,就会找到词霸用来写钩子的代码了。
/**********************************
所以我在次强调,想学这种技术一定要懂汇编语言和熟练使用softice.
**********************************/
至于从cjktl95中mp出来的未公开函数是和Windows32/16混合编程有关的,以后我会提到他们。
我先来讲述取词的过程,
0 判断鼠标是否在一个地方停留了一段时间
1 取得鼠标当前位置
2 以鼠标位置为中心生成一个矩形
3 挂上API钩子
4 让这个矩形产生重画消息
5 在钩子里等输出字符
6 计算鼠标在哪个单词上面,把这个单词保存下来
7 如果得到单词则摘掉API钩子,在一段时间后,无论是否得到单词都摘掉API钩子
8 用单词查词库,显示解释框。
很多步骤实现起来都有一些难度,所以在中国可以做一个完善的取词词典的人屈指可数。
其中0,1,2,7,8比较简单就不提了。
先说如何挂钩子:
所谓钩子其实就是在WindowsAPI入口写一个JMP XXXX:XXXX语句,跳转到自己的代码里。
步骤如下:
1.取得Windows API入口,用GetProcAddress实现
2.保存API入口的前五个字节,因为JMP是0xEA,地址是4个字节
3.写入跳转语句
这步最复杂
Windows的代码段本来是不可以写的,但是Microsoft给自己留了个后门。
有一个未公开函数是AllocCsToDsAlias,
UINT WINAPI ALLOCCSTODSALIAS(UINT);
你可以取到这个函数的入口,把API的代码段的选择符(要是不知道什么是选择符,就先去学学保护模式编程吧)传给他,他会返回一个可写的数据段选择符。这个选择符用完要释放的。用新选择符和API入口的偏移量合成一个指针就可以写windows的代码段了。
这就是取词技术的最核心的东东,不止取词,连外挂中文平台全屏汉化都是使用的这种技术。现在知道为什么这么简单的几句话却很少知道了吧?因为太多的产品使用他,太多的公司靠他赚钱了。
这些公司和产品有:中文之星,四通利方,南极星,金山词霸,实达铭泰的东方快车,roboword,译典通,即时汉化专家等等等等。。。。还有至少20多家小公司。他们的具体实现虽然不同,但大致原理是相同的。
我这些都是随手写的,也没有提纲之类的东西,以后如果有机会我会整理一下,大家先凑合着看吧!xixi...
?
主题 关于屏幕取词的讨论(三)
作者 亦东
让大家久等,很抱歉,前些时候工作忙硬盘又坏了,太不幸了。
这回来点真格的。
咱们以截取TextOut为例。
下面是代码:
//截取TextOut
typedef UINT (WINAPI* ALLOCCSTODSALIAS)(UINT);
ALLOCCSTODSALIAS AllocCsToDsAlias;
BYTE NewValue[5];//保存新的入口代码
BYTE OldValue[5];//API原来的入口代码
unsigned char * Address=NULL;//可写的API入口地址
UINT DsSelector=NULL;//指向API入口的可写的选择符
WORD OffSetEntry=NULL;//API的偏移量
BOOL bHookAlready = FALSE; //是否挂钩子的标志
BOOL InitHook()
{
HMODULE hKernel,hGdi;
hKernel = GetMoleHandle("Kernel");
if(hKernel==NULL)
return FALSE;
AllocCsToDsAlias = (ALLOCCSTODSALIAS)GetProcAddress(hKernel,"AllocCsToDsAlias");//这是未公开的API所以要这样取地址
if(AllocCsToDsAlias==NULL)
return FALSE;
hGdi = GetMoleHandle("Gdi");
if(hmGdi==NULL)
return FALSE;
FARPROC Entry = GetProcAddress(hGdi,"TextOut");
if(Entry==NULL)
return FALSE;
OffSetEntry = (WORD)(FP_OFF(Entry));//取得API代码段的选择符
DsSelector = AllocCsToDsAlias(FP_SEG(Entry));//分配一个等同的可写的选择符
Address = (unsigned char*)MK_FP(DsSelector,OffSetEntry);//合成地址
NewValue[0]=0xEA;
*((DWORD*)(NewValue+1)) = (DWORD)MyTextOut;
OldValue[0]=Address[0];
*((DWORD*)(OldValue+1)) = *((DWORD*)(Address+1));
}
BOOL ClearHook()
{
if(bHookAlready)
HookOff();
FreeSelector(DsSelector);
}
BOOL HookOn()
{
if(!bHookAlready){
for(int i=0;i<5;i++){
Address[i]=NewValue[i];
}
bHookAlready=TRUE;
}
}
BOOL HookOff()
{
if(bHookAlready){
for(int i=0;i<5;i++){
Address[i]=OldValue[i];
}
bHookAlready=FALSE;
}
}
//钩子函数,一定要和API有相同的参数和声明
BOOL WINAPI MyTextOut(HDC hdc,int nXStart,int nYStart,LPCSTR lpszString,UINT cbString)
{
BOOL ret;
HookOff();
ret = TextOut(hdc,nXStart,nYStart,lpszString,cbString);//调原来的TextOut
HookOn();
return ret;
}
上面的代码是一个最简单的挂API钩子的例子,我要提醒大家的是,这段代码是我凭记忆写的,我以前的代码丢了,我没有编译测试过
因为我没有VC++1.52.所以代码可能会有错。
建议使用Borland c++,按16位编译。
如果用VC++1.52,则要改个选项
在VC++1.52的Option里,有个内存模式的设置,选大模式,和"DS!=SS DS Load on Function entry.",切记,否则会系统崩溃。
有什么不明白的可以给我写信
[email protected]
屏幕取词核心内幕屏幕取词核心内幕
本文只对与几个关键性技术的实现细节进行讨论,其它的编程细节,请参考源程序。
32位到16位的形式替换
32位代码与16位代码的数据交换
动态修改Windows内核
1. 32bit到16bit的形式替换(Thunk)
形式替换是指那些允许从16位代码调用32位代码或从32位代码调用16位代码的技术。形式替换用于解决试图在同一操作系统或同一可执行程序上使16位代码与32位代码同时并存的问题,即16位代码与32位代码的混合编程技术。早期的DOS程序及Window3.x上的应用程序均为16位程序,Windows95及Windows NT虽然也可运行旧的16位程序,但它们的主流发展方向是32位应用程序。与Windows NT不同的是,Windows95不是一个“纯”32位操作系统,为了兼有令人满意的速度和与旧的16位程序的良好兼容性,其内核本身就是一个16位与32位的混合体,因此也为编程者使用形式替换提供了便利。Microsoft为编写形式替换程序提供了通用的接口及工具,但因LTW32中的形式替换并不复杂,所以使用了一些编程技巧,而避免了使用Microsoft复杂的开发工具。
形式替换中最主要的问题有两点:①16位与32位数据类型尺寸的变化,如16位代码到32位代码的一个重要变化是整型数int的长度加倍了 ;②是堆栈操作时,16位模式使用SS:SP堆栈指针控制栈顶,而在32位模式中使用ESP寄存器作堆栈指针控制栈顶。
在LTW32中,屏幕抓词功能由16位DLL实现,因而只需实现32位到16位的形式替换,为32位代码提供16位DLL的调用接口。CALL FWORD PTR是32位汇编代码的一种调用方法,它可让32位代码调用到16位代码。作为实现的关键,控制16位侧与32位侧各自的堆栈是编程的要点。
32位侧的调用代码:
_asm{
pusha
call fword ptr [func16bit] /* func16bit是16位被调用者的48位地址 */
popa
}
16位侧的调用代码:
int mmy;
static char stack[8192]; /* 16位代码的临时堆栈 */
static WORD stack_seg;
static WORD prev_seg;
static DWORD prev_ofs;
static WORD prev_ds;
_asm{
push ax;
push bx;
mov ax, ds;
mov bx, seg mmy;
mov ds, bx;
mov stack_seg, bx;
mov prev_ds, ax;
pop bx;
pop ax;
mov prev_seg, ss;
mov dword ptr prev_ofs, esp; /* 保存32位堆栈指针 */
mov ss, stack_seg;
mov sp, offset stack; /* 设置16位堆栈指针 */
add sp, 8192;
}
/* 此处加入16位代码要实现的功能 */
_asm{
mov ss, prev_seg;
mov esp, dword ptr prev_ofs; /* 恢复32位堆栈指针 */
mov ds, prev_ds;
lea sp, word ptr [bp-2];
pop ds;
pop bp;
dec bp;
db 66h;
retf;
}
由于调用中传递的参数有限,所以涉及的代码并不多,唯一比较复杂之处在16位侧,它临时转向一个16位堆栈,服务于来自32位的调用者的请求。在16位侧入口处,必须存放好32位调用者的32位堆栈的指针,并且在16位侧返回时恢复它。由代码可见,这个过程是不可重入的,即一次只支持一个调用者,由于调用者只有LTW32的32位侧代码,所以此限制可以满足。另外,在16位代码返回时,必须恢复32位调用者的48位堆栈指针(SS:ESP)而不是32位的CS:SP,而且必须用一个48位地址(16:32)远返回(66h RETF)到它的32位调用者。
处理好这些细节,实现32位到16位的形式替换实际上是很简单的。
2. 32位代码与16位代码的数据交换
32位代码使用16位段地址加32位线性地址(16:32)的地址形式,16位代码使用16位段选择符(selector)加16位偏移(16:16)的地址形式。在Windows 95的32位侧,段址28h是系统段,即通过CS=28h或DS=28h可以访问系统的4G空间,其它应用程序的地址空间都是映射到28h段的4G空间中。Windows95中所有32位进程的地址空间(共4G)的高2G(80000000H~FFFFFFFFH)全部映射到28:80000000~28:FFFFFFFFH。即这块区域是所有32位程序共享的。这里一般存放系统DLL、虚拟设备驱动程序(VxD)、内存映射文件、16位应用程序和16位全局堆等。最后一项很重要,这为32位代码与16位代码交换数据提供了一个简便的方法。因为16位程序的段选择符的基址即是其所映射的系统段中的线性地址,这样,只要能够得到这个线性地址,32位代码就可以轻易地访问到16位程序的数据(LTW32 的32位侧使用此方法从16位侧获得屏幕截获的信息)。而16位段选择符的线性基址可以通过使用系统调用GetSelectorBase()得到,具体实现可参考源程序。线性地址计算的例子如下:
16位地址:07F2:1234H
段选择符 07F2H的线性基址为:82F41300H
段选择符 07F2H的尺寸为:4000H
∵ 82F41300H + 1234H = 82F42534
∴ 对应的32位线性地址为28:82F42534H
3. 动态修改Windows内核
如前所述,Windows95不是一个“纯”32位操作系统,其内核模块中的USER和GDI均是用16位代码实现的。USER32.DLL和GDI32.DLL只是16位的USER.EXE和GDI.EXE的32位调用接口。因此,如果屏幕截获程序用32位代码实现,则只能截获32位应用程序对USER32.DLL和GDI32.DLL的调用,无法截获16位应用程序对USER.EXE和GDI.EXE的调用,所以如果想截获所有应用程序(包括Windows95的桌面程序Explorer)中有关屏幕输出的系统调用,则应该用16位代码实现屏幕截获功能。这就是LTW32为什么不是“纯”32位应用程序的原因。LTW32主要截获两个系统调用TextOut()和ExtTextOut(),方法很简单,把这两个函数的头五个字节修改为一个JMP FAR 指令,使得对这两个函数的调用均转向屏幕截获程序。这就涉及到一个关键问题:动态修改Windows的代码。
在传统的DOS程序中,动态修改程序代码无任何困难,但在Windows中则不然,因为在Windows中,代码可被同一程序的多个实例(进程)共享,所以系统不允许应用程序动态的修改代码。在16位侧,内存的可读、写属性是与段选择符联系在一起的。段选择符基本上可分为两类:数据段选择符和代码段选择符。前者可读、可写、不可执行;后者可读、可执行、不可写。Windows提供了这两类段选择符相转换的系统调用。未公开的16位系统调用AllocCStoDSAlias()为给定的代码段选择符分配一个具有相同线性基址和尺寸的数据段别名(DS Alias)。通过DS别名可以对给定的代码段进行修改。AllocCStoDSAlias()的使用方法如下:
WORD (FAR PASCAL *AllocCStoDSAlias)(WORD);
AllocCStoDSAlias = GetProcAddress(
GetMoleHandle(“KERNEL”), ”ALLOCCSTODSALIAS”);
调用参数为给定的代码选择符,调用成功时返回一个线性基址和尺寸均与原代码选择符相同的DS别名。当不再使用此DS别名时,要用系统调用FreeSelector()把DS别名释放掉。
使用上述技术,就可实现动态修改Windows代码,从而改变GDI的系统调用TextOut()和ExtTextOut()的执行动作,实时地截获屏幕输出,为实现鼠标随动翻译提供可能。
把上述的32位到16位的形式替换、32位代码与16位代码的数据交换、动态修改Windows内核等技术综合应用在一起,配合单词查找算法和词组分析算法就可以实现鼠标随动翻译功能。
7. 能不能用C#做屏幕取词有源码吗
可以使用Tesseract-OCR
8. 有道词典怎么设置屏幕取词/自动翻译
有道词典开启【屏幕取词/自动翻译】步骤如下:
打开有道词典,在主页面的右下方,可以看到【取词】/【划词】
4.有道网络释义获取了大量存在于网络、但普通词典没有收录的流行词汇、外文名称和缩写,包括影视作品名称、名人姓名、品牌名称、地名、菜名、专业术语等。互联网内容日新月异,有道词库也与时俱进,轻松囊括互联网上的新词热词。
9. 请教关于用python编写屏幕取词的程序问题
1、屏幕取词技术实现原理与关键源码----
Ubuntu 下可以监视 gtk.Clipboard 来获取当前选中文字和位置。
我以前尝试过定时抓取鼠标附近图像做 OCR 来取词,
改成快捷键取词会省一点。
直接获得文字的悬停取词比较麻烦。
网页、XUL 应用程序可以有鼠标悬停事件。
X11 自己没有, 不过以前流行中文平台、中文外挂时候 Turbolinux 的中文 X-window 被修改为集成鼠标悬停取词翻译。
Gtk 程序也许你可以在 ATK 层入手,自己改 ATK 和用 LD_LIBRARY_PATH。
windows下很不好做。
普遍用的是HOOK API的方法。
可以参考stardict的取词模块。
不过我感觉stardict的取词模块也不是太好用(没金山词霸的好用),感觉有bug。
似乎以前某版本的金山词霸可以翻译图片中的文字,就是用 OCR
再,金山似乎出过 Linux Qt3 版本,找 Zoomq 几位在金山的老大索取源码看看吧
嗯, 金山词霸确实出过 Linux 版本,
是基于 wine 的,不是原生的 Linux 版本...
linux下就不知道,windows下,应该是做一个api hook,钩住TextOut,DrawText和DrawTextEx。
要取词的时候给鼠标所在的窗口发一个WM_PAINT消息,让窗口重绘。
当窗口调用TextOut, DrawText或是DrawTextEx进行重绘的时候,你就可以根据传入的参数知道
窗口想在鼠标下画什么东西了。
10. java屏幕取词
仅仅屏幕取词已经是一个很难的问题了,需要用到汇编和C语言,而java仅存在于虚拟机中,想要抓取外部的东西,这个技术更难以想象。估计还没人能搞出来了