unforum

[LilSerf]

Re: outguess

[mmdoogie]

Roc: glad I could help.

Well...
I've tried somewhere near 2 billion distinct keys with length 20 or less,
and nothing yet... thats not even a dent in the 4.42*10^39 total
possible keys...

I'm going to let it keep running, but I think we are going
to need distinct information if we were meant to decrypt this file.
It could just be a false positive too...

--mrm

[Paul_G]

Just to keep this discussion from going completely trout:

1. All of the suggestions for passwords that have been suggested here so far have already been tried in many different variations. There is no need to try these passwords again.

2. stegbreak is the fastest way to try to crack JPHIDE files. In essence, it takes all of the words in the dictionary file that you feed it and tries them all as the password. Using JPSEEK to type in passwords by hand is several orders of magnitude slower. In the time it takes to open the file in JPSEEK, you can run tens of thousands of attacks with stegbreak. I have run over 2 million since I started typing this post.

Now some new notes after creating my own steg and doing some experimenting with JPHIDE and stegdetect/stegbreak:

1. The closer the hidden file's size is to the size of the "cover" file, the easier it is for stegdetect to pick up (i.e., bigger hidden files are easier to detect). Default sensitivity seems to pick up "medium" sized files very well. A three-star rating at default sensitivity indicates an extremely strong likelihood that there genuinely is a file buried in the image.

2. As an experiment, I tried JPHIDEing a file with a passcode that had a space in it ("gum bo"), then running a dictionary attack using some of the word lists I tried yesterday. The attack failed. This demonstrates how easy it is to make a password very strong against dictionary attacks, which is one more reason why we should probably cool our heels for now and wait for more info.

I am becoming more convinced that there is something hidden in the picture, but I am also becoming more convinced that we're going to need more information before we can crack it.

[Roc]

I've been wondering about stegbreak, so I hid a trivial text file (1k) in a different image. (first 8kb bee img GIS gave me) I then hid a trivial text file in bee2_margaretphoto.jpg

stegdetect gave me a negative result on the result from jphide-ing in the new img, and gave a 'false positive likely' on the result from jphide'ing in bee2_margaretphoto.jpg

I put the passphrase I used: survive evade reveal escape in my dictionary file and removed all the rules except ':' (try the entries 'as is')
stegbreak gave me no hits from either image, yet jpseek directly had no problem spitting out the embedded text when given the right passphrase.

Furthermore, stegbreak said it tried 978 keys, yet my dictionary has 502 lines, and a total of 1107 'words'.

So what's goin on with this tool?

EDIT: clarrification: My intention was for stegbreak to try each line in the dictionary file as a discrete passphrase. Clearly it's not doing that, could anyone tell me how I can make it behave the way I'd like?

[linuxfan]

[Paul_G]

Rules.ini syntax guide

[Roc]

Right, so I've removed every phrase from my dictionary, save the known good passphrase for a test jpg that I downloaded and jphid a text file in.

jpseek has no problem extracting this text file from the jpg when given the passphrase.

stegdetect reports

[Paul_G]

looks like stegbreak truncates lines in the dictionary file to 16 characters, or else can't break passwords that are longer than 16 characters.

breaking a file that had been stegoed with password "surviveevadereve": successful

breaking a file that had been stegoed with password "surviveevaderevea": failed

[accidentalsuccess]

maybe the hidden file is spyder? hrmmmmm. ... . .

very interesting stuff

[Roc]

[halofan]

maybe the differences in those recipees hold a clue as to the password?

[quackquack]

That's a good idea... i noticed one of the links on the pages reading "hide and seek" led to recipe2.html. Is there a thread anywhere discussing the differences outlined in the wiki? I can't seem to find one.

[AnthraX101]

[Roc]

Well, the 16 character thing led me to solve 2 frustrations at once.

First, being unable to break my known stegged image.
Second, being unable to get the syntax commands to address characters past the 9th position.
E.g. the rule syntax 'N truncates the given phrase after the Nth character. using '10 throws an error.

Turns out the rules index pass phrase positions in Hex.
If you want to strip all your alphanumeric dictionary terms that are longer than 16 characters, down to 16 characters, you'd have to add the rule:

[Paul_G]

Well, if nothing else, I've taught myself a ridiculous amount info about steganography, JPHIDE/JPSEEK, SNOW, and stegdetect/stegbreak over the past two days

This has also taught me exactly how much difference a "strong" password can make when protecting your data.

I say we concentrate on trying to find passcodes buried elsewhere in the site, since dictionary attacks get very intractable once you have passed a certain number of possible characters. I think that any more effort in that direction will just be a waste.