又出问题了。救命啊!

lovering 2000-10-26 04:33:00
现在我的程序终于能收qp编码的邮件了。
可是新问题出来了,不知道为什么不能删除一个数组。只能收到第一封信。
进行到delete []sbuf时出错
DAMAGE: after normal block (#68) at 0x00650089


附带源码如下,救命啊!!!!!
BOOL CPop3Connection::ReadReturnResponse(CPop3Message& message, DWORD dwSize)
{
//Must be connected to perform a "RETR"
ASSERT(m_bConnected);

//We need a flexible sized receiver buffer here
int nSize = dwSize + 100;
char* sBuf = new char[nSize];
if (!ReadResponse(sBuf, nSize, "\r\n\r\n"))
{
TRACE(_T("Error retrieving the RETR response"));
return FALSE;
}

//determine if the response is an error
if (strnicmp(sBuf,"+OK", 3) != 0)
{
SetLastError(WSAEPROTONOSUPPORT);
TRACE(_T("POP3 server did not respond correctly to the RETR response\n"));
delete []sBuf;
return FALSE;
}
else
{
//remove the first line which contains the +OK from the message
char* pszFirst = GetFirstCharInResponse(sBuf);
VERIFY(pszFirst);

//transfer the message contents to the message class
int nMessageSize = sBuf - pszFirst + strlen(sBuf);
message.m_pszMessage = new char[nMessageSize + 1];
memcpy(message.m_pszMessage, pszFirst, nMessageSize);
message.m_pszMessage[nMessageSize] = '\0';
}
delete []sBuf;
return TRUE;
..........

...全文
132 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复
内容概要:本文详细记录了对一个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调试环境,逐步跟随文中步骤进行动态分析与算法验证,深入理解每一步的推理依据。

16,550

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Creator Browser
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