Permalink : www/retr0_dev/posts/6_post.html

Post date : Fri Mar 22 2024 2159

Upd. date : Sat May 23 2024 0143

"rawSEC RENTAS \"Unofficial\" Crypto Write-up"

Railtwist

***"Don't seek truth in the wrong place; should you be reminded of what is right and tempered." * **

We are going to look into how did I (tried but alas failed) to tackle this (Hard but smartly crafted and deceiving) CTF question by rawSEC rentas.

DISCLAIMER : I did not join this CTF, but all intel was given by [redacted] from [redacted] team. I was merely curious and enlighten to help solve the question and no actual exchange of solution or work to solution was given to [redacted].

Alright, let's get this bread (LGBT)

Table of Contents
Init.
Contents
1st attempt on cryptanalysis

"cipher.pdf"
"key.txt"
"railfence"

Post-Init. Cryptanalysis and Official Solution
Third-Party Re-production and Verification

Init.

A "railtwist.zip" file was given. Inside the archive, there are three files named "railfence", "key.txt", "cipher.pdf"

All files including the archive was hashed early on to preserve its integrity throughout cryptanalysis.

Here is the content of "cipher.pdf" when opened using Adobe Acrobat PDF Viewer. We will go back to this file name soon.

Here is the content of "key.txt".

Here is the content of "railtwist", which is only the sole verified hint from the crypto puzzle author.

1st attempt on cryptanalysis

"cipher.pdf"

When the image is clicked, it tries to go to a certain dir. or link in file system highlighted above.

The existence of this link can be confirmed using HxD or other Hex Editor in the picture above.

The text laid out to be :


                        ZVVOHjVONQNAOtxduxvT9j0ONDRSNNFPNG0jttR5NtRNNxRNz5FLO6FUh06TF+1d5fMmpKHW/1k6vz2SPQfozAhXt6yhGTfbV/yHOYx9JQRlrAJozb8JARoAPlKBzBXmGpRsQjVQNDNONxNZhQAAiXsHXaSHI867z1Ub3en4u+xR1QgvShZRgw420HkujpGysmH3f2yY0MUJDGbUPDRejp3YgM6ElIBWEyrENvRN5X193FY2/yhE5l+OkhFc3v56T4AFAocx4T1GxsRUVD0PVDPhX0gv7oBCubtJ1mc5DVT6vi5FrDUyU3x/aF6+am2uvjVtKHZRJsBjy/ijsHP6kZegUStVWZOu/grA3Wz5j4AkGBRPVUe2wNTeXuAEreRAtCKe6rfTvTx3w3Cj1Lkb74PoZxewNvOY05GUlGmeOIGzueFzPukHACWgAS5wxY6tBvElR38tZj==

First assessment of the extracted text was that it was encoded with Base64 Encoding Algorithm.

Using Base64 Decoding Algorithm, I got this plaintext:


                        eUN5N5@:Ü]»Óö=44R4ÑO4m#¶Ôy6ÔM7MÏ‘K;¡T‡N“í]åó&¤¡ÖÿY:¿=’=èÌW·¬¡7ÛWü‡9Œ}%e¬hÍ¿	�>RÌæ”lB5P43N7Y…��‰{]¤‡#Î»ÏUÝéø»ìQÕ/JQƒ6Ðy.Ž‘²²a÷l˜ÐÅ	fÔ<4^ŽØ€Î„”€V*Ä6ôMå}}ÜV6ÿ(Dæ_Ž’\ÞþzO€‡1á=FÆÄTT=T3á_H/î€B¹»IÖg9
                        Tú¾.E¬52S|h^¾jm®¾5m(vQ&ÀcËø£°sú‘— Q+UY“®þ
                        ÀÝlù€$OUG¶ÀÔÞ^àä@´"žê·Ó½é�% .pÅŽñ%G-f

Knowing that it is not an intelligible plaintext, my first assumption was it is of an Ciphertext output from either :

-- Modern Symmetric Algorithm i.e. AES or DES
-- (At that time I thought was far likely but it was) Asymmetric Cipher i.e. RSA or ECC

This is because classic Symmetric cipher i.e. Caesar, Vignere, etc. do not produce these kind of Ct output (in which only alphabet chars usually), and the inclusion of other ASCII chars in the plaintext makes me believe that this is a ciphertext that must be decrypted using above methods.

However, we are still missing the key, in order to decrypt above Ct; which bring us to the second file.

"key.txt"

From the image above, it is more or less the same. We have a text that is of Base64 Encoding Algorithm.

The text laid out to be :


                        U3bPNI7aqUMlUlLU1l96ElN8LPCJhn34x2KkQGhHeFgjriXVMp2XZXShi6mLYBcBpd2DCNFkXaJztYU+J/dI3w==

After running the Base64 Decoding Algorithm, I got this plaintext:


                        SvП4ЋЪ©C%RRФЦ_zS|,р‰†}шЗb¤@hGxX#®%Х2ќ—etЎ‹©‹`ҐЭѓСd]ўsµ…>'чHЯ

