Talk:PAX USB Drive

From IFWiki

This is the talk page for PAX USB Drive. See How to edit IFWiki to find out about using talk pages, and editing the wiki generally.


On April 1st 2013, @babyjarson tweeted this:

 677572776r70..4n4r5n6r77??2q5250654844526s4572433848716548506r..

Although the date suggests a prank, I haven't found any analysis of this anywhere. So I thought I'd take a shot, and this is what I got so far.

The message has 64 chars. Breaking into 2-char groups, we have these 32 groups:

 67 75 72 77 6r 70 .. 4n 4r 5n 6r 77 ?? 2q 52 50 65 48 44 52 6s 45 72 43 38 48 71 65 48 50 6r ..

This reminded me of @babyjarson's early tweet:

 32 chars, upper+lower+digits+symbols, totally random. patience!

Most of it looks a lot like printable ASCII, so first I tried partially converting it according to decimal values (the unknown ones, with letters or symbols, are temporarily replaced with "_").

 C K H M _ F _ _ _ _ _ M _ _ 4 2 A 0 , 4 _ - H + & 0 G A 0 2 _ _

Looks promising; letters, digits and symbols. I then thought that maybe the letters in the message - "n", "q", "r" and "s" - were representing arbitrary numbers, and we would have to brute-force them to find the correct ones. There are a few problems with this interpretation, however.

  1. So far it only shows uppercase letters and, in decimal ASCII, lowercase letters start at 97 ("a") and most of them are three-digits. So no lowercase letters would be present in the final decoded string (unless "??" and ".." are lowercase letters).
  1. The "2q" symbol would be very hard to reproduce in a RAR password, since decimal values 20-29 represent control codes (I think it wouldn't really be possible to use these on a RAR password, but I could be wrong).

So I thought of the hexadecimal values. All printable ASCII hex values are two-digit, and all the values present in the original message would be printable ASCII if they're hex. Also, hex allows for a possible interpretation of the letters: usually the letter group used to represent [10, 11, 12, 13, 14, 15] is [a, b, c, d, e, f], but what if he's using [n, o, p, q, r, s]? In that case, we could further decode the message into:

 g u r w n p .. J N Z n w ?? - R P e H D R o E r C 8 H q e H P n ..

Which gives us more letters and one symbol (a dash). So now we have all the elements: upper/lowercase letters, one digit and one symbol. The last pieces of the puzzle are the ".." and the "??". My hypothesis are that:

  1. Both instances of ".." represent the same character;
  1. The characters for ".." and "??" are unique in the original message, meaning they're not something that's already there.

Initially I thought that maybe the fact that both symbols are duplicated, it meant that it was a duplicated number like 22, 33, etc. However, I tried all combinations of 22 (\"), 33 ("3"), 55 ("f") and 66 ("w") - not 44 and 77 since they are already in the message - and it didn't work.

So, this is where I stopped. My next step is probably to bruteforce all possible printable ASCII chars that are not in the message as values for ".." and "??". Please feel free to contact me if you read this and have any ideas.

Rmartins (talk) 18:18, 6 October 2015 (UTC)

Don't forget to ROT-13 all that !

Then finding the password will be very easy.

The content is another (unprotected) rar file:

59673452 Apr 1 2011 info.rar

Alegiassi (talk) 16:27, 26 May 2021 (UTC)

Finding the password step by step

start: 677572776r70..4n4r5n6r77??2q5250654844526s4572433848716548506r.. (and a #WAM)

ROT-13: 677572776e70..4a4e5a6e77??2d5250654844526f4572433848716548506e.. (looks like hex ASCII, except for '..' and '??')

string: gurwnp.JNZnw?-RPeHDRoErC8HqeHPn. (with '.' and '?' to be determined; Rmartins 2015)

ROT-13: thejac.WAMaj?-ECrUQEbReP8UdrUCa.

password: thejac#WAMaj?-ECrUQEbReP8UdrUCa# (from #WAM in tweet / brute force)

Alegiassi (talk) 07:28, 29 May 2021 (UTC)