Activate key/license XF Core/Addon validation against piracy

Yenxji

Active member
I have seen this XenForo was 15 years old and released from 2010. I think it’s time to make that XenForo core and addon that must have activate key/license to active and protect against piracy. This would save all developers to continue own addon. If they don’t and they would have lost money anyways no matter what that pirate will still continue to re-sell and because that they are rat. They made my heart broken of my addon have been stolen.

Stop piracy and pirate now!
 
The best advice I can give is to try not to care so much.

Of course nothing excuses piracy but, frankly, being "heart broken" about it is not sustainable. It's going to happen. It literally doesn't matter what protections are in place, your code is essentially "visible source" and therefore it can be very easily be copied or reproduced.

On the merit of the specific suggestion, I'm sorry, but it won't do any good. As I alluded to above, an activation / license key serves no purpose to prevent piracy.

It would take an amateur developer a matter of minutes to bypass license key / activation. Therefore all it does is add additional friction to genuine customers.

Bear in mind companies like Microsoft spend millions every year on anti-piracy mechanisms. I bet you could find a current build of a Microsoft product to download for free in a couple of minutes.
 
Bear in mind companies like Microsoft spend millions every year on anti-piracy mechanisms.
I've heard anecdotal stories that MS customer support will sometimes ask users to try a pirated activation service if their own service fails to activate a legit copy of Windows.

---

The only thing that would put a dent in piracy from a DRM perspective would be if every addon was encoded with something like IonCube, but that would take away one of the great things about addon development; being able to learn from each other.
 
The only thing that would put a dent in piracy from a DRM perspective would be if every addon was encoded with something like IonCube, but that would take away one of the great things about addon development; being able to learn from each other.
You wouldn't need to encode the whole thing. Just a breaking function. If partial IonCode is removed, there would still be stealthy PHP code that relies on it, say a variable that's needed or just a minor function that does a dull task, so it would break the add on if it's not there.
 
You wouldn't need to encode the whole thing. Just a breaking function. If partial IonCode is removed, there would still be stealthy PHP code that relies on it, say a variable that's needed or just a minor function that does a dull task, so it would break the add on if it's not there.
Then it’d also be easy for a mildly competent developer to figure out what’s happening.
 
Then it’d also be easy for a mildly competent developer to figure out what’s happening.
A shower thought: Make a code event listener for posts made. Replace all posts users make with "This is an unlicensed version of X".

If they figure out how to turn it off, make it disable the add on, or do other nuisance like replacing phrases with lorem ipsum, or breaking one function out of many (like in your instance, depositing money in the bank), and switch it up each release version. It'd take a bit of extra work to figure out, but I think you could find a way to make it nearly impossible to do as one portion of the code could break it all if the encoded portion was removed.

But Store and Credits, I have to assume, is your bread and butter. And if I had to guess, are the most pirated add ons that you release. So, you'd have to evaluate whether protecting that bit of income is worth an additional hour per release to throw the "nullers" off.
 
I agree, it’s not something that can be stopped. Best thing to do is publicly expose these individuals so more eyes get on it and hopefully action is taken against them.
I agree but while doing that you’re advertising for them.
 
o, you'd have to evaluate whether protecting that bit of income is worth an additional hour per release to throw the "nullers" off.
The problem is, that hour's work wouldn't throw them off. At most, it would make them do a bit of work.

Perspective: I have been using computers for over 40 years, beginning in the eighties with Apple IIs and Commodore C64s. One of the tricks some companies tried back then was requiring a hardware dongle to be plugged in for the software to run. I played those games without the dongle. Not that I cracked them myself, but a friend of a friend got a cracked copy. And that was in the days of 5.25" floppies. People were copying the cracked versions using (bleep)ing floppies. Sneakernet, as we used to call it. So how do you expect to stop it when the Internet, a highly efficient transfer mechanism, exists? The devs will always be, at most, half a step ahead of the pirates, who will catch up.

The solution, then, is for users to be honest and stop cheaping out by using "free" software that isn't actually free software. And for awareness to be raised about these sites so we know to avoid them. But given what I just said, 40+ years of history suggests that ain't happening anytime soon.
 
