Ngrok ��� ���� ������

Реверс-инжиниринг протокола ngrok v2

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

К сожалению, с 2016 года поддержка open-source версии клиента (ngrok v1) прекращена, и чтобы воспользоваться сервисом, нужно запустить закрытую версию (ngrok v2), что во многих случаях неприемлемо. Данная статья описывает процесс изучения протокола, используемого официальным клиентом, и создания альтернативного открытого клиента.

А нужно ли оно? Альтернативы ngrok

Как ни странно, у данного сервиса очень мало альтернатив. Конкретно, три:

serveo.net. Предоставляет аналогичный функционал, но использует SSH reverse port forwarding, а не кастомный клиент. К сожалению, в настоящее время проект закрыт.

Serveo is temporarily disabled due to phishing.

Serveo will return in a few days with a few new restrictions to help dissuade abuse. Thanks for your patience!

(P.S. В комментариях подсказали, что существует localhost.run, который предоставляет HTTP-туннели через SSH port forwarding, аналогично serveo.net. Однако, судя по всему, сервис предоставляет только HTTP-туннели, в отличие от ngrok)

Naive attempt #1: mitmproxy

Попробуем прослушать трафик официального приложения с помощью mitmproxy:

Приложение, естественно, начинает ругаться на невалидный сертификат. Однако в тексте ошибки видно, что ngrok пытается отрезолвить адрес сервера tunnel.us.ngrok.com через DNS-over-HTTPS:

Попробуем дернуть сам tunnel.us.ngrok.com:

Видимо, клиент использует certificate pinning с самоподписанным сертификатом. Попробуем игнорировать ошибку:

Google по запросу «illegal WNDINC frame length» выдает библиотеку для Go для мультиплексирования TCP-соединений. Эта же библиотека упоминается в issue с призывом открыть исходники ngrok v2.

Библиотека muxado

Проверим, действительно ли ngrok использует библиотеку muxado:

Из вывода этой команды можно сделать несколько выводов (простите за тавтологию):

1. ngrok действительно использует данную библиотеку.
2. Автор не пытался как-либо обфусцировать исполняемый файл, так как в нем оставлены символы.

Также заметим, что ошибка от сервера была получена по защищенному (TLS) соединению, что означает, что протокол muxado используется внутри TLS-сессии. Это позволяет предположить, что поверх muxado данные передаются открытым текстом, так как дополнительное шифрование было бы избыточным. Таким образом, чтобы снять незашифрованный дамп траффика, достаточно перехватить вызовы (*stream).Read и (*stream).Write.

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

Итак, для перехвата траффика нас интересуют:

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

В выводе objdump на функции github.com/inconshreveable/muxado.(*stream).Write (Забавно, что разработчики Go, похоже, не заморачивались с name mangling.) отчетливо видна загрузка аргументов со стека:

Осталось понять, где именно на стеке лежат нужные нам значения. Для этого воспользуемся gdb и выведем состояние стека на момент вызова функции.

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

Итак, теперь мы знаем, как расположены в памяти аргументы функции (*stream).Write (для (*stream).Read всё точно так же, так как у функций одинаковый прототип). Осталось реализовать сам перехват.

Naive attempt #2: runtime function hooks

Попробуем перенаправить вызовы (*stream).Write в функцию-прокси:

При попытке вызвать ngrok с данным хуком получаем краш следующего вида:

Тут нас ждет неожиданное препятствие в лице goroutines. Дело в том, что стек под горутины выделяется динамически: при недостатке места в существующем стеке он выделяется заново в другом месте, и текущее содержимое копируется. К сожалению, функции, генерируемые gcc, сохраняют старый указатель стека в регистре rbp (т.н. frame pointer), и при возврате из такой функции указатель стека начинает указывать на уже освобожденный старый стек (use-after-free). Таким образом, C тут не помощник.

Attempt #3: gdb script

Напишем скрипт для gdb, который будет распечатывать все передаваемые данные:

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

