And key generation tied to individual CPU.

Git

Quite true.

At the moment, our computing model is still more or less a static model. Code is compiled into static instructions. Packers have static signatures. Data is treated as data, code is treated as code. So in a sense, it is still a (albeit less) restrictive console.

Maybe the future is in dynamicism. Code and data is mixed up, stirred well, one cannot tell if it's code or data. Code is generated on-the-fly, morphing from time to time.

> Code is generated on-the-fly, morphing from time to time.

Rather negates the huge speedup gained by the multi tiered large caches we enjoy today.

Git

Yea, that's the sad part. Whether it is a fair trade off remains to be seen. We also make this trade off when we decide to use VM code.

But at the moment, we still do not have a good instrumentation tools for PE files. There are very useful tools for Java VM (ObjectWeb ASM), and probably .NET CLR too. This is probably what holds us back from seeing realizations of such dynamicism.

Maybe the next step in evolution is a morphing VM. Let us wait and see.

As for morphing VM, well themida has got all already..

Bytes -> handler = dynamic (if 00 equals mov in the first instruction it will be different the second, and also different between programs.)
handler sequence = dynamic/random
byte encryption = carrying, modified by each byte(s) and each next byte(s) is encrypted with it.
+ Handler obfuscation
+ VM_code obfuscation

Not much more they could've done..

sometimes life just gets in the way, or goals about things change......not much you can do, but enjoy the ride

> We also make this trade off when we decide to use VM code

But we don't make that choice, it is thrust upon us by software manufacturers thinking they are protecting their product. Nobody would choose to have VM'd apps rather than plain 386, would they?

Git

I've really no clue on how Themida works, so I'm just guessing blindly here.

To me, morphing means the code is changed in each __run__, not in each __application__. Or even better if the code is changed after some condition, even in one run.

Well doable but that won't change it much.. If you'd make the handler -> bytes changeable and the accompanying handler location as well, it would however open a massive security problem.. I can force the VM to become static, by shutting down it's randomization, this way I get an Identical VM on all apps.. Making it a lot weaker then it is now.

If you'd morph VM_code however, you can attack the morpher which can interpret VM_code to morph it and very likely extract usable info from it. (If not pure asm.)

Could it be that the scene is smaller because the scene is getting older?? The younger generation are too lazy to spend the time cracking software protection...and that combined with the fact that there is not too much teaching going on out there (imho) so the tricks of the trade are dying with those that know them. And the older scene "is getting too old for this sh%$" to mess with the newer stuff...

my two cents.

Hehe well thank you. :) But you got a point, how I see it all the 15 and 16, 17 year olds are used to internet spoon feeding. Seems that group are around at the RE sites but not quite cracker material.

The scene's getting smaller for sure. I'm not in the scene for a long time yet but it wasn't hard to notice that trend.

Internet spoon feeding describes the whole attitude perfectly fine (thanks quo :P). But that's also why I don't wonder that the amount of teaching decreases if there's no one left interested in how to solve a RCE problem but rather having the problem solved at all.

This, combined with move to obfuscated code, is the causing less and less people to get involved with rce. Earlier in the decade, the code from protectors was easy to read and there was only anti-debugging techniques, but now you have to search for the right code (sift through thousands of commands). It's much harder to jump right in to reversing, so people quit before they even get started. And the scene is getting smaller because (well, the reason why I retired) is because it's the same old crap. There was a shift toward vm and obfuscated code, then no changes since. The protections haven't changed so people just get bored. And those who do stay in the scene and do know how to deal with new protections do not want to share the information because it takes so long to perfect an attack, which is another reason why the new generation is not getting involved (lack of information on new protections).

perhaps open-source solutions are working well,
thats why scene is not effective as the way it used to be.
for an isntance for the FTP client its been a long time that I'm using filezilla instead of cuteFTP or any other 3rd party commercial software.
don't you think?

I think quite simply its all about time now... it is a very time consuming process now and many have grown out of it / got bored.. Girlfriends / kids dont help either.. lol Although i tend to disagree about a lot of the tutorials out there that rely on things such as scripts or other tools that pretty much do it all and you learn nothing.. also many ways of defeating anti debug tricks are often not explained.. usually just use this plugin it does it for you.. I think a complete understanding of why the debugger is being caught and the way to defeat it should be explained a lot more..