31

General Prerequisites 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 ...


21

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 ...


20

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 ...


19

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 ...


15

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 ...


14

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-...


14

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 ...


11

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 ...


9

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:


8

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 ...


8

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. ...


8

Finding: NGA_FW_CURRENT.BIN is a compressed Videx microchip firmware image file. Preliminary Remarks 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://70.60.240.178:8443/CyberAuditWeb/services/nga/download/ under ...


8

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, ...


8

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 _reset: cseg:FFF0 cseg:FFF0 FA ...


7

Extracting the content of a hardware chip is known as "snarf"ing. (That term may help with your Google searches.) To snarf the contents of a chip, you need a ROM reader/programmer, such as one of the devices from http://www.needhams.com/programmers.htm


7

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 ...


7

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 ...


7

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 ...


7

From brief analysis of the file it looks that the Insta360 One camera is based on or variant of the Ambarella A9 SoC. So lets assume for the moment that we are dealing with Ambarella camera itself and its firmware as it's pretty hard IMO to develop your own HD camera HW and SW stack from scratch. There are some substantial evidence for that if one check ...


7

Emulating a complete physical device is always going to be more of an experimental exercise. In this regard you can use firmadyne which aims to emulate Linux based embedded firmware for MIPS and ARM devices. It's based on the venerable QEMU project. There's also firmware analysis toolkit which is a wrapper around firmadyne allowing you to automate some of ...


7

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. Specifically: ...


6

I was able to get that firmware to a shell by doing the following: Unpacking the squashfs image Create a filesystem image formatted to ext2 and copying the unpacked squashfs contents into that, and using that as -hda Running without -initrd ... and appending init=/bin/sh to the kernel command line Although you are not fully emulating the WR740N because ...


6

It's important to know that not all ZyNOS images are created equal, and the exact steps that worked for piotrbania (as referenced in your question) will likely not work for you. First, ZyNOS is a Real Time Operating System, and you can think of the entire OS as just one big kernel (i.e., there is no user space or file systems or anything easy to deal with ...


6

Usually you only get addresses and raw bytes, but some tools/compilers may use custom record types or add extra information. For example, Tasking VX toolchain for Tricore uses an S0 record for identification: S0-record 'S' '0' <length_byte> <2 bytes 0> <comment> <checksum_byte> A linker generated S-record file starts with a ...


6

The way I did it on the Kindle was to load the flash partitions into memory and then using memory dump commands to dump them in hex format (and then some Python script to convert hex back to binary). It was kinda slow but did achieve the goal. Your U-Boot does not seem to have the bbm command but fload - load binary file from a filesystem image for system ...


6

I use sf read and it works pretty good. It can be called as follows sf read [addr] [offset] [len] So for your case, reading romfs would look like this: sf probe 0; sf read 0x82000000 0x40000 0x370000 Then you can transfer the file to tftp server: tftp 0x82000000 romfs.cramfs 0x370000 You can also use sf to write to the SPI flash (more info can be ...


6

The SquashFS image is version 3.0 with LZMA compression; LZMA compression was not officially added to SquashFS until version 4.0, so standard SquashFS tools won't recognize it. However, sasquatch extracts it just fine for me. In fact, if you have sasquatch installed, the latest version of binwalk will use it to auto-extract the file system if you run ...


6

I will answer not what you asked in the title but what you actually need. There's around 99% probability it's a 8051 derivative. I don't know a single Chinese USB controller which does not use one. Although I haven't seen them all, of course. I downloaded a random MPTOOL for this controller from flashboot.ru and it had some binaries. They do look like 8051 ...


6

There is no LIF file in the D-Link binary file containing the firmware image. file returns a false positive. Since there is no LIF file present, tools in the lifutils package will fail or produce erroneous results Do not trust tools implicitly. Tools can return false positives if they rely on magic numbers, particular byte sequences and the like. When ...


6

I am a developer of the Rockbox open-source project. We figured out the encryption of the firmware upgrade a look time ago by essentially doing the same thing (dumping the chip). upgtool can extract the firmware from UPG tools, those can be extracted from the firmware upgrade installer using cabextract and looking at the file Data/Device/NW_WM_FW.UPG It ...


Only top voted, non community-wiki answers of a minimum length are eligible