Revelations Ciphers, Radios, Wisps, Quotes, Letters, etc.

[Lizizadolphin]

9 minutes ago, oxin8 said:

Some form of transposition. Got a good chunk figured out:
 

 

"Thanks to the sacrifice of Maxis and the contraption called Sophia. all the 115 has been purged from the final universe. Thank fucking god. Time to get some rest. -M"

[Kalinine]

Good job! :P

Just came to my mind, what if we solved this cipher before the EE? haha

[oxin8]

5 hours ago, Kalinine said:

Good job! :P

Just came to my mind, what if we solved this cipher before the EE? haha

I don't think it was there before the EE. Did you complete the EE before finding it?

[Kalinine]

21 minutes ago, oxin8 said:

I don't think it was there before the EE. Did you complete the EE before finding it?

Nope, I didn't even shoot the graves.

[WaterKH]

1 hour ago, Kalinine said:

Nope, I didn't even shoot the graves.

 

I think what he meant was if you have already completed the main EE? (:

[Kalinine]

5 minutes ago, WaterKH said:

 

I think what he meant was if you have already completed the main EE? (:

I don't complete it on Revelations and the image is from a game where I didn't shoot the graves. But maybe Treyarch added it after the main EE was discovered and completed.

[WaterKH]

43 minutes ago, Kalinine said:

I don't complete it on Revelations and the image is from a game where I didn't shoot the graves. But maybe Treyarch added it after the main EE was discovered and completed.

 

Interesting... I wonder if they included it in a patch then. Anyways, nice find! (:

[killerpytthon105]

When i was playing Revelations, I heard the quote from Richtofen, "Accept your fate, begin a new!" and it sounded really familiar and then i remember it was the same thing he says in the die rise opening cutscene... Its probably nothing but i thought it was a cool little easter egg and might as well share it

[deamonkeeper]

maybe another flashback 

[DragonGJY]

Just being curious here. (Coz I haven't seen an edit of the radios and ciphers etc for a while)

So the ciphers of this map (Apart from the 3 we have already decrypted), are they really that hard?

 

Kinda feeling the community has gone passive and silent over the last few weeks... Hope the re-energizing would kick back soon.

[Nieno69]

10 hours ago, DragonGJY said:

Just being curious here. (Coz I haven't seen an edit of the radios and ciphers etc for a while)

So the ciphers of this map (Apart from the 3 we have already decrypted), are they really that hard?

 

Kinda feeling the community has gone passive and silent over the last few weeks... Hope the re-energizing would kick back soon.

They are that hard... they are long (what normally Should be Good) and even the transcripts are hard... but i just have not clue how To solve them... aes, rsa, pgp? Or just a Transposition in the hex/base64 code? Convert them To Decimal and divide all with 935? 

 

We dont know if the plaintext is all uppercase (would be a help To know because of the binary coding of uppercase letters) 

 

We are Jon Snow..we know nothing..

[anonymous]

On ‎27‎-‎9‎-‎2016 at 5:02 AM, killerpytthon105 said:

When i was playing Revelations, I heard the quote from Richtofen, "Accept your fate, begin a new!" and it sounded really familiar and then i remember it was the same thing he says in the die rise opening cutscene... Its probably nothing but i thought it was a cool little easter egg and might as well share it

Where did you heared this and as which character did you play?

[AetherialVoices]

35 minutes ago, anonymous said:

Where did you heared this and as which character did you play?

Ever since The Giant, Richthofen has consistently said "Embrace your fate, begin anew!"

[nayrcraig]

Took a shot at transcribing some of the new Ciphers found by @DragonGJY

 

kin_paper_torn

Spoiler

@CB?>C@F?A?>CCCG??@C>?@C@C>???G=?C?=CC@CGBC@CB?G@A?=CB?C?G<?>CB@C=
CB?<FG<?>C>C>CA?B?AGA?F?C?@CA?G=?B?G=?B?>C@B?

 

sha_paper

Spoiler

bx re yh zy bf lm kt ut yg se tb sx ky co jh km aq we tx wx cy ji ut vt kn vc gx aw ij av qn lg ef fj uq bd kn sv
cx fn je wr rk kn cg aw xq vn zf li fh vz wt ta ia ij zf eh uf tj qm yg hl yq cx ij vw ig de qz tg nj rs er vk tm sa
yv tw hr hs it vy kr qc tv gh hb jn yb qh er ut gk et cs wv jl rh xo wr ex hr xt zi kc xs qs fd wd cm ku ah fh fj
lf ui ly sh vf au xm hx qw dl gi cx vb dh wt xm kv un ej kt kt ye cg jd ef eh zv xt he uz tg cl jw nr tw ur vo jt
jo ru iq iy rz ey ho gd nq yn bq ul ai fh bu ji ho nw qg yg vj if yv zu id jc gh ke xr qf cq ra it gw dl fc gq yi iu
qu ny vr gy sj rh iu hi wr mv ym zi lk re vk xu ry uq gs ve qd yn bq ch ky er qh jr ho ya el ky zj ei hz cb if dk

 

[silver_anth]

Heres all the clear cypher images from the PC version for the main post. :)
 

 

[LackingAGoodName]

I made an Imgur Album with every Cipher from Black Ops III from the source files if anybody's interested :)

 

 

[TheHiddenSpectre]

I've been trying to do some analysis on the cipher titled undercroft_paper_torn.

 

Transcription: OkEeZHnifuMdYB1IbHyAfb0g2FJzrVmfkKcSbKrpQGvhQ0/bvu76RdnGy/WtT7T3

 

Obviously, this doesn't convert from base64 to ASCII. The analysis I've completed so far has assumed that this is indeed ASCII encoded as base64.
What I've found is that there is no way for the current base64 characters to convert to a clean set of ASCII characters, no matter the transposition method. Therefore, there must be some sort of substitution or other method of hiding the true base64 encoding. The substitution might lead to a transposition, but as it stands, I don't believe that transposition is the first step to solving this cipher. At least it's some sort of progress.

 

Here is the Google spreadsheet that I completed my analysis in. The main results are in the table titled "Possible ASCII."
undercroft_paper_torn in Google Sheets

 

 

For those interested in my analysis, I explain it below.

Since I assumed that the cipher text is base64 encoding (it is still possible that it is not an encoding, but possibly a substitution cipher instead), I was only concerned with the process to convert base64 characters to ASCII characters. In this process, a base64 char (6-bits in length) is combined with multiple other base64 chars to create a sequence of ASCII chars (8-bits in length). Since the length of both encoding types differ (6 vs 8), there is a least common denominator between them. That is 6 * 8 = 24. Therefore, to wholly convert base64 chars to ASCII chars, we need 24 bits of data on each side. This means that 4 base64 chars are needed (4 * 6 = 24) and will convert into 3 ASCII chars (3 * 8 = 24). These 4 base64 chars will be nicknamed a four-tuple in my explanation. In this four-tuple, each char gives a part of itself to an ASCII char. For char #1, all six bits are used in ASCII char 1 (nicknamed A1). These six bits form the six most-significant-bits (MSb) of A1. To complete A1, the next char in the four-tuple, #2, uses its 2 MSb to complete A1. This continues on down the four-tuple until all 3 ASCII chars have been formed. The formation would look something like this:

     #1             #2             #3            #4
1 0 1 0 1 0 || 1 0 1 0 1 0 || 1 0 1 0 1 0 || 1 0 1 0 1 0
1 0 1 0 1 0 1 0 || 1 0 1 0 1 0 1 0 || 1 0 1 0 1 0 1 0
       A1                 A2                 A3

The goal of this conversion to form an ASCII text that is readable in some sort of common language. This means that the ASCII characters seen on this table are valid if they are expected to be used in a message. This means that ASCII chars 0 - 31 are pretty much off limits (ASCII 10 and 13 have gotten some notoriety in Rev's other ciphers). Therefore, the valid range of ASCII values that I've used is 32-127 (the DEL char is still used since it makes the analysis easier). Now that we have a limit on the output chars, we can impose rules on the input chars. These rules are applied to the base64 value that is assigned to each char, as seen in this base64 table.

 

The criteria for each char in a base64-to-ASCII four-tuple are as follows:
#1: Bit 5 must be '0', therefore the value must be less than 32. Either bit 3 or 4 must be a '1', therefore the value must be greater than or equal to 8.
#2: Bit 3 must be '0', therefore #2 modulo 16 / 8 must be less than 1. Either bit 1 or 2 must be a '1', therefore #2 modulo 4 must not be 0.
#3: Bit 1 must be '0', therefore #3 modulo 4 / 2 must be less than 1.
#4: Not limited by any exclusive criterion.
#3 and #4: Either bit 0 of #3 or bit 5 of #4 must be a '1'. This causes some issues for determining char position in the four-tuple, but my analysis doesn't consider this possibility show that this cipher cannot be converted to ASCII.

 

The above criteria may seem to be worded a bit strangely, since I was doing my analysis in a spreadsheet. If I were programming this analysis in something like Python, I would use bitwise operations to demonstrate the criteria.

If we subject the cipher text to these rules, we can limit which chars are used in #1, #2, and #3. We cannot do the same for #4, since any base64 value will be valid in the fourth four-tuple position--validity is conditionally based upon the previous char value. Once we have determined which chars are valid for #1, #2, and #3, we have a set of chars left over. By process of elimination, these remaining chars are ONLY valid for #4.

 

Knowing which chars can only be used in #4 is really informative for our purposes. The reason for this is that each ASCII char is 8 bits, but since bit 7 is always 0 in our standard ASCII set (not including extended ASCII set), we reduce an ASCII char to variations on 7 bits. Since #4 will always form the six least-significant-bits for A3, we now have a lot of information about A3 and we are only missing one bit, bit-6. If we look at the possibilities for A3, we can find two possible ASCII chars (bit-6 is either a '0' or '1').

Let's look at an example from the cipher. 'u' is the 10th char and through my process of the four-tuple criteria, I have determined that this char is only available in the #4 position. Looking at the base64 value for 'u', 46 = 0x2E, I can look at the ASCII table and determine that it is either '.' (46 = 0x2E -> bit-6 is '0') or 'n' (110 = 0x6E -> bit-6 is '1').
Now, '.' or 'n' is a pretty good set of possible letters for a message. The cipher text is 68 chars long which means that it can be 48 ASCII chars long after a conversion. That is a pretty short message, considering that the previous sentence I wrote was 99 ASCII chars long. In the cipher text, there are two occurences of 'u', which means that there is a good chance that both are not '.' but maybe one or both are 'n' instead.

 

This is all fine, until you get to the char like '7' in the cipher text. I have also deduced that this char is a #4 only char. Unfortunately, the two possible ASCII chars that this char could convert into are ';' or '{'.
Neither of these are remotely likely to occur in a message. Also, '7' occurs twice in the cipher text, even further reducing the likelyhood that this cipher text is just a transposition away from a base64-to-ASCII conversion.

 

Another example is the char '/' which can convert to '?' or DEL. Seeing as there are two '/' occurences, and the fact that it would be uncommon that there are two question marks in a message further adds to the mystery.

When I look at all of the evidence discovered, I find it VERY unlikely that this cipher text can be converted directly into ASCII through means of transposition (reordering chars).

 

One thing that seems to hint at a substitution method are the last four chars in the cipher text. In many other Rev ciphers, the cipher ends with 13 10. Assuming that this is decimal, it converts into ASCII as CR LF. CR LF is a common type of line ending symbol(s) in text files.
Now, T7 and T3 kind of strikes a similar appearance to 13 10, but 7 and 3 are 4 apart rather than 3. Therefore, it's not a simple subtitution like ROT13. What I find interesting is that while 13 and 10 are 3 away, the letters r and n are 4 away. Here, I am replacing CR LF with the programming version of these line endings "\r" and "\n". A programmer would use both of these to indicate a CR LF line ending in a program's code. This bears a closer resemblence to T7 T3 seen in the cipher text.

 

While I haven't come any closer to determining a substitution used, having a crib (jargon for a cipher-to-plain text hint), albeit small, can help a long ways towards solving a cipher.

[Shootinfish]

@TheHiddenSpectre Nice write up and I understand it.I used these methods to find out if transposition only or subsitution only on TheGiant cipher and worked out neither was possible

 

The undercroft cipher

 

I can rule out

1. Transposition only

2. Vigenere using standard b64 order alphabet and still being in s B64 format ready to decode

3.Mixed case Ascii mono subsubtution

" I cant totally rule out or manually plot ascii mixed case and numbers but doesnt seem likely "

 

That's why I was looking into finding a pattern or keylength with xor and trying to automate it.

 

Do you think this method wont work to test if a key  (4-10) characters has been xored to encrypt B64

 

[TheHiddenSpectre]

On 11/2/2016 at 11:20 AM, Shootinfish said:

That's why I was looking into finding a pattern or keylength with xor and trying to automate it.

 

Do you think this method wont work to test if a key  (4-10) characters has been xored to encrypt B64

 

Sorry for the late reply, but better late than never. Right?

 

While I'm not saying that it isn't possible to automate the cracking of an xor key, you are probably going to run into trouble.

 

First, base64 has 64 possibilities for each character of the key. Given an assumed max key length of 10, there are 64^10 possibilities of a key. That's 1.152 quintillion possibilities for a key. If I did my math correctly, if you assume each key check takes 10ms, it would take over 365 million years to finish the task.

 

Secondly, an issue with xor keys is that they have a tendency to allow for any possible resulting text. For example, let's say I want to hide the word "CATS". I want to use the key "DOGS" to encrypt the message. The result after an ASCII xor would be 0x07 0x0E 0x13 0x00. If you were given such a cipher text, you could apply "CATS" as a key and you would get "DOGS" as a result. Basically, the xor operation is reversible in multiple ways, so you wouldn't know if "CATS" is the key of if "DOGS" is the key, since they both produce the other. Take that to a larger scale, and you end up with a message with "Perfect Secrecy."

See: https://en.wikipedia.org/wiki/One-time_pad#Perfect_secrecy

 

In the end, you would have a hard time sorting through the results because so many would contain potential plaintext messages.