A recent app is local and the data source comes from a local. json file, which is the soul of the app. Recently released the app, very worried about after the release of the. IPA package was untied by competitors and then information leaks. My processing strategy is: When the package is placed in a string of encrypted JSON file, even if others open is garbled. The file is decoded when the program loads, a decoded JSON file is generated inside the sandbox, and the temporary file is deleted when the program exits. This ensures that the data is protected to some extent without affecting existing code. Computer has a point of failure, at hand with C + + in Windows implementation of a file first with TXT, encryption algorithm first with a simple ASCII shift. When you really want to use the same, the encryption algorithm can be used MD5:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
#include "stdafx.h" #include <iostream> #include <fstream> #include <string> using namespace
std;
#define KEY 1
int _tmain(
int argc, _TCHAR* argv[]) {
string oneLineStr;
ifstream inf;
inf.open(
"ReadMe.txt"
);
ofstream outf;
outf.open(
"encode.txt"
);
ofstream outf_recovery;
outf_recovery.open(
"recovery.txt"
);
while (getline(inf, oneLineStr))
{
cout<<
"加密前:"
<<oneLineStr<<endl;
size_t length = oneLineStr.size();
for (size_t i = 0; i < length; i++)
{
oneLineStr[i] = (
char
)(oneLineStr[i] + KEY);
//ascii码改变
}
cout<<
"该行加密后:"
<<oneLineStr<<endl;
outf<<oneLineStr<<endl;
}
outf.close();
inf.clear();
cout<<
"开始恢复文件============================"
;
ifstream inf_encode;
inf_encode.open(
"encode.txt"
);
while (getline(inf_encode, oneLineStr))
{
size_t length = oneLineStr.size();
for (size_t i = 0; i < length; i++)
{
oneLineStr[i] = (
char
)(oneLineStr[i] - KEY);
//ascii码改变
}
cout<<
"解密后:"
<<oneLineStr<<endl;
outf_recovery<<oneLineStr<<endl;
}
inf.close();
inf_encode.close();
outf_recovery.close();
int tmp = 0;
cin>>tmp;
return 0; }
|
Of course, there's a flaw in this approach, which can be a bit time-consuming for very large text files, but it's almost impossible to feel under normal circumstances. I wonder if there are any better ways to protect the text and picture resources within the app package.