问题
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
回答1:
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 H4 plus a third character in the range of s to v.
The reason is, that every base64 character represents 6 bits of the original bytes, so the two bytes 0x1f 0x1b are 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.
another example is
png
starts with: 0x89 0x50 0x4e 0x47 0x0d 0x0a 0x1a 0x0a
base64 encoded:
iVBORw0KGg...
Update: 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:
H4sIAJ89gV4A/+1ZURaEIAi8SkfQ+1/O3f7MtEBfMgz9rC/diXmIA5hSzun3HNdBbgbtVP2v/2+LowM837wFHKxZbmE9pQfsLOaiLAL8kvIk4MBma17ufHQbIJCXoWNZZKGPWB5QljvXIuXOmm0SgLixJw8HRC8Tbmz7x5eIspypaZHSWbj8cAhdjli2WUkR1sv2dZmwXhZlDnIcCl0GyrFX6fKkBEBTBsq+9uY2Ecug2Rf0xtaJlNdYJuxjP9kcd1LOW/fQXtb1sd3fSTGXFTx3UjfGFx6uJGjeIAAA
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:
00110000 00110000 00110001 00110001 00110000 00110001 00110000 00110000 00100000 00110000 00110000 00110001 00110001 00110000 00110001 00110000 00110001 00100000 ...
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.
来源：https://stackoverflow.com/questions/62329321/how-can-i-check-a-base64-string-is-a-filewhat-type-or-not