# Реверс AVR: как работать с чипами, дампить и исследовать архитектуру

## Метаданные

Доклад: «Реверс AVR: как работать с чипами, дампить и исследовать архитектуру»

Спикер: Nord Husky

## Отредактированный текст

### Вступление

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

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

### Почему AVR

Зачем вообще изучать AVR, если архитектура уже не самая популярная? Надо признать, ARM в этом мире победил: ARM-микроконтроллеры сейчас массово производятся разными вендорами и используются практически везде, вплоть до медицинского оборудования. Есть и более дешевые сегменты рынка, которые заняли другие микроконтроллеры, несмотря на проблемы с документацией и разработкой.

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

### Что такое AVR

AVR — это отдельная архитектура микроконтроллеров. Это не x86, не MIPS, не ARM и не какая-то разновидность другой архитектуры, а самостоятельная архитектура со своей системой команд.

Исторически AVR разрабатывала Atmel. Сейчас Atmel уже давно куплена Microchip, поэтому линейка фактически живет внутри Microchip. Из интересного: у AVR есть особенности, связанные с нестандартной организацией памяти и адресации. Для обычного пользователя это почти незаметно, но если вы занимаетесь reverse engineering или low-level-разбором прошивок, такие особенности начинают влиять на работу.

### Где встречается AVR

AVR можно встретить в довольно большом количестве устройств, хотя сейчас это уже не самый массовый выбор. Чаще всего такие микроконтроллеры попадаются в простых embedded-устройствах, в IoT, в каких-то небольших периферийных платах и самодельных или полупромышленных решениях.

Самый знакомый пример — Arduino. Многие платы Arduino исторически построены на ATmega, поэтому для большого количества людей первое знакомство с AVR произошло именно через Arduino.

Также AVR может встречаться в PLC/ПЛК — программируемых логических контроллерах, которые используются для управления различными процессами и оборудованием. В транскрипте звучали примеры каких-то конкретных модулей и устройств, но ASR там слишком шумный, поэтому я не буду уверенно восстанавливать названия.

Линейки AVR бывают разными. ATtiny — это маленькие микроконтроллеры: меньше ножек, меньше памяти, меньше периферии. Например, в транскрипте упоминаются ATtiny12 и ATtiny85 в маленьких корпусах. ATmega — более крупная линейка, рассчитанная на проекты побольше. По современным меркам 256 КБ flash-памяти — это немного, но для микроконтроллерного мира и задач AVR этого может быть более чем достаточно, чтобы реализовать заметную логику.

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

### Как подходить к реверсу устройства

Теперь к практической части: как вообще подойти к реверсу устройства на AVR.

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

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

Дальше нужно понять плату. В случае с микроконтроллером это не всегда слишком сложно: компонентов может быть немного, а большая часть логики находится внутри SoC/МК. Но все равно нужно разобраться, какие элементы на плате за что отвечают, где питание, где интерфейсы, где линии связи и как вообще устроено устройство.

После этого нужно найти прошивку. И вот здесь начинаются основные сложности. То, что у нас есть плата, еще не значит, что мы можем достать из нее firmware.

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

### Откуда взять прошивку

Есть несколько возможных путей, и почти все они неприятные.

Первый вариант — считать прошивку с самого устройства. Казалось бы, у нас есть устройство, значит, надо подключиться к микроконтроллеру, выпаять его при необходимости и считать содержимое. Но вендор, скорее всего, уже позаботился о защите. На микроконтроллере могут быть выставлены lock bits или другие механизмы readout protection, которые запрещают чтение flash. В таком случае просто программатором прошивку не получить, а для обхода защиты может понадобиться специальное оборудование, которое стоит много денег.

Второй вариант — сайт вендора и файлы обновлений. Иногда можно найти firmware update на сайте производителя. Но часто сайта уже нет, устройство не умеет обновляться пользователем или обновления никогда публично не выкладывались.

Третий вариант — процесс обновления. Если устройство все-таки обновляется, можно попытаться перехватить образ прошивки во время апдейта. Но этот путь тоже не гарантирован: образ может быть зашифрован, упакован, подписан или передаваться в формате, который еще нужно понять.

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

### Защиты и интерфейсы

Даже если мы пытаемся работать напрямую с чипом, нас ждут отдельные проблемы.

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

Во-вторых, отладочные интерфейсы могут быть отключены. Даже если физически пины есть на корпусе микроконтроллера или где-то разведены на плате, это не означает, что через них получится подключиться и что интерфейс вообще активен. Для AVR это могут быть ISP/SPI, JTAG или другие интерфейсы в зависимости от конкретной модели.

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

### Что делать с дампом

Предположим, что мы все-таки получили бинарь. Поздравляю: мы попали в мир bare metal и к тому же в архитектуру, которая может быть незнакома реверсеру.

Первое неприятное отличие bare metal от привычных пользовательских программ — отсутствие привычной структуры. Нет нормального исполняемого формата с метаданными, нет удобных символов, нет понятного загрузчика операционной системы, который все расставит по местам. Есть бинарь, который исполняется микроконтроллером, и все.

