Please excuse one of my regular silly questions. Elsewhere, a (former) Delphi programmer is uneasy having found that his binaries have had embedded SQL queries, passwords and so on visible "in clear" for the last 20 years or so.

Can FPC be told to obfuscate ResourceStrings?

Mark Morgan Lloyd wrote

Can FPC be told to obfuscate ResourceStrings?

No, but why the hell would you want to hard-code a password inside an executable. Encrypt it externally and read it from a .INI file at runtime (or prompt for a password). Even something as simple as XorString() is better than nothing - compared to storing it inside your source code.

Regards,
Graeme

I didn't say /I/ was the one doing it. I'm the one asking about it.

No. The default value for resourcestrings is stored as-is in the binary.

To solve this, I store the username/password encrypted in the binary as consts, and they are decrypted when needed.

Michael.

Mark Morgan Lloyd wrote

I didn't say /I/ was the one doing it.

I know and I wasn’t implying you. It’s a figure of speech.

Regards,
Graeme

Graeme Geldenhuys wrote

On 2016-07-12 21:09, Mark Morgan Lloyd wrote:> I didn't say /I/ was the one doing it. I know and I wasn’t implying you. It’s a figure of speech.

In that case "No, but why the hell would *one* want to hard-code a password [...] storing it inside *one's* source code." :-)

Sometimes it's difficult to avoid having to do that sort of thing, or obfuscating them in an external file.

Could it help to try doing this after linking the program binary, to build the resources and scramble them using the program binary part checksum (or have it seed a PRNG and/or derive an encryption key / key pair from it) ?

Not that I know how ;) and whether such a thing is viable at all - or desirable (since an executable would always have to be distributed with matching resources build). But how would that be for an idea ? ;)

el es

Mark Morgan Lloyd wrote

In that case "No, but why the hell would *one* want to hard-code a password [...] storing it inside *one's* source code."

The English language is perplexing (ie: “clear as dishwater”). There are a 1001 rules and exceptions to the rules. Both our sentences are acceptable.

Regards,
Graeme

Mark Morgan Lloyd wrote

Sometimes it's difficult to avoid having to do that sort of thing, or obfuscating them in an external file.

You could use something like DCPCrypt to help the cause. Or you could follow similar tactics to what OnGuard uses - encode sensitive text in a data structure. At the very least use a const of bytes instead of clear text. For example:

const
  CKey : TKey =
($E5,$8F,$84,$D6,$92,$C9,$A4,$D8,$1A,$FA,$6F,$8D,$AB,$FC,$DF,$B4);

Regards,
Graeme

I wonder whether this could this be handled by a step related to i18n.

The whole thing's a bit of a minefield, since there are hacking tools out there which can scan a binary looking for regions which are more random than expected on the basis that these might be things like crypto keys.

May I know what OnGuard is? googling it returns something irrelevant.

On the subject, can the OP simply use UPX to encrypt the executable binary. It won't be secured but no more unsecured than other simple solutions.

UPX is at http://portableapps.com/apps/utilities/free_upx_portable

The original sourceforge.net link is dead, I don't know why.

Dennis

Dennis Poon wrote

May I know what OnGuard is?

It was originally TurboPower OnGuard, but then released as open source software. It allows you to license your software in many different ways. eg: x amount of days trial, lease your software for a year at a time, x amount of uses before it expires etc.

Source code:
https://github.com/graemeg/onguard

FPC Wiki page:
http://wiki.freepascal.org/OnGuard

Regards,
Graeme

Well, if you don't prompt the password, where do you store the password to decrypt the externally encrypted password? ;-)

Whenever you try to hide something without storing the password in user's brain you are just ofuscating. A hard coded password is just another way of ofuscating strings, but with a higher level of ofuscation.

