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 ...
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 ...
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, ...
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 ...
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 ...
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:
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 ...
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, ...
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.
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
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 ...
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 ...
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 ...
It seems very likely that this chip is indeed MIPS, so any MIPS disassembler should work. Remember to try both little-endian and big-endian variants. For finding the entrypoint, see here: Reverse Engineering MIPS Bootloader
Note that it may be possible that the firmware is packed or encrypted (check binwalk's entropy analysis); in that case reading it ...
The password seems to be generated dynamically from /etc/profile
# generate login files
echo "supervisor:3Gnc.CJE1790M:0:0:Administrator:/:/bin/sh" > /var/passwd
echo "root::0:root,supervisor,support,user" > /var/group
You would need to try to crack the DES hash with a program like John the Ripper or replace it with another known ...
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....
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 ...
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 ...
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 ...
It's hard to say without the image but at a guess, maybe you did not properly strip the OOB bytes from the dump, or the block size is wrong.
Instead of mounting it maybe try just extracting the files from the image, e.g. using this script.
To clarify this thread:
C-Sky CPU's are a 16/32 bit variable length instruction set ISA in SoC & PoC packages, that appear to be MIPS-like, that can be switched to execute code in big or little endian. The CK610M is a v1 ISA, which has the MMU, so it is able to run Linux, which contains support as of v4.19.
There are currently (since October 2018) a $...
It seems they also added compression there.
This utility seems to decode it: https://www.nirsoft.net/utils/router_password_recovery.html
Also, I'd just written my own decoder and encoder for it:
openssl enc -d -des-ecb -K 478DA50BF9E3D2CF -nopad -in conf.bin -out conf.lztp