A while ago, a diligent researcher named gsgs solved a mystery that had been bugging me. The placement of the bitmap text layers appeared to be ‘random’ and while it was clear that two sides ended at the edge of where the text ended, the two other sides extended further.
This seemed like a random placement which one may expect from a forger but not from an algorithm
gsgs observed that the top and right hand sides perfectly aligned with 8 bit boundaries. And this was relevant since jpeg takes 8×8 bit chunks to do its ‘magic’.
gsgs placed his findings here and provided us with many useful tools to analyze his findings.
For Hermetian’s benefit I will copy gsgs’s observations because he appears to be confused about gsgs’s findings and his observations that they do not align with 16 bit boundaries.
Seems to me that this “imprecise boundaries” -problem is due to an alignment to 8×8-blocks. This is about the selection of the sizes of the 8 textlayers and their exact position inside the total picture of the WH-pdf. The left and bottom borders of the layer-boxes are always touched by pixels and the right border is touched in img1 and img7. If you calculate (x,y) of the position, where that layer fits into the whole picture and add to it the size of the layer-pic, then you get 0 (mod 8 ) in all 16 cases. So this choice was also likely done by a computer, not a human.
Apparently the program selected the letters/components that did match some color-range and grouped them into a layer. The borders of those layers were always aligned to the 8×8-grid of the whole picture. Then the empty lines at the left and bottom (bottom and right before rotating – all the pics were rotated for some reason) were deleted to save space. This was independent of the 8×8 blocks used for the DCT compression, though. To match that alignment we would need 16×16-blocks for the text-layers because of the double resolution, but it doesn’t align to 16×16
The table he presents requires some math which may cause concern to some of my readers but no worries.
(a) (b) (c) 1, 1819×1454,( 373, 970) 2, 778× 199,(1270, 257) 3, 274× 42,( 710, 334) 4, 228× 123,(1836,1021) 5, 216× 47,( 432,1017) 6, 70× 34,(1458,1310) 7, 217× 243,( 735, 533) 8, 142× 132,(1050,3140)
(a) is the number of the layer, (b) its size and (c) its coordinates from the lower left hand corner. Size and position add to (0,0) mod 8
First observation is that the coordinates themselves do not show any pattern however when adding the size to the position we find the coordinates for the top and right.
Let’s do the addition.
(a) (b) (c) 1, 2192x2424, 274x 303 2, 2048x 456, 256x 57 3, 984x 376 123x 47 4, 2064x1144, 258x 143 5, 648x1064, 81x 133 6, 1528x1344, 191x 168 7, 952x 776, 119x 97 8, 1192x3272, 149x 409
(a) is the number of the layer, (b) the sum of the coordinates and the size (c) when divided by 8
You can quickly observed that several of these do not align to 16×16 bit layers.
gsgs then observes how
the upper right corner becomes upper left in the original rotation. All 9 layers are rotated by 90° counterclockwise and color inverted in the WH-pdf. I assume that they were always handled in this format by the software. Then there must be some additional instructions in the pdf how to rotate,invert,expand and overlay the 9 layers. This is presumably encoded in one of the 3 additional bitstreams, I haven’t studied the pdf-format yet.
However, it seems that all the manipulating was done in that rotated and inverted form, which a human forger would not do. It’s just uncomfortable. But, of course the human forger could have rotated and inverted it after the work was done so to confuse the birthers But then they assume a silly forger who makes mistakes.
He was right, the PDF file contains exactly those instructions to rotate, expand and invert. Why a forger would work with rotated objects is something the ‘researchers’ have never explained… This is typical for most claims of forgery… No plausible or credible explanation is given.