Page MenuHomedesp's stash

sekaictf22.md
No OneTemporary

sekaictf22.md

### symbolic needs 1
me and [@argonaut0]() were basically just finding the debug symbols for the kernel to get volatility 3 working for basically the entirety of the chall referencing my [irc writeup](https://maplebacon.org/2022/03/utctf-irc/)
it was highkey way harder to find than debian ngl lol we finally realized the ddeb was it but then we need to reference the unsigned dbgsym package instead to get the actual thing and its hidden within the control file
finally after setting up [@argonaut0]() ran the usual commands and saw the weird string in bash history `72.48.117.53.84.48.110.95.119.51.95.52.114.51.95.49.110.33.33.33`
and it instantly looked suspiciously like ascii for me for some reason so i wrote a simple oneliner in python to test it out
bruh and its actually the flag `'H', '0', 'u', '5', 'T', '0', 'n', '_', 'w', '3', '_', '4', 'r', '3', '_', '1', 'n', '!', '!', '!'` lmao
3/5 star difficulty ok sure :woozy_face:
### symbolic needs 2
did a lot more commands on it but we couldnt figure out much, especially coz `proc.maps` dies midway when theres a page fault along with some other useful cmds like kmsg
so i resorted to trying to strings or extract any useful info from the command outputs we got, but no luck
[@argonaut0]() eventually saw ncat in pslist, which was kinda suspicious but not too sus still
i figured might as well see if theres anything special while he looks for other hints like tty for ncat and reading buffers (which we cant again coz we dont even know where ncat is mapped in memory)
however `strings` did work - grepping for ncat gave me this:
```sh
ncat -lvnp 1234 -c 'echo N4GQ2CQAAAAAAEFG5JRPEAIAADRQAAAAAAAAAAAAAAAAAAAAAAAAACIAAAAEAAAAABZ6QAAAABSAAZABNQAFUAD2A5SQA2QBMQBBSAC2AJLQA3QLAEAACAABABSQGZADQMAQCADFASBQAAIALEAGOAC2AVSQMZAEMQCYGAUPBZNAOZIHUAEKCAFABGQQAWQFK4AGIAIEAACABAYDAEAG4CBRABZS65YBAEAACAABABMQAAIAMQDFUCTFBNSQVAYBMQDWIAMFAIMQAWQKMUGGKCVABVSQ4ZIKQMAWICDFBZSQVAYBMQEBMAAYAALQBIIBQMAVUCTHABNA6ZIQMQAGKDTFBKBQCZAIQMBUIAC5CRNBCZIPUAJGKBLFCNSQUZIRMUIWICAXACCQEGIAMQDYGATEAIMAAGIAUEAQCADRLFSQGZAJQMAQCADEAFJQAKIK5EAAAAAAJ3UQCAAAAB5BQVLTMFTWKORAFYXXOYLMNRSXIIDQMFZXG53POJSHUDLCNFYDGOLMNFZXILTUPB2NUALSNQKAAAAAABS6KHWNHGMBH4AWTJ3BE3XKCYFWPVQQSR6WWFSHC2WEUE3P5AP7G46OA3IBWAIA5EBAAAAA5EGAAAAA3ICVO4TPNZTSSFG2ANZXS462ARQXEZ3W3IEHAYLTON3W64TE3ICXA4TJNZ2NUBDFPBUXJWQFO5XXEZDT3ICG64DFN3NACZW2ARZGKYLE3IFHG4DMNF2GY2LOMVZ5UBDDN5SGLWQDMJUW5WQDON2HFWQFPJTGS3DM3IBWYZLO3IEG23TFNVXW42LD3ICXEYLOM5S5UALJ3IDGC4DQMVXGJWQDNFXHJKIAOINQAAAAOINQAAAA7IEHIZLTOQZC44DZ3IEDY3LPMR2WYZJ6AEAAAADTEIAAAAAIAABAEDQBAYAQQAIIAECAGDACBYARZ7YEAMIAGIQBAQBRIARGAEGAE=== | base32 -d > file.pyc'
```
LOL sure ok dont mind if i do
turns out its python 3.10 :skull: no decompilers can read 3.10 atm man
disassembled it, but doesnt look to trivial to reverse so i looked for another way to approach it
one way was to try the dice @ hope `better-llvm` trick with pdb, especially if its a flag checker, but i couldnt get too far with it since the codes run on module load not as a function and it doesnt look like a flag checker anyway
i can easily get the results in the module imported after the code runs though, and `test.mnemonic` caught [@argonaut0]()'s eyes - that should be enough to recover the private key since to run the module we alr need `bip39wordlist.txt`
idk blockchain so i let him do the work, and eventually using `ethers` on nodejs we got the privatekey using the mnemonics
`0x81c458e9fae445de18385a3379513acc8e191e4c2667c85aa0a52a32ec4e6d55` lol
also eventually i figured out if i bypass the unrecognized opcodes like i did in nahamcon `brainmelt`, i still get somewhat readable code - which actually is the code that generates the mnemonic but well is useless at this point coz i got the post run values alr
haha forensics more like running `strings` once again

File Metadata

Mime Type
text/plain
Expires
Thu, May 8, 11:52 AM (14 h, 40 m)
Storage Engine
local-disk
Storage Format
Raw Data
Storage Handle
71/80/af53099d05fcbb1d963b43abf205

Event Timeline