Typically when cross-debugging a remote target with GDB, you do not try to preserve debug symbols in files loaded onto the target, but rather for reasons of space use only stripped binaries there.
Instead, you keep the versions with symbols intact (and potentially also associated sources) on your PC, and point the debugger at those. If your files with ...
Most RTOS code is usually a single monolithic binary and is not split into separate binaries like a high-level OS. Usually there is some startup code, some library routines and user-provided code in forms of tasks which are nothing more than simple functions performing the necessary work in a simple infinite loop. The “main function” called by the RTOS ...
You need to load the last 64KB of the ROM at linear address 0xF0000 (0xF000:0000) and create there a 16-bit segment with the base 0xF000. Then all your “low addresses” will line up (they point into the current segment with CS=0xF000).
In case you get references to E000, load the second 64KB chunk and so on.
Once you get to 32-bit code, it will likely be ...
It seems you have an SPI NAND chip and not a more common SPI NOR on which flashrom specializes. The support for SPI NAND in flashrom is pretty new, covers only Toshiba and Micron for now and is not even merged in the master branch yet, so it's very unlikely your build even has it. You can try to either add support for GigaDevice on your own (e.g. from the ...
It is just addition/subtraction (mod 256).
# These key bytes are the two's complement of the hex sequence mentioned in the question.
# The string appears twice in the decrypted blob, which makes me think it's what is used.
key = [ord(n) for n in "llp_owon"]
with open("AFG1022_V1.2.4.tfb", "rb") as infile:
data = infile.read()
Yes the file is encrypted, it is a simple XOR cipher with a key length of 0x800 bytes.
Python script for getting decrypted firmware:
FILENAME = "HW718V40_20171008.firmware"
def xor_cipher(data, key):
from itertools import cycle
if (sys.version_info > (3, 0)):
return bytes(a ^ b for a, b in zip(data, ...
It is a difficult question because there is no general answer. The layout of the FW defined by the OEM and the ECU supplier together during design phase and it might be different between ECUs and OEMs.
Every ECUs has its own firmware(s) and constant parameter sets inside the Flash memory/ROM/Eeprom/other NVMs where the OEM and the supplier is able tune the ...
Is there anything I can do to open the NEC binary dump in Ghidra?
Yes. If Ghidra does not currently support 76F0219F1 NEC processor architecture, Ghidra can be extended using SLEIGH. Here are some examples of how to do this:
Implementing a New CPU Architecture for Ghidra
new 6502 CPU description
Writing a wasm loader for Ghidra. Part 1: Problem statement ...
The firmware for these devices is typically not directly connected to the computer, and the FPGA reads the data itself upon startup through a dedicated connection not accessible to anything else. There would be no need to connect the memory chips to the computer, as it would add unnecessary complexity to the device.
The device may implement functions that ...
There's a few other options can help you narrow down the specific architecture / core / SoC.
Identify which combinations of ARM/THUMB16/THUMB32 instructions it contains.
Look at disassembly to identify the offsets of key memory regions (code, data, flash etc)
Similarly, SoCs tend to have memory mapped peripherals. Identifying what's being accessed here ...
There can be several reasons for that:
Sometimes you want parts of it read/write which squashfs doesn't support. Other parts should always be read-only, so there squashfs would be a great fit.
Some vendors allow OEM-partitions that contain changes specific to that OEM, while that doesn't necessarily have to be a different filesystem it's often a filesystem ...
Your disassembly doesn't show enough memory to know if the target is empty memory, but the x86 segmentation model means that the jump target for 0xF000:E205 is 0xFE205 (i.e. the (0xF000 << 4) + the 0xE205). IDA doesn't show that in an obvious way by default.
The boot log seems similar to the one from this page, so there's a high possibility this device is using an AllWinner SoC. You can try the tools from the linked repository.
Another option could be to dump the flash and analyze it.
I was looking for the same thing and I recently found www.rockbox.org, an open source firmware for audio players. Their idea is the owners would capable to customize that firmware and make it more functional in some cases. Always is good enough to learn something and in the way have some fun too...
No, unfortunately not. Look at this question, among the frequently asked questions.
According to that:
X86 16/32/64, ARM/AARCH64, PowerPC 32/64/VLE, MIPS 16/32/64/micro,
68xxx, Java / DEX bytecode, PA-RISC, PIC 12/16/17/18/24, Sparc 32/64,
CR16C, Z80, 6502, 8051, MSP430, AVR8, AVR32 and the variants of these
are currently supported.
Bosch have been developing firmware for Engine Controllers since Edc14 (as far as I know). I very much doubt their SDKs would ever be publicly available.
By the way I am also working on disassembling EDC17 controllers, so maybe there is a way to cooperate (however I don't know how we can establish contact through stackexchange)?
Do these extra bytes appear at regular intervals? If so, they could be the spare or OOB(out of band) bytes which are present in most NAND chips for error checking or housekeeping (bad block management etc.) in most cases you can discard them and analyze just the “useful” data. See my other answer for some background.
The binary is likely scrambled. At least the one for mine (Eleaf) is. Maybe there is a chance to read the unscrambled image out of the hardware using JTAG (if not disabled)
The Eleaf Controller is labled "M091" and is a 48 PIN but did not find any routed JTAG connection onboard.
A first step to find out what chip it is could be a check to which pins the ...