P
P
pavelkolodin2017-11-23 16:29:08
JavaScript
pavelkolodin, 2017-11-23 16:29:08

Anti-debugging tricks for JS?

One obfuscation is not enough. Is it possible to get involved in some more tricky things that help to distinguish your script being launched by the browser "originally", some addition is screwed to it, the source code has been changed, or is it in some other environment?
In principle, it is possible to connect the entire logic of the script with some calculations incomprehensible to the user with permutations of links in long arrays, so that these calculations do 90% of the work for dust in the eyes, but side by side initialize some key links in the obfuscated code. If some garbage does not match, this entire amount of calculations goes on as usual, but leaves the structure in a non-working form.
Well, you can radically take LLVM, write everything in C ++ and supply machine code that runs in asm.js, and there you can also make pies in 10 layers with additional downloads of pieces from the main server. But all this will be too cruel, expensive and slow.

Answer the question

In order to leave comments, you need to log in

5 answer(s)
I
Ivan, 2017-11-23
@IvanTheCrazy

The radical method is not to post it online. It will be necessary - they will disassemble and put everything on the shelves. If you don't want it, don't post it

P
profesor08, 2017-12-12
@profesor08

Nobody needs your js code. There are cooler and prettier things out there already and available for free that showcase superb performance. Where did I get this, you ask? Yes, if your code had at least some value, significance and interest, you would have demonstrated it yourself. Like, look how I can and how cool it turns out. Well, for now, you just want to hide your shit code.

U
utyfua, 2017-11-23
@utyfua

I got into this code 10 times.
Personally, I do not think that it is possible to protect the code from substitution purely from the client side.
Here you need a server one that will be a "task" for the browser to which all browsers will have the same answer. If you get into the code, then because of the non-obviousness, you can catch it but not limit it to 100%, because you learn from mistakes.
If everything is in js and you need it to be more difficult to analyze (not 99.99% secure), you can do this:
The user comes in. For it, we generate a special algorithm directly in the source code of the script (for example, do Math.ceil(id*1.12) for the answer of any test).
For any request, we accept an eval function with a "task".
When requested, we send the answer of the task + that special part (we just sum or mix, but in no case do we connect the lines).
If there are enough errors, then we send ourselves a report, block the user, or even even.
In eval, you can still focus not only on the current userspace, but on the one that was generated by the previous task. The main thing here is to understand which script works in which tab, because there will be many inconsistencies, and you can try the current for the sake of experiment, no more.

A
Alexander Taratin, 2017-11-23
@Taraflex

It will complicate it by the very drop, but it is still useful, if only for the sake of preventing script substitution without the knowledge of the user
https://developer.mozilla.org/en-US/docs/Web/Secur...
https://developer.mozilla.org/ en-US/docs/Web/HTML/...

A
Alexander Litvinenko, 2017-12-11
@edli007

After compiling with webpack, the code will be reversed by an order of magnitude better than obfuscation, you just need to use non-standard webpack configs and disable source maps for production

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question