blocks|key|2716803|text|您可以使用反汇编程序将可执行文件反汇编回程序集，并与普通的文本比较工具进行比较。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2716804|但即便如此，这也不是100%25准确的。编译过程并不是无损的，在编译C%2B%2B代码时，许多信息会丢失或不可逆地转换。|2716805|特别是，不同的编译器设置可以从完全相同的源代码生成截然不同的机器码。不同的编译器，甚至相同编译器的不同版本或服务包/热修复级别，都可能从相同的源文件中生成非常不同的机器码。|2716806|另一个问题是，为什么他们“表面上没有做任何修改”就把exe送回给你了？如果是这样的话，为什么不直接使用原来的版本呢？|2716807|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

You could use a dissembler to disassemble the executable back into assembly and compare with a normal text diff tool.

But even that will not be 100% accurate. The compilation process is not lossless and much information is lost or irreversibly transformed when C++ code is compiled.

In particular, different compiler settings can generate vastly different machine code from exactly the same source. Different compilers and even different versions or service-pack/hotfix levels of the same compiler can produce vastly different machine code from the same source files.

The other question is, why are they even sending you the exe back "ostensibly with no changes made"? If that's the case, why don't you just use the one you had originally?

blocks|key|2716921|text|您始终可以对可执行文件执行MD5sum。这不会告诉您它们在逻辑上是等价的还是不同的，只是简单地说它们之间存在差异。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2716922|我不确定这是否解决了您的问题，因为您可能正在寻找一个逻辑比较工具。|2716923|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You can always perform an MD5sum on the executables. This won't tell you whether they are logically equivalent or different, simply that a difference exists.

I'm not sure if this solves your issue, as you may be looking for a logical comparison tool.

blocks|key|401709|text|自动化您的测试，以便可以快速重新运行测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|401710|尽管这只是一个小小的声明，但却是一件大事。|401711|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Automate your testing so that the tests can be rerun quickly. 

Even though this is a small statement to make, it is a big undertaking

blocks|key|2717062|text|对于二进制审计，必须拥有的最好的工具之一是交互式反汇编程序，也更为人所知的是。当您需要在不访问源代码的情况下进行审计时，它是必备的。精通使用IDA+Pro的人将能够以合理的信心告诉你，如果源代码有任何表面上的变化。在这种情况下，表面上的更改包括在源文件中重命名变量，或者更改变量、函数或类声明和定义的顺序。它们将能够告诉您组成可执行文件的基本代码块之间的差异是否足够大，足以被标记为可疑，因为这些差异很可能表示源代码级别的差异。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2717063|我之所以说或多或少，是因为从完全相同的源代码树生成的两个可执行文件在几种方式下仍然可能存在彼此之间的细微差异，有时也不是那么微妙。可能影响可执行文件生成的因素包括：|2717064|settings|2717065|differing+|unordered-list-item|2717066|编译器优化settings|2717067|differing库的版本可执行文件与对头文件所做的更改(位于用于构建可执行文件的源代码树的外部)链接在一起，这些更改在编译步骤之前由C%2B%2B预处理器包括|2717068|在运行时操纵其自己的代码的可执行文件，这可能包括将其自身的某一部分动态解压或解密到内存的某个区域中它可以跳转到|2717069|2717070|2717071|这份清单可能会持续一段时间。|2717072|你所建议的二进制审计是可能的吗？是的，一个有足够知识和技能的人可以做到这一点。黑客一直都在这么做。如果做分析的人足够好，他们就能准确地告诉你他们对自己的评估有多自信。|2717073|最终，这变成了一个可行性问题。你愿意在这次审计上花多少钱？雇佣或签约能够做到这一点的人可能会超出此类审计的预算，有足够的资金做到这一点吗？你正在测试的软件有多复杂？您与供应商的关系是什么性质的？|2717074|最后一个问题很重要，因为如果通过审计符合他们的最佳利益，而且他们意识到了这一点，他们可能愿意在一定程度上帮助你。这可能以调试符号的形式出现，使用的编译器选项列表或他们愿意公开的构建过程的一些其他工件。在任何源代码是而不是的分析代码中，由于某种原因，为了分析的目的而使其可用，上述所有内容都非常有用。如果access+to+the+source+code+is+available用于这样的目的，事情就会变得更容易分析。|2717075|如果这是你想自己追求的东西，我推荐两本书，分别是Chris+Eagle的和Chris+Anley，John+Heasman，Felix+Linder和Gerardo+Richarte的。|2717076|最后，为帮助您进行分析而开发的技术和工具仍然是非常活跃的研究领域。你的问题要么比你意识到的更深，要么可能被我误解了。彻底处理你的问题，即使只是从实际的角度出发，忽略随之而来的理论，可以，而且确实，填满了很多书。|2717077|我希望你至少能从中找到一些有用的东西。祝好运!|2717078|entityMap^0|8|5Q|0|0|2A|0|0|8|0|0|A|0|0|D|0|0|24|0|0|1J|0|0|0|0|E|0|0|2B|0|0|2P|0|0|4W|4X|2|50|T|0|0|2L|0|0|2X|0|0|N|0^^$0|@$1|2|3|4|5|6|7|1A|8|@$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1D|8|@$9|1E|A|1F|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1G|8|@$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|J|3|K|5|L|7|1J|8|@$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|M|3|N|5|L|7|1M|8|@$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|O|3|P|5|L|7|1P|8|@$9|1Q|A|1R|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|L|7|1S|8|@$9|1T|A|1U|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1V|8|@]|D|@]|E|$]]|$1|T|3|-4|5|6|7|1W|8|@]|D|@]|E|$]]|$1|U|3|V|5|6|7|1X|8|@$9|1Y|A|1Z|B|C]]|D|@]|E|$]]|$1|W|3|X|5|6|7|20|8|@$9|21|A|22|B|C]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|23|8|@$9|24|A|25|B|C]]|D|@]|E|$]]|$1|10|3|11|5|6|7|26|8|@$9|27|A|28|B|C]|$9|29|A|2A|B|C]|$9|2B|A|2C|B|C]]|D|@]|E|$]]|$1|12|3|13|5|6|7|2D|8|@$9|2E|A|2F|B|C]]|D|@]|E|$]]|$1|14|3|15|5|6|7|2G|8|@$9|2H|A|2I|B|C]]|D|@]|E|$]]|$1|16|3|17|5|6|7|2J|8|@$9|2K|A|2L|B|C]]|D|@]|E|$]]|$1|18|3|-4|5|6|7|2M|8|@]|D|@]|E|$]]]|19|$]]

For binary auditing, one of the hands-down best tools that you must have is the Interactive Disassembler, also better known as <a href="http://www.hex-rays.com/idapro/" rel="nofollow noreferrer">IDA Pro</a>. It is a must have when you need to audit without access to the source code. Someone proficient in using IDA Pro will be able to tell you, with a reasonable amount of confidence, if there have been anything more than superficial changes to the source code. In this context, superficial changes would encompass things like variable renaming within the source files or changing the order of variable, function or class declarations and definitions. They will be able to tell you if the basic code blocks making up the executables have differences between them substantial enough to be flagged as suspicious, in the sense that there is a high probability that the differences are indicative of a source-level difference.

I say more or less, because there are several ways in which two executables generated from the exact same source tree could still have subtle, and on occasion not so subtle, differences between each other. Factors that can influence the generation of the executables include:

<ul>
<li>compiler optimization settings</li>
<li>differing versions of libraries the executables are linked with</li>
<li>changes to header files, external to the source tree used to build the executables, which were included by the C++ preprocessor before the compilation step</li>
<li>an executable that manipulates its own code at runtime, which may include decompressing or decrypting on the fly some part of itself into some area of memory it can jump to</li>
</ul>

And this list could go on for a while.

Is the sort of binary audit you are suggesting possible? Yes, a person with enough knowledge and skill could do this. Hackers do this all the time. And if the person doing the analysis is good enough, they will be able to tell you exactly how confident they are in their assessment as well.

Ultimately it becomes a question of feasibility. How much are you willing to spend on this audit? Hiring or contracting someone who can do this may push beyond what is budgeted for such auditing, is there enough money to do this? How complex is the software you are testing? What is the nature of your relationship with your vendor? 

