Finding the size of a function in C

Hi there. I have a licensing function that I am trying to protect (I'm working with Windows). Basically, I want to use self-modifying code.

I plan to encode all of the function's instructions until the ret, and I will replace the first byte of the function to 0xCC (int 3). When the function is called, my vectored exception handler will be triggered, and I will decode the entire function.

I've run into a small obstacle though. The byte for a ret, 0xC3, might occur before the function's end (for example, 0xC3 might be a byte in the opcode for a call).

Does anyone know a RELIABLE way of finding the size of a function?

Read the symbol table.

I plan to use a packer on my app, so the symbol table will probably be stripped.

Place a signature that is very unlikely to appear in the rest of the body, such as DB 'ANAL RAPE MAGIC', before the return.

Oh, thanks. I wouldn't have thought of that ;)

You should also realise that what you're trying to do is stupid and a horrible idea.

>>5
Fuck you then, and learn to quote.

>>7
s/quote/sage

>>8
No, I really meant quote as in `` >>1000 ''

What happens if you sizeof a dereferenced function pointer?

>>10
It should return the size of the function, but LOLC

>>10
dereferenced function pointer

WHBT

You can always place a label after the function or make a dummy func, and then take &end_of_func - &func. There are also ways to actually calculate function sizes dynamically, but they're pretty complicated and very platform and compiler dependent. You're better off using reliable ways, unless you have no other choice.

A virus scanner will almost certainly flag this.

>>14
Most are too dumb to do it, besides self-modifiying programs are very common on Windows, contrary to popular belief. You'd be surprised how common are packers and protections on this platform, as for the API calls that the application needs to make to perform its tasks, they're also pretty standard stuff (2 VirtualProtect calls if the code section is not writable). However, the reason I wouldn't ever use this trick is because it's very easy to defeat this trick, only novice crackers would have any trouble with it, and >>1 would be paying the price of portability (VEH is NT-only, compared to SEH which is present on all Windows OSes).

>>15
It's 2010. Who the fuck cares about non-NT?

>>16
The fact that the good majority of applications are still portable across the generic Windows platform (be it 9x, NT, reactos/wine, etc) is quite nice. It's a pretty universal ABI with a well known set of modules which are known to work everywhere. While there are certain valid reasons to go beyond 9x compatibility (such as true Unicode support), I consider dropping compatibility so you could achieve some fake sense of protection by abusing VEH a pretty stupid choice, given that you could have achieved it without effort otherwise. I'll find it even funnier how your app would be added to the long list of applications which actually gain better cross-platform compatibility once cracked(since you're only using the VEH for DRM), than the original non-modified version.

tl;dr: If you want to use extended Win32 APIs, you better have a real reason, other than fancy protection tricks. If you really don't care about portability, you might as well put your protection in a device driver and make sure to cause enough BugChecks on the user's machine with your excellent coding skills.

you might as well put your protection in a device driver and make sure to cause enough BugChecks on the user's machine with your excellent coding skills.
This is what game publishers think. I ｆｅｅｌ ｋｉｎｄ ｏｆ ｂａｄ ａｂｏｕｔ ｉｔ ：（

^{Back to /b/, ``GNAA Faggot''}

22 Name: Anonymous 2011-01-31 20:32

<-- check em dubz