Big Bummer for running Shrinkered files!

[Robert Baruch]

> > Well, reliably because you just scan the code section of the
> > executable for the sequence of bytes representing that procedure,
> > since it will always be the same and always be in the code section.
> 
> But then it's tied to a very specific Shrinker version, and will need
> changing basically every time the Shrinker guys touch something. Or
> you make it less specific and risk triggering it on other apps that
> have similar code sequences.

That's true.

> 
> > That is a nifty idea. Unfortunately it obfuscates the code a little
> > bit. Instead of calling the handler, we'd have to code it in
> > assembly with "call ecx" at the end. Shrinker looks for the next
> > instruction after that to be something like mov eax,fs:[00000000],
> > so we'd have to do that as well.
> 
> Yes, it's a bit ugly, but the exception code is already quite
> obfuscated as it is ;-)

Hmm. Well, it looks for one of these two code sequences:

call ecx
mov esp, fs:[00000000]

-or-

call ecx
mov ecx, fs:[00000000]

If it finds the mov ecx code then it unprotects the page of memory where the access failed and sets a pointer to somewhere behind the call ecx code, and then compares the contents to another signature. So the safest code sequence would be the mov esp code, but that mucks with esp :(

One clue is that the signature is inside the executable. Scanning through the executable, there's a call ecx/mov ecx, fs:[00000000] sequence in the executable itself. My guess is that after finding the mov esp code, it installs an exception handler which uses the mov ecx code from then on. Additional evidence is that when it sees the mov esp code, it allocates some memory and copies that section of the executable into the memory.

So the real question is, can we use

call ecx
mov esp, fs:[00000000]

as the handler caller?

--Rob