That last question is important because if it is in their best interest to pass this audit, and they realize this, they may be willing to assist you up to a certain degree. This could come in the form of debugging symbols, a list of compiler options which were used or some other artifacts of the build process they are willing to disclose. The preceding can all be very helpful in any analysis where source code is not being made available for the purposes of analysis due to whatever reason. And if access to the source code is available for such a purpose, things become an order of magnitude easier to analyze.

If this is something you would like to pursue on your own, two books I would recommend are <a href="https://rads.stackoverflow.com/amzn/click/com/1593271786" rel="nofollow noreferrer" rel="nofollow noreferrer">The IDA Pro Book: The Unofficial Guide to the World's Most Popular Disassembler</a> by Chris Eagle and <a href="https://rads.stackoverflow.com/amzn/click/com/047008023X" rel="nofollow noreferrer" rel="nofollow noreferrer">The Shellcoder's Handbook: Discovering and Exploiting Security Holes</a> by Chris Anley, John Heasman, Felix Linder and Gerardo Richarte.

Lastly, the techniques and tools developed for analysis of the kind that would help you are still very much active areas of research. Your question either runs deeper than you may realize, or it may have been misunderstood by me. A thorough treatment of your question, even from just a practical standpoint and ignoring the theory that goes along with it, could, and does, fill many books.

I hope you find at least some part of this helpful. Good luck!

blocks|key|401683|text|如果你能控制源代码，那么就不要发布没有适当版本控制信息的exe。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|401684|如果出于某种原因，他们构建了自己的exe，我建议他们使用一个构建步骤，将版本控制修订号嵌入到版本控制信息中。|401685|如果它们不使用您的构建步骤(您可以检测到)，那么您就认为它们是不同的。|401686|大多数修订控制系统(例如SVN+)都允许您有一个构建步骤，该步骤将说明代码是否处于修改状态。您可以将此信息嵌入到exe的嵌入式资源中的字符串中。然后，您只需提取该资源。|401687|因此，它最终是为了确保所有的构建都是从您的自定义构建脚本进行的。|401688|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

If you are in control of the source simply don't ship out exes that don't have proper versioning info associated with them.

If for some reason they build their own exes, I would suggest having a build step that they have to use that will embed the version control revision number into the versioning info.

If they don't use your build step (which you can detect) then you assume they are different.

Most revision control systems (such as SVN for example) will allow you to have a build step that will say whether the code is in a modified state or not. You could have this info embedded into a string in an embedded resource for the exe. You would then just extract that resource.

So it comes down to make sure all builds happen from your custom build script.

blocks|key|401798|text|从现在开始，添加一个构建后步骤，该步骤将生成源文件的MD5，并将其添加到版本资源(以便您可以在exe属性中看到它)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|401799|这将花费你2到3个工日。|401800|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

From now on, add a post build step that will generate a MD5 of the sources files and add it to the VERSION resource (so that you can see it in the exe properties). 
It will cost you 2 or 3 man days.

blocks|key|2717125|text|在十六进制比较程序中加载可执行文件(BeyondCompare！)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2717126|如果有任何重要的更改(假设编译器设置没有更改)，它们应该很容易发现。如果这只是一个时间戳等问题，这可能是相当明显的。|2717127|这肯定不是万无一失的，但这将是我的第一步。|2717128|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Load up the exes in a hex compare program (BeyondCompare rocks!).

If there are any non-trivial changes (assuming compiler settings have not changed), they should be pretty easy to pick up. If it's just a matter of timestamps, etc. it may be pretty obvious.

This definitely isn't foolproof, but it would be my first step.

Is there a way to detect whether two EXE's (compiled from VS.Net 2008 for C++/MFC) do not have any code-level changes between them i.e. for purposes of knowing that there have been no statement changes. 

This is for compliance purposes when my vendor ships me an exe, ostensibly with no changes made to the code since the last time we tested it.

Is there a tool to check that this is so?

Cheers

How to tell if two exe's are the same code-wise?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

是否有一种方法可以检测两个EXE(从C++/MFC的VS.Net 2008编译而来)之间是否没有任何代码级的更改，即为了知道没有任何语句更改。这是为了合规的目的，当我的供应商给我一个exe时，表面上没有自我们上次测试以来对代码进行任何更改。有没有工具可以确认这一点？干杯

问如何判断两个exe代码是否相同？
EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何判断两个exe代码是否相同？EN

回答 7

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何判断两个exe代码是否相同？
EN