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 ...
The markings look like an Atmel part (it starts with "AT", which is common for Atmel parts). Given the size of the chip and context which you provided, I figured it was probably a serial EEPROM. Looking through Atmel's serial EEPROM datahsheets, your mystery chip is almost certainly an Atmel AT25128B-SSHL SPI EEPROM, which matches your chip's product ...
Since version 0.50, binwalk has a -e option to extract files. Unfortunately, the manual doesn't tell you this, but if you invoke binwalk -version, it tells you
-e, --extract=[file] Automatically extract known file types. Load rules from file, if specified.
Of course, you can use dd as well. For example, if you want the executable at 68264, ...
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 ...
For example you have this directory structure on your server, which resolves to the following accessible URLs (asuming your website is www.example.com):
|-- /index.html -> www.example.com/...
But surely something must know where all the devices live in memory, because something is responsible for routing memory reads/writes to the correct device.
In embedded devices there's nothing like PCI (well, it may be present but it's just one of the many HW blocks). So you can't just scan all possibilities to discover the existing devices. The code must ...
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:
To create a full duplicate, able to generate valid transmission packets you'll need the following information:
Button press mapping
32 bit of KeeLoq encrypted data
See attached Figure 1-2, from the datasheet, near "Transmitted information" at the bottom right:
Using those three pieces of information you can theoretically create your own ...
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 ...
You can use the -D option to dd out sections based on signature.
For example, to extract out the ELF parts, do:
binwalk -D "elf 32-bit lsb shared object":.so image.bin
Note the lowercase signature string.
You can specify more than one instance of -D.
See the binwalk wiki for more details:
Frying your board:
Just touching one single pin of a chip, or connecting it to ground over a reasonably high-resistance voltmeter, will generally not fry a board. However, there are ways to fry a board:
static electricity. Every instruction to insert a PCI card in your computer comes with a warning about that, and there is a reason. However, i found ...
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 ...
I had to add just a few things to have a clear mind (although the other answer is really good and got my up-vote already).
Single pin touching with a probe can blow up your HW.
And I do not mean the obvious static charge or what so ever from the common reasons. With nowadays chips some pins runs on very specific voltage ranges and even a high impedance ...
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.
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:
'S' '0' <length_byte> <2 bytes 0> <comment> <checksum_byte>
A linker generated S-record file starts with a ...
Any such functionality is dependent on the player or viewer used. I know of no image formats that require any kind of interaction from the viewer, but some video formats do (or, rather, did) use it.
In addition to Quicktime mentioned by 0xea, the Windows Media/ASF format allows embedding of script commands, and one of them is opening an URL:
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, ...
I couldn't get a comment to format right .. so forgive this being a new reply.
Here is the header format:
0x00 : 4 unknown, probably 2 16-byte words for a version or file ID
0x04 : 4 size of the data block containing file data
0x08 : 4 unknown
0x0C : 4 offset to the data ...
I managed to solve problem.
First file in directory is ZSP.bin. It doesn't matter if offset of this file is 16 or 32 bit because in both cases is 0. As I know where directory ends and first file after directory should be ZSP.bin.
Below there is last two lines of last directory entry and first line of which I suspected should be ZSP.bin.
00 00 00 00 00 00 ...
What you ask for would be very near remote code execution, which is usually a security no-no.
Tho there are some formats that allow similar things.
As far as i remember MOV file format allows you to embed urls or aliases in it for alternative versions of the movie. I think it's usually used for streaming purposes, so that a player can request a higher or ...
Okay, so far your question is a bit meager on the informational side, but it's intriguing. Let me start an attempt to answer it. I'll not be able to answer it, lacking the device in question.
Here's what I would do.
Pose as a WiFi access point (AP). Most WiFi cards will allow you to do this, if the software side allows for it as well. If the ...
There is an open source project: openpst, which reimplements most functionality of the qpst tool.
Some of the protocols used are:
diag - used to read nv memory, and switch to dload mode using kDiagDload.
sahara - used by the primary bootloader in newer qualcomm chipsets
dload, used by bootroms, and older chipsets.
streaming dload - used by the flash loader....
The file indeed looks encrypted or obfuscated. It might be possible to figure it out using some cryptoanalysis (that 34 48 83 sequence at the end doesn't look random), but you'll probably be better off looking into finding UART or JTAG pins, or maybe a running telnet server or another service which may give you a way in.
EDIT: At the download page for the ...
Some things you will inevitably have to know at some degree to be able to reverse engineer Game Consoles:
Learn a lower level language such as C or C++. Most, if not all, Console games, modern and old, use these two languages for the bulk of the game (AKA, the Engine). This is important for my next point, which is:
Learn about the architecture of game ...
After some searching, it seems that the boot process on the iMX233 is fairly non-standard. By default it looks for a "Boot Control Block" (BCB) in the last block of the SD card.
Examining the original SD card, find the last block using fdisk -l:
Disk /dev/mmcblk0: 1996 MB, 1996488704 bytes
4 heads, 16 sectors/track, 60928 cylinders, total 3899392 sectors
Micro SD cards have a card identification register (CID) that can be read from the card. The CID contains, among other things, the product serial number and manufacturing date, which are different between cards.
Your firmware might be specific to a certain CID as a form of copy protection.
This blog post is about reading the CID on a iMX233 running Linux ...
Your code has a function at 0x400960 that looks like a main function, and, omitting all initialization (everything gets initialized to 0) and error checking, looks like this:
The bootloader is in the flash, so you have to dump it first by using:
dd if=/dev/mtd0 of=/tmp/mtd0
nandump -of /tmp/mtd0 /dev/mtd0
After it you have to copy to an SD card, USB device or send via netcat (nc) to a socket. Of course you can do it in one step also.
You can send files via netcat with 2 easy steps.
Start netcat in your PC in ...