深入浅出MFC文档/视图架构之相互关系(2)

本文介绍了MFC程序中基于文档/视图架构的消息处理机制。详细分析了消息流动过程,包括视图、文档、框架窗口及应用程序级别的处理顺序,并通过代码示例进行了验证。

2. 消息流动机制

  在基于"文档/视图"架构的MFC程序中,用户消息(鼠标、键盘输入等)会先发往视图,如果视图未处理则会发往框架窗口。所以,一般来说,消息映射宜定义在视图中。另外,如果一个应用同时拥有多个视图而当前活动视图没有对消息进行处理则消息也会发往框架窗口。

  下面我们来看实例,我们利用Visual C++向导创建一个单文档/视图架构的MFC程序,在其中增加一个菜单项为"自定义"(ID为IDM_SELF,如图6.4)。


图6.4 含"自定义"菜单的单文档/视图架构MFC程序

  我们分别在视图类和框架窗口类中为"自定义"菜单添加消息映射,代码如下:

//视图中的消息映射和处理函数
BEGIN_MESSAGE_MAP(CExampleView, CView)
 //{{AFX_MSG_MAP(CExampleView)
  ON_COMMAND(IDM_SELF, OnSelf)
 //}}AFX_MSG_MAP
END_MESSAGE_MAP()
void CExampleView::OnSelf()
{
 // TODO: Add your command handler code here
 AfxMessageBox("消息在视图中处理");
}

//框架窗口中的消息映射和处理函数
BEGIN_MESSAGE_MAP(CMainFrame, CFrameWnd)
 //{{AFX_MSG_MAP(CMainFrame)
  ON_COMMAND(IDM_SELF, OnSelf)
 //}}AFX_MSG_MAP
END_MESSAGE_MAP()

void CMainFrame::OnSelf()
{
 // TODO: Add your command handler code here
 AfxMessageBox("消息在框架窗口中处理");
}

  这时候,我们单击"自定义"菜单,弹出对话框显示"消息在视图中处理";如果我们删除框架窗口中的消息映射,再单击"自定义"菜单,弹出对话框也显示"消息在视图中处理";但是,若我们将视图中的消息映射删除了,就会显示"消息在框架窗口中处理"!这验证了我们关于消息处理顺序论述的正确性。

  欲深入理解消息流动过程,还需认真分析CFrameWnd::OnCmdMsg、CView::OnCmdMsg函数的源代码:

BOOL CFrameWnd::OnCmdMsg(UINT nID, int nCode, void* pExtra,
AFX_CMDHANDLERINFO* pHandlerInfo)
{
 // pump through current view FIRST
 CView* pView = GetActiveView();
 if (pView != NULL && pView->OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))
  return TRUE;

 // then pump through frame
 if (CWnd::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))
  return TRUE;

 // last but not least, pump through app
 CWinApp* pApp = AfxGetApp();
 if (pApp != NULL && pApp->OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))
  return TRUE;

 return FALSE;
}

BOOL CView::OnCmdMsg(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO* pHandlerInfo)
{
 // first pump through pane
 if (CWnd::OnCmdMsg(nID, nCode, pExtra, pHandlerInfo))
  return TRUE;

 // then pump through document
 BOOL bHandled = FALSE;
 if (m_pDocument != NULL)
 {
  // special state for saving view before routing to document
  _AFX_THREAD_STATE* pThreadState = AfxGetThreadState();
  CView* pOldRoutingView = pThreadState->m_pRoutingView;
  pThreadState->m_pRoutingView = this;
  bHandled = m_pDocument->OnCmdMsg(nID, nCode, pExtra, pHandlerInfo);
  pThreadState->m_pRoutingView = pOldRoutingView;
 }

 return bHandled;
}

  分析上述源代码可知,WM_COMMAND消息的实际流动顺序比前文叙述的"先视图,后框架窗口"要复杂得多,文档和应用程序都参与了消息的处理过程。如果我们再为文档和应用添加消息映射和处理函数:

//文档的消息映射和处理函数
BEGIN_MESSAGE_MAP(CExampleDoc, CDocument)
 //{{AFX_MSG_MAP(CExampleDoc)
  ON_COMMAND(IDM_SELF, OnSelf)
 //}}AFX_MSG_MAP
END_MESSAGE_MAP()

void CExampleDoc::OnSelf()
{
 // TODO: Add your command handler code here
 AfxMessageBox("消息在文档中处理");
}

//应用的消息映射和处理函数
BEGIN_MESSAGE_MAP(CExampleApp, CWinApp)
//{{AFX_MSG_MAP(CExampleApp)
ON_COMMAND(IDM_SELF, OnSelf)
//}}AFX_MSG_MAP
END_MESSAGE_MAP()

void CExampleApp::OnSelf()
{
 // TODO: Add your command handler code here
 AfxMessageBox("消息在应用中处理");
}

  屏蔽掉视图和框架窗口的消息映射,再单击"自定义"菜单,弹出对话框显示"消息在文档中处理";再屏蔽掉文档中的消息映射,弹出对话框显示"消息在应用中处理"!由此可见,完整的WM_COMMAND消息的处理顺序是"视图――文档――框架窗口――应用"!

  实际上,关于MFC的消息流动是一个很复杂的议题,陷于篇幅的原因,我们不可能对其进行更详尽的介绍,读者可自行寻找相关资料。
内容概要:本文详细记录了对一个Android ARM64静态ELF文件中字符串加密机制的逆向分析过程。该ELF文件的所有字符串均被加密,无法通过常规strings命令或IDA直接识别。作者通过分析发现,加密字符串存储在.rodata段,其解密所需信息(包括密文地址、长度和16位密钥)保存在.data.rel.ro段的40字节描述符中。核心解密函数sub_10F408采用自反的双pass流密码算法,结合固定密钥KEY_TERM(由.data段24字节数据计算得出),实现字节级非线性、位置与长度相关的加密。文章还复现了完整的Python解密脚本,并揭示了该保护机制的本质为代码混淆而非强加密,最终成功批量解密全部956条字符串,暴露程序真实行为,如shell命令模板、设备标识篡改、网络重置等操作。此外,文中还提及未启用的自定义壳框架及其反dump设计。; 适合人群:具备逆向工程基础的安全研究人员、二进制分析人员及对ELF保护技术感兴趣的开发者。; 使用场景及目标:①学习ELF二进制中字符串加密的典型实现方式与逆向突破口;②掌握从结构识别、函数追踪到算法还原的完整逆向流程;③理解“绑定二进制”的完整性校验设计及其局限性;④实践编写IDAPython脚本自动化提取与解密敏感数据。; 阅读建议:此资源以实战案例驱动,不仅展示技术细节,更强调逆向思维与验证方法,建议读者结合IDA调试环境,逐步跟随文中步骤进行动态分析与算法验证,深入理解每一步的推理依据。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值