Is it not more "VST author just does the bare minimum to keep honest people honest, because more invasive DRM risks ruining a live performance"? I'm not understanding why TFA author has such an attitude about this. Is the VST author a horrible person or running a toxic business model or something?

> I'm not understanding why TFA author has such an attitude about this

To me it reads like an ego trip rather than any kind of righteous vendetta against the author. Implicit in "look at the dumb thing this other person did" is "I'm smarter than them because I noticed the dumb thing".

I think the VST author and the DRM vendor are different people and the author is poking fun at the latter. It’s possible that the VST author isn’t aware that the fancy DRM protection they paid for doesn’t cover runtime.

I think the VST author knew that fine, but they figured that:

1) Protecting the installer will take care of most casual piracy

2) Protecting the VST might lead to unpredictable performance and issues on something that needs to run in real-time

So they chose to only protect the installer, which seems like a very user-friendly choice. I both enjoyed the writeup and want to second supporting the developer by buying a license.

That’s also possible, and even if that were the case I don’t see how this article is even tangentially saying that the VST author is a bad person or toxic or whatever the comment I was responding to mentioned.

It’s kind of a rote “this is a bad implementation” post that’s pretty obviously about the DRM vendor and not the guy that made a bass boost plugin for djs or whatever it is.

And furthermore, if a product designed to protect my income was only $200, I wouldn’t expect “serious security”, I’d expect exactly The kind of janky crap that was received.

They didn't even get into the actual protection itself. It may well be terrible, but it being xcopy-able is not the protection vendor's fault.

This is definitely just me, but the diagram with "motivation to buy" was amusing to me. I (try to) refuse to be manipulated by these tactics - if I think the software is worth buying, I will purchase and use it, otherwise I will look elsewhere! Nothing sets my "motivation to buy" to zero quicker than aggressive, "uncrackable" DRM. In fact, it usually skyrockets my "motivation to reverse", whether or not I actually need the thing (though usually this is overruled by having better things to do with my time).

Personally, I would change the article to anonymize the actual plugin that was cracked. The plugin author seems to be a solo dev/musician, actually more a musician than a developer, which might explain the poorly implemented copy protection*. But they're good at crafting sounds, and that's what they're selling. Or trying to sell. Or taking donations for, by the way: https://ko-fi.com/bassbullyvst

* I highly doubt it was deliberate as some others are suggesting.

> actually more a musician than a developer

Yes, they're not a developer at all. They just purchased a tool called "Romplur", you can make VST plugins with it and then export as an installer.

> I cracked a $200 software protection

No, not really. You "cracked" some random guy's $20 VST plugin. You never actually cracked Enigma Protector. The article started talking about cracking it then pivoted at the end to "I wrote a Python script to copy files from the installer" and said "the protection itself works fine"

author here. the irony is enigma protector's documentation literally explains how to add runtime checks to your payload. they just... didn't read it

And I'm glad they didn't. Protecting the installer keeps honest people honest. Protecting the runtime after installed means reduced performance and/or support headaches. That said I hope the developer didn't pay too much for this copy protection when some bespoke checks on the installer would have sufficed.

I'm just glad they didn't use iLok. It's been a pain for me as a legitimate user of a few iLok protected plugins.

Indeed. Some software DRM is so “effective” I’ve been permanently locked out of software I purchased.

I'm confused, then why does your article throw shade at both the protection software and the VST?

It sounds like you didn't find any issues with either of them, except that the VST vendor chose not to protect the thing you were hoping to crack?

I think he should be mainly throwing it at the VST vendor, as opposed to the protection software, since the main issue in the article comes from the vst vendor protecting the installer but not the actual software (that said, they also show that the protection software is fairly trivial to hook and bypass)

Question: Why go through the effort of removing most of the key throughout the article just to have it in a chunk of code in the article anyways? I'm not trying to throw shade here, I am legitimately curious about the reasoning

Runtime checks aren't an impossible effort to defeat either. If you're into this stuff, you should build a plugin with them yourself and then figure out how to crack it. It's a great learning exercise.

