Obfuscator for FreePascal / Lazarus

[marcov]

I still don't see your point. That's a basic dictionary lookup. What's difficult about it? (core algorithm)

Just the understanding of the asm instruction, and then getting some simple loop structures back is quite a bit of work. Just try it yourself.

Personally I like the decompiled code snapshot posted by GPcH a lot, I'll keep it in mind. 

[Thaddy]

I still don't see your point. That's a basic dictionary lookup. What's difficult about it? (core algorithm)

Just the understanding of the asm instruction, and then getting some simple loop structures back is quite a bit of work. Just try it yourself.

Personally I like the decompiled code snapshot posted by GPcH a lot, I'll keep it in mind.

I know that. Time. But it is not complicated at all. Look up my old code....
But the presentation looks good...

BTW half a screenshot is enough for me that it says that you have to run the program. That's not what I explained and naive...
Since when has software a build in hardware timer.... Silly... So you run the piece of sh*t over a software cpu... Basics...

Anyway, I am out..

[Thaddy]

In general I don't understand this kind of questions. Or for OP: proposals. It is sheer nonsense. It bothers me all day again.
Advice: use your time for something different and brilliant. You can't make a career out of obfuscation, try buying an ostrich suit and stick your head into the ground. Makes more money.

And now I will try to keep myself REALLY out, ok? <halfway grumpy.. >

[Thaddy]

Don't get distracted or disappointed: You are a good programmer. Don't waste your time...Go for something brilliant... works half the time, but not always...trust me... been there done it, have a house and a garden (and some female dogs, cat, daughters and wife...)
[edit]
This was obviously a reply to something that was removed.
I also do that. sometimes. Mea Culpa...

[karmacomposer]

I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code.  We have been looking at dotfix's software and I have a question:

Can we use your software to actually encrypt the source code? If the source code is encrypted, then it makes it almost impossible to decompile or disassemble, right?

How can we protect our code with your software above and beyond obsfucation, which I have read is pretty much useless for true protection.

Thank you.

Mike

[440bx]

I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code.  We have been looking at dotfix's software and I have a question:

Can we use your software to actually encrypt the source code? If the source code is encrypted, then it makes it almost impossible to decompile or disassemble, right?

How can we protect our code with your software above and beyond obsfucation, which I have read is pretty much useless for true protection.

Thank you.

Mike

Source code is not decompiled nor disassembled.  Disassembly applies to compile code, not source code.

You can obfuscate source code.  That's usually done by replacing descriptive variable names with very cryptic and nonsensical ones as well as totally messing up the formatting of the code.  Just so you know, that's simply laughable.  It really isn't worth the effort on your part.

As far as making code hard to disassemble, there are what's called "software protectors" that do all kinds of things to make the executable difficult to disassemble properly and difficult to run under a debugger.  That will definitely frustrate the amateurs out there but, it will be no great obstacle to an experienced reverse engineer.

Keep in mind too that every time one of these "software protectors" comes up with something new, there is someone out there impatiently waiting for that new thing to appear, for him/her to publish how to defeat it.  Prestige is currency there.

