I started this course in 2015 and it is great. It is taking a while to work through it and loving the challenge.

For Recover in pset 4, my code works for finding and matching the first 3 static bytes of a JPEG.

The 4th byte in the signature of a JPEG is however a bit more dynamic. The problem states the first 4 bits are 1110 and the remaining 4 bits can have many options.

I'm hitting a wall on finding the functions and syntax in C that will just look at the first 4 bits in the 4th byte and see if they match the pattern of 1110.

The pseudo code for what I want to do is:

1) After finding the 3 JPG static bytes, take the 4th byte.

2) Does the 4th byte = 00e*? * being a wildcard. I have no idea if that is possible in C but that is my thought process.


2) convert the 4th byte to binary string
3) somehow compare "1110" to the first bits of the binary string.

The reason I'm doing this is because if I don't validate the 4th byte, I'm guessing it is possible to create a "false positive" JPG file.

Plus, I'm just kind of curious how this is possible!

If I don't need to worry about the 4th byte to complete this problem, someone please let me know :)


The pset gives you the clue that the first 4 bits will be 1110. There are several ways to approach it. You can check if it's <= 0xef and >= 0xe0. Or you could divide it by 16 (or right shift the bits by 4) and compare it to 0xe. Or you could use a bitmask to mask away the last 4 bits, remembering that anything ANDed with 0 will throw away the values and anything ANDed with 1 will keep them.


01010011 & 11110000 = 01010000   or, in hex: (0x53 & 0xf0 == 0x50)

So can you see how you can then say, if your 4th jpg byte & 0xf0 is equal to 0xe0, then it's a match?

Again, different ways to do it; work with whatever way is most comfortable.

  • Thank you! I forgot that fundamental piece of logic that the signatures have values that can be rank ordered. Also, your tip of "right shift the bits" gave me the clue I needed to find the bitshift operator in C. cs50 stackechange is very helpful. Much different than Stack Overflow where the first answer always seems to be a forum truther saying "this question has been asked and answered." – Xia Jan 5 '16 at 5:51
  • Glad to help. Please vote/accept my answer when you get a chance so that the question will be marked as resolved. – curiouskiwi Jan 5 '16 at 6:06

Last things first, you absolutely have to "worry about the 4th byte". How else would you know if you have found a jpg signature? I think you are complicating things by thinking in terms of bits. The fourth byte is either 0xe0 or 0xe1. Your test of the fourth byte should be an or condition, something like
b4 == 0xe0 || b4 == 0xe1

  • The fourth byte can be 0xe0, 0xe1, 0xe2, ... 0xef ( you must be thinking of an older version of recover). – curiouskiwi Jan 5 '16 at 4:38
  • Thanks for the response. Yeah, I was a bit confused at how some of the Recover questions on this forum have said the 4th bye can only be two possibilities. The version i"m looking at has many more options than that. – Xia Jan 5 '16 at 5:37
  • In earlier iterations of the recover pset, the specs only required a check for e0 or e1 in the 4th byte (they only had jpgs with that), hence the answers you've seen. – curiouskiwi Jan 5 '16 at 6:07
  • Oops! Sorry for the misdirect. And shame on me for not doing the requisite research and leg work. – DinoCoderSaurus Jan 5 '16 at 12:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .