When analyzing binaries, it is important to be able to put what is observed into context. For example, how can CPU instructions be differentiated from data in a binary with a non-standard format? This requires some background knowledge of computer systems in general. I would argue that before any attempt at reverse engineering firmware ...
I've been dissecting the firmware for another type of embedded device for a while and thought I'd see if I could find anything out. After a few hours I figured it out! There is a hard way and an easy way that I found only after digging the hard way. This is a long post, but I hope it will help others in similar ventures.
A little Googling and I found ...
As you may suspect, it very much depends on the hardware. In general, you are correct, JTAG and/or UARTs can be often be used to get a copy of the firmware (downloading a firmware update from the vendor is usually the easiest way of course, but I'm assuming that is not what you mean).
JTAG implementations typically allow you to read/write memory, and flash ...
It's a false positive. There is no LZMA-compressed data in the binary.
Running binwalk without any arguments other than the firmware binary file name is equivalent to running it with the -B or --signature arguments, which directs binwalk to perform a signature scan. Since a signature scan is essentially search for particular byte sequences, false positives ...
SIMs card are a type of Universal Integrated Circuit Card (UICC).
how exactly do they work
According to Karsten Nohl's presentation "Mobile Network Attack Evolution", SIM cards contain an embedded real-time operating system, a filesystem and a Java VM:
Here is the technical specification for UICCs, which describes exactly how they work:
ETSI TS 102 ...
I downloaded the archive you referenced and the first thing I noticed was that the firmware files are very heavy in the 0x80 - 0xff range. Inverting each byte resulted in a much nicer byte distribution and looked like it had some structure but still not quite right. I assume that since they went as far as inverting the bytes, they might have done some bit-...
Hypothesis: the file is encrypted
1. Absence of Compression Signatures
The relevant compression formats that Binwalk detects are as follows: bzip2, lzop, lzip, lrzip, LZO, 7z, gzip, rzip, LZMA, zlib, and LZ4. Since running Binwalk against H201LV2.0_Cur_config.bin returns no results even though Binwalk normally will recognize any of these compression ...
2020-08: For more up-to-date information, see the answer below discussing ISAdetect and Centrifuge
The tools themselves are less important than the approach to the analysis. Instead of looking for better or more tools, seek to develop a sound methodology to employ when analyzing binaries.
I'm an amateur (a student) and can't claim to know much, having ...
I am not aware of a currently active generic "firmware reversing" forum.
A few years ago there was a pretty ambitious attempt with lostscrews.com but unfortunately it languished due to lack of attention, got overwhelmed with spam and eventually the domain has expired. I think the guys behind the /dev/ttyS0 blog also tried opening a forum a couple months ago ...
The LZMA compression identified by binwalk is correct (or at least most of them are - I didn't check them all). If you actually extract and decompress the LZMA files, you'll find that the first one (at offset 0x30) contains the device's code (a MIPS RTOS of some sort) and the rest appear to be the HTML files for the web interface.
The Garmin GCD file format is documented here, with some additional information here and here.
Furthermore, it looks like somebody already wrote a tool (mirrored here) for handling and manipulating Garmin GCD files:
So, I have figured it out myself in the end. I'll try to describe the process.
First, a bit of background on NAND: it is organized in pages which are grouped into blocks. You can read or write a single page at a time but erasing (which turns all bits to 1s (so bytes to FFs)) can be only done one block at a time (writing can only change bits from 1 to 0 but ...
Your best bet is Hachoir-Subfile. You can pass a file stream to Hachior-Subfile, it will search for all known embedded files and display the location. Some known formats it will calculate the size of the file. This makes it easy to carve out the files using dd. A helpful description of Hachoir-Subfile was left by one of the developers a couple weeks back in ...
Expanding on my comment:
The Freeware IDA Pro doesn't support MIPS, so you won't be able to use it. If you can't use the paid versions of IDA, there are free alternatives.
As an example, using radare2 as an example, on the Debian MIPS binutils port:
$ file bin/objdump
bin/objdump: ELF 32-bit MSB executable, MIPS, MIPS-II version 1 (SYSV),
Ubicom32 is a proprietary architecture, not at all related to ARM or MIPS (other than the fact that it is RISC...well, kind of). IIRC it was designed specifically for networking and multimedia streaming applications, so it's a bit of an odd architecture. It was developed by Ubicom, but they were bought by Qualcomm.
There are Linux tool chains out there for ...
As the names in /proc/mtd suggest, mtd0 is probably not a file system, but more likely is the boot loader. Likewise, the name of mtd3 suggests that it contains the saved configuration settings (admin password, wireless settings etc).
The "flags" and "main" names for mtd1 and mtd2 respectively are a bit ambiguous, but I would expect, due to the name and the ...
This depends on a multitude oft things, especially your location, and you should really ask a lawyer. If Nintendo sues you, "a random guy in the internet said it was ok" won't help you anything; your lawyer can at least help you in court and should have insurance to cover up if things really go wrong.
There are limits to what an EULA can forbid you to do. ...
Finding: NGA_FW_CURRENT.BIN is a compressed Videx microchip firmware image file.
There is conflicting background information given in the comments about the file alleged to be firmware in the question.
A gzip compressed data file called authorizer.tar.gz located at https://188.8.131.52:8443/CyberAuditWeb/services/nga/download/ under ...
The encryption for recent ZTE routers' config.bin is AES ECB (Electronic Code Book). The key is stored in the open in /bin/cspd next to string /cfg/db_backup_cfg.xml. The function responsible is CspDBInitPdtInterface, last snprintf call. The key is zero padded if short of 128 bits.
The key very much might be unique to ISP: yours H201L V2 is Renjx%2$CjM, ...
The files in the update are not ARM but classic 16-bit x86 code. For example, loading bios.bin at F000:0000 and starting disassembly from F000:FFF0 (standard x86 entrypoint) produces nice code:
cseg:FFF0 FA ...
The CramFS image is a false positive; I doubt there would be over 1 billion files in a 5MB firmware image.
It looks like your binwalk signatures are a bit old; here is the output from mine (running the latest from the trunk):
DECIMAL HEX DESCRIPTION
Correct me if I'm wrong, but since SREC is an ASCII representation of the binary data, wouldn't the corresponding binary file also "leak" sections of data that are padded with 0x00/0xFF?
With that said, yes, I think that in some cases SREC could expose useful information about the firmware that you wouldn't otherwise get with a binary image, assuming the ...
The output from the file utility, as you've probably guessed, is a false positive. The beginning of the firmware.bin file contains what looks to be a basic header (note the "SIG" string near the beginning of the file), and a bunch of MIPS executable code, which is likely the bootloader:
DECIMAL HEX DESCRIPTION
You can try to use binwalk. It can be used in various ways:
Embedded file identification and extraction
Executable code identification
Entropy analysis and graphing (useful for compression and encryption identification)
"Smart" strings analysis
You could try to open your file with 7zip, since it supports a shitload of compression formats.
And also worth ...
What I usually do:
Load the binary at a not too small base address, like 0x10000000.
Identify as many functions and strings as possible.
you may get lucky starting with only the strings, that is usually less work.
create a list of all constant values, immediates, and dword (assuming a 32 bit binary) values.
now sort the list of function and string ...
Now I don't have the time to help you all the way, but I believe I can get you started. Let's think like some company trying to obfuscate something from the layperson, right? The first choice is usually bitwise xor.
We know the offsets of the bits and pieces already, thanks to jvs3516cs-7601-ver.bin.
Now looking at the jvs3516cs-7601.bin in a hex editor ...
When performing firmware analysis, examination of an entropy plot should always be the first step, since this is the fastest way of determining whether the file is compressed or encrypted.
In this case, an entropy plot and the byte frequency distribution of the file indicate that it is encrypted. Hence, no signatures and nonsense strings.
0x73687371 is apparently a magic value used to indicate LZMA compression by some vendors.
I can't test it since I don't have the image but here's a blog post with some description and source code links which is supposed to handle it:
EDIT: after some struggle with the download site I was able to get the decrypted shsq ...
* webcomp -- Compile web pages into C source
* Copyright (c) GoAhead Software Inc., 1995-2000. All Rights Reserved.
Webcomp, or 'web compiler', is a very simple tool written by GoAhead Software during the period of 1995-2000. It 'compiles' web pages into a single binary blob, adding an index of files in the blob to the httpd ...