Вбивал я тихонько дорки в яд, никого не трогал. И тут хуяк.. Капча!

Капчи средь бело дня это ужос.

И как же меня она уже заебала.. Я часто юзаю яд в инкогнито, а там она вылезает постоянно.

Чё по капче?

Я уже несколько раз разбирал Яндекс капчу на канале, но в последний не затащил. И вот почему:

Сначала у яда был просто фингер и xor по ключу, который прилетал с сервера.

Позднее они добавили обфускацию, ключевое слово уже генерилось каким-то гига массивом в кучей сдвигов. Тоесть хуй поймешь как оно кастует ключ. Только вот массив при каждой загрузке кода капчи был разный.

Довольно долго ручками пытался деобфусцировать то, что по факту, как оказалось, является динамической хуйней (примерно как у твиттера).

Тоесть шифрование (енкод) в каждом файле новое, новые цифры в циклах, как и их количество. Забегая вперед скажу, что итогу я порешал, его нужно целиком из файла пиздить, но об этом чуточку позже)

С появлением сурсов самой капчи (взлома яндекса), имея открытый список большей части проверок, выебать их теперь не составит большого труда. Похуярили!

Подготовка

Проведем поверхностный прочек, чтобы просто понимать чё куда.

В запросе много всяких параметров, но самый интересный, имхо, фингер. Поэтому разберемся с ним.

Как я уже сказал, сурсы яда были слиты.

Чего там есть интересного?

Ну например то, как устроен антифрод на этой капче. С всякими схемами и пояснениями, всей внутрянкой и документацией. В чатике мы это когда-то уже обсуждали.

Даже код генерации текстовой капчи был, со списком блек слов.

Сурсы капчи

Но меня больше интересовали сурсы Yandex SmartCaptcha, потому перейдем сразу к ним. И как же дохуя там всяких папок, версий, инструкций..

Берем просто какую-то демку и чекаем с небольшим допилом..

Фингер собирается, отлишна.

Инициатор сбора одна из этих функций. Делают они примерно одно и то же.

Судя по сурсам, у нас просто есть куча функций фингера. При вызове мы дергаем каждую и результаты сейвим в жсончег. Подход довольно базированный. i6 я докинул от себя, про это будет в конце.

А вот и сами функции под каждый параметр фингера. Зная что собирают, не трудно потом это подменить.

Без обфускаиции все так хорошо читается. Удобно иметь ориг сурсы)

На самом деле, как таковой необходимости в сурсах прям небыло, это чисто интерес почитать как оно там в проде. По факту, тут те же самые сурсы, что и раньше на дзене или яндексе, прост обфускации докинули и новый енкод, что меняет примерно ничего. Сурсы это просто приятный бонус.

Продакшн

Раз все примерно ясно, потыкаем её в проде, хоть и на демо страничке.

В проде они вызывают сбор фингера через window.PGreed.safeGet()

С капчей на поиске всё также. После получения значения мы его ксорим с миксованным массивом. В целом, с фингером все ясно, нужно только придумать че делать с этим массивом ебучим.

Хорошо, чё делать теперь примерно ясно. Будем собирать по чуть-чуть скрипт для решения. А начнем с чего-то простого, с хедера picasso.

Енкод у всех заголовков обычный base64, кроме фингера. И по названию параметров не сложно найти сами функции и докинуть брек. Единственное, входной параметр тут какой-то seed.

Оказалось, це простой рандомчег. Тоест 2 рандом числа от 1 до 1000.

А потом на оба массива вызывают асинхронную функцию для рисования канваса (как не трудно заметить). Функция на самом деле довольно небольшая и относительно простая. Удобно, что в этом файле 0 обфускации.

Мне показалось, что я увидел что-то знакомое, поэтому я просто вбил в поиск по гиту.

Да, это же мой любимый мур мур хэш) Тот самый хэш, который юзается в популярной либе сбора фингера fingerprintjs, а потому есть на куче сайтов и в множестве всяких защит (фанкапча, яху и тд).

Если внимательно сравнить, то коду буквально оно.

Оки, еще у нас есть вот это.

Это функция псевдо рандома.

На гите была ровно та же хуйня с подписью рандом. Так шо еще раз Github +1.

Ещё были функции: So, xo, ko, Oo. Они рисуют на канвасе, но мне уже как-то похуй, просто копировать вставить и фсе, канвас же.

Акей, получаем вот такой код. Зачекаем его валид.

Хешик в яде.

Хешик в моём коде. Ну и они совпадают, что не удивительно. Значит, эту штуку я разъебал.

Вообще, рисуют они вот такую ебень, если кому интересно.

Если представить, что уник канвасов в мире 156 078, отталкиваясь от canvas, получается, им нужно хранить 156 078 000 канвасов на 1 фильтр, а фильтра у них 2 (2 разных настройки рисовалки канваса). Вряд ли они столько хранят.

Закономерно предположить, что можно было бы пихать и рандом, но мне показалось удобным просто сделать по 1к канвасиков (на каждый фильтр) на свое железо и тянуть рандомно.

По итогу это выглядит вот так.

Перейдем к следующей хуйне, к pov pow.

Как обычно, имеем powPrefix и powComplexity. Тоесть ключ и сложность.

Они передаются в отдельную функцию.

И эта функция - воркер.

Ну оки, дернем че за код и зачекаем его.

Применим убийственный примём из серии серьезных - серьезный поиск по гитхабу.

Github vs Yandex: 3:0

Это буквально, самый дефолтный пов. В текстовик я закинул отформатированный код воркера. Код совпадает с решалкой в сурсах с гита.

Ну типа ставим либу и фсе. Отличия в том, что яндекс к коду либы пару строк от себя наговнял для удобства.

В итоге я форматнул под вид яда. Ну и этот хедер тож выебан, получается.

Ебём дальше.

В процессе тестов, на демо страничке столкнулся с новой капчей. Я её чуть потыкал, в целом разобрался как оно работает, но решил забить, тк кроме демки её ни где больше нету.

Ладно, пока я писал эту хуйню, она появилась на яндексе.

Ну и..

И так, а теперь всё-таки разберется с самым интересным, с фингером, в котором хуева туча мелких параметров.

У нас есть динамический кусок хуйни для енкода.

Тоесть идет сбор фингера и его енкод.

Если спиздить енкод, шифрануть самому, то будет такая же хуйня. Ладно, надо подумать как фул код енкода подрезать.

Также, в фингере помимо обычных есть еще парочку значений:

pgrd - ключ версии файла?

pgrdt - тайм штамп времени сбора фингера

pgrd всегда есть где-то в файле. Над будет придумать как его спиздить.

Я решил сравнить фингер собранный с демки и "самодельный".

Отличается только одна хуйня функция i6.

По имени зачекаем чего она делает.

Видим сам код. Else никогда не сработает, поэтому сразу чекаем наши 3 строчки.

Если потыкать чуть ручками код, становится очевидно, что он чекает Performance. memory. Видимо, просто проверяет наличие этих функций.

Сравним фингеры

Штош, тогда обновим код, а потом сравним значения фингера с сайта и с сборщика.

Тк мне лень глазками все это чекать, добавил вывод тех что отличаются.

Подчеркнул, чтоб было проще ориентироваться.

Старый скрипт яда скипает d1 и c9, новый отсутствие значения сейвит как null.

a8 пихает в боди рекламный блок. Думаю, похуй на а8)

c7 чекает возможность установки куки. Тк у меня не сервер, ясен хуй оно не работает.

x,y чисто ошибки таймаута в асинхроне, скорее всего из за бреков, тк фингер с сайта стянул криво.

В фингере есть 2 хэша: z1 и z2.

z1 хэш от шрифтов, в проде совпадает с моим.

А вот z2 мой ему поему-то не нравился. Ну а это какбэ канвас.

Чуть потыкав код я понял, что наебался вот с этой строкой.

В норм виде тут смайлики должны быть.

Но в файле ведь у меня все правильно было.. А не работало потому, что я не указал кодировку у своей демо html странички. Кароч, фикс и все воркает как надо.

С фингером в целом разобрались, ебошим дальше.

Для капчи у нас целых 3 заголовка:

rep - координаты ответов.

tsdata - тайминги ответов.

tdata - инфа о кликах по экрану относительно старт тайминга и позиции относительно фул экрана. Кароч, чисто для статки инфа. pointerPositions и clickPositions на мобилке одинаковые.

Не сложно заметить, что rep действительно инфа об ответах.

А тут видно, как формируется статка по кликам.

Сравним первый поинт и ответ. Разница 28. Шаг от края экрана до картинки у нас тоже 28.

Ну раз тут все ясно, можно накидать простой код для генерации всей даты. Я кастую от момента запуска генератора до минус сколько то секунд (на каждый клик), а потом разворачиваю тайминги типо я гадал в риалтайм.

Помимо очевидного, тут используется ахуительная функция, чтобы слить массивы в 1, упомянутая ранее в материале про перевочики. Array.prototype.slice.call(arguments)

Фингер

Сначала порешаем до конца с фингером. Я искал наиболее простой путь, поэтому мне не хотелось писать деобфускацию.

В процессе заметил, что по дефолту у скрипта все функции сбора фингера сейвятся в глобальную переменную.

Поэтому я решил просто взять и запихать туда фингер с функцией оберткой, которая превратит ключи в функции. И это сработало в браузере, а потом и в бас ноде.

В итоге получился вот такой код, который полностью работал.

Капча

Дальше я пытался сделать решалку под яд, по аналогии с гитестом, но выходило говнище, ебучие иконки хуй выдернешь.

Фильтр по белому помогал только в 10% случаев и в итоге валид решение получалось примерно 1 из 100.

Поэтому я сделал форматирование картинки и выбрал сервис с ручными индусами.

Ресайз.

Не так конечно круто, как без сервисов, но зато решалось.

Соберем все вместе

Запрашиваем капчу.

Через eval сейвим данные капчи в переменную.

Так как у яда на самом деле просто при клике на иконку тоже шлет фул данные (установка чекбокса тоже типо капча), добавляю проверку нужно ли решать капчу. Тоесть pow в любом случае нам надо будет проходить 2 раза.

И так, если капча есть, решаем её и чекаем, что мы его точно получили.

Независимо от капчи шифруем фингер, кастуем pow и picasso. Если капчи небыло, то шлем пустой tdata, как это было и у яд в запросах.

Если капча была решена, шлем запрос с её хэдерами.

Идем чекать.

И.. в итоге все работает.

В случае верного решения также вертаем куку spravka.

Проведем малюсенький тест)

Выебано.

Это было слишком просто..

Лан, я решил её добить, тк получилось всё слишком легко, но капча не без сервисов. Напоминаю https://captcha-api.yandex.ru/demo

И так, не трудно заметить, что в качестве данных решения всегда передается положение.

Ну, это и так на самом деле видно. Крайнее правое положение 13, а начальное 0.

При каждом движении слайдера капча перерисовывается и надо бы найти как и почему она это делает. Заранее стоит пояснить, что капча прилетает вот в таком виде. Судя по всему, таск это порядок перемешивания картинок в каком-то уебанском виде.

Ну акей, я поставил брек на модификации поддерева, чуть потыкал и попал сюды.

Чуть ниже мы видим код перерисовки. Синее - сама перерисовка. А вот зеленое, то что нам нужно, это выполнение функции v, начало которой я подчеркнул красной линией. В неё мы передаем наш массив task (параметр t) и шаг на слайдере, чтобы получить порядок картинок в норм виде, нарезать их и перемиксовать. Параметр e в функции это просто массив размера 9 элементов (3 на 3), тоесть 0-8. Выглядит непривычно, но на деле код не страшный.

Для красоты я поставил логпоинт и в процессе двигания слайда было видно как оно просчитывает переменную v. Правильным решением было 4. Как видно по решенной капче, кусочки стоят в порядке, соответствующем цифрам кусочков с ориг капчи.

Я спиздил функцию, убрал чуть мусора, который нихуя не делал, и получил тот же результат, тот же порядок при указанной позиции слайдера.

Хорошо, раз с этим ясно, нужно разобраться с самим решением. Для начала просто нарежем капчу на кусочки.

Смешная нарезка яндыкса работаит.

Если разрезать картинку на 2 части, то пиксельная линия в месте разреза на обоих картинках будет иметь на 99% схожий рисунок. Как уже говорил в материале по тиктоку, я подсмотрел эту идею когда-то туть. Картинок у нас много, разрезов может быть 4, поэтому докинем к прошлому скрипту пару блоков. По итогу нарезки теперь у нас будет 9 массивов в каждом по 4 картинки (края стороны).

Ну а теперь их нужно как-то сравнить. Очевидно, что верх одной мы можем соединить только с низом другой и наоборот, также и со сторонами. Код я взял из материала по iconcaptcha, чуть перенес циклы и добавил выходы из цикла в соответствии с условиями выше.

Потом чуть допилил код, добавив кастом порог для приемлемой степени совпадения.

Акей, оно решает и получает ровно то что я ожидаю. Теперь у нас есть каждый кусочек пазла и мы знаем его соседей. Нужно понять как превратить это в собранный пазл и желательно без хардкода.

Я пришел к следующей мысли: берем и дергаем левый верхний угол и идем от него сначала влево получая каждый элемент, а потом от него же спускаемся вниз и опять собираем все левые, так повторяем до конца.

А потом закодил это. Вроде всё работает как надо, результат тот же.

Так это выглядит по итогу в бас

Остается только найти на какой позиции слайдера при входных данных будет давать такой порядок. Ну эт изи, грубый перебор, всего ведь 12 вариантов положения. Изе. Не забываем учесть проёб если оно какого-то хуя не нашло решения.

Для удобства я также сделал рисовалку. Делал на основе нарезки, докинул только перестановку по небольшому набору правил.

Сделал скрипт аналогичный тому что в прошлой капче. Тут разве что picasso отсутствует.

Ну и запрос типа text/plain;charset=UTF-8.

Поэтому енкод тела сделать пришлось лапками.

Решалку перенес из тестового скрипта, заодно пару мелочей пофиксил, чтобы ошибки давало если не решило.

На тестах всё ебошит по красоте.

Забавно, что у яда картинки повторяются. Зная этот факт можно сделать решалку сильно пизже по качеству. Тоесть ищем фон по базе, потом режем его и чекаем пару.

Да, звучит неплохо, мож когда-то сделаю(нет).

Есть основания полагать, что яд юзает нейронку. Нинаю, це байт на классы или чисто прикол, при том что фоны повторяются..

В целом, на 100 тестах качество решалки картинок вышло примерно 80%. Результат неплохой, но если есть база картинок, будет точно сильно лучше.

Эта капча была уже чуток интереснее. Но у неё даже обфускации небыло.

В оффтоп чатике опять предлагали потыкать чет интересное и скинули funcaptcha.

Я решил чекнуть на примере гита.

Начало положено. Когда есть точка входа, дальше все идет на много проще.

Я где-то близко.

А вот опять цикл c перебором фингера и шифрованием. Как у qrator.

Тоесть по итогу получаем вот такую красоту с шифрованным фингером

Они действительно чекают движение мыши, забавно

https://www.arkoselabs.com/explained/behavioral-biometrics/

Ну вот и всё, вот наше шифрование.

Согласны, узнали? это же дефолт crypto AES-CBC

Что примечательно, сам ключ et (строка 10654), эт хэш от ua+h, где h по итогу мы передаем как s.

А запрос мы и шлем какбэ с нашим юа, вот такая вот защит очка. Но сам алго пришлось чуть потыкать.

Что забавно, Ar прост кастом массив с парой дефолт чисел

А hashBinary вот так просто md5. По итогу имеем

function md5ToEnc(t) {
var e, n = [],
r = t.length;
for (e = 0; e < r - 1; e += 2)
n.push(parseInt(t.substr(e, 2), 16));
return String.fromCharCode.apply(String, n)
}
hashBinary = function (t, e) {
var n = md5(t);
return e ? md5ToEnc(n) : n
}
zr = function (t, e) {
var i = t + function (t) {
for (var n, c = t.length, u = "", s = 0; c > 1;)
e = t.charAt(s++).charCodeAt(0),
n = t.charAt(s++).charCodeAt(0),
u += String.fromCharCode((Ar[e] << 4) + Ar[n]),
c -= 2;
return u
}(e),
a = [];
a[0] = hashBinary(i, !0);
for (var c = a[0], u = 1; u < 3; u++)
a[u] = hashBinary(a[u - 1] + i, !0),
c += a[u];
return function (t) {
for (var r = new Uint8Array(t.length), o = 0, i = t.length; o < i; ++o)
r[o] = t.charCodeAt(o);
return r
}(c.substring(0, 32));
}
var Ar = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 0, 0, 0, 0, 0, 0, 10, 11, 12, 13, 14, 15, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 11, 12, 13, 14, 15, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0];
var t = "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.11701108000";
var e = "bb3d08ee6011a8e9";
log(zr(t, e))

