Compressie .bin archief achterhalen

[shotputty]

Voor een oude router ben ik een .bin firmware bestand aan het analyseren. Met binwalk kan ik dit bestand probleemloos uitpakken in 2 nieuwe bestanden en daarna in een compleet linux filesystem.
Omdat binwalk die bestanden niet weer terug kan comprimeren tot het orginele .bin bestand ben ik op zoek naar de methode waarmee ze samengesteld zijn. Ik ben er inmiddels 2 dagen mee bezig maar loop nu vast.

Binwalk geeft me een goede hint, het lijkt om een ELF bestand te gaan:

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
64 0x40 ELF, 64-bit MSB MIPS32 rel2 executable, MIPS, version 1 (SYSV)
4231232 0x409040 Linux kernel version 2.6.16
4262864 0x410BD0 DES SP2, big endian
4263376 0x410DD0 DES SP1, big endian
4272784 0x413290 CRC32 polynomial table, little endian
4274175 0x4137FF Copyright string: "Copyright 1995-1998 Mark Adler "
4359512 0x428558 Unix path: /sys/module/perf_counters/parameters/counter{0,1}
4359566 0x42858E Unix path: /sys/module/perf_counters/parameters/l2counter{0-3}
4365712 0x429D90 Unix path: /usr/lib/libc.so.1
4383056 0x42E150 Unix path: /usr/gnemul/irix/
4387424 0x42F260 Unix path: /dev/vc/0
4478008 0x445438 Ubiquiti firmware header, third party, ~CRC32: 0x48495441, version: "-"
4493176 0x448F78 Unix path: /etc/flash/etc/kernel_dump_message.txt
4566256 0x45ACF0 HTML document header
4566373 0x45AD65 HTML document footer
4566392 0x45AD78 HTML document header
4566478 0x45ADCE HTML document footer
4566488 0x45ADD8 HTML document header
4566605 0x45AE4D HTML document footer
4566616 0x45AE58 HTML document header
4566729 0x45AEC9 HTML document footer
4566744 0x45AED8 HTML document header
4566867 0x45AF53 HTML document footer
4566880 0x45AF60 HTML document header
4567001 0x45AFD9 HTML document footer
4567016 0x45AFE8 HTML document header
4567147 0x45B06B HTML document footer
4573960 0x45CB08 HTML document header
4574088 0x45CB88 HTML document footer
4583999 0x45F23F Neighborly text, "NeighborSolicitsts"
4584023 0x45F257 Neighborly text, "NeighborAdvertisements"
4584240 0x45F330 Neighborly text, "NeighborSolicitstRedirects"
4584272 0x45F350 Neighborly text, "NeighborAdvertisementsmbResponses"
4591423 0x460F3F Neighborly text, "neighbor %.2x%.2x.%.2x:%.2x:%.2x:%.2x:%.2x:%.2x lost on port %d(%s)(%s)"
5525568 0x545040 gzip compressed data, maximum compression, from Unix, last modified: 2021-06-21 08:44:48
10307754 0x9D48AA StuffIt Deluxe Segment (data): f
13485177 0xCDC479 MySQL ISAM index file Version 9

Ook "file" geeft wat informatie:

/bin/echo: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c9a0169474cb097fb336f587c28614a4168ec637, stripped, too many notes (256)

Echter als ik het .bin bestand met readelf probeer te openen krijg ik het volgende:

readelf: QVF7303_v2.1.0.13.bin: Error: Not an ELF file - it has the wrong magic bytes at the start

Ik heb ondertussen nog een heel scala aan programma's geprobeerd zoals 7zip, rar, lzma, gzip etc maar allen herkennen ze het bestand niet.
Als ik het .bin bestand met een hex-editor bekijk dan zijn de eerste karakters QVM2100.IMG. Daarna heb ik onder andere nog even bekeken of Winiso het bestand herkende maar helaas.

Wat zou ik nog meer kunnen proberen om de archiveringsmethode te achterhalen?

[Bergen]

shotputty schreef op zondag 4 december 2022 @ 23:54:

Echter als ik het .bin bestand met readelf probeer te openen krijg ik het volgende:
> readelf: QVF7303_v2.1.0.13.bin: Error: Not an ELF file - it has the wrong magic bytes at the start

Ja, omdat het bestand inderdaad geen ELF-binary is. Althans, de ELF-binary begint pas bij byte 64, zoals je ook in je listing laat zien:

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
64 0x40 ELF, 64-bit MSB MIPS32 rel2 executable, MIPS, version 1 (SYSV)

Een ELF-binary hoort met byte 0x7F en dan de 3 karakters "ELF" te beginnen. Zoiets noem je de FourCC (four character code), of "magic number". Die zie je in een hex-editor inderdaad pas bij byte 64 (0x40) staan:


En in plaats daarvan begint het bestand met een QVM2100-header. (Betreft het een QVM2100 router?) Als je die eerste 64 bytes eraf haalt (bijvoorbeeld met tail), houd je vast wel een geldige ELF-binary over, al zou het ook kunnen dat de binary maar een gedeelte van het bestand beslaat en dat er nog andere data achteraan komt, bijvoorbeeld een aantal ingepakte bestanden die in filesystem moeten worden geplaatst. Met name omdat je in je dump ook HTML tags ziet. Maar de bestanden zouden ook in de ELF-binary kunnen zijn geëmbed... Hopelijk geeft binwalk daar meer inzicht in.

[ Voor 7% gewijzigd door Bergen op 05-12-2022 00:22 ]

[shotputty]

Bergen schreef op maandag 5 december 2022 @ 00:16:
[...]
En in plaats daarvan begint het bestand met een QVM2100-header. (Betreft het een QVM2100 router?) Als je die eerste 64 bytes eraf haalt (bijvoorbeeld met tail), houd je vast wel een geldige ELF-binary over..

Geniale oplossing, dat werkt! Ik heb het met dd geknipt.

readelf -h dd-out.bin
ELF Header:
Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0xffffffff81602000
Start of program headers: 64 (bytes into file)
Start of section headers: 26292360 (bytes into file)
Flags: 0x808b0001, noreorder, octeon, mips64r2
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 1
Size of section headers: 64 (bytes)
Number of section headers: 26
Section header string table index: 25

Het is een QVF7303 router, waarschijnlijk hebben ze wat overlap met hun andere modellen.