本文非技术文章，而是回复一些问题。

如果你有任何问题（包括技术，观点等方面的疑问），欢迎留言到我们的邮箱：nostevemodel@proton.me

请注意：如果你在邮箱以外的地方投稿我们可能会忘记，所以所有问题请投稿到邮箱中，如果你的问题比较多可以一封邮件包含所有问题，我们一般不会回复邮件，只要你的邮件发出了，就视为收录，在文章中肯定会回复，如果你没看见你的问题，是因为和某个问题很相似，合并了。

留言里的问题

此列表为回复邮箱中留言的问题

能不能分享一下自己的经历

我们希望保持匿名。

能不能讲讲自己怎么接触的YSM以及为什么想弄一个YSM解密

很显然，我们其实并没有玩过YSM，虽然在很久以前就听说过这个模组，但是对其并不感兴趣，想要解密它的加密算法并且进一步逆向工程也完全是兴趣使然。 在发起这个项目之后。经过调查我们才了解到

• TartaricAcid/YSM被社区过度吹捧
• YSM中使用了很多对于Minecraft模组来说非常规的保护手段，例如使用VMProtect和ollvm混淆Native层代码、对网络通讯进行加密等
• TartaricAcid为了保护模型不被解密已经到了极度偏执的程度

至于想要以此盈利/看不惯模型贩卖/举EULA大旗/反对R18等都不是我们逆向YSM的原因，只是别人臆测出来用来诋毁我们的。 我们在公告群聊中转发的大多数内容也只是出于"这个东西很搞笑/很荒诞，转发一下"的心理。

是否会更新更多版本支持

是的，也是必然的，我们会更新更多版本支持，除了1.20.1以外，我们正在计划更新对于1.21的某些子版本的支持。

OpenYSM作为一个开源项目最大的好处就是所有人都可以加入开发，在仓库公开的两天内，就有人将模组移植到了1.21.1，1.21.4，1.21.8等版本。 我们相信随着更多人加入项目，这个项目所支持的游戏版本数量会远超YSM本体。

我们是否应该在YSM覆盖至更多版本前抢先重新定义标准

原始问题：例如通过移除不必要的加密以简化通信协议，逐步制定一套(独立于YSM原有的)适用于相关生态的开放标准(这可以简化移植难度并支持各种花里胡哨的自定义后端)。

并更进一步，通过设立一个“OpenYSM标准的协议”，明确客户端-服务端交互、模型加载、动画同步等环节的最低实现要求，并使得任何第三方的服务端插件、渲染前端甚至其他的模型mod都能以最低成本接入，从而彻底砸烂国内方块人模型的这坨恩情生态。

我们正在自己的服务端项目（OpenYSM Matrix）上扩展协议系统，这个项目完成之后将开源发布，从此任何服务端插件以及Mod都可以轻松的操作YSM协议，或者基于我们的系统开发自己的功能。

但是我们不认为取代YSM的协议标准是必要的，毕竟一定程度上兼容原版YSM并用更多功能吸引原版YSM用户过渡到OpenYSM才是我们希望达成的目的。

至于自定义协议，抛开加密YSM的协议设计其实很基础，已经没什么值得简化的了。

是否有计划更改modid

我们暂时不计划修改modid，因为这可能引起兼容性问题，例如如果有mod通过在Forge的Mod管理器中判断YSM是否被加载，用于校验的modid就大概率是YSM的而不是OpenYSM的，修改modid会导致校验失效。 不仅如此，ForgeHandshake会发送mod列表给服务器，如果服务器采用强制校验mod列表的方式判断YSM是否被加载，修改modid可能导致错误的判定。

在OpenYSM发布一段时间之后，我们可能会在某个大型更新中更改掉。

什么时候上Curseforge、Modrinth、McMod

这些平台都会卡审核，我们尝试过投稿CurseForge和Modrinth也因为各种原因被审核打回过，我们认为最快的分发mod途径就是直接在 https://ysm.rip 发布，GitHub账号解封之后也可以在GitHub Releases发布。

而Mcmod是国内平台，TartaricAcid本人在国内平台的名誉很好，这个网站的管理员中应该也有不少跟他关系较好的社区成员。 如果他本人要求mcmod下架我们的项目，网站的管理员会直接遵循他的要求。

Github账号复活进度

GitHub客服并没有积极处理任何工单，NoSteveModel账号可能短期内无法复活，但是我们相信是有机会的。

后续若YSM加密方式更新是否会发布新的对应Parser？还是基于OYSM开发独立的Mod，不再兼容YSM？

如果加密方式继续更新，我们会继续研究兼容方案，让YSMParser和OpenYSM都能够兼容新格式。 但是无法在mod更新后第一时间兼容，因为逆向也需要时间成本。 如果酒石酸菌真的更新了加密方式，等到大部分旧版本模型迁移到新版本加密之后，我们才会发布YSMParser更新和OpenYSM兼容。

假设开发YSM的时候如果VMP正确的保护了所有函数，逆向难度是否会大幅提升

难度会大幅提升，但我们的团队成员有丰富的虚拟化逆向经验。

能不能开发ysm转车万女仆格式的啊

我们暂时还没人详细接触过这个Mod，短期内不会开发。

你们在Github上的评论被隐藏了，是主动还是被动的

是GitHub给我们的账号误封了，我们猜测是在Issue发送了大量中文内容被自动风控系统判定为Spamming了。

加密链路代码到底有没有被VMProtect保护

TartaricAcid没正确配置VMProtect，加密链路无虚拟化保护，仅启动时部分JNI函数被保护。

如果TartaricAcid魔改Blockbench给特征做随机化处理，那还可以反渲染吗

TartaricAcid不可能这么做，YSM需要兼容大部分模型，如果他真的要做一个自己的Blockbench，并且限定使用这个工具作为YSM的指定建模软件，那他本人的名声只会变得更臭。

有没有可能直接在 Minecraft 渲染模型时捕获模型数据

早在我们开发这个工具之前就有RenderDoc抓帧获取模型的方案，但是有人拿着这个去跳脸TartaricAcid了。

在此之后，YSM渲染模型会强制进行不可见面剔除，所以需要从多个角度抓帧才能获取完整模型mesh，使这种本身就不易操作的方案变得更加费时费力。

而且在游戏中，模型任意物件的位置都有可能受到动画的修改，也可能有cube一直缩放为0，抓帧获取的mesh准确度完全得不到保证。

不但如此，这样的方案也不能获得可以直接逐个编辑物件的blockbench工程，更不能导出动作文件和音频文件以及附加的molang脚本等资源，属于迫不得已时才会用的模型获取手段。

是否打算长期维护

在YSM官方开源之前，是的。

一位和YSM官方团队关系较好的网友曾说过YSM开源是既定的，也就是说YSM会在未来一到两个月内开源。 如果官方团队的未来规划真如他所说的那样，那么在YSM官方开源之后，我们可能会停止维护这个项目并停止接受Pull Request，这相当于他们放弃了坚持那一套他们自认为正确的加密和代码保护手段，我们也没什么必要继续浪费时间去做对抗了。

但是在他们开源之前，我们是会继续维护OpenYSM的，只是目前不接受Pull Request。 当前阶段下，代码内还有很多BUG没修复，在保证所有功能稳定之后我们才会开放Pull Request。

是否会开发出有别于原YSM的功能

是的，当然会，我们已经开发了例如模型上传等原版YSM没有的功能。

更多功能也会开发，如果你有什么想法和建议，请到我们的GitHub仓库页面提一个Issue，完整表述你的需求或建议，我们会酌情考虑是否采纳。

是否会开发一些接口使得其他模组更容易兼容

我们的模组没有混淆，也没有混淆的理由，如果任何模组想兼容OpenYSM，只需要看一眼代码就可以直接调用我们的类或者方法写判断，也可以使用Mixin来处理我们的类。

是否会优化模型文件格式/是否会增加更多模型加载方式，来达到更好的效果

不会，我们打算长期保持使用Blockbench的格式，和YSM官方同步。

如果有，会邀请一些模型作者来做，只有该mod才能加载的模型吗

不会，那这样我们和TartaricAcid做模型加密有什么区别？

是否会更多的在国外进行宣传

暂无计划

请问你们的逆向团队一共有多少人

五个人

完成对.ysm格式的解密以及OpenYSM的开发花了多长时间

完成解密：一周以内

完成OpenYSM：约一周