И так, зная всё мы можем собрать наш скрипт шифрования и дешифрования фингера.

var MD5 = function(d){var r = M(V(Y(X(d),8*d.length)));return r.toLowerCase()};function M(d){for(var _,m="0123456789ABCDEF",f="",r=0;r<d.length;r++)_=d.charCodeAt(r),f+=m.charAt(_>>>4&15)+m.charAt(15&_);return f}function X(d){for(var _=Array(d.length>>2),m=0;m<_.length;m++)_[m]=0;for(m=0;m<8*d.length;m+=8)_[m>>5]|=(255&d.charCodeAt(m/8))<<m%32;return _}function V(d){for(var _="",m=0;m<32*d.length;m+=8)_+=String.fromCharCode(d[m>>5]>>>m%32&255);return _}function Y(d,_){d[_>>5]|=128<<_%32,d[14+(_+64>>>9<<4)]=_;for(var m=1732584193,f=-271733879,r=-1732584194,i=271733878,n=0;n<d.length;n+=16){var h=m,t=f,g=r,e=i;f=md5_ii(f=md5_ii(f=md5_ii(f=md5_ii(f=md5_hh(f=md5_hh(f=md5_hh(f=md5_hh(f=md5_gg(f=md5_gg(f=md5_gg(f=md5_gg(f=md5_ff(f=md5_ff(f=md5_ff(f=md5_ff(f,r=md5_ff(r,i=md5_ff(i,m=md5_ff(m,f,r,i,d[n+0],7,-680876936),f,r,d[n+1],12,-389564586),m,f,d[n+2],17,606105819),i,m,d[n+3],22,-1044525330),r=md5_ff(r,i=md5_ff(i,m=md5_ff(m,f,r,i,d[n+4],7,-176418897),f,r,d[n+5],12,1200080426),m,f,d[n+6],17,-1473231341),i,m,d[n+7],22,-45705983),r=md5_ff(r,i=md5_ff(i,m=md5_ff(m,f,r,i,d[n+8],7,1770035416),f,r,d[n+9],12,-1958414417),m,f,d[n+10],17,-42063),i,m,d[n+11],22,-1990404162),r=md5_ff(r,i=md5_ff(i,m=md5_ff(m,f,r,i,d[n+12],7,1804603682),f,r,d[n+13],12,-40341101),m,f,d[n+14],17,-1502002290),i,m,d[n+15],22,1236535329),r=md5_gg(r,i=md5_gg(i,m=md5_gg(m,f,r,i,d[n+1],5,-165796510),f,r,d[n+6],9,-1069501632),m,f,d[n+11],14,643717713),i,m,d[n+0],20,-373897302),r=md5_gg(r,i=md5_gg(i,m=md5_gg(m,f,r,i,d[n+5],5,-701558691),f,r,d[n+10],9,38016083),m,f,d[n+15],14,-660478335),i,m,d[n+4],20,-405537848),r=md5_gg(r,i=md5_gg(i,m=md5_gg(m,f,r,i,d[n+9],5,568446438),f,r,d[n+14],9,-1019803690),m,f,d[n+3],14,-187363961),i,m,d[n+8],20,1163531501),r=md5_gg(r,i=md5_gg(i,m=md5_gg(m,f,r,i,d[n+13],5,-1444681467),f,r,d[n+2],9,-51403784),m,f,d[n+7],14,1735328473),i,m,d[n+12],20,-1926607734),r=md5_hh(r,i=md5_hh(i,m=md5_hh(m,f,r,i,d[n+5],4,-378558),f,r,d[n+8],11,-2022574463),m,f,d[n+11],16,1839030562),i,m,d[n+14],23,-35309556),r=md5_hh(r,i=md5_hh(i,m=md5_hh(m,f,r,i,d[n+1],4,-1530992060),f,r,d[n+4],11,1272893353),m,f,d[n+7],16,-155497632),i,m,d[n+10],23,-1094730640),r=md5_hh(r,i=md5_hh(i,m=md5_hh(m,f,r,i,d[n+13],4,681279174),f,r,d[n+0],11,-358537222),m,f,d[n+3],16,-722521979),i,m,d[n+6],23,76029189),r=md5_hh(r,i=md5_hh(i,m=md5_hh(m,f,r,i,d[n+9],4,-640364487),f,r,d[n+12],11,-421815835),m,f,d[n+15],16,530742520),i,m,d[n+2],23,-995338651),r=md5_ii(r,i=md5_ii(i,m=md5_ii(m,f,r,i,d[n+0],6,-198630844),f,r,d[n+7],10,1126891415),m,f,d[n+14],15,-1416354905),i,m,d[n+5],21,-57434055),r=md5_ii(r,i=md5_ii(i,m=md5_ii(m,f,r,i,d[n+12],6,1700485571),f,r,d[n+3],10,-1894986606),m,f,d[n+10],15,-1051523),i,m,d[n+1],21,-2054922799),r=md5_ii(r,i=md5_ii(i,m=md5_ii(m,f,r,i,d[n+8],6,1873313359),f,r,d[n+15],10,-30611744),m,f,d[n+6],15,-1560198380),i,m,d[n+13],21,1309151649),r=md5_ii(r,i=md5_ii(i,m=md5_ii(m,f,r,i,d[n+4],6,-145523070),f,r,d[n+11],10,-1120210379),m,f,d[n+2],15,718787259),i,m,d[n+9],21,-343485551),m=safe_add(m,h),f=safe_add(f,t),r=safe_add(r,g),i=safe_add(i,e)}return Array(m,f,r,i)}function md5_cmn(d,_,m,f,r,i){return safe_add(bit_rol(safe_add(safe_add(_,d),safe_add(f,i)),r),m)}function md5_ff(d,_,m,f,r,i,n){return md5_cmn(_&m|~_&f,d,_,r,i,n)}function md5_gg(d,_,m,f,r,i,n){return md5_cmn(_&f|m&~f,d,_,r,i,n)}function md5_hh(d,_,m,f,r,i,n){return md5_cmn(_^m^f,d,_,r,i,n)}function md5_ii(d,_,m,f,r,i,n){return md5_cmn(m^(_|~f),d,_,r,i,n)}function safe_add(d,_){var m=(65535&d)+(65535&_);return(d>>16)+(_>>16)+(m>>16)<<16|65535&m}function bit_rol(d,_){return d<<_|d>>>32-_}

Вспомогательные функции

function arrayBufferToBase64(arrayBuffer) {
var byteArray = new Uint8Array(arrayBuffer);
var byteString = '';
for(var i=0; i < byteArray.byteLength; i++) {
byteString += String.fromCharCode(byteArray[i]);
}
var b64 = window.btoa(byteString);
return b64;
}

function base64ToArrayBuffer(b64) {
var byteString = window.atob(b64);
var byteArray = new Uint8Array(byteString.length);
for(var i=0; i < byteString.length; i++) {
byteArray[i] = byteString.charCodeAt(i);
}
return byteArray;
}

const fromHexString = function(hexString){return Uint8Array.from(hexString.match(/.{1,2}/g).map(function(byte){return parseInt(byte, 16)}))};

const toHexString = function(bytes){return bytes.reduce(function(str, byte){return str + byte.toString(16).padStart(2, '0')}, '')};

Тестовый код

const crypto = require('crypto');
const { Crypto } = require("@peculiar/webcrypto");
const crypt = new Crypto();
const atob = (base64) => {return Buffer.from(base64, 'base64').toString('binary');}
const btoa = (text) => {return Buffer.from(text, 'binary').toString('base64');}
const md5 = data => crypto.createHash('md5').update(data).digest("hex");
function md5ToEnc(t) {
var e, n = [],
r = t.length;
for (e = 0; e < r - 1; e += 2)
n.push(parseInt(t.substr(e, 2), 16));
return String.fromCharCode.apply(String, n)
}
function hashBinary(t, e) {
var n = md5(t);
return e ? md5ToEnc(n) : n
}
const Ar = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 0, 0, 0, 0, 0, 0, 10, 11, 12, 13, 14, 15, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 11, 12, 13, 14, 15, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0];
function keyEnc(t, e) {
var i = t + function (t) {
for (var n, c = t.length, u = "", s = 0; c > 1;)
e = t.charAt(s++).charCodeAt(0),
n = t.charAt(s++).charCodeAt(0),
u += String.fromCharCode((Ar[e] << 4) + Ar[n]),
c -= 2;
return u
}(e),
a = [];
a[0] = hashBinary(i, !0);
for (var c = a[0], u = 1; u < 3; u++)
a[u] = hashBinary(a[u - 1] + i, !0),
c += a[u];
return function (t) {
for (var r = new Uint8Array(t.length), o = 0, i = t.length; o < i; ++o)
r[o] = t.charCodeAt(o);
return r
}(c.substring(0, 32));
}
const fromHexString = function(hexString){return Uint8Array.from(hexString.match(/.{1,2}/g).map(function(byte){return parseInt(byte, 16)}))};
const base64ToArrayBuffer = function(b64) {var byteString = atob(b64);var byteArray = new Uint8Array(byteString.length);for(var i=0; i < byteString.length; i++) {byteArray[i] = byteString.charCodeAt(i);}return byteArray;}
async function decryptMessage(ua,data){
const encMessage = JSON.parse(data);
const key = await crypt.subtle.importKey('raw', keyEnc(ua,encMessage.s), { name: 'AES-CBC' }, false, ['decrypt']);
const decryptedData = await crypt.subtle.decrypt({ name: "AES-CBC", iv:fromHexString(encMessage.iv) }, key, base64ToArrayBuffer(encMessage.ct));
return new TextDecoder().decode(decryptedData);
}
const ua = "Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.11701108000";
[[BDA_DECRYPT]]=await decryptMessage(ua,[[MESSAGE]])

В итоге на ноде (12) декрипт нихуя не работал, а в браузере блять работал. Ну и хуй с ним тогда.

Сегодня разберемся как решать все гитесты с этой странички https://www.geetest.com/en/adaptive-captcha-demo

Для начала накидаем на эмуляции, а потом посмотрим запросеки.. Похуярили!

И так, скутеры слайдеры.

Разумеется, на много пизже работает на контурах, как я делал до этого.

Но для разнообразия, накидаю попсовым вариантом, как было в статье на хабре, с заготовкой фоной. Это ещё пригодится для последней, клик капчи)

Генерация фонов

Сначала нужно как-то получить фоны. Руками мне лепить их лень, потому я сделал генератор. Напарсил фоны, а потом замерджил по phash. phash выбрал чисто потому, что оно по имени сортируется в папке, выглядит красиво)

А еще, хеш - готовая строка, поэтому сравнение картинок по схожести по нему будет работать сильно быстрее, чем каждую картинку друг с другом сравнивать.

Парсинг в общую папку. Хотя на скринах я уже паршу тесты, но суть та же.

В ответе и запросе есть колбек "geetest_" + Date.now(), так как эт фикса по длине, по ней я ответ и подрезал через slice.

Итак, напарсил чуток фонов с дыркой. Все картинки, кстати, с шумами, но как будет видно позже, это не проблема)

Сортировку делал отдельно по hash, как в скрипте по seosprint.

В результате получаем фон с дыркой в разных местах. Остается только мердж.

А мердж довольно простой и логичный.

Мы у всех сортированных картинок из папки берем пиксель по индексу, сейвим в массив, а потом голосованием выбираем какой это пиксель. Если 1 и 2 вариант одинаковы по количеству голосов, берем случайно либо 1, либо 2, чтобы разнообразить шумы.

Да, массив RGBA я сохраняю как строку, чтобы проще сравнивать схожесть.

Решение

Так как при мердже часть фонов вышла с мусором, я их ручками удалил. Всеравно ведь удалить пару картинок проще, чем сидеть и собирать их по частям)

Имея базу "чистых" фонов, берем картинку капчи и ищем какой фон имеет наибольшую схожесть с нашей используя нативный метод баса "поиск картинки в картинке".

А потом удаляем все лишнее с картинки либой pixelmatch, как делалось в статье с хабра или материале на форуме зенки.

Благодаря либе, шумы, которые есть на каждом фоне, в итоге отсутствуют на нашем итоговом изображении.

Имея позицию по Y и фон, найдем позицию скриптом Sadzurami (с парой строк моего говнокода) для тестов. Как я сказал ранее, подход не самый удачный, но для эмуляции решил поэкспериментировать. Для запросов сделал уже нормально.

Ну и оно работает, что не удивительно, ищет дырку по пазлу.

Эмуляция

Ну а тут будут причины почему мне не нравится эмуляция.

1) Я запускаю сайт и он грузится, а капча не успевает прогрузиться. Хорошо, я ставлю ждать полной загрузки. В итоге выбивает ошибку ожидания загрузки, ведь ждало больше минуты, но что-то вот как-то не пошло. Ну окей, и чего мне тогда делать? Мне нужна обычная, самая обычная, нормальная загрузка страницы и нужно просто ее дождаться. Но нет, мне приходится городить какие-то костыли.. Поэтому я убрал ожидание загрузки страницы и добавил ожидание именно капчи.

Но проблемы на этом не заканчиваются, они только начинаются.

2) При решении слайдера мне нужно зажать кнопочку и переместить по координатам. И вот я беру и... вместо правильного движения мышка резко улетает куда-то в ебеня. Это наверное не проблема баса, а сайта, но мне такие приколы не нравятся.

Более того, сайт еще имеет и горизонтальный, сука, скрол.

Поэтому я ручками пошукал, сделал удаление стилей, которые делали эту хуйню. Тем самым сломав верстку нахуй.

Только вот это нихуя не помогло. Оно опять кликало не туда и мышка улетала в ебеня. Костыльным решением, которое спасло ситуацию, стал юз режима капчи попап.

Еще, зачем-то пришлось добавить сдвиг в 10 пикселей к позиции ответа.

3) Картинки дергал через кеш, с этим проблем не возникло. Хотя нет, возникло блять. Капча без задачек автоматически решалась при загрузке страницы, поэтому в кеш попадала хуйня. Чтоб этого небыло, пришлось добавить ожидание перед переключением режима капчи, тк именно при переключении режима оно сразу дергает получение задания на капчу. Хотя, можно было фильтр кеша делать по типу задания, он ведь тоже в урле.

Но хотя бы теперь я смог протестить, что все работает правильно. Слайдер есть слайдер, потому не удивительно, что оно пиздато решается. Вообще, я применил поиск картинки в картинке для определения позиции, но тк у нас и тк есть онли пазл, можно было дернуть через маску, тк наша картинка по сути маска готовая. Но даже так, за все время тестирования вроде всего 1 ошибка была.

Эта капча очень простая и решается чисто математикой. Я не очень умный, по-этому сделал так как смог.

Тем более, задачка прилетает просто массивом

Решение

По сути, наша задача найти какие-то 2 картинки, флип которых даст линию из 3х совпадающих элементов, причем если флип горизонтальный, линия - решение получится вертикальной и наоборот. Например, мы флипаем 2 красных квадратика, а решение получится в одном из зеленых столбцов.

Я не знаю как это решается по нормальному, но раз нужно найти какую-то пару, которая приведет к решению, я просто возьму и забручу все варианты решения нахуй. Возьму и выполню все варианты перестановок и сделаю прочек получилась линия или нет. Тем более перестановок выйдет около нихуя. Чтобы небыло баги перезаписи значений, опять пришлось добавлять клонирование через сериализацию.

Эмуляция

Тут все обошлось без приколов. Есть классы, где в нейминге указаны позиции. Я передал туда ответы и кликал сразу куда нужно.

Само задание просто парсил из кеша

Все максимально просто и логично

В итоге решало 100 из 100 на эмуляции.

Наверняка, мой код говно и можно сделать проще (любители литкода, ваш выход), но я сделал как сделал и оно работает.

Как и в случае с прошлой капчей, тут нам прилетает массив

Решение

Для начала чекаем какие у нас вообще есть цвета. После, проходимся по горизонтали, вертикали и диагоналям, собирая статку по цветам в каждом типе линий (BOARD) через функцию подсчета checker. Далее чекаем какой именно тип линий - решение и на какой позиции, сейвим в task_type и value.

А после, шукаем конкретную позицию дырки и камня желаемого цвета, исключая при поиске нашу линию - решение. Все довольно топорно. Куча циклов, но проблем по скорости вроде нету, поэтому меня всё устраивает.

Эмуляция

В процессе тестов я нашел багу. Если варианта ответа 2, хуйня как на скрине ниже. Изначально я это не предусмотрел и оно лажало, решая 90%. Но ведь это можно просто взять и фиксануть.

В итоге я её просто взял и захардкодил. У нас в чекере идет подсчет цветов, а дырку мы выкидываем. Получается, у нас всегда остается объект, где всего 1 цвет.

