cseagle / blc Goto Github PK

Hello Chris,

thank you very much for making available this great plugin!

I have loaded an ELF file for the Tricore architecture and am getting the following error within the IDA output window. My IDA 7.4 license on Windows supports the Tricore architecture but the plugin fails to load.

Using sleigh id: tricore:LE
Architecture string does not look like sleigh id: tricore:LE
Could not create architecture

Hi @cseagle,

First of all: thanks for your efforts and releasing blc.

Just downloaded the SP3 release of IDA Pro 7.5, running on macOS Catalina 10.15.7 having GHIDRA_DIR=/usr/local/Caskroom/ghidra/9.1.2_PUBLIC,20200212/ghidra_9.1.2_PUBLIC.

Opened linux binary afl-fuzz to ensure blc still works. Unfortunately it does not. Everything was still fine with SP2. I've tried again using newly built binaries to no avail.

When you start decompilation with blc, IDA immediately shows you it's about te crash (Let it crash vs Continue).

Best,
kciredor

Tested on multiple binaries and small functions. I also tried redownloading prebuilt binaries with prebuilt sleigh files, but no luck. Whenever I try to decompile anything it starts loading and freezes IDA so I need to kill it and relaunch. Also during the time it's frozen, 1 CPU core is running on 100% with ida64 process.

I noticed that ARM strings aren't being displayed very well for arm64 macho files. Here is an example I did with a simple hello world aarch64 Mach-O binary to show the differences.

Example 1: IDA with HEXRAYS decompiler

Example 2: Ghidra with Ghidra Decompiler

Example 3: IDA with blc (Ghidra Decompiler)

For long strings, it would definitely be better (for me) if they were fully displayed in the pseudocode instead of in a shortened variable.

Hi,

I haven't had the chance to debug this issue yet but I found it to be reproducible:

1. Decompile a function that references/calls another function
2. Rename one of its local variables so that it contains an underscore character ("test_123")
3. Double click the symbol/name of a function that is the called by the decompiled function

-> Crash

To compile in my Linux IDA Pro 7.6 the following changes were necessary:

diff --git a/Makefile b/Makefile
index 70ccacb..4a3968b 100644
--- a/Makefile
+++ b/Makefile
@@ -11,7 +11,7 @@ PLATFORM=$(shell uname | cut -f 1 -d _)
 PROC=blc
 
 ifeq "$(PLATFORM)" "Linux"
-IDA=/opt/ida-$(IDAVER)
+IDA=/opt/idapro-$(IDAVER)
 HAVE_IDA64=$(shell if [ -f $(IDA)/libida64.so ]; then echo -n yes; fi)
 PLATFORM_CFLAGS=-D__LINUX__ -D__UNIX__
 PLATFORM_LDFLAGS=-shared -s
