New software encryption method

[dyn!o]

Quick notes from me since JMI may disable my account for lack of posts

1. Presented method is old as hell (look at viruses).

2. Unfortunately it has nothing common with vm. It does not even smell like vm

3. "Erase RET instruciton", "use JMP to divide code" - uhm... it was good trick but my callendar shows 2006.

4. I am a bit surprsied seeing real professional coder, like LiuTaoTao, suggesting that stack execution, even ecnrypted, may stop serious cracker. Bad news: stack analysis will help a lot during reversing. Again: we have 2006 so let's forget it. In 2007 don't even mention it.

Anyway, good news is that LiuTaoTao is back. I was wondering many times about such a talent, being conviced he was lost in some cheap company. It's very good to see him back, even in other field than his specialization.

Originally Posted by dyn!o

2. Unfortunately it has nothing common with vm. It does not even smell like vm

Well, really?

So you say that if you have split the code into single instructions, decoded everything so far that each instruction can be placed at any memory location in any random order and know enough about the code to convert it into any code doing the same, it is more than one simple step to write a VM?

I didn't say that this is a VM, only that this trick is used in VM protectors. Perhaps you can explain me how VM protectors work if they don't use this "trick".

[dyn!o]

So you say that if you have split the code into single instructions, decoded everything so far that each instruction can be placed at any memory location in any random order and know enough about the code to convert it into any code doing the same, it is more than one simple step to write a VM?

That is exactly what I say my friend

I would say more: IMHO that is not even a small step for vm development. It's still only a sample of pure code scrambler. Of course it will complicate reversing, especially when you take memory blocks checksum results as descrambling arguments/parameters or opcodes decryption. Complicate, but for whom? Approximately 95% crackers. There is still 5% left of them and they expect much harder protection.

IMHO VM has to operate in own environment (CPU, registers, stack, memory - including structure and communication). Sometimes virtual machines are misunderstand with virtualization but the topic we discuss is not close to virtualisation too (VMWare and VirtualPC are).

EDIT: Sorry, I did not notice your question "how vm works then". Well, each one of us can have own definition and imagination but if you want to take a look at vm inside protector then you can take Themida - it contains vm but it resembles x86 (I mean is not very hard to reverse). Question why is another topic, but you can answer it yourself looking at SPARC/PowerPC open source emulators available on the net.

Next kind of virtual machines are the ones residing in Atari/ZX/C64/Amiga emulators. They are often "perfect" virtual machines, able to serve as real virtual environment. If we are talking about vm in protections then definitely the best vm resides inside StarForce - it is already a legend. The rest is mystic...

Regards.

Well, I know the difference between virtualisation and a virtual machine. And, again, I didn't say this protection uses a VM.

Of course a VM needs a operating environment. But anybody can code a VM in just two minutes (OK, maybe 2 hours if you don't just want to have a two-opcode VM, but something which can be used for something).

But the problem is not to create the VM, the problem is how to convert any existing piece of code into virtual opcodes, which behave in the VM exactly like the original opcodes on a real CPU.

And if you've already analysed the original code deep enough to use the type of protection mentioned in the first post, it is just a simple step to convert any instruction into a virtual opcode and run it in the VM.

What other really big part do you miss, if this "is not even a small step for vm development"? (assuming that I'm not a super great coding mastermind and therefore don't understand where the big problem is hiding)

[dyn!o]

Oh my , I have no advanced knowledge about virtual machines or protections. I just came today, after a long break, to raise my post count in order to keep my account alive - I am serious. I took the first thread in General Discussion - it was a coincidence of choosing this topic. I am talking about my dreams only. Not "the only truth".

Well, I know the difference between virtualisation and a virtual machine. And, again, I didn't say this protection uses a VM.

I did not say you do.

Of course a VM needs a operating environment. But anybody can code a VM in just two minutes (OK, maybe 2 hours if you don't just want to have a two-opcode VM, but something which can be used for something).

Interpreter my friend... I guess you had that thing in mind. Interpreter is not a virtual machine (it's only a part of it) but you are right: the simpliest interpreter can be coded in 2h. You can find it in many crackmes and less viruses.

But the problem is not to create the VM, the problem is how to convert any existing piece of code into virtual opcodes, which behave in the VM exactly like the original opcodes on a real CPU.

So the question is: how do you want to achieve such a result without writing a virtual machine (quote: "But the problem is not to create the VM")?

And if you've already analysed the original code deep enough to use the type of protection mentioned in the first post, it is just a simple step to convert any instruction into a virtual opcode and run it in the VM.

I cannot agree. I could do if it is about myself only but many people read this thread and many other will do it in the future. Let's do not suggest them that with x86 "scrambler" we are simple step from running the code inside virtual machine. Virtual machine requires own environment, while LiuTaoTao's solution, in its strongest theoretical assumption, requires only an interpreter. Please take a look at the quote below to find my humble opinion regarding this point too.

What other really big part do you miss, if this "is not even a small step for vm development"? (assuming that I'm not a super great coding mastermind and therefore don't understand where the big problem is hiding)

I am also not a mastermind but let's take a look at things which seems a bit complex for me if we are talking about "what do we miss":

1. Stack frames (not to mention FPU stack pointer )
2. Registers
3. Code evaluation
4. Exceptions
5. Non-static code support
6. Memory management
7. Privileged instructions
8. System API emulator
9. Interrupts
10. Threads
11. System calls

If that seems easy for anyone then we can extend this list at least twice.

Kind regards.