Задачку, как и в прошлой капче, дергаем через кеш.

Клик по элементам решил сделать через выбор класса полоски и её элемента.

В итоге все работает, теперь решает 100 из 100.

А вот с этой штукой я уже чуток намучался. Задачка прилетает, как и со слайдером.

Решение

Ну окей, ищем и удаляем фон, всё как у слайдера. Фоны я ранее чисто под эту капчу парсил и мерджил, ровно как и со слайдером.

Картинка получается не очень чистая, но в целом сойдет. Все таки нам важно сохранить иконки и похерить шум.

А теперь самое интересное, че же делать дальше?

А дальше надо по любому дергать эти иконки. Только вот хуйня вся в том, что мини иконки и их версии на картинке чуть отличаются.

Поэтому я решил дергать внешний контур иконки. Я получаю фон, а потом дергаю все что не фон)

Да, выглядит он немного ебано, но задачу свою полностью выполняет. Всетаки прям в пиздатом качестве иконки в данной капче не вытянешь, даже при наличии фона.

Дополнительно добавляю сортировку. В чем смысол решения станет понятно чуть позже.

Ну и мини иконки тож дергаю. Тк они сразу чб, то всё чуток проще.

На выходе получаем подобную хуеверть.

И тоже сортирую.

Ну а теперь перейдем к сути решения.

Берём 2 массива, массив иконок с картинки и мини иконок.
Далее нам нужно как-то их сопоставить. Для этого оба массива сортируем по ключу, какому-то хитрому значению параметров, которое специфично для каждой картинки, но при этом не зависит от размера. На выходе получим пары.

Так как у массива мини иконок был порядковый идентификатор, раз пары у нас есть, соберем новый массив с индексом от второго и координатами от первого, а потом отсортируем по порядковому индексу.

Однако, для сравнения нужен какой-то хитрый параметр. Да, в сортировках выше уже и так видно как я порешал, но представим что ни кто этого не заметил.

Чтобы его подобрать, я просто взял и провел тесты со всеми алгоритмами и значениями. Для тестов заготовил 10 картинок и чекал какой метод решения лучше. Вообще, у роя много всяких параметров и методов, но я почекал чисто базу.

И решением по итогу стал старый советский...

Кароче, я поделил площадь на периметр и определил это значение в качестве кэфа: e.coeff=e.d.mbrSurface/e.d.perimeter

И по итогу получим правильное решение.

Чтобы это все добавить на картинку, я просто выполнил цикл.

Ну и добавил текст. Все довольно просто.

Шо имеем по итогу?

Берём фон и картинку. Делаем маску. По маске получаем картинку из роя, причем с параметрами. Считаем каждой картинке отношение периметра к площади, а также сейвим координаты XY. Потом сортировка.
Получаем инфу по площади и периметру для мини иконок. Их тоже сортируем? но при этом сейвим их индексы.

Далее еще она сортировка, но итогового массива.

Так как мини иконки без фона, отдельно делал функцию добавления оного

Эмуляция

Ну тут все совсем просто. Парсим положение картинки, а потом эти координаты докидываем к ответу.

В целом, на тестах статка выходила в 60% успеха, что неплохо для такой капчи, при том без использования нейронок.

Помимо описанных ранее капч, у гитеста ещё есть вот такая поебеть, которую можно чекнуть на другой демо страничке https://www.geetest.com/en/demo

Но как её решать я не смог придумать, не затащил.

Типо кликни на маленький зеленый рядом с большим еще чем-то. Я хуй знает как это решать без нейронок и распознавания объектов. Поэтому её скрипаем.

Напоминаю, наша демо страничка.

Проведем поверхностный ресерч. Все параметры и так есть в задачке капчи или еще где-то, а вот W. Её нам и надо будет разгадать.

Опять чекаем стек вызовов, опять чекаем каждый вызов..

Находим воть и потом разматываем дальше

И приходим вот сюды. И шо мы тут видим? А видим мы, что было тело с решением, а потом мы его как-то пошифровали, получив на выход 2 какие-то строки.

Шагаем еще чуть назад и видим, что создаются 2 функции, AES(cbc) и RSA. Тогда все становится на свои места. Мы генерим рандом ключ, им шифруем тело через AES, а потом шифруем ключ через RSA, тем самым юзаем плюсы обоих крипто методов.

Теперь нужно понять че мы шифруем. Для слайдера это позиция + какой-то пов + пара дефолт данных. В целом, вроде ничего сложного.

Такс, ну ключик RSA у нас статичный, поэтому пиздим его из памяти.

Все оказалось довольно просто, поэтому я решил почекать другие варианты гитеста (старый вид). Чекнул на демо страничке от кап гуру. Код такой же практически, алгоритмы те же..

И нашел я там.. такой же ключ RSA. Типо, ровно тот же.

00C1E3934D1614465B33053E7F48EE4EC87B14B95EF88947713D25EECBFF7E74C7977D02DC1D9451F79DD5D1C10C29ACB6A9B4D6FB7D0A0279B6719E1772565F09AF627715919221AEF91899CAE08C0D686D748B20A3603BE2318CA6BC2B59706592A9219D0BF05C9F65023A21D2330807252AE0066D59CEEFA5F2748EA80BAB81

А потом я подумал: выглядит гига изично, но мне так лень писать код.

Поэтому по ключу я посерчил на гите и нашел сразу готовые решения.

Какбэ да, можно было б и самому пореверсить, но нахуя, а главное зочем, если это ровно тот же код, что я получил бы и сам, но часа через 3.

Из всех реп для меня примечательна стала именно эта, тк код на ноде.

Забегая вперед скажу, что китаец молодец и написал отличный рабочий код. Желаю ему получить мискарис и кошкажена от партия.

Также, чуток погуглил и нашел много заметок прям с разбором реверса от других китайцев, поэтому не вижу смысла расписывать это тут.

Хорошие заметки, все подробно и четко расписано, со стрелочками даже.

А тут даже есть подробный видео гайд, помимо статьи.

Вот тоже интересная заметка по реверсу гитеста. Тут даже целый форум, точнее ветка на форуме.

Вот например реверс протобуфа. Чел показал, как собрал данные и шаблон, а потом через питончик отправить запрос.

Такс, раз шифрование у нас есть, соберем решалку на самой простой задачке и почекаем. Общая схема скрипта такая.

В процессе подготовки к тестам, я обратил внимание, что в прод коде капчи, в отличие от китайского есть 2 новых значения:

Чуть потыкал стек вызовов и нашел biht.

Тут оно дергало из гига массива файла по индексу нейм biht.

Значение мы всегда получаем одно и то же - 1426265548. А значение это - контрольная сумма функции от самой себя. Возможно это какой-то контроль версий файла капчи.

А вот чтобы найти второй параметр, пришлось чуть похитрить. И нет, это не рандом. Оказалось он тянется из файла капчи и ставится как window._lib

Я поставил на декод логический брек, который стопал когда видел слово _lib. И нашел от куда оно берется.

Оказалось, в коде есть гига массив с данными, по индексу от туда и берется значение. Первая часть имени есть в файле, вторая в массиве. И получается это какбэ привязка к файлу, типо ключи.. можно и наверное нужно сделать парсер, но для тестов я просто их дернул как есть и фсе. Хотя парсинг написать изи, пример скрин ниже.

По итоге код шифрования стал выглядеть так

Теперь перейдем к самой решалке.

Чисто визуально массив повернут, но на самом деле нет и ничего делать не нужно.

Почекаем че мы шифруем для этой капчи. Вроде вся та же хуйня, что я собрал ранее. Можно тестить.

Запрашиваем капчу, дергаем ответ и пару данных для запроса ответа. Получаем ответ, шифруем и шлем на решение.

Интересная тут только подготовка тела капчи. Я докинул параметров, которые нужны в запросе и добавил енкод для тела, чтобы сразу из JSON получить uri данные.

И оно в итоге работает, решает 100 из 100 на запросах)

А значит нужно переходить к остальным капчам.

И в отличие от прошлой капчи, тут поменялся только тип таска и блок решалки перекочевал из скрипта с эмуляцией.

Итог: 100 из 100

У клик капчи данные были странноватые.

Но оказалось, что они просто в процентах.

Тоесть, в отличие от предыдущей капчи, помимо переноса решалки, в эту потребовалось докинуть еще функцию перевода координат в проценты.

В итоге, около 60% валид решения, как и в случае с эмуляцией.

А вот у слайдера есть пара своих отличий.

Как и в ориг репе китайца, в теле решения этой капчи нужны были параметры setLeft и userresponse.

{
"setLeft": 216,
"passtime": 1003,
"userresponse": 216.72311322005146
}

Там я и спиздил кусок userresponse: distance / (.8876 * 340 / 300)

Для запросов решалку я поставил уже нормальную, на контурах, как и у бинанса.

Ну и все решалось также отлично.

Итог: 100 из 100, но парочку захавал антифрод.

Введение

В первой части я рассказал о своей истории знакомства с тт, тем как проебал темку с потенциалом в дохуя, а также, тем на что я въебал пол года.

С одной стороны, было весело и полезно, все-таки скил я сильно подкачал. С другой, обидно что по деньгам вышло нихуя.

Чуть позже, как подкачал скил, капчи всё же раъебал. Потому, хотелось бы ими поделиться.

Да, я натыкался на форуме, что подобное решение продают, но я потратил на тикток слишком много времени и сил, чтобы что-то продавать или допиливать, а потому делюсь тем что есть) Как обычно, я решил сделать чуточку больше чем остальные, больше чем есть в паблике. Похуярили..

Демо страница: https://sf16-scmcdn-va.ibytedtos.com/goofy/secsdk-captcha/va/2.15.21/index.html

Нашел я эту демо страничку когда-то совсем давно, копаясь в коде запроса капчи тт. Если правильно помню, тогда она (капча) прилетала фреймом с линкой на эту страничку.

Подходы к решению

На zenno форуме когда-то давно уже поднимался вопрос решения капчи слайдера.

Применяемое там решение базировалось на логике: напарсить всё и составить целые картинки, а потом уже искать отличия.

Кстати, несколько позднее я увидел подобную идею на хабре, что было переводом вот этой статьи (спиздинг с зенки?).

Ещё есть варианты переводить в серое, как делал Sadzurami.

Однако, мне такой подход кажется не очень практичным, особенно когда есть сопоставимые (на деле на порядок лучше) по качеству альтернативы. Потому, я использовал подход на контурах, как и в случае с бинансом. Более подробно то как я пришел к этому решению расписано в материале про бинанс.

Мой подход

Как уже сказал, я просто перенес решение с бинанса на тикток, но без трудностей тут конечно не обошлось.

Я взял свой модуль и въебал большие пороговые значения, чтоб получать по сути только белые линии обтекающие пазл на фул картинке.

Первой задачкой стало то, что положение пазла по Y (высоте), которое присылает тт, слишком маленькое.

В итоге оно резало криво.

Решением стало - прописать 2х размер. Почему это сработало, станет очевидно чуть позже.

Второй преградой на пути стало то, что контуры получались слишком тонкие, что в итоге приводило к ошибке. При наличии мусора в контурах или белых объектов часто не мог найти правильное положение. Хотя казалось бы, куда ещё лучше.

В отличие от мелкой картинки банана, тут она имеет размер 552х344 и потому был резон сделать расширение белых областей, подробнее и на умном туть.

Значение подбирать, разумеется, нужно не от пизды.

Я опять использовал image-js. Дока.

В итоге, оно начало стабильно работать, на 10 из 10.

Но веселье на этом не заканчивается. Покопавшись в сурсах капчи, я понял, что они используют не ориг картинку, а уменьшенную (вот так сюрприз). Тоесть если я вот так решу, то эта позиция пазла нахуй не пригодится.

Причем, для пк размеры одни, а для мобилок другие.

Поставив брек на модификации атрибута кнопки, который отвечает за перерисовку положения кнопки слайдера..

Я попал сюда, где увидел, что исходная позиция tip_y, которую вертает тикток, увеличена на некоторую константу.

Прокрутив чуть выше, стало очевидно как работает вся эта хуеверть. Оно просто чекает какое у нас устройство (бек это кстати по юа чекает) и в зависимости от этого ставит константу в 1 или в 1.23...

А после сжимает её через css до 276, либо до 340, в зависимости от устройства.

Всё это я применил и в софте.

Ресайз сделал также через image-js. Теперь результат решалки уже можно будет применять на практике.

Третий препон - координаты. Раз я решил делать на запросах, значит нужно и координаты как-то кастовать. Но прежде, стоит разобраться, а чё вообще генерировать.

В случае с пк, данных до ху я.

А с мобилкой, не сказал бы что меньше. Но я решил выбрать мобилку (на деле разницы нет шо выбирать, одинаковая хуйня).

Ну.. пока ты двигал пазл, вот там всё и происходило

Сначала я долго всматривался в координаты, а потом они начали всматриваться в меня. И тогда тикток сказал:

А если серьезно, я поставил бреки, посерчил код и пришел сюда

А потом сюда (на позицию данных перед отправкой).

Вернувшись назад по стеку, я увидел как пополнялись эти массивы.

Ну окэй, мы знаем 2 массива, пазл (drag_track, он же reply) и кнопка слайдера (slide_btn_track, он же m) и можем примерно понять от куда они берутся. Но остается странный массив T. Количество значений в drag_track и reply одинаковое, тк оно по сути описывает одно и то же движение, только с дух разных точек по Y, а вот T..

Причем, заметим что T кратно 5 от количества reply значений всегда.

Прочекав код мы придем вот сюда. Оно тречит позицию не пазла, а "мышки", когда она зажата и сейвит каждую пятую точку.

Штош, имея примерное представление о том, что тут происходит, я решил не ебать себе мозги, а тупо: сделал скрин экрана, обрезал его, взял ответ с координатами и накидал скрипт который нарисовал всю хуйню движения мышки.

Результаты были не очень читаемые, поэтому мне пришлось применить немного магии рандомного подбора циферков, добавив сдвиги. Точнее, я почекал всякие расстояния, но не прям чтобы сильно уверен, что правильно все понял (но работает же все в итоге). Примечательно, что координаты движения кнопки были прям точные и правильные относительно скрина. Значит, в написании решения от нее и будем отталкиваться.

Чтобы воспроизвести эту хуйню, мне нужно было понять от каких цифр отталкиваться, поэтому я собрал чуть инфы - размеры кнопок и картинок, а также их положение через getBoundingClientRect()

Применительно к тт это выглядело вот так.

Ну и осталась генерация..

В ситуации с бинансом я писал свой говнокод, этот случай конечно не исключение, но часть работы я решил переложить на попсовое решение windmouse. Классека.

На первый взгляд может показаться, что тут нихуя непонятно.. и на второй тоже..

Благо, у либы есть онлайн визуализатор, благодаря чему можно быстрее понять всю эту хуеверть. По факту, я просто хочу, чтобы из одной точки по координатам XY до другой провели линию. При этом гравитация (плавность) максимальная, отклонения от траектории 1, шаг по времени между точками от 1 до 5 (мс), а в пикселях макс шаг например 4. Таргет зона, это степень отклонения от конечной точки.

Я чуток поигрался с настройками и разобрался как кастовать правильную линию.

И так, я набросал базовую инфу, понял как генерить линии и накидал некий сценарий работы в голове:

• Берем позицию кнопки от её середины по высоте.
• От нее ставим позицию до конца по Y + допустимые отклонения и передаем windmouse задачу генерации линии.
• Имея данные движения, кастуем 3 массива, учитывая специфику доп отклонений каждого. У кнопки это -8 пикселей вверх, у пазла фикса по Y, а X как у кнопки, у курсора добавил некоторое старт отклонения в рамка иконки стрелки у кнопки.

По итогу получился следующий код.

Ииии... он нихуя не работал. Я въебал 6 часов, собирая какую-то хуйню на координатах, до конца вообще не контролируя че происходит и оно блять не заработало.

Вот так сюрприз, с нихуя ничего не работает.

В рисовалке все выглядело как надо, как в решенных. Тоесть я свой генератор тестил на демо картинке и рисовало похоже.

И я уж было собирался идти спать, но подумал порандомить отступы для значения reply. В сравнении с данными от решенных капч, позиции у нее были со сдвигом на размер от окна до кнопки (37.5), тоесть будто движения от края экрана. Но я убрал этот шаг и оно начало нормально работать.

Ну типо 100 из 100 ответ от сервера тт на решение. Решалось по сути мгновенно.

На браузере, ясен хуй, оно тоже пиздато работает. Причем и для моб и для пк режима.

Картинки и тело задачи я дернул через кеш. Сначала вытянул инфу по капче, потом ссылки на картинки, а по ним сами картинки (тоже из кеша).

Не найдя для себя удобным доступы к капче через всякие формы авторизации, я решил потыкать текущую демку.

