Тут по работе возникла задачка с PostgreSQL. Нужно было определить, как часто при определенных условиях вызываются такие-то процедуры, и что они при этом возвращают. Трейсить предстояло совсем чуть-чуть, да и не в проде, поэтому я воспользовался LLDB. Несмотря на то, что это не инструмент трассировки, в моем случае с задачей он справился. И тут я вспомнил, что еще не так давно читал про bpftrace. Хотя, конечно же, успел напрочь все позабыть. Было решено проверить, насколько лучше или хуже bpftrace подошел бы для той же задачи.
Бывает так, что ошибка в коде воспроизводится лишь при определенном стечение обстоятельств. Эти обстоятельства могут быть довольно сложными, особенно если приложение распределенное и каждый его экземпляр состоит из N процессов. Подцепиться отладчиком к правильному процессу в правильный момент времени практически невозможно. В подобных случаях я использую один незамысловатый прием, речь о котором и пойдет далее.
Сегодня нас окружает множество так называемых «умных» устройств — телефонов, часов, 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 и имеет больно уж широкий вывод в консоль. Столкнувшись с этим в очередной раз, я решил написать маленький сниффер, который был бы удобен лично мне. Оказалось, что пишутся снифферы очень просто.
Как это всегда бывает в мире Linux, нормальной документации нет. Когда мне захотелось разобраться, как в это время суток разработчики отлаживают модули ядра Linux, а также само ядро, мне пришлось прочитать, наверное, около двадцати статей, разбросанных по всему интернету. Из этих источников половина содержала устаревшую информацию в стиле «Линус запретил использовать отладчики, смиритесь». Еще половина освещала вопрос где-то на 1/10. В итоге, скорее вопреки, чем благодаря, мне все-таки удалось более-менее разобраться в вопросе и собрать всю информацию в одном месте. Не благодарите.
