Decompile Pascal Binaries - some advice please

[prsjm3qf]

Hi All,

I'm a past pascal programmer from the days of Turbo Pascal on DOS upto Delphi 4. So I have some pascal background. However, my current languages are Perl and C++ on linux.

I have been asked to write a security application to protect intellectual property and algorithms within turnkey image analysis systems running on Ubuntu Server.

My main fear is that my C++ binaries can be reverse engineered by a host of readily available decompilers. Would I be correct in assuming that binaries compiled with the Free Pascal Compiler would be much harder to decompile to C code, which is what all these tools seem to attempt?

The gnu pascal compiler seems to be merely a wrapper around gcc, which may even make matters worse.

Thanks for any advice...

[Leledumbo]

If you use optimizations and strip your binaries, there's almost no way one could reverse engineer your executable back into code. Even if one could, it's no longer the same code. He could guess an address to be a function start by examining all call instruction, but there's no sign at all what would the function do. He couldn't even do it on inline functions.

It's not language specific, after all, all (compiled) languages would produce the same end format: binary (PE, ELF, whatever).

[prsjm3qf]

So you think theres no point in swtching to Pascal from C++?

I'm not a cracker and I've never really tried to decompile anything. I just googled C++ decompile and there seem to be a lot of tools that claim to be able to reverse engineer executables back to a sort of C code.

I figured that if the code didn't start off life as C++ in the first place many of the structures that a decompile tool would expect to find within a binary file would be different.

My aim is to raise the skill level needed to be able to pick my binaries apart and modify/patch them directly.

[circular]

I don't think it's a valuable motivation.

There are of course other issues that can make you prefer the Pascal language. 

[prsjm3qf]

I actually do prefer the Pascal language.

Given a free choice I would have gone for Perl and Pascal and never bothered with C.

Don't like C++ much at all, but since I've done about 3 months work on this project in C++,  if no-one here thinks there are any serious security advantages to be gained by switching to Pascal then I may as well complete with what I've got.

Perl, on the other hand, is an amazing tool..

[Martin_fr]

Reverse engineer is a lot of work, but always possible.

