经过进一步的深入研究后，Palo Alto 发现该恶意文件已经被重新打包并植入到一些 IOS 应用中，而这些 IOS 应用往往可以通过多个渠道进行下载（非 App Store 渠道）。在接下来的篇幅里，我们将会讨论“TinyV”是如何工作以及如何传播的。

 

重新打包和传播

 

“TinyV”被重新打包进一些为越狱设备而“准备”的应用中，受影响的 IOS 应用不少。经过重新打包后，这些应用被上传到网络并提供用户下载。

 

用户有可能通过 xx 助手下载到这些受感染的应用，在一些应用的官网上供下载的应用，也不见得是十分安全。我们往往在 IOS 设备上访问这些网站的下载链接的时候会被跳转到描述文件页面并让用户安装，这些被标榜为企业级应用的应用往往需要用户手动开启验证，才可以在设备上使用该应用。

需要指出的是，“TinyV”重新打包的方式和之前的 IOS 或者 OSX 恶意应用不太一样（和之前著名的 WireLurker 也不一样）。例如在某个受感染的播放器应用的 IOS 安装文件“com.某某.ipa”中，往往存在着两个执行文件。一个是主要的执行文件 Mach-O ，而另一个则是名为“xg.png”的 Mach-O 动态库文件。在主要执行文件的导入表中，最后的导入入口是“@executable_path/xg.png”。这意味着在应用被执行后，“xg.png”的文件将会被加载。

 

而在其它受感染的应用中，除了主要的 Mach-O 执行文件外，也会出现一些额外的 Mach-O 动态库文件：“dj.png”， “macro_off@2x.png和zippo_on@2x.png” 。“TinyV”的作者修改了原来的应用文件，并增加这些动态库文件到导入表中。

 

 

被加载的“xg.png”文件将会通过调用方法来连接到 C2 服务器并取得配置信息。被 C2 提供的配置将会指向一个 ZIP 文件的 URL，并被指定为一个带有“zipinstall”值的 “shName”。

 

在这个被感染的应用中， “macro_off@2x.png” 将会访问同一个 C2 服务器的另一个页面来获取其配置。这次“debUrl”值使用 XOR 算法加密。尽管代码混淆，但使用关键的 “0xaf”加密，却依然可以显示相同的 URL。

 

恶意行为

 

从 C2 服务器获得配置后，“TinyV”将会从授予的“debUrl” 值中下载 ZIP 文件。这里调查的 ZI P文件被托管在另一个 C2 服务器apt[.]appstt.com 上，目前该 URL 地址出现 404 错误。不过据说在 10 月底开始调查的时候，这个 URL 是可以访问的，并且“deb.zip”文件也可以下载。

需要指出的是，“TinyV”重新打包的方式和之前的 IOS 或者 OSX 恶意应用不太一样（和之前著名的 WireLurker 也不一样）。例如在某个受感染的播放器应用的 IOS 安装文件“com.某某.ipa”中，往往存在着两个执行文件。一个是主要的执行文件 Mach-O ，而另一个则是名为“xg.png”的 Mach-O 动态库文件。在主要执行文件的导入表中，最后的导入入口是“@executable_path/xg.png”。这意味着在应用被执行后，“xg.png”的文件将会被加载。

 

而在其它受感染的应用中，除了主要的 Mach-O 执行文件外，也会出现一些额外的 Mach-O 动态库文件：“dj.png”， “macro_off@2x.png和zippo_on@2x.png” 。“TinyV”的作者修改了原来的应用文件，并增加这些动态库文件到导入表中。

 

 

被加载的“xg.png”文件将会通过调用方法来连接到 C2 服务器并取得配置信息。被 C2 提供的配置将会指向一个 ZIP 文件的 URL，并被指定为一个带有“zipinstall”值的 “shName”。

 

在这个被感染的应用中， “macro_off@2x.png” 将会访问同一个 C2 服务器的另一个页面来获取其配置。这次“debUrl”值使用 XOR 算法加密。尽管代码混淆，但使用关键的 “0xaf”加密，却依然可以显示相同的 URL。

 

恶意行为

 

从 C2 服务器获得配置后，“TinyV”将会从授予的“debUrl” 值中下载 ZIP 文件。这里调查的 ZI P文件被托管在另一个 C2 服务器apt[.]appstt.com 上，目前该 URL 地址出现 404 错误。不过据说在 10 月底开始调查的时候，这个 URL 是可以访问的，并且“deb.zip”文件也可以下载。