I've been looking through the source code for Pixel Knot and I found that it has a default password.
public final static byte[] DEFAULT_PASSWORD_SALT = new String("When I say \"make some\", you say \"noise\"!").getBytes();
If it was intended as a direct comm to Q then they would not have made things difficult for him.
Silly question: Has anyone tried not imputing a password and letting it go to defaults?
Opps, wrong line.
Anyway, it looks like it has the option to run without a password. I haven't installed in in a sandbox yet, but was wondering if anyone bothered to try the obvious.
private String getPassword() { if(!hasPassword()) { return null; } return extractPassword(mPassword); } private byte[] getPasswordSalt() { if(!hasPassword()) { return Constants.DEFAULT_PASSWORD_SALT; } return extractPasswordSalt(mPassword).getBytes(); } private byte[] getF5Seed() { if(!hasPassword()) { return Constants.DEFAULT_F5_SEED; } return extractF5Seed(mPassword).getBytes(); }
The only way we are going to crack this thing is by reimplementing the F5 algorithm in something faster so we can make intelligent guesses quicker or simply brute-force it. I found the Java library used:
https://github.com/guardianproject/F5Android
I don't know Java. So it's going to mean a bit of monkey-see-monkey-do if I'm going to port it to C.
I know what I'm doing this weekend. :)
I found a way to modify the PC version of this to test is a password is correct. It won't decrypt it. If you happen find the right password you'll still have to use the app to decrypt.
First down load the PC version,
https://code.google.com/archive/p/f5-steganography/
Unpack the JAR file and change line in /main/Extract.java from,
final F5Random random = new F5Random(password.getBytes());
to
final F5Random random = new F5Random(password.substring((password.length()/3)*2).getBytes());
This will cause it generate the F5 seed the same way that SteganoDecryptionJob.java in the app does it.
Then recompile the java using "javac Main.java" in the top level directory and then either repack the JAR file or call it directly from the command line like,
java Main x -p "passphrase" imagefilename.jpg
It will dump the result into output.txt. If it is the wrong passphrase it will give an error like "Incomplete file: only 0 of 123456 bytes extracted" (or it sometimes spits out some garbage). If it is the correct passphrase it will NOT give this error and the output file will be base64 starting with "—- PK v 1.0 REQUIRES PASSWORD —-"
It runs in about one second. And I could post a shell script to test whole lists of passphrases… but it's time for me to go to bed.
No, there is no easy way to tell if the image has a hidden message. That is a design goal of steganography. But if there is a fairly large payload relative to the carrier image size then it's possible to detect it statistically. We don't know that there is actually anything there. We don't even know it this is the correct program or if Q was linking to it as a generic example of stenography.
The designer of this app did some really stupid things. First, the stegano layer only uses 2/3rds of the password. This obviously makes it easier to bruteforce. And if your big computer goes "ding!" to spits out 2/3rds of a natural language password then a human can probably guess the remaining third. The same password is used for the encryption. The second dumb thing he did was have the message start with the same sentinel string every time! And this is OUTSIDE the AES encryption layer. The F5 algorithm for distributing the message bits is probably not very cryptographically secure. Bruce Schneier would be mortified (then he'd break down in hysterical laughter). And what is the point of the bas64 encoding layer?
So we have a 6,000 year old global cabal putting there lives (literally) in the hands of some toy crypto program they found in the Google Apps store and expecting that to protect them from the mighty power of the NSA. These People are Stupid™.
The app Q linked to does not have a public-key crypto option. I noticed a mention in the GitHub notes of the app author's plan to add that. But currently it's symmetric password-based encryption only.