Best defense is, make the software really easy to disassemble but, add all kinds of "red herrings" for the cracker to follow.  Easy stuff too so the guy gets really bored, you don't want to provide a challenge because it will be accepted and defeated, instead provide boredom, more boredom and boredom ad nauseam.  IOW,  don't challenge the smarts (you'll lose), challenge the patience! (you do that well, you have a chance - young kids know that!.)

[Thaddy]

I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code.

You could have spent those 5 years to educate yourself instead of asking really stupid questions. (which is fine, I do the same)

to protect the compiled code

Not possible.. Period.
Take the legal track, that usually can achieve some result.

[marcov]

I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code.

You could have spent those 5 years to educate yourself instead of asking really stupid questions. (which is fine, I do the same)

Like here, since Karmacomposer never said he spent 5 years on the problem.

to protect the compiled code

Not possible.. Period.
Take the legal track, that usually can achieve some result.

Basic anti piracy controls can strengthen a court case because it needs active circumvention of copyright controls, making an "accidental" defence less likely.

[Martin_fr]

If the source code is encrypted, then it makes it almost impossible to decompile or disassemble, right?

How can we protect our code with your software above and beyond obsfucation, which I have read is pretty much useless for true protection.

At first, no. Sourcecode encryption is not helping....

But:

Due to RTTI some of your identifiers actually end up in the exe (e.g. TForm). A decompiler that knows the fpc RTTI format, will be able to use that. So replacing all identifiers with nonsense names => may help.

Also a decompiler might (not sure what is on the market) recognize code from the RTL or LCL (even in its compiled form).
Splitting functions, inserting other code,.... All that may help.
 
Actually an obfuscater that rewrites the code, spilts subroutines, inserts none-sense code, inlines some code, yet calls other,.... That may make it a little harder to decompile.

[Blade]

Machine code can be translated into Assembly code (disassembler), from there you can create high level pseudo code (decompilers).  Probably the most famous one is Hex-Rays in IDA Pro.  Other notables are Snowman (think its also in Ghidra and an option for IDA Pro), Reko, and RetDec.  The quality of the pseudo code (in pseudo C) is the subject of lots of debate, but it can give an idea of how the original source code works.  We have to also keep in mind that such tools are slowly improving.  How useful this "kind of useful" information is, most likely depends on how much an expert the person is. 

In regards to Object Pascal, the decompilers that I've seen on the web were mainly targeting Delphi.  Revendepro, DeDe, etc...  They all look old.  Haven't seen anything specifically for FPC, though clearly if a concerted effort was made, it could be done.  Probably the most obvious thing that shows up with FPC, with something simple like Resource Hacker or similar are .lfm (TForm) data.  Then the next common thing is "string hunting".  You could use the well known decompilers on FPC executables, but then how useful psuedo C code is going to be in comparison to the actual source is doubtful.  Then add various optimizations into the mix, yet more doubtful.

Usually obfuscation is necessary for the scripting and interpreted languages, like JavaScript or C#.  Compiled languages are a higher step in difficulty.  There are people that are really good at reading Assembly (disassembler output).  It's just that its troublesome for most, so the numbers of programmers interested in and good at reading it are few.  Regular people, users, and customers are not about that life, which is the realm of those into cracking, criminals, professionals, or security.  Those that are hardcore into cracking, will usually not be customers and nearly nothing will deter them because they are getting off on the challenge.  If any deterrent can work on those types, it's likely the legal route, like notifying ISPs, suing over copyright and trademark violations, etc...

[Blade]

Actually an obfuscater that rewrites the code, spilts subroutines, inserts none-sense code, inlines some code, yet calls other,.... That may make it a little harder to decompile.

There are YouTube videos of high-level programmers ripping into Metasploit defensive measures like obfuscation and anti-debugger (code for the specific purpose of having its payload undisturbed).  "Tricky code" could slow people down, but clearly those about that life are going to figure it out with enough time.  Average folk don't even know about such things, so it's definitely going to be a select percentage even trying.

[Martin_fr]

Actually an obfuscater that rewrites the code, spilts subroutines, inserts none-sense code, inlines some code, yet calls other,.... That may make it a little harder to decompile.

There are YouTube videos of high-level programmers ripping into Metasploit defensive measures like obfuscation and anti-debugger (code for the specific purpose of having its payload undisturbed).  "Tricky code" could slow people down, but clearly those about that life are going to figure it out with enough time.  Average folk don't even know about such things, so it's definitely going to be a select percentage even trying.

Hence, I said: "make it a little harder". And I did not say "might stop" or anything alike.

[Mr.Madguy]

Obfuscation is usually needed for scripts only. And not only to protect it from "decompiling", but also to reduce code size and make interpretation faster. For compilers it's better to use some binary manipulation.

[MarkMLl]

You can obfuscate source code.  That's usually done by replacing descriptive variable names with very cryptic and nonsensical ones as well as totally messing up the formatting of the code.  Just so you know, that's simply laughable.  It really isn't worth the effort on your part.

I'm winding back and commenting here since plenty of others will point out that "security by obscurity" is never a good idea, and that if you want to keep your code fully-protected the only thing you can do is keep it on systems under your full physical control... and then pray incessantly that you won't be hit by a zero-day. However, on the topic of obfuscators:

Tools that produce "shrouded C" etc. typically do much more than remove formatting and replace symbolic names: they also replace control structures by jumps and gotos and so on. They can be moderately effective against casual perusal by an application-level programmer, but confer no protection at all against a determined (and expensive) professional.

But obfuscating the source should still result in the same- or at least a very similar- executable being emitted, so is of no practical use if a product is being shipped as binaries: avoiding RTTI and making sure that debugging info is stripped is far more important.

The only real area in which an obfuscator might be relevant is if somebody is using GPL-licensed libraries, and is of a mind to protect his own code which, as everybody now knows, similarly becomes GPLed on release of the binary. I have to caution that the legality of doing that has not, to the best of my knowledge, been tested in court, and the attempt would risk getting an extreme amount of media and possibly legal attention.

MarkMLl

[avra]

I know this thread is 5 years old, but we are creating a security product and need to protect the compiled code.

If you are referring to software protection, then you might want to check out some of these links:
https://forum.lazarus.freepascal.org/index.php/topic,38960.0.html
http://forum.lazarus.freepascal.org/index.php/topic,13000.msg67843.html#msg67843
https://wiki.freepascal.org/OnGuard

For simple windows executable obfuscation tool, search the net:
https://duckduckgo.com/?q=windows+executable+obfuscation+tool&ia=web

There is no perfect tool for either. Whatever you use, it will just lower the percentage of people who are able to decode your code and data, but that percentage will never be zero. When there is a will, there is a way...