Отладка *

Как то под Старый Новый Год, решил разместить пост о PinBoard II R2. И буквально в течении 20 минут был жестко заминусован двумя отрицательными голосами (топик было решено перенести в черновики). Не имея особого опыта в написании топиков, конкретно в написании каких либо обзоров, отсутствии времени и желании что либо исправлять. Решил оставить все как есть, добавив лишь данное отступление. В любом случае готов принять отрицательную карму, выслушать мнения и пожелания.
Хотелось бы заметить, что данный пост, ни в коем случае не является рекламой изи-ресурса, или рекламой его продукции. Данный пост несет в себе положительные намерения выразить мнения и пожелания по отладочной плате PinBoard, и является неким самовыражением на многоуважаемом Хабре.

А вы никогда не задумывались над тем, что же происходит с операционной системой в тот момент, когда она рисует свой логотип и говорит «Starting Windows»? И вообще, почему она долго загружается? Ведь при старте системы уж точно не решаются никакие задачи, сложные с вычислительной точки зрения!

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

Давайте интереса ради разберемся, какие модули, в каком количестве и в каком порядке загружаются при старте ОС. Чтобы выяснить это, можно, например, получить лог загрузки системы. Подопытная ОС в моем случае — Windows 7 Enterprise x64. Логировать процесс загрузки будем при помощи отладчика ядра. Существует несколько вариантов отладчиков ядра, лично я предпочитаю WinDbg. Также нам понадобятся некоторые вспомогательные средства для волшебного превращения лога в нечто более приятное глазу.

Существует разные техники отладки: кто-то зарывается в отладчик, кто-то медитирует, ожидая просветления, кто-то судорожно меняет код в надежде на удачу, но почти ни кто не откажется от файла в котором будет сохранены последние мгновения жизни процесса, что происходило, в каких нитях, на каких ядрах, в какое время. Заботливо и педантично сохраненная отладочная информация может сохранить многие рабочие часы, особенно если речь идет о отладке драйвера и аппаратного обеспечения с которым он работает. Ну, а в случае когда ошибка случайная и воспроизводиться на 1 системе из 20 в течении недели, то без отладочной информации медитация может затянуться.
В данной статье пойдет речь об утилитах, помогающих в перехвате отладочных сообщений драйверов, работающих на нескольких машинах одновременно и передаче сообщений на сервер для сохранения и анализа.

Тестирование и поиск ошибок – неотъемлемая и не самая интересная часть процесса разработки ПО. Для избавления себя от рутины этот процесс все стараются автоматизировать. И если для проверки функционала приложения создаются специализированные самодельные тесты, то поиск ошибок общего типа далеко не всегда ими покрывается. Проверяется ли, например, ваше приложение на наличие утечек памяти или гонок данных? В этой статье рассмотрим, как использовать обновлённый Inspector XE 2013 в двух ипостасях:

• Для регулярного автоматического тестирования (regression testing)
• Для ручного поиска причин проблемы в паре с отладчиком

Перефразируя известную поговорку: «не делает багов тот, кто ничего не кодирует». Каждый разработчик умеет и любит делать баги, но не любит потом их исправлять. Ошибки в коде в одном случае приводят просто к некорректной обработке данных программой, а в другом — к исключениям (вылетам, падениям, крашам). В этом посте я расскажу о том, как можно автоматизировать сбор данных о краше программы, чтобы сильно облегчить себе жизнь при разборе и устранении ошибок.

Существует стереотип, что reverse engineering — это занятие для злых хакеров в темных очках и блестящих кожаных пальто. Под покровом ночи, в перерывах между беготней по стенам и рукопашными схватками с толпами спецназовцев, эти компьютерные нелюди творят страшные взломы программ, пентагонов и прочих баз данных. Сами взломы как правило не требуют никакой предварительной подготовки и занимают считанные секунды. Ну и конечно в процессе практически любого взлома по чОрным экранам адских хакерских ноутбуков с непонятной ОС ползут зелёные кракозяблы и/или крутится какая-то 3D-фиговина…



Сегодня я хочу отойти от затасканных голливудских штампов про злых компьютерных взломщиков и поведать вам, дорогие читатели, о том как мирный reverse engineering помог чуть-чуть улучшить приложение Яндекс.Деньги. Надеюсь эта история пошатнет устойчивый стереотип, что reverse engineering — это обязательно плохо и нужно только нехорошим людям.

О чем эта статья

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

Так уж вышло что до сих пор я рассказывал исключительно об отладке байткода Dalvik и ни словом не обмолвился об отладке native методов. А ведь именно в native методах часто скрывается самое вкусное — хитрые защиты, интересные malware фичи, уязвимости нулевого дня. Поэтому сегодня я сжато, без «воды», расскажу как отлаживать native методы без исходного кода на C/C++ (ну или на чем, уважаемый читатель, они у вас там написаны).

О чем эта статья

Это продолжения моей вчерашней статьи об отладке приложений для Android без исходного кода на Java (если кто-то её не читал — я очень советую начать с неё). Вчера я давал пошаговую инструкцию как настроить и начать использовать связку Apk-tool плюс NetBeans. Два последних пункта там звучали примерно так:

13. Установите breakpoint на интересующую вас инструкцию… blah-blah-blah...

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

Дальше, в разделе «Подводные камни», я рассказывал почему мы не может начать отладку приложения с самого начала, например поставив breakpoint на какую-нибудь инструкцию метода onCreate(...) в activity, с которой начинает выполняться приложение.

В этой статье я расскажу как всё же можно начать отлаживать приложение без исходного кода на Java с самого начала. Эта статья опять-таки не для новичков. Нужно как минимум понимать синтаксис ассемблера Smali и уметь ручками патчить .smali файлы, грамотно вписывая туда свой код.

О чем статья

В этой статье я сжато, без «воды», расскажу как отлаживать приложения для Android не имея их исходного кода на Java. Статья не совсем для новичков. Она пригодиться прежде всего тем кто более или менее понимает синтаксис Smali и имеет некоторый опыт в reversing engineering приложений для Android.

Иногда возникают ситуации, когда стандартных средств отладки недостаточно.

Например, в iOS 4.1 была возможность использовать valgrind в симуляторе. А в Lion x86_64 и iOS 5 valgrind работать уже перестал.
Это связано с 64-битной архитектурой и изменениями в симуляторе (в valgrind есть ряд
недоработок).

С переходом на ARC метод отладки retain исчез:

- (id) retain
{
    // Break here to see who is retaining me.
    return [super retain];
}

Мотивация

В связи с испорченным местными властями отпуском приходится занимать свое время чем-нибудь интересным. Например, подлечить старую игрушку, косяки которой не позволяют нормально поиграть на современных ОС, либо поменять несколько байтов для получения разных extra-возможностей just for fun. Подопытным будет игра из далекого 2000 года под названием Hogs of War. Если кто не знает, то это turn-based стратегия, где вам дается команда хрюшек, с помощью которых вы должны ни много ни мало, завоевать мир. В процессе игры в зависимости от результатов можно модифицировать каждую хрюшку, например повысив её в звании. В 2009 Atari объявила о продолжении игры в виде разработки HOW2, но по последним данным проект свернули из-за недостатка финансирования. Ничего приятного.

Цель этой части: исправление бага, при котором блокируется весь рабочий стол, если произошел appcrash по какой-либо причине и подготовка приложения для работы в экранном режиме для упрощения отладки.

В нашей повседневной работе, как и всем, требуется много пользоваться отладчиком. В силу специфики работы: (разработка ОС, использование технологий виртуализации наподобие Intel-VT, ит.д.) нам часто требуется использовать отладчик для работы со специфическими случаями: отладка кода загрузчика ядра, отладка загрузчиков виртуальных машин, а так же в принципе обеспечение возможности отлаживать ОС собственной разработки. Именно эти особые случаи так пафосно названы в заголовке ”по максимуму”.

Для решения всех этих задач (и конечно, многих других) мы используем gdb. Возможно использование и таких оболочек как DDD, но лично я предпочитаю использовать cgdb как оптимальный выбор, особенно для случая работы с отладчиком по ssh.
В этой статье мы расскажем о том, как можно использовать gdb для отладки кода загрузочных секторов и загрузчиков.

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

Однако не так был прост конкурс, чтобы его можно было выиграть одной лишь ссылкой на MSDN — там объясняются лишь знаки 1, 2, 3, 7 и 8. А вот что означают и чем друг от друга отличаются 4, 5 и 6 — в этом и была сама задача. К сожалению, многие посчитали первый комментарий верным ответом и отказались от дальнейшего участия. А зря. Прошу под кат.