Я заметил, что если передать в ссылке другой тип капчи, то оно вернет картинки под другую капчу. По сути, ссылку можно свести даже к виду https://verify-sg.byteoversea.com/captcha/get?os_type=2&fp=verify_0&subtype=whirl

А потому, можно попробовать и запрос подменить) Что я собственно и сделал, получив в распоряжение демку на все 3 типа капчи.

Манкипатч запросекаф опять помог мне.

Кстати, при работе с качей на запросах мне нужен был параметр verify_, а это оказалось подобие UUID.

Ещё, было весело играть в отслеживание координат мышки

Демо страница: https://www.tiktok.com/login/phone-or-email/email

Не то чтобы данная страница капчи была полезная для меня в тестах, имея описанную ранее фичу, но раз это линка того, где тт использует данную капчу в проде, пусть будет.

Следующей капчей, которую я порешал, была эта. Рассмотрим какие у нее есть решения в паблике.

Подходы к решению

Данная капча похожа на (старую) rotation captcha у funcaptcha.

Есть опенсурс демка и сурсы.

У поворотных капч на гите было решение на основе RotNet.

Только вот данная капча проще чем кажется (это не тот rotation), у неё есть и более интересный подход к решению)

Некоторое время назад на zenno форуме бесплатно выложили решалку этой капчи. Хоть оно и работало, но оказалось с подвохом. В скрипте был стилак)

Все сначала так радовались, пока не поняли подвоха..

Однако, не суть, всё равно оно ведь работало)

И так, оно дергало координаты по некому списку, а потом сравнивало.

Мой подход

До публикации софта со стилаком (каким-то кеком) на форме зенки, я пришел примерно к тем же мыслям и сделал подобное решение. Так как кругляшка у тт 2, а не один, это сильный проеб, благодаря которому сложность всей капчи сводится на нет.

Если разрезать картинку на 2 части, в месте разреза на каждой из картинок будет одинаковый рисунок, с круглым вырезом та же хуйня. Берем внешний контур у мелкой, внутренний у большой, вертим и сравниваем эти 2 круга пока не совпадут.

Подглядел я эту мысль когда-то в статье по взлому KeyCaptcha.

Но есть нюанс.. сначала, развить эту идею я нормально не смог. Я дергал контуры 2 пиксельные полоски, а потом крутил их.. Да, оно работало, но крайне нестабильно.

Что я пробовал?

Начал я вообще с того, что стал вникать как вертеть картинки и потом обрабатывать каким-нибудь фильтром, чтобы в итоге при сравнении картинок бас давал хороший результат.

И так, вертим картинки

Сначала вертел я её сервисами.. как долбаёб.

А потом до меня дошло, что таким макаром я далеко не уеду. И опять пришел к либе image-js, а именно функции rotate.

Я подбирал всякие серые фильтры, экспериментировал с тем как лучше делать: взять мини картинки и растянуть до размера контура кольца или наоборот контур кольца сжать или вообще их оба растянуть или сжать до какой-то иной цифры.

Тестировал чб фильтры и их комбинации.

Убил недели 2 на всякую хуйню. Зато, код выглядит не сильно по уебански.

Кстати, в один из тестов я даже нашел еще один сбой в матрице (прям как в бинансе с нередач картинкой). Берем контур.

Перегоняем в оттенки серого. И получаем.. изначальную картинку.

Причем если контур из png перевести в jpg, то бага уже не воспроизведется.

Хз почему так выходит.

Остановился я в итоге на фильтре "magenta".

Ну и вынес это в отдельный скрипт решалку.

Ну и какбэ, оно решало, да, но не достаточно хорошо. Пробив 20% меня не устраивал.

На деле все решение сводилось вот к чему: вертим картинки и дергаем контур круга, а потом сравниваем через бас совпало или нет.. говно говна, а не решение.

А потом до меня дошло, что линяя не обязательно должна быть круглой. Мы можем перевести контуры в 2 прямые линии и искать позицию уже в них. Тк если делать через поворот круга, происходит пересчет цвета и уебищно все выходит.

Уроборос, который кусает (наверное) свой хвост, отличная визуализация этой мысли. Тоесть ее можно развернуть.

@ZennoTema привел эти мысли в рабочий красивый пример, со своим хитрым алгоритмом поиска краёв.

И оно просто ахуительно работало

Хоть у ZennoTema всё работало заебись, я решил сделать по своему, более топорным методом.

К чему я пришел в итоге?!

Рисуем кружок, как и в случае с tutanota. Только тут задача получить все крайние пиксели кружка.

Чекаем прозрачность и пропускаем пиксели, где пусто.

Но мне не нравилось, что линии получались разной длинны, я был убежден что так быть не должно. Пробуя делать разные алго, в итоге всеравно получалось разное количество пикселей. Сравнивать было неудобно и результат был хуевый. Я чуть даже не дошел до того, чтобы сесть руками позиции пикселей посчитать. Ну типо бля, в одной 169, в другой 276, хуй поймешь как потом от туда вытянуть правильный результат.

Поэтому я решил рисовать чуть с отступом от края, получая в итоге 360 пикселей. Последним параметром я указал тип кружка, о нем чуть позже.

Однако, при текущем алго возникает проеб.

Получается 361. 0 и 360 градусов совпадают по X и Y. И мы это быстро фиксим.

Сначала я сделал так, поставив шаг от 1 градуса, а потом понял, что лучше наоборот, начинать от 0 до 359.

360 пикселей, 360 градусов.

Дальше ключевое - делать полоски из найденных пикселей, чтобы потом их сравнить и найти правильное положение. Я много экспериментировал и выходила хуйня.

И тут ZennoTema предложил гениальную в своей простоте идею, до которой я сам дойти не смог: просто удваиваем вторую линию, тогда при поиске мы сразу можем найти правильное положение первой во второй.

По итогу получился вот такой простой код. Для кольца мы делаем удвоение линии.

Я въебал кучу времени, чтобы рисовать 360 линий (каждую со сдвигом на 1 пиксель), но в итоге оно у меня работало через хуй, а тут буквально 1 мелочь в пару строк кода и сразу все встало на свои места, стало решать на 100%.

Еще раз, вот это и есть все решение. Да, вот так все просто.

Так как у нас 2 круга, которые крутятся на встречу друг к другу, итоговый угол надо делить на 2 (макс угол для каждой картинки в таком случае 180 градусов).

Ну а теперь перейдем к запросекам.

С точки зрения кода, что слайдер, что это, по сути одна хуйня.

Единственное, меняется тип капчи whirl и положение у reply по Y это 0. Тем не менее, нам надо как-то еще понять, как перевести полученный угол в координаты для слайдера.

Ну окей, ставим брек на rotateZ, а потом чекаем че у нас выше места остановки. А выше формула перевода координат в угол, она нам и нужна: var deg = a.x / (222 * _.n * kt / 100) * 180; Это вроде мусор * kt / 100 там 100 на 100 всегда делится, нахуя оно это делает я так и не понял. А вот _.n коэффициент масштабирования капчи.

Я поставил логпоинт, чтобы почекать данные в процессе решения.

Ну какбэ понятно, берем координаты, делим 222 и умножаем на 180, получаем угол в градусах. А нам нужно наоборот. Кстати, 180 тут тк 1 картинка должна максимально пройти 180 градусов, а картинок у нас 2 движущиеся в противоположных направлениях. Тоесть даже если они уже в правильном положении, если каждая пройдет 180 градусов, они опять встретятся.

Ну и фсе, я просто взял и вывернул формулу, допом обновил startY, тк тут (в куче ответов) она была другая.

В теле поменялись пару мелочей

Ну и оно работает по красоте в итоге. По сути 100 из 100, но часть решений скушал антифрод. Либо проеб на пол пикселя есть.

Пример ситуации с ошибкой. Остальные 2 ошибки такие же. Решено все вроде правильно, но фроду тт чет не понравилось.

Про браузер и смысла нет говорить. Добавилась только формула dist для конвертации угла в координаты кнопки. И тоже работает пиздато. В режиме моб и в режиме пк.

Помимо этого, помнится мне, был вопрос по этой капче применительно к мобилкам.

Мне стало интересно, а можно ли чисто из скрина делать решение. На ранних экспериментах я говнял свой детект краев и думал кропать.

По факту, если юзать метод прохода по кругу, зная размеры кружков, можно все спокойно собрать, причем даже со скрина. Но лучше так не делать.. Лучше дергать ориг картинки.

Ещё, похожую по своей сути капчу кидали в чат, но валид демку я найти не смог, так что и тестов применительно к ней не будет.

Демо страница: https://ads.tiktok.com/i18n/login/

Ну а теперь перейдем к самому интересному. Именно с этой капчи у меня начались сложности с тиктоком. Все-таки, я ведь именно с ads tiktok работал.

Чисто технически, найти решение данной капчи, да еще и без всяких нейронок (онли на бас), было самой интересной задачкой)

Данное решение (ну не прям точно такое, но суть осталась прежней) я придумал еще тогда, года 4 назад, но не затащил по скилам. На эксперименты с этой хуйней суммарно я потратил где-то недели 2, а может и месяц..

Разберем какие есть подходы к решению в паблике.

Подходы к решению

На форуме зенки была решалка данной капчи. Строилась она на сравнении картинок по phash из другого материала. Челы из авито, кстати, для сравнения картинок в антифроде сетку отдельную обучали.

Вернемся к зенке. Они дергают картинку, режут на мини картинки (фигуры), сравнивают их. Важным шагом тут является вот это:

Если я правильно понял, они берут картинку, как-то фильтруют и получают чб маску, вычитают ее и дергают фигуры.

Непосредственно код.

Вся обработка вот этой либой, по аналогии с примером.

Кажется, что фильтруют только фон?!

И сравнивают в итоге через phash. Только вот сравнение по phash тут не является оптимальным подходом, лучше подойдут шаблоны (Template Matching или простыми словами "поиск картинки в картинке"). В чем я убедился на собственных тестах.

Потому не удивительно, что даже на простых примерах оно лажает.

Когда я решал ее в своем софте на запросах, я выбрал рукапчу. Но токен (кука) очень быстро умирал.

С запросеками при решении капчи я чуток намучался, тикток штука крайне специфическая..

Ну и оно работало, я даже по нему софт публиковал на форуме.

Весь смысл капчи тт, на самом деле, сводится к тому, что при входе на сайт дается сгенерированная на фронтенде кука verify_ (как генерится писал чуть ранее), а потом по ней происходит запрос авторизации и капчи. Если капчу на этой куке решили, тт пустит. Поэтому мне на рукапче нужно было передать свои куки и попросить verify_ куку? в которой пройдена капча.

Также я тогда упоминал шифрование логина и пароля. Вдруг, пригодится кому-то.

function encrypt(e) {
var t, n = [];
if (void 0 === e)
return "";
t = function(e) {
for (var t, n = e.toString(), o = [], i = 0; i < n.length; i++)
0 <= (t = n.charCodeAt(i)) && t <= 127 ? o.push(t) : 128 <= t && t <= 2047 ? (o.push(192 | 31 & t >> 6),
o.push(128 | 63 & t)) : (2048 <= t && t <= 55295 || 57344 <= t && t <= 65535) && (o.push(224 | 15 & t >> 12),
o.push(128 | 63 & t >> 6),
o.push(128 | 63 & t));
for (var r = 0; r < o.length; r++)
o[r] &= 255;
return o
}(e);
for (var o = 0, i = t.length; o < i; ++o)
n.push((5 ^ t[o]).toString(16));
return n.join("")
}
[[MAIL_HASH]] = encrypt([[MAIL]])
[[PASSWORD_HASH]] = encrypt([[PASSWORD]])
[[TIME]] = Date.now()

Наверняка, можно было сделать готовых нейронках или заюзать что-то типо yolo, разметить ручками датасет, как делал индус в гайде, и затюнить под себя.

Но это не мой путь...

Мой подход

Я выбрал для себя выбрал некий вектор, который и хотел добить и почекать что выйдет.

Для начала просто взял картинку, нарезал ее ручками и решил проверить, что имея готовые фигурки я достаточно точно смогу найти правильный ответ. На тот момент я еще не учел важность приведения их к 1 размеру, но и без этого тест оказался удачным. Я заготовил 3 теста: нарезка, с фильтром цвета, с перегоном в серое.

Вырезал я картинки ручками, через фотошоп. В бас создавал картинку - фон 100 на 100 пикселей и добавлял на каждый фигуры в центр. А потом производил сравнение картинок в двойном цикле, как в первой версии скрипта для IconCaptcha.

По результатом сравнения победила нужная пара. Ожидаемо.

Самое забавное, что при цветном тесте победило розовое колесо и розовая буква Y, получается, важно убрать цветовой шум. Поэтому, в ласт тесте показаны серые фигуры. Черипикинг такой черипикинг..

Осталось всего-то понять как вырезать автоматом.. вез всяких питонов, через бас..

По факту ведь нам нужно: перегнать в серый, получить маску, по маске дернуть фигурки. По цветам также есть резон фильтры сделать. Так, ну а тени определенно идут нахуй.

И все бы ничего, если б я не столкнулся вот с этим примером. Оказалось, что в тт не мало (на самом деле мало, нахуя я вообще на это обратил внимание) картинок с перекрытием одноцветных фигур, на решение этого и ушло больше всего времени.

Как оказалось позже, смысла в этом особого и небыло, докинуло всего пару процентов.

Что я пробовал?

Начал я с ресерча подходов к сравнению картинок и поиску похожих. В целом, базированная база.

Так как я хотел решать без нейронок, этот (yolo) подход я проигнорил. Они всетаки для более сложных задач подходят, а эта выглядит посильной и без них.

В целом, накидать контуры, пару фильтров, а потом дергаем то что нашли. Выйдет примерно то шо и у зенки.

Ну какбэ да, опять собель, опять контуры.

Кстати, тени идут нахуй. Как и фон. Чекал туть.

Я пробовал чекать контуры. Но сами по себе контуры решением являться не могут. Наложения картинок, фигуры всетаки 3д и состоят из частей.

Я думал делать цветовую сегментацию. Или как туть.

Только вот у меня не opencv с питоном, а нода и бас.

Тогда я опять вспомнил про image-js, в которой были нужные функции, примерчики, и которая работала в бас 23.2.2 (12 ноде).

Подставив свою картинку я сразу понял, что с этим уже можно будет работать.

За пару часов я накидал простой код выдергивания фигур. И оно прекрасно и абсолютно точно не работало нахуй. Чего-то нехватало.

P.s.: На самом деле, нужно было добавить также сжатие картинок в 1 размер, на скрине просто неудачный пример.

А нехватало разделения объектов. Но я, вместо того чтобы накинуть фильтры по цветам, начал копать совершенно в другую сторону, надеясь заодно порешать вторую проблему - наложение одноцветных.

Я стал копать как можно вообще разделять наложенные объекты. Самое умное к чему я пришел - алгоритм водораздела. На самом деле, я перепробовал дохуища всяких вариантов, но в итоге получалось какое-то говнище и водораздел стал последней надеждой.

Бля, ну ведь с монетками оно работает же.

Вообще, я потом чуть потыкал и дергать без фильтра по цвету, результат хоть не очень, но даже так, оно всеравно работало.

Решило 52 из 100. это без всего. Без цветовой сегментации и без водораздела (разбиения слипшихся одноцветных), чисто минус фон только.

Вернемся к разделению картинок.

Пока все дрочили на чатгпт, я отсматривал хуеву тучу видео от индусов про то, как юзать алгоритм водораздела в опенцв, при том что у меня даже пайтон не установлен.

В image-js был алгоритм fromWaterShed, но он нихуя не работал у меня в бас.

Поэтому мне пришлось ручками его переносить из сурсов.

Только вот по итогу тестов я понял, что фигуры то у меня тонкие, буквы там всякие и тд, это не блядские круги, потому этот алгоритм не подойдет.

Я решил начать сначала, с подбора алгоритма серого, потом возможно бахну эрозию и собеля или канни, чтоб получить контуры и выкину нахуй ту часть где контуры/

Сложно только, что картинки одного цвета с нечетким контуром

Потом я нашел ещё одно интересное решение. В image-js есть всякие такие проколы: monotoneChainConvexHull, localMaxima

Но в моем случае это наверное не очень подошло бы. Кароче, этот вариант я тоже развивать не стал.

Для решения проблемы наложения картинок у меня было несколько тупых идей:
1) градиентный фильтр
2) херовые точки выпуклых фигур
3) поиск картинки из базы на картинке
4) вычесть контуры
Но остановился я по итогу на контурах.

К чему я пришел в итоге?!

Ранее я писал что получилось делать 52%. Я брал картинку, убирал фон фильтром уровней, переводил в серое и делал маску. Потом, применял маску и дергал по ней те фигуры, которые больше 500. А после, под каждую делал квадратную подложку размером по максимальной стороне и уменьшал до размера 20 на 20. Увеличил их только сейчас для скрина.