My first assumption also applied here, that it is also a Ct product of a Modern Cipher algo. that is need to be decrypted first.

Another reason that I said I was focusing on decrypting the above Ct first is because I thought it is some sort of Key Decryption Key (KDK) concept, where the key to decrypt the first Ct (cipher.pdf) is encrypted with another key in which is in (key.txt). An illustration of my initial plan was this :

Unable to proceed more further, I can only look into the third and last file.

"railfence"

From the image above, there are nothing much noting of possible leads.


                        0
                        \n
                        \n
                        //* warning this filename has been modified
                        \n
                        \n
                        13
                        \n
                        \n

The content suggested the filename was modified; thus we are discouraged to use railfence cipher.

The only clue here is the numbers (THE NUMBERS MASON WHAT DO THEY MEAN)

-- 0
-- 13

A suggestion at the time is to use ROT-13 cipher from the number 13. (We will go back to this)

Another suggestion is that from number-letter conversion (A=0, B=1, ...) the 0 - 13 means only choosing the first 13 letters of alphabet? but it was illogical and I do not see this lead going forward.

Post-Init. Cryptanalysis and Official Solution

At last, I did not manage to break the puzzle with the KDK concept in mind. But I was almost certainly right about the cipher method used on encryption; which is RSA.

From Official Write-up by [redacted], the method is below:

-- "String" the PDF on Kali (We have already done this using HxD on Windows, which bring the same result)
-- ROT-13 the string from the "cipher.pdf" 49 times (No need for 49 times, one is enough)
-- Decrypt the key.txt using the Pt of op. above.

So actually, these filenames were deceiving us in the first moment we start the cryptanalysis. The "cipher.pdf" - in which we thought denotes Ct, was actually a Key.

And "key.txt" is the ACTUAL Ct. An illustration is given below:

This actually made sense because of two reasons:

-- RSA private key are longer than RSA public key (The puzzle used RSA-515 (deprecated), and the key size is 460 bytes.)
-- The length of "key.txt" is 88 bytes, in which I realised that I can rule out the possibility of AES / DES (which is capped at max len. of 256-bits (32 Bytes) key size)

Now we go to the second step. Actually one time op. is enough since ROTting it twice will give back the same Pt, and in which the first 48th attempts are pointless.

With this method, ROTting the "cipher.pdf" will produce:


                        MIIBUwIBADANBgkqhkiG9w0BAQEFAASCAT0wggE5AgEAAkEAm5SYB6SHu06GS+1q5sZzcXUJ/1x6im2FCDsbmNuKg6luTGsoI/lUBLk9WDEyeNWbmo8WNEbNCyXOmOKzTcEfDwIDAQABAkAMuDNNvKfUKnFUV867m1Ho3ra4h+kE1DtiFuMEtj420UxhwcTlfzU3s2lL0ZHWQToHCQErwc3LtZ6RyVOJRleRAiEA5K193SL2/luR5y+BxuSp3i56G4NSNbpk4G1TkfEHIQ0CIQCuK0ti7bOPhogW1zp5QIG6iv5SeQHlH3k/nS6+nz2hiwIgXUMEWfOwl/vwfUC6xMrtHFgIJMBh/teN3Jm5w4NxTOECIHr2jAGrKhNRerENgPXr6esGiGk3j3Pw1Yxo74CbMkrjAiBL05THyTzrBVTmhrSmChxUNPJtNF5jkL6gOiRyE38gMw==

Plugging this value to RSA encryption/decryption tool will return the flag in which is:


                        RWSC{c18af8f24d61d0c55d32972b3b405ac7}

Third-Party Re-production and Verification

[will continue later]