-1

(sorry in advance, I have no idea where to put this)

I'm part of a team working to figure out something in an ARG currently happening. The person running this ARG gave us a link to a pastebin that was a text dump of a gif (like if someone opened it in Notepad and then copy-pasted it)

I've tried saving the raw file as a gif, among other things, but nothing works. Taking a file I know is a gif, saving it as a text file, and then trying to save that as a gif gives me the same issues (which makes sense). Google hasn't been helpful at all in me figuring out what to do

Does anyone happen to know of any tools that can help me?

EDIT for clarification:

Here is the pastebin in question: https://pastebin.com/sQNc0Bsr An ARG is an Alternate Reality Game- basically it's a kind of story that someone uses real-life platforms to tell, but sometimes it's played out so that others have to uncover certain things before the story progresses. Some examples are the Youtube series about Slenderman, like MarbleHornets

I didn't create the pastebin, but I took a picture that was a gif and opened it in Wordpad/Notepad to see what it looked like, to compare with the pastebin

I put this question here to ask if there are any tools that can take the text that you get when opening a gif in wordpad and turn it back into a gif file instead of a text file

closed as off-topic by Rafael, usr2564301, Ovaryraptor, zeethreepio, Luciano Jul 2 '18 at 9:42

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Sorry to say this, but you really need to rephrase the question. What is ARG, what is dump of a gif? why you open a gif file as text? how do you save a text file to gif? What issues make sense out of this procedure? – Rafael Jun 22 '18 at 17:28
  • ARG probably means Alternate Reality Game. Kind of like an online scavenger hunt/detective work/cryptography mashup. – Yorik Jun 22 '18 at 18:02
  • I've come across something similar if an image file is transferred via FTP to a web host, but sent via ASCII transfer instead of Binary. I don't know if you can fix a file that has been transferred incorrectly. As far as I know transferring an image file as ASCII text instead of Binary image data will corrupt the data. – Billy Kerr Jun 22 '18 at 20:50
  • 1
    There's a stackoverflow question here that might have some relevance stackoverflow.com/questions/9770920/… and another on superuser here: superuser.com/questions/195612/… – Billy Kerr Jun 22 '18 at 20:54
1

If the text looks like this: TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ and contains only A-Z,a-z, 0-9 and possibly +, / then it is probably base-64 encoded. Base-64 is a common encoding for transmitting binary data using a base set of characters that can be expected to be supported in most text encodings (especially email services) and is printable.

You would need to use a base-64 decoder. If you have a web hosting account, a simple accessible way would be to pass the text to PHP's base64_decode() function and then emit the result to a file.

Googling "base64 decode" will show you more options.

http://php.net/manual/en/function.base64-decode.php

  • Yeah it probably is something like this. Macs probabaly have uuencode in the terminal – joojaa Jun 22 '18 at 18:45
0

Ok, now we have the actual link to work with. It is clearly not encoded in base64 but is mangled in some way. Lets see if we can figure out and possibly reverse the mangling.

The first thing I noticed is that the raw option on pastebin ( https://pastebin.com/raw/sQNc0Bsr ) has data (control characters) that are missing in the web UI. I downloaded the raw file using wget to minimise the chance of further mangling.

The second thing I noticed is that there appears to have been a character encoding conversion. The file downloaded from pastebin raw validates as utf-8 which is very unlikely for an arbitary binary file.

I tried performing a UTF-8 to windows-1252 conversion with iconv but it erored out.

I then wrote a quick python program to determine the number of distinct codepoints in the text.

#!/usr/bin/python3
f=open("sQNc0Bsr","rb")
data = f.read()
datadecoded = data.decode("utf-8")
codepoints=set(datadecoded)
print(len(codepoints))

I got the answer 256, promising.

So I extended my code to write out what the codepoints actually were in a sorted list.

codepointnums = []
for codepoint in codepoints:
    codepointnums.append(ord(codepoint))
codepointnums.sort()
for codepoint in codepointnums:
    print(hex(codepoint))

The first value above 0xFF I found was 0x131. A quick googling showed that was a "dotless i". A letter that is associated with turkish. Ok then lets try encoding the data as windows-1254

dataencoded=datadecoded.encode("cp1254")

Ok, that failed "UnicodeEncodeError: 'charmap' codec can't encode character '\u2260' in position 55: character maps to " lets do some more googling.

Looks like macroman has both U+0131 and U_2260. Lets try that.

dataencoded=datadecoded.encode("macroman")

Ok, that didn't raise an error, lets write the data out to a file and see if it is a valid gif.

f2=open("sQNc0Bsr.gif","wb")
f2.write(dataencoded)
f2.close()

eom still can't read it, next suspect mangled line endings.

crcount = 0
lfcount = 0
crlfcount = 0
for p in range(1,len(dataencoded)):
    byte = dataencoded[p]
    bytem1 = dataencoded[p-1]
    if (byte != 0x0A) and (bytem1 == 0x0D):
        crcount += 1
    if (byte == 0x0A) and (bytem1 != 0x0D):
        lfcount += 1
    if (byte == 0x0A) and (bytem1 == 0x0D):
        crlfcount += 1

print(crcount,lfcount,crlfcount)

This confirmed my fears, there were a load of occurrences of CRLF but no lone CRs or lone LFs.

This is where I give up, the next step would probably be to write a custom gif parser that could make an educated guess as to whether each CRLF sequence was originally meant to be CR, LF or CRLF but that is far more work than I am prepared to put into a stack exchange answer.

  • I expect that if this was transferred via ascii, any hex(0a) encountered would be naively converted to hex(0d0a), so perhaps naively reverting CRLF back to LF would be worth trying – Yorik Jun 25 '18 at 14:24
  • 1
    I actually tried that, it still failed to decode, from the counts I saw I belive that both plain CR and plain LF were converted to CRLF. – Peter Green Jun 25 '18 at 15:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.