At first I thought it was just Base64, but decoding that didn't give me anything that made sense.[EDIT]: should mention that I know pretty much nothing about ciphers, so I might have done it wrong... if that's even possible.

Last edited by Leviathan on Thu Apr 28, 2016 6:30 pm; edited 1 time in total (Reason for editing : new information)

I only suspect that base64 is involved because of the == at the end, which is usually used in base64 messages to serve as padding.

I think the solution will probably involve doing some kind of decryption on the letters and then running that result through a base64 decoder. But it's also entirely possible that base64 isn't needed at all.

Also really weird: the message seems to follow the pattern that you are talking about except for that one spot. Maybe that K was intended to be an O?

Final note, with the exception of a few spots, those letters from the 4f\5f]5e]5f]5e]5e\5e\4e]4fm5e\5e]4faEe\5f]4e\4f\4f\4e]4f]4f\4v\4f\5e\4 piece are letters/numbers used in hexadecimal

okay, i've been pouring over all sorts of cryptography forums since 5, and i've reached a couple conclusions on this one:

-it is actually a base64 cipher, or at least it should be. this conclusion is primarily based on the fact that it definitely is formatted to work with the base64 conversion method.-that said, there is f*ckery afoot. Something is pushing the bit values a good deal higher (at least I'm pretty sure it's higher) than it would be to deliver a purely plaintext response. I suspect it's some sort of Ceasar or translation of some sort. -it's possible those first two conclusions are total bull, and this is actually supposed to give an actual number value, OR (arguably the more likely of the two) I'm so far from the real solution that the water in the drains here is spinning counterclockwise.

Hey everyone, what you guys are thinking about sounds like a good starting point...so I attempted the puzzle myself. I tried using one of my own cipher techniques and with my attempt, I was able to get "101" for one of the sections. Is that of any help...?

Ok, that knocks some pieces off the board. So we know A) the end goal is either a regular decimal value or a binary (likely one word or value all put together) B) 101 or 5 (binary) is the end result for one of the sections and C) not to argue semantics but she said "one" section specifically, so i'm thinking that means most of the answers are unique, and that of them one should end up at 101. The one issue is us not knowing what a defines a section. I'm assuming it's one of the four digit groups though.

[EDIT]: cipher series: LunarShucks cipher 1 --> base64 --> binary --> decimal returns with a batch of values, one that repeats a few times is 101.

I can't stay at my computer long enough to solve it right now, but here's some good progress: 101 in base64 is MTAx. MTAx under a rot 2 cipher is OVCz. We have an OVCz in the original cipher. So if we put the given cipher under the inverse (a rot24) we get this base64 string:

To me it suggests that each block is a word rather than a couple of letters. That's pretty significant because an ascii character needs a whole 8 bits to be represented. Therefore, we only have about 8 and a half ascii letters worth of binary here. That's not really enough to make a very meaningful message, and wouldn't really make sense with the comma or spacing.

I tried converting this into morse code (using 1 as a - and a 0 as a ., and then tried the inverse).That doesn't work either.

When I translate it into decimal from binary, I get four numbers (9 digits total), it's not a zip code, IP address (unless the goal is in Beijing), phone number, or atbash, but it looks simple enough to mean something. It is a valid SSN, but I seriously doubt that's relevant.

Leviathan wrote:When I translate it into decimal from binary, I get four numbers (9 digits total), it's not a zip code, IP address (unless the goal is in Beijing), phone number, or atbash, but it looks simple enough to mean something. It is a valid SSN, but I seriously doubt that's relevant.

122 78 75 87

How did you get those numbers (Specifically the first and third)? When I translate the binary chunks into decimal I get the following: