API HOOK 金山词霸取词功能原理2

本文介绍了一种屏幕抓词技术的实现方法,该方法通过截获特定系统函数调用来获取屏幕上显示的文字信息。具体步骤包括获取鼠标位置、触发窗口重绘、重定向系统函数调用等。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

屏幕上的文字大都是由gdi32.dll的以下几个函数显示的:TextOutATextOutWExtTextOutAExtTextOutW。实现屏幕抓词的关键就是截获对这些函数的调用,得到程序发给它们的参数。  
   
 
  我的方法有以下三个步骤:  
   
 
  一、得到鼠标的当前位置  
   
 
  通过SetWindowsHookEx实现。  
   
 
  二、向鼠标下的窗口发重画消息,让它调用系统函数重画  
   
 
  通过WindowFromPointScreenToClientInvalidateRect   实现。  
   
 
  三、截获对系统函数的调用,取得参数(TextOutA为例)  
   
 
  1.仿照TextOutA作成自己的函数MyTextOutA,与TextOutA有相同参数和返回值,放在系统钩子所在的DLL里。  
   
 
  SysFunc1=(DWORD)GetProcAddress(GetModuleHandle("gdi32.dll"),"TextOutA");  
   
 
  BOOL   WINAPI   MyTextOutA(HDC   hdc,   int   nXStart,   int   nYStart,   LPCSTR   lpszString,int   cbString)  
   
 
  {   //输出lpszString的处理  
   
  return   ((FARPROC)SysFunc1)(hdc,nXStart,nYStart,lpszString,cbString);}  
   
 
  2.由于系统鼠标钩子已经完成注入其它GUI进程的工作,我们不需要为注入再做工作。  
   
 
  如果你知道所有系统钩子的函数必须要在动态库里,就不会对"注入"感到奇怪。当进程隐式或显式调用一个动态库里的函数时,系统都要把这个动态库映射到 这个进程的虚拟地址空间里(以下简称"地址空间")。这使得DLL成为进程的一部分,以这个进程的身份执行,使用这个进程的堆栈(见图1)  
   
   
 
  图1   DLL映射到虚拟地址空间中  
   
 
  对系统钩子来说,系统自动将包含"钩子回调函数"DLL映射到受钩子函数影响的所有进程的地址空间中,即将这个DLL注入了那些进程。  
   
 
  3.当包含钩子的DLL注入其它进程后,寻找映射到这个进程虚拟内存里的各个模块(EXEDLL)的基地址。EXEDLL被映射到虚拟内存空间的 什么地方是由它们的基地址决定的。它们的基地址是在链接时由链接器决定的。当你新建一个Win32工程时,VC++链接器使用缺省的基地址 0x00400000。可以通过链接器的BASE选项改变模块的基地址。EXE通常被映射到虚拟内存的0x00400000处,DLL也随之有不同的基地 址,通常被映射到不同进程的相同的虚拟地址空间处。  
   
 
  如何知道EXEDLL被映射到哪里了呢?  
   
 
  在Win32中,HMODULEHINSTANCE是相同的。它们就是相应模块被装入进程的虚拟内存空间的基地址。比如:  
   
 
  HMODULE   hmodule=GetModuleHandle(gdi32.dll);  
   
 
  返回的模块句柄强制转换为指针后,就是gdi32.dll被装入的基地址。  
   
 
  关于如何找到虚拟内存空间映射了哪些DLL?我用如下方式实现:  
   
  while(VirtualQuery   (base,  
mbi,   sizeof   (mbi))0)  
   
  {   if(mbi.Type==MEM-IMAGE)  
   
  ChangeFuncEntry((DWORD)mbi.BaseAddress,1);  
   
  base=(DWORD)mbi.BaseAddress
mbi.RegionSize;   }  
   
 
  4.得到模块的基地址后,根据PE文件的格式穷举这个模块的IMAGE-IMPORT-DESCRIPTOR数组,看是否引入了gdi32.dll。如是,则穷举IMAGE-THUNK-DATA数组,看是否引入了TextOutA函数。  
   
 
  5.如果找到,将其替换为相应的自己的函数。  
   
 
  系统将EXEDLL原封不动映射到虚拟内存空间中,它们在内存中的结构与磁盘上的静态文件结构是一样的。即PE   (Portable   Executable)   文件格式。  
   
 
  所有对给定API函数的调用总是通过可执行文件的同一个地方转移。那就是一个模块(可以是EXEDLL)的输入地址表(import   address   table)。那里有所有本模块调用的其它DLL的函数名及地址。对其它DLL的函数调用实际上只是跳转到输入地址表,由输入地址表再跳转到DLL真正的 函数入口。例如:  
   
   
 
  图2   MessageBox()的调用跳转到输入地址表,从输入地址表再跳转到MessageBox函数  
   
   
 
  IMAGE-IMPORT-DESCRIPTORIMAGE-THUNK-DATA分别对应于DLL和函数。它们是PE文件的输入地址表的格式(数据结构参见winnt.h)。  
   
 
  BOOL   ChangeFuncEntry(HMODULE   hmodule)  
   
 
  {   PIMAGE-DOS-HEADER   pDOSHeader;  
   
 
  PIMAGE-NT-HEADERS   pNTHeader;  
   
 
  PIMAGE-IMPORT-DESCRIPTOR   pImportDesc;  
   
  /   get   system   functions   and   my   functions′entry   /  
   
 
  pSysFunc1=(DWORD)GetProcAddress(GetModuleHandle(gdi32.dll),TextOutA);  
   
 
  pMyFunc1=   (DWORD)GetProcAddress(GetModuleHandle(hookdll.dll),MyTextOutA);  
   
  pDOSHeader=(PIMAGE-DOS-HEADER)hmodule;  
   
 
  if   (IsBadReadPtr(hmodule,   sizeof(PIMAGE-NT-HEADERS)))  
   
 
     return   FALSE;  
   
 
  if   (pDOSHeader-〉e-magic   !=   IMAGE-DOS-SIGNATURE)  
   
 
     return   FALSE;  
   
 
  pNTHeader=(PIMAGE-NT-HEADERS)((DWORD)pDOSHeader+(DWORD)pDOSHeader-〉e-lfanew);  
   
 
  if   (pNTHeader-〉Signature   !=   IMAGE-NT-SIGNATURE)  
   
 
     return   FALSE;  
   
 
  pImportDesc   =   (PIMAGE-IMPORT-DESCRIPTOR)((DWORD)hmodule(DWORD)pNTHeader-〉OptionalHeader.DataDirectory  
   
 
     [IMAGE-DIRECTORY-ENTRY-IMPORT].VirtualAddress);  
   
 
  if   (pImportDesc   ==   (PIMAGE-IMPORT-DESCRIPTOR)pNTHeader)  
   
  return   FALSE;  
   
 
  while   (pImportDesc-〉Name)  
   
 
  {   PIMAGE-THUNK-DATA   pThunk;  
   
 
  strcpy(buffer,(char   )((DWORD)hmodule+(DWORD)pImportDesc-〉Name));  
   
  CharLower(buffer);  
   
  if(strcmp(buffer,"gdi32.dll"))  
   
  {   pImportDesc++;  
   
  continue;  
   
  }else  
   
  {   pThunk=(PIMAGE-THUNK-DATA)((DWORD)hmodule
(DWORD)pImportDesc-〉FirstThunk);  
   
  while   (pThunk
-〉u1.Function)  
   
  {   if   ((pThunk
-〉u1.Function)   ==   pSysFunc1)  
   
  {   VirtualProtect((LPVOID)(&pThunk
-〉u1.Function),  
   
 
     sizeof(DWORD),PAGE-EXECUTE-READWRITE,&dwProtect);  
   
 
     (pThunk-〉u1.Function)=pMyFunc1;  
   
 
     VirtualProtect((LPVOID)(&pThunk-〉u1.Function),   sizeof(DWORD),dwProtect,&temp);   }  
   
  pThunk++;   }   return   1;}}}  
   
 
  替换了输入地址表中TextOutA的入口为MyTextOutA后,截获系统函数调用的主要部分已经完成,当一个被注入进程调用TextOutA 时,其实调用的是MyTextOutA,只需在MyTextOutA中显示传进来的字符串,再交给TextOutA处理即可。

 
