Comments 14
UFO just landed and posted this here
К сожалению prepack там только хуже делает. Удаляет большую часть кода так-как считает её недостижимой, выносит все функции из словаря отдельными функциями (и оставляет словарь), не собирает даже те строки, которые не выкинул и оставляет часть тернарных операторов. Идея у них хорошая, но с таким вот кошмаром пока не работает.
0
Удивляюсь упорству автора.
Нужно было просто посмотреть на решения типа JavaScript Deobfuscator для Firefox.
Нужно было просто посмотреть на решения типа JavaScript Deobfuscator для Firefox.
0
Например, запретить onload/onerror для скриптов на сайтах с подобной дрянью, переопределив пустым сеттером, добавить zfgloadedpopup === true и, по желанию, сломать геттер у свойства 'content' стилей.
Это как?
Написать расширение для браузера, которое будет инжектить в head страницы скрипт реализующий всё вышеперечисленное и выполняющийся до вызова скрипта с рекламой?
Btw, jsnice не нужен, можно сделать pretty print прямо в Chrome DevTools.
0
> Написать расширение для браузера, которое будет инжектить в head страницы скрипт реализующий всё вышеперечисленное и выполняющийся до вызова скрипта с рекламой?
Да, именно так. Правда писать само расширение не нужно — достаточно скрипта для Tampermonkey/Violentmonkey с "@run-at document-start" в заголовке.
Я вот такой кошмар поддерживаю, например: greasyfork.org/en/scripts/19993-ru-adlist-js-fixes
> Btw, jsnice не нужен, можно сделать pretty print прямо в Chrome DevTools.
Мне просто этого зверька прислали в виде текста. На сайте я эту дрянь потом очень долго отлавливал. Там на рандоме то ничего не выпадает, то другой скрипт вылезает с банальным eval(function(p,a,c,k,e,d), в котором интересным является лишь то, как они открывают попап в Хроме. А этот вот довольно редко.
Кстати, разве DevTools приводит числа в разных формах записи к десятичной системе?
Да, именно так. Правда писать само расширение не нужно — достаточно скрипта для Tampermonkey/Violentmonkey с "@run-at document-start" в заголовке.
Я вот такой кошмар поддерживаю, например: greasyfork.org/en/scripts/19993-ru-adlist-js-fixes
> Btw, jsnice не нужен, можно сделать pretty print прямо в Chrome DevTools.
Мне просто этого зверька прислали в виде текста. На сайте я эту дрянь потом очень долго отлавливал. Там на рандоме то ничего не выпадает, то другой скрипт вылезает с банальным eval(function(p,a,c,k,e,d), в котором интересным является лишь то, как они открывают попап в Хроме. А этот вот довольно редко.
Кстати, разве DevTools приводит числа в разных формах записи к десятичной системе?
0
Это было трудно, но про внешний вид пациента прочитал до конца :)
+1
Может я сейчас фигню сморожу, но что мешает выполнить в консоли этот код, но не в eval(), а в log? Браузер по идее должен деобфусцировать и нормальный код выдать.
0
Попробуй. :)
Для начала там нет eval, который можно было бы заменить. Это, конечно, классный способ развернуть недоразумение вроде «eval(function(p,a,c,k,e,d){...}(...));» — некоторые «разработчики» до сих пор думают, что такое сжатие усложняет понимание их кода, но в данном случае код скрипта изначально исполним в браузере и не проходит предварительную обработку. Браузеру ведь без разницы будет ли у тебя умножение записано как let c = a * b; или как let z = {m1f:(x,y)=>x*y}; let c = z.m1f(a,b); Результат в обоих случаях тот же. Во втором случае просто больше лишних действий.
Там есть два блока кода в текстовой форме: скрипт в две команды закодированный в data:url и используемый для перехода на другую страницу при открытии оного в новом окне, и скрипт, спрятанный в стиле. Последний действительно можно выцепить при желании через код, но поди ж пойми что он там вообще есть не разобрав для начала этот вот.
Для начала там нет eval, который можно было бы заменить. Это, конечно, классный способ развернуть недоразумение вроде «eval(function(p,a,c,k,e,d){...}(...));» — некоторые «разработчики» до сих пор думают, что такое сжатие усложняет понимание их кода, но в данном случае код скрипта изначально исполним в браузере и не проходит предварительную обработку. Браузеру ведь без разницы будет ли у тебя умножение записано как let c = a * b; или как let z = {m1f:(x,y)=>x*y}; let c = z.m1f(a,b); Результат в обоих случаях тот же. Во втором случае просто больше лишних действий.
Там есть два блока кода в текстовой форме: скрипт в две команды закодированный в data:url и используемый для перехода на другую страницу при открытии оного в новом окне, и скрипт, спрятанный в стиле. Последний действительно можно выцепить при желании через код, но поди ж пойми что он там вообще есть не разобрав для начала этот вот.
+1
Есть ряд методов обфускации, которые полностью «парализуют» такой подход к обфускации регэкспами. Например, переименование переменных глобально и использование большого кол-ва дубликатов. Тут надо будет следить за областью видимости переменных.
Около года назад я столкнулся с похожей задачкой (тоже, к стати, скрипт всплывающего окна) и вот там как раз подобные методы не сработали.
Но я нашел очень мощный набор инструментов: github.com/estools
Подход такой: разбираем жс-код в дерево, прогоняем по нему разные методы деобфускации, результат опять генерим в жс-код. Первое и последние — не проблема, а вот сами методы было не просто реализовать и особенно там, где нужно учитывать области видимости. Но в итоге получилось и код оказался прям хорошо читаемым, только названия переменных подводили. Но их уже в нормальных IDE можно удобно править в процессе вникания в код.
Вот примеры методов, которые деобфусцируют то, что у вас под номером 4:
Около года назад я столкнулся с похожей задачкой (тоже, к стати, скрипт всплывающего окна) и вот там как раз подобные методы не сработали.
Но я нашел очень мощный набор инструментов: github.com/estools
Подход такой: разбираем жс-код в дерево, прогоняем по нему разные методы деобфускации, результат опять генерим в жс-код. Первое и последние — не проблема, а вот сами методы было не просто реализовать и особенно там, где нужно учитывать области видимости. Но в итоге получилось и код оказался прям хорошо читаемым, только названия переменных подводили. Но их уже в нормальных IDE можно удобно править в процессе вникания в код.
Вот примеры методов, которые деобфусцируют то, что у вас под номером 4:
var estraverse = require('estraverse');
(function() {
module.exports = function (ast){
var count = 0;
estraverse.replace(ast, {
enter: function(n, p){
if(n.type == 'ConditionalExpression' &&
n.test.type == 'BinaryExpression' &&
n.test.left.type == 'Literal' &&
n.test.right.type == 'Literal'){
count++;
var l = n.test.left.value;
var r = n.test.right.value;
var test;
switch(n.test.operator){
case '>': test = l > r; break;
case '>=': test = l >= r; break;
case '<': test = l < r; break;
case '<=': test = l <= r; break;
}
return test ? n.consequent : n.alternate;
}
return n;
}
});
return count;
};
}());
var estraverse = require('estraverse');
(function() {
module.exports = function (ast){
estraverse.replace(ast, {
enter: function(n, p){
if(n.type == 'SequenceExpression' && n.expressions.length == 2){
return n.expressions[1];
}
return n;
}
});
};
}());
0
lisperator.net/uglifyjs
откройте тут онлайн-демку, включите compress,mangle,beautify и получите уже достаточно читаемый результат.
Но вообще, этот обфускатор добавляет много левого кода и иногда использует антиотладочные приемы, так что анализировать существенный объем кода, который через него пропущен, будет не сильно эффективно.
Лучше добиться того, чтобы он нормально запустился после Uglify (выкосить антиотладочные куски) и использовать console.log/trace в
И да, не думаю, что тут получится задать пустой сеттер, учитывая, что onload прямо в html прописан. Да и внутри обсусцированного скрипта есть дополнительные проверки того, загружен скрипт или нет. А такие проверки обойти будет очень и очень сложно. Уж лучше попытаться какой-то document.write переопределить или window.open.
откройте тут онлайн-демку, включите compress,mangle,beautify и получите уже достаточно читаемый результат.
Но вообще, этот обфускатор добавляет много левого кода и иногда использует антиотладочные приемы, так что анализировать существенный объем кода, который через него пропущен, будет не сильно эффективно.
Лучше добиться того, чтобы он нормально запустился после Uglify (выкосить антиотладочные куски) и использовать console.log/trace в
подозрительных участках вроде
X.document.write(decodeURIComponent(M) + (nn + F + Sn + Ln + nn + yt + Ln + Vn + z + R + S + vn + L + pn + H + Jn + Dn + Fn + E + Ln + Qn + Fn + Cn + Rn + Qn + vn + W + Ln + vn + P + nn + F + Sn + T + yt + pn + N + G + Ln + vn + yt + Bn + Dn + Vn + pn + _n + w + k) + m.href + y + decodeURIComponent(b + O + g + b + Z + v + p + I3x.Y2h + b + O + s + b + O + g + b + Z + A + C + x + b + O + s + b + O + g + l + d + b + O + s + b + O + g + b + Z + A + jn + a + f + b + O + s + b + O + g + b + Z + u + b + O + s))
И да, не думаю, что тут получится задать пустой сеттер, учитывая, что onload прямо в html прописан. Да и внутри обсусцированного скрипта есть дополнительные проверки того, загружен скрипт или нет. А такие проверки обойти будет очень и очень сложно. Уж лучше попытаться какой-то document.write переопределить или window.open.
0
Вообще да, сеттер на onload/onerror для основного скрипта не поможет. Просто они там в случае ошибки сначала создают ещё один и вот на нём уже сработает. Правда если его адблок не заблокирует, то тут уже без разницы сработает onload на нём или нет, наверное. В JS Fixes я там и window.open переопределил, да.
0
Sign up to leave a comment.
Деобфускация одного скрипта с попапами