Permutation Engine

[Guy]

you could go over it twice, first doing the actual obfuscation and then combining/optimizing the changes made

a 1:1 translation would, as you say, be reversible by an automated process, but if it was further modified after being obfuscated, it would be much harder

also, inserting junk commands now and then would make the whole thing much more confusing

pushf
clc
push ebp
push eax
jc short 10h
push esp
mov eax, esp
jc short 2ah
add dword [eax], 4
mov esp, [esp]
mov eax, [esp]
popf
popf

the efficiency of this can scarcely be compared to the original mov eax, ebp, but it cranks up the wtf factor by quite a bit

a program trying to reverse it would presumably not be able to do away with the jumps, as they could be legitimate, meaning by extension it would be unable to combine most, if not all, of the other instructions

this example could be reversed automatically, but the analysis required to do so would be on par with olly

a few tricks like this could be sprinkled around randomly with disastrous effects on analysers but little loss in efficiency (relative to your current obfuscation, anyway)

nops could be inserted at random to kill byte for byte comparisons, if such tricks were not generated dynamically

i would hate to see this project thrown out, as it happens to be relevant to my interests

Junk instructions would ruin the point of the project; it's intended to end up with no noticeable performance loss, something junk instructions would add.

In all honesty, you're better off designing a VM-like solution; you could have your entire program be interpreted by pseudo-bytecode, which decides which functions to execute, and in what series (A cross-platform representation of the entrypoint function, essentially). In this way, you'll given the same protection level offered by virtualization, but with less cross-platform compatibility issues, and an overall better performance.

[arenti]

Junk instructions would ruin the point of the project; it's intended to end up with no noticeable performance loss, something junk instructions would add.

you're barking up the wrong tree then; this whole concept totally destroys efficiency as the substitute instructions are more expensive than the originals (granted this criticism is pointless since you've already moved on)

In all honesty, you're better off designing a VM-like solution; you could have your entire program be interpreted by pseudo-bytecode, which decides which functions to execute, and in what series (A cross-platform representation of the entrypoint function, essentially). In this way, you'll given the same protection level offered by virtualization, but with less cross-platform compatibility issues, and an overall better performance.

that's an equally interesting concept

you pump out good ideas by the truckload