• Чтобы прочитать принятые данные, нужно дождаться, пока функция завершит выполнение. Эта проблема решается установкой breakpoint’а на инструкцию ret.
• Функция может считать меньше данных, чем планировалось, при этом количество реально считанных байт — одно из возвращаемых значений функции. Нужно понять, как передаются возвращаемые значения. (Также тривиально, достаточно распечатать стек после выполнения функции. Нужное число лежит по адресу $rsp+48).
• Третья, и самая главная проблема. Вывод gdb не предназначен для автоматического парсинга (в качестве примера см. распечатку из раздела ABI), поэтому полученные таким образом дампы пригодны только для визуального анализа. (На самом деле это не проблема, так как протокол крайне прост и распознается с первого взгляда).

Attempt #4: assembly

Открыв бинарник ngrok objdump’ом, можно заметить, что между секциями .text и .rodata присутствует зазор в 0xc10=3088 байт:

Этот же зазор присутствует и в самом файле, там пустое пространство заполнено нулевыми байтами. Это позволяет изменить записанный в файле размер сегмента, содержащего секцию .text (поиск/замена в hex-редакторе), и добавить в пустое пространство код для логгирования вызовов.

Инструкция относительного перехода на архитектуре x86_64 занимает 5 байт: опкод (E9) + смещение до конечного адреса (signed int). Так как размер исполняемого файла ngrok сильно меньше 2 гигабайт, эта инструкция позволяет передать управление в любую точку секции .text, в том числе в наш новый код.

Первая инструкция обоих функций занимает 9 байт, так что первые 5 байт инструкции можно заменить на инструкцию перехода:

Для вызова оригинальной функции достаточно выполнить исходную инструкцию и перейти по адресу func+9

С инструкцией ret в функции (*stream).Read все куда интереснее:

Инструкция ret (записана как retq, в противовес retf) занимает всего 1 байт, при этом следующая за ней инструкция является jump target’ом, поэтому изменять ее нельзя. Однако на саму инструкцию ret переход нигде не производится, поэтому ничто не мешает заменить ее на переход вместе с предыдущей инструкцией (после перехода, естественно, ее придется выполнить).

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

Из этого дампа прекрасно видно внутреннее устройство протокола:

• Очевидно, что потоки авторизации и создания туннеля инициируются клиентом, а потоки с собственно подключениями — сервером. Этого нет в логах, но это очевидно по соображениям здравого смысла.
• В начале каждого потока передается 32-битное число — тип потока. Это 0 для авторизации, 1 для создания туннеля и 3 для входящих соединений.
• Поток с типом -1 — heartbeat. Инициатор соединения периодически отправляет туда случайные 4 байта и ожидает получить их же на выходе. Таких потока создается 2 в обоих направлениях.
• При получении входящего соединения передается 32-битный тип 3, 64-битное число L (little-endian) и JSON-объект длины L байт, описывающий соединение. После этого по соединению передаются сырые данные без каких-либо служебных пакетов.

Заключение

Так как muxado — open-source библиотека, протокол мультиплексирования можно изучить по исходникам. Приводить его здесь не имеет смысла.

Результатом работы стали библиотека на Python для работы с протоколом ngrok, и альтернативный консольный клиент, использующий данную библиотеку. GitHub

Источник

Public URLs for

Spend more time programming. One command for an instant, secure URL to your localhost server through any NAT or firewall.

Welcome to Kate’s Site!

It’s currently under development… Check back soon!

node app.js Serving app.js port 3000

./ngrok http 3000

ngrok by @inconshreveable Session Status online Account Kate Libby (Plan: Pro) Web Interface http://127.0.0.1:4040 Forwarding http://katesapp.ngrok.io -> localhost:3000 Forwarding https://katesapp.ngrok.io -> localhost:3000

Take advantage of a powerful local inspector

And so much more.

Join the hundreds of thousands of developers who love ngrok
Here’s some kind words from a few of them.

ngrok has become essential to my workflow. Makes testing responsive designs so much easier.

ngrok is genius, replaying requests makes webhooks 1M times easier to handle. ngrok.com

#ngrok is a dream for testing localhost with remote APIs!

ngrok has got to be the easiest local tunnel solution I’ve ever used.

ngrok, probably the best tool I have started to use for my webwork since firebug also great support

Источник

Раскрыто настоящее название нового iPhone

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

В китайской соцсети Weibo разошелся «шпионский» снимок, на котором якобы запечатлен стикер от коробок со смартфонами Apple следующего поколения. Если утечка правдива, модели новой линейки, как и ожидается, будут называться iPhone 13.

