Reverse engineering compiled Xojo programs

[quote=90404:@Kem Tekinay]While that’s a clever way of hiding information, that’s not what he meant. He was saying that the picture itself could be converted to a string at runtime which, in turn, would act as a password for traditional encryption. Very clever, and raises the difficulty level.

Still, anyone who has the expertise and tools to trace the code may be annoyed, but not fooled.[/quote]

Yes I agree. Like everyone has said if the hacker is determined enough they will get what they want. My concept though was to separate the password in some way from the binary so they are not stored together and also to hide it in an unlikely place. I.e., turn off the ignition, lock the doors and bury the car keys in a hole away from the car :slight_smile:

And then tell everyone about it on a public forum (ha ha) :wink:

I am used to compare this question with Wallbuilders and Cannonmakers in ancient times:

Somebody builds a strong wall without any weak spot when somebody else builds a strong cannon with enough power to break it. Then the Wall is built higher and stronger to match the firepower. But the cannonmaker is raising the bar a little more and starts to improve his cannon and makes the wall to break again. The story goes on and on…

It’s on you to decide how high you want to set your security bar of your app.

Ultimately, the problem of storing confidential information in a program is a bad idea. Nobody in his right mind would leave his briefcase containing confidential information unattended in a public place. The best way to keep anything secret is not to tell.

Any hacker, even with limited knowledge but with enough time will defeat all clever ideas to conceal it. Steganography is a clever way, which could be used as often within a working UI picture. Then it is possible to use the result of a math operation produced by a Xojo Script itself assembled on the fly from several sources. The on the fly assembly of code has the advantage to remain invisible to a desassembler, and be difficult to trace in a running program. The the password should not be stored in a unique place, but divided in chunks of different size and assembled at the last minute to be used.

That said, if Steve Hill needs the information to perform whatever task is expected from his program, seems to me the data does not have to reside into the app itself. Why not ask the user to register with a password, then use a web service to deliver the encrypted data and use the user password to decrypt. That way the confidential information is at least absent from the app.

You could always return to the user a guid which is a pointer to an image on a web server (with 1000s of different images with different guids) and then use the image converted to a string (as per Mike Charlesworth suggestion) and then encrypt the returned string with the user login name and password. This way you have a user specific one time (out of however many images you have) way of securing the data being returned. So each time a user logs in the software uses a different decrypt key which wont be the same as last time. You could then if you wanted have a seperate routine that runs on the server that every X days grabs a totally fresh set of of images from say Google Images, this would then make it more difficult to break.

Or you could just go and get one of these one time only keys that look like a calculator that the banks use.

And then just like ebay the server gets hacked and you are liable for the loss of personally identifiable information that all your users have submitted when registering. There is no sure fast way to resolve this.

Just out of interest why is the developer needing to store personal information in the app, I am struggling to think of a reason for this in the first place.

He said “confidential”, not “personal”.

Doh, I should have scrolled up…

Damned if you do, damned if you don’t. At any rate, you are convicted of possessing confidential information that you dare want to protect from unscrupulous individuals. But from what I read, the OP does not mention users personal information. So confusing the issue with eBay seems a bit of a stretch…

What sort of confidential information? Text? Images? Mix?

I’m sorry I haven’t responded to those useful suggestions and comments earlier, I had to go away for a couple of days unexpectedly.

The information is text and there is not a lot of it. The problem is that I am building a program allowing a small group of users to store and access transaction data in a remote database, but I don’t fancy putting any sensitive information (like bank card details) in the remote database. On the other hand, the users will need access to that information for secure online transactions.

I thought it might be safer to include that information in the actual programs people would be using, and as we’re talking fairly small scale here, there wouldn’t be anything to indicate to a hacker that there was any sensitive information to be hacked. On the other hand, I need to make sure that people’s bank card details are as safe as I can make them.

If I can’t guarantee the info is safe encoded in a remote database and sent as required, one bank card at a time, to be decoded and used, and if I can’t include the information in the programs, then I don’t know what is best except maybe the users have to carry a third of the information around with them in notebooks, access a third from the database and the remaining third from the programs they are using.

Maybe I’m being too alarmist about it. The amount of work required for a hacker to locate and then extract the information would seem to be hardly worth the effort.

I think you need to be vary careful about what you store as bank details really are something you shouldnt store anywhere and their are strict rules as to what and how you should store things. PCI compliance etc. If it was me then I would ask the user to enter the details as and when they are needed this way you dont store anything anywhere. The other option might be to use some kind of secure electronic wallet service where they users register their details with a trusted third party and then you interface to the wallet system. Never tried that approach but it might work.

Credit card information is exactly what should not be stored in a program for hackers to find.

You could have all orders compiled by a client applications…quantity, item, etc…and forward the orders to a queue where a single piece of software not accessible to any users would do the actual order filing. You do not want to store card info on the server, or in the client software. Embedded into software…a hacker will find it… stored on a server…a hacker will still find it (look at microsoft/xbox and verizon over the last 2 years). If you dare store the info in software, do it in a custom server application that only receives orders, stores the orders to file, and processes the orders, and cannot be logged into or execute any code…only receive orders.

Well thank you all for those comments, you have given me serious food for thought. It had not occurred to me that it might really be so easy to hack into a compiled program and extract encrypted information along with methods for encrypting and decrypting that information. I shall have to rethink that aspect of the project and I hope the discussion has been informative to other Xojo users.

Exe to c will take your application, and decompile it to C++ code :-/ unfortunately where there’s a will there is always a way. Like the great Wizard of the emerald city, you always want to stay behind the “curtain” of secrecy and never let anyone venture to close to the curtain; that they may see behind it…

An analogy that has made sense to me: To encrypt data in an app, in essence you are providing the end user with the Lock, and the Locking Mechanism, the Key, and the Instructions by which to insert the lock into the key and turn it, and expecting that they can’t make use of that to get at your data.

More practically : you want to make the recovery of your secure data more costly than it’s worth. All security is a cost/benefit tradeoff.

You are quite right. At the end of the day, the small transactions envisaged (in a club context) would have been carried out via a secure https connection supplied by a reliable, commercial third party. My only concern was keeping confidential information as secure as possible outside those transactions and I can see now that the concept of burying it inside some software that hackers might get hold of was a very, very bad idea and I won’t be pursuing it. So thank you for all your comments and suggestions. As I’m not pursuing this line of thinking, I won’t keep coming back to this discussion, which has drawn an unexpectedly large readership. But please feel free to continue it if you wish.

Years ago in the early days of the internet we created a standalone server that had no correction to the outside world except via a custom made parallel cable that only allowed data to travel to the receiving device so the bit that was connected to the internet used a custom bit of code that would send the sensitive data via the custom cable to a box that then stored the data for processing internally. This way we new exactly what data we should be getting and no data could pass back to the sending device. The great thing was that we new what data was coming in so were able to checksum and validate that the internal systems had got the right information and if not then we could tell the senders out on the internet to resend it at a later date. This proved to be very secure.

Out of curiosity, for the guys that said to split up the data and spread it around the program, would an efficient compiler not put it all together again?