tools may be able to produce c code (or maybe other languages; but that is c-code a compiler can deal with. Not necessarily a human.

Tools may be specialized for the binaries produced by certain compilers.
Those tools may recognize individual functions from libraries.
I do not know for which compilers/languages this is available.

One think that comes to mind about pascal:
RTTI => if you use a form, or any TComponent, then it produces RTTI => that means all the names of your classes and method are in the exe as plain text (even if debug info is stripped).
For classnames that may even be true without rtti.

If that is the case (please double check), you may want to run the code through an obfuscator first.

On the other hand keep in mind:
Reverse engineering an entire exe is always a lot of work.

But to overcome a security feature, you may only need a very few lines of source.

Never mind which compiler language was used. If no precautions where taken, it very easy and quick to get a assembler version of the code.
Example: if you have a feature that allows 3 trial runs and then blocks with an error msg.
In the assembler you can quickly find the error msg, and all references to it. It's not hard to find the code where the counter is compared to the limit.
Once you got the assembler statement (and it's offset in the exe, you can use a hex editor, and modify the exe. No need to even recompile.

So more important than the language, is to write the code, in a way that produces assembler that is hard to track.
That does not expose constants. That checks multiple times in different places, and and and...

---
Oh well, and I am *not* an expert on it. So just imagine how many more ways an experienced hacker may have to overcome your security features.

[Leledumbo]

I figured that if the code didn't start off life as C++ in the first place many of the structures that a decompile tool would expect to find within a binary file would be different.

Yes, some tools might recognize startup code of certain compilers (and can branch up itself from there), so switching compilers could be a solution. But only if there's no (yet) reverse engineering tool for that compiler.

One think that comes to mind about pascal:
RTTI => if you use a form, or any TComponent, then it produces RTTI => that means all the names of your classes and method are in the exe as plain text (even if debug info is stripped).
For classnames that may even be true without rtti.

Sorry, I forgot to tell about this. Yes, this should be watched and can't be eliminated since some features rely on RTTI.

Anyway, there are Delphi decompilers out there, but since we have different startup code, I guess those tool (hoprefully) won't work on FPC generated binaries.

[prsjm3qf]

Once you got the assembler statement (and it's offset in the exe, you can use a hex editor, and modify the exe. No need to even recompile.

So more important than the language, is to write the code, in a way that produces assembler that is hard to track.
That does not expose constants. That checks multiple times in different places, and and and...

Just a simple examination of C++ binaries in a hex editor reveals string literals. In fact I use this feature to substitute an encrypted shared secret into the binary at runtime as a session/hardware/environment specific fingerprint.
My approach is not to have any sensitive stuff in the binary at all but to build data and dynamic code at runtime from system specific sources and encrypted files. My aim isn't really to prevent theft of sensitive data from a particular binary file. Rather to hinder comprehension of a wider system composed of several closely inter-related components that are tightly integrated into the OS and hardware and only accessible in a meaningful context when the whole system is operating.

An obvious attack vector into my system is substitution of a modified binary at runtime. I have made the task of substitution as difficult as I can (sha512 checksums and random shared keys generated on the fly, etc) but I need to make the task of actually modifying the binaries more difficult too. Which is why I'm trying to make the task of understanding my binaries more difficult.

(another vector is a modified kernel but ultimately I can't be certain of handling that)

[prsjm3qf]

Yes, some tools might recognize startup code of certain compilers (and can branch up itself from there), so switching compilers could be a solution. But only if there's no (yet) reverse engineering tool for that compiler.

That was my hope, to push any attacker into working at such a low level that comprehending my complex system would be a huge task, but that such "whole system" comprehension would be needed to crack it.

Hopefully, then, for the suits to find someone with such skills who could be paid to steal intellectual property would be that much more difficult and expensive.

[prsjm3qf]

Obfuscation is the route I am following but I don't really know anything about reverse engineering binary files so I can only guess at the best approach.

Obviously be very careful with literal strings.

My actual functional code compiles to about 50k without debug info so would it make sense to increase the size of the executable by including and meaninglessly using a bunch of libraries? I have noticed that object pascal binaries are much larger. Is this an advantage?

How about forking sub-processes? Do crackers work by analysing the running program in memory in a procedural way?

Can I make it harder by being less structured? Jumping around with goto and using functions less? Should I use include files or try to make my main program huge and convoluted?

As I said, I have made it so the system only comes together meaningfully when run as a whole and so my biggest worry is binary tampering and substitution.

I fully understand that ultimately I cannot prevent reverse engineering. So I am trying to arrange for "possible" and "viable" to part company....

[Eclipticon]

Include files won't make any difference, the $INCLUDE command inserts the include file into the original code when parsed.

[prsjm3qf]

"Include files won't make any difference, the $INCLUDE command inserts the include file into the original code when parsed."

Yes, but would it be easier to trace from that point of insertion rather than if I mixed the whole thing up? - ie by modularising my code am I helping an attacker split it into logical chunks and so making it easier for him to manage his task?

Ah, on reflection I see what you are saying.... include files certainly won't make it harder.

[prsjm3qf]

Thank you very much

That's a lot to think about and it initially sounds like it may be well beyond my current skills and time constraints

I will investigate....

[avra]

If you are really concerned about protecting your intelectual property then you can combine your PC based software with some external custom made micro controller (MCU like AVR, PIC, 8051...) based hardware key (connected to PC via USB, RS232, LPT, I2C, SPI, 1wire...). For example, PC side application generates a random number which is sent to MCU, decoded and sent back as an unlock key to decrypt something important. Then additionally you have some important function executed directly in MCU (you just pass parameters and get the result from MCU). You can imagine how that would raise cracking difficulty for a hacker in order of a magnitude, since his knowledge would have to be much wider then usual. There isn't a perfect protection, but if you really want to make it a challenge then this could be a way to go.

AVR Pascal compiler (free for MEGA8/88 which is more then enough for this task, you can get USB from RS232 with some FTDI chip like FT232 and you get virtual serial port without need for libusb):
http://www.e-lab.de/AVRco/index_en.html

AVR V-USB GCC library (USB interface implemented in software, libusb used for communication):
http://www.obdev.at/products/vusb/index.html

libusb translated headers and example in Lazarus:
http://mcuprogramming.blogspot.com/2010/12/example-in-lazarus-for-libusb.html
http://www.radiolocman.com/shem/schematics.html?di=67235

EDIT1:
AVR LUFA library (USB interface implemented in hardware)
http://www.fourwalledcubicle.com/LUFA.php

EDIT2:
ARM Pascal Compiler (I know that FPC can compile for ARM but this one is much more microcontroller oriented with I2C, SPI and many other important drivers)
http://www.mikroe.com/eng/products/view/754/mikropascal-pro-for-arm

[eny]

If you are really concerned about protecting your intelectual property then you can combine your PC based software with some external custom made micro controller (MCU like AVR, PIC, 8051...) based hardware key

Also known as a dongle (for example http://www.microcosm.com/dinkey_pro_models.php).