StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
9567610
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
8
CommunityOwnedDate
CreationDate
2012-03-05T13:40:15.630
FavoriteCount
0
LastActivityDate
2012-03-05T16:52:48.810
LastEditDate
2012-03-05T16:52:48.810
LastEditorUserId
411022
OwnerUserId
411022
ParentId
9566736
PostTypeId
2
Score
5
ViewCount
0
LastEditorDisplayName
text
Body
You haven't provided nearly enough sample data for us to reliably guess even the alphabet used to encode it, much less what structure it might have. What I can tell, from the three sample values you've provided, is: <ul> <li>There is quite a lot of redundancy in the data — compare e.g. <code>width=IypcOysK</code> and <code>height=IypcLykK</code> (and even <code>watermark=ISpQICAK</code>, though that might be just coincidence). This suggests that the data is neither random nor securely encrypted (which would make it look random).</li> <li>The alphabet contains a fairly broad range of upper- and lowercase letters, from <code>A</code> to <code>S</code> and from <code>c</code> to <code>y</code>. Assuming that the alphabet consists of contiguous letter ranges, that means a palette of between 42 and 52 possible letters. Of course, we can't tell with any certainty from the samples whether other characters might also be used, so we can't even entirely rule out Base64.</li> <li>This is not the output of PHP's <code>base_convert</code> function, as I first guessed it might be: that function only handles bases up to 36, and doesn't output uppercase letters.</li> </ul> That, however, is just about all. It would help to see some more data samples, ideally with the plaintext values they correspond to. <hr> Edit: The <code>id</code> parameters you give in the comments are definitely in Base64. Besides the distinctive trailing <code>=</code> signs, they both decode to simple strings of nine printable ASCII characters followed by a line feed (hex <code>0A</code>): <pre><code>_Base64___________Hex____________________________ASCII_____ JiJQPjNfT0MtCg== 26 22 50 3e 33 5f 4f 43 2d 0a &"P>3_OC-. JikwPClUPENICg== 26 29 30 3c 29 54 3c 43 48 0a &)0<)T<CH. </code></pre> (I've replaced non-printable characters with a <code>.</code> in the ASCII column above.) On the assumption that all the other parameters are Base64 too, let's see what they decode to: <pre><code>_Base64___Hex________________ASCII_ ISpQICAK 21 2a 50 20 20 0a !*P . IypcOysK 23 2a 5c 3b 2b 0a #*\;+. IypcLykK 23 2a 5c 2f 29 0a #*\/). ISNAICAK 21 23 40 20 20 0a !#@ . IyNAPjIK 23 23 40 3e 32 0a ##@>2. IyNAKjAK 23 23 40 2a 30 0a ##@*0. ISggICAK 21 28 20 20 20 0a !( . IikwICAK 22 29 30 20 20 0a ")0 . IilAPCAK 22 29 40 3c 20 0a ")@< . </code></pre> So there's definitely another encoding layer involved, but we can already see some patterns: <ul> <li>All decoded values consist of a constant number of printable ASCII characters followed by a trailing line feed character. This cannot be a coincidence.</li> <li>Most of the characters are on the low end of the printable ASCII range (hex <code>20</code> – <code>7E</code>). In particular, the lowest printable ASCII character, space = hex <code>20</code>, is particularly common, especially in the <code>watermark</code> strings.</li> <li>The strings in each URL resemble each other more than they resemble the corresponding strings from other URLs. (But there are resemblances between URLs too: for example, all the decoded <code>watermark</code> values begin with <code>!</code> = hex <code>21</code>.)</li> </ul> <hr> In fact, the highest numbered character that occurs in any of the strings is <code>_</code> = hex <code>5F</code>, while the lowest (excluding the line feeds) is space = hex <code>20</code>. Their difference is hex <code>3F</code> = decimal 63. Coincidence? I think not. I'll guess that the second encoding layer is similar to <a href="http://en.wikipedia.org/wiki/Uuencoding" rel="noreferrer">uuencoding</a>: the data is split into 6-bit groups (as in Base64), and each group is mapped to an ASCII character simply by adding hex <code>20</code> to it. In fact, it looks like the second layer might be uuencoding: the first bytes of each string have the right values to be uuencode length indicators. Let's see what we get if we try to decode them: <pre><code>_Base64___________UUEnc______Hex________________ASCII___re-UUE____ JiJQPjNfT0MtCg== &"P>3_OC- 0b 07 93 fe f8 cd ...... &"P>3_OC- JikwPClUPENICg== &)0<)T<CH 25 07 09 d1 c8 e8 %..... &)0<)T<CH _Base64___UUEnc__Hex_______ASC__re-UUE____ ISpQICAK !*P 2b + !*P`` IypcOysK #*\;+ 2b c6 cb +.. #*\;+ IypcLykK #*\/) 2b c3 c9 +.. #*\/) ISNAICAK !#@ 0e . !#@`` IyNAPjIK ##@>2 0e 07 92 ... ##@>2 IyNAKjAK ##@*0 0e 02 90 ... ##@*0 ISggICAK !( 20 !(``` IikwICAK ")0 25 00 %. ")0`` IilAPCAK ")@< 26 07 &. ")@<` </code></pre> This is looking good: <ul> <li>Uudecoding and re-encoding the data (using Perl's <code>unpack "u"</code> and <code>pack "u"</code>) produces the original string, except that trailing spaces are replaced with <code>`</code> characters (which falls within acceptable variation between encoders).</li> <li>The decoded strings are no longer printable ASCII, which suggests that we might be closer to the real data.</li> <li>The <code>watermark</code> strings are now single characters. In two cases out of three, they're prefixes of the corresponding <code>width</code> and <code>height</code> strings. (In the third case, which looks a bit different, the watermark might perhaps have been added to the other values.)</li> </ul> <hr> One more piece of the puzzle — comparing the ID strings and corresponding numeric values you give in the comments, we see that: <ul> <li>The numbers all have six digits. The first two digits of each number are the same.</li> <li>The uudecoded strings all have six bytes. The first two bytes of each string are the same.</li> </ul> Coincidence? Again, I think not. Let's see what we get if we write the numbers out as ASCII strings, and XOR them with the uudecoded strings: <pre><code>_Num_____ASCII_hex___________UUDecoded_ID________XOR______________ 406747 34 30 36 37 34 37 25 07 09 d1 c8 e8 11 37 3f e6 fc df 405174 34 30 35 31 37 34 25 07 0a d7 cb eb 11 37 3f e6 fc df 405273 34 30 35 32 37 33 25 07 0a d4 cb ec 11 37 3f e6 fc df </code></pre> What is this <code>11 37 3f e6 fc df</code> string? I have no idea — it's mostly not printable ASCII — but XORing the uudecoded ID with it yields the corresponding ID number in three cases out of three. More to think about: you've provided two different ID strings for the value <code>405174</code>: <code>JiJQPjNfT0MtCg==</code> and <code>JikwPCpVXE9LCg==</code>. These decode to <code>0b 07 93 fe f8 cd</code> and <code>25 07 0a d7 cb eb</code> respectively, and their XOR is <code>2e 00 99 29 33 26</code>. The two URLs from which these ID strings came from have decoded watermarks of <code>0e</code> and <code>20</code> respectively, which accounts for the first byte (and the second byte is the same in both, anyway). Where the differences in the remaining four bytes come from is still a mystery to me.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POFiguring out how to decode obfuscated URL parameters
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USIlmari Karonen
UserOwnerUserId
1. USIlmari Karonen
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POFiguring out how to decode obfuscated URL parameters
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.