The attack and prevention of Sqlcipher

On the mobile side, whether it's iOS or Android, the most common local database for developers is non-SQLite. SQLite is a lightweight, cross-platform, open source database engine, its advantages in reading and writing efficiency, total consumption, delay time and overall simplicity, making it the best solution for the mobile platform database.

However, the use of SQLite to save some of the information is not very sensitive can be accepted, storage of sensitive information is debatable, the free version of SQLite information is stored in plaintext, you even directly with a text editor open can see sensitive content, such as the following:

In fact, SQLite is provided with encryption function, that is, SQLite encryption Extension (see), but to charge! It's not cheap, 2000 knives. Yards farmers poor ah, so we find free solutions, eventually Sqlcipher became a more ideal choice, because it is free, open source, and other home sqliteencrypt, Sqlitecrypt, etc. still have to charge.

Sqlcipher also has a fee version, but the fee version is only in the integration, dependency and other ease of use has the advantage, function and free almost, so the free version of the Sqlcipher became the coder choice of objects.

Sqlcipher uses the whole database file encryption strategy, using 256-bit AES encryption, from the algorithm point of view is quite strong. So, the encrypted file looks like this in time:

Full of heavenly book, OK, you can wash and sleep. But is it really safe? Oh.

001. To seek an offensive article

There is a more classical word in cryptography: All secrets are in the key. As soon as we get the key, the rest of the problem is not a problem. Let's analyze the Sqlcipher key and encryption process. According to the official description, Sqlcipher is the overall encryption scheme:

Transparent–an application doesn ' t require any special knowledge of the underlying database security. Applications use the standard SQLite API to manipulate tables using SQL. Behind The scenes The library silently manages the security.

On-the-fly–sqlcipher encrypts and decrypts in chunks called pages, as needed, so it doesn ' t operate on the database all At one time. This means SQLCipher starts up and closes off quickly performs very well even with very large databases works with SQLite Indexing (i.e. retrieving a single record using an indexed search can incur as little as 5% overhead above a standard SQL ITE database)

It does not encrypt the table or column, which means that his database key is only one, which is the key.

Sqlcipher is used on iOS:

1) Add sqlite3.h and SQLITE3.M to the project;

2) Connect to the database using the following code:

The key is the one we need! The key is then associated with the database through the Sqlite3_key function, and the SQL statement operation is then performed. The programmer must feel good, add two lines of statement to complete the encryption function, directly copy the official code into their own project, the "StrongPassword" into their own key. Real easy Ah, then I attack also very easy.

In general, dealing with this level of encryption requires only static analysis. For iOS programs, drag the program to Ida, find the Sqlite3_key function related reference address, the basic is done. Here is an application that locates the function in the Setkey method, which is called in its data open method, and you can see that the password for the database is hard-coded in plaintext (the red part of the image).

There's a lazy way to get the password. You can open the encrypted database directly: using Sqlitemanager, it supports Sqlcipher encrypted database, will prompt for the database password, do not need to write programs, and browsing data is also very convenient.

For Android version of the program, if not shell, it is also very good analysis. Android calls Sqlcipher using the following method:

The second parameter of the Openorcreatedatabase method is the key. The corresponding database key can be touched by searching for related methods in the code that Jeb compiles.

Here the programmer may want to think, I do not hard code to see you, I am in the code after subtraction, XOR or after the key is calculated, or more ruthless with the user password and other dynamic decryption transformation, the key will not appear in the program.

But the attackers still have more than n tricks to play, such as dynamic debugging, in the input key of the method entry break point, the key clear text interception. There is hook technology, for Android applications, we can use Cydiasubstrate, using the Ms.hookclassload method to hook the openorcreatedatabase:

public class Main {

static void Hookcryptokey () {

Ms.hookclassload ("Net.sqlcipher.database.SQLiteDatabase",

New MS. Classloadhook () {

public void classloaded (Class arg0) {

LOG.D ("Myhook", "##### Class Loaded");

Method openorcreatedatabase;

try {

Openorcreatedatabase = Arg0.getmethod (

"Openorcreatedatabase",

New class[] {file.class, string.class, SQLiteDatabase.CursorFactory.class});

} catch (Nosuchmethodexception e) {

Openorcreatedatabase = null;

LOG.D ("Myhook",

"##### Unable to Find method");

}

if (openorcreatedatabase! = null) {

LOG.D ("Myhook", "##### Found method");

try {

Final MS. Methodpointer old = new MS. Methodpointer ();

Ms.hookmethod (arg0,

Openorcreatedatabase,

New MS. Methodhook () {

public object invoked (object arg0,

Object ... args)

Throws Throwable {

LOG.D ("Myhook", "##### Error:" + thread.currentthread (). Getstacktrace ());

LOG.D ("Myhook",

"###### Method hooked, stealing key:" + args[1]);

Return Old.invoke (arg0, args);

}

}, old);

} catch (Exception e) {

System.out

. println ("# # Unable to find class");

}

}

}

});

}

static void Initialize () {

Hookcryptokey ();

}

}

This code can hook up the Openorcreatedatabase method and print the second parameter key in the log, ignoring how much you have been hidden and transformed. As for the use of substrate here is not detailed, you crossing can refer to the online information. Of course, you can also try other hook frames, such as xposed.

The programmer may not be convinced, I can also on the shell, on the iOS side I can also be confused, LUA dynamic online loading and other means AH? However, this seems to be beyond the Sqlcipher offensive and defensive site, is the program of local protection of the large category, have the opportunity to study again.

002 Anti-

Write here, in fact, the local database encryption is frustrated, this is completely put the door lock and key together, no matter you on the local any soft means (hardware, if your keys, algorithms are placed in hardware, such as usbkey, security should be in the nature of Ascension), Whether it is a simple transformation or confusion, shell, anti-debugging, anti-hook, are not to be broken by attackers, but more or less to delay the time to find the key.

Therefore, it is recommended that you do not use local database encryption such as Sqlcipher, except in the following cases:

Non-sensitive data, love how to use

User's own data, can use the user password, fingerprint and other means of direct or indirect protection, because in this case key is actually with the user walk, you can do key and algorithm, data separation

Other recommended data are placed on the service side of the app, which will thin the client and focus security on communication and service-side protection.

The attack and prevention of Sqlcipher