Отладка *

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

Итак, началось всё с малого — простенькая купольная камера, бралась самая паршивая по принципу "только б IP и купол". После пошел процесс перебора софта (тема отдельного поста, будет, опять же, позже)… В конце зафиксировался на Macroscop в один канал. Стояла пару месяцев, есть-пить не просила, наркоманов гонять помогала.

И вот работает вроде всё, но как-то подлагивает периодически. Грешил на всё: на проц, на сеть, на софт, на погоду на марсе… Саппорт по логам говорит, что-де камера периодически отваливается.

Upd

В качестве среды разработки компанией «Мультиклет» был выбран текстовый редактор Geany с основными функциями интегрированной среды разработки. Для поддержки необходимых для отладки инструментов разработчиками компании «Мультиклет» был написан плагин MC-DBG, о тестировании возможностей которого пойдет речь в данной статье.

Я уверен, что у многих из нас при отладке приложений периодически возникает желание отступить на шаг (или два, десять...) назад от текущей строки, чтобы увидеть причины происходящего в ней неправильного поведения. Чаще всего для этого приходится перезапускать отладку с начала и пытаться остановить исполнение программы чуть раньше, чем на предыдущей попытке. Затем надо пошагово приблизиться к предполагаемому месту с проблемой… упс, опять перешагнули! Начинаем всё по новой, ведь в дебаггере уже нельзя отступить назад даже на один шаг. Или можно?

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


^{Автор фото: Иван Андреев}

Это перевод статьи Джошуа Блоха «Extra, Extra — Read All About It: Nearly All Binary Searches and Mergesorts are Broken» 2006 года.

Я живо помню первую лекцию Джона Бентли в университете Карнеги-Меллон, на которой он попросил нас, свежеиспечённых аспирантов, написать функцию двоичного поиска. Он взял одно из решений и разобрал его на доске, и, разумеется, в нём оказалась ошибка, как и во многих других наших попытках. Этот случай стал для меня наглядной демонстрацией к его книге «Жемчужины программирования». Мораль в том, чтобы внимательно расставлять инварианты в программе.

И вот, теперь 2006 год. Я был потрясён, узнав, что программа двоичного поиска, корректность которой Бентли доказывал формально и тестами, содержит ошибку. Не подумайте, что я придираюсь; по правде сказать, такая ошибка вполне может ускользать от тестеров десятилетиями. Более того, двоичный поиск, который я написал для JDK, тоже был багнутым лет девять. И только сейчас, когда она сломала кому-то программу, о ней сообщили в Sun.

Биржевые и околобиржевые компании создают серьезный спрос на программистов, занятых совершенно разными вещами — от автоматизации бэкофиса до дата майнинга. Очень серьезные зарплаты и ответственность имеют разработчики так называемых High Frequency Trading algorithms, высокочастотных торговых алгоритмов. Написать этот пост меня сподвиг один занудный и одновременно забавный фильм (youtube, 50 минут, без перевода), в котором разработчик Хаим Бодек очень просто объясняет суть происходящего в HFT.

Поток заявок на покупку-продажу в биржевом "стакане" Бодек ассоциирует с очередью за редким товаром, которого не хватает

Вчера узнал об одной изящной возможности отладки в «Инструментах разработчика Chrome». На конференции "Web Developer Conference Compact" Маркус Росс (Marcus Ross — @zahlenhelfer) рассказывал о различных инструментах отладки, реализованных в Chrome, об одном из который я хочу рассказать.

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

Спросите, зачем?
Ну как же, для 32-битного приложения 2-3 гигабайта – это ваш лимит за пределы которого без использования AWE вы выбраться не сможете, а контролировать собственные ресурсы все же желательно. Но даже и без этого просто с целью разобраться…

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

Давайте посмотрим, как именно программист работает с памятью при отладке (особенно при отладке стороннего приложения, проще говоря, при реверсе):

1. Как правило, самой частой операцией будет поиск значения в памяти приложения и, к сожалению, данный функционал почему-то не предоставлен в отладчике Delphi (собственно, как и в MS VC++).
2. Модификация системных структур (PEB/TEB/SEHChain/Unwind/директорий PE-файлов etc...) будет происходить гораздо проще, когда поля структур размаплены на занимаемые ими адреса и представлены в читабельном виде.
3. Отслеживание изменений в памяти процесса (практически никем не предоставляемый функционал, реализованный в виде плагинов к популярным отладчикам). Действительно, зачем трассировать до посинения, когда достаточно сравнить два снимка карты памяти, чтобы понять, тут ли происходит нужная нам модификация данных или нет?

Да, собственно, вариантов использования много.

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

В первой части мы изучили некоторые вопросы безопасности хранения и передачи данных. Теперь переходим к защите исполняемого кода. Мы будем модифицировать функционал iOS-приложения во время выполнения и проделаем реверс-инжиниринг. И снова, помните! Наша цель — не стать гадким взломщиком, а защитить ваше приложение и пользователей от злонамеренных действий. Для этого нужно понять, что может сделать взломщик.

