> at some > point the encrypted SQL wiill have to be decrypted before SQLite > interprets it.
Perhaps we could achieve some level of obfuscation by "pre-preparing" at compile time the set of all statements that the program uses, and storing the SQLite prepared statement objects in the program image. Then you'd just do argument binding at run time. That is, you are more-or-less storing the query plan instead of the SQL. I guess you'd have to make a bunch of assumptions about the db schema, the boundedness of your universe of queries and the like, and perhaps have to hack a few values into some relevant structs -- I'm not enough of an expert to know the extent of it. Would something like that be workable? Again, even if it is workable, it won't stop a sufficiently motivated and skilled reverse engineer. There are people employed at e.g. Symantec whose entire job is to figure out what a program does, despite the efforts of world-class adversaries to obfuscate it. They would probably think my above suggestion is adorable, and crack it during a donut break. In order to evaluate suggestions coherently, we'd really need to know what threat you are trying to mitigate. Eric
