### 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