Далее я пытался разбираться с масками. Заметил, что фильтр шара неплохо режет что-то целое.

Потом, я пытался юзать 2 фильтра, светлый и темный и мерждить маски от них, в надежде получить удачный способ разделения картинок.

Ну и, разумеется, оно работало. Но хуево.

Следующим шагом стала фильтрация по цветам.

Я пытался по аналогии с opencv делать фильтрацию по цветам. Пытался понять что-то на вот этих всяких графках.

Я правда пытался понять как вот эти всякие цвета подбирать https://stackoverflow.com/questions/57469394/opencv-choosing-hsv-thresholds-for-color-filtering

Но в итоге, я просто сам методом научного тыка наугадывал диапазоны под каждый цвет и добил до 78%.

На простых примерах понятно, изи.

Однако, есть и проебы, а они бывают 2х видов:
1) Слипшиеся одноцветные (14)

2) Просто похожесть букв блять разных (8)

Хороший ли это результат, не знаю. Но вряд ли кто то еще проебал бы месяц на такую хуйню.

Поэтому я сел делать дальше, добавив разделение слипшихся одноцветных.

И в итоге добил до 80%

Ну а теперь перейдем к запросекам.

В отличие от остальных, тут все максимально просто. Тупо 2 координаты + параметр T.

Координаты в соответствии с картинкой.

Но есть нюанс, картинку опять ресайзит

Я решил не менять размер картинки сразу, чтобы не сбивать статичные настройки фильтров, но для лога и координат я сделал ресайз.

Значение T у меня было на тестах почему-то одинаковое. Поэтому, его я захардкодил. Помимо формирования JSON все остальное я выкинул.

Ну и в итоге все по красоте ебошило)

В том числе и на эмуляции, в пк и моб режимах

Теперь мы можем ебать все 3 капчи тт)

Но при работе с тт я столкнулся с ещё одной неприятной штукой

Блять, это должно было быть легким, но я долго не мог разобраться, пока не подсказал товарищ про одну мелочь.

Казалось бы, окей, берем линию, дергаем текст у selected.

Потом дергаем все тексты и чекаем на какой позиции выбранный и сколько нам шагать до желаемого значения.

Написал отдельный генератор разбиения на свапы с шагом в n.

1) Только вот не все так просто. Вся ебля была вот здесь. Без блока двигать мышь оно начинало играть в angrybirds при шаге выше 1, вместо нормального свапа.

В целом, оно и сейчас иногда багает, но это пофикшено перечеком даты

2) Как не сложно догадаться, блоки идут на самом деле не по порядку. Нулевой индекс у блока с годом, потом у блока с месяцем и уже после идет с днём

Поэтому я сразу сделал генерацию даты в нужном формате и порядке.

3) Блок с днем, центральный блок, тоже оказался с подвохом.

Написано свойство селектед у одного, а по факту там у 24 было. Фиксанул докинув флаг. Перечек тож по итогу спасает.

4) Хорошее решение не всегда хорошо. Когда софт двигал положение пиксель в пиксель на правильную позицию, тт просто не выставлял это число. Тоесть еще один способ палева. У обычных людей так не бывает и должно срабатывать автоматическое докручивание до верной позиции.

Поэтому пришлось добавить небольшое смещение.

Ну а на этом всё, я пиздую пить чай

В чат прилетел вопрос про "сложную" вафку. Штош, ну мы это еще посмотрим...

Улетает шифро дата, прилетает кука.

Чутка повангуем.

Ставим брек на btoa, тк очевидно что шифро дату удобнее слать так.

Хотя можно было бы и вот так забрекать отправку запроса, но тут мы попадаем в момент перед отправкой, эт пригодится трохи позже.

И так, после брека btoa имеем скрипт. Теперь над собрать по частям чего оно тут хуевертит.

Чуток потыкав, становится все очевидно.

Чекнем че такое ne тк эт и есть шифрование данных, после которого идет btoa

Довольно быстро, но и не без подсказки со стороны чела из чата, код шифрования был готов:

Подсказкой оказалось, что генерация pow (он же x, он же getD), находился на пару строк выше..

А сама вот эта хуеверть по итогу превращается в простенький цикл

И какбэ жить здорово, да, только вот оно шифрует фингер в процессе работы. А мне он нужен в сыром виде, для допила. Поэтому..

Типо вот у нас функции, каждая из них перебирается и вызывается в цикле, получая и сразу шифруя ответ. И чё?

При этом сохраняя время создания

И вот я сел пилить снятие фингера. Только вот форматирование документа приводило сразу к крашу

Тоесть вкладка с этой поеботой сразу умирала, тк впадала в бесконечный цикл. Защита блять ебучая.

Тогда я накинул манкипатч, закастомил, но вышла страшная хуета, от которой я решил отказаться.

По итогу, тот же чел из чата поделился интересным наблюдением. Скрипт умирал вот от этого кода. Получается, вся их защита строилась просто на проверке переносов

Как они настраивали эту защиту остается лишь гадать

Для обхода такой сложной защиты, я подошел к скрипту, взять за руку и сказать

Накидав еще совсем чуток кода, получилось то что я и хотел.

Убрал шифрование и попросил вертать только ориг, тк я не стал вникать в скольких пред функциях идет вызов текущей, всё равно шифрование только туть.

Отправка запроса. Было:

Стало

Чекаем. Все работает.

Чекаем в браузере, добавив наш патченый файл через локальное переопределение. Тож воркает.

Тестим через бас

Тож ноу проблем

Можно было бы и дальше копать, зачекать какие именно данные оно собирет с отпечатка, но мне резко стало похуй.

Пожалуйста, не проматывайте до середины

В этом материале я разобрал один из своих заказов, то как решал авторизацию (binance и coinmarketcap) и регистрацию (coinmarketcap) аков на запросах, их алгоритмы шифрования, а также реверс geetest slider и его решение на запросах без сервисов (онли нода, онли бас + шифрования).

Однако не все сразу, начнем чуть издалека.

Шифрования и подписи на авторизации

Понадобился мне как-то бинанс, но копировать куки из браузера было не очень хорошим решением, тк они автоматически умирали через сутки. Да, можно было повесить браузер, делать авториз и работать с ним, но мне захотелось сделать авториз на запросах, потому-что могу. А еще, через браузер, почти всегда, получается какое-то не стабильное говнище.

Начнем с конца.

Для проверки авториза и работы на аке достаточно вот этого. Я ручками взял и удалял все куки, заголовки и тд. Все остальное по сути мусор.

Тоесть достаточно всего одного кукиса p20t, который серв при авторизе дает и csrftoken (который всего-то нужно как-то получить). Хорошо, получается нам нужно узнать от куда берутся всего 2 параметра)

И я сел серчить. Когда я тыкал, пост параметры выглядели следующим образом

Тыкал я, тыкал.. и случайно мне выпала другая капча. Ну раз она на обычном гитесте, который есть на рукапче, сделать авториз выйдет еще проще.

Тоесть вот так выглядят пост данные, девайс инфо - фингер, мыло, пароль, сейф пароль и капча.

Ну оки, запросим тогда капчу. Ключ для капчи получаем так
"https://accounts.binance.com/bapi/composite/v1/public/common/security/gt-code?t="+Date.now()
Апи дока по решению https://rucaptcha.com/api-rucaptcha#solving_geetest

deviceInfo - прост фингер. по итогу оно на беке будет чекать, юа ласт авториза совпадает или нет. Тоесть в случае спиздинга куков будет фрод, тк не тот юа.

password - md5(password+email)

Ну и я такой: О, md5!

А что если бы было сложнее?
Ну воть, зашел в функцию и опять очевидно что это md5.

safePassword - sha512(password). Да, это тоже сразу очевидно..

Если вдруг, по какой-то причине это не очевидно, тыкаем дальше брек и тут прямо в коде это написано

Потыкать можно туть: https://emn178.github.io/online-tools/md5.html

А потом я еще словил.. validateCodeType: "random". Не пон, защита це или нет, капчу решать я понимаю как, ее слать и буду.

В запросеках есть вот такое. Это обычный uuid. Но эт не обязательно, чисто украшательства для статки бинанса.
x-ui-request-trace: 74274726-6d01-48fc-b885-7eb578840b84
x-trace-id: 74274726-6d01-48fc-b885-7eb578840b84

Генерю так
function uuidv4() {
return 'xxxxxxxx-xxxx-4xxx-bxxx-xxxxxxxxxxxx'.replace(/[xb]/g, function(c) {
var r = Math.random() * 16 | 0, v = c == 'x' ? r : (r & 0x3 | 0x8);
return v.toString(16);
});
}
VAR_UUID=uuidv4();

Я: наверное бинанс использует какие-то хитрые методы для индентификации юзера, а также при авторизе супер шифруют и потом как-то разгадывают...
Бинанс: no

Тоесть они прост собирают трохи инфы о фингере, в основном тут важен юа, а стартовый csrf это md5 от нихуя.

Также, чуток посерчил вебархив на предмет рест апишек интересных. В целом, их там есть и они даже работают.

http://web.archive.org/web/20171230040337/https://www.binance.com/login.html

https://web.archive.org/web/20200417073710/https://www.binance.com/en/login

Довольно интересно копаться в сурсах через веб архив.

Старая: https://accounts.binance.com/gateway-api/v1/public/authcenter/login

Нынешняя (на момент создания софта): https://accounts.binance.com/bapi/accounts/v2/public/authcenter/login

Нынешняя (на момент написания этой заметки): https://accounts.binance.com/bapi/accounts/v3/public/authcenter/login

Я даже некий прекол нашел. При авторизе можно отправить что угодно в письме на мыло юзеру. Потенциально, зная пароль можно было бы придумать какой-то фиш..

Тоесть если проходит логин и пароль, но девайс по юа новый, в device_name можно пропихнуть свой текст. Вроде и прикольно, но просто текст, более ничего запихать не удалось, а это до уязвимости не дотягивает(

Итог:

Авториз работает, банан сосатб. Вот такой скриптик по итогу вышел.

Хэшим логпас и пас.

Добавляем девайс дату, как баз64 от нашего фингера

Запрашиваем и решаем капчу

Формируем запросек на рукапчу и дергаем ответ

Ну и собственно шлем запрос авториза, а потом дергаем токен и куку, выполнил от куки хэш.

По итогу чека авториз воркал (на момент написания софта)

Я был бы не я, если б не сел чекать и дефолтную капчу. Как я потом понял, оказалось, что эт был geetest. Хотя, выглядело не то чтобы сильно страшно.

Шифрование и данные

Начнем с шифрования.

Имеем тело. Данными о решении будет data.

Напоминаю, урл банана: https://accounts.binance.com/ru/login?return_to=aHR0cHM6Ly93d3cuYmluYW5jZS5jb20vcnU%3D

И так, картинка прилетает 1 куском, получается дальше он ее режет по ширине пазла и высоту не знает, умно)

Хорошо, как обычно, открываем стек вызовов, находим хуйню. Осталось теперь понять как работает эта хуйня, а именно как формируется тело запроса.

Вариантов фона за пазлом не много и это наводит на некоторые мысли по решению самого поиска пазла. А именно, собрать фон без дырки и шукать потом отличие. Также заметим, что из исходного изображения ещё 60 пикселей слева нужно вырезать. 60 чтобы отрезать пазл и ещё 60, ТК в браузере туда ставится пазл. Но об этом трохи позже.

Тэкс. Ну, начало найдено, где бреки ставить более менее ясно.

Чуть потыкав находим ключевой поинт, от которого и будет строиться весь остальной ресерч. Это итоговый жысончег, который мы шифруем.

Вот мы получаем параметр ev.

Выведем нашу инфу в лог до шифрования.

Тыкаем далее и попадаем сюда. Видим дохуя страшную обфускацию сглаживания потока (свичкейсы и порядок действий). Где-то тут оно шифрует наше решение.

И по итогу превращает в нечитаемую кашу, а потом перегон в base64.

Ёпта, ну.. пару строк я и ручками деобфусцирую

for (var d = 0; i[o("JF1c", 218)](d, u[s(1242, "%O$2") + "h"]); d++)
p += i[s(3410, "7crc")](on, i[n("S3iz", 2013)](u[o("UlhH", 105) + n("k*^^", 1441)](d), t[r("TKH^", 2165) + c("JF1c", 2489)](i[n("u&1s", 2227)](d, t[n("Lw!2", 3103) + "h"]))));

Хуяк!

p = [];
for (var d = 0; d<u.length; d++){
p += String.fromCharCode(u.charCodeAt(d)^t.charCodeAt(d%t.length))
}
btoa(p)

Получается, оно просто выполняет xor с неким ключом t ("2p5facdc").

Бля, ну тогда надо понять от куда берется этот ключ и шифрование будет выебано.

Сравниваем data из запроса с той что я заенкодил. Всё как надо)

Теперь осталось понять, от куда берется этот ключ t и это, либо ek, либо salt.

Тыкаем по коду и попадаем сюды, где какая-то математика с ключом ek, но в реверс виде.

var c = ["a", "b", "c", "d", "h", "i", "j", "k", "x", "y"].join("")
, l = Math.floor(e.length/t);

var i = t.split("").reverse().join("")

Ну тож изи ручками деобфусцирую. На выходе получаю простой код. На вход ek, на выходе получим ключ. Тоесть тело нашли, шифрование, на удивление, тоже.

В итоговом коде это выглядит вот так

А потом отправляем запрос с нашим решением.

Я тестировал каждый этап работы, в том числе этот. Я брекал решенную в браузере капчу, чтобы запрос не улетел, а потом перекидывал все в бас, шифровал и слал на сервер, чтобы убедиться, что все собрал правильно.

Анализ шифруемых данных

Перейдем к анализу шифруемых данных и начнем собирать ev, be, dist

Напомню, что отталкиваемся вот от сюда.

ev - какая-то мини инфа о браузере, размеры экрана и какая-то странная pre.. выглядит довольно не сложно. А вот в be у нас есть el и th, в котором тоже el..

Остаются: be - движение мыши, dist - ответ. Ну, с dist всё понятно.

Получается, нужно всего лишь понять как формировать be и в целом, че это там происходит, и пол дела сделано будет.

В be у нас есть ec, el, th

Покопавшись в коде, можем найти, что оно собирает инфу по событиям. Если ориентироваться на el в th, видно как оно сейвит нажатие мыши, её движение и отпускание.

click: "cl"
mousedown: "md"
mouseenter: "me"
mousemove: "mm"
mouseout: "mo"
mouseup: "mu"
touchcancel: "tc"
touchend: "te"
touchmove: "tm"
touchstart: "ts"

Получается, но чекает координаты относительно всякой хуйни и пишет в массив.

Кажется, что в thumbnailEventList координаты только относительно квадратика.

Направил курсор на нижний левый угол, выдало координаты (0, 38), учитывая что кубик 40 на 40, а 0 в у нас от левого верхнего угла.

"me|39,20" - навел и сработал первый тригер
"mm|39,20" - появилась лапка
"md|24,20" - клик с зажатием
"mm|27,22" - тяну лапку до сюда
"me|26,22" - отпускаю лапку

В результате получаем хуйню с данными о перемещении.

"dist":133 - решение

"si":{"w":40,"h":40} - дефолт (це размер дырки)

"el" - другие параметры движения. вот те которых дохера

"ec":{"mm":80,"md":1,"mu":1} - количество событий в массиве а также количество тыков на капчу

Если выкинуть кучу данных это превращается в :
'{"ev":{"wd":35,"im":31,"de":"","brla":35,"prde":"9,35,77,59","pl":"Win32","wiinhe":657,"wiouhe":728},"be":{"ec":{"mm":80,"md":1,"mu":1},"el":[],"th":{"el":[],"si":{"w":40,"h":40}}},"dist":133}'

А если по сути, то вообще
{ev: {…}, be: {…}, dist: 133}

Не так уж на деле и страшно

Получается, что be это прост пропарс результатов
be: {
ec: {}
el: []
th: {}
}
От сюда
r={
eventCount: {},
eventList: [],
lastEventTime: 0,
thumbnailEventList: [],
thumbnailSize: {w: 40, h: 40}
}

ec - eventCount

el - eventList

th - {thumbnailEventList, thumbnailSize}

Генерация ev это конечно кек

ev = {
brla: s(),
de: "",
im: s(),
pl: pc.platform,
prde: prde(),
wd: s(),
wiinhe: pc.innerHeight,
wiouhe: pc.outerHeight
}

Что же это за хитрая функция s..
function s(){
(Math.floor(50 * Math.random())*2) + 1;
}

На деле, be не такой уж и сложный

be: {
ec: {
md: 1
mm: 80
mu: 1
}
el: [ ]
th: {
el: [ ]
si: { }
}
}

