Some observations on the use of RTTI

[marcov]

Looking at other dev environments like Java, .Net or even LLVM backed Swift and Objective C on MacOS, do generally publish all their symbols. For the vast majority of System reverse engineering is not a threat that needs to be mitigated.
There are commercially available obfuscators for many different languages, but they are a very small niche of products, most developers don't need protection against this.

Obfuscating debug info is less of a problem, since the symbols only link reference with definition. Change both and it will be ok.

RTTI is harder to change, since some field properties might exist in datastreams that stop working.

[Joanna from IRC]

It also seems like leaving symbols in would make the exe larger.

Does fpc have obfuscation? {If it doesn’t it should be added }Think I once saw it somewhere.
If not the only option left it to convert everything you want kept private into jibberish before building.

[MarkMLl]

It also seems like leaving symbols in would make the exe larger.

Does fpc have obfuscation? {If it doesn’t it should be added }Think I once saw it somewhere.
If not the only option left it to convert everything you want kept private into jibberish before building.

I've been watching this thread, and suggest that there's a distinction that might be being overlooked.

The first is that the most revealing information is debugging symbols since they provide the name and position of every variable and routine, and they can be omitted or stripped reliably.

The second is RTTI, which is less revealing but is problematic in that it cannot be stripped.

The third is obfuscation at the source level, which replaces variable names etc. but in general does nothing that a strip could also do (it was originally aimed at making sourcecode difficult to analyze, without changing the generated binary.

The fourth is encryption, which is rarely 100% effective unless done by the sort of technology that makes privacy advocates extremely unhappy.

But the bottom line is that the transformations applied by compilers are by now well-understood and that tools like Ghidra, originally written (and donated to the community) by the NSA but now embraced by hackers of all hat styles, makes it relatively easy to analyse an unknown binary, even in the complete absence of embedded symbolic information.

MarkMLl

[Warfley]

It also seems like leaving symbols in would make the exe larger.

It depends, executables are padded up to multiple kilobytes. So if the symbol names total to less than the padding, you will have 0 difference.
But sure in any larger program having all symbol names in there adds slightly to the size. But let's do a simple calculation. A 500gb SSD costs around 30€, let's say all the symbol names add up to a whopping 100kb (100kb of raw ASCII text us a lot), we end up with an additional cost of 0.000006€ for your application.
I'm pretty sure if your revenue margins are this low that this is a valid concern, you might reconsider your business decisions that lead you there.

Does fpc have obfuscation? {If it doesn’t it should be added }Think I once saw it somewhere.
If not the only option left it to convert everything you want kept private into jibberish before building.

The FPC is open source, feel free to add it yourself if you need it. The vast vast majority of people will not need it, especially as obfuscation usually impedes performance, so making your app worse with nearly no benefit is not a good tradeoff.

Let me ask again, what are you protecting against? If we are talking certification, source code is usually ot considered a primary asset, meaning no one protects source for the sake of protecting source code. What do you want to protect against by protecting the source?

[Joanna from IRC]

The FPC is open source, feel free to add it yourself if you need it. The vast vast majority of people will not need it, especially as obfuscation usually impedes performance, so making your app worse with nearly no benefit is not a good tradeoff.

I didn’t know tha obfuscation slows down code. I know little about how obfuscation a works I know that it is used for web programming.

What do you want to protect against by protecting the source?

well obviously if you have something like Say a banking app you don’t want people getting into your source code looking for exploits. Also as Fibonacci said earlier. There are people who will clone your apps and sell them as their own ..  who would want that? Not me !

[Warfley]

I didn’t know tha obfuscation slows down code. I know little about how obfuscation a works I know that it is used for web programming.

Basically obfuscation is to replace the obvious way of doing something with a more complicated way. For example, you could replace all Boolean operators with just nand as a simple example:

Code: Pascal  [Select][+][-]

1. a And b = (a nand b) nand (a nand b)

And as you can see this replaced one operation with 3. This is the slowdown I talked about.

With web it's usually not obfuscation for obfuscation sake, but for performance and compatibility. JavaScript source is always open source. The problem is, what is readable might not be what's most efficient. For example, a long variable name requires the Lexer longer to read than a short one, so the Js minimizers first rename all variables to short random few char names. Second it removes all white spaces and stuff like that.

The result is unreadable code, but not for the sake of making the code unreadable, but for other utilities

well obviously if you have something like Say a banking app you don’t want people getting into your source code looking for exploits. Also as Fibonacci said earlier. There are people who will clone your apps and sell them as their own ..  who would want that? Not me !

Bank apps are very specific because they are security software. But even there it's not the goal to protect the code, it's the goal to protect the primary assets, mainly the user pin, the private keys stored in the secure enclave/keystone and access to their bank account.
There obfuscation is just one of many techniques, like anti debugging, root detection, etc.

But how many banking apps are written in Pascal? There are not so many written to begin with and those that do exist are usually written in much better maintained languages. Because do you know what's more important than obfuscation? Having a Compiler and libraries which are hardened and well tested and do not accidentally introduce any vulnerabilities.
Which is something the FPC cannot provide.

Also Pascal is an unsafe language, so I hope that no one is writing security software in it to begin with

[MarkMLl]

well obviously if you have something like Say a banking app you don’t want people getting into your source code looking for exploits.

That is called security by obscurity, and is universally condemned: if somebody can crack your security solely by applying skill and time to it then you're screwed, since apart from anything else that sort of person will specifically target it because it gives him an advantage over those of his felonious competitors who lack those resources.

Also as Fibonacci said earlier. There are people who will clone your apps and sell them as their own ..  who would want that? Not me !

In that case use a platform where every executable is specifically encrypted for the machine it's going to run on. The only way to do that on a PC is to use an on-CPU TPM, which privacy advocates refuse because they are obsessed with the idea that it will allow Disney (of which the US government is of course a subsidiary) to snoop on them.

And at a risk moving further from the original RTTI question (but justifying it as an attempt to focus on the "what are you protecting yourself" issue), a vast amount of software has been hacked by looking for encraption keys in over-the-net updates: once you've cracked one you can apply that knowledge to what's running on just about any PC since they're all fundamentally the same and unserialised. And even if an update was individually encrypted you're at risk of somebody getting at your PC or domestic appliance and recovering its private key: who in here would notice if an intruder opened their PC, applied test probes and read security info from the mainboard?

MarkMLl

[Bogen85]

You would have to forbid compilers and hexbrowsers.(the latter the simplest form of decompiler)

There are always individuals like @Bogen85 who say it doesn’t matter to hide things (RTTI in this case). A sophisticated adversary specialized in this narrow field of binary analysis can reverse engineer your binary… Well, I certainly don’t want just anyone to open my .exe LITERALLY in NOTEPAD and say "oh, so you used FPC and this component, noob, maybe I will do something similar and sell it for half your price".

Well, always is relative....

I actually did not consider your scenario (some casual end user, not really who I would consider a reverse engineer, opens your .exe in notepad) and the fallout from RTTI exposing things.

In the software domains I work in (where there is a lot of closed source and shipped binaries) even with advanced reverse engineering tools if a customer were try the it would take them days (or weeks) to extract anything useful and months (or years) to produce anything viable.
And none of that would be taking place in a vaccum, those who developed the software initially would be hearing about, as people always talk in these domains. And when they would start to produce anything viable and selling it, they would be getting sued.

When someone does want to make their own product, they start their own company and start from scratch, and how they are developing the new products is chatted about and the other companies all know. So they make sure to develop in such a manner as to not get sued.

So, to be fair, I was not taking the time to see your side of it. So yeah, for situations in domains with producers and consumers like you describe, and those producers and consumers are not operating in overlapping chatty spheres of development, then disabling/stripping all RTTI and symbols in the final executable I can see as having merit.

The domain you describe is just not one I've operated in, but I do see your point, and it is a valid one.
But as MarkMLI pointed out, in cases like you describe, the executable could be encrypted in a way that allows it run, but not be observed so casually.

Even if encrypted, it still has to be run, and therefore at some point has to be decrypted, but the difficulty of decrypting for human (or for other machine) analysis increases as the encryption is pushed deeper into the hardware/firmware the program is running on.

[Bogen85]

Also Pascal is an unsafe language, so I hope that no one is writing security software in it to begin with

And then the RTTI would be useful for it made it obvious it was pascal, so a customer who knows about pascal who accidentally opened it up in notepad and saw that, can report with a vendor concern to determine if the app in question (especially if an end user received a binary) is mission critical and mission safe in regard to how it is to be used.

[Joanna from IRC]

when they would start to produce anything viable and selling it, they would be getting sued.

Sure it takes them effort to reverse engineer the code, but it’s probably much less effort than creating all the code to begin with.

Not everyone who plagiarizes software can be sued. What if they are located outside of your legal jurisdiction? There are well known companies that have gotten away with claiming other people’s work as their own and have a legal department to handle any lawsuits.

I’d much rather that my code can’t be easy to reverse engineer to begin with than hope that the legal system will rescue me after my code is stolen.

[Bogen85]

when they would start to produce anything viable and selling it, they would be getting sued.

Sure it takes them effort to reverse engineer the code, but it’s probably much less effort than creating all the code to begin with.

Not everyone who plagiarizes software can be sued. What if they are located outside of your legal jurisdiction? There are well known companies that have gotten away with claiming other people’s work as their own and have a legal department to handle any lawsuits.

I’d much rather that my code can’t be easy to reverse engineer to begin with than hope that the legal system will rescue me after my code is stolen.

I'm talking about a specific class of companies and customers, where all involved are playing in the same global arena with a lot of people who talk. Those are "small world" arenas (despite being global), and the likelihood of getting caught and found guilty is very high.

This does not apply the same way to all other classes of suppliers and consumer of software products.

[Joanna from IRC]

Sure they will get caught and might get a slap on the wrist 

[Bogen85]

Sure they will get caught and might get a slap on the wrist 

Small worlds. Long memories.

[Thaddy]

Not everyone who plagiarizes software can be sued. What if they are located outside of your legal jurisdiction? There are well known companies that have gotten away with claiming other people’s work as their own and have a legal department to handle any lawsuits.

I’d much rather that my code can’t be easy to reverse engineer to begin with than hope that the legal system will rescue me after my code is stolen.

One word: Concordsky

Even if you reverse enigneer code you run into trouble if you do it bad...
Joanna, is it so difficult to understand that if code runs it can be reverse engineered? All other assumptions are naíve.
Would not waste my time on it.

[Fibonacci]

My post is now buried and invisible, so let me remind what this is about: the level of difficulty. RTTI makes reverse engineering a walk in the park, and there is really no room for debate on that. Everything can be reverse engineered, but the real question is: whats the cost of that?

A sophisticated adversary will know exactly what your binary does, but with RTTI, even a kid can pop open your binary in some "exe analyzer", click "gimme list of the strings" and voila! They see all your precious secrets. They know you are using that specific AES256-CTR encryption, that particular TSHA256 hash class, that fancy component to display output in a nice table, and even that licensing component which screams at you to search for "componentname keygen/crack".

Simple: RTTI not used should not be visible.