init -------------------------------------------------------------------------------- when the protection dll is loaded (protect.dll, sfp.dll, ...) by some process, sf switches to kernelmode via deviceiocontrol on sfdrv01.sys (from within dllmain of protdll). the deviohandler in sfdrv01 copies the (now unpacked) vm from usermode into kernel allocated mem and executes a special initialization function: (sfdrv01.sys) PAGE:0001C3E6 push ecx ; usermode vm base PAGE:0001C3E7 push 0DEADCAFEh PAGE:0001C3EC push offset callgate PAGE:0001C3F1 push edx ; ram PAGE:0001C3F2 push 0 PAGE:0001C3F4 add eax, edi PAGE:0001C3F6 call eax <--- call into vm int1 -------------------------------------------------------------------------------- to switch to kernel mode, sf is using int1 exceptions. to make this possible, sf needs an own int1 isr (interrupt service routine). this handler is installed during the initfunction, mentioned above. the following steps show the int1 setup process: [ .... ] 000023c5 (00047b00): mov reg_0018, reg_0038 reg_0038 = 0004b284 000023c6 (0004b284): mov reg_0038, 0000ad7c 000023c7 (0004b290): add reg_0038, reg_0008 reg_0038 = 0000ad7c, reg_0008 = 81191000, res = 8119bd7c 000023c8 (0004b298): jmp reg_0038 reg_0038 = 8119bd7c 8119bd7c: 83 ec 08 sub esp, 0x08 8119bd7f: 0f 01 4c 24 02 sidt [esp+2] <---- pointer to idt is retrieved 8119bd84: 8b 44 24 04 mov eax, [esp+4] 8119bd88: 89 87 40 06 00 00 mov [edi+0x640], eax <---- and saved into reg_0640 8119bd8e: 83 c4 08 add esp, 0x08 8119bd91: c6 47 28 c3 mov [edi+40], 0xC3 8119bd95: 8b 9f 40 06 00 00 mov ebx, [edi+0x640] [ .... ] 000023c9 (0004b298): mov reg_05a0, reg_0640 reg_0640 = 8003f400 <----- idt base 000023ca (0004b298): mov reg_05b0, reg_05a8 + reg_07b0 reg_05a8 = 8127aa00, reg_07b0 = 00000020, res = 8127aa20 000023cb (0004b298): mov reg_05b8, [reg_05b0] reg_05b0 = 8127aa20, [reg_05b0] = 0008e884 000023cc (0004b298): mov reg_07b0, reg_05b0 + reg_07b0 reg_05b0 = 8127aa20, reg_07b0 = 00000004, res = 8127aa24 000023cd (0004b298): mov reg_05c0, [reg_07b0] reg_07b0 = 8127aa24, [reg_07b0] = 811aee00 int1 writes: 000023ce (0004b298): mov reg_07b0, reg_05a0 + reg_07b0 reg_05a0 = 8003f400, reg_07b0 = 00000008, res = 8003f408 000023cf (0004b298): mov [reg_07b0], reg_05b8 reg_07b0 = 8003f408, reg_05b8 = 0008e884 000023d0 (0004b298): mov reg_07b0, reg_05a0 + reg_07b0 reg_05a0 = 8003f400, reg_07b0 = 0000000c, res = 8003f40c 000023d1 (0004b298): mov [reg_07b0], reg_05c0 reg_07b0 = 8003f40c, reg_05c0 = 811aee00 [ .... ] from now on, sf will see each int1 exception. the handlers are removed, when the sf process terminates. since those handlers are system wide, sf has to make sure, only own int 1 exceptions are handled by sf code and all non-sf-process int1-exceptions are handled by windows default handlers. sf can now safely use int1 to switch from usermode to kernelmode. int1 in kernelmode switches back to usermode. there are 2 ways to generate int1 exceptions (and trigger the own handler): the "int 1" instruction (cd 01) and a singlestep exception (hardware breakpoint). the latter type uses the cpu's debugregs dr0..dr3 and dr7. sf uses both of them: 00000111 (0003fa9c): mov reg_0038, 00073b0c 00000112 (0003faa8): add reg_0038, reg_0008 reg_0038 = 00073b0c, reg_0008 = 00c11000, res = 00c84b0c 00000113 (0003fab0): jmp reg_0038 reg_0038 = 00c84b0c 00c84b0c: 0f ba 77 10 01 btr [edi+16], 0x01 00c84b11: cd 01 int 0x01 00c84b13: c6 47 20 33 mov [edi+32], 0x33 00c84b17: 8b 9f 20 03 00 00 mov ebx, [edi+0x320] 00c84b1d: 89 9f 20 03 00 00 mov [edi+0x320], ebx 00c84b23: c7 87 24 03 00 00 00 mov [edi+0x324], 0x00000000 the code above int 1 is obviously executed in usermode. the int 1 instruction triggers the handler. example how a hardware breakpoint is installed: 00000122 (000628d0): mov reg_0038, 00156c78 00000123 (000628dc): add reg_0038, reg_0008 reg_0038 = 00156c78, reg_0008 = 8117b000, res = 812d1c78 00000124 (000628e4): jmp reg_0038 reg_0038 = 812d1c78 812d1c78: 0f ba 7f 10 04 btc [edi+16], 0x04 812d1c7d: 8b 9f 80 07 00 00 mov ebx, [edi+0x780] <------ addr of breakpoint in reg_0780 812d1c83: 8b c3 mov eax, ebx 812d1c85: 0f 23 c0 mov dr0, eax <------ dr0 is used 812d1c88: 0f 21 f8 mov eax, dr7 812d1c8b: 0c 03 or al, 0x03 <------ enable dr0 bit in dr7 reg 812d1c8d: 0f 23 f8 mov dr7, eax this code installs a hw breakpoint at reg_0780. note that kernelmode is needed, to setup hw breakpoints that way, since dr-reg access is forbidden in usermode. int1 handler -------------------------------------------------------------------------------- when sf generates an int1 exception while in usermode, the sf handler first checks if the exceptionaddress lies in a valid vmrange. then it tries to find a matching x86 block in its vm, that contains this exceptionaddress: seg000:0001D8F0 xor eax, eax seg000:0001D8F2 mov ebp, cs:[esi+0Ah] seg000:0001D8F6 mov edx, cs:[esi+0Eh] seg000:0001D8FA add ebp, esi seg000:0001D8FC seg000:0001D8FC loc_1D8FC: ; CODE XREF: int1Proc+73j seg000:0001D8FC ; int1Proc+77j seg000:0001D8FC cmp eax, edx ; binary int1 block search seg000:0001D8FE jz short loc_1D931 seg000:0001D900 mov ecx, eax seg000:0001D902 add ecx, edx seg000:0001D904 shr ecx, 1 seg000:0001D906 cmp edi, cs:[ebp+ecx*4+0] seg000:0001D90B jz short loc_1D918 ; int1block found seg000:0001D90D jb short loc_1D914 seg000:0001D90F mov eax, ecx seg000:0001D911 inc eax seg000:0001D912 jmp short loc_1D8FC ; binary int1 block search if it finds a matching block, the handler copies the ram from usermode into kernelmode alloced mem and returns to same offset, but in kernelmode. to prevent problems with non sf-processes, sf installs a hook in the kernel's SwapContext-routine (!). this hook will be executed when a new thread gets the cpu. when a sf thread gets scheduled, this SwapContext-hook makes sure proper debugregs (and ram?) are setup. when a non-sf-thread gets scheduled, sf restores debugregs (and ram?).