Looking at the output from round 64 of our script, we can see some human readable PHP code with some goto steps, like our author learned to code in BASIC. We also have some strings that are obfuscated using unicode escaping, and mixed decimal and hexidecimal values. We could step through these character by character, but that sounds awful, especially when we have Python and know enough regex to be dangerous. Once our strings are deobfuscated, we can toss the PHP code in an editor, properly format it, and it's pretty easy to see that this is a dropper that spoofs a Safari User-Agent string and downloads & executes the contents of a URL at 156.67.221.29 (which hosts the domain haxor[.]lol). Unfortunately, by the time I got around to looking at their shady PDF file, the 'wibu.jpg' payload was gone. But it would have been additional PHP code encoded in base64. Perhaps a webshell, or a payload stager for other malware? Or maybe just some obscure anime?

We could manually step through each round of obfuscation using the technique above, but without knowing how many rounds there are, automating the work seems like a good approach. And knowing that we can't write a static parser and decoder because the varied order and type of encoding used changes each round, we can't write a simple static decoder. While I like Python - and you could write this in Python - the minor changes, simple loop, and need to execute PHP each round make the right solution a bash script. And, yeah, really glad we didn't step through 64 rounds of this nonsense.

To deobfuscate PHP that uses eval() to execute obfuscated code, it's as simple as replacing eval() with echo() and then executing the file. In this case, we just trim away everything before '<?php' and after '?>' then replace the first eval() with echo() and run it using a local copy of PHP. Unfortunately, we quickly discover that there are multiple rounds of obfuscation, and they change the order and number of encodings used between rounds.