I’m not a hacker, but I try to put rudimentary anti-hacking elements in my software. Whether these really work or not, I honestly don’t know …
Sometimes I’ll use a method which decodes some encoded data in some convoluted way. Obviously, if a hacker gets at the “encode / decode” code, they’ll know how to get the unencoded data. That is simple to hack. Just now I was wondering about a tactic which might make such simple encoding more effective. Here’s the idea:
In the app would be a bunch of different complicated encoding / decoding methods. If the code calls any of the methods directly, it’s easy to hack. I wonder if a Delegate could make it a lot harder to hack? The idea is to use use a Delegate to obfuscate which method is being called.
For example, say we have 3 different encode methods called “Encode1”, “Encode2”, “Encode3” (in practice we’d give them totally misleading names). Then we make a delegate “EncodeX” that we can route to any of the other methods at will.
Would that accomplish anything? Or would the routed method name still show up in a stack trace? If only the delegate is shown, then a hacker doesn’t know which encoding / decoding is happening there. That’s the idea anyway.
That’s it. I’m ready to be laughed at by the hackers.
Obfuscate any plain text that you don’t want to make plain to a casual viewer. Beyond that, don’t bother, a hacker is just going to decompile your app into pseudo code anyway.
Thanks Kem, that’s basically been my practice so far. I was just wondering if using a Delegate would change anything about what a hacker ultimately finds.
Hard to say “obfuscate” here. A compiled code obfuscate what you do. Let’s change the question to “Does a Delegate hides what’s the method called from it, or not?”. Answer: Not.
When the interested party debugs your (compiled) code, he will see the indirect call, and will follow your method.
You should never rely on security through obscurity or obfuscation. If a hacker wants to see what your code does or manipulate it, they will. Take reasonable precautions but don’t kill yourself trying to make your applications hacker-proof. As long as it runs on their system, they’ll be able to tear it down and analyze it.
I don’t think your delegate would work, as the non-called code will not be included in your exe anyway.
Other considerations
To obfuscate all text variables I use the below web site. I retrieve these values at the last moment and never store them in a variable that hangs around:
I keep the UserID of the logged in user as an encrypted string that I turn into a number only as it is input into a database call. I am paranoid that the hacker will be able to change the UserID and pretend to be someone else.
All database calls are done via a REST server (a Xojo Web using HandleURL, accessed by Desktop and Web clients using ConnectionURL), so there are no database login details in my client app. The database is not accessible to the internet, only the REST servers.
I use #if TargetDesktop/Web and #if App.ApplicationName = “ABC” to limit certain code even existing in applications it doesn’t need to be in.
If a hacker really wants to access my data they will find a way, I just need to make the effort not worth while. The other vector is to hack my development computer, so I encrypt my source code and place it off site nightly. Other than this, I would give it all up if someone knocked on my door with a water-pistol.
Right, that’s good advice, and I know that already. The thought just crossed my mind that maybe a Delegate would make encoding data in different ways less transparent. I see the answer is “no”
[quote=“David_Cox, post:10, topic:57209”]
I don’t think your delegate would work, as the non-called code will not be included in your exe anyway.[/quote]
My idea would be to use all the code, just switch between them using the delegate. It would only make sense to do that if the delegate showed up for the call and not the method it points to. That’s not how it works, I’m being told, so the idea doesn’t work.
That’s cool. I already do similar things in my apps (with more complicated encoding schemes).
Well, if the app makes logs and bug reports, then of course I want to see the stack trace, so yes, that app should include function names. But if I don’t need that and the goal of the app is obfuscation, then not including them makes more sense. I’m pretty sure that’s all Rick was saying, and I agree with that.
Giving functions and variables misleading names is a tactic I mentioned at the outset which I already use. Making strings into gibberish or numbers is also something I’ve done in my apps for a long time, and that is the reason I was wondering about the delegate, just thinking today about some way to make those gibberish-generators a little less transparent.
I once remembered we had an app, which had all the license checking code three times in the app, so it would check on different sections and the hacker would need to patch it three times.
If an user have some kind of unknown crash, or exception, that the QA did not catch, you can send him a fat “debug version” with names, logging stack traces, etc. Fix ASAP, release new one. Most of the times you just need steps to reproduce it and find the bug without leaking names.
That’s an interesting point of view I hadn’t thought of before. Worth considering. I include a “startup logging switch” in my apps, so I don’t have to send out a special version when I need more info, I just tell them to start the app with a certain key combination held on the keyboard. I suppose there’s no way to do that with the stack trace though.
Depending on your process and budget and perceived overall experience of your product, you could always send the data to a server and have it run code (which the hacker can’t see). However there are many downsides to this process.
Requires Internet connection for app to function.
If connection is slow, process will be slow.
Cost for hosting.
Cost for bandwidth.
In theory “Harden Runtime” code signing option can actually prevent a debugger from accessing running code, so the hacker cannot connect to it to debug it. Which sounds great, except that the hacker could also resign the app before hand and remove the Harden Runtime option.
