How do jpeg's with embedded executables work?
Virus Guy
internal executable code?
Some recent examples of this are SillyDl and Waledac.
Does the jpeg file format allow for embedded executable code or files?
Or are these specially crafted jpeg files that trips up image decoding
engines (like a buffer overrun) that causes them to execute the desired
code (while still rendering a perfectly coherent bitmapped image) and
not causing the background application to crash?
FromTheRafters
news:49B130B3...@Guy.com...
They exploit a vulnerability.
Virus Guy
> > What is the mechanism behind the execution of jpegs that
> > contain internal executable code?
>
> They exploit a vulnerability.
Was that supposed to be some sort of answer? Of course there's a
vulerability here, you moron. If you can't answer a question, then
don't waste our time posting a garbage answer.
Beauregard T. Shagnasty
> What is the mechanism behind the execution of jpegs that contain
> internal executable code?
One of the oldest ways (been in use since the last millennium) is to
obfuscate the file name. Ex:
britneynaked.jpg .exe
When you see the file listed as an attachment, the .exe part is spaced
outside the file name display area. So you happily click it, and Windows
happily executes the (not-a-jpg) executable file. If the exploit is not
in your a-v database, you are immediately infected. Social engineering,
as are most viruses.
This is a good case for first saving to hard drive, and scanning, prior
to "opening" any attachments.
http://outside.arc.ab.ca/staff/erkamp/security.jpg
I don't know what else they may use these days.
--
-bts
-Friends don't let friends drive Windows
FromTheRafters
"Virus Guy" <Vi...@Guy.com> wrote in message
Before calling someone *else* a moron, you should reread your own
question.
"Does the jpeg file format allow for embedded executable code or files?"
OR
"Or are these specially crafted jpeg files that trips up ...?"
It exploits a vulnerability as opposed to being an executable filetype.
Remember the WMF fiasco where it was actually an executable filetype and
yet that function was deprecated and mostly forgotten about? JPEG file
format remains a data filetype.
Virus Guy
> > What is the mechanism behind the execution of jpegs that contain
> > internal executable code?
>
> One of the oldest ways (been in use since the last millennium)
> is to obfuscate the file name. Ex:
>
> britneynaked.jpg .exe
I realize that.
However, the threats named SillyDl and Waledac employ graphic images (I
assume jpeg) that seem to render a usable image but otherwise still
result in unintended code execution:
http://community.ca.com/blogs/securityadvisor/archive/2009/02/15/waledac-s-malware-companions.aspx
See near the bottom of this page:
http://www.ca.com/us/securityadvisor/virusinfo/virus.aspx?id=77663
---------------
Win32/Waledac.AJ is also capable of downloading additional malware from
the orldlovelife.com domain.
The downloaded file appears to be an image file and has a .JPG
extension:
(example image - somewhat easy on the eyes)
However, the file is embedded with a malicious executable detected as a
Win32/SillyDl trojan variant.
---------------
> When you see the file listed as an attachment, the .exe part
> is spaced outside the file name display area.
These examples are not described as simple file-name obfuscations.
I know that an .exe that has simply had it's name changed to .jpg is
also possible, but again I don't see how it's possible to do that and
still end up with a render-able inline image.
The CA writeups do not identify these examples as a simple file-renaming
phenomena.
Virus Guy
> >> > What is the mechanism behind the execution of jpegs that
> >> > contain internal executable code?
> >>
> >> They exploit a vulnerability.
> >
> > Was that supposed to be some sort of answer? Of course there's a
> > vulerability here, you moron.
>
> Before calling someone *else* a moron, you should reread your own
> question.
>
> "Does the jpeg file format allow for embedded executable code or files?"
Which you did not directly answer.
> OR
>
> "Or are these specially crafted jpeg files that trips up ...?"
Which again you did not answer.
> It exploits a vulnerability as opposed to being an
> executable filetype.
Which is not an answer to this:
> > What is the mechanism behind the execution of jpegs that
> > contain internal executable code?
> JPEG file format remains a data filetype.
Explain the mechanism of action of these mal-formed jpeg files, as they
are utilized in the threats known as SillyDl and Waledac.
James Egan
On Fri, 06 Mar 2009 19:27:17 -0500, Virus Guy <Vi...@Guy.com> wrote:
>However, the threats named SillyDl and Waledac employ graphic images (I
>assume jpeg) that seem to render a usable image but otherwise still
>result in unintended code execution:
>
>http://community.ca.com/blogs/securityadvisor/archive/2009/02/15/waledac-s-malware-companions.aspx
>
>See near the bottom of this page:
>
>http://www.ca.com/us/securityadvisor/virusinfo/virus.aspx?id=77663
I don't follow what explanation you are looking for.
From reading the links you posted, some malware is already running and
downloads some more malware hidden in the tag area or after the end of
file marker in a jpg file. So it's the already running malware which
extracts and runs the additional malware not some exploit in your
image viewing software which will simply show the image (ignoring the
tagged on malware) if you click on it.
Jim.
Virus Guy
> I don't follow what explanation you are looking for.
>
> From reading the links you posted, some malware is already
> running and downloads some more malware hidden in the tag
> area or after the end of file marker in a jpg file.
I had the impression that simply displaying the jpeg's on a clean system
somehow results in a code execution that leads to the downloading and
installation of the real payload.
Or is this used to get the code past AV scanners (by embedding them into
or at the end of otherwise legit jpeg files) ?
Virus Guy
> Open the questionable file in a hex editor to see if the first
> characters are [MZ] or [ÿØÿá]
You are completely missing the point of this thread.
James Egan
On Sat, 07 Mar 2009 08:42:08 -0500, Virus Guy <Vi...@Guy.com> wrote:
>Or is this used to get the code past AV scanners (by embedding them into
>or at the end of otherwise legit jpeg files) ?
That's what I think it's for. The malware is just trying to conceal
itself from both malware scanners and curious users.The baddies
already have control of the computer so don't need another exploit.
Jim.
Russg
"ASCII" <> wrote in message news:..
> Virus Guy wrote:
>>
>>The downloaded file appears to be an image file and has a .JPG
>>extension:
>
> fonts to render correctly, it looks like [yOya] but with accent marks.
> This will tell whether the file is an exe (executable) or jpeg data.
> Never mind the visible extension, could be misleading.
my jpg don't start with yOya, they start with FF D8 FF E0.
James Egan
On Sat, 7 Mar 2009 12:07:30 -0500, "Russg"
<russ...@MUNGEsbcglobal.net> wrote:
>my jpg don't start with yOya, they start with FF D8 FF E0.
Ho Ho Ho! or should I say 48 6F 20 48 6F 20 48 6F 21
Jim.
FromTheRafters
"Virus Guy" <Vi...@Guy.com> wrote in message
> FromTheRafters wrote:
>
>> >> > What is the mechanism behind the execution of jpegs that
>> >> > contain internal executable code?
>> >>
>> >> They exploit a vulnerability.
>> >
>> > Was that supposed to be some sort of answer? Of course there's a
>> > vulerability here, you moron.
>>
>> Before calling someone *else* a moron, you should reread your own
>> question.
>>
>> "Does the jpeg file format allow for embedded executable code or
>> files?"
>
> Which you did not directly answer.
Sorry, I assumed the above and the below were choices for the first
question. You know, like "Why 'a' - is it because 'b' or because 'c'?".
I answered *that* question. I figured that you knew if JPEG is a data
filetype then it must be an exploit of a vulnerability in the handling
of that data that allows execution of "embedded code".
The WMF scenario was different because it was assumed by most to be a
data filetype (and yet, by design, it wasn't) and would fit your above
scenario.
>> OR
>>
>> "Or are these specially crafted jpeg files that trips up ...?"
>
> Which again you did not answer.
Yes, I did! This was the choice I chose because JPEG is a data filetype
and not by design an executable filetype.
>> It exploits a vulnerability as opposed to being an
>> executable filetype.
>
> Which is not an answer to this:
>
>> > What is the mechanism behind the execution of jpegs that
>> > contain internal executable code?
Yes, it is! It exploits a vulnerability in the programming that handles
the data the file contains.
>> JPEG file format remains a data filetype.
>
> Explain the mechanism of action of these mal-formed jpeg files, as
> they
> are utilized in the threats known as SillyDl and Waledac.
No vulnerability is noted, but seeing as the file is downloaded by
already running malware, the system itself is vulnerable to
exploitation.
Russg
"ASCII" <> wrote in message news:> Russg wrote:
>>my jpg don't start with yOya, they start with FF D8 FF E0.
>
Don't understand 'non-hex side'.
FF is a non-display value. only the D8 has a display
and that isn't an ASCII value, as ASCII only goes
to 127/&H1B, '?' displays D8 (216).
Ant
> "ASCII" wrote:
>> Russg wrote:
>>>my jpg don't start with yOya, they start with FF D8 FF E0.
>>
>> Same here, but in the non-hex side is where I was referring to.
>
> Don't understand 'non-hex side'.
Character symbols.
> FF is a non-display value. only the D8 has a display
> and that isn't an ASCII value, as ASCII only goes
> to 127
None of those values are ASCII and none of them have display symbols
in that character set. However, characters in the ANSI set do have
symbols for some values in the range up to FF (255), including the
ones mentioned.
> /&H1B, '?' displays D8 (216).
I don't know what that's supposed to mean. 1B (27) is an escape
character and has no symbol in either set.
Dustin Cook
news:jLKdnUAHe5Clmy7U...@brightview.co.uk:
> "Russg" wrote:
>
>> "ASCII" wrote:
>>> Russg wrote:
>>>>my jpg don't start with yOya, they start with FF D8 FF E0.
>>>
>>> Same here, but in the non-hex side is where I was referring to.
>>
>> Don't understand 'non-hex side'.
>
> Character symbols.
>
>> FF is a non-display value. only the D8 has a display
>> and that isn't an ASCII value, as ASCII only goes
>> to 127
>
> None of those values are ASCII and none of them have display symbols
> in that character set. However, characters in the ANSI set do have
> symbols for some values in the range up to FF (255), including the
> ones mentioned.
Yea, sometimes, we'd use the higher ascii codes to draw with. :)
Well that was back in the day..... ahh, megadeth...
> I don't know what that's supposed to mean. 1B (27) is an escape
> character and has no symbol in either set.
Hmm.. Yes, it does too. An arrow pointing to the left. This isn't wise to
hard code in your source, as it wracks having when printing... hahahaha,
but.. alas, live and learn.
--
Regards,
Dustin Cook
Malware Researcher
MalwareBytes - http://www.malwarebytes.org
Russg
"Ant" <> wrote in message news:
? .
I can't find the large O with a slash like the one ASCII
displayed. What I was saying was a .jpg header
doesn't have the ˙O˙ŕ, trying to get away from the
display characters and give hex instead.
Beauregard T. Shagnasty
> as it wracks having when printing...
wreaks havoc? ;-)
Ant
> "Ant" wrote:
>> 1B (27) is an escape character and has no symbol in either set.
>
> Hmm.. Yes, it does too. An arrow pointing to the left.
That's in the DOS OEM character set which has a symbol for all 8 bit
values. It's neither true ASCII nor ANSI.
Ant
> I was trying to display a CHR$(216)
In/on what, and with what language? That looks like Basic code.
> I'll try again:
>
> ? .
The question mark means that whatever you're using to display the
character isn't using the ANSI set and has no symbol for it.
> I can't find the large O with a slash like the one ASCII
> displayed.
Open notepad and type the numbers 0216 using the keypad while
holding down the alt key.
> What I was saying was a .jpg header doesn't have the яOяа,
It depends what you view it with.
> trying to get away from the
> display characters and give hex instead.
Fairy nuff.
Russg
"Ant" <> wrote in message news:
>
>> I was trying to display a CHR$(216)
>
> In/on what, and with what language? That looks like Basic code.
>
The O with a slash is what ASCII had with the yOya.
The problem is it doesn't display that way with my
hex/character display program (VonBerg's LISTER from
DOS days). Hex FF D8 FF E0 or E1 is what I
get from ASCII's post and looking at .jpg header.
Why it gets the ÿ and à (decimal 152 and 133) I dunno.
The problem is the character sets we're seeing, so giving
hex values is less ambiguous.
>> I'll try again:
>>
>> ? .
>
> The question mark means that whatever you're using to display the
> character isn't using the ANSI set and has no symbol for it.
>
>> I can't find the large O with a slash like the one ASCII
>> displayed.
>
> Open notepad and type the numbers 0216 using the keypad while
> holding down the alt key.
I tried in notepad, it displayed a small black box, meaning
I think that notepad doesn't know what to do with it, like the little
squares you get sometimes. ALT 2 1 6 displays the big O with a slash in
word pad.
>> What I was saying was a .jpg header doesn't have the ÿOÿà,
>
> It depends what you view it with.
>
>> trying to get away from the
>> display characters and give hex instead.
>
> Fairy nuff.
>
ASCII original post shows ÿOÿà (decimal 152,216,
152,133) in my news reader (OE),
but I don't know why it gives that, as a copy of the
four characters and paste them into notepad and
save them to a .txt file and look at them with my
hex reader and I get FF D8 FF E1. So, I agree
with ASCII's header now. How ASCII typed the
four characters is a puzzle, hex values would be
clearer, I think.
Dustin Cook
news:gov5tf$dj5$1...@news.motzarella.org:
> Dustin Cook wrote:
>
>> as it wracks having when printing...
>
> wreaks havoc? ;-)
>
That would be the one.... woops!
Dustin Cook
news:QcmdnfBve5NCuy7U...@brightview.co.uk:
I think ? it was once used for printer control of some sort... Abort mebbe?
It's been a very long time...
Buzzard
> "Beauregard T. Shagnasty" wrote:
> (snip)
> Win32/Waledac.AJ is also capable of downloading additional malware from
> the orldlovelife.com domain.
> The downloaded file appears to be an image file and has a .JPG
> extension:
> (example image - somewhat easy on the eyes)
> However, the file is embedded with a malicious executable detected as a
> Win32/SillyDl trojan variant.
I've heard that some malware exists just for the purpose
of downloading bigger, badder bugs to your computer.
sillydl and waledac ...could be... such loaders.
If so, the bigger bugs they are downloading can be
concealed at their source by tacking them onto the
end of otherwise legit files, such as perfectly
viewable jpegs.
Conceiveably, a virus payload, provided your pc is already
infected with a loader trojan, could even be tacked
onto the end of a textfile [.txt], after the EOF marker.
(chr 26)
Once loaded, the existing loader malware would then
extract these hidden virii, and install them.
(Again, this is "...could be..." I've never actually
had such a thing happen here)
Beauregard T. Shagnasty
> Virus Guy wrote:
>> "Beauregard T. Shagnasty" wrote:
>> (snip)
>> Win32/Waledac.AJ is also capable of downloading additional malware from
>> the orldlovelife.com domain.
Beauregard did not write anything in your post. Please take care with
editing attribution lines. Thanks for your attention in the matter.
FromTheRafters
news:KeKdnZoy3f8pyC7U...@citizens.coop...
> I've heard that some malware exists just for the purpose
> of downloading bigger, badder bugs to your computer.
>
> sillydl and waledac ...could be... such loaders.
>
> If so, the bigger bugs they are downloading can be
> concealed at their source by tacking them onto the
> end of otherwise legit files, such as perfectly
> viewable jpegs.
>
> Conceiveably, a virus payload, provided your pc is already
> infected with a loader trojan, could even be tacked
> onto the end of a textfile [.txt], after the EOF marker.
> (chr 26)
>
> Once loaded, the existing loader malware would then
> extract these hidden virii, and install them.
>
> (Again, this is "...could be..." I've never actually
> had such a thing happen here)
Yep, just about anything can be used as a container for malware if the
system is executing a program capable of extracting that malware from
that container. A JPEG file is just as dangerous as a cabinet file (or a
text file) if malware can extract and execute malware from it.
Ant
> I think ? it was once used for printer control of some sort... Abort mebbe?
> It's been a very long time...
Yes, HP's printer control language uses escape sequences (escape
followed by numbers/chars) for all sorts of printer commands. So any
random junk following an escape would cause strange effects.
Ant
> "Ant" wrote:
>> "Russg" wrote:
>>> I was trying to display a CHR$(216)
>>
>> In/on what, and with what language? That looks like Basic code.
>
> Yes, BASIC code, display a character decimal 216.
> The O with a slash is what ASCII had with the yOya.
> The problem is it doesn't display that way with my
> hex/character display program (VonBerg's LISTER from
> DOS days). Hex FF D8 FF E0 or E1 is what I
> get from ASCII's post and looking at .jpg header.
The hex values above are correct for the symbols in question when
interpreted as ANSI. That old DOS program will likely be using the
OEM or similar character set.
> Why it gets the я and а (decimal 152 and 133) I dunno.
What gets? 152 (0x98) and 133 (0x85) are the values (or positions)
for those symbols in the OEM set.
>> Open notepad and type the numbers 0216 using the keypad while
>> holding down the alt key.
>
> I tried in notepad, it displayed a small black box, meaning
> I think that notepad doesn't know what to do with it, like the little
> squares you get sometimes.
Try changing the font.
> ALT 2 1 6 displays the big O with a slash in word pad.
There ya go.
> ASCII original post shows яOяа (decimal 152,216,
> 152,133) in my news reader (OE),
> but I don't know why it gives that, as a copy of the
> four characters and paste them into notepad and
> save them to a .txt file and look at them with my
> hex reader and I get FF D8 FF E1.
Because your OE font interprets them as valid ANSI characters,
whereas the old DOS prog won't use the same symbols for those
values.
James Egan
If you were addressing the printer directly that is. With windows (or
similar) sitting in between, I would expect it to escape (sequence)
such escape sequences as literals.
Jim.
Ant
> On Sun, 8 Mar 2009 19:12:18 -0000, "Ant" wrote:
>>"Dustin Cook" wrote:
>>> I think ? it was once used for printer control of some sort... Abort mebbe?
>>> It's been a very long time...
>>
>>Yes, HP's printer control language uses escape sequences (escape
>>followed by numbers/chars) for all sorts of printer commands. So any
>>random junk following an escape would cause strange effects.
>
> If you were addressing the printer directly that is.
Which is easy to do on DOS systems.
> With windows (or
> similar) sitting in between, I would expect it to escape (sequence)
> such escape sequences as literals.
It must surely depend on the device driver.
As you probably know, on the NT OS family it's not possible to talk
directly to peripherals - you have to go through the kernel and
hardware abstraction layer. I don't know what the port drivers do
with random bytes sent to them from user mode but a printer driver
needs some way to send a PCL or equivalent byte stream to the device.
A printer driver would have to make that raw-data/command mode
functionality available to the user.
James Egan
On Sun, 8 Mar 2009 23:53:53 -0000, "Ant" <n...@home.today> wrote:
>A printer driver would have to make that raw-data/command mode
>functionality available to the user.
>
Yes. And since a user is unlikely to do this inadvertantly, it is
unlikely that the havoc predicted by raidy would ensue in today's
circumstances. Perhaps he was just reminiscing about bygone days.
Jim.
Dustin Cook
@mid.individual.net:
Aye. I was taking a trip down memory lane..