Где это просто счетчик

ec: {
md: 1
mm: 80
mu: 1
}
Большая координат движения мыши el: [ ]

Статика si: { h: 40, w: 40 }
Малая (относительно квадратика) группа движения мыши el: [ ]

Генерация данных

Штош, разобрались с реверсом шифрования и поверхностно с данными, осталось понять, как генерировать эти самые координаты.

Начнем сначала. У нас оно чекает координаты.

Чуть деобфусцируем и получим

var u = e.getBoundingClientRect()
, l = Math.round(t.clientX - u.left)
, d = Math.round(t.clientY - u.top)

x: Math .floor(l).toString()
y: Math .floor(d).toString()

Получается, шо это код, который дергает относительно этого маленького пазла, как было замечено ранее.

По сути просто вот эти значения - старт значения кнопки.

Для генерации времени использует (new Date).getTime()

Напомню, у нас есть несколько типов событий:
click: "cl"
mousedown: "md"
mouseenter: "me"
mousemove: "mm"
mouseout: "mo"
mouseup: "mu"
touchcancel: "tc"
touchend: "te"
touchmove: "tm"
touchstart: "ts"

Фул блок капчи на самом деле содержит много областей. В зависимости от того, куда я навел мышку, кликнул и тд, выводится соответствующее событие.

Пример набора событий.

0: "im|mm|355,284|1648175834425|1"
27: "im|mm|120,385|5|1"
39: "shim|mm|85,397|10|1"
40: "wi|mm|84,398|7|1"
50: "slth|mm|76,416|10489542|1"
51: "wi|mm|282,505|882163|1"
52: "wi|mm|378,413|1994077|1"

Действие над im, тип действия mm - навел на картинку

Действие над shim (пазл), mm - навел на картинку

Хорошо, раз у нас дохуя всяких областей, разберемся какие вообще мы имеем области:

wi - область окна капчи

im - область картинки пазла

shim - область полоски для пазла

sl - область слайдера. скорее всего, за исключением область квадратика и надписи

trtx - область надписи на слайдере

slth - область квадратика слайдера, исключая иконку

ar - область иконки на квадратике слайдера. В идеале, в ней и нужно двигаться при решении.

Имеем области:
wi - область окна капчи
im - область картинки пазла
shim - область полоски для пазла
sl - область слайдера
trtx - область надписи на слайдере
slth - область квадратика слайдера, исключая иконку
ar - область иконки на квадратике слайдера

Имеем события:
click: "cl"
mousedown: "md"
mouseenter: "me"
mousemove: "mm"
mouseout: "mo"
mouseup: "mu"
touchcancel: "tc"
touchend: "te"
touchmove: "tm"
touchstart: "ts"

Может возникнуть резонный вопрос нахуя нужно вот это? А вот в чем фокус:

0: "im|mm|355,284|1648175834425|1"
27: "im|mm|120,385|5|1"
39: "shim|mm|85,397|10|1"
40: "wi|mm|84,398|7|1"
50: "slth|mm|76,416|10489542|1"
51: "wi|mm|282,505|882163|1"
52: "wi|mm|378,413|1994077|1"

0: "|22,2"
1: "mm|22,2"

Ещё раз 50: "slth|mm|76,416|10489542|1"

И 1: "mm|22,2"

Второй массив отражает движение мыши только относительно квадратика,
а основной - первый, в нем и время в миллисекундах и координаты. Получается мы можем получить второй из первого по сути.

И тут я прикинул, что закодить это все будет не очень просто. Ну точнее, мне не очень уже хочется так сильно ебаться. И кто-то наверное спросит "а почему бы просто не заюзать windmouse?", а я, который о ней узнал только после того как сделал софт, отвечу:

А потом я покумекал и решил чекнуть "что если решать имитируя телефон?". Должно же быть ну явно по проще. И таки да.

Всего лишь один простенький массив нужно генерить и всё. Еще раз, нам нужен только el для be (большой), а для "th":{"el":[].. уже не нужен. Не то чтобы это прям на сильно проще, но точно не сложнее)

Дергает оно инфу о положении с тачскрина:

clientX: 42.66666793823242
clientY: 509.3333435058594
force: 1
identifier: 0
pageX: 42.66666793823242
pageY: 509.3333435058594
radiusX: 15.333333015441895
radiusY: 15.333333015441895
rotationAngle: 0
screenX: 366
screenY: 520

Да, нам все еще нужно чекать положение пазла относительно всей высоты страницы, но лучше генерить 1 хуйню, чем 2.

Учитывая логи выше, получается, нужно зажимать только иконку стрелки, чтобы мозги себе не ебать. 44х44 - кнопка, 24х24 - иконка.
Тоесть: x = 40+((44-24)/2)+random(0,24)

slth словил на координатах, которые означают левый край, тоесть все оки.
x = 40; y = 510
at словил тыкая тож в край иконки
x = 54; y = 524

at словил тыкая тож в край иконки
x = 52; y = 520

Получается следующее:
Минималка: x = 50; y = 520
Максималка должна быть: x = 50+24=74; y = 520+24=544
Но это в рамках начального положения.

Для теста сложил время начиная с первого значения массива:
"ar|ts|61,526|1648212768794|1"
от 1648212768794, получилось 6419

Вычел от lastEventTime: 1648212775213, получил то же значение
значит я все правильно посчитал. А значит, время действительно правильно посчиталось. Единственное, дало пол секунды хз откуда.

Хорошо, перейдем к итоговому решению. Задаем константы.

Шизо генерация.. Вместо того, чтобы юзать windmouse, которая вероятно и в бас стоит, я наговнял свой алго ветренной мышки.

По итогу генерится вот такая красота.

С другой стороны, блять, оно ведь, действительно, по итогу работало..

Решение пазла

Вернемся немного назад, ведь нужно же еще и само положение ответа как-то найти.

Классически слайдер решают собирая фоновую картинку без дырки и сопоставляют с той что в задаче.

На это я намекал чуть ранее.

Но работает это, когда картинок фона не много, а хотелось бы чет более универсальное.

Также, на форуме бас были 2 старых решения.

В обоих суть сводилась к поиску кусочка пазла на картинке.

Но в этом подходе качество было крайне скверное. Поэтому, как всегда, я решил пойти своим путём.

Общая тактика решения должна свестись к тому, что первым шагом мы подрежем мини пазл и чекнем его положение, далее кропнем картинку по высоте этого пазла, а потом как-то надо будет найти куда его двигать.

Я стал разгонять, а как можно улучшить картинку, убрать всякий мусор, чтоб искало положение лучше, чем бас это делает дефолтно. Погонял разные фильтры:

Перегон в серый

Уменьшение цветов

Я пробовал делать перегон в чб по порогу (нативными средствами бас)

Ну и оно вроде как работает, причем довольно неплохо.

Но результат был не достаточно хорош для меня.

В процессе работы также возникла очень странная бага: на картинке нельзя было рисовать через бас.

Скриним, рисуем на картинке и.. ни ху я

Берем картинку в base64, получаем айди, применяем по айди формат в жпег,, получаем base64, получаем опять айди и рисуем прямоугольник.

Я хуй знает почему, но даже на скрине не позволял рисовать. До сих пор не разобрался.

Оператор Собеля

Кароче, шукал я, шукал, и потом я наткнулся на это (Алгоритмы выделения контуров изображений):

Оказалось, что это база в обработке изображений. (Более подробная инфа про фильтр собеля с хорошим кодом есть туть). Тоесть, во всяких спец либах типо OpenCV именно так и решают мою задачу

Прогнал свою картинку на одном из сайтиков и понял, что это именно то что я искал. Онли пазл, ни каких цветов, ни какого мусора.

Детектор границ Кенни (Canny)

Чуть поискав дальше, я нашел, что у этой задачи (выделения краев) есть допил на фильтра собеля, чтоб лучше фильтровать мусор. Это был алгоритм кеннни/кэннни/канни.

Я искал то, что работает без канваса, в 23.2.2 и тут (в canny-edge-detector) всё работает. Это доп либа для библиотеки image-js, либы с кучей фич для обработки изображений.

Даже код понятный.

Очень простой и логичный подход, но на удивление эффективный. Просто переводим картинки в серое, уменьшая тем самым шум от цветов, упрощая картинку, затем применяем фильтр Гауса, чтобы добавить мыла и уменьшить количество деталей, а после восстанавливаем детали фильтром собеля (алгоритмом поиска края). Тем самым мы оставим только важные детали на картинке и получим чб. По итогу мы получим только очертания, без всякого мусора. При этом, размечать ничего тоже не надо. Иные подходы к слайдерам я разберу в одной из следующих статей.

Я накидал простой код..

И в итоге оно сработало!

Поэтому я сразу же решил упаковать все в модуль.

Юзать ноду конечно прикольно, но иметь 1 готовый блок на много прикольнее. Для этого я и сделаль сасный прекрасный модуль

Чуть потыкав код модуля, обнаружил, что в меню можно нарисовать практически что угодно. Гифку, видео.. Ну я и нарисовал.

Чет похерилось качество при конвертации в гифку.

Анимаш очка

И еще..

В итоге остановился на более минималистичной анимации, прост чтобы что-то мелькало.

Че вышло по итогу?!

Дергаем мини пазл, отрезая X по фиксе и Y по прозрачности (сверху вниз).

Докинем контуров, кроп фона и поиск картинки в картинке.

Объединив генерацию мышки и шифрование тела из прошлых разделов с решалкой можем начать тестить.

Ну и все ебашит по красоте. Единственное, в половине случаев ему не нравились движения мышки. Фрод типо. С другой стороны, у меня и руками оно решалось через раз.

99% решения, сука. Не решилась всего одна ебучая картинка.

Преколы

Помимо этого нашел еще всяких приколов. Тогда я открыл для себя huggingface, где увидел кучу нейронок. Оказалось, что детектор края делают и на нейронках (нахуя, не очень понятно, но наверное в этом есть смысл).

Ну и типо это все бесплатно. Тоесть оно решает и гугл и hcaptcha и эт готовые модельки. Как гитхаб, только для нейронок и с демками.

Оказалось, есть алгоритмы генерации всякой хуйни на фракталах.

Вот такую всякую хуйню я почекал. Времени въебал конечно много, но было довольно весело.

Ну и казалось бы фсе, но нет..

Спустя пару недель, как я разъебал банан, спросили "могу ли я на заказ сделать coinmarketcap (авторизация и регистрация)?". Ну я и решил чекнуть че же там, со стороны выглядит, что банан, что coinmarketcap, примерно как одна хуйня.

А потом я такой: лол они просто капчу банана поставили.. и домен в капче банана.. и подписи банана.. и кучу еще чего как у него. хм.. слишком уж все похоже.

Интересно, конечно, что линка на капчу до сих пор валид: https://public.bnbstatic.com/image/antibot/image/SLIDE/20220804/01/f4b6ab69cf7f42939d9a0c77eacfea29.png

Регистрация

Хоть капча и та же (как и всё остальное), на всякий случай проведем поверхностный ресерч.

И csrf токен в урле, как и в банане, md5 от нихуя

В случае с бананом я прост 1 раз снимал свой фингер и юзал его, но раз это заказ, много аков.. желательно и этот момент по красоте порешать.

Поэтому, нашел все данные для генерации фингера - deviceInfo и его подпись fingerprint. Для полноты картины нехватает только 3х подписей x-se на реге (x-se-bh, x-se-pd, x-se-rd) и Fvideo-Id. Фингер, кстати, подписывается через MurmurHash3 (x64hash128).

Про MurmurHash3 из либы fingerprintjs я писал уже на примере yahoo. Открытые сурсы либы нашел на каком-то гитлаб через гугел.

Штош, раз ясно что собирать, накидаем скриптик.

o = {
screen_resolution: i.screenResolution,
available_screen_resolution: i.avaScreenResolution,
system_version: Rt(),
brand_model: _t(),
system_lang: r.language,
timezone: Mt(),
timezoneOffset: r.timezoneOffset,
user_agent: r.userAgent,
list_plugin: Pt(r),
canvas_code: Bt(r.canvas),
webgl_vendor: n.vendor,
webgl_renderer: n.renderer,
audio: r.audio,
platform: r.platform,
web_timezone: r.timezone,
device_name: Et()
}

Данные тянуть можно из бас фингера, разве что аудио и обычный канвас не получится.. можно сделать нормально их, а можно чисто шума туда въебать, всеравно это хэш, а на фрод оно тут не повлияет)

Ну я и накидал за пару минут.

В отличие от банана, тут было еще некоторое количество дополнительных приколов, например подписи в заголовке, те самые x-se. А x-request-id, как и у банана, это тупо uuid4, а именно - uuid4().replace(/-/g, "")

Ну и.. вот они, осталось деобфусцировать.

Опять тело с хуйней как у капчи, опять xor по ключу. Хотя стоп, че это блять за координаты ебучие. Заметим ключик "abcddcbabadc7hbw", он нам еще пригодится)

Оказалось, оно тречит как чел тыкает вводит форму, это и есть подпись x-se-bh.

Я взял и деобфусцировал ручками эту хуетень, получив код. Ксорим мы как раз с "abcddcbabadc7hbw". Причем, как оказалось, он статичный.

Хорошо, перейдем к следующим подписям

Возьмем подпись x-se-rd. Мы енкодим какую-то рандом строку?!

Отреверсим алгоритм и получим.. такой же код как и для прошлой подписи. И ведь с x-se-pd ровно то же самое.

Заметим, что дополнительно каждая подпись енкодится еще одним алгоритмом

Задекодим его и получим ровно то что ожидали. Однако, статичное число 1100..

Я почекал и оказалось что оно считается из длинны. И тут я подумал, ну а что если я возьму сделаю по шагам енкод, а потом наоборот декод, у нас ведь ксор. И это, действительно, сработало.

Так на много удобнее работать с этими подписями. Увидел, закинул в свой алго, декодировал и чекнул че там.

А актуален ли этот код? Да, перед выпуском данного материала я чекнул coinmarketcap и оно реально до сих пор работает.

x-se-pd и x-se-rd похожи на рандом. Потыкав чуть код (пол часика тыкал код деобфусцируя через консольку), я убедился, что это и есть рандом. Тоесть рандом + контрольная сумма от него. Назвал я этот алгоритм hueta.

Итоговый код. Скорее всего, они они чекают тайм штамп в этой псевдо рандом подписи.

Вернемся к подписи x-se-bh, тк её же надо тоже генерировать..

А шо нам тут собственно надо?
ec - счетчик каждого вида в el
el - набор всех движений
mt - статик параметры полей
sg - хуета хеш от el
si - сумма всех элементов el
t - текущее время

Ну, с sg всё понятно

А вот el.. бля, генерить дату под ввод каждого символа будет ооочень дрочно. Это получается, над учитывать длину вводимых данных, скорость ввода имитировать.

И тут я подумал, можно же просто взять и сделать ctrl+c ctrl+v, как я люблю. В смысле, имитировать копировать вставить и эт сильно упростит мне задачу.

0 - номер блока
ts - тип события
1659865878895 - время старта
128,184 - координаты относительно всего экрана
112,28 - координаты относительно центра объекта

Для события keydown не нужны ни какие координаты, как и для touchend, но тут добавляется всё равно черт очка -

Я проделал все действия и заготовил образцовый шаблон.

Образцовый шаблон:
0: "0ts1659871850308-178,184-163,28"
1: "0te114-,"
2: "0k31"
3: "0m9-179,184"
4: "0d1-179,184-163,28"
5: "0u3-179,184"
6: "0k156"
7: "1ts6204-170,286-155,26"
8: "1te98-,"
9: "1m9-171,287"
10: "1d2-171,287-155,27"
11: "1u9-171,287"
12: "1k78"
13: "1k257"
14: "2ts1977-186,532-171,32"
15: "2te219-,"
16: "2m53-187,532"
17: "2d4-187,532-171,32"
18: "2u5-187,532"

Тыкаем на поле, потом жмем кноп очки копировать вставить, потом отпускаем и еще 1 раз но на второе поле, а потом тыкаем на кнопку отправки и тоже отпускаем.

touchstart
touchend
keydown
mousemove
mousedown
mouseup
keydown
————————-
touchstart
touchend
mousemove
mousedown
mouseup
keydown
keydown
————————-
touchstart
touchend
mousemove
mousedown
mouseup

Я всё это перевел в код

А потом собрал всё в более полный вид. Изи)

Так, с этим разобрались. В итоге, чё по хэдерам?

Пройдемся по порядку в хэдерах запроса реги
URL запроса: https://api.coinmarketcap.com/auth/v4/user/signUp
1) x-csrf-token= о, он приходит в ответ на первый запрос
2) Дефолт хедеры:

