Jscrambler transformations: what you can expect from Rename Local
September 30th, 2014 | By Filipe Silva | 4 min read
If you do not know what to expect from Rename Local, let us explain everything. Jscrambler transformations, or our renaming source code transformations, replace identifier names with meaningless ones.
There is a reason why many organizations set coding conventions around naming variables and function names: they are extremely helpful in understanding more quickly what a program does. So it seems intuitive that by destroying any meaning those identifiers hold, you will get much harder-to-read and more confusing code. This is perfect if you seek a trustworthy service to obfuscate your JavaScript source code.
Since the volatility of the identifier names is unnecessary for the JavaScript engine to run your program, renaming them will not impact the code's functionality.
Even if you are not seeking to protect the code, renaming is a good step because it makes identifiers as small as possible, thus contributing to the minification of the code.
Rename Local source code transformations
"Rename All" and other source code transformations that create or change names are not covered here. Rename Local only targets identifiers belonging to variables, functions, or objects declared locally. This means that identifiers that are accessible publicly or that we cannot find the declaration to which they belong are not renamed.
By working this way, Rename Local transformations is the safest choice when you want to replace the names of your source code without worrying about other JavaScripts that yours might depend on.
Rename Local figures out what it should rename automatically
In Figure 1, you can see a simple example where only local declarations and their calls have been renamed, and public or native names have not been touched.
(function(global) {
var logMessage = function(message) {
global.console.log(message)
}
logMessage("Rename Local example");
})(window)
Figure 1a: Source code
(function(b) {
var c = function(a) {
b.console.log(a);
};
c("Rename Local example");
})(window);
Figure 1b: After Rename Local
Jscrambler does not maintain a (black) list of names like window, console, and log that it should not rename. And because it does not need to. For each local declaration, Jscrambler seeks their respective calls on the reachable local scope(s). If it does not find any, then it does not touch them.
Rename Locals reuse names as much as possible
Another interesting detail about Jscrambler renaming is that it tries, whenever possible, to reuse names.
That benefits both protection and minification purposes:
For the former, it generates additional confusion because you see names repeated in different parts of the code.
For the latter, it reduces the number of characters needed for names, reducing the overall size of the code.
As you can see in Figure 2, the parameter names a and b are reused on both functions.
function drawCanvas(width, height) {
// ...
}
function move(toPosition, effect) {
// ...
}
Figure 2a: Source code
function c(a, b) {
// ...
}
function d(a, b) {
// ...
}
Figure 2b: After Rename Local
Rename Local picks up identifiers inside evaluated code strings
Rename Local also targets names inside string arguments evaluated by functions like eval, setTimeout, and setInterval. Otherwise, the code could break due to unmatched references.
(function() {
var three = 3;
var doSomethingAmazing = function(condition) {
var res;
if (condition) {
res = three;
} else {
res = three * 10;
}
console.log(res);
}
var doTheSameWithEval = function(condition) {
var res;
eval("if ( condition ) { res = three; } else { res = three*10; }");
console.log(res);
}
doSomethingAmazing(true); // prints 3
doTheSameWithEval(false); // prints 30
})()
Figure 3a: Source Code
(function() {
var b = 3;
var d = function(c) {
var a;
if (c) {
a = b;
} else {
a = b * 10;
}
console.log(a);
};
var e = function(c) {
var a;
eval("if(c){a=b;}else{a=b*10;}");
console.log(a);
};
d(true); // prints 3
e(false); // prints 30
})();
Figure 3b: After Rename Local
Limits of what you can do statically
However, there are cases where it can fail, mostly when it can’t figure out statically the link between declarations and their respective calls.
In Figure 4, you can see a case where using Rename Local breaks the code by renaming the hello variable to b.
(function() {
var hello = 'Hello world!';
var foo = 'hello';
return eval(foo);
})();
// returns "Hello world!"
Figure 4a: Source Code
(function() {
var b = 'Hello world!';
var a = 'hello';
return eval(a);
})();
// throws ReferenceError: hello is not defined
Figure 4b: After Rename Local
With a little help from my friends
In the previous example (Figure 4b), you can fix it by adding the hello variable to the Exceptions List. The result would be:
(function() {
var hello = 'Hello world!';
var a = 'hello';
return eval(a);
})();
// returns "Hello world!"
Figure 5: After Rename Local + Exception List (hello)
It’s important to understand that other transformations may impact whether Rename Local ultimately breaks the code or not. For instance, if we had used Constant Propagation transformation, it would have been applied before renaming. It would replace variable foo by the string ‘hello', and ‘hello' by ‘Hello world'.
Rename Local would then come into action, but it basically wouldn’t have anything to work with (to rename), as you can see in Figure 6.
(function() {
var hello = 'Hello world!';
return eval('hello');
})();
Figure 6a: After Constant Propagation (1)
(function() {
return eval('Hello world!');
})();
Figure 6b: After Constant Propagation (2)
Rename Local utility
In conclusion, Rename Local was developed by Jscrambler to be safe and to work out of the box as much as it is technically possible with JavaScript.
On the few occasions where Jscrambler is not matching all the occurrences of a name, you may add that name to the Exceptions List, and that identifier name won’t be touched. Problem solved.
Jscrambler
The leader in client-side Web security. With Jscrambler, JavaScript applications become self-defensive and capable of detecting and blocking client-side attacks like Magecart.
View All ArticlesMust read next
Working with Angular Local Storage
In this article, we'll discuss local storage and its usage from an Angular application's perspective. Let's start by trying to understand what Angular local storage is.
April 8, 2022 | By Jay Raj | 5 min read
Enterprise JavaScript Security [INFOGRAPHIC]
JavaScript is the powerhouse of enterprise apps, but it can be targeted by attackers who seek to steal the code or user data. Here's how to counter this.
November 18, 2020 | By Jscrambler | 1 min read