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

Попробуй для начала binwalk какой натрави

достать некоторые файлы

Попробуйте через gpart вытащить

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

Может натравить на дамп kpartx и смонтировать loop с файловой системой.

Норкомания. Просто через losetup монтируется.

вот вывод 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

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

7z l dump.bin

Команды без черты.

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

И 7-Zip надо поновее, так только архивы прочитает, а новый уже таблицы разделов с ФС.

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: dump.bin: Can not open file as archive

mount /dev/loop0 dump.bin mount: /dev/loop0: can't read superblock

насколько я понимаю, просто дамп не получится подмонтировать , а нужно доставать из него партишины, или я чтото не так понимаю?

qemu-nbd + offset

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

не благодари

устройства нет в системе пока оно не подмонтировано, есть файл слитого дампа с флешки.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

# losetup -o 8129014 --sizelimit 24092727 -f --show dump.bin
# mount /dev/loop0 /mnt/tmp -o ro

Со второй фс по аналогии.

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.

Может фс быть дополнительно сжата, или закодирована ? Вот ссылка на на дамп

ftp://193.104.85.200/S29GL512N11FFA02(BGA64).bin

В ядре твоего Linux есть поддержка cramfs?

хм..., а как узнать ?

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

Посмотреть в /proc/filesystems и смотри есть ли модуль для ядра с поддержкой cramfs.

find /lib/modules/ -type f -name 'cram*'

find /lib/modules/ -type f -name 'cram*'

/lib/modules/4.4.0-31-generic/kernel/fs/cramfs/cramfs.ko

/lib/modules/4.4.0-112-generic/kernel/fs/cramfs/cramfs.ko

и в /proc/filesystems есть

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

cramfs: unsupported filesystem features

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

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

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

Вот тут был патчик на предмет поддержки LZO:
https://lkml.org/lkml/2007/10/30/556

поставил самый новый binwalk, и в его выводе ни строчки про cramfs

Моя цитата от 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...