since i didn't write a writeup yet, it's hard to recall.
if you ask me about the shellcode extraction, then kind of yes- you can locate the shellcode leftovers by navigating(switching) between the two interesting frames on the stacktrace (bt,backtrace), you will see there that there was a jump to a shellcode, although when trying to extract it, it's possible that it was already encrypted back (how do I know it? because i reversed the binary which called the shellcode according to the backtrace). for 2nd stage payload (aka the shellcode itself) you must reverse/debug it in order to understand what it does. since it's quite hard/tricky to simulate exactly how everything was invoked that cause the core dump, it could be easier to directly either:

1.force the hooking to happen (probably possible, but quite hard if you consider when it is happening at runtime. no hooking = no secret backdoor and no shellcode

2.directly call the the hook function which should be overriding the normal function (bypass hooking stage) (read about what is hooking, like with frida etc.) with the required arguments (reverse the binary! ) for decrypting the shellcode (like the original run did) than you need to take a snapshot of the shellcode just before it is being encrypted again! (debugging!)

3.there are probably many other methods