yeo / Blog: Recent posts

Functionality remains the same
- replaced JPG handling code with a neater wrapper for JPG file data
- think i changed the helpfile somewhere (typos etc)

busy preparing for a wxWidgets port that will be able to store and display / modify svg data in a simple annotation pane. (only lines, arcs, text maybe)

that would enable drawing / viewing of diagrams to accompany the text.
also would put the code in a more portable framework and add a nifty GUI.... read more

• cleaned some of the code up (removed irrelevant comments)
• added burn support to PNG messages
  next i will mess around with it a bit aimlessly to check everything works always etc.,
  and see if i can clean up the code to e.g. use a swish wrapped-up class thing for JPGs like i did
  with PNGs. stuff like that.

where this is going:
i want this to remain a short-message thing with some plausible deniability (so to use file-types people often post publicly, not leaving data traces on machines etc - so no plaintext FILES)... read more

So now we (me and my imaginary friends i send encrypted messages to) can handle both compresssed image types commonly used by most people.
since this is for communication, i am not going to include bmp support (there are lots of projects offering bmp support only - can't see why someone would be emailing / uploading bmps nowadays though...)

i am thinking the steganography works a bit better in jpgs, as LSBs would be closer to random in their compression vectors - for a realistic message length, data should be pretty invisible in pngs too, as there are so many valid data pixels to hide things in (we always scatter data across the entire image, so a short image could very well make no statistical difference to an image's LSBs, and there will be no systematic between different parts of the image, as the entire image is used for data hiding - costs us a lot of speed, but i think it's important...)... read more

added message compression, while in the process of adding PNG support.

since libpng claims to require zlib, i went about getting zlib to work for me first.
which was surprisingly easy...

so since i have zlib working, i decided to compress the message string before encryption
(a legacy option is still available to encrypt / decrypt without compression)

that should increase the capacity of images significantly, and may affect security in a positive way for 3 reasons:
- the message is shorter, so were there to be a weakness in the encryption (aes256), one should have less opportunities to exploit it.
- the plain text won't be looking like plain text, so it may be harder to brute-force it with some software looking to recognise text.
- the message is shorter, so there is less change to the carrier image, which should make modifications harder to detect statistically.... read more

so i have been thinking (bad idea...)
png files are also cool, cos people realistically use them to send dense images around, as they use lossless compression (nobody sane emails bmps and tiffs around anymore. am i wrong? if i am then tell me so i can fix my logic). and it is an opensource file format.

so it's doubly cool.

so next would be png files...

hope not that's an issue for anyone. thing is hosting flvs seem to be a specialised thing anyway, which means all your stuff will be at youtube or something, and you actually need a browser plug-in to access the message conveniently, which means you are exposed on a network when dealing with stuff you want quiet, which is a bad idea... ... read more

OK so here's where i think this thing is going next:

• add some functionality to enable reading and wiping of messages in one move
  for coolness / paranoia value. at this point i'm more thinking how that will
  mess up the user interface than how to do it. implementation will be really easy application side actually...
  this will happen next probably, as it is easy.
• once i'm done wasting time, i want to add functionality to hide messages in flv files.

i've been reading the easy places, and it seems that flvs contain mp3 audio streams.
i've seen some projects that use mp3 stegaography, in i'm guessing it's very similar in principle to jpgs, so i may be able to use the same steg code. the same amount of effort would then also add mp3 files as possible containers. mp3 is also a realistic file format for people to use for other reasons, so it won't be like 'why are you having all those huge wav files all over your machine - what are you up to...' (also the reason i'm not going to bother with bmp support)... read more

fixed a bug in the test function that mis-calculated the available message length
by a lot... (x64)

steg and encryption and file handling stayed the way it was in V2.

not coming right with the default package chooser, so look before you download.
sorry about that...

hopefully that will come right (the any key must be here somewhere...)

please use the new version only (redownload it)
i did some important things to the steg code which maintains image clarity. (and also speeds up processing ~ 10x)
the old one messed up the images visibly for medium-sized messages.

that is because most coefficients in a jpeg file are empty most of the time.
when we update a 0 to a 1 it is a huge difference in coefficient value. which showed...

what i did:
used
0000 0000 0000 1110 ( == 14)
as the lowest positive value to modify,... read more