OpenCL support for cracking Android Backups

[kholia]

Current speed,

$  ../run/john --test --format=androidbackup  # i7-7820HQ
Will run 8 OpenMP threads
Benchmarking: AndroidBackup [PBKDF2-SHA1 256/256 AVX2 8x AES]... (8xOMP) DONE
Speed for cost 1 (iteration count) of 10000
Warning: "Many salts" test limited: 6/256
Many salts:	5389 c/s real, 727 c/s virtual
Only one salt:	5251 c/s real, 713 c/s virtual

$ ../run/john --test --format=androidbackup-opencl
Device 2: AMD Radeon Pro 560 Compute Engine
Benchmarking: AndroidBackup-opencl [PBKDF2-SHA1 AES OpenCL]... DONE
Speed for cost 1 (iteration count) of 10000
Raw:	26425 c/s real, 3276K c/s virtual

@magnumripper Hey, how do I get the format to emit GPU utilisation figures automatically?

[kholia]

The nelenkov/android-backup-extractor#57 (add support "MIUI BACKUP" magic header) idea looks interesting as a future enhancement.

However, I don't have a Xiaomi device and MIUI backup app won't install on a regular Android device.

[kholia]

The following patch should do the trick for Xiaomi-MIUI backup,

diff --git a/run/androidbackup2john.py b/run/androidbackup2john.py
index 2e30bd6a7..8bebefe08 100755
--- a/run/androidbackup2john.py
+++ b/run/androidbackup2john.py
@@ -46,6 +46,15 @@ def process_file(filename):
     """
     with open(filename, "rb") as f:
         magic = f.readline()
+
+        # Untested hack for "Xiaomi-MIUI backup"
+        while True:
+            line = f.readline()
+            if not line:
+                break
+            if line == BACKUP_FILE_HEADER_MAGIC:
+                magic = line
+                break
         if magic != BACKUP_FILE_HEADER_MAGIC:
             sys.stderr.write("[!] Magic missing from file, is this an Android Backup?\n")
             return

Update: A modified version of this patch is committed now.

[kholia]

On super,

$ ../run/john --test --format=androidbackup-opencl
Device 6: GeForce GTX TITAN X
Benchmarking: AndroidBackup-opencl [PBKDF2-SHA1 AES OpenCL]... DONE
Speed for cost 1 (iteration count) of 10000
Raw:	90187 c/s real, 90187 c/s virtual, GPU util: 99%

This OpenCL runtime reports GPU utilisation just fine.

[magnumripper]

@magnumripper Hey, how do I get the format to emit GPU utilisation figures automatically?

It should just work (under Linux) provided device is supported (nvidia or AMD). I have no means of maintaining the AMD stuff - if they changed something from the ADL we're using, we're not supporting it.

Windows support should be easy to fix, although I refuse to touch that shite so someone else has to. Unfortunately macOS doesn't seem to support any sensor queries.

[kholia]

@magnumripper Ah, I see. Thanks! Yeah, I was running macOS for the first set of benchmarks.

[magnumripper]

Are you sure this will not result in false negatives?

[kholia]

We also have the if (check_pkcs_pad(out, length, 16) < 0) call above it.

I believe that with these two checks we have ensured that last 9 padding bytes of the decrypted text should be the same. This should be good enough, right?

[magnumripper]

What I meant is: Are you sure there can't be a valid padding of 8 or less? Why is that?

[kholia]

My bad, I missed reading the false negatives word correctly.

I have added the following comment to the code regarding this.

// The structure of masteykey_blob is fixed:
//   + masteykey_blob -> length_1 (byte) + IV (16 bytes) + length_2 + masteykey (32 bytes) + length_3 + checksum (32 bytes) => total of 83 bytes
//   + padding -> this data blob of 83 bytes gets 13 bytes of padding making the masteykey_blob_length = 96 bytes always

[kholia]

This implies that padding is always 13 bytes in practice.

[magnumripper]

Perfect!

[magnumripper]

"Just" for autotune? An incorrect figure here will result in suboptimal autotune. Since all of your test vectors seem to use 10000 I'm guessing that figure should be here as well.

[kholia]

Ack. Fixing now.