If I know the CPU architecture of a target, can I send instructions embedded in an image?

Question

Can I send instructions embedded in an image to a target, if I know his CPU architecture?

Answer 1

CPU instructions are given in what are called opcodes, and you're right that those live in memory just like your image. They live in conceptually different "areas" of memory, though.

For instance, you could imagine an opcode "read" (0x01) that reads a byte of input from stdin and puts it somewhere, and another operand "add" (0x02) that adds two bytes. Some opcodes can take arguments, so we'll give our example opcodes some: the "read" opcode takes an operand for where to store the byte it reads, and the "add" one takes three operands: two for where to read its inputs, and one for where to write the result to.

0x01 a1 // read a byte to memory location 0xa1
0x01 a2 // read a byte to memory location 0xa2
0x02 a1 a2 a3 // read the bytes at locations 0xa1 and 0xa2, add them,
              // and write the result to location 0xa3

This is typical of how a lot of instructions work: most of them just operate on data that's in memory, and some of them put new data into memory from the outside world (from reading stdin, in this example, or from reading a file or network interface).

While it's true that the the instructions and the data they operate on are both in memory, the program will only run the instructions. It's the job of the CPU, the OS, and the program to all make sure that happens. When they fail, you can in fact load data into the execution space, and it's a serious security bug. Buffer overflows are probably the most famous example of such a bug. But other than those kinds of bugs, you can essentially think of the data space and the execution space as being separate chunks of CPU.

In a toy computer, using the example above, the memory might look something like:

(loc)  | Initial      | After op 1   | After op 2   | After op 3   |
0x00   | *01 a1       |  01 a1       |  01 a1       |  01 a1       |
0x02   |  01 a2       | *01 a2       |  01 a2       |  01 a2       |
0x04   |  02 a1 a2 a3 |  02 a1 a2 a3 | *02 a1 a2 a3 |  02 a1 a2 a3 |
0x08   |  99          |  99          |  99          | *99          |
...
0xa1   |  00          |  03          |  03          |  03          |
0xa2   |  00          |  00          |  04          |  04          |
0xa3   |  00          |  00          |  00          |  07          |

In that example, the asterisk (*) points to the next opcode that will be executed. The leftmost column specifies the starting memory location for that line. So for instance, the second line shows us two bytes of memory (with values 01 and a2) at locations 0x02 (explicitly in the left-hand column) and 0x03.

(Please understand that this is all a big simplification. For instance, in a real computer the memory can be interleaved -- you won't just have one chunk of instructions and one chunk of everything else. The above should be good enough for this answer, though. )

Note that as we run the program, the memory in areas 0xa1 - 0xa3 changes, but the memory in 0x00 - 0x08 does not. The data in 0x00 - 0x08 is our program's executable, while the memory in areas 0xa1 - 0xa3 is memory the program uses to do the number crunching.

So to get back to your example: the data in your jpeg will get loaded into the memory by opcodes, and will be manipulated by opcodes, but will not be loaded into their same area in memory. In the example above, the two values 0x03 and 0x04 were never in opcode area, which is what the CPU executes; they were only in the area that the opcodes read and write from. Unless you found a bug (like a buffer overflow) which let you write data into that opcode space, your instructions won't be executed; they'll just be the data that gets manipulated by the program's execution.

Answer 2

Other answers give a good technical explanation but let me try with an analogy:

Please send your credit card number to [email protected]

• Did you read it?

• Did you do it?

It's more or less the same for your CPU. Reading something is not the same as executing it.

Answer 3

Can you send them? Yes, of course. Just assemble them and stick them somewhere in the image file.

Will the target execute them? No, not unless you already have control over the target (and can thus put a program there to read and execute them), or you find some exploit in an image viewer and get the image to load in it.

Answer 4

You could if your target used a version of Internet Explorer from before August 2005 to view a JPG. Or if they were going to open a PNG in Windows Media Player on Windows 98 with no security updates installed. And so on.

There was a lot of old software that used to have bugs where, if you made an image file in which the first part of the image file lied outrageously about the size and location of the pixel data in the file, the software could do something wrong and accidentally jump to code at the wrong address or write data from the file in a place where program code should be. I recall one of these hacks involved a file whose header claimed the image had negative size. You probably can't do this with more recent versions of Internet Explorer, or Edge, because everyone knows about the problem now and Microsoft did their best to fix it.

Today's operating systems have some protective measures in place to make it difficult (but not completely impossible) to achieve anything really bad if you find a new way to hack a program using a method like this. Areas of memory can be set so they cannot be executed. Programs have separate virtual address spaces so they can't accidentally access each other's memory. Some OS components are loaded at unpredictable memory locations so it's not simple for malicious code to find and use them.

Answer 5

No. Image files such as JPEG files don't execute code, they are simply rendered and displayed.

If you want to hide some information in a file that's called Steganography, but that only hides information, it doesn't execute any instructions.

For a file to run code it has to be an executable, or be run by another program which reads the file, then executes the commands in the file.

In this case the rare instance when an image could result in executing code is if there were a bug in the software which rendered the image based off the file. This has happened in the past, but it's exceedingly rare. For all practical purposes an image can't run instructions.

This of course isn't the case for PDFs, Adobe Flash, etc.

Answer 6

You can, IF you also know what software stack will touch the image on the receiving side, AND IF there are unresolved security vulnerabilities in that software stack.

Simply putting the instructions in the JPEG file does nothing.

However, if there is a known way to make a certain exact JPEG reader implementation crash on a malformed JPEG file in a way that it will copy data from the image file where that data does not belong (like, on top of variables that contain program control flow information like function pointers or return addresses), and if OS or hardware level countermeasures (eg DEP) do not stop that from happening, there is a realistic chance. Such vulnerabilities have existed in (and do exist in legacy) real-world implementations.

Answer 7

The short version is no, because computers (SHOULD) know the difference between data and instructions. The worst you SHOULD be able to do with a JPEG is something like a zip-bomb or something that crashes some JPEG decompression routines. A program to load & display a JPEG will not be trying to RUN any of the data in the file, only read it and process it - and if it hits some unexpectedly not-jpeg data it will either stop or crash, or just show a really messed up picture.

HOWEVER, sometimes (I'm looking at you, Microsoft) people try and write helpful software that can be vulnerable by (for example) trying to automatically load & display e-mail attachments, create document formats that can contain scripts/macros, etc. and this is where a malicious file can cause damage.

The classic (and by now hopefully defunct/protected against) example is e-mail attachments called something like .jpg.exe where the file is really an executable and Windows will treat it as such, but because Windows hides the extension (hiding the last .exe part) people see file.jpg and click on it, causing the OS to run it.

It's the difference between reading a book and acting out the content of the book - if the book says "go and punch someone" you're not going to do it, because the words (data) in the book is not controlling your brain even though your brain is processing that data.