You can hide 'exec' quite deep, as deep as you want really
Code:
vars(__builtins__)[bytes((101, 120, 101, 99)).decode()]
As I said, so far Ren'py rely on Python 2.x where
exec is an instruction, not a built-in function. Therefore, this will not works until Ren'Py hit the version 8.x
Plus this way is still totally obvious. If you're trying to access a built-in function, you've no reason to do it through
__builtins__. Coupled to the fact that the name of the index you try to access is obfuscated, this is a big warning and would immediately lead to a close investigation of the code.
I know quite a lot about python and I'm not a very smart person, but I am smart enough to know I won't be able to tell if a program running embedded python is safe just by looking at the python source files.
Well, I past near to 20 years doing this, half of it professionally, and I can assure you that, it's not too difficult to know when there's something suspicious in a Python script. And once you've found it, it's just a matter of minutes before you know if it's malicious or not.
But, apparently, you don't understand the problem ; what isn't a criticism. You're saying that you wouldn't be able to tell if the code is safe, but it's not what people are searching. You aren't checking in the code is secured, but if it is malicious. This mean that you don't need to looks at all the lines, nor to understand what the code do.
If you want, put the problem outside of its context. Take a lake of small size by example. If you look at it, you'll not be able to tell how many boats are sailing on it. But if there's a car or a plane, you'll not miss it.
The principle is exactly the same. What you're looking for in the code is everything that stand out. And the more you know the language, the easier it is ; especially with a language as rigid than Python.
I mean look at this (pun not intended)
Code:
s = """Gur Mra bs Clguba, ol Gvz Crgref
First warning: Four consecutive consonants ; and too often in the whole text in regard of the number of words.
Second warning: This clearly isn't a human language.
Code:
d[chr(i+c)] = chr((i+13) % 26 + c)
Third warning: Obvious obfuscation attempt.
Code:
print "".join([d.get(c, c) for c in s])
Fourth warning: Another obvious obfuscation attempt.
Fifth warning [that come once you trace back
d: It's an obfuscation of an obfuscation.
And what you'll use in place of
print would probably be the sixth warning.
Even if you split this and put it here and there, inside legit functions by example, like you said yourself, it would change nothing. Those lines stand out, they deserve that you pass some times looking more closely ; firstly at the function where they are, secondly at the whole code if it didn't lowered your attention.
Side note: Python being ZEN is the reason why it's easier to spot the issues than with more TAO languages, like Perl by example.
And someone needs to check the person doing the check and the person checking the person... and, well it's turtles all the way down.
Do you trust the Open Source software you use ? Do you think that there's a guy that check the code, one that check this guy, and so on ? Of course not, yet I'm sure that you believe that the code is secured enough to be used.
And it's the same here. There's in the community peoples who know what they do, and who will see it if something is odd. There's no need to check those guys, because there isn't "a guy". It's someone, rarely the same, who caught is the first to caught the issue ; and once it caught it, the others just don't check. This while, if there's nothing to caught, then a thousand of people would have checked the code, just to see that there's nothing.
Take the guys who try to be smart and alter the way RPYC/RPA files are generated, to prevent their reversion. Not only it don't prevent the reversion, but so far all of them have been caught less than 10 hours after the release of the game/update. It's obviously easier, since you don't need knowledge to catch them, but the principle is the same: Just trust the community.
