6

You can use FunctionManager to get all the functions in the current program and then, from it iterate and get signatures of each. fm = currentProgram.getFunctionManager() functions = fm.getFunctions(True) for f in functions: print(f.getSignature().getPrototypeString()) The output: Signatures.py> Running... char * strcpy(char * __dest, char * __src) ...


5

Well thanks to @IgorSkochinsky's suggestion, I found a disassembler for the Blackfin architecture in the pf0camino/cross-bfin-elf Docker image. Being in Docker meant it was easy to run and I didn't have to mess around with installing cross compilers myself. I was then able to disassemble the image with this command: bfin-elf-objdump -D -b binary -mbfin ...


5

The firmware is incorrectly dumped. In your file all occurrences of the byte 0A have been replaced with 0D 0A. Looks like a line ending issue. May be the tool which you have used to dump the firmware have prepended a 0D to each 0A. After replacing all instances of 0D 0A with 0A, it has an exact size of 256 KiB (262144 bytes) as it should be. Previously it ...


5

So, I found out the reason. By default when the ghidra asks for options when we load the binary, Decompiler Parameter ID option is disabled. Once you enable it, you will have the function parameters correctly. It will take longer time to make the analysis once this option is enabled.


5

There is no problem, the comment is simply informational. The TMS320C6 is a DSP and like many DSPs the architecture is optimized for fast data processing. In particular, it has a very deep pipeline and the branches have not one or two, but up to five delay slots. You can see that after the B .S2X A3 instruction there are five other instructions before the ...


4

You can obtain the list of all defined basic blocks using BasicBlockModel Example from ghidra.program.model.block import BasicBlockModel from ghidra.util.task import TaskMonitor bbm = BasicBlockModel(currentProgram) blocks = bbm.getCodeBlocks(TaskMonitor.DUMMY) block = blocks.next() while block: print "Label: {}".format(block.name) print "Min ...


3

You noted that Decompiler Parameter ID fixes the discrepancy, but I suspect that the relevant logic is the one behind the context menu action Commit Params/Return. The Ghidra Advanced Class slides state: Decompiler Parameter ID The Decompiler Parameter ID Analyzer (Analysis → One Shot → Decompiler Parameter ID) uses the decompiler and an ...


3

@0xec's answer is great. This script will help you get blocks function wise. from ghidra.program.model.block import BasicBlockModel blockiterator = BasicBlockModel(currentProgram).getCodeBlocks(monitor) # dictionary contains function wise basic block information functions = {} def add_block(function, block): if function not in functions: ...


3

0xec has answered you but if you are interested in functions you can iterate as below #TODO Lists Functions in a given program #@author blabb #@category _NEW_ funcs = currentProgram.getFunctionManager().getFunctions(True) f1 = funcs.next() print("Function Name",f1.getName()) print("Function Body" , f1.getBody()) print("Function Entry" , f1.getEntryPoint()...


3

It does appear to be MIPS 32-bit little-endian machine code. First, the file was converted from .hex to binary via $ objcopy --input-target=ihex --output-target=binary FORD_P5_STEER_RevA_v1.2.0.hex FORD_P5_STEER_RevA_v1.2.0.bin After looking at a binwalk entropy plot and a hex dump, I sliced out the first 0x00021330 bytes, because nearly everything after ...


3

I was working on this this weekend. Turns out it's pretty straight-forward. Simple list of contiguous files. Just copies files when they change, and marks the allocation-table entries as dead, for later collection. The following is incomplete, but it should let you tweak and special-case your way through a specific MFS partition. I've tried to document ...


3

If the company has released new firmware, you can just download that and compare those files without needing to dump anything. Your first step would have to be to disassemble both units and look at the circuitry inside, and compare model numbers on all the larger chips. You might find they are using different chips, which is why the firmware is different. ...


2

came across these keys and sharing Known AES keys: zxhn h118n ert5 - 'MIK@0STzKpB%qJZe' zxhn h118n V2.1.3_ROSCNT? - 'MIK@0STzKpB%qJZf' zxhn h168n v3 - '402c38de39bed665' zxhn h298n hv17_fv116_mts?t1 - 'Wj' (due to bug, orig. is 'Wj%2$CjM') zxhn h298a hw1.1.20_fw1.1.20_ros_t1? - 'm8@96&...