The problem is, that hour's work wouldn't throw them off. At most, it would make them do a bit of work.
I'm not entirely sure how IonCube works, but if it works as I think, and isn't crackable, it would make a pirated add on impossible to null because there would be at least 1 vital function in there that would be encoded, and without it, the add on wouldn't work.

So if IonCube is as strong as I think, it would be the perfect solution.
 
I'm not entirely sure how IonCube works, but if it works as I think, and isn't crackable, it would make a pirated add on impossible to null because there would be at least 1 vital function in there that would be encoded, and without it, the add on wouldn't work.

So if IonCube is as strong as I think, it would be the perfect solution.
I think I understand where the confusion is. What @Mendalla and I are saying is; you could simply re-create the encoded function.

Let's say I have this file:
PHP:
<?php

namespace DBTech\eCommerce\Repository;

use XF\Mvc\Entity\Repository;

class ClassifiedsRepository extends Repository
{
    public function getFilteredUserGroupTitlePairs(array $userGroups): array
    {
        return array_filter(
            $userGroups,
            fn ($v, $k) => in_array($k, \XF::options()->dbtechEcommerceClassifiedsUserGroups),
            ARRAY_FILTER_USE_BOTH
        );
    }

    public function getFilteredInputGroups(array $inputGroups): array
    {
        return array_filter(
            $inputGroups,
            fn ($v) => in_array($v, \XF::options()->dbtechEcommerceClassifiedsUserGroups)
        );
    }
}

Now, let's say we want to encode one of the functions, and to make it even more confusing we also rename it so that it's no longer possible to discern what the function does simply from its name. We might end up with, instead of getFilteredInputGroups, something like this:
PHP:
    public function x0800fc577294c34e0b28ad2839435945(array $x098f6bcd4621d373cade4e832627b4f6): array
    {
        // Replace this with however IonCube actually works
        return IonCubeDecode('ad0234829205b9033196ba818f7a872b');
    }

Looks foolproof, right? There's nothing in the function name or anything else that actually gives any hint what this function does.

Then we look at usage:
PHP:
        $bulkInput['extra_group_ids'] = $classifiedsRepo->getFilteredInputGroups(
            $this->filter('extra_group_ids', 'array-uint')
        );

Even if we replace it so it says:

PHP:
        $bulkInput['extra_group_ids'] = $classifiedsRepo->x0800fc577294c34e0b28ad2839435945(
            $this->filter('extra_group_ids', 'array-uint')
        );

It's still pretty obvious that it's doing some kind of processing of the filtered input.

Working with this information, at some point during the process, the cracker would look at the settings and find this:
1740405769719.webp

Putting two and two together, you can reasonably deduce that the encrypted function is filtering the user-provided data, and simply re-create the function in plaintext. Even if the code isn't 100% identical to what I originally wrote, it would still do the same job.

The addon has therefore been cracked.

So, the only way around this is to encode more of the addon, right? If we keep applying this methodology to other random functions across the addon, all we're really doing is slowing the cracker down by having to repeat this process multiple times. If we encode a large enough chunk of the addon that an entire feature is locked behind encoding, then it's functionally identical to encoding 100% of the addon.

Even if you're willing to accept 100% encoding, that simply creates a new problem: There is now no way to know that the addon author isn't doing something shady. I could encode anything in the IonCube encoded portions. I could send your session record and session cookie back to my server and change the session's IP to match my IP address, then simply insert that cookie in my browser and boom, I am logged in as you. Or I could change your password and simply login as if I'm you. I could DROP DATABASE. There is literally no limit to what sort of shenanigans I could do.

That is, I would presume, at least part of the reason why encoded addons are forbidden.

Speaking personally, I want to give my customers the ability to modify the code. I want other developers to be able to figure out ways of extending my addons with their own functionality - or simply integrating with my addon, in the case of Credits - without me having to write and maintain detailed documentation.

Piracy is a service problem in a lot of ways, and I believe the addon update notifications in 2.4 is an important first step. If XenForo in the future will work towards increasing the visibility of addons by allowing admins to f.ex. search for addons in the AdminCP akin to WordPress, you reduce a lot of friction that might drive people towards all-in-one sites like the piracy sites.
 
