#Obfuscation

112 messages · Page 1 of 1 (latest)

median widget
#

Hey

#

If I want to hide my code in production, if I'm using Vite as the bundler, is not serving sourcemaps enough to sufficiently protect the code?

#

Or should I use a vite obfuscator plugin

#

my question is basically, if i don't provide sourcemaps, would it be possible to someone to unpack or get the original source code from the minified bundle that vite produces?

#

and what would be the benefits of using some sort of vite obfuscation plugin

#

Also, I understand that it is possible to debug any client-side code and that I should not store any sensitive data there, so please ignore that

fossil stump
#

anyone proficient enough at programming will be able to easily identify common patterns, so they'd be able to pretty easily guess certain parts of the code

#

and once those are renamed, it makes the purpose of other parts clearer

median widget
fossil stump
#

maybe

median widget
#

i'm concerned about this blowing up the file size tho

#

if i have like a 2mb bundle

#

you really think it'd be trivial to reverse engineer the bundle? even if it has a couple of libraries included

halcyon tree
#

Trivial isn't really the right word, but it will always be possible. Time consuming? Yeah. Especially if it's the first time someone's done it, but having built some tools to help with it in the past, I'm pretty confident in saying all you can do is make it harder.

fossil stump
#

there are even tools online to reverse some common obfuscation techniques

halcyon tree
#

Even if you wrote in something that compiled to WASM, that can be reverse engineered. It's probably harder as there are likely less tooling available for it since it's relatively new, but...

fossil stump
#

and if you're trying to protect a secret then that's even more impossible to protect against, since you could extract it from a breakpoint, or network logs, or devtools tabs

median widget
#

yea i know it will always be possible to debug

#

but i just wanted to be sure that like vite doesn't do anything specifically to reveal the source code as well

#

sometimes on websites, i can see the original ts source files if i open devtools

#

and i learned this is because of sourcemaps

#

so as long as i don't serve sourcemaps, this shouldn't be possible right

halcyon tree
#

If you don't publish sourcemaps, yes, the original TS won't be visible in a debugger from the compiled JS

#

Though generally compiled JS really closely matches TS... even minified stuff isn't that hard to turn back into the original

median widget
#

you think so?

#

what if there's a couple libraries included as well

#

because i tested, and obviously a bundle with a few simple lines was pretty easy to transform back to the original code (minus the original variable names)

#

but once i included libraries the bundle seemed a lot more complex and harder to read

halcyon tree
#

libraries certainly make the output bigger, but if you can identify what library it is via its exports, then that can be ignored

median widget
#

but if it's all in 1 file, wouldn't it be hard to remove all the code pertaining to specific libraries and extract only the original sourcecode?

halcyon tree
#

Basically every bundler I've seen, will, with minor inlining exceptions, stick modules into functions, if you identify a function as being library X, you can note that and remove the function

median widget
#

ah interesting

#

it would probably be best to use some kind of obfuscator then wouldn't it

halcyon tree
#

shrug it'll probably make it take more time, if that's what you're after

median widget
#

as long as it's not as simple as just removing certain functions and yoiu're able to get to the main function

#

i think it will be better

halcyon tree
#

However, it's likely to break on larger applications
Fun disclaimer there

median widget
#

but yea i've debugged obfuscated js before and i know it is not hard

#

with breakpoints and stuff

#

i also had another question about vite

#

So I have this as my main.ts file

function test() {
    for (let i = 0; i < 10; i++) {
        console.log("Hello world")
    }
}

test()
test()

console.log("test")

And here is the bundle that vite produces (formatted)

(function() {
    const o = document.createElement("link").relList;
    if (o && o.supports && o.supports("modulepreload")) return;
    for (const e of document.querySelectorAll('link[rel="modulepreload"]')) i(e);
    new MutationObserver(e => {
        for (const t of e)
            if (t.type === "childList")
                for (const s of t.addedNodes) s.tagName === "LINK" && s.rel === "modulepreload" && i(s)
    }).observe(document, {
        childList: !0,
        subtree: !0
    });

    function c(e) {
        const t = {};
        return e.integrity && (t.integrity = e.integrity), e.referrerPolicy && (t.referrerPolicy = e.referrerPolicy), e.crossOrigin === "use-credentials" ? t.credentials = "include" : e.crossOrigin === "anonymous" ? t.credentials = "omit" : t.credentials = "same-origin", t
    }

    function i(e) {
        if (e.ep) return;
        e.ep = !0;
        const t = c(e);
        fetch(e.href, t)
    }
})();

