大家应该都知道, Win32 API的SendMessage方法可以跨进程使用...-> 可以在[进程A]中发送消息到[进程B]的某个窗体...而[句柄]指定的窗体在收到消息后由WndProc与DefWndProc窗口过程进行处理...-> 在这种情况下, [接收窗体]该如何判断.消息.是由<系统>还是<其他进程>发送过来的呢???当然, 我所指的<其他进程>也包括自身的...请问大家, 这种要求能实现吗??? 该如何实现呢???

解决方案 »

  1.   

    我们是对于自己发送的消息会自定义特殊的Msg ID。
    接收者根据ID就可以判断出要做的事。
    至于如果要明确判断出发送者,不知道如何判断。
    (是不是有这个必要?)
      

  2.   

    是有这个必要的.至少我现在需要...对于已知的, 我们是可以用自定义消息来解决...但是未知的进程向我们的[应用程序]发送消息, 我要知道谁是[发送者]. 该如何判断???
    -> 我觉得Windows的消息值应该能标识消息发送者的句柄,可是找来找去没结果...-_-!!!
      

  3.   

    再说, MS这套[消息机制]不会那么单纯吧...就只有接收者的句柄, 至于<消息>的出处在哪? 都无证可查吗???
      

  4.   

    消息机制你也清楚。废话不多说了。
    消息从是
    信源->系统消息队列->hook->信宿
    这个过程的。信源发送后,就退出这个过程,这是PostMessage。消息是宏观的序列化操作方法,线程调度是微观的序列化操作方法。
    因为序列化操作。信宿处理消息的时候,信源很可能已经不存在了。不论是ProcessID还是ThreadID都可能不存在了。HWND就更不要想了。因为除了窗体,没窗体的程序,服务都可以发消息的。所以回溯消息是不可行也不容易保证正确的。所以是无法做到找到谁发的消息的。
      

  5.   

    首先! 感谢你们的关注...TO: wuyazhe ...按您所说, 要实现根本是不可能的...可是我以前无意中见到过一个工具, 它可以监控每个窗体发送的消息( 具体名字忘了 )...那它是怎样实现呢???
      

  6.   

    spy++?
    你是想实现那个效果么?那个应该和你的出发点不同。你是不知道对方是什么。单从消息往回推,那估计是推不回去。但如果是spy++。我不知道如何作的。但如果是我。我可以尝试的修改我想使用SetWindowLong设置到我这里一个函数来处理消息,然后啥也不做的再调用他原来的消息处理方法,这样我就知道某个窗体收到了什么消息了。我只见过能监控别的窗体收到消息的工具。没见过能监视对方发送的。你说的软件叫什么?
      

  7.   

    SPY++这个工具我知道...可是我说的并不是SPY++, 时间太长了, 想不起来, 我也尝试找回那个软件...-_-!!!消息是经过序列化后传到目标窗体. 所以回溯信源根本是不可能的...一般来说, 相同进程中的数据都会保存到进程所开劈的内存空间上...我们可不可以,换个角度, 判断每个Message结构的WParam与LParam的内存地址呢???
      

  8.   

    "消息是经过序列化后传到目标窗体. 所以回溯信源根本是不可能的...??"WIN32 WINDOWS MESSAGE 从来没有序列化的概念, 在任一进程内, 都可以用SendMessage或者PostMessage向特定窗口投递消息, 在WINDOWS消息中也从没有发送方的概念!!!!!"可是我以前无意中见到过一个工具, 它可以监控每个窗体发送的消息( 具体名字忘了 )...
    那它是怎样实现呢???"这个工具是SPY++, 在windows中要拦截一个消息是可能的, 用全局或局部hook即可实现,
    但即使hook了也只能拦截消息的内容, 同样无法获的发送方准确的说, 此题无解你硬要钻牛角, 推荐你研究一种方法, WIN32API hook, 监视所有调用过SendMessage, PostMessage的进程
      

  9.   

    支持楼上说的
    你要真要做  
    作个全局钩子 监视调用SendMessage PostMessage的进程
    就能知道了
      

  10.   

    全局Hook我已经做了, 可以监控窗体接收的所有信息...-------------------------------------------------监视所有调用过SendMessage, PostMessage的进程???这个不明白你好意思...
      

  11.   

    全局Hook我已经做了, 可以监控窗体接收的所有信息...-------------------------------------------------监视所有调用过SendMessage, PostMessage的进程???这个不明白你好意思...
    --------------------
    就是挂钩这两个API,这样当任意进程调用这两个函数的时候,
    就会先执行你的代码.
    然后你就可以做相应的处理.
      

  12.   

    勾进程比较好理解...勾API没做过. 能给个例子吗???
      

  13.   

    拦截API有很多种方法最简单的就是IAT说白了就是,先载入自定义函数,假设其地址是0XFF01找到API在地址表中的地址,假设是0XEE01那么就把地址表中的0XEE01改成0XFF01,那么其它程序字调用这个API时,就进入到自定义函数里面来了当然,这个自定义函数要完成两个工作:1:自己的事情做完后要交还给API
    2:自身模块被卸载后要把API地址改回去找IAT可以用ImageDirectoryEntryToData获取,方便点
      

  14.   

    TO: KKND2006 ...你说的方法, 就相当于窗体子类化, 想办把原来的函数地址换成自己的...处理完之后, 再交给原来的API继续做操作是吗???
      

  15.   

    原理都是一样的,无非是"代理"方式拦截API的方式非常之多,IAT是其中一种拦截API在<WINDOWS核心编程>中有详细叙述,看看教程就明白了
      

  16.   

    好的.谢谢...那我想问一下, [IAT] 须不须要注入或创建远程线程呢???因为之前那些都是用这两种方式做的, 个人觉得不好. 常被杀毒软件认为是病毒...超郁闷...
      

  17.   


    对于SendMessage理论上是可以查找到源进程的
    只要在消息响应函数中使用GetCurrentThreadID获得线程的ID,然后枚举所有进程,找到拥有这个线程的进程就可以。PostMessage就没办法溯源了
      

  18.   

    我来说一种方法,清大侠们赐教:
    1.搜索系统所有进程列表保存;
    2.往以上进程中加入hook,并且区分各个进程的hook,假设为hook[n];
    3.各个进程的hook对该进程所发的message检测并收集,然后向我们的进程回报结果
    4.我们可以根据汇报的hook的id,来去分是哪个进程发送的消息和什么样消息!
      

  19.   

    感谢两位提供的线索...首先我对oldforest提供的方法,存在一些疑问...您所说的[响应函数]是指窗口处理过程<WndProc与DefWndProc>吗???如果在这里执行GetCurrentThreadID, 也只能获取到创建当前窗口的线程ID而已. 能找到信源吗??^o^ 请继断指教...
    对于zzultc的方法, 好像不太可行...第一: 给所有进程加上Hook本来就不太现实...第二: 就算加上Hook, 也只能收集它所收到的消息, 那怎么检测它所发出的Message呢???是不是我不理解您的意思...
      

  20.   

    TO: oldforest ...是给SendMessage挂上勾子后, 在自己的接管函数里调用GetCurrentThreadID吗???
      

  21.   

    HOOK了API,那么你肯定会有一个接管函数 这个接管函数,在被调用时,肯定是在目标进程中应该只需要在这个函数内调用一下GetCurrentThreadID,就可以知道是哪个进程了然后再把PID什么的做个包发到你的程序,不就知道了不过这也只是理论上的东东,实际做的时候,恐怕问题多多,困难多多哦~~~~~~~+U啊,呵呵
      

  22.   

    只要在消息响应函数中使用GetCurrentThreadID获得线程的ID,然后枚举所有进程,找到拥有这个线程的进程就可以。这个行不通的。SendMessage会做同步,实际执行的还是本窗口的主线程。
      

  23.   

    常规API hook方法 
    一、难以实现
    二、难以稳定
    三、系统消耗太大
    四、杀毒软件不太欢迎Windows系统中每个API的调用, 都最终打包成服务请求,扔给了驱动, 系统维护着一张描述符表(SSDT), 这张表记录大部分服务的入口, 通过替换这些入口, 你可以钩住大部份API操作,比如注册表读、写, 大部分杀毒软件也将关卡设在这里, 比如卡巴斯基的注册表监控,
    (当然我不肯定SendMessage、PostMessage的服务也在其中) , 也许这是最佳方法
     
    如果仅仅是为讨论而讨论, 这个话题可以到此为止了, 因为最终你可能找不到答案!!
    如果是为项目为工作而讨论, 建议重新规划思路, 另寻解决方案
      

  24.   

    TO: longlijun ...对于您的建议, 我也同意的, 不过, 还是仅存一点希望能找到答案...^o^ C/C++的是您吧??? 嘻嘻...谢谢...
      

  25.   

    觉得CSDN现在越来越少人说话...高人都躲起来了吗???-_-!!!
      

  26.   

    有些问题的确很需要花费精力来解决而高手们不一定正好有那么多的精力要么自己想办法,要么继续顶.....顶到某位/些高手有时间&精力了帮你一下......
      

  27.   

    你找ReactOS代码看看,很多代码在驱动层里面实现的,比如说窗口创建的WM_CREATE WM_PAINT
    都是窗口管理器里面实现的。