Apparently we got our own thread <img src="images/smiles/icon_wink.gif" alt="Wink" title="Wink" />
jaclaz wrote:
If I get it right this, translated into English means "repetitions of FF value must be considered as a single instance, thus FF is not an acceptable value for 4th byte"<img src="images/smiles/icon_question.gif" alt="Question" title="Question" />
So yes, this also gets back to one of your earlier questions why 3 people yield 3 different results:
1. language is ambiguous
2. reading and writing standards is difficult
3. theory and practice not necessarily align
As I read it:
it means any valid segment marker can be preceded by an arbitrary number of FF byte values
e.g. FF C4 should be interpreted in the same way as FF FF FF FF FF FF C4
Which make parsing the format so much more fun [I'm being sarcastic here]
jaclaz wrote:
Well, yes and no.
I thought I addressed that with the remark about it being debatable <img src="images/smiles/icon_wink.gif" alt="Wink" title="Wink" />
jaclaz wrote:
I mean, we have to decide if we are going "according to specifications", according to "values found in nature" or "according to values that can be commonly displayed", I had hoped we could get a "probability map".
As I've indicated to mscotgrove probabilities are not worth much
1. what is the sample set you base the probabilities on?
2. is the exotic/edge case relevant for your case?
So again this depends on how you interpret the standard:
* does reserved means it cannot be used? then again invalid would be more clear
* or does it mean some future variant of the format can use it
* if you want to build your parser to allow it or detect it, depends on your use case IMO, hence debatable
but to get back to assumption in software, here we have 2 areas where assumption happen
and if the tool does not point out the assumptions it is based on, can you as a digital forensic analyst rely on the tool?
jaclaz wrote:
So, if I get it right, this is your "final" map of acceptable values please do review it once again:
Code::
02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F
50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F
60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F
70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F
90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F
A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF
B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF
C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF
D0 D1 D2 D3 D4 D5 D6 D7 D9 DB
E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF
F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE
So D9 is not one I mentioned, since that would be EOI and according to the spec there should be always a valid frame (assuming I'm interpreting it correctly). But the rest looks good at first glance (though it has been a long day, so don't rely on 100% accuracy here at the moment)
jaclaz wrote:
All in all, considering that:
00 displays in Photo Editor
01 displays in both Photo Editor and jpegsnoop
DC displays in Photo Editor
FF displays in Photo Editor
And that the (new entry in the test) Irtfanview can display:
00-BF
D0-D8 and DC
E0-FF
I.e. the only values that "stop it" are:
C0-CF
D9, DA, DB, DD
So this is where probably "creative interpretation" comes into play, not uncommon for file formats <img src="images/smiles/icon_wink.gif" alt="Wink" title="Wink" />
Again what is your goal, determining the edge cases, finding images that correspond to a certain camera, trying to find this one JPEG that was fabricated to compromise your web server? You (in general) as the analyst will have to adapt to the situation, hopefully your tool is as helpful as it can get without giving you false information.
jaclaz wrote:
The three bytes pattern FFD8FF seems like a reasonable one, to "tentatively identify" a JPEG file, after which instead of checking the fourth byte, that can seemingly be *almost* any value with the exception of a handful of values, it would be smarter to look for other "typical" patterns or values.
this will depends on your use case, but the point to stress here is this a conscious decision by you (in general) as the analyst? or are you relying on the knowledge of the people that created the tool?
↧