/tech/ - technology

Sure. I think that jpg images can be extended without changing the image.
The resulting image will be very large for an image, so anyone being keen can easily see that it's been messed with, but for silly uses it's fine.

>>2501
Oh, forgot to tell you how:
Step 1. Get your image
Step 2. Get your zip
Step 3. Append your zip file to the end of your jpg
Step 4. ???
Step 5. Profit

>>2502
how do you know where the image begins and the zip begins?

>>2503
Most file formats begin with "magic numbers" that identify the format used. It's like the shebang for scripts, but binary. Zip files start with

PK\x03\x04

. You can try searching for embedded files using binwalk: https://github.com/ReFirmLabs/binwalk

>>2500
You can append a(n) .RAR or .zip archive to a JPEG file like said earlier in thread, but most image uploading sites compress or alter image files uploaded so you won't have luck with images uploaded to sites like Imgur. As for knowing where the jpeg ends and the zip begins, just change the name of the file (ie image.jpg to image.rar) after appending the .RAR archive to the end of the JPEG and open it, your archive manager/viewer should do the rest. I recommend using 7zip to view archives.

https://www.7-zip.org/
https://web.archive.org/web/20180319162915/https://www.wikihow.com/Hide-a-File-in-an-Image-File

>>2506

binwalk -e <file>

should automatically extract all detected "subfiles" in a file
If you're sending a 200M jpeg that's 500x500 pixels and trying to hide from someone mildly competent, you're gonna have a bad time.
Don't think stego adds anything but obscurity.

>>2510
Stego is as much an obscurity thing as cryptography.

Appending a file to something doesn't qualify as proper stego to me. Something that is spread over a collection of files in a pattern that is purely dependent upon the seed/key you give it qualifies more.

And yes, you can pile up encryption on top of such a payload, meaning that deobfuscation and decryption are now both required.

>>2504

This is the wrong way to make a anything/zip polyglot, and some uncompressors will reject it (like the built in windows unzip), others might figure it out. The white paper on the zip format is pretty unambiguous about how they should be constructed:

1) One or more Files

Files contain a "local header" then the compressed "file data"

2) One or more "central directory header(s)", which give you the absolute offsets (i.e from the beginning of the file) of local headers

3) One "end of central directory header", which gives you the absolute offset of the start of the central directory headers.

You can't just binary concat a file with a zip, because the absolute offsets will be wrong. If you don't want to make a utility specifically for making zip polyglots, you can rename your image to .zip, and then add your files; most zip utilities will do the right thing.

t. Just implemented an unzip utility that supports png/zip polyglots

>>2526
i thought the idea was that you search for the magic number and then unzip whatever follows.

>>2500
Here's a simple trick that you can use to embed a zip file containing a text file into a png image. It's a pretty quick and dirty method and there will probably be an error stating something to the effect of "extra bytes at beginning of the zipfile" but, provided the png was larger then the zip, it should uncompress without issue.

To encode:
$ cat file.zip >> image.png
And to decode:
$ unzip image.png

>>2529

Nope! One of the features of zip files (when the format was made) is that they could (potentially) be spread across multiple floppy disks, and if you wanted to add or remove a file from the zip, you only needed to edit the last floppy disk (which contained the central directory headers, and the end of central directory header). This means you could have "junk" files at the beginning of the zip file, but since they're not referenced the the central directory, they shouldn't be unziped.

Also, the magic numbers that >>2504
describes is the first part of the signature for a local header and end of central directory. It's entirely possible to have a zip file with no files inside it, in which case the magic number will be 0x06054b50. If there's at least one file, it'll start with the magic number for a local header, 0x04034b50.

The way zlib and the windows unzip utility works is by looking at the end of the file, and scanning backwards until they find the magic number for the end of central directory header, then they get the central directory headers, and finally the local headers and the associated compressed files.

>>2541

That just appends a zip file to a png, it's the same as a binary concat; your offsets will be wrong.

>>2500
You're better off using a ZuluCrypt volume with a plausible deniability partition, you can get it from apt

```
sudo apt install zulucrypt-gui
```