资源下载链接为: https://pan.quark.cn/s/140386800631 通用大模型文本分类实践的基本原理是,借助大模型自身较强的理解和推理能力,在使用时需在prompt中明确分类任务目标,并详细解释每个类目概念,尤其要突出类目间的差别。 结合in-context learning思想,有效的prompt应包含分类任务介绍及细节、类目概念解释、每个类目对应的例子和待分类文本。但实际应用中,类目和样本较多易导致prompt过长,影响大模型推理效果,因此可先通过向量检索缩小范围,再由大模型做最终决策。 具体方案为:离线时提前配置好每个类目的概念及对应样本;在线时先对给定query进行向量召回,再将召回结果交给大模型决策。 该方法不更新任何模型参数,直接使用开源模型参数。其架构参考GPT-RE并结合相关实践改写,加入上下文学习以提高准确度,还使用BGE作为向量模型,K-BERT提取文本关键词,拼接召回的相似例子作为上下文输入大模型。 代码实现上,大模型用Qwen2-7B-Instruct,Embedding采用bge-base-zh-v1.5,向量库选择milvus。分类主函数的作用是在向量库中召回相似案例,拼接prompt后输入大模型。 结果方面,使用ICL时accuracy达0.94,比bert文本分类的0.98低0.04,错误类别6个,处理时添加“家居”类别,影响不大;不使用ICL时accuracy为0.88,错误58项,可能与未修改prompt有关。 优点是无需训练即可有较好结果,例子优质、类目界限清晰时效果更佳,适合围绕通用大模型api打造工具;缺点是上限不高,仅针对一个分类任务部署大模型不划算,推理速度慢,icl的token使用多,用收费api会有额外开销。 后续可优化的点是利用key-bert提取的关键词,因为核心词语有时比语意更重要。 参考资料包括
内容概要:本文详细介绍了哈希表及其相关概念和技术细节,包括哈希表的引入、哈希函数的设计、冲突处理机制、字符串哈希的基础、哈希错误率分析以及哈希的改进与应用。哈希表作为一种高效的数据结构,通过键值对存储数据,能够快速定位和检索。文中讨论了整数键值和字符串键值的哈希方法,特别是字符串哈希中的多项式哈希及其优化方法,如双哈希和子串哈希的快速计算。此外,还探讨了常见的冲突处理方法——拉链法和闭散列法,并提供了C++实现示例。最后,文章列举了哈希在字符串匹配、最长回文子串、最长公共子字符串等问题中的具体应用。 适合人群:计算机科学专业的学生、算法竞赛选手以及有一定编程基础并对数据结构和算法感兴趣的开发者。 使用场景及目标:①理解哈希表的工作原理及其在各种编程任务中的应用;②掌握哈希函数的设计原则,包括如何选择合适的模数和基数;③学会处理哈希冲突的方法,如拉链法和闭散列法;④了解并能运用字符串哈希解决实际问题,如字符串匹配、回文检测等。 阅读建议:由于哈希涉及较多数学知识和编程技巧,建议读者先熟悉基本的数据结构和算法理论,再结合代码实例进行深入理解。同时,在实践中不断尝试不同的哈希策略,对比性能差异,从而更好地掌握哈希技术。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值