0

I have a dll (ansi c) that has some string litarals defined.

__declspec(dllexport) char* GetSomeString()
{
    return "This is a test string from TestLib.dll";
}

When compiled this string is still visible in "notepad" for example. I'm fairly new to C, so I was wondering, is there a way to safely store string literals?

Should I do it with a resx file (for example), that has some encrypted values, or what would be the best way?

Thanks

EDIT 1: The scenario is basically the following in pseudo code: if(hostname) return hostname else return "Literal String"';

It's this "literal string" that I would like to see "secured" in some way..

Yves Schelpe
  • 3,343
  • 4
  • 36
  • 69
  • 1
    You could use a (simply reversible) encryption algorithm and use only the encrypted values in your code, which you could decrypt during runtime. Beware of the runtime penalty though. – arne Nov 21 '13 at 18:10
  • 1
    Using an (encrypted) resource file is one way to go, but that also adds decryption overhead and linking to runtime library that handles the resource file management (unless you roll out your own). – Santa Nov 21 '13 at 18:11
  • thx @arne & Santa - I'm going to try and use arne's option.. It doesn't have to be super tight, but not too obvious as well. – Yves Schelpe Nov 21 '13 at 18:16
  • 1
    You should explain better what kind of security you need, and what "secret" is to be stored in your dll, maybe there are better ways to tackle the problem that don't involve storing a secret string. – Matteo Italia Nov 21 '13 at 18:19
  • Well for example, say I'm returning the user's machine name.. If it can't be returned, I'll give a message in stead of the machine name.. That sort of strings.. in pseudo code: 'if(hostname) return hostname else return "Literal String"'; – Yves Schelpe Nov 21 '13 at 18:27
  • @YvesSchelpe: uhm, and why should this data be secret? Actually, people not only never bother with encrypting this data, but often put this kind of messages in the resources to help translators. – Matteo Italia Nov 21 '13 at 18:28
  • it's just an example, not the actual implementation, due to some reasons this code will be fed into an algorithm used to generate a key.. It's one of the parameters.. – Yves Schelpe Nov 21 '13 at 18:34
  • 1
    As said above, encryption isn't going to help much in this schema. You are hiding keys behind encryption, but since you have to leave the last key in clear it's mostly pointless. Still, if it's just *one* string you want to hide, probably you should exploit security by obscurity: store it scrambled in some bizarre way (permute the bytes, apply xor, the like), decrypt it on the fly when you need it and then zero it out. Since you can rely only on obscurity, you just want to make it go unnoticed (hence "hide the ASCII", and no crypto library calls) and stay in memory for the least time possible. – Matteo Italia Nov 21 '13 at 19:05

3 Answers3

4

Don't put your secrets on anyone else's computer if you want them to stay secret.

See my related answer, The #1 Law of Software Licensing

And Eric Lippert's similar answer

Community
  • 1
  • 1
Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • "If you want to keep control over your code, you need to make it a web service and give the end user just a thin client that interfaces to that web service.".. I understand it very well, and I know that is a weakness.. Still, we're in relatively much control of the pc's we'll deploy this on, so, it's easy to change the implementation from time to time.. The software will only be useful for those domain machines. – Yves Schelpe Nov 21 '13 at 18:36
  • 2
    @Yves: If you control the PC, you can replace web service with system service. You just need the data outside the portion of the code that runs in the user's own profile. – Ben Voigt Nov 21 '13 at 18:39
  • Ok, that I have 't thought of yet.. need to research though if it's 100% compatible. Thc – Yves Schelpe Nov 21 '13 at 18:45
4

First of all, since your executable1 needs to decode that literal in memory, any attacker determined enough will be able to do the same; often it's just as easy as freezing the process after startup (or after it needed to use the string we want), creating a memory dump and use utilities like string over it. There are methods to mitigate the issue (e.g. zeroing the memory used by a sensitive string immediately after using it), but since your code is on a machine where the potential attacker has all the privileges, you can only put roadblocks: in the end your executable is completely in the attacker's hands.

That being said, if your concern is just "not leaving important strings en plein air" you may just run an executable packer/encrypter over your whole dll. This is as easy as adding a post-build step in your solution, the packer will compress/encrypt the whole executable image and build an executable that when launched will decrypt and run it in memory.

This method has the great advantage of not requiring any change to your code: you just run upx over the compiled dll and you get your compressed dll, no XORs or weird literals spread across your code are needed.

Of course, this is quite weak security (basically it will just protect from snooping around in the executable with notepad or a hex editor), but again, storing critical "secrets" in an executable that is going to be distributed is a bad idea in first place.

  1. In the whole answer I "executable" is to be intended in the wide meaning - i.e. also dlls are included.
Matteo Italia
  • 123,740
  • 17
  • 206
  • 299
  • Such packers aren't freely available, no, or am I mistaking? The packer then acts (or creates) as a kind of wrapper I presume? Thx for the info, and I know that it isn't good to keep such "secrets" in an application, that's not why I'll be using it for.. It just seemed kind of sloppy to give these things away - even though they aren't "secrets". – Yves Schelpe Nov 21 '13 at 18:22
  • 1
    @YvesSchelpe: UPX is a great packer and is free, but it does not encrypt anything, it just compresses (not that it changes things by much); it must be noted that UPX is particularly easy to decompress, once you noticed that the exe or dll is UPX-compressed you can just go on the UPX site, grab the packer and do `upx -d yourlibrary.dll`. – Matteo Italia Nov 21 '13 at 18:25
  • ok, thanks for the suggestion, this is helpful I think (see my edited question above /edit1) – Yves Schelpe Nov 21 '13 at 18:29
  • It should be noted that encoded executables make some antivirus programs unhappy, because they want to analyze the code and now they can't. – Ben Voigt Nov 21 '13 at 19:45
1

You probably want to store hardcoded passwords in the library, right? You can XOR the string with some value, and store it, then read it and XOR again. It's the simplest way, but it doesn't protect your string from any kind of disassembling/reverse engineering.

HEKTO
  • 3,876
  • 2
  • 24
  • 45
  • it's a start.. basically it shouldn't be super secure.. It just seemed too obvious to have it open and wide like that, so thanks for the suggestion! – Yves Schelpe Nov 21 '13 at 18:13