Интересный способ посниффить трафик приложений ведра
https://medium.com/@yoshimlutfi/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62
https://medium.com/@yoshimlutfi/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62
Forwarded from GitHub Community
30DaysofSwift –Учим Swift за 30 дней с помощью примеров
Этот проект был полностью вдохновлен проектом Сэма Лу «100 дней Swift», после прочтения его поста на Medium
GitHub | #Swift #Archive
Этот проект был полностью вдохновлен проектом Сэма Лу «100 дней Swift», после прочтения его поста на Medium
GitHub | #Swift #Archive
Forwarded from Интернет-Розыск
Установка Autopsy на Mac OS Big Sur. Autopsy - отличный инструмент с открытым исходным кодом, который позволяет многим людям погрузиться в компьютерную криминалистику. Он всегда был легко доступен на стороне Windows, но было очень сложно начать работать c ним на Mac OS. Мануал...
♾ https://github.com/sleuthkit/autopsy/blob/develop/Running_Linux_OSX.txt
♾ https://slo-sleuth.github.io/tools/InstallingAutopsyOnMacOS.html
♾ https://github.com/sleuthkit/autopsy/blob/develop/Running_Linux_OSX.txt
♾ https://slo-sleuth.github.io/tools/InstallingAutopsyOnMacOS.html
Forwarded from Codeby
ASM – Тёмная сторона РЕ-файла
Исполняемым файлом в системах класса Win является "Рortable-Еxecutable", или просто РЕ. Инженеры Microsoft потрудились на славу, чтобы предоставить нам спецификацию на него, однако некоторые "тузы в рукавах" они всё-таки припрятали. В данной статье рассматривается недокументированная часть РЕ-файла, ознакомившись с которой можно будет собирать информацию о процессе создания файлов компилятором.
📌 Читать статью: https://codeby.net/threads/asm-tjomnaja-storona-re-fajla.79133/
📝 Школа Кодебай |🍿Наш ютуб |👾 Наш дискорд
#asm #fasm #pe
Исполняемым файлом в системах класса Win является "Рortable-Еxecutable", или просто РЕ. Инженеры Microsoft потрудились на славу, чтобы предоставить нам спецификацию на него, однако некоторые "тузы в рукавах" они всё-таки припрятали. В данной статье рассматривается недокументированная часть РЕ-файла, ознакомившись с которой можно будет собирать информацию о процессе создания файлов компилятором.
📌 Читать статью: https://codeby.net/threads/asm-tjomnaja-storona-re-fajla.79133/
📝 Школа Кодебай |🍿Наш ютуб |👾 Наш дискорд
#asm #fasm #pe
Forwarded from Deleted Account
Я делаю расшифровку трафика iOS приложений
Для этого в системной библиотеке boringssl.dylib включаю логгирование ключей и успешно расшифровываю трафик tshark ом.
Как это работает если кто не знаком:
- https://andydavies.me/blog/2019/12/12/capturing-and-decrypting-https-traffic-from-ios-apps/
- https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_keylog_callback.html
- https://sharkfesteurope.wireshark.org/assets/presentations17eu/15.pdf
Проблема в том что далеко не все приложения обязательно должны использовать системный boringssl.dylib. Некоторые используют динамически-линкованные библиотеки и их можно таким же образом заставить логгировать ключи. А некоторые статически линкуют библиотеки что не позволяет их хукать с помощью фриды, например так работает фейсбук и инстаграм и возможно всякие банковские приложения.
Сейчас я использую такой код: https://zerobin.net/?462d1e1a9962d940#rIboEB7gUGe3YDUqlJo/MzwUm+AAOBT41wDxbNdRqcY=
Я подумал что намного лучше и универсальнее будет не устанавливать свой CTX keylog callback, а дампить память процесса и находить ключи в data. Либо находить функции похожие на SSL_CTX_set_keylog_callback по оп кодам в exec сегментах/дизассемблить код capstone'ом (https://www.capstone-engine.org/lang_python.html) и это будет работать независимо от того boringssl это или openssl библиотека статически или динамически линкованная.
Как лучше сделать универсальный логгер SSL ключей? Насколько сложно будет из дампа что-то вытащить?
Для этого в системной библиотеке boringssl.dylib включаю логгирование ключей и успешно расшифровываю трафик tshark ом.
Как это работает если кто не знаком:
- https://andydavies.me/blog/2019/12/12/capturing-and-decrypting-https-traffic-from-ios-apps/
- https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_keylog_callback.html
- https://sharkfesteurope.wireshark.org/assets/presentations17eu/15.pdf
Проблема в том что далеко не все приложения обязательно должны использовать системный boringssl.dylib. Некоторые используют динамически-линкованные библиотеки и их можно таким же образом заставить логгировать ключи. А некоторые статически линкуют библиотеки что не позволяет их хукать с помощью фриды, например так работает фейсбук и инстаграм и возможно всякие банковские приложения.
Сейчас я использую такой код: https://zerobin.net/?462d1e1a9962d940#rIboEB7gUGe3YDUqlJo/MzwUm+AAOBT41wDxbNdRqcY=
Я подумал что намного лучше и универсальнее будет не устанавливать свой CTX keylog callback, а дампить память процесса и находить ключи в data. Либо находить функции похожие на SSL_CTX_set_keylog_callback по оп кодам в exec сегментах/дизассемблить код capstone'ом (https://www.capstone-engine.org/lang_python.html) и это будет работать независимо от того boringssl это или openssl библиотека статически или динамически линкованная.
Как лучше сделать универсальный логгер SSL ключей? Насколько сложно будет из дампа что-то вытащить?
Forwarded from Deleted Account
Причем 50% приложений используют имплементируют HTTP3 QUIC своей собственной реализацией или от гугла или от proxygen, там нет вообще keylog_callback функций и нужно вычленить каким-то образом ключи из памяти. Пока что проблема решена затыканием UDP:443 на роутере. Тогда приложение переходит на HTTP2.
Forwarded from OSINT CLUB