mumbel / ghidra Goto Github PK

This project forked from nationalsecurityagency/ghidra

Ghidra is a software reverse engineering (SRE) framework

License: Apache License 2.0

Java 85.22% C 1.61% HTML 4.42% CSS 0.02% Shell 0.34% Python 0.99% Haskell 0.01% Makefile 0.01% C++ 6.91% Yacc 0.11% Lex 0.02% XSLT 0.01% GAP 0.09% Pawn 0.01% Batchfile 0.02% Assembly 0.07% TeX 0.05% Xtend 0.10% JavaScript 0.01% GDB 0.01%

ghidra's Introduction

Ghidra Software Reverse Engineering Framework

Ghidra is a software reverse engineering (SRE) framework created and maintained by the National Security Agency Research Directorate. This framework includes a suite of full-featured, high-end software analysis tools that enable users to analyze compiled code on a variety of platforms including Windows, macOS, and Linux. Capabilities include disassembly, assembly, decompilation, graphing, and scripting, along with hundreds of other features. Ghidra supports a wide variety of processor instruction sets and executable formats and can be run in both user-interactive and automated modes. Users may also develop their own Ghidra extension components and/or scripts using Java or Python.

In support of NSA's Cybersecurity mission, Ghidra was built to solve scaling and teaming problems on complex SRE efforts, and to provide a customizable and extensible SRE research platform. NSA has applied Ghidra SRE capabilities to a variety of problems that involve analyzing malicious code and generating deep insights for SRE analysts who seek a better understanding of potential vulnerabilities in networks and systems.

If you are a U.S. citizen interested in projects like this, to develop Ghidra and other cybersecurity tools for NSA to help protect our nation and its allies, consider applying for a career with us.

Security Warning

WARNING: There are known security vulnerabilities within certain versions of Ghidra. Before proceeding, please read through Ghidra's Security Advisories for a better understanding of how you might be impacted.

Install

To install an official pre-built multi-platform Ghidra release:

Install JDK 17 64-bit
Download a Ghidra release file
- NOTE: The official multi-platform release file is named ghidra_<version>_<release>_<date>.zip which can be found under the "Assets" drop-down. Downloading either of the files named "Source Code" is not correct for this step.
Extract the Ghidra release file
Launch Ghidra: ./ghidraRun (or ghidraRun.bat for Windows)

For additional information and troubleshooting tips about installing and running a Ghidra release, please refer to docs/InstallationGuide.html which can be found in your extracted Ghidra release directory.

Build

To create the latest development build for your platform from this source repository:

Install build tools:

JDK 17 64-bit
Gradle 7.3+
make, gcc, and g++ (Linux/macOS-only)
Microsoft Visual Studio 2017+ or Microsoft C++ Build Tools with the following components installed (Windows-only):
- MSVC
- Windows SDK
- C++ ATL

Download and extract the source:

Download from GitHub

unzip ghidra-master
cd ghidra-master

NOTE: Instead of downloading the compressed source, you may instead want to clone the GitHub repository: git clone https://github.com/NationalSecurityAgency/ghidra.git

Download additional build dependencies into source repository:

gradle -I gradle/support/fetchDependencies.gradle init

Create development build:

gradle buildGhidra

The compressed development build will be located at build/dist/.

For more detailed information on building Ghidra, please read the Developer Guide.

For issues building, please check the Known Issues section for possible solutions.

Develop

User Scripts and Extensions

Ghidra installations support users writing custom scripts and extensions via the GhidraDev plugin for Eclipse. The plugin and its corresponding instructions can be found within a Ghidra release at Extensions/Eclipse/GhidraDev/ or at this link.

NOTE: The GhidraDev plugin for Eclipse only supports developing against fully built Ghidra installations which can be downloaded from the Releases page.

Advanced Development

To develop the Ghidra tool itself, it is highly recommended to use Eclipse, which the Ghidra development process has been highly customized for.

Install build and development tools:

Follow the above build instructions so the build completes without errors
Install Eclipse IDE for Java Developers

Prepare the development environment:

gradle prepdev eclipse buildNatives

Import Ghidra projects into Eclipse:

File -> Import...
General | Existing Projects into Workspace
Select root directory to be your downloaded or cloned ghidra source repository
Check Search for nested projects
Click Finish

When Eclipse finishes building the projects, Ghidra can be launched and debugged with the provided Ghidra Eclipse run configuration.

For more detailed information on developing Ghidra, please read the Developer Guide.

Contribute

If you would like to contribute bug fixes, improvements, and new features back to Ghidra, please take a look at our Contributor Guide to see how you can participate in this open source project.

ghidra's People

