LINUX.ORG.RU

Извлечь ядро из дампа памяти

 , ,


0

2

Доброе время суток. Снял дамп памяти с одного устройства на базе arm-процессора (dd if=/dev/mem...). Задача состоит в том чтобы извлечь ядро, initrd и загрузчик. А вопрос в том грузится ли ядро в память целиком? Соответственно можно ли вообще вырезать его из дампа. binwalk видит ядро но извлекает какие-то потоки. Заранее спасибо:) Лог от binwalk будет чуть позже)

Задача состоит в том чтобы извлечь ядро, initrd и загрузчик.

Эм... а не проще скопировать всё это с диска, с которого грузиться это устройство, вместо возни с дампом памяти?

Vsevolod-linuxoid ★★★★★ ()
Ответ на: комментарий от Vsevolod-linuxoid

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

P.S. -тся

Doctor_Dark ()
Ответ на: комментарий от Vsevolod-linuxoid

Устройство китайский тв-бокс с функцией secureboot. И шифрованой флешкой. Как получить доступ к флешке не понятно. Я видимо, нарушил её целостность. Тв-бокс в бутлупе. Больше доступа к нему не имею.(

Doctor_Dark ()

А вопрос в том грузится ли ядро в память целиком?

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

i-rinat ★★★★★ ()
Ответ на: комментарий от xmikex

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

Doctor_Dark ()
Ответ на: комментарий от Doctor_Dark

китайский тв-бокс

настолько уникальный что «в интернетах» не то, что его «прошивок» (дампов) нет, но и нигде он не обсуждается?

попытались флешку прочитать и устройство «заблокировалось» (или что-то ещё/другое делали)?

anymouze ()
Ответ на: комментарий от Doctor_Dark

Нашёл интересные строки в логе binwalk 33554468 0x2000024 Linux kernel ARM boot executable zImage (little-endian), load address: «0x00000000», end address: «0x00634390»

514166784 0x1EA59000 ELF, 32-bit LSB shared object, ARM, version 1 (SYSV) 514318336 0x1EA7E000 ELF, 32-bit LSB executable, ARM, version 1 (SYSV)

Doctor_Dark ()
Ответ на: комментарий от Doctor_Dark

Может есть сигнатуры?

Если там был SecureBoot, то скорее всего, ядро было запаковано в Windows portable executable. Начинается с «MZ». Только вот непонятно, будет ли оно в памяти именно так же.

i-rinat ★★★★★ ()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от Doctor_Dark

А где почитать?

Вот прямо тут: «Память не обязательно сплошная. У процессора и железок бывают регистры, отображаемые в память, поэтому память не обязательно отображается сплошным куском.» По факту, /dev/mem это разреженый псевдофайл, но пустые области не возвращают нули, как в нормальных файлах. Вместо этого функции чтения возвращают ошибки.

Нет, я не знаю как дампить. Думаю, подойдут SEEK_DATA и SEEK_HOLE в lseek(). Но вот какие готовые утилиты так могут, не знаю.

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

Вот ТСу и хинт, в какую сторону копать. Но это долго, больно и скорее всего не принесёт результата.

mord0d ()
Ответ на: комментарий от Doctor_Dark

что для кого?

Человек ответил в тред, не заметив, что ты интересуешься про embedded, и стал писать про диски, файлы.

На остальной вопрос тебе уже ответил i-rinat.

mord0d ()
Ответ на: комментарий от mord0d

Так себе хинт. ТС уже сдампил память с помощью dd. Скорее всего, у него до того места, где ядро находится, dd и не добрался. Завершил работу на первой дыре в адресном пространстве.

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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

Думаю так и было. dd с ошибкой вылетел. Однако в дампе иногда встречается версия ядра в виде строки.

Вот инфа из лога загрузки:

The DDR Layout: Total DDR: 0x00000000 - 0x20000000 [ ] 512MB stack: 0x00000000 - 0x00a00000 [CB] 10MB malloc: 0x00a00000 - 0x00afe000 [CB] 1016KB global: 0x00afe000 - 0x00c00000 [CB] 1.0MB .text: 0x00c00000 - 0x00c1a9fc [CB] 106.49KB .data: 0x00c1a9fc - 0x00d81e40 [CB] 1.40MB pagetable: 0x00e00000 - 0x00e04000 [CB] 16KB irqstack: 0x00e04000 - 0x00e24000 [CB] 128KB DMA: 0x00f00000 - 0x01100000 [ ] 2MB free: 0x01100000 - 0x09100000 [ ] 128MB resmem: 0x1c000000 - 0x20000000 [ ] 64MB

Kernel Name: Linux-3.18.13_s40 Kernel Size: 6553099 Load Address: 0x02000000 Entry Address: 0x02000000

Doctor_Dark ()
Ответ на: комментарий от Doctor_Dark
Kernel Name: Linux-3.18.13_s40
Kernel Size: 6553099
Load Address: 0x02000000
Entry Address: 0x02000000

The DDR Layout:
Total DDR: 0x00000000 - 0x20000000 [ ] 512MB
stack: 0x00000000 - 0x00a00000 [CB] 10MB
malloc: 0x00a00000 - 0x00afe000 [CB] 1016KB
global: 0x00afe000 - 0x00c00000 [CB] 1.0MB
.text: 0x00c00000 - 0x00c1a9fc [CB] 106.49KB
.data: 0x00c1a9fc - 0x00d81e40 [CB] 1.40MB
pagetable: 0x00e00000 - 0x00e04000 [CB] 16KB
irqstack: 0x00e04000 - 0x00e24000 [CB] 128KB
DMA: 0x00f00000 - 0x01100000 [ ] 2MB
free: 0x01100000 - 0x09100000 [ ] 128MB
resmem: 0x1c000000 - 0x20000000 [ ] 64MB
Doctor_Dark ()
Ответ на: комментарий от i-rinat

Скорее всего, у него до того места, где ядро находится, dd и не добрался.

Если ТС запускал с noerror, то может и добрался.

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

Вот потому я и написал, что

скорее всего не принесёт результата.

mord0d ()
Ответ на: комментарий от i-rinat

binwalk говорит

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
36            0x24            Linux kernel ARM boot executable zImage (little-endian), load address: "0x00000000", end address: "0x00634390"
16924         0x421C          gzip compressed data, maximum compression, from Unix, NULL date (1970-01-01 00:00:00)

Doctor_Dark ()