Yum Audio The Complete Bundle 2025 [WiN]

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.