На Хабре уже упоминалась данная тулза, но как-то в контексте других тем.

What is Fiddler?
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect traffic, set breakpoints, and «fiddle» with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.

Fiddler is freeware and can debug traffic from virtually any application that supports a proxy, including Internet Explorer, Google Chrome, Apple Safari, Mozilla Firefox, Opera, and thousands more. You can also debug traffic from popular devices like Windows Phone, iPod/iPad, and others.

To debug applications you've written in Java, .NET, or using WinHTTP, see this page.

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

Многие из вас, возможно, видели всякие загадочные знаки на полях. Нет, не те что на картинке слева :). Я имею в виду значки на полях редактора кода в Visual Studio. Наиболее известными являются иконки точки останова (Breakpoint) и закладки (Bookmark) . Но есть и другие. Я предлагаю небольшой конкурс: вот 8 значков, которые могут появиться на полях редактора кода в Visual Studio 2010 (без всяких плагинов). Первый, кто верно объяснит их все, получит от меня инвайт на Хабр.

Пишите ответы комментариями к этому топику, а у кого нету аккаунта на Хабре — пишите куда угодно и бросайте ссылку в твиттер с хештегом #VsMisterySigns — обещаю всё прочитать. Ответы удобно нумеровать в соответствии именам интовских переменных в коде. Срок приёма ответов — сутки с момента публикации. Объявление победителя — в течение суток по окончанию приёма ответов, развёрнутой статьей в этих же хабах.

P.S. Обратите внимание, №4 и №6 — это не глюк в задании, это разные значки, обозначающие разные вещи. Смотрите внимательно. Все претензии — к дизайнерам Visual Studio.

Upd. Дискуссия в твиттере поактивнее комментов. Дерзайте, друзья, у всех есть шансы.
Upd2. Ставки сделаны, ставок больше нет. Результаты.

Разве можно отказать после такой просьбы о помощи?

И подробное описание проблемы, и картинка для настроения

Update: Здесь я не приследую задачу посмеяться над коллегой, наоборот, он на мой взгляд описал проблему очень оригинально, при этом заставив улыбнуться, но улыбнуться по доброму

Путь от “несвяти с сетей” и “спаритьБлютуф” до человеческого телефона

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

Скупой платит дважды...

Так было и со мной, когда примерно два года назад я увидел на очередном китайском сайте смартфон с gps, usb-host’ом, двумя камерами и прочими плюшками за смешные деньги. В тот момент, само словосочетание “китайский телефон” должно было остановить меня, но я уже вписывал пароль от PayPal и скоро эта “прелесть” попала мне в руки…

Хабраюзер burdakovd задал в Q&A задачку про C++, vector и запись в чужую память. Задачка, кроме всего прочего, хороша тем, что на ней можно удобно продемонстрировать, как пользоваться инструментом Application Verifier и находить, кто же портит память.

Application Verifier — очень мощный инструмент, кроме диагностики работы с хипом он умеет уйму всего другого, например определять неправильную работу с хендлами, ошибки реализации многопоточности, эмулировать нехватку ресурсов, чтобы проверить корректную работу программы в таких условиях, но об этом как-нибудь в другой раз.

Просматривая очередную серию мультов Фримена заметил мелькание чего-то похожего на QR код, заинтересовался, нашел этот кадр:


Оказалось действительно код. Нашел онлайн декодер от гугла, который и помог восстановить исходное сообщение:

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


Такая вот вирусная реклама для it'шников.

Кому интересно можете найти сами, на видео, отмотав к 01:59.

P.S. Это статья не про Фримена и поиск смысла в его мультиках. А просто про интересный ход, про скрытие информации в видеопотоке, что используется почти в каждой его серии.

Вы, конечно, знаете о свободной карте OpenStreetMap. Это настоящая народная карта, создаваемая такими же людьми как и вы! Это такой же opensource-проект как Linux и как Википедия.

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

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

Итак, помочь улучшить OpenStreetMap может каждый! Просто зайдите на сайт openstreetbugs.schokokeks.org, приблизьте мышкой хорошо знакомое вам место на карте, кликните по проблемному месту, опишите суть ошибки и нажмите OK.

^{Если вам понравится, то вы можете стать полноценным участником проекта OpenStreetMap и рассказать где в вашем районе находятся магазины, кафе, аптеки, школы и прочее.}