LINUX.ORG.RU

как подмонтировать дамп слитый с флешки?

 


1

2

Добрый день! Есть дамп слитый с S29GL512N11FFA02 , стоит в автомобильном спидометре на базе процессора Nvidia tegra 3, заведомо известно, что ето загрузочная флешка с линуксом. Нужно подмонтировать и достать некоторые файлы. пробовал монтировать как ext2-4 , cramfs,squashfs, не монтируется. Подскажите возможно вообще ето зделать и в какую сторону копать, так как никогда не сталкивался с такой задачей.

Поставить виртуалбокс сделай там диск динамический формата вхд или ещё проще из управления дисками создай , подключи его в шинде и форматни в нтфс , скачай лехонький линь iso подключи в виртуалбоксе созданный вхд и грузись с iso , есть ещё вариант попробуй открыть свой этот дамп архиватором 7z. P.S Griggorii

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

вот вывод 7z 7z -l dump.bin

7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,4 CPUs)

Error: Incorrect command line

Можно по подробнее про процедуру с виртулбоксом ? дамп монтировать в виртуалбокс ?

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

binwalk dump.bin

DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 2381160 0x245568 CRC32 polynomial table, little endian

2385256 0x246568 CRC32 polynomial table, big endian

2392379 0x24813B Copyright string: «Copyright 1995-2010 Mark Adler »

2393377 0x248521 Android bootimg, kernel size: 1701331712 bytes, kernel addr: 0x75736B63, ramdisk size: 1868963949 bytes, ramdisk addr: 0x656B2072, product name: «h!»

5395816 0x525568 CRC32 polynomial table, little endian

5399912 0x526568 CRC32 polynomial table, big endian

5407035 0x52813B Copyright string: «Copyright 1995-2010 Mark Adler »

5408033 0x528521 Android bootimg, kernel size: 1701331712 bytes, kernel addr: 0x75736B63, ramdisk size: 1868963949 bytes, ramdisk addr: 0x656B2072, product name: «h!» 6503456 0x633C20 PNG image, 39 x 25, 8-bit/color RGBA, non-interlaced

6503534 0x633C6E Zlib compressed data, best compression

6505053 0x63425D PNG image, 40 x 25, 8-bit/color RGBA, non-interlaced

6815744 0x680000 Android bootimg, kernel size: 3896430 bytes, kernel addr: 0x8000, ramdisk size: 0 bytes, ramdisk addr: 0x8200000, product name: «»

8129014 0x7C09F6 CramFS filesystem, little endian, size: 24092727 version 2 CRC 0x000B2039, edition 3238732015, 561512555 blocks, 6242395 files

39583744 0x25C0000 Android bootimg, kernel size: 5283026 bytes, kernel addr: 0x8000, ramdisk size: 0 bytes, ramdisk addr: 0x8200000, product name: «»

40899507 0x27013B3 CramFS filesystem, little endian, size: 24092727 version 2 CRC 0x0053200C, edition 729145, 729327 blocks, 1074470921 files

yurkou ()

1. dmesg - смотришь, как определилось устройство
2. fdisk -l - смотришь структуру
3. mount -o loop - монтируешь нужный тебе раздел
4. cp - копируешь нужные тебу файлы/директории
5. ....................
6. PROFIT

не благодари

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

устройства нет в системе пока оно не подмонтировано, есть файл слитого дампа с флешки.dmesg ничего не покажет, пока не подмонтировать.

fdisk -l dump.bin Disk dump.bin: 64 MiB, 67108864 bytes, 131072 sectors

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

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

losetup -o 8129014 --sizelimit 24092727 -f --show dump.bin /dev/loop0

losetup: dump.bin: Warning: file does not fit into a 512-byte sector; the end of the file will be ignored.

mount /dev/loop0 /mnt/tmp -o ro

mount: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error

In some cases useful info is found in syslog - try dmesg | tail or so.

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

Slackware 14.2, 64-бит
В обоих случаях (-o 8129014 и -o 40899507) в dmesg вывод от cramfs одинаков:

cramfs: unsupported filesystem features

Соответственно, или binwalk ошибся при определении расположения ФС:
8129014       0x7C09F6        CramFS filesystem, little endian, size: 24092727 version 2 CRC 0x000B2039, edition 3238732015, 561512555 blocks, 6242395 files
40899507      0x27013B3       CramFS filesystem, little endian, size: 24092727 version 2 CRC 0x0053200C, edition 729145, 729327 blocks, 1074470921 files

Или действительно выставлены флаги, которые не поддерживаются имеющимся в наличии модулем cramfs.

Нужно разбираться предметно.

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

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

2393377 0x248521 Android bootimg, kernel size: 1701331712 bytes, kernel addr: 0x75736B63, ramdisk size: 1868963949 bytes, ramdisk addr: 0x656B2072, product name: «h!» ето типа ядро андроида ?

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

Моя цитата от binwalk 2.1.1 — это последний релиз от 23.12.2015, после него действительно сделано 256 комитов на github:
https://github.com/ReFirmLabs/binwalk/releases

Три из них помечены комментарием:
«Improved CramFS false positive detection»
https://github.com/ReFirmLabs/binwalk/commit/2ed5e09968e64188e62e0f7219ec6916...
https://github.com/ReFirmLabs/binwalk/commit/2491d80b697b9fb0517272943b0bdefa...
https://github.com/ReFirmLabs/binwalk/commit/62e9caa164305a18d7d1f037ab27d14a...

Так что не исключено, что оба случая «похожести» на CramFS были ложным срабатыванием (false positive), которое вылечено в ходе последующей разработки binwalk...

bormant ★★★★★ ()
Последнее исправление: bormant (всего исправлений: 2)