Вы хорошо поработали, и вот ваше приложение в App Store!

• Храните учётные записи юзеров?
• Используете встроенные покупки?
• Не хотите показывать своё ноу-хау?

Повод задуматься о безопасности кода и данных! Мы будем искать уязвимости в тестовом приложении. В этой статье поговорим о безопасности данных, а в следующей — перейдём к коду.

С выходом инструментов Windows Azure SDK 2.2 разработчики облачных приложений и сервисов Windows Azure получили отличное расширение возможностей Visual Studio 2013, которое позволяет отлаживать код удаленно прямо из облака. Удаленная отладка приложений доступна как для ролей облачных сервисов (Cloud Services) так и веб-сайтов (Windows Azure Web Sites).

Рассмотрим как разработчик может использовать новые возможности удаленной отладки для разработки приложений Windows Azure. Для начала нам потребуется Visual Studio 2013 RTM с установленным пакетом Windows Azure SDK for .NET 2.2. Visual Studio 2013 уже должна иметь привязку к подписке Windows Azure.

Введение

С недавнего времени я увлекся микроконтроллерами. Сначала AVR, затем ARM. Для программирования микроконтроллеров существует два основных варианта: ассемблер и С. Однако, я фанат языка программирования Форт и занялся портированием его на эти микроконтроллеры. Конечно, существуют и готовые решения, но ни в одном из них не было того, что я хотел: отладки с помощью gdb. И я задался целью заполнить этот пробел (пока только для ARM). В моем распоряжении была плата stm32vldiscovery с 32-битным процессором ARM Cortex-M3, 128кБ flash и 8 кБ RAM, поэтому я и начал с нее.
Писал я кросс-транслятор Форта конечно на Форте, и кода в статье не будет, так как этот язык считается экзотическим. Ограничусь достаточно подробными рекомендациями. Документации и примеров в сети по предмету почти нет, некоторые параметры подбирались мной путем проб и ошибок, некоторые — путем анализа выходных файлов компилятора gcc. Кроме того, я использовал только необходимый минимум отладочной информации, не касаясь, например, relocation-ов и множества других вещей. Тема очень обширна и, признаюсь, разобрался я с ней только процентов на 30, что оказалось для меня достаточным.

Класс CSharpCodeProvider позволяет программе на C# компилировать код на C#. Обычный вопрос – «зачем». Обычные ответы:

1. исполнение кода, данного пользователями, как на ideone.com,
2. «ну мало ли зачем» и
3. «а это уже отдельный вопрос»

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

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

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

В качестве платформы была выбрана 64-битная версия ОС Windows. 64 бита — потому что использование Hex-Rays Decompiler для x86 сильно упрощает задачу, а под x64 декомпилятора пока нет. Да и вообще, 64-битные приложения уже стали обычным явлением.

Итак, была собрана небольшая программа с использованием Qt (и статических библиотек). При этом исполняемый файл получился размером почти 10 МБ. Но разве это много для настоящего реверсера? Хотя, по отзывам, некоторых участников напугал размер файла. С другой стороны, Qt оставляет кучу полезной информации, а уж отделять зерна от плевел реверсер должен уметь…

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

В принципе, эта проблема решается, если в dev-окружении в приложение подключается какой-нибудь плагин/модуль (например Profiler в Symfony), отображающий имя файла или класс контроллера, или если используется какой нибудь отладчик. Но все-таки, куда удобнее перейти к исходнику прямо со страницы в браузере. О том, как мы реализовали это в AdMe, читать под катом.

На днях у меня перестал работать онлайн-банкинг моего банка. Нет, не то чтобы совсем перестал — вроде бы можно зайти и даже кое-что сделать, но вот одна из самых важных вещей (просмотр архива платежей) — просто намертво отказалась работать (а как раз было очень нужно). Выглядит это так: при открытии страницы со списком платежей браузер съедает всю доступную оперативную память и падает. В Chrome падает только текущая вкладка, а вот Firefox и IE умирают совсем. Баг воспроизводится на трёх разных PC, айпаде, в Safari под Mac OS и в Firefox под Linux. Ну это я просто так рассказываю, для того чтобы показать наивность советов техподдержки «поставить антивирус» и «перезагрузиться и зайти ещё раз». Давайте подумаем — можем ли мы что-нибудь в этой ситуации сделать?

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

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

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

Вот что-то такое мы и рассмотрим, только в очень упрощенной форме.

В первой части статьи были рассмотрены некоторые нюансы работы с интегрированным отладчиком Delphi — не все конечно, но наиболее необходимые разработчику. Теперь задача выглядит несколько иначе: рассмотрим его работу изнутри на примере его исходного кода. Для того чтобы не сильно утомлять вас описанием API функций и не разжевывать все этапы отладки, описывать его работу я буду на примере класса TFWDebugerCore. Часть не особо важных моментов я опущу, при желании вы их сможете уточнить просмотрев код данного класса.

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