function n() {
    for (let r = 0; r < 10; r++) console.log("Hello world")
}
n();
n();
console.log("test");
#

it's obvious that the last 6 lines are just what the original main.ts program was

#

but what is all of that code before it

#

why is it using a mutation observer

halcyon tree
#

Live reload I suspect, to automatically reload your browser tab when you change the code in watch mode

median widget
#

but why would this code be in the production bundle?

#

i did npm run build

#

isn't HMR only for development

halcyon tree
#

Yeah, strange

#

Maybe some browser has a bug where modulepreload is ignored, so it's forcing a fetch on those resources?

median widget
#

hmmm

halcyon tree
median widget
#

oh it's a polyfill

#

is that something i should keep

halcyon tree
#

Depends on what browsers you're after supporting, if you actually even use multiple modules after bundling...

median widget
#

also had another question about vite

#

one of the libraries i'm using is included inside the final bundle

#

and it has this css

#

takes up alot of lines

#

did i do something wrong / should that be minified or something

#

was also wondering what this code does

image.png
vernal sky
#

vite/rollup/esbuild are already "harder" to reverse because they merge all modules into a single scope whereas in webpack you can distinguish them

median widget
vernal sky
#

yes

median widget
#

could i give you something to try

vernal sky
#

ok

median widget
#

@vernal sky i've seen another obfuscator being used by some licensed programs

#

it's not javascript-obfuscator

#

Its like

#

one of the features is that every single string is split up and they're all like

#

wrapped by functions

#

like "example string" => "exa" + "mple s" + "tring" => o(536) + K.a(456) + s(1800)

#

something like that

#

do u know what im talkin gabout

#

I think its a paid service

#

it might be jscrambler but i'm not sure

vernal sky
#

thats a pretty common feature, could be anything

median widget
#

almos looks only minified but it's really obfuscated and protected

#

whereas like javascript-obfuscator you can clearly tell because everything is like hex

fossil stump
#

while i haven't seen a deobfuscator for that style, it would be fairly easy to write one in JS, i'm pretty sure.

#

you'd just pass the deobfuscator a list of functions to run at compile time, and then it'd run (o, and K.a, and s), and turn them all back into strings

#

that said, because it's harder to find a deobfuscator for that online, it might be better than other options

median widget
#

stuff like this as well, not seen in javascript-obfuscator

image.png
#

more recently, i've investigated scripts that spam breakpoints via debugger; inside anonymous functions to make it hard to use devtools, and, if i disable breakpoints, the site crashes

median widget
median widget
fossil stump
#

isn't as easy, yes

#

isn't easy for someone with decent experience in deobfuscation, probably not

median widget
#

how could i compile a package using a bundler into a vanilla js file that i can include on my site without type="module"

fossil stump
#

or changing whatever the bundler's "module" setting is, to "commonjs"

median widget
#

I meant for my dependencies, like could I create a file that is just like dependencies.js with everything that I used npm install --save for and a separate main.js?

fossil stump
#

well

#

no because dependencies should already be bundled into the main file

#

is there a reason you want your dependencies to be separate?

median widget
#

well just back to the main point of this thread, if i want to have main source code that is meant to be protected, there's no point in obfuscating the dependencies along with it, it'll just blow up the file size for no reason, and i want to have as few files as possible

fossil stump
#

i mean

#

the easiest way i can think of, is to have basically a "barrel import" file where you import all your dependencies, and then re-export them

#

it'd look pretty janky though

median widget
#

something like this?

import { whatever } from 'whatever'

export { whatever }
#

and bundle that into a single file

fossil stump
#

yeah.

#

not 100% sure how hard it would be to specify that file as one bundle, and your entrypoint as the other bundle

median widget
#

hmmm

vernal sky
#

that plugin already excludes node modules: https://www.npmjs.com/package/rollup-obfuscator#obfuscator-options
may need to enable https://vitejs.dev/guide/build#chunking-strategy

Vite

Next Generation Frontend Tooling

npm
rollup-obfuscator

A plugin to obfuscate javascript for rollup & vite based on https://www.npmjs.com/javascript-obfuscator. Latest version: 4.1.1, last published: a month ago. Start using rollup-obfuscator in your project by running npm i rollup-obfuscator. There are 2 other projects in the npm registry using rollup-obfuscator.

median widget
#

I think this is what I meant

image.png