Delivery Man
22.10.2010, 19:03
Авторы: aLS и Alfredo
Переводчик: Ex0rcist a.k.a. Heroin
Оригинал (EN): www.phrack.org (http://www.phrack.org/issues.html?issue=66&id=7)
Источник (RU): www.reverse4you.org (http://forum.reverse4you.org/showthread.php?t=899)
Persistent BIOS Infection
------[ 0.- Предисловие
Уважаемые пользователи, если вы читаете эту статью, мы можем предположить, что вы уже знаете, что такое BIOS и как он работает. Или, по крайней мере, вы имеете общtе представление о том, что делает BIOS, и его значение для нормальной работы компьютера. Основываясь на этом, мы кратко объясним некоторые основные понятия, чтобы ввести в курс дела, а затем мы будем переходить к более актуальным техническим тонкостям.
------[ 1.- Введение
На протяжении многих лет многое было сказано по этой теме. Но кроме старого вируса Chernobyl, который просто обнулял BIOS, если твоя материнская плата была одной из поддерживаемых, или для некоторых изменений для моддинга, такими как работа Pinczakko, мы не в состоянии найти общедоступные разработки, характерные для определенного класса вредоносных BIOS инфекций. Люди, как правило, думают, что эта тема раскурена вдоль и поперек, стара и имеются готовые разработки. Иногда даже путают с MBR вирусами. Мы намерены показать, что такой тип атаки возможен и может быть очень надежным и стойким руткитом, находясь в прошивке BIOS и оставаясь невидимой для ОС инфекцией.
В этой статье мы покажем универсальный метод, чтобы внедрить код в BIOS прошивки. Этот метод позволит нам встроить наш собственный код в BIOS прошивки так, что он будет выполнен непосредственно перед загрузкой операционной системы.
Мы также продемонстрируем, как с контролем жесткого диска или просто путем изменения конфиденциальных данных ОС в Linux box, развертывать полностью функциональный код непосредственно в процесс Windows.
---[ 1.1 - Назначение статьи
Основной идеей данной работы является показать то, как BIOS прошивки можно модифицировать и использовать как метод сохранения контроля после успешного рутанья. Ну, начнем потихонечку и постепенно будем рассматривать возникающие вопросы, разделив статью в двух основных направлениях:
- Модификации VMWare's (Phoenix) BIOS
- Рельные модификации BIOS
В каждом разделе мы расскажем основные моменты, чтобы показать, как провести атаку, а затем перейдем непосредственно к рассмотрению кода.
------[ 2.- Основы BIOS
---[2.1 - Введение в BIOS
Из википедии:
BIOS - загрузочная прошивка, запускаящаяся и исполняющая код самой первой после включения ПК. Начальной функцией BIOS является запуск тестирования и инициализация системных устройств, таких как видеокарта, жесткий диск, флоппи и проч. Это делается для подготовки машины к запуску с заданными параметрами так, чтобы загружалось и выполнялось установленное на носителях программное обечпечение, и передача управления ПК. Этот процесс известен как загрузка, за которой следует короткая преднастройка.
...создать небольшую библиотеку базовой системы ввода / вывода функций, которая может быть вызвана при эксплуатации и управлении периферийными устройствами, такими как клавиатура, функциями отображения текста и так далее. В IBM PC и в некоторых периферийных устройствах, таких как жесткий диск и контроллеры видеоадаптеров, имеется их собственный BIOS Extension ROM, который, предоставляет дополнительные функции. Операционные системы и исполнительняемое программное обеспечение, предназначенное для замены этих базовых функций прошивки, обеспечивает замену интерфейса программного обеспечения для приложений.
---[2.1.1 - Железо
Еще в 80-х BIOS прошивки загружались в ПЗУ или ППЗУ чипы, которые не могли быть изменены, но в настоящее время эта прошивка хранится в EEPROM (электрически стираемая программируемая Read-Only память). Этот вид памяти разрешает пользователю перепрошивать его, позволяя поставщику создавать обновления встроенного программного обеспечения для того чтобы исправить ошибки, добавить поддержку нового железа и функциональности.
---[2.1.2 - Как это работает?
BIOS имеет очень важное значение в работе компьютера. Он должен быть всегда доступен, как первая инструкция, выполняемая центральным процессором, при его включении. Вот почему он хранится в ROM.
Первый модуль BIOS называется загрузочный блок (Bootblock) и отвечает за POST (Power-On Self-Test) и аварийную загрузочную процедуру. POST является общим термином предварительной загрузки для компьютера, маршрутизатора или принтера. Он должен протестировать и инициализировать почти все аппаратные компоненты в системе, чтобы убедиться, что все работает правильно.
Современный BIOS имеет модульную структуру, что означает, что есть несколько модулей, интегрированных в одну прошивку, каждый из которых отвечает за конкретные задачи, от аппаратной инициализации до безопасности.
Каждый модуль является сжатым, поэтому есть точный алгоритм декомпрессии, отвечающий за декомпрессию и проверку других модулей, которые впоследствии будут выполняться.
После декомпрессии, определяются другие аппаратные средства, такие как PCI ROM (если необходимо), и в конце концов, в поисках загрузчика, читается 0 сектор жесткого диска (MBR), чтобы начать загрузку операционной системы.
---[2.2 - Файловая структура прошивки
Как мы упоминали ранее, прошивка BIOS имеет модульную структуру. При хранении в нормальном файле, он состоит из нескольких LZH сжатых модулей, каждый из которых содержит 8 бит контрольной суммы. Однако, не все модули являются сжатыми. Несколько модулей, такие как загрузочный блок (Bootblock) и алгоритм декомпрессии, явно не сжаты, потому что они являются фундаментальной частью процесса загрузки и должны выполнять декомпрессию других модулей. Далее мы увидим, почему для нас это так удобно.
Мы имеем выход Phnxdeco (доступны в Debian репозитории), открытый исходный код для разбора и анализа прошивки Phoenix BIOS ROM (то, что собираемся извлечь в 3.1.1):
Code:
+-------------------------------------------------------------------------+
| Class.Instance (Name) Packed ---> Expanded Compression Offse |
+-------------------------------------------------------------------------+
B.03 ( BIOSCODE) 06DAF (28079) => 093F0 ( 37872) LZINT ( 74%) 446DFh
B.02 ( BIOSCODE) 05B87 (23431) => 087A4 ( 34724) LZINT ( 67%) 4B4A9h
B.01 ( BIOSCODE) 05A36 (23094) => 080E0 ( 32992) LZINT ( 69%) 5104Bh
C.00 ( UPDATE) 03010 (12304) => 03010 ( 12304) NONE (100%) 5CFDFh
X.01 ( ROMEXEC) 01110 (04368) => 01110 ( 4368) NONE (100%) 6000Ah
T.00 ( TEMPLATE) 02476 (09334) => 055E0 ( 21984) LZINT ( 42%) 63D78h
S.00 ( STRINGS) 020AC (08364) => 047EA ( 18410) LZINT ( 45%) 66209h
E.00 ( SETUP) 03AE6 (15078) => 09058 ( 36952) LZINT ( 40%) 682D0h
M.00 ( MISER) 03095 (12437) => 046D0 ( 18128) LZINT ( 68%) 6BDD1h
L.01 ( LOGO) 01A23 (06691) => 246B2 (149170) LZINT ( 4%) 6EE81h
L.00 ( LOGO) 00500 (01280) => 03752 ( 14162) LZINT ( 9%) 708BFh
X.00 ( ROMEXEC) 06A6C (27244) => 06A6C ( 27244) NONE (100%) 70DDAh
B.00 ( BIOSCODE) 001DD (00477) => 0D740 ( 55104) LZINT ( 0%) 77862h
*.00 ( TCPA_*) 00004 (00004) => 00004 ( 004) NONE (100%) 77A5Ah
D.00 ( DISPLAY) 00AF1 (02801) => 00FE0 ( 4064) LZINT ( 68%) 77A79h
G.00 ( DECOMPCODE) 006D6 (01750) => 006D6 ( 1750) NONE (100%) 78585h
A.01 ( ACPI) 0005B (00091) => 00074 ( 116) LZINT ( 78%) 78C76h
A.00 ( ACPI) 012FE (04862) => 0437C ( 17276) LZINT ( 28%) 78CECh
B.00 ( BIOSCODE) 00BD0 (03024) => 00BD0 ( 3024) NONE (100%) 7D6AAh
Мы видим здесь различные части файла прошивки, содержащие DECOMPCODE раздел, где расположен алгоритм декомпрессии, а также другие, не рассматриваемые в этой статье параметры.
---[2.3 - Обновление
Программное обеспечение BIOS не так уж сильно отличается от любого другого программного обеспечения. Это относится к ошибкам, которые можно встретить и в другом программном обеспечении. С новыми версиями выходит поддержка нового железа, дополнения, исправление ошибок и т. д. Но процесс обновления может быть очень опасным на реальной машине. BIOS является одним из основных компонентов компьютера. Это первая часть кода, выполняемая при включении машины. Именно поэтому мы должны быть очень осторожны, когда делаем такого рода вещи. Неудачное обновление BIOS может привести к зависанию машины. И ты соснешь тунца.
Вот почему так важно иметь такую платформу для тестирования как VMWare. По крайней мере на первое время, потому что, как мы увидим далее, есть много различий между VMware и реальным железом.
------[ 3 .- Заражение BIOS
--- [3.0 - Первичная настройка
--- [3.1 - Модификация VMware (Phoenix) BIOS
Во-первых, мы должны получить действительную прошивку VMWARE BIOS для работы. Для того чтобы читать EEPROM (где хранится прошивка BIOS) нам необходимо запустить код в режиме отладки ядра, чтобы отправлять и получать данные непосредственно в южный мост через порты ввода-вывода. Для этого нам также необходимо знать некоторые конкретные данные о текущем оборудовании. Эти данные обычно предоставляются производителем. Более того, почти все поставщики плат предоставляют некоторые инструменты для обновления BIOS, и очень часто они имеют возможность резервного копирования существующей прошивки.
В VMWare мы не можем использовать эти инструменты, потому что эмулируемое железо не имеет ту же функциональность, как реальное оборудование. В этом есть смысл... Почему бы не обновить VMWare BIOS изнутри...?
---[3.1.1 - Дамп VMWare BIOS
Для начала было бы неплохо иметь встроенный GDB сервер, который предлагает VMWare. Он позволяет нам производить отладку и понимать, что происходит. Таким образом, в целях исправления и изменения некоторых маленьких кусков кода, чтобы начать тестирование, мы использовали некоторые случайные массивы байтов в качестве шаблонов для поиска BIOS в памяти.П роделывая это, мы обнаружили, что в VMware-VMX существует основная исполняемая VMware секция, весом почти 256кб, которая называется .bios440 (которая в нашей версии VMware находится между смещением в файле 0x6276c7-0x65B994). Она содержит всю прошивку BIOS, точно так же, как и в обычном файле, готовом к выполнению.Вы можете использовать objdump для того чтобы видеть разделы файла:
Code:
objdump -h vmware-vmx
И вы можете сдампить его, используя инструмент objcopу:
Code:
objcopy -j .bios440 -O binary --set-section-flags .bios440=a \
vmware-vmx bios440.rom.zl
Ммм... Это означает, что... если у нас есть привилегии на машине жертвы, мы можем изменить исполняемый VMware-VMX, вставляя наш собственный инфицированный BIOS, и он будет выполняться каждый раз, когда загружается VMware. Для каждого из VMware на компьютер. Sweet!
Но Существуют более простые способы решения этой задачи. Мы собираемся изменить его несколько раз, и он не будет работать все время... Чем проще, тем лучше.
---[3.1.2 - Настройка VMWARE для загрузки альтернативного BIOS
Мы поняли, что VMWare предлагает очень практичный путь, чтобы пользователь мог использовать конкретный файл прошивки BIOS прямо через файл конфигурации .VMX. Существует не очень известный тег, который называется "bios440.filename" и он позволяет избегать использование встроенного в VMWare BIOS и вместо этого позволяет нам указать BIOS файл, который нужно использовать. Добавь в файл .VMX следующий код:
Code:
bios440.filename = "path/to/file/bios.rom"
На нах! Теперь у нас есть другая прошивка BIOS, которая работает в нашей VM, и в сочетании с:
Code:
debugStub.listen.guest32 = "TRUE" or
debugStub.listen.guest64 = "TRUE"
ставит GDB заглушки на VMWare и ждет вашего соединения на локальный порт 8832. И мы в конечном итоге с остаемся с отличной и полностью поддающейся отладке исследовательской платформой. Нравится? Другими важными скрытыми тегами, которые могут быть полезны, являются:
Code:
bios.bootDelay = "3000" # Для задержки загрузки X
миллисекундах
debugStub.hideBreakpoints = "TRUE" # Позволяет GDB
работать с остановками
debugStub.listen.guest32.remote = "TRUE" # Для отладки с
другой машины (32bit)
debugStub.listen.guest64.remote = "TRUE" # Для отладки с
другой машины (64bit)
monitor.debugOnStartGuest32 = "TRUE" # Позволяет остановить VM
на первой инструкции
по адресу 0xFFFF0
---[3.1.3 - Распаковка прошивки
Как мы уже говорили, некоторые из модулей сжаты LZH. Есть несколько доступных средств для извлечения и распаковки каждого отдельного модуля файла прошивки. Наиболее часто используемыми являются Phnxdeco и Awardeco (два отличных Linux GPL инструмента) совместно с Phoenix BIOS Editor и Award BIOS Editor (не GPL инструменты для Windows).
Если хочешь, можешь использовать Phoenix BIOS Editor в Linux с помощью wine. Он будет извлекать все модули в каталог/временный каталог внутри Phoenix BIOS Editor, которые готовы к открытию привычным тебе дизассемблером. Хорошей возможностью Phoenix BIOS Editor является то, что он также может восстанавливать основной файл прошивки. Он может сжимать и встраивать различные распакованные модули, чтобы прошивка была в неизменном виде. Учти, что эта функция была сделана для последних версий Phoenix BIOS и он пропускает проверку контрольной суммы, поэтому нам придется делать это вручную (мы увидим это в 3.2.2.1)
Некоторые из этих задач выполняются отдельными инструментами, которые могут быть вызваны непосредственно из командной строки, что является очень удобным, для того чтобы автоматизировать процесс для исследования простых скриптов.
---[3.1.4 - Модификации
Итак, вот мы и приблизились к самому интересному. У нас есть все распакованные модули, и возможность их изменения, а затем и восстановления в полностью рабочий BIOS Flash Update. Первая фраза, которая приходит на ум это, "где патчить?". Мы можем поставить "ловушку" на выполнение нашего кода почти в любом месте. Но мы должны все продумать, прежде чем решить о том, в каком месте патчить.
В начале мы думали о подключении к первой инструкции, которую выполняет процессор, а именно 0xF000: FFF0. Это казалось самым лучшим вариантом, потому что эта команда всегда в точном месте, и ее легко найти. Но мы должны принимать во внимание сам процесс выполнения. Чтобы наш код работал, все распознавание оборудования должно производится нами (DRAM, северный мост, кэш, PCI и т.д.)
Например, если мы хотим иметь доступ к жестким дискам, мы должны быть уверены, что, при выполнении нашего кода, мы уже имеем доступ к жесткому диску. По этой причине мы выбрали для подключения алгоритм декомпрессии. Также это удобно потому, что он не меняется от версии к версии. Кроме того, его очень легко найти путем поиска по шаблону. Он не сжат и вызывается много раз в течение последовательной загрузки BIOS, что дает нам возможность проверить, все ли необходимые службы доступны и приступить к реальным вещам. Далее мы имеем дамп скрипта для быстрого извлечения прошивки модулей, сбора данных, их внедрения, и компиляции измененного файла прошивки. PREPARE.EXE и CATENATE.EXE являются собственными инструменты создания прошивки Phoenix, которые можно найти в Phoenix BIOS Editor, а также в комплекте с другими инструментами. В более поздних версиях скрипта эти инструменты не нужны (как показано в 3.2.2.1).
[CODE]
Code:
#!/usr/bin/python import os,struct
#--------------------------- Decomp processing ------------------------------
#assemble the whole code to inject
os.system('nasm ./decomphook.asm')
decomphook = open('decomphook','rb').read()
print "Leido hook: %d bytes" % len(decomphook)
minihook = '\x9a\x40\x04\x3b\x66\x90' # call near +0x430
#Load the decompression rom
decorom = open('DECOMPC0.ROM.orig','rb').read()
#Add the hook
hookoffset=0x23
decorom = decorom[:hookoffset]+minihook+decorom[len(minihook)+hookoffset:]
#Add the shellcode
decorom+="\x90"*100+decomphook
decorom=decorom+'\x90'*10
#recalculate the ROM size
decorom=decorom[:0xf]+struct.pack("
Переводчик: Ex0rcist a.k.a. Heroin
Оригинал (EN): www.phrack.org (http://www.phrack.org/issues.html?issue=66&id=7)
Источник (RU): www.reverse4you.org (http://forum.reverse4you.org/showthread.php?t=899)
Persistent BIOS Infection
------[ 0.- Предисловие
Уважаемые пользователи, если вы читаете эту статью, мы можем предположить, что вы уже знаете, что такое BIOS и как он работает. Или, по крайней мере, вы имеете общtе представление о том, что делает BIOS, и его значение для нормальной работы компьютера. Основываясь на этом, мы кратко объясним некоторые основные понятия, чтобы ввести в курс дела, а затем мы будем переходить к более актуальным техническим тонкостям.
------[ 1.- Введение
На протяжении многих лет многое было сказано по этой теме. Но кроме старого вируса Chernobyl, который просто обнулял BIOS, если твоя материнская плата была одной из поддерживаемых, или для некоторых изменений для моддинга, такими как работа Pinczakko, мы не в состоянии найти общедоступные разработки, характерные для определенного класса вредоносных BIOS инфекций. Люди, как правило, думают, что эта тема раскурена вдоль и поперек, стара и имеются готовые разработки. Иногда даже путают с MBR вирусами. Мы намерены показать, что такой тип атаки возможен и может быть очень надежным и стойким руткитом, находясь в прошивке BIOS и оставаясь невидимой для ОС инфекцией.
В этой статье мы покажем универсальный метод, чтобы внедрить код в BIOS прошивки. Этот метод позволит нам встроить наш собственный код в BIOS прошивки так, что он будет выполнен непосредственно перед загрузкой операционной системы.
Мы также продемонстрируем, как с контролем жесткого диска или просто путем изменения конфиденциальных данных ОС в Linux box, развертывать полностью функциональный код непосредственно в процесс Windows.
---[ 1.1 - Назначение статьи
Основной идеей данной работы является показать то, как BIOS прошивки можно модифицировать и использовать как метод сохранения контроля после успешного рутанья. Ну, начнем потихонечку и постепенно будем рассматривать возникающие вопросы, разделив статью в двух основных направлениях:
- Модификации VMWare's (Phoenix) BIOS
- Рельные модификации BIOS
В каждом разделе мы расскажем основные моменты, чтобы показать, как провести атаку, а затем перейдем непосредственно к рассмотрению кода.
------[ 2.- Основы BIOS
---[2.1 - Введение в BIOS
Из википедии:
BIOS - загрузочная прошивка, запускаящаяся и исполняющая код самой первой после включения ПК. Начальной функцией BIOS является запуск тестирования и инициализация системных устройств, таких как видеокарта, жесткий диск, флоппи и проч. Это делается для подготовки машины к запуску с заданными параметрами так, чтобы загружалось и выполнялось установленное на носителях программное обечпечение, и передача управления ПК. Этот процесс известен как загрузка, за которой следует короткая преднастройка.
...создать небольшую библиотеку базовой системы ввода / вывода функций, которая может быть вызвана при эксплуатации и управлении периферийными устройствами, такими как клавиатура, функциями отображения текста и так далее. В IBM PC и в некоторых периферийных устройствах, таких как жесткий диск и контроллеры видеоадаптеров, имеется их собственный BIOS Extension ROM, который, предоставляет дополнительные функции. Операционные системы и исполнительняемое программное обеспечение, предназначенное для замены этих базовых функций прошивки, обеспечивает замену интерфейса программного обеспечения для приложений.
---[2.1.1 - Железо
Еще в 80-х BIOS прошивки загружались в ПЗУ или ППЗУ чипы, которые не могли быть изменены, но в настоящее время эта прошивка хранится в EEPROM (электрически стираемая программируемая Read-Only память). Этот вид памяти разрешает пользователю перепрошивать его, позволяя поставщику создавать обновления встроенного программного обеспечения для того чтобы исправить ошибки, добавить поддержку нового железа и функциональности.
---[2.1.2 - Как это работает?
BIOS имеет очень важное значение в работе компьютера. Он должен быть всегда доступен, как первая инструкция, выполняемая центральным процессором, при его включении. Вот почему он хранится в ROM.
Первый модуль BIOS называется загрузочный блок (Bootblock) и отвечает за POST (Power-On Self-Test) и аварийную загрузочную процедуру. POST является общим термином предварительной загрузки для компьютера, маршрутизатора или принтера. Он должен протестировать и инициализировать почти все аппаратные компоненты в системе, чтобы убедиться, что все работает правильно.
Современный BIOS имеет модульную структуру, что означает, что есть несколько модулей, интегрированных в одну прошивку, каждый из которых отвечает за конкретные задачи, от аппаратной инициализации до безопасности.
Каждый модуль является сжатым, поэтому есть точный алгоритм декомпрессии, отвечающий за декомпрессию и проверку других модулей, которые впоследствии будут выполняться.
После декомпрессии, определяются другие аппаратные средства, такие как PCI ROM (если необходимо), и в конце концов, в поисках загрузчика, читается 0 сектор жесткого диска (MBR), чтобы начать загрузку операционной системы.
---[2.2 - Файловая структура прошивки
Как мы упоминали ранее, прошивка BIOS имеет модульную структуру. При хранении в нормальном файле, он состоит из нескольких LZH сжатых модулей, каждый из которых содержит 8 бит контрольной суммы. Однако, не все модули являются сжатыми. Несколько модулей, такие как загрузочный блок (Bootblock) и алгоритм декомпрессии, явно не сжаты, потому что они являются фундаментальной частью процесса загрузки и должны выполнять декомпрессию других модулей. Далее мы увидим, почему для нас это так удобно.
Мы имеем выход Phnxdeco (доступны в Debian репозитории), открытый исходный код для разбора и анализа прошивки Phoenix BIOS ROM (то, что собираемся извлечь в 3.1.1):
Code:
+-------------------------------------------------------------------------+
| Class.Instance (Name) Packed ---> Expanded Compression Offse |
+-------------------------------------------------------------------------+
B.03 ( BIOSCODE) 06DAF (28079) => 093F0 ( 37872) LZINT ( 74%) 446DFh
B.02 ( BIOSCODE) 05B87 (23431) => 087A4 ( 34724) LZINT ( 67%) 4B4A9h
B.01 ( BIOSCODE) 05A36 (23094) => 080E0 ( 32992) LZINT ( 69%) 5104Bh
C.00 ( UPDATE) 03010 (12304) => 03010 ( 12304) NONE (100%) 5CFDFh
X.01 ( ROMEXEC) 01110 (04368) => 01110 ( 4368) NONE (100%) 6000Ah
T.00 ( TEMPLATE) 02476 (09334) => 055E0 ( 21984) LZINT ( 42%) 63D78h
S.00 ( STRINGS) 020AC (08364) => 047EA ( 18410) LZINT ( 45%) 66209h
E.00 ( SETUP) 03AE6 (15078) => 09058 ( 36952) LZINT ( 40%) 682D0h
M.00 ( MISER) 03095 (12437) => 046D0 ( 18128) LZINT ( 68%) 6BDD1h
L.01 ( LOGO) 01A23 (06691) => 246B2 (149170) LZINT ( 4%) 6EE81h
L.00 ( LOGO) 00500 (01280) => 03752 ( 14162) LZINT ( 9%) 708BFh
X.00 ( ROMEXEC) 06A6C (27244) => 06A6C ( 27244) NONE (100%) 70DDAh
B.00 ( BIOSCODE) 001DD (00477) => 0D740 ( 55104) LZINT ( 0%) 77862h
*.00 ( TCPA_*) 00004 (00004) => 00004 ( 004) NONE (100%) 77A5Ah
D.00 ( DISPLAY) 00AF1 (02801) => 00FE0 ( 4064) LZINT ( 68%) 77A79h
G.00 ( DECOMPCODE) 006D6 (01750) => 006D6 ( 1750) NONE (100%) 78585h
A.01 ( ACPI) 0005B (00091) => 00074 ( 116) LZINT ( 78%) 78C76h
A.00 ( ACPI) 012FE (04862) => 0437C ( 17276) LZINT ( 28%) 78CECh
B.00 ( BIOSCODE) 00BD0 (03024) => 00BD0 ( 3024) NONE (100%) 7D6AAh
Мы видим здесь различные части файла прошивки, содержащие DECOMPCODE раздел, где расположен алгоритм декомпрессии, а также другие, не рассматриваемые в этой статье параметры.
---[2.3 - Обновление
Программное обеспечение BIOS не так уж сильно отличается от любого другого программного обеспечения. Это относится к ошибкам, которые можно встретить и в другом программном обеспечении. С новыми версиями выходит поддержка нового железа, дополнения, исправление ошибок и т. д. Но процесс обновления может быть очень опасным на реальной машине. BIOS является одним из основных компонентов компьютера. Это первая часть кода, выполняемая при включении машины. Именно поэтому мы должны быть очень осторожны, когда делаем такого рода вещи. Неудачное обновление BIOS может привести к зависанию машины. И ты соснешь тунца.
Вот почему так важно иметь такую платформу для тестирования как VMWare. По крайней мере на первое время, потому что, как мы увидим далее, есть много различий между VMware и реальным железом.
------[ 3 .- Заражение BIOS
--- [3.0 - Первичная настройка
--- [3.1 - Модификация VMware (Phoenix) BIOS
Во-первых, мы должны получить действительную прошивку VMWARE BIOS для работы. Для того чтобы читать EEPROM (где хранится прошивка BIOS) нам необходимо запустить код в режиме отладки ядра, чтобы отправлять и получать данные непосредственно в южный мост через порты ввода-вывода. Для этого нам также необходимо знать некоторые конкретные данные о текущем оборудовании. Эти данные обычно предоставляются производителем. Более того, почти все поставщики плат предоставляют некоторые инструменты для обновления BIOS, и очень часто они имеют возможность резервного копирования существующей прошивки.
В VMWare мы не можем использовать эти инструменты, потому что эмулируемое железо не имеет ту же функциональность, как реальное оборудование. В этом есть смысл... Почему бы не обновить VMWare BIOS изнутри...?
---[3.1.1 - Дамп VMWare BIOS
Для начала было бы неплохо иметь встроенный GDB сервер, который предлагает VMWare. Он позволяет нам производить отладку и понимать, что происходит. Таким образом, в целях исправления и изменения некоторых маленьких кусков кода, чтобы начать тестирование, мы использовали некоторые случайные массивы байтов в качестве шаблонов для поиска BIOS в памяти.П роделывая это, мы обнаружили, что в VMware-VMX существует основная исполняемая VMware секция, весом почти 256кб, которая называется .bios440 (которая в нашей версии VMware находится между смещением в файле 0x6276c7-0x65B994). Она содержит всю прошивку BIOS, точно так же, как и в обычном файле, готовом к выполнению.Вы можете использовать objdump для того чтобы видеть разделы файла:
Code:
objdump -h vmware-vmx
И вы можете сдампить его, используя инструмент objcopу:
Code:
objcopy -j .bios440 -O binary --set-section-flags .bios440=a \
vmware-vmx bios440.rom.zl
Ммм... Это означает, что... если у нас есть привилегии на машине жертвы, мы можем изменить исполняемый VMware-VMX, вставляя наш собственный инфицированный BIOS, и он будет выполняться каждый раз, когда загружается VMware. Для каждого из VMware на компьютер. Sweet!
Но Существуют более простые способы решения этой задачи. Мы собираемся изменить его несколько раз, и он не будет работать все время... Чем проще, тем лучше.
---[3.1.2 - Настройка VMWARE для загрузки альтернативного BIOS
Мы поняли, что VMWare предлагает очень практичный путь, чтобы пользователь мог использовать конкретный файл прошивки BIOS прямо через файл конфигурации .VMX. Существует не очень известный тег, который называется "bios440.filename" и он позволяет избегать использование встроенного в VMWare BIOS и вместо этого позволяет нам указать BIOS файл, который нужно использовать. Добавь в файл .VMX следующий код:
Code:
bios440.filename = "path/to/file/bios.rom"
На нах! Теперь у нас есть другая прошивка BIOS, которая работает в нашей VM, и в сочетании с:
Code:
debugStub.listen.guest32 = "TRUE" or
debugStub.listen.guest64 = "TRUE"
ставит GDB заглушки на VMWare и ждет вашего соединения на локальный порт 8832. И мы в конечном итоге с остаемся с отличной и полностью поддающейся отладке исследовательской платформой. Нравится? Другими важными скрытыми тегами, которые могут быть полезны, являются:
Code:
bios.bootDelay = "3000" # Для задержки загрузки X
миллисекундах
debugStub.hideBreakpoints = "TRUE" # Позволяет GDB
работать с остановками
debugStub.listen.guest32.remote = "TRUE" # Для отладки с
другой машины (32bit)
debugStub.listen.guest64.remote = "TRUE" # Для отладки с
другой машины (64bit)
monitor.debugOnStartGuest32 = "TRUE" # Позволяет остановить VM
на первой инструкции
по адресу 0xFFFF0
---[3.1.3 - Распаковка прошивки
Как мы уже говорили, некоторые из модулей сжаты LZH. Есть несколько доступных средств для извлечения и распаковки каждого отдельного модуля файла прошивки. Наиболее часто используемыми являются Phnxdeco и Awardeco (два отличных Linux GPL инструмента) совместно с Phoenix BIOS Editor и Award BIOS Editor (не GPL инструменты для Windows).
Если хочешь, можешь использовать Phoenix BIOS Editor в Linux с помощью wine. Он будет извлекать все модули в каталог/временный каталог внутри Phoenix BIOS Editor, которые готовы к открытию привычным тебе дизассемблером. Хорошей возможностью Phoenix BIOS Editor является то, что он также может восстанавливать основной файл прошивки. Он может сжимать и встраивать различные распакованные модули, чтобы прошивка была в неизменном виде. Учти, что эта функция была сделана для последних версий Phoenix BIOS и он пропускает проверку контрольной суммы, поэтому нам придется делать это вручную (мы увидим это в 3.2.2.1)
Некоторые из этих задач выполняются отдельными инструментами, которые могут быть вызваны непосредственно из командной строки, что является очень удобным, для того чтобы автоматизировать процесс для исследования простых скриптов.
---[3.1.4 - Модификации
Итак, вот мы и приблизились к самому интересному. У нас есть все распакованные модули, и возможность их изменения, а затем и восстановления в полностью рабочий BIOS Flash Update. Первая фраза, которая приходит на ум это, "где патчить?". Мы можем поставить "ловушку" на выполнение нашего кода почти в любом месте. Но мы должны все продумать, прежде чем решить о том, в каком месте патчить.
В начале мы думали о подключении к первой инструкции, которую выполняет процессор, а именно 0xF000: FFF0. Это казалось самым лучшим вариантом, потому что эта команда всегда в точном месте, и ее легко найти. Но мы должны принимать во внимание сам процесс выполнения. Чтобы наш код работал, все распознавание оборудования должно производится нами (DRAM, северный мост, кэш, PCI и т.д.)
Например, если мы хотим иметь доступ к жестким дискам, мы должны быть уверены, что, при выполнении нашего кода, мы уже имеем доступ к жесткому диску. По этой причине мы выбрали для подключения алгоритм декомпрессии. Также это удобно потому, что он не меняется от версии к версии. Кроме того, его очень легко найти путем поиска по шаблону. Он не сжат и вызывается много раз в течение последовательной загрузки BIOS, что дает нам возможность проверить, все ли необходимые службы доступны и приступить к реальным вещам. Далее мы имеем дамп скрипта для быстрого извлечения прошивки модулей, сбора данных, их внедрения, и компиляции измененного файла прошивки. PREPARE.EXE и CATENATE.EXE являются собственными инструменты создания прошивки Phoenix, которые можно найти в Phoenix BIOS Editor, а также в комплекте с другими инструментами. В более поздних версиях скрипта эти инструменты не нужны (как показано в 3.2.2.1).
[CODE]
Code:
#!/usr/bin/python import os,struct
#--------------------------- Decomp processing ------------------------------
#assemble the whole code to inject
os.system('nasm ./decomphook.asm')
decomphook = open('decomphook','rb').read()
print "Leido hook: %d bytes" % len(decomphook)
minihook = '\x9a\x40\x04\x3b\x66\x90' # call near +0x430
#Load the decompression rom
decorom = open('DECOMPC0.ROM.orig','rb').read()
#Add the hook
hookoffset=0x23
decorom = decorom[:hookoffset]+minihook+decorom[len(minihook)+hookoffset:]
#Add the shellcode
decorom+="\x90"*100+decomphook
decorom=decorom+'\x90'*10
#recalculate the ROM size
decorom=decorom[:0xf]+struct.pack("