Could not make sure if extracted image is correct about binwalk HOT 20 CLOSED

It is valid; binwalk's -e option extracts it just fine (binwalk uses the p7zip utility, so you might try that instead of the utility you were using).

To answer your question more generally, one way to double-check binwalk's LZMA results is to overlay the signature results onto an entropy graph (use the -B and -E options together). An LZMA header should occur at the beginning of a block of high entropy data; if it does not, it is probably a false positive.

The -L option has been removed from binwalk 2.0.

from binwalk.

No luck. 7z from p7zip package still says "Data Error". Interestingly, using "l -slt" options gives some info:

7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=pt_BR.utf8,Utf16=on,HugeFiles=on,2 CPUs)

Listing archive: 8814.7z

Path = 8814.7z
Type = lzma

Size = 268435456
Packed Size = 1320970
Method = LZMA:23

Maybe the firmware has a nonstandard LZMA?

from binwalk.

It is standard lzma. Bin walk extracts it fine for me. What p7zip and are Tou running? Try:

p7zip -d 8814.7z

from binwalk.

I am on Fedora 19 x64... The p7zip package available is 'p7zip', but it installs a 7z (and 7za), not a 'p7zip' command. I guess it aren't different, but... just for sure, you are on Win or Linux?

Here is the output of my 'p7zip' version:

7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=pt_BR.utf8,Utf16=on,HugeFiles=on,2 CPUs)

Usage: 7z [...] <archive_name> [<file_names>...]
[@listfiles...]

from binwalk.

There is no "-d" option.

from binwalk.

Output of 7z for extracting 8814.7z:

[luzemario@acer _EdiEngEW7209APg_1.29.bin.extracted]$ 7z e 8814.7z

7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=pt_BR.utf8,Utf16=on,HugeFiles=on,2 CPUs)

Processing archive: 8814.7z

Extracting 8814 Data Error

Sub items Errors: 1

Listing archive:

[luzemario@acer _EdiEngEW7209APg_1.29.bin.extracted]$ 7z l 8814.7z

7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18
p7zip Version 9.20 (locale=pt_BR.utf8,Utf16=on,HugeFiles=on,2 CPUs)

Listing archive: 8814.7z

Path = 8814.7z
Type = lzma

Date Time Attr Size Compressed Name

                .....    268435456      1320970  8814

                         268435456      1320970  1 files, 0 folders

from binwalk.

p7zip is just a wrapper around 7z/7zr. I can extract the 8814.7z file with all three.

Looking at the output from your '7z l' command, I think your file is corrupted or was not properly extracted; specifically, your size and compressed fields do not match what I have for the 8814.7z file:

$ 7z l 8814.7z 

7-Zip 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,1 CPU)

Listing archive: 8814.7z

--
Path = 8814.7z
Type = lzma

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
                    .....      6893568      1320962  8814
------------------- ----- ------------ ------------  ------------------------
                               6893568      1320962  1 files, 0 folders

For reference, here are the relevant files that I am working with:

File                          Size       MD5
---------------------------------------------------------------------------
EdiEngEW7209APg_1.29.bin      1355798    d6b1cc9f54057b3c535c5789fd47b822
8814.7z                       1320962    84c6511e1032d68dc993d1d843bc7610

from binwalk.

Hi devttys0,

Here are the md5sums of both files I have:

<tableFileSizeMD5

So, the original file is intact, but the extracted is not. I am using built-in version for Fedora 19 x64. I will try the version from GitHub, as the version packaged by Fedora can be defective.

from binwalk.

No luck with svn compiled version. Binwalk still puts 8 more bytes inside file. I couldn't figure out where they are. But I suspect it stay at the beginning of file.

from binwalk.

Can you provide a copy of your extracted 8814.7z that contains the extra bytes? If you manually dd the LZMA file from the firmware are you able to decompress it?

from binwalk.

Hi dev,

My file is ok. I could extract 8814.7z by using

So there is something wrong with binwalk's extract process. Maybe a bug on my Core2 Duo processor?

from binwalk.

Here is the extracted (wrong) file:

https://drive.google.com/file/d/0ByK_hMeEuyflT0xLMVFMU1EzTlk/edit?usp=sharing

from binwalk.

I found the following extra bytes at offset 0004 to 000B:

I have not seen no other differences in the file.

from binwalk.

It's a distro issue; specifically, the Fedora package for p7zip installs '7z' and '7za', while Debian installs '7z' and '7zr'. Binwalk expects 7zr; since this didn't exist on your system, the extraction failed and binwalk's lzmamod plugin thought the fialure was due to a possibly modified LZMA header (commonly found in modem firmware); it patched the header (which is where your 8 extra bytes came from) and tried to extract again (which of course still failed, since 7zr still didn't exist).

I updated the extraction rules to use '7z' instead of '7zr' since that appears to be more standard across distros. You should also be able to specify the --carve option along with -e to tell binwalk not to execute extraction utilities, in which case you should just get the original (un-modified) LZMA file that you can then extract manually.

from binwalk.

Cool! I am happy this little "bug" has been catched!

Thank you for your kindly support. I like binwalk too much and like it to be THE tool for researching and studying. it is not perfect, but you will make it very good thanks to your patience.

from binwalk.

[Feedback] I checked out revision 374. I am using Fedora 19 x64. It was compiled as expected, except for pyqtgraph lib. I coudn't find a package for it. The LD_LIBRARY_PATH environment trick was needed.

Running

binwalk -e --carve


Did the trick. The file was extracted correctly and I was able to decompress it manually and use binwalk again to analyse it more deeply. But using only the '-e' option still gives a "patched" LZMA. Using '-M' option in this case failed.

from binwalk.

The latest commit hash is 6747bc6; is this what you're using?

from binwalk.

I am using only "svn checkout" to sync. Do you suggest using "git clone" or so? My knowledge to collaborative development tools is very limited. Svn says it generated a local working copy for revision 374. It is all I know.

from binwalk.

Since github supports checkouts via svn that should be OK; I'm just not sure how the svn revision numbers correlate to the git commit hashes. I'm just trying to verify that you do have the latest check-in, as you should no longer be getting the patched LZMA file.

I've added some additional verbosity to the extractor output when -v is specified; if you update your repository and run with the -v flag you should see output from the 7z utility.

from binwalk.

Using "svn update binwalk" bring to me 'revision 375'. An update was made:

After configure/make/make install process, it works like a charm!

from binwalk.