I took the Spentalkux challenge on https://2020.ractf.co.uk/. This is the first time I do a CTF challenge so I went through a solution on https://github.com/W3rni0/RACTF_2020/blob/master/readme.md#spentalkux
When I receive this base64 string :
JA2HGSKBJI4DSZ2WGRAS6KZRLJKVEYKFJFAWSOCTNNTFCKZRF5HTGZRXJV2EKQTGJVTXUOLSIMXWI2KYNVEUCNLIKN5HK3RTJBHGIQTCM5RHIVSQGJ3C6MRLJRXXOTJYGM3XORSIJN4FUYTNIU4XAULGONGE6YLJJRAUYODLOZEWWNCNIJWWCMJXOVTEQULCJFFEGWDPK5HFUWSLI5IFOQRVKFWGU5SYJF2VQT3NNUYFGZ2MNF4EU5ZYJBJEGOCUMJWXUN3YGVSUS43QPFYGCWSIKNLWE2RYMNAWQZDKNRUTEV2VNNJDC43WGJSFU3LXLBUFU3CENZEWGQ3MGBDXS4SGLA3GMS3LIJCUEVCCONYSWOLVLEZEKY3VM4ZFEZRQPB2GCSTMJZSFSSTVPBVFAOLLMNSDCTCPK4XWMUKYORRDC43EGNTFGVCHLBDFI6BTKVVGMR2GPA3HKSSHNJSUSQKBIE
I don't know how to check if it is a file, but the solver said that it is a gz compressed data file.
Can you help me, please? detail here
Link to file: https://github.com/W3rni0/RACTF_2020/blob/master/assets/files/Spentalkux.gz
Many filetypes have a header (the first few bytes of the file) with some fixed information by which a file can be identified as a gz, png, pdf, etc.
So every base64 encoded gz file would also start with a certain sequence of base64 characters, by which it can be recognized.
A gzip-file always starts with the two byte sequence 0x1f 0x1b, which in base64 encoding is
H4plus a third character in the range ofstov.The reason is, that every base64 character represents 6 bits of the original bytes, so the two bytes
0x1f 0x1bare encoded with two base64 characters (12 bits) plus the first 4 bits of the third character.Based on that, I would say that's no base64 encoded gzip that you show there.
other examples are:
png
starts with:
0x89 0x50 0x4e 0x47 0x0d 0x0a 0x1a 0x0abase64 encoded:
iVBORw0KGg...jpg
starts with:
0xFF 0xD8 0xFF 0xD0base64 encoded:
/9j/4...gif
starts with:
GIFbase64 encoded:
R0lGtif
a) little endian: starts with:
0x49 0x49 0x2A 0x00base64 encoded:
SUkqAb) big endian: starts with:
0x4D 0x4D 0x00 0x2Abase64 encoded:
TU0AKflv
starts with
FLVbase64 encoded:
RkxWwav/avi/webp and others
several audio/video/image/graphic -formats are base on RIFF(Resource Interchange Format) The common part is that all files start with
RIFFbase64 encoded:
UklGRAfter the
RIFFheader, you'll find the specific format starting in the 4 bytes starting at the 9th byte. In the following_is used as a placeholder for any character.wav
starts with:
RIFF____WAVEbase64 encoded:UklGR______XQVZFwebp
starts with:
RIFF____WEBPbase64 encoded:UklGR______XRUJQavi
starts with:
RIFF____AVIbase64 encoded:UklGR______BVkkgRegarding the specific example in the question:
in the updated question there's a hint in the attached picture that
the data is first base32 encoded and then base64 encoded.
When we feed an online base32 decoder with the string given in the question (
JA2HGSKBJI4DSZ2WGRAS...), we get:It starts with
H4s, so according to what I wrote about how to recognize file types in base64 encoding, it's a base64 encoded gzip file.This can be saved in a text file and then uploaded on base64decode.org where it will be converted into a gzip file. When you download and open that gzip file it contains a file with text like this:
Conclusion for this case: The original string/file is a gzip file that was first base64 encoded and the base64 encoded part was again encoded with base32.