I have a 1MB text file which the program uses, when opening, to provide data for the program’s use. It is read into a text variable on opening. This operation is very fast. No notable delay on opening the program.
Now I would just as soon that users of this program did not have “easy” access to the text file independent of my program so I would like to at least obscure it. It is not an issue that requires military grade security. Just trying to discourage an amateur hacker. The 1MB file is UTF8 text with many Japanese characters so it is not just simple ASCII text.
This is a static piece of text that does not change with the use of the program. I would like to encrypt it with my program “knowing” the password so that when it was imported on opening the program it would decrypted within a couple secs. Is this realistic? And how would you do this?
When I look at the crypto functions of Xojo, they are confusing to me and I am not sure that they are intended to encrypt a large (1MB) piece of text. Maybe I am wrong.
One thought that I had was to create an SQL database with basically one record and one field that was this 1MB text file. I would encrypt that database and decrypt it within the program to get access to the 1MB file? Is that a crazy “indirect” approach to a problem that would be simply solved by some easy way of encrypting and decrypting a 1MB text file?
Interesting timing. I’ve just written an article describing an “obfuscation” method for the next issue of xDev, which comes out on Monday (May 2nd).
The problem with actual encryption is that your program needs the key to decrypt it, so then you’re having to obfuscate the key somewhere in your program… might as well just obfuscate the text file if you don’t need it to be super-secure.
Take that encrypted data & put it in a constant inside your application
That way it’s compiled in instead of being in a separate file
Then you decrypt it at app start up to load the data
This will stop most simple “hacking”
I had not thought of simply putting the static 1MB file into the program itself as a text file. That is actually “enough” security for my purposes even if it sits in there unencrypted. And it makes it easier for the user because there is one less file to deal with. It probably violates some principle that you should not have “data” in your code, but in this circumstance it might work for me.
When I just try it this morning it does not quite work for some mysterious reason, but I will work on this in a few days when I come home from a trip. I am intrigued, but I have to leave for this small trip
I am surprised by this because I was originally just importing the data into a variable in the program. To test the Constant approach, I just pasted the 1MB file into a Constant in the IDE and then altered the code to copy it into the same variable to see if it would work. For some reason it does not. Self.xInfo is the variable (property). It has plenty of return characters,
[quote] Dim axOneLine() As Text
axOneLine = Self.xInfo.Split(CR)[/quote]
That line does not work when Self.xInfo has simply had its contents transferred from the Constant.
The variable is large enough that I cannot effectively see it in the debugger. The wheel starts spinning endlessly.
Anyway, with a little time, I should be able to study this and get a notion of what is happening.
But I am going to look into the other suggestions made because then I will learn something about encryption. Both the Tekinay and MSB.
Look forward to the obfuscation article in xDev. Thanks all.
Right, I was being proactive. But I should have mentioned ReplaceLineEndings if available.
If ReplaceLineEndings is not available, that’s the only way to do it. Even EndOfLine is not available. Again, I should have mentioned that.
Same as above.
The codepoint used is not important, just as it wasn’t in the other thread. It doesn’t matter if it’s native to the particular platform or not since it’s being used for Split exclusively. (cc @Tim Hare)
Its not obvious nor easy to read
&u0D &u0A are not obviously “end of line” alone or together
A constant would be nicer
And direct support for “something” in the framework even better
Not sure if that would land in System or something like Platform
Either way - we experience these same issue so we do have lists of things we’re considering adding but they need consideration & discussion rather than just toss everything in
The new framework has a few interesting features not found in classic framework, such as Xojo.io.SpecialFolder.GetResource, Timer CallLater, Text support for composite glyphs, HTTP 1.1 with Xojo.Net.HTTPSocket.
Unless you are developing for iOS where the classic framework is absent, I see very little reasons to switch entirely to the new framework. I tend to use the new framework as needed, when classic would not do. Besides, sometimes it is not implemented, such as in Web where Xojo.io.GetResource is not here, as I found out last week.