Если же вы ранее никогда не сталкивались с самостоятельной реализацией отладчика, но заинтересованы в ней, то как минимум вы должны начать с данной ссылки: Debugging and Error Handling
По ней вы сможете узнать об основных аспектах отладки, как-то структурной обработке исключений, работой с отладочной информацией, минидампами. Работой с образом исполняемого файла, заголовками, секциями, картой памяти процесса, что такое RVA и VA и прочее-прочее.
Но это только если захотите разобраться во всей этой кухне.

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

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

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

Пару лет назад я писал об использовании базы PAF (Postcode Address File) британской Королевской почты (Royal Mail) для приведения почтовых адресов, вводимых пользователями, к стандартному виду. Поскольку PAF — основная интеллектуальная собственность Royal Mail, то заполучить её не так-то просто: годовая подписка стоит от £400 в зависимости от полноты базы и от частоты апдейтов. Спустя неделю-другую после оформления подписки по почте приходит солидная красная коробочка с CD-диском:


На диске — EXE-файл, который запрашивает «серийный номер» и распаковывает базу (набор CSV-файлов) на диск. Серийный номер присылают отдельно, чтобы злоумышленник, перехвативший посылку, не смог бы воспользоваться базой. (Вот выдумают же — текстовый файл с серийным номером!) Номер у каждого клиента свой, чтобы в случае «утечки» было ясно, к кому предъявлять претензии. Впрочем, организовать «утечку» самих данных серийный номер никак не мешает, и на WikiLeaks в 2009 г. появилась база Postzon (одна из составляющих PAF). В комментариях к ней отмечено, что "данная база составлена на средства налогоплатильщиков, и активисты, в их числе газета The Guardian и сэр Тим Бернерс-Ли, уже давно пытаются убедить Royal Mail открыть свободный доступ к PAF; но до сих пор эти попытки не увенчались успехом". Впрочем, через год после появления Postzon на WikiLeaks аналогичная по содержанию база появилась в открытом доступе от имени британской картографической службы Ordnance Survey и под названием OS Code-Point Open — таким образом и Royal Mail сохранила лицо, не уступив требованиям активистов, и утёкшие данные официально получили статус общедоступных. Тем не менее, полностью PAF до сих пор необщедоступна. (Пока я готовил эту статью, Postzon и с WikiLeaks куда-то пропала; но гугл всё помнит.)

Спустя год после получения PAF мне понадобилось в неё снова заглянуть, но листочек с серийным номером, присланный отдельно от диска, за год успел куда-то затеряться. Тут мне и стало интересно — насколько сложно будет обойти проверку серийного номера в продукте таком солидном и так яростно защищаемом от «освободителей информации»? Через полчаса данные были у меня на винте, а сама программа-распаковщик мне показалась неплохим демонстрационным примером для начинающих реверс-инженеров. Никакая IDA не потребуется — только бесплатные и быстроустанавливаемые инструменты.

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

Единственной постоянной в разработке програмного обеспечения являются баги. Давайте посмотрим правде в глаза, нам никогда не удавалось сделать все правильно с первого раза. Из-за небрежности или неправильных предположений, разработка программного обеспечения становится похожа на приготовление пирога в мотеле, кишащим тараканами, за исключением того, что в нашем случае мы сами создаем жуков. К счастью Xcode дает нам множество инструментов для того, чтобы держать насекомых в ужасе. Очевидно что для этой цели существует отладчик, который мы знаем и любим, но есть еще многое что он умеет помимо просмотра переменных и построчной отладки. Это туториал для начинающих и продвинутых iOS разработчиков, где вы сможете получить практический опыт работы с некоторыми менее известными но черезвычайно полезными методами отладки, таких как:
— как избавится от NSLog в пользу логирования брейкпоинтов;
— как избавится от списка TODO в пользу генерации предупреждений компилятора;
— остановка на условиях с выражениями;
— динамическое изменение данных с помощью LLDB и многое другое.
Как вы можете заметить, целью для меня является быть ленивым разработчиком. К счастью LLDB позволяет сохранить мое время на мартини. Он предоставляет мне отличные инструменты для того, чтобы я не был приклеен к моему компьютеру в течении дня и ночи. Устраивайтесь поудобнее в кресле и открывайте свой любимый напиток. Время становиться ленивым!
Замечу что данный туториал подразумевает что вы уже знакомы с основами отладки в Xcode. Если вы новичек, рекомендую пройти сначала этот туториал.

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

Помимо улучшения вашего приложения путем добавления в него всяких «завитушек», есть одна вещь, которую все хорошие разработчики должны сделать со своим кодом – обработать его утилитой Instruments!

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