Pulling JPEGs out of thin air

#1

Post by atulagarwal » Fri, Nov 07, 2014, 10:18 AM UTC

Pulling JPEGs out of thin air
lcamtuf.blogspot.com

Re: Pulling JPEGs out of thin air

#2

Post by tux3 » Fri, Nov 07, 2014, 5:58 PM UTC

This is INSANELY COOL.

If it's smart enough to learn how to build a JPEG in a day, use it with netcat and it could probably send quite a lot of things down in flames.

Who needs static analysis :) ?

Re: Pulling JPEGs out of thin air

#3

Post by gear54rus » Fri, Nov 07, 2014, 5:59 PM UTC

I had a brief 'It's alive :O' moment when reading this, imagine seeing face looking at you in one of those pics :)

Nice article, concept of fuzzers was new to me.

Re: Pulling JPEGs out of thin air

#4

Post by byEngineer » Fri, Nov 07, 2014, 6:03 PM UTC

This is totally amazing! Wondering if it would be possible to go the other way around: from generated JPG to a string. If yes, what a cool way to send your password as a... JPG over email.

Re: Pulling JPEGs out of thin air

#5

Post by gear54rus » Fri, Nov 07, 2014, 6:04 PM UTC

tux3 wrote: post #2

This is INSANELY COOL. If it's smart enough to learn how to build a JPEG in a day, use it with netcat and it could probably send quite a lot of things down in flames. Who needs static analysis :) ?

Yeah, netcat would be fun. Although, it seems that it also straces (or similar?) the app it tests.

> it triggers a slightly different internal code path in the tested app

This would be impossible on the network.

Re: Pulling JPEGs out of thin air

#6

Post by rwg » Fri, Nov 07, 2014, 6:10 PM UTC

gear54rus wrote: post #5

tux3 wrote: post #2

This is INSANELY COOL. If it's smart enough to learn how to build a JPEG in a day, use it with netcat and it could probably send quite a lot of things down in flames. Who needs static analysis :) ?

Yeah, netcat would be fun. Although, it seems that it also straces (or similar?) the app it tests. > it triggers a slightly different internal code path in the tested app This would be impossible on the network.

Why impossible? (Hint: 127/8 is a network, too.)

Re: Pulling JPEGs out of thin air

#7

Post by tux3 » Fri, Nov 07, 2014, 6:12 PM UTC

gear54rus wrote: post #5

tux3 wrote: post #2

This is INSANELY COOL. If it's smart enough to learn how to build a JPEG in a day, use it with netcat and it could probably send quite a lot of things down in flames. Who needs static analysis :) ?

Yeah, netcat would be fun. Although, it seems that it also straces (or similar?) the app it tests. > it triggers a slightly different internal code path in the tested app This would be impossible on the network.

>Yeah, netcat would be fun. Although, it seems that it also straces (or similar?) the app it tests.

Ah yes, I forgot this little detail. I wonder if you can get it to work on the local machine first, but talking throught a socket instead of stdin.

Then, pipe the result throught netcat !

Re: Pulling JPEGs out of thin air

#8

Post by jameshart » Fri, Nov 07, 2014, 6:15 PM UTC

byEngineer wrote: post #4

This is totally amazing! Wondering if it would be possible to go the other way around: from generated JPG to a string. If yes, what a cool way to send your password as a... JPG over email.

The original string is not in any way part of the image that's generated. The fuzzer notices that the initial codepath being triggered with the "hello" file would be different if the first byte were 0xff, instead of 0x68. So it changes the file and tries it. The 'h' has gone - it wouldn't matter what it was originally, the fuzzer would always have chosen 0xff.

All the fuzzer is doing is exploring the possible codepaths through the application trying to exercise all the code; many of the codepaths end up with the executable outputting an error message and terminating. Some maybe put it into an infinite loop. Some end up with it completing a JPEG data parse and terminating - so in amongst all the possible paths it explores, of course it will eventually seek out input sequences which bring that about.

Re: Pulling JPEGs out of thin air

#9

Post by byEngineer » Fri, Nov 07, 2014, 6:16 PM UTC

jameshart wrote: post #8

byEngineer wrote: post #4

This is totally amazing! Wondering if it would be possible to go the other way around: from generated JPG to a string. If yes, what a cool way to send your password as a... JPG over email.

The original string is not in any way part of the image that's generated. The fuzzer notices that the initial codepath being triggered with the "hello" file would be different if the first byte were 0xff, instead of 0x68. So it changes the file and tries it. The 'h' has gone - it wouldn't matter what it was originally, the fuzzer would always have chosen 0xff. All the fuzzer is doing is exploring the possible codepat…

thank you very much for explaining that! So it is really quasi-random image generator with the initial string being a seed?

Re: Pulling JPEGs out of thin air

#10

Post by im2w1l » Fri, Nov 07, 2014, 6:20 PM UTC

Regarding

>if (strcmp(header.magic_password, "h4ck3d by p1gZ")) goto terminate_now;

How impossible would it be to look at the branching instruction, perform a taint analysis on its input and see if there is any part of the input we can tweak to make it branch/not branch. Like, we jumped because the zero flag was set. And the zero flags was set because these two bytes were equal. Hmm that byte is hardcoded. This other byte was mov'd here from that memory address. That memory address was set by this call to fread... hey, it come from this byte in the input file.