Don't Be Afraid Of The Dark

Question

This puzzle follows the convention that anything outside a quote is flavour text.

So last night I left my computer running. You know - when computers get older they want to bend the rules a bit. Don't go to sleep when you tell them to and so on. I didn't feel like discussing it with them last night. I guess they pulled an all-nighter.

Anyway, I woke up today with this console window open on my desktop. What happened last night? Is this dangerous? Help!

 

The puzzle

I think this is some kind of homebrew program. Just converting it to ascii does not yield anything useful, but you know what they say about homebrew algorithms in cryptography. Can you tell me what is sent back and forth? And not just the actual data?

========================================================
 .--.  .--.  .--. .-..-.  .-..-. .--. .-..-. .--. .---.
: .; :: .--': .--': :: :  : `' :: .--': `: :: .--': .; :
:    :`. `. : :   : :: :  : .. :`. `. : .` :: : _ :   .'
: :: : _`, :: :__ : :: :  : :; : _`, :: :. :: :; :: :.`.
:_;:_;`.__.'`.__.':_;:_;  :_;:_;`.__.':_;:_;`.__.':_;:_;
========================================================



Booting................... Done
Node 86 ready
[19:44] Listening for connections...
[23:43] Connection accepted.
SIGTERM

Transcript follows


 O> 0x2ba85ef23e0480b8L
<I  0x2feef54ee0823cc4L
[Authentication succesful]
<I  0x29a74761bd3c1f067a3342a85a7afebbe4500504110414014500L
<I  0x28494451e73da8f700af10404514400110500504110414014500100114414010410504500400114400104014410104110404404014014110404510010110L
 O> 0x1cf014e6e014e7f054fb10404514400110500504110414014500100114414010410504500400114400104014410104110404404014014110404510L
<I  0x2358e611b083e5a97e405142addf3159f43b62fcf61940e5faf8f51840a583602ceb0450040011440010401441010411040440401401411040451001011011040050000410041050401041410450010051041400441010040401010411010440440010040050051401000451000451000011010040441040011041010400441401410050050400011441040410400001401010041040400441050400401000051050451001410000000041040400010040011441011410010051441001001010010441011011000441441410040000411400000450040050040410410000411400401001010001000411450040041040001400050000041010451010401401000401040051401001400050L
<I  0x2ea53a0b1023fc141141104045144001105005041104140145001001144140L
 O> 0x3514
<I  0x3514510504510414114110404514400110500504110414014500100114L
[WARN] No data
<I  0x2db95445a8b00a1b73fc6483bdf12c4ff4efeb0411041401450010011441401041050450040011440010401441010411040440401401411040451001011011040050000410041050L
[ERR] Unauthorized message
<I  0x3b23aa98ebbd1814114110404514400110500504110414014500100114414010410504500400114400104014410104110404404014014110404510010110110400500004100410504010414104500100510414004410100404010104110104404400100400500514010004510004510000110100404410400110410104L
[Remote host closed connection]
 O> 0x255461a690450414114110404514400110500504110414014500100114414010410504500400114400104014410104110404404014014110404510010110110400500004100410504010414104500100510414004410100404010104L
[No route to host]
 O> 0x252e40d76645041411411040451440011050050411041401450010011441401041050450040011440010401441010411040440401401411040451001011011040050000410041050401041410450010051041400441010040401010411010440440010040050051401000451000451000011010040441040011041010400441401410050050400011441040410400001401010041040400441050400401000051050451001410000000041040400010040011441011410010051441001001010010441011011000441441410040000411400000450040050040410410000411400401001010001000411450040041040001400050000041010451010401401000401040051401001400050450040L
[No route to host]
<I  0x2db95445a8b00a1b73fc6483bdf12c4ff4efeb0411041401450010011441401041050450040011440010401441010411040440401401411040451001011011040050000410041050L
[ERR] Unauthorized message

Process killed

I prepared a CSV for you

O,2ba85ef23e0480b8,
I,2feef54ee0823cc4,[Authentication succesful]
I,29a74761bd3c1f067a3342a85a7afebbe4500504110414014500,
I,28494451e73da8f700af10404514400110500504110414014500100114414010410504500400114400104014410104110404404014014110404510010110,
O,1cf014e6e014e7f054fb10404514400110500504110414014500100114414010410504500400114400104014410104110404404014014110404510,
I,2358e611b083e5a97e405142addf3159f43b62fcf61940e5faf8f51840a583602ceb0450040011440010401441010411040440401401411040451001011011040050000410041050401041410450010051041400441010040401010411010440440010040050051401000451000451000011010040441040011041010400441401410050050400011441040410400001401010041040400441050400401000051050451001410000000041040400010040011441011410010051441001001010010441011011000441441410040000411400000450040050040410410000411400401001010001000411450040041040001400050000041010451010401401000401040051401001400050,
I,2ea53a0b1023fc141141104045144001105005041104140145001001144140,
O,3514,
I,3514510504510414114110404514400110500504110414014500100114,[WARN] No data
I,2db95445a8b00a1b73fc6483bdf12c4ff4efeb0411041401450010011441401041050450040011440010401441010411040440401401411040451001011011040050000410041050,[ERR] Unauthorized message
I,3b23aa98ebbd1814114110404514400110500504110414014500100114414010410504500400114400104014410104110404404014014110404510010110110400500004100410504010414104500100510414004410100404010104110104404400100400500514010004510004510000110100404410400110410104,[Remote host closed connection]
O,255461a690450414114110404514400110500504110414014500100114414010410504500400114400104014410104110404404014014110404510010110110400500004100410504010414104500100510414004410100404010104,[No route to host]
O,252e40d76645041411411040451440011050050411041401450010011441401041050450040011440010401441010411040440401401411040451001011011040050000410041050401041410450010051041400441010040401010411010440440010040050051401000451000451000011010040441040011041010400441401410050050400011441040410400001401010041040400441050400401000051050451001410000000041040400010040011441011410010051441001001010010441011011000441441410040000411400000450040050040410410000411400401001010001000411450040041040001400050000041010451010401401000401040051401001400050450040,[No route to host]
I,2db95445a8b00a1b73fc6483bdf12c4ff4efeb0411041401450010011441401041050450040011440010401441010411040440401401411040451001011011040050000410041050,[ERR] Unauthorized message

 

Final notes

I wish to thank network-science.de for providing this tool.

The general strategy of solving this puzzle can be layed out by hand, but I expect that a computer is needed to handle the awefully large hexadecimal numbers for true decryption. Please note that a long in Python does not have a maximum length, which can help if you wish to write something.

 

Hints

Hint 1 (17 december 2016):

This is a homebrew algorithm, intended to be cracked. Homebrew algorithms usually work well for normal cases, and produce interesting behaviour for edge-cases.

Hint 2 (20 december 2016):

No seriously, there is a sequence somewhere. Unless you plan to encode your own messages, you don't need to know how to generate it. Once you figured that out, you can simplify the problem.

Hint 3 (22 december 2016):

Almost nothing in the output of this program is there without a reason. Some of it is to help you find the correct answer after decoding, and some of it is to help you break the decoding. To encode a message, you need to perform two steps.

Hint 4 (22 january 2017):

You have all the information needed to decode one half of the conversation. While doing that you will obtain enough information to decode the other half. There are some questions you might want to ask yourself:

• How could the program deduct if a message was sent from the correct node? What is a computer good at?
• Why were you able to find the whole sequence in one of the messages? What does this tell you about the nature of the scheme that is used?
• The message is still unreadable after the sequence has been "removed". What information could the sender have used to encode it, that is also known to the receiver to decode it?

After you have the conversation, the title can serve as a clue to help you search in the right direction - not just as an obscure reference to the framing of this puzzle.

Answer 1

My first observations:

It appears to me that we have hex messages, right padded with zeroes to some length, and then salted with a pattern of 0, 1, 4, and 5.

After the first 12 characters, at least three messages share the same values until they terminate. In the comments to this answer, TusanHomichi noted that this pattern corresponds to the binary indexes of the primes (zero-indexed). So, the full "salt" is:

351451050451041411411040451440011050050411041401450010011441401041050450040011440010401441010411040440401401411040451001011011040050000410041050401041410450010051041400441010040401010411010440440010040050051401000451000451000011010040441040011041010400441401410050050400011441040410400001401010041040400441050400401000051050451001410000000041040400010040011441011410010051441001001010010441011011000441441410040000411400000450040050040410410000411400401001010001000411450040041040001400050000041010451010401401000401040051401001400050450040

To remove this salt, there are a couple options:

• subtract: (raw + salt = cipher), so (cipher - salt = raw)

• xor: (raw ^ salt = cipher), so (cipher ^ salt = raw)

Since the add/subtract method requires a convention for handling overflows, let's assume it's xor for now.

After removal of the salt (via xor) we get the following:

O 1ebc0ff73a5584ac
I 1afaa44be4d338d0
I 1cb31664b96d1b126b7252e81f6ebebaf4000000000000000000
I 1d5d1554e36cace311ee00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
O 29e445e3e445e3e445ba00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
I 164cb714b4d2e1bd6f014102e8cb7158e46b67f8e71d54e4bff8e51954e4c3706dee0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
I 1bb16b0e1472f8000000000000000000000000000000000000000000000000
O 0000
I 0000000000000000000000000000000000000000000000000000000000
I 18ad0540ace10e0f62bd74c3f8e56c4ee4bfee0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
I 0e37fb9defec1c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
O 104030a394140000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
O 103a11d26214000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
I 18ad0540ace10e0f62bd74c3f8e56c4ee4bfee0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

So, presumably, the unsalted bits can be easily decrypted, but I've had no luck yet. Also, presumably, there is some significance to the lengths of the messages, but I've yet to find out how.

Methods I've attempted to decode without luck are (though not fully exhausted):

- Bacon's cipher
- 8-bit ASCII
- 5-bit ASCII (adding 010 or 011 to the front)
- Prime factors of the hex, with or without the extra zeroes
- Direct conversion to other bases (base-26 [a-z], base-36 [0-9a-z]), then alphabetic cipher

The first few require some form of padding, since the lengths aren't always nice multiples. The others seem to be a bit far-fetched.

There are some other numbers that, per hint #3, are worth investigating, in some rough order of suspicion from my point of view:

- 86 from the node number
- 19 from the number of dots while booting
- 19, 44, 23, 43 from the timestamps
- 15 from the standard value of SIGTERM

Unanswered questions (I'm not expecting direct answers from OP, these are just things that I haven't fully solved. I've listed the assumptions I'm making where applicable. If they spark a hint, however, I wouldn't complain.)

1. Does a arithmetic operation need to be performed before decoding? I assume no, but have tried a few things, like multiplying all messages by the length of the message (including the number of zeroes at the end).
2. Is padding necessary and if so, how is it done? I assume yes, and by adding leading zeroes.
3. Is base conversion required? I assume we'll only need binary and hexadecimal, but I have also tried a couple other bases as described above.
4. Is each 'letter' the same length? Yes, we are using fixed-length ASCII.
5. What is the significance of the other numbers in the full text? I assume they mean something, but I haven't figured out how to put them to use.

Answer 2

As people seem to have lost interest in this puzzle, this is the answer and the intended way of solving this problem.

Lets first start with some basic information

The title states that this is ASCII MSNGR. It's safe to assume that we are communicating in ascii.

The puzzle links to a security.se question that states that homebrew algorithms should not be expected to provide any security than obscurity. In other words, we should assume that the algorithm used here is flawed.

The footnotes mention that long variable type. That is a number. Perhaps we can do math.

When we examine the transcript, we notice the following:

There is a part before [Authentication succesful] that looks vastly different than the part after it. We can assume that the part before this message is done with limited knowledge.

There are various status messages in the text surrounded by [ and ]

There is some form of authentication going on. The system is able to figure out when a message is sent by a third party based on the message.

There are two identical messages. This suggests that the algorithm is deterministic. (The same input produces the same output)

---

With this information, let's do this:

The message that gave the error "No data" is an interesting sequence. We can identify this as a sequence of bits where the bit is 1 of the number is prime, and 0 if it is not. In other words, it is a deterministic, but for us pseudo-random sequence.

Futhermore, this gives us this information

If a message is empty, whatever else the algorithm is doing does not produce any output if the message is empty. This eliminates a lot of possible complicated algorithms.

So let's use this number:

There are various ways we can combine this number with the rest of the output from the algorithm. One could just append part of the sequence to the output, but why cut off the first couple of bits? Alternatively, we can do arithmetic, but multiplication would lead to 0x0 for an empty message, division sounds like it would fail most of the time. And addition and subtraction would lead to an unrecognisable sequence.

Then there are bitwise operations. Bitwise and and bitwise or would lead to lots of zeroes or lots of ones, but the message seems to be quite balanced. So let's use bitwise exlusive or, like many other algorithms use.

But this does still not lead to anything useful on the top two messages, our most likely candidates. There is however more information in the puzzle...

The output starts with Node 86 ready. Can we use this number? We can probably use arithmetic here. If we use division, we get our first clue:

msg2 = long("0x2feef54ee0823cc4L", 0)
prime = long("0x3514510504510414", 0)
unsalted_msg2 = msg2 ^ prime
msg2_without_destination = unsalted_msg2 / 86

#Num to ascii converter borrowed from https://stackoverflow.com/a/42498359/2209007
''.join(chr((msg2_without_destination>>8*(100-byte-1)&0xFF) for byte in range(100))
#\x00\x00.........PONG 98

That... looks useful. Let's do this same trick on the other message

msg1_without_destination = (msg1 ^ prime) / 98
''.join(chr((msg1_without_destination>>8*(100-byte-1)&0xFF) for byte in range(100))
#\x00\x00.........PING 86

So, now we are getting somewhere. In fact, it turns out that using this same trick, we can decode every message, resulting in the following transcript.

O PING 86
I PONG 98
[Authentication succesful]
I Unfaithful woman
I Who is he
O mnmmnmmnm
I Baby, don't you lie to me no more
I Robert
O (empty string)
I (empty string)
[WARN] No data
I It's because of me
[ERR] Unauthorized message
I SLAM
[Remote host closed connection]
O sob
[No route to host]
O cry
[No route to host]
I It's because of me
[ERR] Unauthorized message

---

Solving the actual puzzle

Those messages are... interesting. They do not make a great deal of sense in a chatroom-like environment. Google or general knowledge will come in handy here

The transcript mentions several parts of sentences. If you put the first few in Google, it will rightfully guess the lyrics of a song.

Which leads us to the answer:

Right Next Door (by Robert Cray)

---

Understanding the rest better

Now that we know what the answer is, let's find some other clues?

The title is strangely capitalised. This happens more often, for example in the song title we just found. It turns out to be another song by Robert Cray.

Just above the transcript we see [23:43] Connection accepted..

This corresponds to the lyric text "Around midnight I hear him shout unfaithful woman".

There are some unauthorised messages. Besides that the content of those messages is a big clue to the answer of the puzzle, we find that they differ in a specific way from other messages.

The system determines if a message could be by the sender by doing a simple modulo. If the result is 0, we pass. If it isn't, there is a third party sending us messages. If we would try to reverse engineer the id of the third party, it could be 13, 16, 26, 52, 71, 104, 113, 142 or 199. The system is far from fool-proof.

This is also the reason why we need a pseudo-random number. We just try more and more of the sequence in an attempt to find a number that is divisible by the node number.

There are messages with "No route to host".

The lyrics say "I can hear him slam the door and walk away". The subsequent messages are sent ("Right next door I hear that woman start to cry"), but the husband can not hear it.

When we look at the first two messages, we can see that the protocol in itself is a bit silly. If it weren't for this puzzle, the two first messages would be omitted.

The messages require the node number of the other to work. The exchange of node numbers is solely to help people decode things, not because the nodes themselves didn't have that information already.

---

Anyway... enjoy.

https://open.spotify.com/track/2FSX4cB1qIdXHKlVTddwjw

Answer 3

Since the OP has requested partial answers, here is what I have. It isn't much.

The most obvious features are:

First: after the first shortish portion of each message, the remainder is very sparse -- most of the bits are zeros -- and most of the gaps between 1-bits are of odd length. (But not of consistent length mod 4, or always prime, or anything like that that I've noticed.) This suggests treating the pair of bits as the basic unit (I wrote W=00, X=01, Y=10, Z=11) and then counting runs of Ws separated by (as it turns out) Xs. The longest run is of length 16, but most are substantially shorter. Some have length 0 (i.e., there are two consecutive Xs).

Second: there is a lot of repetition both between and (to a lesser extent) within the sparse parts of the messages. Perhaps the server is echoing back data submitted to it, in addition to whatever other networky things it may be doing. And perhaps some of those repeated sections are protocol boilerplate of some sort.

Third: Those initial two messages look like a challenge/response pair, but it's hard to believe there's enough information to figure out what's going on.

Here, in case it is of any use to anyone, is what you get by

pairing bits to yield, er, quits W,X,Y,Z as defined above, turning runs like WWXWWWWWWXWW into things like <2,6,2>, and identifying -- by hand, ad hoc, and unreliably -- repeated sequences. The names are arbitrary.

O WYYZYYYWXXZYZZWYWZZYWWXWYWWWYZYW
I WYZZZYZYZZXXXWZYZYWWYWWYWZZWZWXW [Authentication succesful]
I WYYXYYXZXWXZXYWXYZZXWZZWWXZZWWXYXZYYWZWZXWWYYYYWXXYYXZYYZZZYYZYZZYX<1,0,4,0,FOX,4>
I WYYWXWYXX<1,SEP>XZYXZWZZXYYYWZZXZ<4>YYZZ
O WXZWZZ<3,0,1>ZYXYZY<3,0,1>ZYXZZZ<2>XXXWZZYZ
I WYWZXXYWZYXY<1,1>XYZ<2>Y<2>ZZYXXYYYXXZZYX<3,0,1,0,2>YYYZXZXZZWZWXXXYXZZX<2>ZYZXYWYZZZWZZXYWXYXX<3>ZYXXZZYYZZYWZZXXWXY<1,3>YYXXY<2>ZXY<3>YZWZYYZ<2,1,0,RAT,FROG,DOG,COW,HORSE>
I WYZYYYXXWZYY<2>YZ<1,3>YWZZZZ
O WZXX
I WZXX [WARN] No data
I WYZXYZYXXXX<1,1>XXYYYWYZ<4>YYWXYZXZWZZZZWXYXWY<2>ZYZZXZZ<1,1>YZ<1,1>ZZZZXWZYZZZYYZ [ERR] Unauthorized message
I WZYZWYWZYYYYYXYWZYYZYZZXWXY [Remote host closed connection]
O WYXXXXXWXYWXYYXYYX<2,1,0,2,BAT,PIG,CAT,DOG,1> [No route to host]
O WYXXWYZYX<3>ZXXZXYXYX<1,0,2,BAT,PIG,CAT,DOG,COW,HORSE,1,0,4,3> [No route to host]
I WYZXYZYXXXX<1,1>XXYYYWYZ<4>YYWXYZXZWZZZZWXYXWY<2>ZYZZXZZ<1,1>YZ<1,1>ZZZZXWZYZZZYYZ [ERR] Unauthorized message

where

BAT=2,0,2,1,0,2
PIG=1,2,3,SEP,0,1,6,1,2,0,4,0
CAT=FOX,HEN,2,0,4,2,2,2,0,2,1,0,RAT,FROG
DOG=MOUSE,4,2,2,0,2,2,1,0,5,4,0,1,2,2,0,5,1,2,3,4,3,4,3,2
COW=2,1,3,2,1,3,1,6,4,5,0,4,0,1,0,RAT,6,SEP,9,1,3,4,3,1,2,2,6,1,2,2,3,2
HORSE=5,1,2,0,4,0,2,4,0,4,0,2,8,SEP,2,2,3,2,2,10,0,4,3,4,2,2,3,5,1,2,2,0,2,5,4,8,FLEA,SEP,5,0,2,16,2,2,3,8,RAT,2,3,1,0,2,5,4,0,SEP,2,5,5,3,5,2,1,2,3,1,3,1,6,1,2,FLEA,4,9,2,1,0,11,1,0,4,5,0,4,3,2,2,2,8,2,1,0,5,4,5,3,7,6,2,SEP,0,4,5,2,2,8,0,7,0,10,2,3,2,SEP,3,2,4,0,4,6,4,2,5,0,1,0,4,5,0,7,0,2
MOUSE=5,3,1,3,1,2,5,0,8,2,4,2,2,0,2
FOX=2,2,1,2,2,0,4,0,1,0
HEN=5,5,SEP
RAT=4,6,SEP
FROG=6,2,4,0,1,2,3,2,2,1,2,3,1,3,4,0,4,0,2,1,2,3,SEP
FLEA=0,1,2,0,2
SEP=1,0,1

Answer 4

I just took a quick look at this, although I haven't spent a lot of time on it.

If you use that ASCII converter, you can use the Fuzzy font to get the same font as the ASCII MSNGR at the top.

Given the hint of using that tool (I presume this isn't spoilers; we wouldn't be given that tool if we weren't supposed to use it, I presume), I think we're supposed to do that.

Then we get a sequence of various punctuation marks which we're supposed to decode into something sensible, I presume.

The question is how to decode the hex given in the problem into the correct input to put into the tool, and then how we take the output of the tool to turn into something else sensible.

My guess is we're supposed to convert the hex into some other common format. My guess is either text, decimal, or binary. I tried decimal and binary though and didn't get anything that looked useful. Another guess I have is that the first line is a password dialog and the second line is the password in raw text, for some definition of "raw text", which is to be used as a partial cipher in some sort of replacement cipher type of scheme. However, I have no idea how to use it.

Also...

I have a feeling it's a Shakespeare quote. I think those 4 long lines at the bottom have repeated phrases, I'm looking for the delimiters on them to try to find where the phrases begin and end.

Another piece of information I think is useful:

After a bunch of hex preamble, each message is encoded using only the numbers 0, 1, 4 and 5. Presumably that is the "text" portion of the message, and the hex preamble has some other function, which I haven't figured out.

Random brainstorming: 1)

The fact that the short message 3514 is immediately followed by another message that begins 3514 is no coincidence.

2)

I have to believe that the message responses mean something. I'm not sure what, but something.

3)

Based on the hint that the Homebrew encryption produces some interesting edge cases, my guess is that there's a red herring somewhere where the encryption algorithm uses some salt, but due to some edge case weirdness, part of the encrypted message melds with the salted portion to make the salted portion look longer than it actually is. Credits to the post below this one for reminding me that salting is a thing that people do. My guess for the weird message is the one immediately following 3514.

4)

As mentioned elsewhere, it is likely that salting is used. I believe that the authentication question and answer (the first 2 lines of the communication) in some way conveys from the server to the client the salting procedure if you compare them in the correct way. The question is, what is the correct comparison? I've tried adding them together, subtracting them from each other (in both orders), and XOR, and found nothing so far.