Для привычных архитектур вроде x86 или ARM у большинства реверсеров уже есть опыт и инструменты. С AVR все хуже: архитектура менее распространена, и многие инструменты работают ограниченно.

Из дизассемблеров можно пробовать разные варианты: Ghidra, IDA, radare2 и другие. В транскрипте звучит, что все они в этом случае работают примерно одинаково плохо. Главная причина — отсутствие качественного декомпилятора. Ассемблер вы получите, но привычного красивого псевдокода, на который многие опираются при реверсе, скорее всего, не будет.

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

### Где брать информацию

Основной источник информации — datasheet. Их часто не любят читать, но для AVR это очень важный и полезный источник. У Atmel/Microchip документация в целом хорошая по сравнению со многими другими вендорами, у которых даташиты бывают намного хуже или вообще не дают нужных подробностей.

В datasheet нужно смотреть pinout, карту памяти, регистры периферии, описание портов ввода-вывода, interrupt vectors, fuse bits, lock bits, режимы программирования и отладочные интерфейсы. Без этой информации дизассемблированный код почти не имеет контекста: вы видите обращения по адресам, но не понимаете, к каким регистрам периферии они относятся.

### Практические наблюдения

У AVR есть набор регистров общего назначения. Их достаточно много, но если вы знакомы с другими простыми архитектурами, базовая работа не выглядит принципиально чужой. Работа со стеком и памятью тоже требует привыкания, но в целом ее можно разобрать по документации и по AVR instruction set.

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

Один из практических вопросов при реверсе — как найти `main`. Если у вас есть ELF, компилятор и стандартная C-среда помогают: можно увидеть символы или структуру старта. Но в голом бинаре это становится проблемой.

По опыту докладчика, одним из экспериментально найденных признаков было искать инструкцию `sei` — включение глобальных прерываний. Предположение такое: в начале исполнения программа инициализирует окружение и включает interrupts, чтобы, например, корректно обрабатывать reset/периферию. Другого надежного объяснения в рамках доклада не прозвучало, и сам спикер отмечает, что это именно практическое наблюдение, а не универсальное правило.

### Можно ли использовать LLM

Раз уж конференция неожиданно стала более LLM-oriented, стоит сказать и про это. Можно ли использовать LLM для реверса AVR? В принципе, для анализа можно использовать любую LLM. Вопрос в том, насколько хорошо это будет работать.

Ответ: ограниченно. Понять примерно, что делает программа, LLM может помочь. Это работает и на других бинарях: модель может объяснить кусок ассемблера, подсказать возможную структуру функции или прокомментировать логику.

Но есть важный нюанс: LLM не знает всей периферии, которая окружает микроконтроллер. Ей нужно объяснить, что находится на плате, какие микросхемы используются, как они подключены, какие сигналы за что отвечают и какие регистры периферии задействованы. На это можно потратить очень много времени. И хорошо, если маркировка на микросхемах не спилена и datasheet вообще можно найти.

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

### Вопрос из зала

В конце прозвучал вопрос или комментарий из зала о плагине для IDA, который помогает работать с AVR и генерировать нужные структуры. По словам участника, такой плагин можно найти на GitHub; звезд у него немного, выглядит сомнительно, но работает.

Основная проблема, как отметил спикер, может быть в установке плагинов: внутренняя Python-система IDA не всегда хорошо описана, и плагины могут ставиться неочевидно. Тем не менее участник сказал, что у него плагин установился и был расписан порядок установки.

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

## Неоднозначные места

- В начале доклада есть несколько фраз до фактического старта выступления: проверка панели, звука и реплики с места. Они удалены как технический шум.
- В описании опыта спикера ASR несколько раз искажает должность и область работы. Смысл восстановлен как «специалист по аппаратным исследованиям», но точная формулировка должности могла звучать иначе.
- Фраза про то, что ARM «победил», и следующий пример про дешевые микроконтроллеры распознаны очень плохо. Возможно, там упоминались конкретные китайские MCU или вендоры, но уверенно восстановить нельзя.
- В исторической части про AVR и Atmel/Microchip часть слов распознана как «врачебного» и похожие искажения. По контексту это восстановлено как Microchip, но отдельные детали про разработчиков AVR могли быть потеряны.
- Примеры устройств, где встречается AVR, сильно повреждены. Уверенно оставлены Arduino, IoT/embedded-устройства и PLC/ПЛК; конкретные названия модулей не восстановлены.
- В части про линейки микроконтроллеров уверенно распознаны ATtiny12, ATtiny85 и ATmega. Остальные упомянутые варианты AVR не восстановлены.
- Блок про работу с инструкциями, стеком и вызовами поврежден. Сохранен общий смысл про ассемблер, стек, вызовы и возвраты, но без уверенного восстановления конкретных формулировок.
- Упоминание инструкции `sei` восстановлено по фразе «C global» и контексту включения глобальных прерываний. Это вероятное восстановление, но не дословная уверенность.
- В вопросе из зала про плагин для IDA название плагина не распознано. Уверенно сохранен только смысл: GitHub-плагин для AVR/IDA, который помогает генерировать вспомогательные данные или структуры.