2

Don’t know what swap is about, but spare area, or OOB area is an additional area at the end of each page storing metadata such as: bad block markers ECC (error checking and correcting) code custom data which may be used by the system It seems the spare option enables dumping it which is why the dump is slightly bigger. For more info about NAND flash ...


2

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


2

Some Routers use a NVRAM for storing settings. That would give you exactly this result: No writable partitions but some binary is taking care of reading and writing to that NVRAM (wherever that might be). Check if there's anything called nvread, nvconf or something like that. If that's not successful you can always try to find a binary that uses a ...


2

To add to Igor's excellent reply. Unfortunately IDA Pro up until now does not handle TMS320C6 properly. TI DSP common pattern for the calls is to load up call address into 32 bit register and do the register branching (it has direct branching with immediate offsets as well but compiler seems to use it only for local branches within the function). IDA seems ...


2

This tutorial (NB: in Italian) covers recovering ATA passwords from the drive itself. Not for the faint of heart, and drive controller firmware dependent. You might also post on forum.hddguru.com as they seem like SMEs. Here's another tutorial covering different tools and techniques. There's plenty of additional information about Tandberg RDX here starting ...


1

binwalk easily finds the beginning of the lzma file but not the end. It is necessary to modify the files extracted with a Hexadecimal editor. I don't have the same version as you but for TD-W8961ND_V3_140305.bin: The first extracted file (in 0x14C33) contains from the offset 0x41cf many 0x00, all the following bytes must be deleted. In my version the file ...


1

I figured it out: You reset the checksum to ZEROs then you calculate CRC32 of the u boot header (from first byte to 64th byte) AA XX YY ZZ 00 00 00 00 .... the first 4 bytes are for magic word; the next 4 bytes are the checksum.


1

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


1

It is indeed valid MIPS litte-endian code: seg000:1D0121F0 A8 FF BD 27 addiu $sp, -0x58 seg000:1D0121F4 04 00 A1 AF sw $at, 0x58+var_54($sp) seg000:1D0121F8 08 00 A2 AF sw $v0, 0x58+var_50($sp) seg000:1D0121FC 0C 00 A3 AF sw $v1, 0x58+var_4C($sp) seg000:1D012200 10 00 A4 AF ...


1

Assuming this is a firmware file, a good first step would be to identify where execution starts. You could do this by: finding the type of processor / microcontroller / system-on-chip and checking for the reset vector (try searching for product approvals, e.g. from the FCC, which might contain interior images). scanning the file for known byte sequences ...


1

If you can't find documentation indicating the checksum algorithm, you could try reversing the software that reads or writes the checksum. I'm not familiar with GAL, but from the site you linked, there are references to programming software [1] which should be writing the checksum or verifying it before programming the chip. [1] http://www.armory.com/~...


1

The solution that I found that suffices for my current issue of debugging the EXT4 parser is is the following Ghidra Script, saved as ImportFS.java: import ghidra.app.script.GhidraScript; import ghidra.formats.gfilesystem.FSRL; import ghidra.formats.gfilesystem.FileSystemRef; import ghidra.formats.gfilesystem.FileSystemService; import java.io.File; public ...


1

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.


1

Well, I am not (yet) an expert, but since I work in embedded software now I'd guess that this is your problem: Old: MXC MTD nand Driver 2.5 NAND device: Manufacturer ID: 0x20, Chip ID: 0xaa (ST Micro NAND 256MiB 1,8V 8-bit) Searching for RedBoot partition table in NAND 256MiB 1,8V 8-bit at offset 0xff60000 No RedBoot partition table detected in NAND 256MiB ...


1

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


1

I have not encountered FCRS but EFFS is the legacy Flash Filesystem partition, used to store configuration and runtime ME data. The only known tool that can parse it (besides ME firmware itself) is Intel’s Flash Image Tool (FIT) for the corresponding firmware version. However, the format is likely very similar to that of the newer MFS in ME 11 and later, ...


1

I've found this project https://github.com/lorf/csr-spi-ftdi, along with info: BlueCore 2 chips (such as BC212015) are not supported in BlueSuite 2.4 and above what means they are intentionally try to enforce developers to use more high level tools . Above github tool should help you identify exact chip without disassembling physical device. I've checked ...


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