I think C# Anon is going to have an issue with SecureRandom(). They won't be the same on .NET vs. JAVA, I'm running into this issue as I'm porting the JAVA code to JS.
I can call JAVA code from JS, but I want all this to run client side browser.
Actually, if people are using different OS other than Android for trying passwords it probably won't work correctly.
I think there was a change in Jellybean 4.3, where the underlying SecureRandom was changed. If this is the case, if the image F5'd with pre 4.3, it may not work correctly 4.3 and greater. I'm guessing these people are using burner phones for all this.
What a mess, and we probably don't know if Q uses f5, but I think iOS is used.
We should probably consider using this impl:
https://android.googlesource.com/platform/libcore/+/android-5.1.1_r37/luni/src/main/java/org/apache/harmony/security/provider/crypto/SHA1PRNG_SecureRandomImpl.java
I hope that this will eliminate some concerns in regards to Android versions of these pedos.
Either I don't have the correct image, but I don't think that SS image has anything in it.
I ran this against jumping comey image >>2336293 and it detected stego.
Comments like this are concerning…
https://stackoverflow.com/questions/13433529/android-4-2-broke-my-encrypt-decrypt-code-and-the-provided-solutions-dont-work
https://stackoverflow.com/questions/39097099/security-crypto-provider-deprecated-in-android-n/42337802#42337802
So I think it's going to be an uphill climb given that we don't know what version of Android the OG images were created with.
I think burner phones are pretty much a given, and with that in mind we mind have lower version of Android (typical with cheap phones).
WOW, this is great…
I was right about the SS image then.
BTW - I was using a tool called autosteg, which uses the same F5 lib, and will encode a folder of images with a given password. The one thing it will do is detect F5, it didn't detect F5, but it did detect it for the jumping comey pic.
One thing that's concerning that gets back what I just recently said, I built PixelKnot app, and encoded my own image, and it didn't detect it, but it does have the JFIF tag in the image. I need to dig some more on why that is.
I got it wrong then, so if it's JFIF it's a normal image, and it's been PK'd then it's gone.
#
# Sun Provider SecureRandom seed source.
#
# Select the primary source of seed data for the "SHA1PRNG" and
# "NativePRNG" SecureRandom implementations in the "Sun" provider.
# (Other SecureRandom implementations might also use this property.)
#
# On Unix-like systems (for example, Solaris/Linux/MacOS), the
# "NativePRNG" and "SHA1PRNG" implementations obtains seed data from
# special device files such as file:/dev/random.
#
# On Windows systems, specifying the URLs "file:/dev/random" or
# "file:/dev/urandom" will enable the native Microsoft CryptoAPI seeding
# mechanism for SHA1PRNG.
#
# By default, an attempt is made to use the entropy gathering device
# specified by the "securerandom.source" Security property. If an
# exception occurs while accessing the specified URL:
#
# SHA1PRNG:
# the traditional system/thread activity algorithm will be used.
#
# NativePRNG:
# a default value of /dev/random will be used. If neither
# are available, the implementation will be disabled.
# "file" is the only currently supported protocol type.
#
# The entropy gathering device can also be specified with the System
# property "java.security.egd". For example:
#
# % java -Djava.security.egd=file:/dev/random MainClass
#
# Specifying this System property will override the
# "securerandom.source" Security property.
#
# In addition, if "file:/dev/random" or "file:/dev/urandom" is
# specified, the "NativePRNG" implementation will be more preferred than
# SHA1PRNG in the Sun provider.
#
securerandom.source=file:/dev/random