So if IonCube is as strong as I think, it would be the perfect solution.
I've had the pleasure/displeasure of working with products encoded with IonCube. It hampers the end user's ability to fix issues on their own and forces the original developer to intervene directly. If the developer isn't responsive or takes time to address a specific issue, you're dead in the water

This is what an IonCube encoded .php file looks like (for example). This is from a sub-product, or essentially an addon in XF terms.
1740407770648.webp
 
Last edited:
This is what an IonCube encoded .php file looks like (for example). This is from a sub-product, or essentially an addon in XF terms.
I wasn't suggesting the full add on to be encoded, just a portion that would make the rest fail if it was determined to be a pirated copy. Further, that portion be vital for the add on to fully execute. So, you still have the "learning environment" with 99% visible source, but without that 1% or figuring out what that code could be on your own, that links to other code to break, you have nothing that works.
 
I wasn't suggesting the full add on to be encoded, just a portion that would make the rest fail if it was determined to be a pirated copy. Further, that portion be vital for the add on to fully execute. So, you still have the "learning environment" with 99% visible source, but without that 1% or figuring out what that code could be on your own, that links to other code to break, you have nothing that works.
And @DragonByte Tech explained very well the problems.

Also, will Ioncube be feasible for those of us on shared hosting? If it requires plugins to the web server or a daemon in the OS to do the decryption, we could blocked out of installing any add-on using it.
 
Not that I've written add-ons for XF, but I do appreciate being able to tinker a little around the edges of those we do use. So looking at this more as a consumer think generally you'll find the people who are happy to use pirated software are not the sort of people who will instead be buying your software so I can't imagine you'd be recovering much in the way of sales by "stopping it". So that leaves someone unwittingly buying your software from a pirate not knowing who the true author is. That seems like a more likely situation where you have "lost a sale".

So off the top of my head and thinking out loud ... one way of tackling that would be to at least offer a purchase mechanism through XenForo itself - the company rather than the software. Now I'm not a big fan of locked in "app stores" and the like so I'd never want this to be the only way, but buying my add-ons via this site would certainly lend some assurance that I was buying the "legit" copy. Granted it introduces some overhead of management to ensure the pirates were not "here" and so forth (code duplication checking maybe) so maybe XF do take a small cut of the sale for that. Personally I do find it a little annoying that I have several other places I need to go to and grab updated add-ons, pay licences and so forth - some of those sites are better than others, but it's more overhead for me. There is a slight lure to just being able to login to my account here and tick the boxes for the core and add-on licences I wanted to renew and download them - job done. Would I even pay a little more for an add-on here to make up for the overhead "cut" - quite possibly if it make my admin overhead lower. Granted I accept XF get more information about me as a customer, but given I'm heavily bought into their ecosystem already that doesn't feel too dreadful in this case.

Anyhow that's my not excessively thought out "first thought" as to one way you might tackle (to a modest extent) it other than through direct code based DRM which I'm even less of a fan of :)
 
Last edited:
I'm not entirely sure how IonCube works, but if it works as I think, and isn't crackable, it would make a pirated add on impossible to null because there would be at least 1 vital function in there that would be encoded, and without it, the add on wouldn't work.

So if IonCube is as strong as I think, it would be the perfect solution.
IonCube can easily be decoded, and older IonCube methods are publicly available; more recent ones (up to the current 14) are generally private, but you can get them through different channels.

While not every person in the piracy scene will be capable of decrypting, it is a non-zero chance that it will eventually get cracked.

Using IonCube also means that many medium to large communities, as well as many business/enterprise communities will not use the product as code review is basically required at a certain level. That means a loss of business, and also more expenses for the developer (probably the $300 plan).
 
AI as Claude or Grok, Deepseek will become powerful in the next 5 or 10 years away and they can take computer or programming code control, they can write that make XenForo core and add-on support to make activate license validation more difficult against piracy. Neither all of you nor me are thinking that is impossible is nothing but it's possible. AI is more powerful than humans because it can do anything for new technology.

ChatGPT was kinda meh and taken by Deepseek for open source and free

Claude 3.7 sonnet has been released
 
Back
Top Bottom