Can I simply embed tar file inside png image? I`m tried
cat file.tar image.png > secret.png,
but this not working for me. does have anybody working example? it would be preferable in ruby or python
For simplicity's sake, you can use the stepic library.
It will do what you want out of the box:
stepic --encode --image-in=plain.png --data-in=data.tar --out=secret.png
to decode:
stepic --decode --image-in=secret.png --out=data.tar
You can download and install from the stepic webpage
I doubt you're going to be using this for life-critical data, but just in case:
Encrypt the data first!
It's somewhat trivial to recover ordered data from an image using image processing techniques. What you're encoding in the image should have the following properties to keep you safe and to be difficult to discover:
Be cryptographically secure
Be indistinguishable from random noise (see 1.)
Be large enough that all the pixel of the image carry the encrypted data
The reason we do the last one is because it is very easy to detect if the encoded data stops half way down the image. You'll have an image where half has high noise, and half doesn't. In some cases, this is visible to the naked eye, let alone to someone who knows what they're doing.
I don't know if stepic does all this. Rely on it at your own risk.
Related
Anyone knows why the image, shown below, is partially gray while loading? I assume it has something to do with progressive JPG, but I haven't seen the grayscale effect before. Is there some kind of a JPG export setting that enables that? How is it called? Can I disable it?
Direct image link
Edit:
The problem could either be the problem described in #KonradDzwinel answer OR my answer, both could look identical:
What is the problem
For some reason the file is saved or produced in way that make the file we call it Lossless JPEG.
I am not sure which software, tool or how this problem is was produced, but that won’t change the fact that your file had have some issues or even corrupted.
How to find the problem in the file
Your file was saved in way that it works identical but it had issues. To check whether your file is healthy or not, it requires a tool to scan/analysis the image file. I use a very nice and easy to use tool (software) called JPEGsnoop (link for download). This tool is free and I used it to scan and analysis your image files for problems.
Your file comes up with few places with following note, (the screen-shot btw shows only one note, but there were more):
NOTE: Scan parsing doesn’t support this SOF mode.
After I have re-saved the file correctly and analysis it again, it does not show any problems or notes:
What I did to create a problem FREE image file
For testing I have used Photoshop 5.5 to open the Lossless file and save it with new name with default jpeg (since I don't have the original file). But correctly I assume you have the original file, and I assume you have Photoshop any version does not matter OR any other image tool. Try to optimize your jpeg file best possible, analysis it and remember/note the saving setting for future wise image saving.
Here is an example of my Photoshop save settings, which result in problem FREE file:
How can I learn more about Lossless JPEG
I won’t go in details of this problem but I will leave some link that explain it in details, I hope also you find this is useful to solve your issue:
http://www.impulseadventure.com/photo/fix-corrupt-jpeg-photo.html
http://fileformats.archiveteam.org/wiki/JPEG
http://fileformats.archiveteam.org/wiki/Lossless_JPEG_%28original%29
http://www.howtogeek.com/142174/what-lossless-file-formats-are-why-you-shouldnt-convert-lossy-to-lossless/
Software JPEGsnoop
http://www.impulseadventure.com/photo/jpeg-snoop.html
Progressively encoded JPEGs contain ten scan layers by default. That means ten iterative layers of image information build on each other to deliver the final visual quality of the image. The first visible scan layer of a progressive JPEG is always highly pixelated and often black & white because it saves on color channel information.
Source (emphasis mine)
Another resource that explores this issue in lengh: http://cloudinary.com/blog/progressive_jpegs_and_green_martians
I am developing a game in j2me. How to handle images in .dat format.
I downloaded some games and extracted jar , found some dat format images and not able to open that images and images size also very less.. what tools I need to use?
Ref link
enter link description here
Not able to find solution?
A dat file could be anything. Depends what the developer felt like doing.
Some developers chose to strip PNG files of their header, and added the header back in the code. This was partly done in order to save a few bytes (because they mattered back then), and partly because of the challenge in doing it like that, and partly because it ensured all images used the exact same palette.
So that's one possibility, but it really could be anything.
As stated by mr_lou, there really isn't anything special about a .dat extension.
The steps to re-compile a file usually start with opening the file up in a hex editor and then looking at the first bits of information in the file. You then basically work from there to re-compile the data necessary for a 'normal' program to interpret the file. In particular, the first 8-16 bytes are often very helpful for determining what type of file it is "supposed" to be.
If you are looking at a png file (that's what I usually prefer to use for art assets) then you can reference http://en.wikipedia.org/wiki/Portable_Network_Graphics to see how a 'normal' png might look. When you're tweaking to save bytes you often strip unnecessary fields from png headers (things like the ancillary chunks) and using a common palette.
However, remember that it's not necessarily image data. It could be things like level data, sound, default stats or any particular amount of stuff.
I have read that some image viewers were hacked by appropriately doctored images (in a format particularly suited for that? not sure about the details).
So, how could this threat be completely eliminated? For instance, suppose we make a viewer for the affected format written in managed code and have it convert images to a pure BMP (or something else so simple that its viewers cannot be hacked); would the problem go away? How about first convert to BMP and then introduce some pervasive minor random pixel alterations to better disrupt the possible hack?
Let's say this image sanitization converter would be incorporated into the firewall so that only "safe" sanitized images would, by default, end up loaded during regular browsing. Would this solve the problem? Or is my reasoning incorrect due to flawed understanding of the nature of image based exploits?
Your question, i think, boils down to whether the attack lives in the data or in the image. If it's in the data, then merely decoding the image and re-encoding with a known-good encoder it will ensure safety. If it's in the image, then you may need to alter the pixels.
The famous example of this was mishandling of JPEG comment fields with bad lengths, originally a bug in Netscape, but later independently introduced into Windows. This was very much a data rather than an image problem; the part of the data in question isn't even image data, it's metadata. If you decoded the image with a sandboxed decoder, perhaps detecting and recovering from the corrupt comment field, then re-encoded it with a friendly encoder, the result would be safe even for vulnerable decoders. Doing this naively would lead to a loss of quality; it is possible to losslessly transcode JPEGs, but it requires code to specifically do so.
My gut feeling is that image-level attacks are not possible, only data-level attacks. Image formats are well-enough specified, and fundamentally simple enough, that the content of the image really shouldn't affect the decoding process. I certainly can't prove that, though, nor really even argue for it.
I would like to compress scanned text (monochrome or few colours) and store it in pdf (maybe djvu) files. I remember that I got very good results with Windows/Acrobat and "ZRLE" compressed monochrome tiff embedded into pdf. The algorithm was loossless as far as I remember. Now I search a way to obtain good results on linux. It should be storage saving and avoid loss (I do not mind loosing colours, but I do not want e.g. jpeg compression which would create noisy results for text scans). I need it for batch conversion, so I was thinking of the ImageMagick convert command. But which output format should I use so I get good results and to be able to embed it into pdf files (for example using pdflatex)? Or is it generally better to use djvu files?
jbig2enc encoder for images using jbig2 compression,
was originally written for GoogleBooks by Adam Langley
https://github.com/agl/jbig2enc
I forked to include latest improvements By Rubypdf and others
https://github.com/DingoDog/jbig2enc
I also built several binaries of jbig2enc for puppy linux (it can be working also on other distributions)
http://dokupuppylinux.info/programs:encoders
DJVU is not a bad choice, but if you want to stay in PDF for better compatibility you may want to look into lossless JBIG2 compression.
Quote from Wikipedia:
Overall, the algorithm used by JBIG2 to compress text is very similar
to the JB2 compression scheme used in the DjVu file format for coding
binary images.
Can anyone tell me how i can parse a png image into many png images in J2ME ? I want to write a code that take a image and give many images that have equal pixels.
You mean you want to cut it into smaller images?
Load the image.
Convert to a bitmap.
Encode arbitrary rectangles as PNG.
Save the PNGs.
Unfortunately, I don't know anything about image processing usinf J2ME libraries.
Here's what I googled as far as loading a PNG in J2ME.
Using that, you'll be able to see the API calls used, and following the import list, you'll get to the classes used. Look at those class's methods, and yu'll probably come up with what you need.
I did this mostly because you're having an emergency, but frankly, you could have googled this yourself, or composed a question that was clearer, which would have led to someone more knowledgeable about J2ME image processing helping you.
Just don't panic, take a breath, google for what you need, you'll be fine.