[nneonneo]

The context of the log messages seems to imply that it's part of an automated (or semi-automated) string decryption system. Many binaries obfuscate strings using some simple encryption algorithm to defeat trivial analysis (i.e. "strings"), and manually reversing those is tedious. It's nice to have an automated decryption routine, but not so nice if it consists of just eval() with no sandbox...

[Karliss]

Even if the binary isn't malicious executing random parts of a program has high risk of breaking or at least polluting the current system. Most executables will have some side effects on the system due to interactions with file system or other processes. There is no point in having executable which only crunches numbers in a loop with no sideeffects (unless it's a benchmark or something like ls executable) so in most cases there will be sideffects. And doing them in uncontrolled manner will be pure chaos. Something as seemingly harmless as backuping software can overwrite stuff if not executed in correct way.

Assuming sandbox is working correctly any parts with sideffects will probably not be very productive for deobfuscation anyway. Such automated decryption strategy would work best for purely functional parts of code. But the parts that interact with os and filesystem are either not part of decryption code (so no point executing) or if they are part of decryption they are probably the parts which try to defeat such automated decryption by detecting sandboxed/emulated environment and stopping decryption (again no point executing it without some manual intervention or very carefully designed fake environment simulating a specific target).