As another commenter wrote, the protection is there to keep honest people honest, like locking the front door of your house.

It's not foolproof and doesn't need to be. It's role is to make sure respectful users know that you'd genuinely prefer they not steal your stuff (not everyone actually does care about that).

Or maybe they knew about the runtime checks, but made a decision not to add them? As others have pointed out, this plugin can be used during live performances. The last thing a plugin author wants is a reputation for their software being flaky at really bad times. A runtime copy protection check might fail for spurious reasons, who knows.

Hi, I am the developer of Bass Bully Premium and I wanted to clarify a few things from my perspective.

I chose to protect only the installer with a simple lock-door method because my priority has always been stability and performance, especially at runtime. In the VST and plugin world, heavy or aggressive DRM can cause glitches or failures during a live performance. That risk felt far more harmful to my paying customers than the risk of casual piracy.

I understand that reverse engineering is part of how some people learn, and I am not here to criticize that. But when a post becomes a look-at-how-I-cracked-this thread, especially one that singles out a small independent developer, it starts to feel like a hit piece rather than a technical discussion.

The protection was minimal. It could be cracked. Maybe I should have done more. But this was not about being stingy with security. It was about delivering a stable and reliable plugin to real users without introducing bugs, system conflicts, or performance issues that can come from heavier protection systems.

I appreciate honest technical discussion and feedback. I also hope people understand that not every developer has a large team or a big budget. Many of us have to balance protection with usability, and for me, making music was more important than building an unbreakable DRM wall.

For some context, the original Bass Bully plugin started as a free release. It unexpectedly went viral, and users reached out asking for a more premium version with more sounds and features. I created Bass Bully Premium because the demand was there. It ended up being used in the production of Playboi Carti’s music, which later led to a collaboration VST with his producer wakeupf1lthy. The plugin also made its way onto Lil Wayne’s Carter album through producer Keyboard Kid.

If you like the plugin and it helps your workflow, supporting it by buying a legitimate license goes much further than any crack-test ever will.

Thanks for taking the time to read this.

Josh, Director Bass Bully VST https://www.bassbullyvst.com/

For VST performance and timing is important so you can't protect the actual plugin

It only affects the timing of starting it up.

> no winhttp.dll, wininet.dll, or ws2_32.dll. offline validation only. all crypto is local, so theoretically extractable.

You can't possibly know that by the mere lack of these DLLs from the import directory.

TFA is checking those via imports, not copied DLLs.

I suppose they could LoadLibrary/GetProcAddress at runtime, but that'd be a lot of effort for obfuscation.

For $200 how many casual pirates does it have to dissuade to pay for itself. Not many. At that price it doesn’t need to be very good.

Technically, it needs to dissuade pirates who then go spend money on the software legitimately.

Is this LLM slop? One cannot truncate RSA signatures and still check them. The sample hook code is nonsense, it lacks an address to hook (and would break Enigma‘s self-checks). The sentence structure and all lower-case looks like a bad prompt attempt to hide LLM usage.

Agreed. I don't know anything about DLL hooks, but code looks like nonsense to me. It's trying to hook into a null pointer.

  #include <windows.h>
  #include <detours.h>
  
  static int (WINAPI *Real_EP_RegCheckKey)(LPCSTR, LPCSTR) = NULL;
  
  int WINAPI Hooked_EP_RegCheckKey(LPCSTR name, LPCSTR key) {
      return 1;
  }
  
  BOOL APIENTRY DllMain(HMODULE hModule, DWORD reason, LPVOID lpReserved) {
      if (reason == DLL_PROCESS_ATTACH) {
          Sleep(2000);
          DetourTransactionBegin();
          DetourUpdateThread(GetCurrentThread());
          DetourAttach(&(PVOID&)Real_EP_RegCheckKey, Hooked_EP_RegCheckKey);
          DetourTransactionCommit();
      }
      return TRUE;
  }

Nice going Jean, after you've scammed people out of thousands of dollars, associated with known furry pedophiles, your membership in a skid gang, leeching off your parents money in France to remove your dox and steal even more money from them so you can make a new startup every month while larping about living lavishly. We know what you did.