abel1502
commented
3 years ago I've jsut found something out: apparently, what I've been dealing with wasn't part of pjorion's obfuscation. It turns out the script I was testing on (it's a wot mod I was interested in) employed two different protectors, and the inner one was actually not PJOrion, but scraZ. I've only just found out about its existence, but now it makes a lot of sense: the rnd12 names in fact always start with "_scraZ". Well, that's a shame, I guess... I'll maybe try and take a look at the actual PJOrion protection some other time, but for now I withdraw all of my previous statements. I can't state anything for certain about PJOrion's obfuscation anymore
I've found a different way into the pyc package I was working on (func_globals and code on some world of tanks api hooks, used by the mod. Also a viable approach is to add your own hooks to built-in apis, but that's a different topic), and with that, have bypassed the outer, wrapper layers. So I got samples of code, protected solely by the algorithm bytecodesimpifier (let it be BS for short) is supporsed to bypass. There, I found another security feature, not taken into account by BS: The code has two extra local variables with names "`{something}rnd{1 or 2}{several random charaters}
" - I'll call themrnd1andrnd2`. They are only set to predefined constants, but the code's control flow depends on their values. I'm working towards a solution for this, but the point is, nothing like that is implemented in BS. On the other hand, in small files it isn't technically difficult to write out the code flow manually, but I still feel like making a tool for it. I'll document it better after I'm done with at least a prototype deobfuscator