>>2315699

Below code to generate a diff from the upstream repo to anon's PixelUnknot program.

This is to ease up code review, as we all know, that we shouldn't run code that we can't understand. This should make it easier to understand what anon changed from the original library code.

Tl;dr: this code is not necessary to run PixelUnknot, but it may be helpful to run it in order to see changes and ensure there's no harmful code included. Based on my preliminary audit there's no such code included. This code (not PixelUnknot!) is Unix/Linux only.

#!/bin/sh

git clone https://github.com/banona/PixelUnknot

git clone https://github.com/harlo/F5Android

rm -rf refrepo; mkdir refrepo

cp -a F5Android/src/main/java/info/guardianproject/f5android/plugins/f5/ refrepo/f5

mv refrepo/f5/james/ refrepo/james

rm -f refrepo/f5/F5Buffers.java

cp -a PixelUnknot/src/q/james/*.txt refrepo/james/

diff -waur refrepo PixelUnknot/src/q

>>2328850

For you I made this: >>2316353

With this snippet you can verify that the code hasn't been tampered too much from the original version. For extra security you can run code in a virtual machine or remotely on some cheap VPS server.

>>2316353

Hereby I'm adding instructions how to run the PixelUnknot code on a Unix/Linux machine, because it happened to be quite difficult for me at first.

First, install packages: maven, java-1.8.0-openjdk-devel, bouncycastle (Red Hat, on Debian packages may be named differently)

Clone the repository, open the directory

Edit file pom.xml: after <buildadd <sourceDirectory>src</sourceDirectory>

Execute: mvn package

Execute: java -cp /usr/share/java/bcprov.jar:target/PixelUnknot-1.0-SNAPSHOT.jar q.Main Q4example.jpg passwords.txt

(file bcprov.jar may be in a different location if your distribution is not Red Hat-based. check files in your bouncycastle package)

>>2301393

This isn't the correct image. PixelUnknot crashes on this one.

This one is correct: https://i.4pcdn.org/pol/1532237608528.jpg as referenced by >>2304030

SHA1SUM: f1335a1095a3ae15094e0a09e1cb83e5679dda26

>>2331140

The example file included matches just "plan". I would kind of want to optimize the PixelUnknot source code.

diff –git a/src/q/Main.java b/src/q/Main.java

index 9954f97..ab94435 100644

— a/src/q/Main.java

+++ b/src/q/Main.java

@@ -132,14 +132,14 @@ public class Main {

Files.readAllLines(filePath, StandardCharsets.ISO_8859_1)

.parallelStream()

.forEach(line -{

• for (int j = 0; j<line.length() - 2; j++) {

• String l = line.substring(j);

• //for (int j = 0; j<line.length() - 2; j++) {

• //String l = line.substring(j);

// System.out.println("trying " + l);

• int res = extract(coeff, l);

• int res = extract(coeff, line);

if (res == 1) {

System.exit(1);

}

• }

• //}

});

}

}

What has changed? Now, our password file contains only the 1/3 suffixes, for example "plan" and so we check only "plan", before that optimization, for a line "trusttheplan" in the password file we would check "n", "an", "lan", "plan", …, "rusttheplan". The problem is, that with the original code suffixes like "a", "b", "c" get checked too often.

I'm now trying all strings of a form [a-z]{4}.

>>2331362

Are we checking the image Q uploaded, or the image "Sarahposter" uploaded at 4chan? I'm checking the second one.

>>2331362

This is the Q-original.

SHA1SUM: 4cfbe7be8d8dd07dcb298fda493b80947db5c91e

This one isn't: >>2331454

Picrel is the "Sarahposter"-original. Should be:

SHA1SUM: f1335a1095a3ae15094e0a09e1cb83e5679dda26

>>2331537

Forgot the picrel. It's in this post actually: >>2301393

>>2331580

Yes, we should use SHA256 as it's what 8chan uses for filenames.

5A7F006BC6398E644EC960D83A9E36F04BE80E96BB4A48082D18042FE55993CD

This is the "Sarahposter"-original.

fabd30ac56bac002df63a0e6961c10eb5c307e6aadb91743306fa217bbd6fe49

This is Q-original

Incidentally, the original Q image is named:

3930a76b2028bf79781986862c68c6bfd3e36bd727f7c2dd8e14c5cc702aae34

So let's do an experiment: does 8chan rewrite images upon upload. The images I will upload now should have the following SHA256 checksums:

286e0495d8feaa363a2060471064e41662cdeea6e53c023cca89dfb2a0e57c0f test2.png

2c1efa6ceef7e02ece13f538b1234b4cc52d09cad3b471994037f417d7bd5872 test.jpg

d695fab6d2dc8fd1417723a014712925a99fbd1beafa1aec08fd71aed8c0f7bb test.png

If they don't match, they got rewritten on the fly.

>>2331713

Incorrect. They got rewritten:

886094e3f5ddc2aeab88c295b7d9b5529272af8a271bff1068d1734612d28f15 286e0495d8feaa363a2060471064e41662cdeea6e53c023cca89dfb2a0e57c0f.png

874087581dc97a9f447bb4f8aef9d72d8d1d6817b25bbee1b2f45b78a416caa4 2c1efa6ceef7e02ece13f538b1234b4cc52d09cad3b471994037f417d7bd5872.jpg

886094e3f5ddc2aeab88c295b7d9b5529272af8a271bff1068d1734612d28f15 d695fab6d2dc8fd1417723a014712925a99fbd1beafa1aec08fd71aed8c0f7bb.png

test2.png was constructed by appending some data (that happen to be test.jpg) to test.png. 8chan dropped the extra data, so test.png equals to test2.png. What if I upload them again?

>>2331785

They are intact now. So I guess 8chan drops metadata, but after they are rewritten by 8chan and reuploaded, they stay intact.

>>2331831

Ok, I tried downloading with the "download with an original filename" link and it's how you can ensure you will download the original file and not a rewritten one (not really - I don't know how it works).

This is the original Q checksum, as denoted by the filename:

3930a76b2028bf79781986862c68c6bfd3e36bd727f7c2dd8e14c5cc702aae34

I managed to download the original, but I can't recreate it anymore. Pic related, you may have some luck clicking on the (h), (u) buttons.

Not that we should focus on this image, but on the "Sarahposter"-original. Just be aware, that 8chan rewrites images.

>>2332051

Ok, I know now. This is how you can download the Q-original image:

https://media.8ch.net/file_dl/3930a76b2028bf79781986862c68c6bfd3e36bd727f7c2dd8e14c5cc702aae34.jpg/typeheresomethingrandom.jpg

Make sure it's random, so you don't get the modified 840e56f8babf0c9d8292f73d7ca34f00dfbb741c338aed0859a7ca80590eca80 file.

>>2332171

It rewrites both, but not on the first access.

>>2331831

Yes anon, you are right. Your image in >>2301393 is actually correct, just make sure to check the checksum later on. For reference, it's: 5a7f006bc6398e644ec960d83a9e36f04be80e96bb4a48082d18042fe55993cd . I didn't intend to muddy the waters, but I actually did. But at least make sure to check the SHA256 checksum before trying to crack. Use this method for best results in downloading the original file: >>2332232 or download from 4plebs: https://i.4pcdn.org/pol/1532237608528.jpg

>>2332344

>>2332368

You are both wrong, unfortunately. See pic related. You need to get a random link as described here: >>2332232

>>2332416

You got the right files because you were the first to download them. See pic related. If you try to download them now, they will be cut. But I think we don't need to derail the thread more, I will report the issue on /sudo/ in a moment.

>>2332419

Ty anon, I can confirm the sha256 checksum of the file still served by 4chan on https://is2.4chan.org/pol/1532237608528.jpg to be 5a7f006bc6398e644ec960d83a9e36f04be80e96bb4a48082d18042fe55993cd as expected.

>>2332748

I repeated my results from another ISP (HTTPS hijacking? That would be interesting). For the record, changing from curl to wget did not trigger getting the original file. You don't look like a Tor user though, so I don't really know where's the culprit.

>>2332809

>>2332850

I checked it out and yeah, that's not a result.

>>2330157

Nice find. I stumbled across the same now. I found 3 files in my research that have this "CDEFGHIJSTUV…" string.

First one is Q4example.jpg (OP's image)

Second one is 5a7f006bc6398e644ec960d83a9e36f04be80e96bb4a48082d18042fe55993cd (SS image)

Third one… is 3930a76b2028bf79781986862c68c6bfd3e36bd727f7c2dd8e14c5cc702aae34 (Q's image)

It probably means that all 3 were generated with the same image generation library. Which could be the Java generation library. And that could mean, that while we know that the first one has some obfuscated data… Q tells us the second has as well… But he himself probably embedded a message too :) Or not. Just make sure you get the rare original file.

>>2351079

One protip: The pseudorandom function will have the same seed for all those images. You could in theory speed up the search by caching the generated random values, same with individual image coefficients, moving the problem from O(m*n) to O(m+n) (where: m - number of images, n - number of passwords to check)