unlike many others, REP STOS/MOVS instruction is very hard to emulate (see “self-overwritten REP STOS/MOVS, IDA-Pro 5.4 and Ko” post). at first sight it’s easy! live CPU continues executing overwritten command, right? so, take OllyDbg or IDA-Pro and write a plug-in to redesign the trace engine. if the tracer meets self-overwritten REP STOS/MOVS it memorizes it and continues executing like the real CPU does. it’s easy! what’s the problem?!

but, it’s more than meets the eye. CPU stops executing over-written REP STOS/MOVS in arbitrary moments. well, almost arbitrary. hardware interrupts force CPU to clean pipeline, stopping executing the overwritten REP STOS/MOVS command. internal CPU events also stop REP executing. different CPUs have different behavior (and different bugs :=).

this gives us… a very interesting pseudo-random number generator. if initial ECX is quite big, REP loop finishes with almost unpredictable ECX and the most interesting part is - our PRNG does not look like normal PRNG!!!

to prove it, I wrote a simple POC (plz, do not use it in commercial software, coz, due to CPU bugs sometimes it crashes with access violation or another exception, but in general it works, I’m working on the stable version now). download it and run.

the program allocates memory on the heap, copies self-overwritten REP STOSB code there, initializes ECX by 16Mb value, passes control to it and displays ECX. the point is - ECX is different every run.

my favorite Pentium-III 733 MHz Coppermine (my base PC) copies at least 64 Kb in average, see:

16685683 (91533 copied)
16575731 (201485 copied)
16755560 (21656 copied)
16770446 (6770 copied)
16670677 (106539 copied)
16759763 (17453 copied)
Pentium-4 3.2 GHz HT (my home file-server) shows pretty different result:

16044939 (00732277 bytes copied)
16777211 (00000005 bytes copied)
16777210 (00000006 bytes copied)
16777206 (00000010 bytes copied)
16777209 (00000007 bytes copied)
15788810 (00988406 bytes copied)
damn! sometimes CPU copies only 5 bytes!!! well, not “sometimes” - very often!!! it makes this trick not just PRNG, but… kind of fingerprints of CPU.



http://nezumi-lab.org/blog/?p=136