Сегодня нас окружает множество так называемых «умных» устройств — телефонов, часов, Wi-Fi роутеров, IP-камер. Даже лампочки и зубные щетки внезапно поумнели. Само по себе это явление не обязательно плохое. Плохо то, что названные устройства часто доступны посторонним людям через интернет, Bluetooth или Zigbee. При этом производители не сильно беспокоятся об их безопасности. Во многих роутерах даже находили намеренно оставленные бэкдоры (пример 1, пример 2). Не удивительно, что мы видим появление целых ботнетов из IoT устройств. Как выяснить, нет ли в конкретном устройстве уязвимостей или бэкдоров? Давайте разберемся на примере роутера GL.iNet GL-AR750.

Благодаря заметке Изучаем Ethernet-фреймы с помощью осциллографа теперь мы знаем, как физически осуществляется передача данных по Ethernet-кабелю. Однако описанный в посте подход не слишком удобен для полноценной отладки какого-то устройства, работающего с Ethernet. Есть несколько решений этой проблемы. Например, можно воспользоваться старым Ethernet-хабом (но нынче их не так-то просто найти) или настроить зеркалирование портов на Ethernet-свиче. Но в рамках этого поста мы рассмотрим альтернативное решение, которое заключается в использовании платы Throwing Star LAN Tap.

Вы можете помнить заметку про интерактивный дизассемблер Hopper, в рамках которой мы познакомились с недорогой (99$) альтернативой IDA Pro. А если я скажу вам, что существует не просто недорогая, а полностью бесплатная и открытая альтернатива, которая по многим показателям превосходит Hopper, а по некоторым и саму IDA Pro? Лет 10 назад мне было бы трудно в это поверить, но сегодня существование такого решения — это объективная действительность. Решение называется Radare2.

Недавно у меня наконец-то дошли руки поиграться с eBPF. Если вдруг вы все пропустили, eBPF — это очередная реализация идеи «а давайте сделаем DTrace для Linux». Другой реализацией этой идеи является SystemTap. Только SystemTap трудно устанавливается, пользоваться им не очень удобно, и его страшно запускать на проде. В отличие от него, eBPF прямо-таки похож на нормальный инструмент. Давайте же поскорее с ним познакомимся!

Если вы пишете код на языке C или C++, поиск и устранение ошибок работы с памятью, таких, как утечки, выход за границы массива или обращение к неинициализированной памяти, могут доставить немало хлопот. Существует по крайней мере два инструмента для решения этих проблем — Valgrind (не путать с Vagrant!) и Clang’овский MemorySanitizer. Последний работает исключительно под Linux и показал себя несколько сырым и не слишком гибким инструментом, поэтому поговорим о Valgrind. Он довольно гибок и работает везде. Кроме того, в отличие от MemorySanitizer, Valgrind может находить неинициализированные данные с точностью до одного бита. Из недостатков Valgrind стоит отметить сравнительно низкую скорость работы.

Не то, чтобы мне часто приходилось что-то там дизассемблировать. Но время от времени возникает желание посмотреть, в какой ассемблерный код превратился твой код на C. Для решения этой задачи зачастую хватает objdump, но только если ты заранее знаешь, где и что именно ищешь. Для более сложных случаев возникает потребность в чем-то вроде IDA Pro, да вот только стоит эта IDA Pro как вне себя (минимум 589$). К счастью, есть не менее функциональная альтернатива с вменяемой стоимостью (99$) в лице дизассемблера Hopper.

Иногда при отладке программы бывает удобно посмотреть, что она передает по сети. Для решения этой задачи существует множество программ-снифферов. Проблема в том, что иногда они бывают не совсем удобны. Так, tcpdump всегда выводит IP- и TCP-заголовки пакетов, а мне они не всегда интересны. Этого недостатка лишен tcpflow, однако он не работает с UDP и имеет больно уж широкий вывод в консоль. Столкнувшись со всем этим в очередной раз, я решил написать наконец свой маленький основанный на libpcap сниффер, который был бы удобен лично мне. Как оказалось, пишутся такие снифферы очень просто.

Как это всегда бывает в мире Linux, нормальной документации нет. Когда мне захотелось разобраться, как в это время суток разработчики отлаживают модули ядра Linux, а также само ядро, мне пришлось прочитать, наверное, около двадцати статей, разбросанных по всему интернету. А также две книги (книга раз, книга два), вскользь упоминающих этот вопрос, притом одна из них была посвящена непосредственно разработке ядра Linux! Из этих источников половина содержала устаревшую информацию в стиле «Линус запретил использовать отладчики, смиритесь». Еще половина освещала вопрос где-то на 1/10. В итоге, скорее вопреки, чем благодаря, мне все-таки удалось более-менее разобраться в вопросе и собрать всю информацию в одном месте. Не благодарите.

Некоторое время назад мы с вами научились пользоваться DTrace. SystemTap представляет собой нечто похожее, но сильно заточенное под Linux и с рядом важных отличий. Во-первых, SystemTap не требует ручного добавления пробов в код ядра или приложений. Он работает и так, правда, требуя взамен знания исходников. Во-вторых, скрипты SystemTap транслируются в язык C и загружаются в ядро в виде модулей. За это приходится платить временем компиляции скриптов. Зато скриптовый язык SystemTap намного мощнее, чем у DTrace.

DTrace — это такая штука, присутствующая во FreeBSD, NetBSD, MacOS, Solaris и Linux. DTrace предназначен для динамической трассировки ядра системы и приложений в реальном времени, главным образом с целью их профайлинга и отладки. Сегодня мы попробуем поработать с DTrace во FreeBSD. Кроме того, мы установим DTrace и в Ubuntu, хотя по поводу стабильности такой конфигурации и остаются вопросы.