If I know the CPU architecture of a target, can I send instructions embedded in an image?
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.
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.
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.