Отладка *

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

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

Посмотрим, как справиться с противодействием отладке на примере 1337ReverseEngineer's The Junkrat https://crackmes.one/crackme/62dc0ecd33c5d44a934e9922 .

Привет, Хабр. Хочу поделиться своим решением одной из проблем использования корутин в Kotlin.

Корутины в Kotlin - одна из значимых фич языка, которая позволяет писать асинхронных код в синхронном стиле. Корутины прекрасны во всём, до тех пор пока не возникает необходимость их дебажить.

Правильный процесс ревью кода — это процесс итеративного улучшения продукты и контроля.
Контроля того, что:
1) Cоблюдены общие правила и договорённости
2) Решение не избыточное и масштабируемое.
3) Решение покрывает все критерии приемки указанные в описании к задаче

Для начала будет хорошо задать в своей команды такие вопросы:
1) Сколько времени занимает ревью кода для средней (сферической в вакууме) задачи
2) Как вы минимизируете время ревью?
3) Как вы определяете, что ревью конкретной задачи сделано правильно?

Понедельник, 9 утра, сообщение в рабочем чате: "Всё сломалось, почините". Согласитесь, неприятная ситуация, особенно когда это ваш первый месяц работы, а сломалось что-то в функционале, с которым вы ещё ни разу не контактировали, да и не трогал его уже никто месяцами.

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

После ряда успешных (и не очень) проектов по развертыванию фреймворков на корпоративных инфраструктурах и в облаке, была сформулирована концепция фреймворка FaaS (Function as a Service). Его задача – обеспечить запуск приложений в контейнерах без сохранения состояния. Это дает разработчикам возможность сконцентрироваться на самом коде, а не на управлении сложной инфраструктурой и связанными с ней ресурсами. Это привело к изобретению бессерверной архитектуры, ориентированной исключительно на исполнение двоичных файлов приложений, при этом все необходимые ресурсы управляются сторонним провайдером и принадлежат ему. По своей сути бессерверная архитектура позволила предприятиям не только сильнее сосредоточиться на разработке основных приложений, но и существенно снизить накладные расходы.

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

В предыдущей части был реализован более-менее работающий контроллер памяти, а точнее — обёртка над IP Core из Quartus, являющаяся переходником на TileLink. Сегодня же в рубрике «Портируем RocketChip на малоизвестную китайскую плату с Циклоном» вы увидите работающую консоль. Процесс несколько затянулся: я уже было думал, что сейчас по-быстрому запущу Linux, и пойдём дальше, но не тут то было. В этой части предлагаю посмотреть на процесс запуска U-Boot, BBL, и робкие попытки Linux kernel инициализироваться. Но консоль есть — U-Boot-овская, и довольно-таки продвинутая, имеющая многое из того, что вы ожидаете от полноценной консоли.

В аппаратной части добавится SD-карта, подключённая по интерфейсу SPI, а также UART. В программной части BootROM будет заменён с xip на sdboot и, собственно, добавлены следующие стадии загрузки (на SD-карте).

using System;
public class Example
{
    public static void Main()
    {
        var x = Math.Round(11.1, MidpointRounding.AwayFromZero);
    }
}

Изображение: Julien Dumont, Flickr

К сожалению, иногда случаются ситуации, когда система перестает работать или начинает безудержно потреблять ресурсы, а логи и системные метрики не могут помочь. Ситуация еще усугубляется тем, что на системе в продакшене нет Visual Studio или какого-либо отладчика, невозможно поотлаживаться удаленно. Чаще всего даже нет возможности получить доступ этой машине. В данном случае единственным решением является анализ дампа памяти процесса. Я хочу описать несколько общих сценариев поиска проблем на таких дампах. Это поиск взаимоблокировок, утечек памяти и высокого потребления процессорных ресурсов.

У нас возник резкий рост количества вылетов Explorer из-за того, что указатель команд оказывался в пустоте.

0:000> r eax=00000001 ebx=008bf8aa ecx=77231cf3 edx=00000000 esi=008bf680 edi=008bf8a8 eip=7077c100 esp=008bf664 ebp=008bf678 iopl=0 nv up ei pl zr na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246 7077c100 ?? ???

Возможно, нам о чём-то скажет адрес возврата.

0:000> u poi esp 008bf6d4 test eax,eax 008bf6d6 je 008bf6b9 008bf6d8 xor edi,edi 008bf6da cmp dword ptr [esi+430h],edi

Странно, что мы исполняем код из какого-то места, не имеющего имени. Если приглядеться, то можно увидеть, что мы исполняем код из стека: esp — это  008bf664, то есть вызывающий проблемы код находится в стеке.

Кто исполняет код из стека?

Конечно, зловреды.

Давайте посмотрим, что пытается сделать это зловредное ПО.

Разрабатывая код для очень узких мест, привычного стандартного набора средств и отладчиков зачастую не хватает, когда нам требуется отладить фрагмент алгоритма именно в конкретном случае, в конкретном состоянии окружения и массивов данных.

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

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

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