正如楼上老哥所说，感觉你问错地方了。

像这种面板，主力用户基本都是小白。

你来 v2 问。。没啥意义啊，还不如去宝塔什么的论坛蹲点收集。

是的，目前见到的多数模拟器都是直接用的 libhoudini 这种成熟的方案。

没记错的话类似方案 google 好像也搞了一套扔在开发者工具，不过没有多少人会拿来用在正式产品上。

#3 说的 x86 跑 arm 镜像，基本不可能。首先性能堪忧，其次目前大部分模拟器都是用的 virtualbox(virtualbox 貌似不支持 x86 模拟 arm)。

#6 说的 android11 模拟器镜像感觉很可能就是加了上文说的方案(时间线搞不太清，不是专职 android)

#9 说的 unicorn ，这个太底层了，通过它来直接开发，成本较高(有些 lib 还是得调 x86 的，全 qemu 模拟那性能没法看了)。

@catalysia

1995 年。。

甚至作者是否还健在都是个未知数。

@paradoxs

仔细看了下，虽然像公网，但实际并不是。

这个域名在公网疑似是泛解析到一个美国的 aws ip 。

完全不可能出现在这种场合。

敢偷数据真的胆子太大了。

@lrhtony

kizuna ai ？

jp 暂停了吧，cn 还在好像。

jp 早安，cn 晚安。

@WenJimmy

知乎之前不也爆过嘛。

这种事，可大可小。

毕竟哪怕有 sourcemap 也大概率没办法轻易还原整体项目。

@FrankHB

估计是业务不考虑其他国家？

不然绝对要命，这个逻辑太鬼才了。

@OkabeRintaro

算不上大佬，不过确实踩了不少坑。

有 sourcemap 你要知足，没 sourcemap 我都搞过。

之前闲的没事接了个小的外包单子。

vue + php ，前任跑路了要加功能，连个 sourcemap 也没留下。幸好功能不算复杂(前端没多少代码，主要在后端)，照着打包后的 js 文件重写了一遍。

那感觉，生不如死，不过倒也接触到了不少新知识。

发了上面这些，就想告诉你一件事。

这玩意，如果你 souercemap 和打包后项目文件完整，是可以跑起来的。

但是你要做的事情非常多，时间精力消耗很大。

不是有 sourcemap 就能万事大吉，完整 sourcemap 只是给你个可能性。

对了，还有个问题。

你在 sourcemap 找到的 image 等文件，大概率不是直接可用的。

webpack 什么的会搞个花活，那里面并不直接是文件内容，而是一段 js ，js 里面才会写真实路径。

大文件会指向打包后项目代码的 url(如 images/some_source_name.random_id.ext_name)，你得手动下载下来替换。

小文件会直接 base64 编码成 data url ，提取出来替换就可以了。

以前测试过用 sourcemap 逆向 vue 项目。

得出的结论是，这玩意要能跑起来可完全不容易。

假设你拿到的 sourcemap 是完整可用的，那么你会遇到如下问题:

1. 独立的 css/less/sass/scss 文件大概率是不存在的，如果很不幸你遇到了 import 这些文件而不是直接写在 vue 的话，你需要去打包后的 css 里手动提取出来。稍微庆幸的是，除非全局引入，不然每个页面的样式基本都会是同一个 data-v-id 。

2. sourcemap 解包后可能会出现带后缀以及不带后缀的文件，你需要自行挑选出来原始文件，但在我个人经验上，基本都是无后缀的是原始文件。

3. vue.config.js ，起码我没见到过有的，大概率得手动写一下。

4. package.json 是不可能有的，这个你纯粹想多了，真正的难点也在这里，你需要去可能非常不全的 node_modules 目录里手动逐个查依赖，这个过程很费劲，因为有些时候你可能找的一头雾水，这个时候就得试着把项目跑起来按照报错找依赖。

各大打包工具对 sourcemap 都是抱着调试的用途去生成的，根本不可能把开箱即用的项目代码扔进去，找思路可以，原样跑起来非常费劲。

@sadfQED2 老哥啥时候离职的？现在也是这样吗？震惊。

这技术架构也忒老了，用的自研的 php 框架吗？

@minilei 你重装系统没备份 /etc/pve 目录吗？

没记错的话那里面好像也存放了虚拟机配置文件。。

那么问题来了，程序的调度方案是怎样的？

程序该怎么去选择存储地点以及该怎么去下载你的文件？

这个程序很难写，很多厂商都不给普通用户提供接口，全得自己抓包，但抓包出来的接口可用性以及稳定性又十分堪忧。

各大厂商功能实现的也不同，而且还要考虑到可能的限速 /限流问题。

如果你有临时修补方案，请谨慎公开漏洞细节和 POC ，因为某些用户可能无法及时了解到该信息并予以修补。

如果你没有临时修补方案，请永远不要公开漏洞细节和 POC ，厂商不负责任不代表用户需要承担因你而造成的风险。

一旦公开漏洞细节和 POC ，该漏洞的利用门槛将显著降低。

前几楼老哥已经发了相关地址了，建议向上级反馈推动厂商积极性。

感谢你做出的努力。

说真的，个人对 OP 有点疑惑。。

刚注册的新号。

第一贴和第一个回复都是在这个帖子。

帖子内容还是自媒体这种鱼龙混杂的行业。