获取进程信息在Realease下路径不完整的情况分析

最新推荐文章于 2024-02-25 16:45:57 发布
最新推荐文章于 2024-02-25 16:45:57 发布
阅读量875 收藏
点赞数
分类专栏： 木马/远控编写 调试 windows系统编程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/junbopengpeng/article/details/40395605
版权

在win7 x86 && x64下的Release版本会获取的进程的路径获取不到或者获取不完整的情况。

这是因为权限不够的原因，当然了获取进程的方法有很多，可以是使用toolhelp.dll以及psapi.dll中的函数进行获取.

在win7 x64下使用函数GetProcessImageFileName解决，但是还是有例如System这样的进程获取不到路径，要怎样的权限才能获取到这些进程的路径呢？


下面记录几个链接学习：

http://blog.youkuaiyun.com/sder3445555/article/details/7986627

http://bbs.youkuaiyun.com/topics/350227699

http://hi.baidu.com/viarus_zxx/item/918268c0f299f9200bd93a1f

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683217%28v=vs.85%29.aspx

Windows内核下获取进程全路径的方法
Think88666的博客
08-25 1197
Windows内核下获取进程全路径的方法
基于Curator对zookeeper分布式锁、Leader选举的实践和原理分析
yewandemty的博客
07-20 468
文章目录zookeeper在分布式锁和master选举实践一、包含的知识点二、基于Curator的分布式锁实现2.1 引如pom文件2.2 实现逻辑代码示例三、基于Curator的master选举实现3.1 引入pom文件3.2 实现逻辑代码示例四、Curator分布式锁实现原理4.1 分布式锁入口InterProcessMutex4.2 curator获取锁acquire4.3 curator释放锁release五、Curator选举Leader实现原理5.1 选举入口start()5.2 进行入队操作r
关于PsGetProcessImageFileName获取结果不全的问题
DaiCharlie的博客
12-13 1041
就是这个函数是获得EPROCESS结构体中的ImageFileName，而这个变量是15字节长度，超过就会截断。所以获取到的就不是准确的，下面给出准确获取的方法链接。
c++获取进程路径的几种方法（32位/64位程序的坑）
04-12 3462
这两天在做一个网络程序时，遇到了通过进程pid获取进程路径的需求，之前是用CreateToolhelp32Snapshot获取指定pid的模块，然后通过Module32First获取到其中的路径信息。不过因为本身程序是32位的，在获取64位程序时，却返回了299错误。经过网上查询，找到了另外的方法：OpenProcess打开指定pid进程，获得其句柄，该进程要有PROCESS_QUERY_INFO...
通过进程ID得到进程名
十年磨一剑，霜刃未曾试!
05-21 1万+
在内核中，通过进程ID，得到进程名称，有多种方法。我使用了两种方法，第一种是使用ZwOpeProcess得到句柄然后ObReferenceObjectByHandle函数得到PEPROCESS结构，然后char *ProcessName = (char*)EProcess + 0x174;第二种方法是得到PEPROCESS结构之后，使用PsGetProcessImageFileName函数得到进程名。具体代码如下：#include #include UCHAR* PsGetProcessImageF
[填坑记录][路径]jsp找不到对应的action的路径
jhqdlove的专栏
02-08 3051
问题：  程序运行时，js文件找不到对应的action的路径。检查Struts和hibernate文件配置都没有问题，js里面action的路径，感觉也是没有问题的，那么问题出在了哪里？  问题出在jsp里面的basePath和js里面的action路径不配套！  Eclipse 新建 jsp页面里自动生成以下代码： 
【Linux】进程间通信介绍 | 管道
joy.728的博客
02-25 2108
本篇博客主要讲解了什么是进程间通信、进程间通信的目的、什么是管道、管道的原理、匿名管道、管道的特点、命名管道等等。
Linux进程间通信详解
机会是给有准备的人
02-25 1211
进程间通信目的数据传输：一个进程需要将它的数据发送给另一个进程资源共享：多个进程之间共享同样的资源。通知事件：一个进程需要向另一个或一组进程发送消息，通知它（它们）发生了某种事件（如进程终止时要通知父进程）。进程控制：有些进程希望完全控制另一个进程的执行（如Debug进程），此时控制进程希望能够拦截另一个进程的所有陷入和异常，并能够及时知道它的状态改变。进程间通信发展管道System V进程间通信POSIX进程间通信进程间通信分类管道匿名管道pipe命名管道。
开源C++单元测试框架Google Test介绍
weixin_42488011的博客
04-29 1106
开源C++单元测试框架Google Test介绍 Google Test Google test是针对c/c++的开源测试项目。采用的协议是BSD license，有很多著名的开源项目采用了它，包括Chromium（谷歌浏览器开发版）。 安装配置 下载主页： http://code.google.com/p/googletest/ 官方资料文档： http://code.google.com/p/googletest/wiki/GoogleTestPrimer http://code.google.com/
八股面经总结-C++
qq_40808423的博客
04-21 5140
C++ [C++基础] 关键字与运算符 指针与引用 1. 指针存放某个对象的地址，其本身是变量（命名了的对象），本身就有地址，所以可以有指向指针的指针；可变，包括其所指向地址的改变和棋指向的地址中所存放的数据的改变 2. 引用就是变量的别名，从一而终，不可变，必须初始化 3.不存在指向空的值的引用，但是存在指向空值的指针 define 和 typedef 的区别 define： 1. 只是简单的字符串替换，没有类型检查 2. 是在编译的预处理阶段起作用 3. 可以用来防止头文件重复引用
玩转Google开源C++单元测试框架
weixin_42488011的博客
04-29 580
玩转Google开源C++单元测试框架Google Test系列(gtest)(总) 前段时间学习和了解了下Google的开源C++单元测试框架Google Test，简称gtest，非常的不错。 我们原来使用的是自己实现的一套单元测试框架，在使用过程中，发现越来越多使用不便之处，而这样不便之处，gtest恰恰很好的解决了。 其实gtest本身的实现并不复杂，我们完全可以模仿gtest，不断的完善我们的测试框架， 但最后我们还是决定使用gtest取代掉原来的自己的测试框架，原因是： 1.不断完善我们的测试框
Red5二次开发实现用户自定义逻辑
qq_41345281的博客
08-12 638
Red5二次开发实现用户自定义逻辑 上一篇文章介绍了Red5服务器的搭建是使用，这一篇文章将介绍如何在Red5中实现自己的逻辑。本文章是以第一篇为基础，默认已搭建好Red5服务器，不再介绍Red5服务器的搭建与使用。 准备工作 开发工具：Eclipse Red5 Server：Red5 Server 1.0.9 https://github.com/Red5/red5-server red5-eclipse-plugin：https://github.com/Red5/red5-eclipse-plugi
根据Handle获取进程名的方法
坦然
08-13 2590
写ZwTerminateProcess hook的时候hook到ZwTerminateProcess的参数是HANDLE ProcessHandle和NTSTATUS ExitStatus。结构如下： NTSTATUS   ZwTerminateProcess(     IN HANDLE  ProcessHandle,     IN NTSTATUS  ExitStatus
[Win32] 获取进程完整路径
zuishikonghuan的博客
08-18 1万+
上两篇中，我们讲到了ToolHelp API，Process API和提升Debug权限，这一篇中来说说如何获取进程的程序路径。 获取进程路径其实有很多方法。 方法1。使用ToolHelp API枚举模块，其中，Module32First得到一个MODULEENTRY32 结构，结构中有一个szExePath成员，这个成员代表这个进程第一个模块的路径，也就是进程的路径 （32位程序只能获取3
Hook技术之API拦截(API Hook)
热门推荐
bobopeng
06-02 3万+
Inline Hook就是修改
HTTP代理服务器的实现
bobopeng
02-13 2万+
一．套接字编程 API函数介绍 SOCKET accept( SOCKET s , struct sockaddr_in FAR * addr ,int Far *addlen ) ;  函数说明：当没有连接请求时，对于阻塞式套接字，如果程序调用了accept函数，那么线程将进入等待状态，知道有一个连接请求到达为止，accept在接收到连接请求时，会为这个连接建立起一个新的套接字
网络嗅探器(Sniffer)的原理与实现(1)
bobopeng
02-19 1万+
一.背景 为了使不同体系结构的计算机网络都能进行互联，国际标准化组织ISO于1997年成立了专门的结构研究这个问题。不久他们就提出了一个试图使各种计算机在世界范围内都能互联的成网的标准框架，即著名的OSI/RM(Open Systems Interconnection Reference Model , 开放系统互联基本参考模型），简称为OSI。它的主要目标是：只要遵循OSI标准，一个系统就可以
MFC中的CListCtrl添加右键菜单消息响应实例分析
bobopeng
07-04 7617
一.创建一个菜单资源 无论是
利用socket自己实现基于HTTP协议的Web服务器
bobopeng
01-14 7385
在开发网站的过程中，首先我们需要配置一个web服务器，一般会使用Apache这个开源的服务器软件，扩展性高，支持性也很好。实际上如果是windows系统的话那么也可以使用windows操作系统提供的IIS(Internet Information Server)。这两个服务器软件使用度各占60%和30%。但是现在，我们经过分析HTTP协议，我们会自己实现一个Web服务器，当然了，只是一个很小的We
为什么realease版本 O1优化等级，RTT打印不能使用了？
最新发布
03-26
<think>好的，我现在要解决用户的问题：“为什么release版本 O1优化等级，RTT打印不能使用了？”首先，我需要理解用户的问题背景。用户在使用某种嵌入式系统，可能是在使用类似ARM Cortex-M系列的芯片，并且使用了SEGGER的RTT（Real-Time Transfer）进行日志打印。在Debug版本下可能正常，但切换到Release版本并使用O1优化等级时，RTT打印失效了。我需要逐步分析可能的原因。 首先，回忆一下编译器优化对代码的影响。O1优化等级会进行一些基本的优化，比如删除未使用的代码、内联小函数、调整循环等。这些优化可能导致某些代码被意外删除或改变执行顺序，进而影响RTT的输出。 接下来，RTT的工作原理是怎样的？RTT通常通过特定的内存区域与调试器通信，不需要额外的硬件引脚。它依赖于特定的数据结构（如控制块）存在于内存中，并且应用程序需要正确写入数据到这些区域。如果编译器优化导致这些数据结构未被正确保留，或者写入操作被优化掉，那么RTT就无法正常工作。 可能的原因一：链接脚本或内存区域的问题。在Release版本中，可能链接脚本被修改，导致RTT所需的内存区域未被正确保留。例如，RTT控制块可能被放置在未初始化的内存区域，而Release模式下可能优化了这部分，导致数据被覆盖或未被正确分配。 需要检查链接脚本（.ld文件）中是否有保留RTT使用的部分，比如SEGGER_RTT_SECTION。在Release配置中，是否可能因为优化选项导致这部分被忽略或合并到其他段中，导致数据被覆盖。 可能的原因二：编译器优化删除了必要的代码。例如，如果RTT打印函数在某些情况下被编译器判定为无用代码（比如输出变量未被后续使用），可能会被优化掉。例如，用户可能有如下的代码： printf_rtt("Debug info: %d", variable); 如果variable在后续代码中没有被使用，且编译器认为printf_rtt没有副作用（比如没有正确声明为具有副作用），则O1优化可能会删除这行代码。 此时需要检查RTT的打印函数是否被正确声明，例如使用__attribute__((used))或者volatile来防止优化。或者，是否在函数声明中使用了适当的修饰符，告诉编译器该函数有副作用，不应该被优化掉。 可能的原因三：RTT缓冲区被优化。RTT使用全局变量作为缓冲区，如果编译器认为这些变量未被访问，可能会将其优化掉。例如，在Release模式下，如果代码中没有显式引用这些缓冲区变量，编译器可能认为它们未被使用，从而删除它们。此时需要使用volatile关键字或者将其放置在特定的段中，防止被优化。 可能的原因四：优化导致时序问题。某些情况下，优化后的代码执行速度更快，可能导致RTT的缓冲区未及时处理，或者硬件响应不及时。但这种情况可能较少见，除非RTT的实现有严格的时序要求，而优化后的代码改变了执行流程，导致通信失败。 接下来，我需要考虑如何验证这些可能的原因。用户可能需要检查以下几点： 1. 检查链接脚本是否在Release配置中正确保留RTT所需的内存区域，确保RTT控制块和缓冲区没有被其他数据覆盖。 2. 检查RTT相关的变量和缓冲区是否被正确声明，例如使用volatile或者特定的段属性，防止编译器优化删除。 3. 检查RTT打印函数是否被编译器优化掉。可以通过查看生成的汇编代码，或者在代码中添加__attribute__((used))或#pragma指令来保留函数。 4. 在代码中临时禁用优化，例如在函数前使用#pragma GCC optimize("O0")，看是否恢复功能，从而确认是否是优化导致的问题。 另外，O1优化可能还会影响调试信息，但Release版本通常不包含调试符号，这可能让问题更难追踪。用户可能需要生成反汇编代码，查看相关函数是否还存在，或者是否被内联、删除。 例如，如果用户使用GCC编译器，可以通过查看map文件来确认RTT相关的符号是否存在于最终的可执行文件中。如果不存在，说明被优化掉了，需要调整代码或编译器选项。 可能的解决方案包括： - 在RTT相关的变量和函数前添加修饰符，如__attribute__((used))，确保编译器不优化它们。 - 在链接脚本中显式保留RTT使用的内存段，确保在Release版本中不会被其他数据占用。 - 检查RTT的初始化代码是否被优化，可能需要将其放在特定的函数中，并在main函数中显式调用，防止链接器优化掉未显式调用的代码。 - 使用volatile关键字修饰RTT的缓冲区指针，防止编译器优化对缓冲区的访问。 此外，用户可能还需要确认在Release配置中，是否禁用了某些必要的功能，比如Semihosting或者其他调试相关的设置，这些可能会影响RTT的正常工作。 总结来说，最可能的原因是编译器优化删除了RTT相关的代码或数据，或者链接脚本未正确配置导致内存区域被覆盖。用户需要逐一排查这些可能性，通过检查生成的代码和内存布局，调整代码或编译选项来解决。</think>针对Release版本使用O1优化导致RTT打印失效的问题，以下是可能原因及解决方案的逐步分析： --- ### **1. 编译器优化删除关键代码** **现象**：编译器认为RTT相关函数或变量未被使用，直接优化删除。 **验证方法**： - 检查生成的汇编代码（如使用`objdump`），确认RTT函数（如`SEGGER_RTT_Write`）是否被保留。 - 在代码中对RTT函数添加`__attribute__((used))`，强制保留函数。 **解决方案**： - 在RTT函数声明前添加编译器特定的保留属性： ```c __attribute__((used)) void SEGGER_RTT_Write(...); ``` - 对RTT缓冲区变量使用`volatile`修饰： ```c volatile char rtt_buffer[BUFFER_SIZE]; ``` --- ### **2. 链接脚本未保留RTT内存区域** **现象**：RTT控制块或缓冲区被其他数据覆盖。 **验证方法**： - 检查链接脚本（.ld文件）是否包含RTT专用段（如`SEGGER_RTT_SECTION`）。 - 在map文件中搜索`_SEGGER_RTT`符号，确认其地址合法且未被占用。 **解决方案**： - 在链接脚本中显式保留RTT段： ```ld .rtt_section : { KEEP(*(SEGGER_RTT_SECTION)) } > RAM ``` --- ### **3. 初始化代码被优化** **现象**：RTT初始化函数（如`SEGGER_RTT_Init()`）未被调用。 **验证方法**： - 在代码中插入调试语句（如点亮LED），确认初始化函数是否执行。 **解决方案**： - 显式调用初始化函数，并标记为`used`： ```c __attribute__((used)) void init_rtt(void) { SEGGER_RTT_Init(); } ``` - 在`main()`函数中强制调用初始化代码。 --- ### **4. 缓冲区访问被优化导致数据未更新** **现象**：编译器认为缓冲区写入操作无意义（如未读取），优化掉写操作。 **解决方案**： - 使用`volatile`修饰缓冲区指针： ```c volatile char* p_rtt_buffer = (char*)RTT_BUFFER_ADDR; ``` --- ### **5. 优化导致时序问题** **现象**：优化后代码执行过快，RTT通信未完成。 **解决方案**： - 在关键操作（如写入缓冲区后）添加短暂延迟： ```c SEGGER_RTT_Write(...); for (volatile int i = 0; i < 1000; i++); // 短暂延时 ``` --- ### **操作建议** 1. **逐步验证**： - 在Release配置中**暂时关闭优化**（`-O0`），确认RTT是否恢复。 - 逐步开启优化等级（O1→O2→O3），定位触发问题的优化阶段。 2. **查看编译器文档**： - 查阅O1优化的具体行为（如GCC的`-fomit-frame-pointer`可能影响调试）。 3. **使用调试工具**： - 通过JTAG/SWD读取内存，检查RTT控制块是否被正确初始化。 --- ### **总结** 根本原因通常是**编译器优化误删关键代码或数据**，或**内存配置冲突**。通过显式保留代码/数据、调整链接脚本、使用`volatile`修饰符等手段，可有效解决问题。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值