Похоже, в Apple снова пропустят модели с индексом S, который ранее мог указывать на «доработанность» устройств или наличие особенных функций (однажды глава компании Тим Кук объяснил, что буква S в iPhone 4S расшифровывается как Siri, что обозначает новую голосовую помощницу). «Номерным» айфонам отдали предпочтение и в прошлом году, когда серию iPhone 11 сменила iPhone 12.

Let me emphasize again that I am not a leaker. I don’t have first-hand information. I just reprint some information that I have seen that I feel is relatively reliable. pic.twitter.com/Avy9ndDT4Q

Помимо названия iPhone 13, на упаковке можно увидеть фирменную надпись, сопровождающую все «яблочные» продукты: Designed by Apple in California. Assembled in China («Разработано Apple в Калифорнии. Собрано в Китае»).

Официально в Apple пока не объявляли индекс следующей модели. Однако проведенный летом опрос в США показал, что каждый пятый американец готов отказаться от покупки нового смартфона, если в его названии будет число 13. Причиной тому была названа трискайдекафобия — патологическая боязнь числа 13, которое, согласно приметам и суевериям, приносит несчастье. Большинство респондентов заявили, что предпочли бы другое наименование — например, многие поддержали идею назвать следующее устройство «iPhone (2021)».

Анонс смартфонов Apple следующего поколения ожидается в сентябре—октябре. Если верить утечкам, iPhone 13 будет отличаться от предшественника незначительно. Apple снова предложит четыре модели с такими же диагоналями — одну на 5,4 дюйма, две 6,1-дюймовые и одну на 6,5 дюйма.

Экраны продвинутых айфонов — iPhone 13 Pro и iPhone 13 Pro Max — будут изготовлены по технологии LTPO, что позволит им поддерживать частоту обновления до 120 Гц без серьезного ущерба для автономности. Главным визуальным изменением станет «челка» уменьшенного размера. Кроме того, флагманская модель выйдет в эксклюзивном «глубоком черном» цвете.

Источник

Раскрыты секреты ужаснувшей американцев российской подлодки

При производстве модернизированных подводных лодок проекта 855-М были обнаружены сложности, повлиявшие на сроки сдачи головной субмарины «Казань». Как предположил член экспертного совета «Офицеров России», капитан первого ранга Василий Дандыкин, это связано с переходом на систему импортозамещения.

ПО ТЕМЕ

США готовит сокрушительный удар по России

В Северодвинске спустили на воду «Казань»

В разговоре с «Дни.ру» эксперт выразил уверенность, что доработка закончится в срок, и в дальнейшем Военно-морской флот будет пополняться в год по меньшей мере на одну подводную лодку класса «Ясень-М». Они, по его словам, будут вставать в строй в Тихоокеанском и Северном флотах на замену легендарным подводным лодкам 971-го проекта «Щука». Если сравнивать новейшие субмарины с предшественниками, они по ударной мощи превосходят тех в два-три раза.

«Это атомная субмарина, которая не знает себе равных», – подчеркнул Дандыкин.

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

Самое главное, подчеркнул капитан первого ранга, это арсенал, который может применять новейшая российская подводная лодка. «Она обладает возможностью нести десятки «Калибров» – крылатых ракет с подводным стартом, которые себя очень хорошо показали в сирийских событиях. И не только «Калибров». Как у нас, судя по всему, отмечается, в будущем она может быть носителем гиперзвуковых ракет «Циркон», – напомнил он.

«Самая главная задача этой подводной лодки в перспективе – это гроза авианосных группировок вероятного противника», – рассказал Дандыкин.

Он добавил, что, возможно, американские СМИ хвалят российские подводные лодки класса «Ясень-М» исходя из собственных интересов. Дескать, таким образом пытаются выбить дополнительные деньги из бюджета. «Тем не менее где-то они недалеки от истины», – заключил эксперт.

Ранее портал The National Interest опубликовал статью «У России есть рождественский подарок для ВМС США» о новых ударных атомных подводных лодках усовершенствованного проекта «Ясень-М». Отмечается, что проект был расширен с шести до восьми единиц, и это говорит об уверенности Министерства обороны в перспективах техники.

Источник