diff --git a/plugin.cc b/plugin.cc
index 7245f51..d85a1d0 100644
--- a/plugin.cc
+++ b/plugin.cc
@@ -671,7 +671,7 @@ bool get_sleigh_id(string &sleigh) {
          break;
       case PLFM_386:
          //options include "System Management Mode" "Real Mode" "Protected Mode" "default"
-         sleigh += is_64 ? ":64" : (inf_is_32bit() ? ":32" : ":16");
+         sleigh += is_64 ? ":64" : (!inf_is_16bit() ? ":32" : ":16");
          if (sleigh.find(":16") != string::npos) {
             sleigh += ":Real Mode";
          }

dunno if this works for older versions too and if ida home is using just /opt/ida-VER, so not doing a pull request.
inf_is_32bit does not exist anymore it is now either inf_is_32bit_or_higher or inf_is_32bit_exactly.

blc currently does not compile on arm64 macOS:

make
g++ -c -Wextra -Os -D__MAC__ -D__UNIX__ -D__X64__ -m64 -fPIC -std=c++11 -I../../include/ -I./include/ action.cc -o obj32/action.o
In file included from action.cc:16:
In file included from ./action.hh:21:
In file included from ./block.hh:22:
In file included from ./jumptable.hh:22:
In file included from ./emulateutil.hh:22:
In file included from ./emulate.hh:22:
In file included from ./memstate.hh:22:
In file included from ./pcoderaw.hh:21:
In file included from ./address.hh:29:
In file included from ./space.hh:22:
In file included from ./error.hh:24:
./types.h:223:9: error: unknown type name 'int8'; did you mean 'int'?
typedef int8 intb; /* This is a signed big integer /
^~~~
int
./types.h:226:9: error: unknown type name 'uint8'
typedef uint8 uintb; / This is an unsigned big integer */
^

The plugin didn't seems to load and saw this in the console

Using sleigh id: x86:LE:16:Real Mode:windows
Bad symbol xml
Could not create architecture

I've copied the sleigh processors into plugins/Ghidra/Processors from 10.2.2.

The file I'm using is s DOS 16bit real mode EXE https://gist.github.com/palmerj/d006c9abf0eaf1be085ccf8f734359e1

Hi thank you so much for this work. Is it possible for you to provide an updated binary for 7.5 on Windows?

Hello, I tried copying the binaries to ~/.idapro/plugins or IDA installation directory plugins, but for some reason I cannot find the plugin in the menu.

So far I tried 32-bit powerpc ELF binaries and 64-bit x86 Mach-O for a test, both should be supported by Ghidra. Have you tried the plugin on macOS? I removed quarantine attribute the usual way with xattr -cr. My IDA installation is 7.4 on 10.15, so far I have not had issues with plugin installation, so I believe the issue should be elsewhere.

Since I like this project a lot I am currently looking into your ast to improve the output coloring a bit. Do you have any plans to work on this or already did so in a unreleased version? I am asking to avoid spending too much time into something which might be obsolete with the hopefully next release.

Hi, the latest Ghidra I can download from https://ghidra-sre.org/ (9.2.3) Sleigh version in the .sla files is 2, but the one required in this plugin is 3 (here), where can I acquire the newer version?

Platform: Darwin 19.6.0 Darwin Kernel Version 19.6.0: Tue Jan 12 22:13:05 PST 2021; root:xnu-6153.141.16~1/RELEASE_X86_64 x86_64

Ghidra:

int __cdecl16far main(int argc,char **argv, char **envp)

{
  byte bVar1;
  uint uVar2;
  char *unaff_DS;
  char *pcVar3;
  int iVar4;
  
  _aFchkstk();
  pcVar3 = unaff_DS;
  _printf((char *)0x1010);
  if (argc < 2) goto LAB_1292_0069;
  pcVar3 = argv[3];
  uVar2 = _strlen(argv[2]);
  if (uVar2 != 1) goto LAB_1292_0069;
  bVar1 = **(byte **)(argv + 2);
  if (bVar1 == 100) {
LAB_1292_00a7:
    pcVar3 = (char *)0x1;
  }
  else {
    if (100 < bVar1) goto LAB_1292_0069;
    if (bVar1 != 0x43) {
      if (bVar1 == 0x44) goto LAB_1292_00a7;
      if (bVar1 != 99) goto LAB_1292_0069;
    }
    pcVar3 = (char *)0x0;
  }
LAB_1292_0069:
  if ((pcVar3 == (char *)0xffff) || (argc < 3)) {
    show_usage((int)pcVar3);
    _exit(1);
  }
  pcVar3 = argv[5];
  strcpy((char *)0x4acc,unaff_DS);
  for (iVar4 = 3; iVar4 < argc; iVar4 = iVar4 + 1) {
    _strcat((char *)0x4acc,unaff_DS);
    pcVar3 = argv[iVar4 * 2 + 1];
    _strcat((char *)0x4acc,unaff_DS);
  }
  if (pcVar3 == (char *)0x0) {
    iVar4 = dcs_decompress(0x4acc);
  }
  else {
    iVar4 = dcs_compress(0x4acc);
  }
  return iVar4;
}

BLC:

void _main(__uint16 param_1, int16_t param_2, __uint32 param_3)
{
   uint8_t uVar1;
   int16_t iVar2;
   int16_t iVar3;
   __uint16 xVar4;
   int16_t unaff_DS;
   int16_t iVar5;

   __aFchkstk();
   _printf(0x13c8, 0x1010);
   iVar3 = (int16_t)param_3;
   xVar4 = (__uint16)((uint32_t)param_3 >> 0x10);
   if (param_2 < 2) {
      goto loc_12989;
   }
   unaff_DS = *(int16_t*)(iVar3 + 6);
   iVar2 = _strlen(0x13c8, *(__uint16*)(iVar3 + 4));
   if (iVar2 != 1) {
      goto loc_12989;
   }
   uVar1 = **(uint8_t**)(iVar3 + 4);
   if (uVar1 == 100) {
loc_129C7:
      unaff_DS = 1;
   }
   else {
      if (100 < uVar1) {
         goto loc_12989;
      }
      if (uVar1 != 0x43) {
         if (uVar1 == 0x44) {
            goto loc_129C7;
         }
         if (uVar1 != 99) {
            goto loc_12989;
         }
      }
      unaff_DS = 0;
   }
loc_12989:
   if ((unaff_DS == -1) || (param_2 < 3)) {
      show_usage(0x13c8, unaff_DS);
      _exit(0x1000, 1);
   }
   iVar2 = *(int16_t*)(iVar3 + 10);
   _strcpy(0x13c8, 0x4acc);
   iVar5 = 3;
   iVar5 < param_2;
   iVar5 = iVar5 + 1;
   _strcat(0x13c8, 0x4acc);
   iVar2 = *(int16_t*)(iVar5 * 4 + iVar3 + 2);
   _strcat(0x13c8, 0x4acc);
   if (iVar2 == 0) {
      dcs_decompress(0x13c8, 0x4acc);
   }
   else {
      dcs_compress(0x13c8, 0x4acc);
   }
   return;
}

Not having the main and string function signatures and parameters as defined in IDA disassembly I think it hurting the decomp process.

Seems to be missing an obvious loop too.

This is for a DOS 16 Real mode EXE binary. See EXE here