i saw this piece of code in an obfuscated javascript :
if(1s Q.is.ep=='a')
do you have any idea what this might mean? Im quite confused about the space..
thanks :)
The code looks like generated by Dean Edwards' packer (or another similar one). You could unpack it with this tool.
It's indeed JavaScript, however replaced keywords, method, variables with meaningless strings. The bottom half of the file you provided is actually a mapper between obscured and original.
And this, it the power of eval (and don't use eval if by all means you could do without it).
Related
I know about JS minfiers, obfuscators and minifiers. I was wondering if there is any existing tool (or any fast-to-code solution) to partially obfuscate JavaScript. By partially I mean that it should become difficult to read, but not appear as uglified/minified. It should keep indentation, but lose comments, and partially change variable names, making them unclear without converting them to "a, b, c" like an obfuscator.
The purpose of this could be to take an explicit and reusable code and make it implicit and difficult to be reused by other people, without making it impossible to work with for yourself.
Any idea from where to start to achieve this ? Maybe editing an existing obfuscator ?
[This answer is a direct response to OP's request].
Semantic Designs JavaScript obfuscator will do what you want, but you'll need two passes.
On the first pass, run it as obfuscator; it will rename identifiers (although you can control how much or how that is done), strip whitepspace and comments. If you limit its ability to rename the identifiers, you lose some the strength of the obfuscator but that's your choice.
On the second pass, run it as a prettyprinter; it will introduce nice indentation again.
(In fact, the idea for obfsucation came from building a prettyprinter; if you can print-pretty, surely it is easy to print-ugly).
From the point of view of working with the code, you are better off working with your master copy any way you like, complete with your indentation and nice commentary as documentation. When you are ready to obfsucate, you run the obfuscator, shipping the obfuscated result. Errors reported in the obfuscated result that involve obfuscated names can be mapped back to the original names, using the map of obfuscated <--> original names produced during the obfuscation step.
This a product of my company. I'd provide a link but SO hates it when I do that, so you'll have to find it via my bio or googling.
PS: It works exactly as #georg suggests, by parsing to an AST, mangling, and prettyprinting. It doesn't use esprima.
I'm not aware of a tool that would meet your specific requirements, but it seems to be relatively easy to create, given that the vital parts already exist.
parse the source into an AST, using esprima or similar
manipulate the tree in the way you want (eg. remove comments, mangle identifiers etc)
rebuild the source from the tree using escodegen
I came to know that "obscure" the code - make it less readable, but will still execute.
It replaces symbol names with non-meaningful one
Replaces numeric constants with expressions
Replaces characters in strings with their hex escapes
So If we Obfuscate the Code , then if something goes wrong in production & how we can fix it ?
If we want to do modification how we can go around with it?
You fix the problem in the original code and then run it through the obfuscater again.
You do not debug with obfuscated code. You should turn off the obfuscation on development environments, since it is only needed for production.
Quentin has it right: don't throw away the original source, and then you can debug the problem there. (Likewise for "modifications" to the code).
A bit trickier is, how do you diagnose the problem, when it occurs while running the obfuscated version? I don't know how others do this. However, our tools provide an invertible mapping from the original source to the obfuscated version as an additional output from the obfuscation process. When a problem is found in the running code, if the obfuscated identifiers "nearby" the problem (e.g., in the offending statement/function/... or in a crash call backtrace) can be captured, the inverse map can be used to produce corresponding unobfuscated identifiers, which can then be used to locate the offending construct in the original source code.
While I of course agree with the above posters, they're kind of negating the question, not answering it.
Anyway, if you use Chrome, you can open the dev tools ( Right click anywhere>inspect element> sources tab). Find the obfuscated code on the file explorer on the left, then click the two curly braces on the bottom.
Once you do that, the variable names are still obfuscated, but at least it's formatted properly. This is extremely useful for when you're worried that the minification process itself is breaking something.
1:{key:value}["key"]
2:({key:value})["key"]
I'm wondering how the JS interpreter works on the above codes, and why 1 doesn't work and why 2 works?
I assume you are asking the question because you saw this effect in a JavaScript REPL (shell). You are using a JavaScript shell which assumes the leading "{" begins a block statement instead of an object literal.
For example, if you use the JavaScript interpreter that comes with the Chrome browser, you see the following:
> {key:"value"}["key"]
["key"]
Here, Chrome saw what you entered as a block statement, followed by the expression that was an array of one element, the string "key". So it responded with the result of that expression, namely the array ["key"]
But not all shells work this way. If you use the interpreter with node.js, then #1 will work for you!
$ node
> {key:"value"}["key"]
'value'
>
In interpreters like Chrome, you have to use parentheses to tell it that you want the first part to be an object literal. (This technique, by the way, is guaranteed to work in all shells, including node's).
EDIT
As pointed out in one of the comments, if you use that construct in an expression context anywhere in an actual script, it will produce "value". It's the use in the shell that looks confusing.
This fact was actually exploited in the famous WAT video by Gary Bernhardt.
I want to extract javasscript code and find out if there are any dynamic tag creations like document.createElement('script'); I have tried to do this with Regular expressions but using regular expressions restricts me to get only some formats so i thought of writing a javascript parser which extracts all the keywords, strings and functions from the javascript code.
In general there is no way to know if a given line of code will ever run, you would need to solve the halting problem.
If you restrict your analysis to just finding occurances of a function call you don't make much progress. Naive methods will still be easy to trick, if you just regex match for document.createElement, you would not be able to match something as simple as document["create" + "Element"]. In general you would need to not only parse the code but evaluate it as well to get around this. And to be sure that you can evaluate the code you would again need to solve the halting problem.
Maybe you should try using Burrito
Well the first rule is never use regex for big things like this, or DOM, or ... . You have to parse it by tokens. The good news is that you don't have to write your own. There are a few JS to JS parsers.
UglifyJS
narcissus
Esprima
ZeParser
They may be a bit hard to work with it. But well better to work with them. There are other projects that are uses these such as burrito or code surgeon. So you can have a look at the source code and see how they uses them.
But there is bad news too, which people can still outsmart other people, let alone the parsers and the code they write. At least you need to evaluate the code with some execution time variables and see if it tries to access the DOM or not.
There are many tools to compress a Javascript file (Packer YUI for example).
But how can I decompress them back to a human readable format?
I have compressed a file using a tool like Packer YUI , but I couldn't reach the source back again.
Is there any good software or tricks you can suggest to decompress the JS ?
You can't. Javascript compression is usually a lossy one, and the information is lost forever.
What you can do, is use a source formatter and a good refactoring tool and -- painfully -- reconstruct the original source. Even if you are not familiar with the code it should be possible; Jeff and a few others reverse engineered the WMD javascript code from a minified version.
Finally, you should consider using a version control system and proper backups to keep your source code safe.
This website is really cool. You can paste a minified JS, then you get a human readable view.
Try JSMinNpp (now called JSToolNpp) plugin for notepad++ (to compress and decompress).
http://www.sunjw.us/jstoolnpp/
DECOMPRESS JAVASCRIPT
A typical JavaScript compressed with /packer/ starts with the following code:
`eval(function(p,a,c,k,e,r)`…
`eval` can simply be replaced by alert.
The eval function evaluates a string argument that contains JavaScript. In most packers, eval is used, followed by document.write.
To decompress JavaScript, replace these methods by one of the following:
1. Replace eval by alert (The alert will simply print the code in a popup-window)
2. If the JavaScript appears after the <body> element, you can add a <textarea> like so:
`<textarea id="code"></textarea>`
Then, replace eval(…); by document.getElementById("code").value=…;.
A linter like ESLint can be handy as well. It can format the code using the "fix all auto-fixable problems" to a point where you can at least start doing manual editing with greater ease.
I never used Packer YUI. But if you use this javascript packer, you can always get your code back using this javascript beautifier which also decompresses the code.
Some javascipt minifier shorten the variable names while compressing the js. In that case you could never get your original code back even if you beautify it.