My solution to store passwords was to store de password in a .INI file (i.e. user doesn't want to type the password, wants the program to remember it).

The connection password was encrypted with a hard-coded password and stored in base64 in the in file.

i.e.

implementation
Const _Password='48-49-50'; // hardcoded ofuscated 123, so in resources
it is not plain
function unofuscate(s):string;
begin
  .....
end;
procedure LoadData;
begin
  ....
  IniPassword:=unofuscate(_Password);
ConnectionPass:=SimpleDecrypt(Base64Decode(ini.ReadString('connection','pass','')),IniPassword);
  ....
end;

I always declared the password in the implementation section, (don't know where I read that that way there is not a recognizable symbol "_Password"), if I had to use it in several places, I used ($include pass.inc}

My ofuscate function was a little more complex, and but anyway, any system that stores passwords without human intervention is inherently insecure.

Well, it was long time ago.

Dennis Poon wrote

On the subject, can the OP simply use UPX to encrypt the executable binary. It won't be secured but no more unsecured than other simple solutions.

I'm the nominal OP, but I raised the question in response to what an (ex-) Delphi programmer was asking elsewhere about obfuscators etc. for .NET which is what he now uses.

He posts: "...particularly database access strings. I realised I had the passwords in plain text, so figured this must be a well-trodden path. Found a thread about it from 2006, with detailed discussion. Struck me as odd that ten years later it isn't automatically solved in Visual Studio."

What's interested me is how this thread has almost looped back to a recent thread on that steaming heap of brown stuff know as GTK and the attitude of the programmers behind it.

I had a similar problem a few years ago whiich I wanted to solve by putting the passwords in an external file and using file permissions to hide it from the bad guys. The file could be owned and only readable by root, or better some ordinary user. The preferred solution was to make it read/write a non-login user and read only to a group but no one else. Users had to be members of the group to read it. Better still was to make the program setgid to that group, allowing anyone who could run the program (and login into the database) to get access to the password controlled info without being able to actually read the password themselves.

However, GTK gets in the way of this because some bozo GTK developer thinks they should police use of setuid and setgid from GTK and will raise an exception if run from a setgid program. Google "gtk setgid" for examples. I can't see a security problem from setgid to a normal group - to me its a security mechanism, but you try telling that to the GTK team.

Read http://www.gtk.org/setuid.html for an example of some incredibly muddled thinking. They make the point here that GTK is (too) complex and difficult to analyse hence setuid (and setgid) is bad on the grounds that no one knows how it could be mis-used. They then recommend writing an setuid backend in such situations, without recognising that all they have done is to move a problem rather than solve it. I wanted my program to be setgid so that only it could access privileged information. If I write a setgid backend program now I have to find a way of authenticating my GTK frontend to my backend.... (Oh perhaps I should have an embedded password).

The point is that while it is reasonable for a developer to give guidance on what is good practice, actively stopping a user from using your code in a way that you do not approve is not just stupid and contemptuous of your users, it can actually get in the way of the right solution to a problem that you do not know about.

Assuming that this problem still exists in GTK2, it may get in the way of what otherwise could be a good way to solve the original problem in this thread.

Tony

Tony Whyman wrote

What's interested me is how this thread has almost looped back to a recent thread on that steaming heap of brown stuff know as GTK and the attitude of the programmers behind it.

It wasn't intentional :-)

There's certainly still problems setting running something setuid root, I can't speak for using a less-privileged user. I think you might be able to work around some (but not all) of the issues using capabilities.

The thing that I found most incredible about the attitude of the GTK developers was that they used the fact that Linux changes /internal/ interfaces as a precedent that they claimed justified their changing /external/ APIs (i.e. as available to application programmers).

Thinking this sort of thing through, and focussing on reasonable obfuscation rather than rigorous encryption, one possibility would be to put a passphrase in the executable stored with (say) nibbles reversed, then to subtract each letter of this from obfuscated resourcestrings when they were needed.

Subtracting a couple of test paragraphs (start of Genesis, start of the American declaration of independence) gives a fairly even distribution of bytes in the range -84 through +87 (this would need to be tested with a much larger corpus). This would probably be good enough to deter people who thought they might be able to find passwords using a simple file viewer.

Can anybody comment on what effect using UTF8 would have rather than simple ASCII?