I'm Shocked! Why Are Plugins Decrypted on Install?

I just realized that UXP plugins are decrypted and installed as plain text on the user’s computer. Seeing the ccx installer file encyrpted was one of my initial motivations to rewrite my old border scripts for the UXP framework. I’ve poured months, literally thousands of hours into developing a feature-rich plugin and now find that all of my code is just sitting there for anyone that buys the plugin to see.

I know that it’s not really possible to completely protect scripting languages from being viewed with encryption alone, but really, is it necessary to simply leave this fully visible to anyone that wants to take or look, or even steal? Are there any plans to protect the intellectual property of the hordes of developers pouring their hearts and souls into these plugins?

2 Likes

You could obfuscate your JS :wink:

1 Like

Sure, but I didn’t know it was not encrypted until a few minutes ago. Aargh!!

What do you mean by decrypted? It was never a secret, that CCX is just a simple ZIP archive with all your code inside

1 Like

For sure, it’s my oversight, but I was reassured when I opened the installer and found a binary file. I thought that Adobe had done a good job to protect the contents of the plugin. Besides, I never said it was a secret. It was just not something that I thought to check into further based on the binary installer.

It never was encrypted in the first place.

OK, old hat developers. I know NOW that it was never encrypted, but it was not obvious that it was not. Does no one agree that more could be done to protect the contents of the files?

Even better, what are people using to obfuscate your files? If you are already using something that is known to work well with UXP plugins, I’d really appreciate some constructive advice.

1 Like

Proper encryption is on our wishlists for decades. Even JSXBIN is not an encryption. It even preserves variable names.

Yes, I saw that, again though, just tonight, after I found the jsx files sitting all unpacked on my hard drive. Should have looked harder much earlier.

1 Like

Hi, you might want to have a go with this

https://obfuscator.io/

1 Like

Thanks! I was just looking at that so your reply gives me confidence to dig deeper.

Have you used this yourself for a UXP plugin? I don’t want to jump in and do something that would cause problems for the review process or anything.

I use Obfuscator (same @Pierre_G posted) and webpack:


module.exports = function (env, argv) {

    <...>

    return {
        <...>
        plugins: [

            <...>

            new WebpackObfuscator({
                debugProtection: true,
                disableConsoleOutput: true,
                selfDefending: true,
            }),
            
            <...>

        ]
    };
};

Works like a charm

3 Likes

Excellent! Thanks @Karmalakas. I’ll give it a try.

I’m using that link for each and every plugin of mine. Plenty of options to adjust. Until it eventually breaks. So you’d want to start and gradually introduce more “scrambling” until… then you know what works for you :slight_smile:

Great! Thanks @Pierre_G ! I really appreciate the help.

You’re most welcome :pray:t2:

Same worked for me. I think both plugins passed review in Marketplace.

1 Like

I was wondering… If you use React and your code gets compiled to plain JS, is there really an easy way to retrieve the original state? Sure, you could steal some individual parts but without seeing the whole picture they’d be out of context and kind of hard to understand, wouldn’t they?

That’s correct. Not even sure about reverse-engineering some parts, or one should have a lot of time and energy to dive in :wink:

Sounds fine to me then. I also feel like someone who’d take the time to reverse-engineer that compiled mess could also just write the plugin himself in the first place :man_shrugging:

1 Like