Universal C Decompiler (Open Source)

[BarryG]

Just found this from a Reddit post -> https://mohamadhanijanaty85.itch.io/cdecompiler

I thought it might work on PureBasic exe made with the C compiler, but that's not supported.

[NicTheQuick]

It seems like this decompiler is only useful for 32 bit executables which are quite rare nowadays.

I also found this one: https://github.com/uglyoldbob/decompiler

But I was not able to compile it.

Also please ask Fred if decompiling is allowed. I can not find anything in the licence but you never know.

[BarryG]

ask Fred if decompiling is allowed

That's not what I'm interested in. I was more concerned if we compiled with the C backend, could our exes be decompiled by others?

[yuki]

Ghidra is pretty good and open-source, but being owned by the NSA turns some people off to it.

IDA is closed-source but I tend to prefer it (more accustomed, faster, more plugins, better analysis of common patterns).

ask Fred if decompiling is allowed

That's not what I'm interested in. I was more concerned if we compiled with the C backend, could our exes be decompiled by others?

Someone determined enough could decompile your executables (regardless of backend) with readily available tools (like Ghidra/IDA).

For example, this PB source:

Code: Select all

OpenConsole()
Print("Please enter your name: ")
Define name.s = Input()
PrintN("Hi " + name + "!")

Decompiles into (via IDA):

Code: Select all

void __noreturn start()
{
  __int64 (__fastcall *v0)(); // rbx
  unsigned int v1; // eax
  unsigned int v2; // eax
  __int64 v3; // rcx
  __int64 v4; // [rsp+28h] [rbp-18h]

  qword_140004530 = (__int64)GetModuleHandleW(0i64);
  hHeap = HeapCreate(0, 0x1000ui64, 0i64);
  sub_140001650();
  sub_14000119C();
  off_140004090(aPleaseEnterYou);
  sub_1400016E0();
  sub_1400016E0();
  v0 = off_140004088;
  v1 = sub_140001710();
  ((void (__fastcall *)(_QWORD))v0)(v1);
  v2 = sub_140001710();
  sub_140001850(&qword_140004550, v2);
  sub_1400016E0();
  sub_1400016E0();
  sub_140001920(aHi);
  sub_140001920(qword_140004550);
  sub_140001920(&unk_140004014);
  v4 = sub_1400017F0();
  off_140004080(v4);
  sub_140001760(v3);
  sub_14000110A();
}

Note that the C code you'll get back is often not nearly as intelligible as the source, and not directly recompile-able.

Without exports or debug symbols, names of functions will be lost. Names of variables aren't knowable, so decompilers will have to assume what something is (or name it arbitrarily).

Despite that — and not to fearmonger — the loss of name information isn't really a problem for people skilled in reverse-engineering. With enough dedication, if someone has your executable, they can suss out your secret sauce.

It's extremely unlikely that someone rips off your entire program this way, but they might circumvent licensing restrictions ("crack" it) or dive into intricacies of some specific operation it does, file format it reads/produces, etc. in order to replicate such behaviours externally.

Unless someone needs interoperability with a program, it's mostly cheaper and easier to just build a separate program rather than deal with the mess of decompilation. Examples where someone might need interoperability, and thus be inclined to reverse-engineer:

• They're trying to figure out how some undocumented bytecode is interpreted, so they can produce or parse it themselves. (VM, shader IR, etc.)
• They want to mine your program's data files packaged using an unknown format that existing unpackers (e.g., QuickBMS) don't already handle.
• They intend to inject code meant to run inside your own program in order to affect its behaviour.
• …

There are tools like Themida, designed specifically to deter this, but they're only slight speedbumps to the very determined.

[Fred]

The executables you create with PB are yours, so you can do what ever you want with it. IMHO, using the ASM backend or C backend shouldn't change a lot when doing reverse engineering.

[Nituvious]

I've used a few different disassemblers before on windows, mainly Ollydbg and a fork of x64dbg. They're very useful for patching things in and out of closed source software.

Since becoming a linux nerd I haven't needed to use one, unless gdb counts.

[juergenkulow]

German Act on Copyright and Related Rights (Urheberrechtsgesetz – UrhG) Section 69e Decompilation
x64dbg snapshot_2019-06-16_14-12.zip with C Decompiler

[tj1010]

I'm sure HexRays will be glad to hear someone found a working C decompiler...

[Keya]

HexRays in IDA works on any Windows x86/x64 executable regardless of what language it's compiled in, because it converts assembly to C pseudocode. It can for example convert a Visual Basic executable to C pseudocode. There are obfuscation tricks you can use to help thwart this and make it more difficult, but that would be your job, not Fred's