[终极 Yum Audio 插件套装] Yum Audio The Complete Bundle 2025 Incl Patched and Keygen READ NFO-R2R [WiN]（114.0MB）

卸载旧版本。

安装。

运行我们的程序并注册。

尽情享受吧！

如果您想更改 OpenGL 支持，

请将“OpenGL – Enable”或“OpenGL – Disable”文件夹中的内容复制到

“%APPDATA%\Application Support\Yum Audio”。

我们不确定所有产品是否都支持此设置。

TEAM R2R 2026

机器 ID 不稳定
———————-
在 Moonbase JUCE 模块中，机器 ID 的生成依赖于 JUCE 的 UniqueID
函数。问题在于，旧版 JUCE 中的 UniqueID 在某些
计算机上无法正常工作（每次重启计算机后 ID 都会改变）。我们发现一些开发者
仍然在使用存在问题的旧版 UniqueID 来运行 Moonbase。

你可能会问，到底是谁在用旧版 JUCE？在
现实世界中，确实有一些开发者还在这样做。虽然 JUCE 8 是最新版本，但许多插件仍然基于 6/7 版本构建。HISE
引擎基于 JUCE 6，尽管 HISE 对
UniqueID 做了一些自定义修复 :P

Moonbase 似乎已经注意到了这个问题。Yum Audio 的一个最新
插件采用了一种新的机器 ID 计算方法，不再依赖于
JUCE 的 UniqueID。以下是该插件中机器 ID 的计算方式：

System32 目录的 FileSystemID + CPU 厂商名称 + CPU 型号名称

<<

在 JUCE
改用 UniqueID 之前，FileSystemID 曾用于生成机器 ID。由于以下原因，该功能已被弃用：

* Windows 更新可能会更改 FileSystemID。
* 32 位进程和 64 位进程的 FileSystemID 不同。

如果开发人员需要使用 Moonbase JUCE 模块，唯一能使其
正常工作的方法是使用 JUCE7（最新版）或 JUCE8。HISE Engine 用户需要
确认他使用的是已修复的版本。

他们真的需要聘请一位精通 Windows 和硬件的人员 :/

无用的额外保护
————————
Moonbase JUCE 模块有一个 JSON 文件，用于进行如下配置。

{
“productId” : “super-compressor”,
“baseUrl” : “http://blah.moonbase.sh/”,
“offlineUrl” : “http://blah.moonbase.sh/activate”,
“licenseFileLocation” : “Super Plugin/Super Compressor/license.mb”,
“publicKey” : “(在此处插入 RSA2048 公钥)”
}

自 YumAudio/BlackSaltAudio 时代以来，我们已将 RSA 公钥替换
为我们自己的公钥，以使密钥生成器正常工作。

一段时间后，Moonbase 开始检测公钥的修改。如果
检测到修改，它将不会读取许可证。该检测是通过
使用 BigInt 进行数学运算来实现的。

最新的保护措施更加巧妙。公钥并非以 ASCII
格式保存，而是像这样逐个连接公钥文本：

put(“a”);
put(“X”);
….
put(“n”);
put(“=”);

我们不明白他们为什么花了额外的时间来加强保护。
是他们的客户要求的吗？

自从第一个保护机制出现以来，我们就一直在制作密钥生成器。当时没有 Moonbase，没有文档，也
没有 SDK。没有任何提示。一般来说，懂密码学
并且能在不看源代码的情况下分析许可结构的黑客不会被
这些伎俩迷惑。根据我们的聊天记录，这两个新伎俩都在
10 分钟内被破解了。考虑到所需的工作量和成本（设计、代码、测试、文档……），
最好什么都不做。不要让保护机制变得复杂。

世界上有很多有竞争力的在线许可解决方案。
它们中的大多数都没有反盗版功能，因为它们根本不起作用。如果客户需要
反盗版功能，他们会付费购买真正有效的服务或软件。

其他小问题
——————
双层芝士汉堡：Moonbase 在编码时，
首先会进行 base16 编码，然后再进行 base64 编码。最终长度会因为
这种浪费而翻倍。

“Pikachu” -> “50696b61636875” -> “NTA2OTZiNjE2MzY4NzU=” (plain->b16->b64)
“Pikachu” -> “UGlrYWNodQ==” (plain->b64)

还有许多其他方法可以延长 NFO 文件。

Machine ID Instability
———————-
In Moonbase JUCE Module, Machine ID Generation is depending on JUCE’s UniqueID
function. The problem is, the UniqueID in old JUCE is not working on some
computers (it changes ID at every computer restart). We saw some developers
are really using Moonbase with that problematic old UniqueID.

Who the hell is using old JUCE? You may ask. Some developers still does in the
real world. While JUCE8 is the latest, many plugins are still built on 6/7.
The HISE Engine is based on JUCE6, although HISE had some custom fix for the
UniqueID :P

It seems that Moonbase already noticed that issue. One of the latest Yum Audio
plugin is using new way of Machine ID calculation which does not rely on
JUCE’s UniqueID. Here is how they calc Machine ID in that plugin :

FileSystemID of Sytem32 dir + CPU Vendor Name + CPU Model Name

<<

The FileSystemID was used in the first JUCE’s Machine ID generation before
they went to UniqueID. It was deprecated becayse of the following reasons.

* The FileSystemID can be changed by Windows Update.
* The FileSystemID are different between 32bit Process and 64bit Process.

If the developer needs to use Moonbase JUCE Module, the only way to make it
working properly, is using JUCE7(LATEST) or JUCE8. The HISE Engine user needs
to confirm that he is using the fixed one.

They really need to hire someone who knows well about Windows and Hardware :/

Useless Extra Protection
————————
In Moonbase JUCE Module, it has JSON file to configurate like this.

{
“productId” : “super-compressor”,
“baseUrl” : “http://blah.moonbase.sh/”,
“offlineUrl” : “http://blah.moonbase.sh/activate”,
“licenseFileLocation” : “Super Plugin/Super Compressor/license.mb”,
“publicKey” : “(INSERT RSA2048 PUBLIC KEY HERE)”
}

Since the YumAudio/BlackSaltAudio age, we have replaced the RSA Public Key
to our one to make keygen working.

After a while, Moonbase starts detecting Public Key modification. If the
modification detected, it won’t read the license. The detection is done by
math using BigInt.

The latest protection has more trick. The public key is not saved in ASCII
format. It concatenate public key text one by one like this.

put(“a”);
put(“X”);
….
put(“n”);
put(“=”);

We have no ideas why they took extra time to make the protection “stronger”.
Did their clients request for that?

We have made keygens since the first protection. There was no Moonbase, docs,
SDK. No hints at all. Generally speaking, hackers who know cryptography
and who can analyse the license structure without source code are not confused
by those tricks. According to our chat log, both new tricks were solved within
10 minutes. Considering the effort and cost (design, code, test, docs…….),
it is better to do nothing. Do not make the protection complicated FOR YOU.

There are lots of competitive online licensing solutions in the world. Most of
them do not have anti-piracy because it doesn’t work. If the client needs a
anti-piracy, they will pay to the service or software that actual works.

Other Small Things
——————
Double CheeseBurger : When Moonbase is encoding something, it encodes to
base16 at first, then it encodes base64 again. The final length is doubled by
that waste.

“Pikachu” -> “50696b61636875” -> “NTA2OTZiNjE2MzY4NzU=” (plain->b16->b64)
“Pikachu” -> “UGlrYWNodQ==” (plain->b64)

And there are lots of other things to make NFO longer.