most of the program is standard assembly, then sometimes it's just manipulating some bits of data in bizarre ways to get to a value, either way it's mostly just consulting the x86 instruction documentation for functionality and encoding.

in terms of the instructions being wild, some of them are chosen, because the opcode matches the byte we need on a specific spot, but other times the instruction is just a randomly chosen one, however it was still usually important that the instruction could take a long operand instead of an immediate 8-bit value

sadly yes lmao, it was a fun challenge trying to not reuse instructions, but nearing the end where most modr/m bytes started repeating, i ended up having to resort to jmps to jump from a long operand to another long operand

thank you! you are wonderful for this <3 idk why but the stack being in the lower end of the address space doesn't feel right. nevertheless this is an amazing explanation and thank you for taking the time <3

i love Domas' work! this project did have a bit of inspiration from him

Yeah, it's not a way to 100% obfuscate the functionality, but instead it could be more of a way to throw off someone looking at the binary

If I was reverse engineering a program and I saw this I think I might just quit and rethink my life.

Finally finished this "proof of concept", that obfuscates a string in a binary by scattering its bytes across the program's opcodes.