网站投放,网站优化报告,梅州网站建设求职简历,无锡网站建设哪家公司比较好对所有编译的软件语言来说#xff0c;将人类可读代码转换成计算机可读代码都是一项软件保障挑战#xff1a; 用户如何有信心相信在其计算机上运行的软件程序是根据开发者创建的同一源代码文件生成的呢#xff1f; 这不一定#xff0c;即使源代码文件经过行业专家评审#… 对所有编译的软件语言来说将人类可读代码转换成计算机可读代码都是一项软件保障挑战 用户如何有信心相信在其计算机上运行的软件程序是根据开发者创建的同一源代码文件生成的呢 这不一定即使源代码文件经过行业专家评审也不例外因为可能出现开放源代码软件的情况。软件保障的核心是信任经过评审的源代码文件是生成可执行文件的相同源代码文件。 在编译和链接过程中使用特定编程语言C#、C、Objective C、Java 等编写的一组源代码文件被转换成二进制可执行文件以供在特定体系结构如 x86、x64、ARM的计算机上运行。但这种转换可能不具有决定性作用。两组不同的源代码文件可能被转换成两组位完全相同的可执行文件。有时这是有意而为之。源代码文件内空格或文本注释不一致不得影响编译器生成的二进制代码。另一方面同一组源代码文件也可能会因不同的编译过程而被转换成不同的可执行文件。无论属于上述哪种情况问题都在于确定性即无法确定拥有的文件是否就是所需的文件。 为了解决这个问题不妨在编译过程中使用 Visual Studio 编译器对源代码文件进行哈希处理。将编译器生成的哈希值与经过检查的源代码文件生成的哈希值进行匹配可以验证可执行代码是否的确是由特定的源代码文件生成而来。这显然会让用户很受益实际上如果其他编译器的供应商也采用了类似方法那么用户会进一步受益。本文介绍了用于选择哈希算法的新 Visual Studio 开关、此类哈希可能适用的应用场景以及如何使用 Visual Studio 生成源代码哈希值。 在编译过程中生成强哈希值 程序数据库 (PDB) 文件是一个单独数据文件存储用于调试二进制可执行文件的信息。Microsoft 最近将其各种编译器文件哈希运算如 PDB 文件中嵌入的源哈希值更新为使用强加密算法。 本机代码编译器Visual Studio 2015 本机 C/C 编译器 cl.exe 随附一个新开关 /ZH:{MD5|SHA_256}用于为编译器选择其他哈希算法从而对源代码文件进行哈希处理。默认开关为 MD5虽然已知其更容易导致冲突但仍采用默认开关因为从计算层面来讲它的哈希值生成成本更低。使用新的开关编译器可以实现密码强度高于 MD5 的 SHA-256 选项。 如果源代码文件的 SHA-256 哈希值与二进制可执行文件的 PDB 文件中存储的 SHA-256 哈希值一致就可以确定可执行文件是由相同的源代码文件编译而成这样所有利益干系人便可以对二进制可执行文件有信心。实际上二进制可执行文件的 PDB 文件中存储的一组 SHA-256 哈希值全都成为二进制可执行文件的“生成证明”中的标识符因为这些标识符由“生成”二进制可执行文件的编译器进行注册。 使用调试接口访问 SDK (bit.ly/2gBqKDo)可以轻松创建简单的工具如调试信息转储程序 cvdump.exe可从 bit.ly/2hAUhyy 中获取此程序及其源代码。可以使用 cvdump.exe 的 -sf 开关查看模块使用本地生成计算机中的完整路径名称及其 MD5 或 SHA-256 哈希值的列表如图 1 中的命令窗口所示。 图 1使用 cvdump.exe 查看模块及其哈希值 使用旧版 cvdump.exe 查看同一 PDB 文件时我看到的文字是“0x3”而不是“SHA_256”。“0x3”值是“SHA_256”的枚举值更新后的 cvdump.exe 知道如何进行解析。它也是调试接口访问 SDK 的 IDiaSourceFile::get_checksumType 方法返回的同一枚举值。 托管代码编译器默认情况下Visual Studio 2015 托管代码 C# 编译器 csc.exe 使用 SHA-1 加密算法计算源文件校验和哈希值以存储在 PDB 文件中。然而csc.exe 现在支持使用新的可选“/checksumalgorithm”开关来指定 SHA-256 算法。若要切换到 SHA-256 算法请使用此选项编译当前目录中的所有 C# 文件然后将调试信息包括源文件列表和 SHA-256 哈希值放入 PDB文件中 csc /checksumalgorithm:SHA256 /debug *.cs 可从 github.com/dotnet/roslyn 中获取属于 .NET 编译器平台 (Roslyn) 开放源代码项目的 csc.exe。有关对文件中 SHA-256 源文件调试校验和算法命令行选择器的支持请访问 bit.ly/2hd3rF3。 Visual Studio 2015 csc.exe 只与 Microsoft .NET Framework 4 或更高版本的可执行文件兼容。另一个用于生成低于版本 4 的可执行文件的 Visual Studio 2015 .NET Framework 编译器不支持 /checksumalgorithm 开关。 托管代码 PDB 文件存储数据的方式不同于本机代码 PDB 文件。可使用 Microsoft DiaSymReader 互操作接口和实用工具来读取托管代码 PDB 文件而不是使用调试接口访问 SDK。可从 bit.ly/2hrLZJb 中以 NuGet 包的形式获取 Microsoft DiaSymReader。 Roslyn 项目包括 pdb2xml.exe 实用工具可从 bit.ly/2h2h596 中获取此工具及其源。此实用工具以 XML格式显示 PDB 的内容。例如图 2 中的各段列出了用于编译托管代码可执行文件的 C# 源代码文件。 图 2以 XML 格式显示托管代码 PDB checkSumAlgorithmId 字段中的“8829d00f-11b8-4213-878b-770e8597ac16”GUID 表明校验和字段中的值是名称字段中引用的文件的 SHA-256 哈希值。可移植 PDB 格式规范 v0.1 (bit.ly/2hVYfEX) 中定义了此 GUID。 编译器对 SHA-256 的支持 以下 Visual Studio 2015 编译器支持对源代码文件进行 SHA-256 哈希处理 cl.exe /ZH:SHA_256 ml.exe /ZH:SHA_256 ml64.exe /ZH:SHA_256 armasm.exe -gh:SHA_256 armasm64.exe -gh:SHA_256 csc.exe /checksumalgorithm:SHA256 可在 Visual Studio 2015 的“VS2015 开发者命令提示符”命令窗口中创建这些编译器。 不面向 Windows 平台的编译器通常不使用 PDB 文件存储其调试信息。这些编译器通常在编译期间同时生成两个可执行文件一个是未删除源信息的可执行文件另一个是已删除源信息的可执行文件 (bit.ly/2hIfvx6)。所有调试信息都存储在未删除源信息的可执行文件中而已删除源信息的可执行文件则不包含任何详细的调试信息。未删除源信息的可执行文件可能适合存储可执行文件的已处理源代码文件的 SHA-256 哈希值。我们正打算联系其他这些编译器的创建者确定最适合其编译器的方法以便使用这些编译器的非 Windows 软件如 Office for Android、Office for iOS 或 Office for Mac可以和 Windows 软件一样受益。 用例应用场景 现在我们来看一下源文件哈希值可能适用的一些应用场景。 检索可移植可执行 (PE) 二进制文件的已编入索引源文件Ssindex.cmd 脚本 (bit.ly/2haI0D6) 是一种实用工具可用于生成签入源控件的已编入索引源文件列表以及每个文件的版本信息以供存储在 PDB 文件中。如果 PDB 文件包含此版本控制信息可以结合使用 srctool 实用工具 (bit.ly/2hs3WXY) 及其 -h 选项来显示信息。由于已编入索引的源文件也将其哈希值嵌入 PDB 文件因此这些哈希值可用于在检索期间验证源文件如知识库文章 3195907 (bit.ly/2hs8q0u)“How To Retrieve Indexed Source Files of a Portable Executable Binary File”如何检索可移植可执行二进制文件的已编入索引源文件中所述。 具体来说如果哈希值不一致则表明 PE/PDB 对生成期间或源控件系统中的某个环节可能出现了问题。这可能有必要执行进一步调查。相比之下如果哈希值一致则充分表明检索到的已编入索引源文件是用于编译 PE/PDB 对。 匹配源文件静态分析器生成的哈希值现在使用自动工具来评估软件质量是常事就像 Microsoft 安全开发生命周期 (SDL) 针对实现阶段建议的一样 (bit.ly/29qEfVd)。具体来说源文件静态分析器用于扫描目标源代码文件以评估软件质量的许多不同方面。这些静态分析器通常在扫描目标源代码文件后立即生成相应的实时结果。在静态分析器扫描各个源代码文件时也是生成每个在扫描源代码文件的强哈希值 (SHA-256) 的绝佳机会。实际上bit.ly/2ibkbwz 中开放源代码项目提出了静态分析结果交换格式 (SARIF)这种格式提供了静态分析结果中的特定位置以供静态分析器生成扫描的目标源代码文件及其 SHA-256 哈希值。 以 PE 文件为例假设可获得以下内容 1. 由编译器生成的相应 PDB 文件中的编译源文件哈希列表。 2. 由静态分析器生成的相应静态分析结果中的扫描源文件哈希列表。 在此应用场景中可以评审并验证这两个文件哈希列表是否匹配。如果匹配表明静态分析器已扫描源文件来评估某方面的质量无需重新扫描源文件。以前没有文件哈希列表可能就需要重新扫描以确保静态分析器进行了正确的评估。 在软件更新或修补程序开发过程中更快速地执行健全性检查如果需要发布软件更新来修复源文件静态分析器在已发布产品中发现的质量问题静态分析器应报告待定更新程序的源代码文件中不存在发现的质量问题。这个报告至少将确认更新程序能否有效解决原始质量问题。也就是说它将验证软件更新的预期用途。如果需要你或安全评审员可以执行下列步骤来实施快速验证 1. 确认原始静态分析器报告是否发现相关质量问题。 2. 确认原始静态分析器报告是否包括存在质量问题的源文件的哈希值。 3. 将原始静态分析器报告中发现的文件哈希值与已发布产品版本的源文件的哈希值进行匹配。 4. 使用同一静态分析器扫描更新程序的源代码文件生成更新后的静态分析器报告。 5. 确认更新程序的静态分析器报告中是否不存在之前发现的质量问题。 6. 将更新后的静态分析器报告中的文件哈希值与更新程序的源文件的哈希值进行匹配。 在执行这些验证步骤期间无需访问原始发布产品或更新程序的实际源代码文件。 构造两个软件版本之间的源代码增量评审一组完整的源代码可能需要一些时间。然而在某些情况下不一定非要在更改源代码后评审全部源代码。因此可能要求只评审源代码增量。这样的要求当然合理因为重复分析上次评审后没有变化的所有部分并不合理。 以前没有源代码文件的密码强度高的哈希值很难精确构造增量子集。即使你有增量子集可以提供行业专家也可能对你能否准确创建增量子集没有什么信心。但现在情况已不再如此。借助源代码文件的密码强度高的哈希值可以执行下列步骤来创建增量子集 1. 获取原始产品版本的所有源代码文件的哈希值池例如池 X。 2. 精确复制文件目录例如目录 A其中包含后续产品版本的源代码登记将根据其构造增量子集。 3. 准备用于仅保留增量文件子集的最终文件目标文件夹例如目录 B。 4. 整理目录 A 中的所有文件 5. a.如果文件的哈希值与池 X 中的哈希值一致什么也不做匹配下一个文件。 6. b.如果文件的哈希值与池 X 中的哈希值不一致将文件复制到目录 B 中然后匹配下一个文件。 7. 确认目录 B 中所有文件的哈希值与后续产品版本的源文件的相应哈希值一致。 8. 让目录 B 的内容成为后续产品版本的增量源文件子集。 生成哈希值 现在我们来了解一下如何使用 Visual Studio 编译器对文件进行哈希处理。为此我将以联机 Visual Studio 文档 (bit.ly/2haPupF) 中的“Hello, World”应用程序创建应用场景为例 1. 介绍在输出 PDB 文件中在何处可以找到编译的源文件的哈希值。 2. 使用 certutil 工具 (bit.ly/2hIrnPR) 计算源文件哈希值与 PDB 文件中的哈希值进行匹配。 首先我在 Visual Studio 2015\Projects 文件夹中新建了一个 Win32HelloWorld 应用程序项目。在这个 Win32HelloWorld 项目中只有一个 C 源文件 Win32HelloWorld.cpp如图 3 所示。 图 3Win32HelloWorld.cpp 如你所见Win32HelloWorld.cpp 包含用于显示“Hello”文字的主函数。 生成 Win32HelloWorld 项目后我在 Visual Studio 2015\Projects\W32HelloWorld\x64\Debug 文件夹中生成了 W32HelloWorld.exe 和 W32HelloWorld.pdb 文件。 对 W32HelloWorld.pdb 文件结合使用 cvdump 工具和 -sf 选项在输出中显示 Win32HelloWorld.cpp 文件及其 MD5 哈希值如图 4 所示。 图 4显示 Win32HelloWorld.cpp 及其 MD5 哈希值的 cvdump 输出 此哈希值是 MD5因为 MD5 是 Visual Studio 2015 编译器 cl.exe 的默认算法。若要将源文件哈希算法切换成 SHA-256我需要向 cl.exe 提供 /ZH:SHA_256 选项。为此我可以在 Win32HelloWorld 项目“属性”页上的“其他选项”框中添加“/ZH:SHA_256”如图 5 所示。 图 5将源文件哈希算法切换成 SHA-256 在 Visual Studio 中重建后我在 Visual Studio 2015\Projects\W32HelloWorld\x64\Debug 文件夹中生成了 W32HelloWorld.exe 和 W32HelloWorld.pdb 的新 PE/PDB 对。现在对新的 W32HelloWorld.pdb 文件结合使用 cvdump 工具和 -sf 选项在输出中显示 Win32HelloWorld.cpp 文件及其 SHA-256 哈希值如图 6 所示。 图 6显示 Win32HelloWorld.cpp 及其 SHA-256 哈希值的 cvdump 输出 现在我可以返回到 Visual Studio 2015\Projects\W32HelloWorld\W32HelloWorld 文件夹中的 W32HelloWorld.cpp 文件查看它的 SHA-256 哈希值。对于 SHA-256对 Win32HelloWorld.cpp 文件结合使用 certutil 工具和 -hashfile 谓词生成 SHA-256 哈希值如图 7 所示。 图 7使用 Certutil 生成 SHA-256 哈希值 很显然此哈希值与 W32HelloWorld.pdb 文件中记录的 SHA-256 值一致。这充分表明 W32HelloWorld.exe 应用程序确实是按预期由 Win32HelloWorld.cpp 文件编译而成。 若要详细了解适用于本机代码和托管代码 PE/PDB 文件对的相关公共工具请参阅知识库文章 3195907 (bit.ly/2hs8q0u)“How To Retrieve Indexed Source Files of a Portable Executable Binary File”如何检索可移植可执行二进制文件的已编入索引源文件。 总结 我希望通过本文你可以了解到更紧密地关联源代码文件和用其编译的 PE 文件可能会带来的一些好处。可以在编译过程中使用最强的可用哈希算法 SHA-256 让编译器对源代码文件进行哈希处理从而更紧密地关联两者。实际上编译器生成的源代码文件的实际哈希值成为了用于编译可执行文件的源代码文件的唯一标识符。 了解这些唯一标识符的值后就可以在不同软件开发生命周期计划中使用它们跟踪、处理和控制与特定可执行文件有着紧密联系的源代码文件从而让最终用户对可执行文件更有信心。 Mike Lai 刚刚迎来他在 Microsoft 工作的第 20 个年头。他很感谢 Microsoft 能够提供各种机会来推动许多产品在功能及工程方面取得进步。他想要感谢可信任计算部门现任管理层能够耐心等待他的思想变成熟并逐步融入已发布的产品另外还要感谢他们支持加入信息和通信技术安全标准组织。 衷心感谢以下 Microsoft 技术专家对本文的审阅 Scott Field、Mike Grimm、Sue Hotelling、Ariel Netz、Richard Ward 和 Roy Williams 原文地址https://msdn.microsoft.com/en-us/magazine/mt795185 .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
