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 People

Contributors

Stargazers

Watchers

Forkers

kaydoh

ghidra's Issues

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

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)

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.

tricore/certification.manifest

Please, add *.idx files to certification.manifest

Now, gradle build fails on 'ip' task.

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

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

[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;
}

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.

[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

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

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"/>```

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 .

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 misa instead for the context

See privileged PDF for misa CSR

This is the exact register to use for the context register

mirror addresses

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

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

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.

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.

mumbel / ghidra Goto Github PK

ghidra's People

Contributors

Stargazers

Watchers

Forkers

ghidra's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs