1

一般来说，微软声称appx 包应该基本上是带有特殊内容的 zip，但实际上它们略有不同。如果我拿一个 appx 包并用 7-Zip 解压，我在解压时已经收到“Headers-Error”。如果我再次将文件打包成 Zip 并更改扩展名，则该包无效。

我已经在搜索有关格式的更多详细信息，但找不到任何东西。appx 打包相关问题的大多数答案都以与 MakeAppx.exe 交互的命令结尾。有谁知道是什么使 appx 与经典的 zip 文件不同，并且由此可以描述如何在不使用 MakeAppx.exe 的情况下创建这样的包？

目标是能够以我自己的方式以编程方式创建 appx 包，而不依赖于 MakeAppx。考虑到他们如此提倡“建立在标准之上”和“开放式包装公约”，我猜它们的区别是微妙的。大多数其他 OPC 文件格式似乎是 100% 的经典 zip。Office 文档、NuGet 包、Visual Studio 扩展等可以轻松解压缩和重新打包，无需额外的逻辑。只有 appx 容器似乎包含一些特殊的标头信息。

我的问题的背景是我是我们公司使用的签名服务器的作者。它接受某些数据格式并创建它们的签名版本（如“SignTool”服务）。一项功能是用我们公司的签名覆盖现有的签名（例如，用生产证书替换内部测试证书）。Appx 在签名方面有相当多的限制，清单必须正确，必须使用正确的哈希算法等。微软提供了如何以编程方式进行签名的源代码，很好。但是当涉及到可能的重新打包时，没有可用的 API。我可以尝试简单地与 exe 交互，调用它，但这会带来很多我想要防止的缺点（错误处理、临时文件创建等）

4

1 回答 1

2

根据您提供的链接（设计一个简单而安全的应用程序包 – APPX），似乎 appx 文件实际上只是一个包含一组明确定义的文档的 zip 文件。

检查我是否下载了几个示例 appx 文件。当我在 Linux 机器上运行解压缩测试时，它们通过了。我没有 7-Zip。

深入挖掘 appx 文件，我发现它们在文件中的每个数据描述符部分之后都包含 8 个额外的非标准填充字节。这些字节似乎没有包含在 zip 文件规范 ( APPNOTE.TXT ) 或Open Office 规范中。这可能解释了您在 7-zip 中看到的行为。

那么，您的关键问题是填充字节是否是您无法使用 7-Zip 创建有效 appx 文件的根本原因。

更新

更详细地查看了 appx 文件中使用的数据描述符的构成。

以下是基于我在Package.appx容器中看到的第一个成员的一些观察结果，如下所示

$ unzip -lv Package.appx 
Archive:  Package.appx
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
  444578  Defl:N   104066  77% 2019-06-17 11:01 4d706e98  OfflineFiles/Microsoft.Office.Smartlookup.Vendor_cfe9ce8c6334a9b3191bbc9bfc72ad56.js

下面是第一个成员的数据描述符的十六进制转储（假设是标准的 32 位描述符）。

OFFSET BYTES       DESCRIPTION           VALUE
0196F4 50 4B 07 08 STREAMING DATA HEADER 08074B50
0196F8 98 6E 70 4D CRC                   4D706E98
0196FC 82 96 01 00 Compressed Length     00019682
019700 00 00 00 00 Uncompressed Length   00000000
019704 00 06 C8 A2 UNEXPECTED PADDING    ........
       00 00 00 00

  1. 使用的数据描述符的总大小对于 64 位数据描述符是正确的。（4 字节头 + 4 字节 CRC32 + 8 字节压缩长度 + 8 字节未压缩长度 = 24 字节）。问题是，这不是一个格式良好的 64 位 zip 文件。

  2. CRC 值正确。

  3. 数据描述符中的Compressed Length字段包含正确的 64 位 little-endian 值——444578 (0x19682)。

  4. 该字段的前 32 位Uncompressed Length包含 19682 的大端编码。后 32 位为零。整个事情应该是小端的。

所以两个问题

  1. 如果打算使用 64 位数据描述符，则 zip 文件应符合Zip64扩展名。本地标头中至少应该有一个Zip64 扩展信息额外字段(0x0001)（请参阅Zip64中的第 4.5.3 节）。Zip64 中央目录标题也应该存在。
  2. 该Uncompressed Length字段部分以大端而不是小端编码。
于 2018-01-25T16:42:36.237 回答