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

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

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

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

P.S. -тся

Да, «тся». А как дампил? Через dd? Может нужно было просто скопировать через cp -rp ?

через dd.Иначе никак ибо не смонтировано.

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

embedded

Для кого? Нет там никакой файловой системы, чтобы вот так просто.

что для кого? В общем и целом образа ядра в памяти нет?

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

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

а как бы помогло вам наличие файлов ядра оживить девайс то?

Отлично, ибо модулей небыло. Думаю можно извлечь. Вопрос в том как?

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

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

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

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

настолько уникальный, что нету. Не шучу. Правда нету. Это всё детали. Нужна помощь в извлечении ядра из дампа.)

Попробуй посмотреть с адреса 0x80008000. Я бы ожидал его с этого адреса, сплошным куском.

Нашёл интересные строки в логе 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)

попробую. А как вообще найти начало и конец ядра? Может есть сигнатуры?

А, да. Ты ведь в курсе, что в /dev/mem память не обязательно сплошным куском идёт?

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

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

Ну. Нет. А где почитать? Кстати адреса 0x80008000 у меня нет. Дамп 512 мб.

Хм. А причём WPE и линух? o_O

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

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

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

Ну так Microsoft же за Secure Boot стоит.

В продолжении темы. Кто знает как можно проанализировать дамп памяти? К сожалению binwalk толком ничего не нашёл(

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

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

что для кого?

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

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

Ок. Может существует способ запустить виртуалку с образом памяти?

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

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

Может существует способ запустить виртуалку с образом памяти?

Может и существует, но вопрос не по адресу. Я вообще попал в этот тред случайно.

Думаю так и было. 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

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

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

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

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

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

dd с ошибкой вылетел

Тогда можешь выбросить свой дамп.

И что, похожи эти 6553099 байт по смещению 0x02000000 на ядро?

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)

Вроде похожи. Но gzip compressed data?! Походу поврежден дамп.Возможно озу скремблирована? Или это фантастика?

Но gzip compressed data?!

Никогда не задумывался, что означает z в zImage?

Задумывался. Но если бы был корректный образ он бы был сжат весь. А не так. Насколько я помню)

Не сами же по себе данные распаковываются. Что-то должно код распаковать. Для этого это что-то само по себе должно быть несжатым кодом.