• accept: application/json, text/plain, */*
• accept-encoding: gzip, deflate, br
• accept-language: ru-RU,ru;q=0.9
• cache-control: no-cache
• content-length: 164
• content-type: application/json

3) cookie имеют тут Fvideo-Id 33899f3fa49a9da38d94435ff364252d052666b5, но больше там ничего нового или страшного нет, кроме sensorsdata2015jssdkcross..
4) device-info ну эт фингер
5) fvideo-id та самая золупа которую я и буду дальше ковырять
6) x-request-id: 6648b1f9fc3541ddb46540b670cd2b50 - uuid4
7) Дальше подписи, как генерить их уже ясно, осталось данные научиться правильно готовить

Кстати, это тоже uuid4: "X-UI-REQUEST-TRACE", "X-TRACE-ID", "BNC-UUID"

Чекал я Fvideo-Id, но ни где его не было и я уж было начал думать, что это какая-то генерация, но нет, он есть в ответе.

Запросек https://api.commonservice.io/fvideo/tenant/sign/web?en=CXU&t=cmc

А получаем мы его отправив фингер

От фингера deviceInfo оно отличается неймингом и парой доп параметров, в остальном смысол одинаковый. Главное, канвас и аудио хэш совпадают, это наверняка и чекают

До него улетает запрос на странный урл со словом antibot: https://api.commonservice.io/gateway-api/v1/friendly/antibot/coll

Параметр c не base64, потому я попробовал декодировать как подписи до этого. И оно сработало.

Обратим внимание на 52ce8bda-04ee-4fec-bea1-2c2781d992f7.

Тоесть мы сначала шлем https://api.commonservice.io/gateway-api/v1/friendly/antibot/coll и после этого запрашиваем Fvideo-Id, при том передав один и тот же идентификатор. Так как это все на одном домене, закономерно предположить, что это отдельный антифрод.

Тогда антибот тож нужно пилить..

se_ данные эт рандом с таймингом и контрольной суммой, как и в хэдерах ранее.

А вот ev это еще один фингер. Даже парочку страшных слов есть, корс, языки.. ужос.

На самом деле, тут ничего страшного нет, чуть ручками деобфусцировать и готово.

hl - window.history

ivw - ('$cdc_asdjflasutopfhvcZLmcfl_' in document) || !!i['webdriver'] || ![];

ismo - /Android|webOS|iPhone|iPad|iPod|BlackBerry|Mobile/i.test(navigator.userAgent) || 'ontouchstart' in window || ('orientation' in window);

cors - window.XMLHttpRequest

Чё по кукам?
1) sajssdk_2015_cross_new_user=1;
2) sensorsdata2015jssdkcross={"distinct_id":"1827ee10e6213e-07d1158fc471378-5437971-250125-1827ee10e6a12d","first_id":"","props":{"$latest_traffic_source_type":"直接流量","$latest_search_keyword":"未取到值_直接打开","$latest_referrer":""},"identities":"eyIkaWRlbnRpdHlfY29va2llX2lkIjoiMTgyN2VlMTBlNjIxM2UtMDdkMTE1OGZjNDcxMzc4LTU0Mzc5NzEtMjUwMTI1LTE4MjdlZTEwZTZhMTJkIn0=","history_login_id":{"name":"","value":""},"$device_id":"1827ee10e6213e-07d1158fc471378-5437971-250125-1827ee10e6a12d"};
3) _ga=GA1.....; _gid=GA1.2.1...;
4) se_sd=gUKVhWRwDRVGQ4HxaCBlgZZF1AgkNESW1tWBcVEN1hdWwVlNXVIO1; se_gd=hNTVhUhgRHAUVBVlSCgggZZXQElUGBVUFoSBcVEN1hdWwDlNXVcM1; se_gsd=XjEgOzBhLCM0CQUxNAw2Ci0xEgFXAQBXV1lBW1NWVlhbAlNS1;

sensorsdata2015jssdkcross

Вообще, это вроде какие-то чисто китайские кукисы.

А вот se_.. непонятно только от куда берется se_gsd

se_gsd берется из ответа на этот запрос + немного доп обработки.

"T1LVF1UUlBUAlNwAgwYBQMIUVpkIDM2IQMxDjE3VgMhFSdyLDA0w9223q9dj04".split('').reverse().join('')

parseInt("40jd9q3229w0ADLydSFhMgV3EjDxMQI2MDIkpVUIMQBYwgAwNlAUBlUU1FVL1T".length/0x5)

А такая функция у меня уже есть

Еще встретил в процессе реверса какие-то преколы.

Как я сделал по итогу

Мне было лен парсить и форматировать фингеры баса, поэтому я сделал html страничку и прогнал на эмуле скрипты с установкой фингера.

Ну а далее все как было ранее, формируем фингер и докидываем хэш, формируем из него фингер для fvideo, дергаем кукисы, касуем генерацию sensorsdata2015jssdkcross, формируем sd_ подписи и проходим antibot, получив fvideo.

А далее автори. Кастуем подписи, получаем куки, решаем капчу, пытаемся войти по токену качпчи.

С капчей все как было разобрано ранее. Получаем, режем, решаем, получаем токен решения.

В итоге, все работает. Не удивительно.

Единственное, модуль на 23.2.2 бас в 12 ноде перестал работать, тк тянул новую версию image-js с какой-то багой. Хотя на новом бас в 18 ноде оно работает нормально. Для 23.2.2 я нашел ласт валидную версию - 0.21.9 и фиксанул модуль.

Авторизация

И тут меня ждал сюрприз. Я делал под слайдер, а тут не слайдер. Тут хуйня как у бинанса. Нахуя я тогда вообще ебался со слайдером?

Я начал тыкать капчу, презагружал много раз, переключал на регу. И случилось чудо. Я обнаружил "фичу" с подменой капчи)

Цимес тут вот в чем. Нельзя просто так взять и получить капчу. Капча привязана к "приложению", а именно токену который оно возвращает. Тоесть при запросе авториза оно вертает securityId (securityCheckResponseValidateId)

По этому айди вертает только капчу приложения, тоесть что бы я не написал biz mode (CMC_register например), оно вернет такую капчу, какая положена для этого ендпоинта.

Только вот есть нюанс. Я могу получить капчу слайдер для регистрации, а токен решения потом применить на авторизации)

Собственно, это я и сделал, запилив по итогу фул рабочий софт всего с 1 капчей.

Все ебашит по красоте)

А почему не соло?

Потому-что у меня есть дохуя потоков чтобы выебать бинанс)

Дополнение

Чёт я решил ещё раз почекать бинанс перед публикацией и случайно наткнулся на демо страницу, страницу с капчей и без шифрования. На её примере на много проще понять всю эту хуйню.

И так, у нас есть тело

Чекаем вызовы

Чуть выше видим формирование тела решения капчи

Перейдем тогда сразу к шифрованию. Видим ультра гига мега шифровку на ксор в пару строк)

У меня по итогу ручной деобфускации вышел тот же код по сути.

В мое случае также sig была в качестве контрольной суммы, но туть она прилетает сразу.

Чекнем ev. Штош, без обфускации выглядит совсем не страшно

Ну, а c be тут все тоже на много яснее.

Я искал файл который дебажил (с обфускацией), но он не сохранился, благо на скрине осталось название, а потому я смог дернуть искомый файл)

Я думал, что в проде данная капча уже не юзается, раз сурсы открытые. Но оказалось шо нет, до сих пор висит на каких-то эндпоинтах.

А это значит, что можно подсунуть её токен в любой эндпоинт)

Цель жизни - въебать тутаноту (или хотябы тикток).

В очередной раз, все началось с вопросика в чате

Я в ответ в чатике написал небольшой обзор подходов, как ее можно было бы решать. И сразу написал в лс автору вопроса и.. игнор, час, два. Кто вообще спит в 5 утра? Хотя на след день мне уже ответили.

А я вообще-то потыкать ее хотел. Нахуя тогда было спрашивать..(

• Как узнать время по часам https://ru.wikihow.com/%D1%83%D0%B7%D0%BD%D0%B0%D1%82%D1%8C-%D0%B2%D1%80%D0%B5%D0%BC%D1%8F-%D0%BF%D0%BE-%D1%87%D0%B0%D1%81%D0%B0%D0%BC
• Аналоговые часы на JS https://gohtml.ru/js/82-canvas-s-nulya-analogovyie-chasyi-na-js
• Часы отрисованные canvas https://ru.stackoverflow.com/questions/859941/%D0%A7%D0%B0%D1%81%D1%8B-%D0%BE%D1%82%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5-canvas

Тогда я подумал: В пизду, сам блять найду эту капчу и выебу ее нахуй

И где же я ее нашел? в Яндексе, а в Гугле блять нихуя! Хотя, странно что оно гит коммит проиндексировало.

https://github.com/tutao/tutanota/commit/23017c06e4291acf9cd9265749ec055cc4ac78bb.patch

https://github.com/tutao/tutanota/commit/23017c06e4291acf9cd9265749ec055cc4ac78bb

https://github.com/tutao/tutanota/blob/f52ac6e09af03925863d76410fd0862b147c58f4/src/subscription/Captcha.ts

https://github.com/tutao/tutanota/blob/c3637bf6487431c7383b49da033e894adc19bd06/test/tests/subscription/SignupFormTest.ts

Еще было обсуждение на форуме зенки. Я мельком почекал, но чужие решения мне не сильно инетересны

Нашел про капчу часы в блоге протона, но примера не нашел там https://proton.me/blog/captchas

Похуярили

Даже зная что искать, капчу получить мне удалось не сразу, пришлось по перебирать прокси.

Сразу бросается в глаза то, что часы разных размеров и расположены в разных частях картинки. Тогда над для начала кропнуть их.

Проходимся по всей картинке, ищем границы чекая черные пиксели.

Кропаем картинку по полученным координатам. Пока всё довольно просто.

Акей, теперь мысля следующая, нам надо как-то рисовать круги зная радиус. Я решил поискать другой варик, не тот что скинул в ориг ответе, чуток погуглил и нашел ответ на хабре https://qna.habr.com/q/623933

И в итоге накидал следующий код, чтобы рисовать кружок.

Я перегнал градусы в другую систему координат, чтоб можно было считать позицию X и Y.

Прошелся по всему кругу, увеличивая позицию на шаг. Тк шаг мелкий, а пиксель большой, сейвил позицию ласт пикселя, чтобы 2 раза его не считать потом. Дополнительно +радиус к позиции, тк в радианах оно считает типо от центра, а у нас 0 это лево верх.

Докинем лог и получим чет типо этого, если чекать и менять цвет пикселя. Тогда остается сделать так, чтобы проходило по кругу в некотором диапозоне и как-то понимать где какая стрелка.

Если мы будем двигаться из центра наружу, то нам получается нужно найти сначала центр, выкинуть центральный круг и двигаться от его позиции, потом найти первый пиксель и засейвить его положение в градусах, чтобы следить отдельно тк мы не знаем какая именно это стрелка. Потом ждать на каком из диапазонов, первом или большом, кончается черные пиксели, что в итоге и станет ответом на вопрос какая первая была стрелка. Если обе были на 1 позиции, то во втором диапазоне изначально не будет черных пикселей.

Я не очень умный, поэтому подумал сделать все наоборот, искать первую - большую, а потом мелкую, двигаясь из наружи к центру.

А еще, вдруг картинка повернута, как например тут или хуже, значит над в любом случае будет искать где начало.

На самом деле, в любом случае нужно искать границы для стрелок, чтобы учесть ситуацию, где обе стрелки в 1 положении, иначе оно будет ебошить либо в 0, либо на край капчи и проще сразу это учесть)

И так уж совпало, что начало - цифра 1, всегда прорисована твердо и четко, поэтому я захардкодил ее поиск. Делим на 8 частей и в 4 ищем длинную прямую палку.

Двигаемся сверху вниз (y), справа налево (x), чтоб быстрее добраться и прийти от зеленой точки к синей. Ищем черный пиксель. К синей (левому краю), тк в ситуации с зеленой стрелкой (12-60 минут), у нас самой нижней точкой может оказаться стрелка, а нужно получить нижнюю точку единички, потому ищем макс нижнюю левую.

Она будет нашим отступом от края по всей длине окружности.

В итоге получим вот такую границу.

Теперь надо найти границы центрального кружка, чтобы установить нижнюю границу для диапазона поиска. Я просто двигался в 4 стороны по 1 пикселю, пока не встретил не черный на как минимум 2х позициях.

В итоге я все накидал, но столкнулся вот с такой хуйней. Я не оч умный, хоть и видел всякое дерьмо, но даже я ахуел. Хотя казалось бы, база.. (зеленым выделил диапазон, который скипается при проверке).

Речь про лог. Если чекнуть внимательно, видно как на переменную в итоге влиял реверс. Массив перемешивается в процессе работы, блен, это ж типо другая функция.. хуле оно так делает. Зелененький диапазон распидорасило, неприятненько.

Вот более простой пример, чтобы было понятно о чем речь.

Все дело в старом советском .. Копировани объектов и ссылки и нет, const тут не поможет. Вот еще пример.

Ебучий, сука, JS, блять, ебучее программирование.

Да, это говнокод.. Но суть не поменялась, через searchPos мы перебираем круги и чекаем ответ и сервим черные пиксели, при том передавая диапазон если нашли первую стрелку. А через getPos просто рисуем кружок и собираем черные пиксели, исключая диапазон, если он передан.

Также важно не забыть, что у нас на часах 0 там где 12, а у тригонометрического круга там где 3 и при том, на нем отсчет против часовой, поэтому надо докинуть 90 градусов и потом пересчитать их. Всё довольно логично.

Функцию определения координат предложила чат гпт.

Ошибку я случайно заметил на тестах, тупо вхуячив ее код.. ненадо так делать.

8:60, очевидно, не пройдет валидацию

Я ее трохи поправил, чтоб округляло времени до 5 минут - нашего шага в капче.

Ебац, роботаит

И для часов пофиксил округление, чтоб не было как на центральном примере (9:00).

Однако, я не мог остановиться просто на одной капче и решил сделать регер.

Реверс!?

Ну я и сел тыкать че же там после капчи.

А после капчи какой-то пиздец. Более того, еще и минуту ожидания зачем-то (pow).

Ладно, поехали разбираться с проблемами по мере поступления.

Начнем с signup.

Другое дело) Тогда можно будет тупо фул код подрезать..

Трохи поресерчим, что тут происходит

Ясна понятна, криптография ебучая значит

Хмммм.. https://www.npmjs.com/package/@tutao/tutanota-crypto?activeTab=explore

Штош, раз просто так взять и поставить либы нельзя, летс гоу хэнд джоб

Ну а потом я тупо взял и перенес каждый файл, добавил все нужные импорты и фсе. Всего-то 2 дня ушло.. (если правильно помню)

Как он работает? Ну.. он работает.. да.

По сути я тупо подтянул весь код который был нужен из всех файлов и чуть поправил. Наверное можно было проще, спиздить из воркера, но я не догадался.. или не получилось, не помню уже.

Ещё, вот эт хуйню вынес в отдельный блок, она по сути и майнила минуту у меня ключи с браузера. https://www.npmjs.com/package/jsbn-rsa

Утечка памяти в бас

По порту файлов в ноде баса я спросил у Ghost, и он поделился багой - утечкой памяти и ее решением.

Тоесть нужно сейвить в глобалку, чтобы постоянно не дергать файлы.

А я прост в объект все сейвил и фсе. Кароч, наверное так не надо делать.

Тесты

Тутанота сосатб. Капча решается.

Рега проходит

Код работает. Я вообще в ахуе, что оно без всяких тестов завелось. Столько кода и сразу все работает. Вот что значит копипейст)

Но письма слать с ходу нельзя, хоть я и не собирался.

Когда я увидел, что это все рил работает, я такой:

Вы думаете что с человеком, который вот до такой степени точно исследует тему можно спорить? Вы думаете что я вас не переиграю? Что я вас не уничтожу? Я вас уничтожу!

А началось все как обычно. Некоторое время назад мне прилетел вопрос

И кто-то щя подумал: Ооо, очередной букс помойка.

Однако. Вы тыкаете буксы, чтобы заработать копейки, я потому что их весело ебать.

Я уже сталкивался с похожей капчей, тогда это была икон капача. Нужно было просто найти 1 картинку отличную от других.

Дуглас в чате тогда (дохуя давно) предложил (не ебу сам он додумался или нет), что раз отличная картинка одна, сравним просто самую первую с остальными, если у первой со всеми одинаковая схожесть эт и есть ответ, либо если есть какая-то, что сильнее отличается от первой чем остальные, то ответ уже она. Довольно простая идея.

Мне она не понравилась. Я использовал подсчет траста каждой картинки (сравнение каждой с каждой). В перспективе это сработало бы и при наличии шума на картинках.

Ну и как будто бы, с моим подходом при наличии шума и поворота ничего сильно не поменялось бы. Нужно всего лишь докинуть еще 1 (2) цикл чтобы сравнивать все виды 1 картинки с вариантами других.

И так, генерим тест массив для визуализации манипуляций с чиселками, чтоб не наебаться потом с картинками. Создаем каждой "картинке" 8 вариантов положения: 4 поворот и еще 4 для каждой - отзеркаливание.

Чтоб не сравнивать с собой, есть резон добавить if (i === j) {continue;}

Атлишна. Осталось добавить счетчик макс значения, чтоб не была такая огромная ебала на 64 варианта каждая, а всего 4 варианта с ответами.

Чел утром:

Чет до меня только к утру дошло, что изначальный вопрос был не про иконкапчу, а про похожую, а я уже иконкапчу почти разъебал.

Штош, ну тогда добьем её.

Кстати, сурсы самой капчи с иконками https://github.com/Agence-MIBE/IconCaptcha-Plugin-jQuery-PHP/blob/master/assets/icons/light/icon-1.png

Похуярили

Начнем с простого, с реверса. Так, ну токен изи, он в первом запросе.

Тело запроса. Тоже изи.

widgetId обычный uuid

Тайм штампы тоже изи, 0 обфускации - 0 проблем

При отправке решения используется challengeId, эт uuid с сервера в теле ответа на запрос капчи, а challenge там эт сама картинка.

Прогнав пару капч, можно заметить, что размер фул капчи всегда фикс, а количество иконок (задач) внутри 5-8. А еще, мы можем пройтись вверху с шагом в пиксель посчитать количество черных писелей фильтруя по альфа каналу, это будет количество частей (+1).

Докинем парочку функций и веселая нарезка готова. Код максимально простой.

Ну и всё бы ничего, если б картинки определялись нормально, только по итогу нихуя не получалось их нормально сравнить.

Я потыкал разные алгоритмы иии.. нихуя. Казалось бы, дохуя алгоритмов, но блять, простой сдвиг в пару пикселей и оно уже нихуя не видит. Однако..

Используя image-js я написал перегон 1 картинки в 8 и дополнительно каждой мыло и сжатие до 20% + еще пару фильтров. И в итоге это сработало.

Видишь слева такую полоску хуйни? Это всё картинки, уменьшенные и замыленные. И попарно все они сравнены (4090 сравнений).

А 4090 сравнивания - не дохуя? Оказалось, что нет, решает мгновенно.

Примечательно, что без уменьшения и доп фильтров работало крайне ебано, возможно еще прозрачность самой иконки тож рандом.

В простой версии капчи я делал накопление траста для каждой картинки и его юзал как метод для определения картинки, которая больше всего отличается от остальных.

Сейчас получилось по сути то же самое.

Я беру список коллекций (вариантов картинки: повороты и отзеркаливание) для каждой картинки. Первые 2 цикла перебирают коллекции 1-8 сравнивая их друг с другом. Чтобы сравнивать элементы коллекций есть еще 2 цикла (тк сравниваем 2 коллекции). Если какая-то картинка из коллекции нашла пару в другой, пишем collection_trust +1. Еще добавил пару прерываний цикла, чтоб если похожую картинку нашло, не искало дальше.

Через getSimilarity из image-js я сравниваю картинки и говорю совпадает или нет.

По итогу в trusts мы будем иметь инфу о количестве пар у каждой картинки.

Ну а дальше просто дергаем индекс макс элемента

А теперь можно и тесты провести. По итогу всего 1 ошибка, возможно, надо с порогом чуть поиграть, щя стоит 90%. За 300 тестов всего 1, довольно неплохо. Предположим, что качество решения 99,9%)

На картинке выше представлено 3 подхода к решению:
1) Просто вызывать код через консольку и не вникать че там (easy)

2) Юзать имитацию дум например window на основе jsdom (medium)

3) Реверсить и разобраться как же все-таки работает код (hard)

Похуярили

1) И так, я открыл запросеки, увидел следующую хуйню и решил чекнуть че куда.

2) Подошел, взял за руку и сказал твердо и чётко: ctrl+shift+f. Изи.

3) Ставлю бреки на старте функции на прочек, тк у нас жысончег на выходе.

4) Зачек через консоль очка. Вызываем код и смотрим че происходит. Он вертает результаты вычислений. При том, результат всегда одинаковый. Оки, вход найден, осталось понять как оно это делает.

5) Казалось бы, вертает объект с циферками, а в начале они собстна и есть, но хуй там плавал, оно еще и считает чето, тоесть код получается динамический и весь код (ну почти) и есть по сути шифрование. Оки, тогда как жить то блять? Надо чекать дальше.

6) Я просто скопировал весь код нахуй и отправил на http://jsnice.org/, чтобы привести к более читаемому виду. Переменные стали чутка понятнее, да и в целом приятнее смотреть. Посмотрим, сломался ли код или все норм.

7) Создал файлики и подрубил код к html шаблончику, чтоб дебагать код изолированно. Установил див куда вывести текст для сравнения. Вывод в обоих файлах направил на див. Почекаем норм ли работает файл с читаемыми переменными.

Тоесть я в самом начале нашел где оно там ответ дергает и вхучил туда свой кусок кода, чтобы выводить результаты на страничку. Затестил иии..

Вывод одинаковый, код заебок, значит можно реверсить.

8) Начинаем реверсить локал очка фаел

Оно взяло хуйню и вызвало первую функцию.

Судя по коду:
//создает див
var content = document.createElement("div");
//скрывает его от юзера, чтоб мозгу не ебать эпилептикам
content.setAttribute("style", "display:none;");
//вставляет в конец боди
document.getElementsByTagName("body")[0].appendChild(content);
//тут делает какую-то ебаную магию с входными числами, которую и нужно понять
var object = parse($($($(content, d), a), b), content, 0);
//удаляет нахуй созданный див
content.parentNode.removeChild(content);
//вертает ебаную хуйню
return object;

Окей, давайте тогда разбираться с этой магией

Оно закидывает
content - блок див и цифру входную в функцию $
$(content, d)
потом опять content и другую цифры
$(.., a)
с третьей та же хуйня
$(.., b)
а потом передает обновленный content, старый и 0 в parse
parse($($($(content, d), a), b), content, 0);
как не трудно догадаться, content превращается в огромное дерево вложенных дивов, а parse дергает нужное.

Тоесть $ делает какие-то вычисления, создает дум дерево и пишет их в него. А parse вытягивает назад всю хуйню.

Окей, тогда надо понять как переписать это на нормальный язык, выкинув работу с дум.

function $(elem, value) {
var i = 0;
for (; i < 8; i++) {
var parent = document.createElement («div»);
elem.appendChild (parent);
parent.innerText = value;
if ((value & 1) == 0) {
elem = parent;
}
value = value ≫ 1;
}
return elem;
}

Тут на вход брало числа и делало какую-то хуйню. вопрос, какую?
ну ясен хуй, оно делало 8 итераций, создавало див и вот еще какая-то вот поебень

if ((value & 1) == 0) {
elem = parent;
}
value = value >> 1;

Хорошо, чекаем доку чтобы понять что это за поебень.
Да, эт побитовые операторы. И хуле они тут делают? Число обрабатывается в двоичном виде:
value = value >> 1;

Ну какбэ на самом деле похуй что они делаю, математика обычная.

Чекаем также след хуйню.

На строках 17 и 30 стояли логпоинты, которые писали значения. Не трудно догадаться, что значения тут как в дум дереве и це и есть нужные цифры

Фиксанем функцию $, чтоб вертала только нужное, как было в логе.

Тоесть оно засунуло через $ и отредачило, а потом дернуло через parse всю хуйню и далее сложило их рекурсивно и вернуло остаток от деления на 256

Тоесть вместо parse, если у нас норм массив, можем написать

...reduce(function (a, b) { return a + b }, 0) % 256

На выходе получаем простой код

А теперь сюрпрайз. Если пролистать ниже, везде дублируется точно такой же код, название функции только меняется. Тоесть вот це и была браузерная за щит очка.

Можно было бы ну просто взять и запарсить регулярками входные значения, названия переменных и генерить без трабл, я бы так и сделал.

Только вот код оказался динамическим и я прихуел, подумав что фсе, смэрть. Эт ведь каждый раз новые имена переменных, позиции в коде, код постоянно разный.

Но бля, больше то привязок к браузеру нет нахуй. Поэтому я просто подошел, взял за руку и сказал:

Возьми из фул кода все функции, дерни мне их в массив, выкинь их нахуй и поменяй на вызов моей.

Тк в коде встречались и простые функции, добавил условие проверки, чтоб такую хуйню не трогал, только та которая с привязкой к браузеру

Есть еще немножко мусора

Поэтому нам нужно дернуть основную функцию по имени

Для этого я запилил регулярку, чтоб дернуть нейм нашей основной функции

Тк конец нашей функции дефолт хуйня - возврат результата, режем от нейма функции до сюды.

Также собираем наш шаблон кода. После отправляем в эвал и сохраняем результат в переменную.
Режем через split код по имени нашей функции и вытягиваем ее.

Как видно по скрину, я свою функцию сумм добавил к шаблону кода, в области видимости основной её видно

Моя функция сумм заменяет вот такую повторяющуюся хуйню. Тк оно просто дергает нужные значения, пихает их в дум, а потом вытаскивает, а я сразу чекаю какие нужны и делаю расчет.

Кстати, это логпоинт, если кто не знал. Работает как лог

Собираем код и тестим

Лол, не трогал код больше года, а он все еще рабочий..

На протяжении многих веков величайшие умы человечества бились над поисками ответа на вопрос "как решить такую капчу?". Вопрошающие хотели знать, как решать капчи на буксах, чтоб залутать многа деняк.

Раньше решали просто - сбор всех картинок как md5 и сопоставление с вопросом.

Даже под текст капчи был на бас пост Бесплатное автоматическое распознавание капчи на BAS. И под profitcentr тоже.

На самом деле, эт прикольный подход не только как решение, но и как оптимизация. По сути, мало кому нужно иметь риалтайм генерацию, это большая нагрузка, тем более, вдруг сгенерится чет нерешаемое, поэтому практически все (если не все) просто генерят 1к капч (сильно больше будто бы и смысла особо нет) и сейвят на сервере. А потому, есть резон собрать их все и прорешать 1 раз, пусть даже через сервисы, зато будет база ответов. А если база и обновляется или пополняется, можно просто ее каждый день дополнять. Оптимизация, хуле.

Не могу сказать точно, что это блеклист слов капчи, но оно лежало в сурсах (слитый гитлаб яндекса) капчи в одной папке с генератором (вроде как).

Я решил внести свою лепту в поиски данного ответа.
Хачу решать капчу не решая капчу. Мне было немножко лень писать код, поэтому я попробовал напрячь "искусственный интеллект", но он упорно выдавал хуйню с багами, без посказок, поэтому пришлось трохи и самому писать.

Некоторое время назад у меня была идея сделать так, чтобы капча решила сама себя. Раз картинок не много, их пускают по кругу в разные вопросы, та что чаще всего в вопросе, та и есть верный ответ.

Я напарсил запросеками задач с сеоспринт вида: вопрос и ответы, а потом вывернул и сделал перегруппировку, чтобы у каждого ответа был вопрос и частота встречи.

Таким образом, я хотел чтобы были получены все правильные вопросы на ответы и оно даже кое как работало, но недавно на форуме я увидел вопрос и оказалось, что капча поменялась.

Теперь там картинки, видимо, создаются "динамически". Рано или поздно я планировал опубликовать решалку, но тут оказалось, что она сдохла, поэтому мне захотелось придумать как наебать систему.

И для этого, я проделал все то же самое, но в качестве имени указывал не md5, а перцептуальный хэш, под который я делал когда-то модуль. Дополнительно мерждил ответы по 75% pHash в 1 картинку.

Прогнал скачивание 1к капч, вывернул, подсчитал, опять вывернул, получил на выходе набор ответов под каждый вопрос.

Запустил сортиров очку по папкам на основе по имени хеша и категории вопроса. По итогу было 30% мусора в каждой категории (наверное из за мерджа.. либо мало запросов), который я ручками почистил. Как не трудно заметить, похожие картинки даже расположены рядом. Только по итогу в решении через pHash, в качестве основного алго, это не помогло, схожесть картинок с разных групп была почему-то слишком высокая, но может это я конечно чет недопонял или проебался в коде.

Тесты

Я решил провести немножко тестов на различные алго поиска схожести изображений и ручками разметил 10 тасков.

Удобно, что и тут в бас html работает

'<div><h3>'+[[QUEST]]+'</h3><p><img src="data:image/jpeg;base64, '+[[IMG]]+' /></p></div>'

В результате получились вот такие размеченные картинки.

Я подготовил 5 тестов: BAS (нативное сравнение), pHash, image-js (getSimilarity), Jimp (distance - pHash), Jimp (diff - PixelMatch)

Также несколько доп тестов для каждого: ориг, gray, gaussianFilter, resize

Ну а теперь к самим тестам..

Test1

Test2

Test3

Test4

Test5

Test6

Test7

Test8

Test9

Test10

И еще тесты..

По итогу я выбрал 3 варианта и провел еще пару тестов: сравнение картинок бас, комбо по 3 метрикам (phash, bas, image-js). Но комбо чет прироста не дало особо, хотя я пытался ставить разные пороги у разных алго в надежде, что это чет поменяет. Jimp алгоритмы почему-то работали в 10 раз медленнее, еще и хуёво в рамках данной задачи. А еще, вполне закономерно, что сходство по pHash у сжатых картинок хуже чем у фул размера.

Затем, я заметил, что можно по урлу запрашивать 1 картинку и каждый раз она будет чуть видоизменяться (чб, кроп, поворот). Попробовал насобирать по 10 вариантов каждой картинки при решении 1 таска, но прироста в качестве это не дало, зато стало в 10 раз дольше решать.

Итоговое решение

По итогу я выбрал вариант сравнение image-js с порогом выше 92, по качеству, кажется, трохи лучше чем нейтив бас, а по скорости примерно также.

Прогнал 100 тестов. Результат 52/100, что для фри решения без всяких нейросеток вполне неплохо.

Когда решил капчу сам, без сервисов и она работает, хоть и хуёво, но зато бесплатно.

С другой стороны, картинки разные, добиться иного результата будет не просто.

Шучу, хуярим дальше

Помните, я чуть ранее сказал, что при повторном запросе картинки сайт вертает разные её виды? нутк го этим воспользуемся и напИздим все что есть)

Так как есть все правильные картинки, можно напарсить каждой по 30 вариаций.

Ну я и напарсил. Ну вот, другое дело. 10/10, алгоритм BAS, сжатие + чб + мыло, порог 95%

И на алго image-js, 92% тоже 10/10.

Прогнал 100 тестов. Алго: BAS 91/100, image-js 92/100. Сила черипикинга) Но по сути сильно разницы нет, можно будто бы и то и то юзать.

Ошибка не выделил нужное (над по больше примерчиков): BAS 6/9 , image-js 6/8

Ошибки в парах для сравнения алго:

Ну и кароч, я заметил, в итоге что проебал 1 картинку с коровой, потому и были с ней ошибки в тестах. В итоге алго: BAS 94/100, image-js 95/100.

Судя по качеству решения, кажется что я спарсил почти все что у них было.. мож так и есть. Если еще чуток допарсить каждой картинки, скорее всего качество улучшится..

Иии... конец!?

Шучу, какой конце нахуй, с хуя ли блять конец?

Надо проверим работала ли моя та изначальная уебанская идея.

Ну и я типо не доволен нихуя. Какого хуя мне опять пришлось заниматься вот этой всей дрочкой? Мне нужно было прогонять тесты фильтруя по вопросу и чекать та или не та картинка, чтоб запускать ее парс.

Я хотел прочекать, что моя идея с авто решением через группировку вопроса и ответа сработает, а вместо этого ебался с капчей. Напоминаю, я хочу чекнуть валид алго:

Формируем хэш таблицу, где в имени хэш картинки и варианты вопросов под нее с подсчетом.
После этого выворачиваем её наоборот, берем теперь хэш с его вариантами вопросов и выбираем тот где большее значение, в этот вопрос и ставим хэш.

На выходе получим жсончег с вопросами и ответами.

Возьмем самое удобное на чем можно почекать.

1к запросекаф, есть ошибки, не удовлетворительно. Пробуем еще раз.

10к запросекаф. Вот теперь все хорошо разметилось, отлично)

Да, теперь перевес у ответов статистически значимый.

Итог:

По сути, хэшить картинки действительно есть резон, даже для обычных капч. Все-таки сайт вряд ли их генерит или хранит на серверах огромное количество. А на буксах такой подход стабильно решает капчу на 100%.

В целом, тыкать буксы было даже немного интересно, особенно попробовать разные сравнения картинок.