Contributors

Stargazers

Watchers

Forkers

kaydoh

ghidra's Issues

RISC-V fixes

@hex , sorry for the ping like this. I just came across a paper titled "Analyzing and enhancing embedded software technologies on RISC-V64 using the Ghidra framework." Are you one in the same as the Supervisor? I could not find contact info for the authors, but was wondering if they had plans to report the bugs or submit a PR for any bugs of mine they found.

Use misa instead for the context

See privileged PDF for misa CSR

This is the exact register to use for the context register

size of "long" for risc64

The size of "long" in riscv64-fp.cspec appears wrong to me; should it be 8 bytes? sizeof(long)==8 in the Kendryte k210 toolchain. Because of this ghidra thinks uint64_t is 4 bytes.

Peripheral register definitions

Please add register definitions for supported MCUs.

For example, it can be converted from XML files (I found it here: https://github.com/Hailong89/K2SAR_EMS/tree/master/02_Build/01_Compile/01_Tasking_4p3/cpcp/include/sfr ) with this simplest script:

#!/usr/bin/python

import xml.etree.ElementTree as ET

# output
#       <!-- I2C Registers -->
#           <symbol name = "I2CIFG"  address = "RAM:0051"    entry = "false"/>

root = ET.parse('regtc1724.xml').getroot()

for group in root.iter('{http://www.tasking.com/schema/sfrfile/v1.0}group'):
    group_name = group.get('name')
    group_desc = group.get('description')
    if not group_desc: group_desc = ''

    # print group.tag, group.attrib, group_name
    print '\t\t<!-- %s %s -->' % (group_name, group_desc)

    for sfr in group.iter('{http://www.tasking.com/schema/sfrfile/v1.0}sfr'):
        # print sfr.tag, sfr.attrib
        name = sfr.get('name')
        addr = sfr.get('address')
        desc = sfr.get('description')

        print '\t\t\t<symbol name = "%s"\taddress = "%s"\tentry = "false"/>' % (name, addr)

NOP opcode

Please, add support for NOP instruction.
patch for tricore.sinc:

was:

# NOP (SR)
:nop  is op0007=0x0 & op0815=0x0 unimpl

# NOP (SYS)
:nop  is op0007=0xd & op0815=0x0 ; op1631=0x0 unimpl

corrected:

# NOP (SR)
:nop  is op0007=0x0 & op0815=0x0
{
}

# NOP (SYS)
:nop  is op0007=0xd & op0815=0x0 ; op1631=0x0
{
}

Use separate git repositories for processor specs

Is your feature request related to a problem? Please describe.
I would like to use your RISCV processor implementation, but have my own forks as well.

Describe the solution you'd like
Using a separate git repo with a submodule in this one would be much preferred to a dirty merge.

Describe alternatives you've considered
I could just copy that section of your source, but that wouldn't credit you fairly or link back for possible updates.

sample files

@Decryptortuning Do you have more of those i6l files (and possibly a db w/ RE applied to pair with)... mix of architecture if possible

Possible bad instruction decode

@esaulenka Thanks again for the firmware.

Do you have any thoughts on offset 0x68ee0 7e 77 bd a3.

Hopefully its data, but as a decode:
80068ee0 7e 77 jne d15,d7,LAB_80068eee
followed by bd a3 91 10 which doesn't decode
jumping to 00 5d 7b 10 which doesn't decode

other things:

I've only been using ELF so far, so this definitely is useful to look at. DWARF helps so much with arguments, and I know my implementation is lacking, not sure how to handle it.
Do you know if this image has PCP? I'll hopefully be adding PCP soon (looking to use the same approach as ARM/THUMB)
Looking at adding the specific TC172x processor spec with at least memory mappings, still figuring out labels with-in the mappings

Base + offset addressing mode

Ghidra produses strange code when meets with inderect addressing.

For example, in pcmflash..._2726.bin register a0 writes only once - with value 0xD000 BC00.
When I set this value (for whole code), i get:

                             **************************************************************
                             *                          FUNCTION                          *
                             **************************************************************
                             void __stdcall FUN_8006f8f4(void)
                               assume a0 = 0xd000bc00
             void              <VOID>         <RETURN>
                             FUN_8006f8f4                                    XREF[1]:     800700a2(c)  
        8006f8f4 82 00           mov        d0,#0x0
        8006f8f6 d9 03 60 b9     lea        a3,[a0]-0x6920
        8006f8fa 82 01           mov        d1,#0x0
        8006f8fc d9 02 60 c9     lea        a2,[a0]-0x68e0
        8006f900 3b 00 01 20     mov        d2,#0x10
                             LAB_8006f904                                    XREF[1]:     8006f916(j)  
        8006f904 8f 20 20 f0     sha        d15,d0,#0x2
        8006f908 c2 10           add        d0,#0x1
        8006f90a 10 3f           addsc.a    a15,a3,d15,#0x0
        8006f90c 37 00 68 00     extr.u     d0,d0,#0x0,#0x8
        8006f910 68 01           st.w       [a15]#0x0,d1
        8006f912 10 2f           addsc.a    a15,a2,d15,#0x0
        8006f914 68 01           st.w       [a15]#0x0,d1
        8006f916 3f 20 f7 ff     jlt.u      d0,d2,LAB_8006f904
        8006f91a 00 00           nop
        8006f91c 00 90           ret

void FUN_8006f8f4(void)
{
  int iVar1;
  uint uVar2;
  
  uVar2 = 0;
  do {
    iVar1 = uVar2 * 4;
    uVar2 = uVar2 + 1 & 0xff;
    *(undefined4 *)(iVar1 + -0x2fffad20) = 0;
    *(undefined4 *)(iVar1 + -0x2ffface0) = 0;
  } while (uVar2 < 0x10);
  a0 = &DAT_d000bc00;
  return;
}

Address calculations are correct (-0x2ffad20 is the same as 0xd000bc00 - 0x6920 = 0xD00052E0), but...

perhaps there is some way to indicate that result in address registers should be only unsigned ?

Another example:

                             void __stdcall FUN_8006f9be(void)
                               assume a0 = 0xd000bc00
             void              <VOID>         <RETURN>
                             FUN_8006f9be
        8006f9be 00 00           nop
        8006f9c0 ed 87 16 1e     calla      FUN_800e3c2c
        8006f9c4 df 12 07 00     jeq        d2,#0x1,LAB_8006f9d2
        8006f9c8 d9 0f 0a dc     lea        a15,[a0]-0x3cb6
        8006f9cc 0c f0           ld.bu      d15,[a15]#0x0=>DAT_d0007f4a                      = ??
        8006f9ce c2 1f           add        d15,#0x1
        8006f9d0 28 0f           st.b       [a15]#0x0=>DAT_d0007f4a,d15                      = ??
                             LAB_8006f9d2                                    XREF[1]:     8006f9c4(j)  
        8006f9d2 00 90           ret

void FUN_8006f9be(void)
{
  int iVar1;
  
  a0 = &DAT_d000bc00;
  iVar1 = FUN_800e3c2c();
  if (iVar1 != 1) {
    (&DAT_ffffc34a)[(int)a0] = (&DAT_ffffc34a)[(int)a0] + 1;
  }
  return;
}

Here disasm works correct, but decompiler doesn't understand this construction...

Add address spaces to processor definition files

Is your feature request related to a problem? Please describe.
Adding these definitions allows for a more accurate memory map of TC2xx processors

Describe the solution you'd like
When I load a binary for a TC277/297 processor, I would like commonly-used address spaces/ranges to be defined for me.

Additional context
Here are some sample memory regions for a TC277. There exist many more like caches, tags, emulation memory, data acquisition, boot rom, etc. but those are not required for most tasks.

    <memory_block name="CPU2_DSPR" start_address="0x50000000" length="0x1E000" mode="rwv" initialized="false"/>
    <memory_block name="CPU2_PSPR" start_address="0x50100000" length="0x8000" mode="rwv" initialized="false"/>
    <memory_block name="CPU1_DSPR" start_address="0x60000000" length="0x1E000" mode="rwv" initialized="false"/>
    <memory_block name="CPU1_PSPR" start_address="0x60100000" length="0x8000" mode="rwv" initialized="false"/>
    <memory_block name="CPU0_DSPR" start_address="0x70000000" length="0x1E000" mode="rwv" initialized="false"/>
    <memory_block name="CPU0_PSPR" start_address="0x70100000" length="0x8000" mode="rwv" initialized="false"/>
    <memory_block name="PFLASH0" start_address="0x80000000" length="0x200000" mode="rwv" initialized="false"/>
    <memory_block name="PFLASH1" start_address="0x80200000" length="0x200000" mode="rwv" initialized="false"/>```

Can't build 'tricore' project

Describe the bug
When running gradle --init-script gradle/support/fetchDependencies.gradle init, the process fails because \gradleScripts\processorUtils.gradle does not exist

Output

Where:
Build file 'C:\Users\user\Desktop\ghidra\ghidra\Ghidra\Processors\tricore\build.gradle' line: 7

What went wrong:
A problem occurred evaluating project ':tricore'.

Could not read script 'C:\Users\user\Desktop\ghidra\ghidra\gradleScripts\processorUtils.gradle' as it does not exist.

Environment (please complete the following information):

OS: Windows 10 18932
Java Version: openjdk 11.0.3 2019-04-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.3+7)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.3+7, mixed mode)
Ghidra Version: forked from this repo, branch tricore 7fc76db

tricore/certification.manifest

Please, add *.idx files to certification.manifest

Now, gradle build fails on 'ip' task.

Test binaries

@Frankracer @bri3d @Normmatt @bugasu

Sorry to ping you guys, but you are the few that have some interest in this. Does anyone have sample binaries they would be willing to share, it would be appreciated (Feel free to msg my Reddit acct if you don't want file info here/public). Also didn't realize issues isn't default on, so if you had been wanting to make one .

[tricore] float-point in DVADJ operand

@mumbel, if you dont mind, i will continue describe bugs in tricore sleigh here.

Describe the bug
According to p-Code operation manual, abs() function, that used in dvadj constructor, dealing with float-point operands, but any values, used in dvinit / dvstep / dvadj should be integer.

To Reproduce
Look at decompiled function, that uses dvadj

Expected behavior
I didnt fully understand, how dvXXX works, but according to tricore architecture manual, it should be redone as follows:

:dvadj Ree2831/Reo2831,Ree2427/Reo2427,Rd1215 is PCPMode=0 & Rd1215 & op0007=0x6b & op0811=0x0 ; Ree2427 & Reo2427 & Ree2831 & Reo2831 & op1623=0xd0
{
	#TODO  divide sequence
	local quotient:4 = Ree2427;		# E[d]  0..31
	local remainder:4 = Reo2427;	# E[d] 32..63
	local divisor:4 = Rd1215;		# D[b]
	
	local x_sign = remainder[31,1];
 	local q_sign = quotient[31,1];

	if (q_sign) goto <no_inc_quot>;
		quotient = quotient + 1;
	<no_inc_quot>
	if (((remainder == divisor) || (remainder == - divisor)) && x_sign) goto <nonzero_remainder>;
		remainder = 0;
	<nonzero_remainder>
	Reo2831 = remainder;
	Ree2831 = quotient;
}

improvements

@esaulenka @bagasu @rolandh @DarrylC03 I started a new branch to maybe add a few improvements. The patterns thing seems pretty nice already though to help find code (feedback on bad/additional/better patterns would be great, still figuring out the capabilities of patterns though) and ELF relocations (probably not of use to you, but will hopefully help with other analysis/code/testing).

https://github.com/mumbel/ghidra/tree/tricoreanalyzer

not sure how much more/often I'll work on it, but at least letting you know about the patterns feature

Add support for TC277

Is your feature request related to a problem? Please describe.
The TC29x is working well. Infineon makes a similar processor which has less on-board memory

Describe the solution you'd like
Similar to /Ghidra/Processors/tricore/data/languages/tc29x.pspec, a /Ghidra/Processors/tricore/data/languages/tc27x.pspec should exist, resulting in the TC27x processors being available for selection.

Describe alternatives you've considered
I've constructed a TC277 definition for IDA. While the TC29x definition could work for analyzing a TC27x system, it is potentially misleading.

Additional context
I can help in whatever capacity the maintainer would like.
In #13 The spaces I pasted are actually for the TC277, the 297 has double the flash (8MB) and most likely some more ram. From what I remember, the instruction set is the same.

mirror addresses

Sorry for question, but i don't found, how to specify that addresses 0x80001234 and 0xA0001234 point to the same location?

[tricore] 64 bit registers in DVINIT instruction

Describe the bug
To better compliance to other DVxx instructions, please use pair of 32-bit registers instead of one 64-bit. It also improves generated code.

I rewrote your code as follows:

@if defined(TRICORE_RIDER_B) || defined(TRICORE_RIDER_D) || defined(TRICORE_V2)
# DVINIT E[c], D[a], D[b] (RR)
:dvinit Ree2831/Reo2831,Rd0811,Rd1215 is PCPMode=0 & Rd0811 & Rd1215 & op0007=0x4b ; Ree2831 & Reo2831 & op1627=0x1a0
{
	#TODO  divide sequence
	local dividend:4 = Rd0811;		# D[a]
	local divisor:4 = Rd1215;		# D[b]

	Ree2831 = dividend;
	Reo2831 = 0xFFFFFFFF * zext(dividend[31,1]);
	$(PSW_V) = ((divisor == 0) || ((divisor == 0xFFFFFFFF) && (dividend == 0x80000000)));
	$(PSW_SV) = $(PSW_V) | $(PSW_SV);
	$(PSW_AV) = 0;
}
@endif

@if defined(TRICORE_RIDER_B) || defined(TRICORE_RIDER_D) || defined(TRICORE_V2)
# DVINIT.B E[c], D[a], D[b] (RR)
:dvinit.b Ree2831/Reo2831,Rd0811,Rd1215 is PCPMode=0 & Rd0811 & Rd1215 & op0007=0x4b ; Ree2831 & Reo2831 & op1627=0x5a0
{
	#TODO  divide sequence
	local dividend:4 = Rd0811;		# D[a]
	local divisor:4 = Rd1215;		# D[b]
	local quotient_sign = !(dividend[31,1] == divisor[31,1]);

	Ree2831 = (dividend << 24) | (0xFFFFFF * zext(quotient_sign));
	Reo2831 = dividend s>> 8;
	$(PSW_V) = ((divisor == 0) || ((divisor == 0xFFFFFFFF) && (dividend == 0xFFFFFF80)));
	$(PSW_SV) = $(PSW_V) | $(PSW_SV);
	$(PSW_AV) = 0;
}
@endif

@if defined(TRICORE_RIDER_B) || defined(TRICORE_RIDER_D) || defined(TRICORE_V2)
# DVINIT.BU E[c], D[a], D[b] (RR)
:dvinit.bu Ree2831/Reo2831,Rd0811,Rd1215 is PCPMode=0 & Rd0811 & Rd1215 & op0007=0x4b ; Ree2831 & Reo2831 & op1627=0x4a0
{
	#TODO  divide sequence
	local dividend:4 = Rd0811;		# D[a]
	local divisor:4 = Rd1215;		# D[b]

	Ree2831 = dividend << 24;
	Reo2831 = dividend >> 8;
	$(PSW_V) = (divisor == 0);
	$(PSW_SV) = $(PSW_V) | $(PSW_SV);
	$(PSW_AV) = 0;
}
@endif

@if defined(TRICORE_RIDER_B) || defined(TRICORE_RIDER_D) || defined(TRICORE_V2)
# DVINIT.H E[c], D[a], D[b] (RR)
:dvinit.h Ree2831/Reo2831,Rd0811,Rd1215 is PCPMode=0 & Rd0811 & Rd1215 & op0007=0x4b ; Ree2831 & Reo2831 & op1627=0x3a0
{
	#TODO  divide sequence
	local dividend:4 = Rd0811;		# D[a]
	local divisor:4 = Rd1215;		# D[b]
	local quotient_sign = !(dividend[31,1] == divisor[31,1]);
	
	Ree2831 = (dividend << 16) | (zext(quotient_sign) * 0xFFFF);
	Reo2831 = dividend s>> 16;
	$(PSW_V) = ((divisor == 0) || ((divisor == 0xFFFFFFFF) && (dividend == 0xFFFF8000)));
	$(PSW_SV) = $(PSW_V) | $(PSW_SV);
	$(PSW_AV) = 0;
}
@endif

@if defined(TRICORE_RIDER_B) || defined(TRICORE_RIDER_D) || defined(TRICORE_V2)
# DVINIT.HU E[c], D[a], D[b] (RR)
:dvinit.hu Ree2831/Reo2831,Rd0811,Rd1215 is PCPMode=0 & Rd0811 & Rd1215 & op0007=0x4b ; Ree2831 & Reo2831 & op1627=0x2a0
{
	#TODO  divide sequence
	local dividend:4 = Rd0811;		# D[a]
	local divisor:4 = Rd1215;		# D[b]

	Ree2831 = dividend << 16;
	Reo2831 = dividend >> 16;
	$(PSW_V) = (divisor == 0);
	$(PSW_SV) = $(PSW_V) | $(PSW_SV);
	$(PSW_AV) = 0;
}
@endif

@if defined(TRICORE_RIDER_B) || defined(TRICORE_RIDER_D) || defined(TRICORE_V2)
# DVINIT.U E[c], D[a], D[b] (RR)
:dvinit.u Ree2831/Reo2831,Rd0811,Rd1215 is PCPMode=0 & Rd0811 & Rd1215 & op0007=0x4b ; Ree2831 & Reo2831 & op1627=0xa0
{
	#TODO  divide sequence
	local dividend:4 = Rd0811;		# D[a]
	local divisor:4 = Rd1215;		# D[b]

	Ree2831 = dividend;
	Reo2831 = 0;
	$(PSW_V) = (divisor == 0);
	$(PSW_SV) = $(PSW_V) | $(PSW_SV);
	$(PSW_AV) = 0;
}
@endif