Page 1 of 2 12 LastLast
Results 1 to 15 of 27

Thread: int 20 (hinte's crackme #6)

  1. #1
    Red wine, not vodka! ZaiRoN's Avatar
    Join Date
    Oct 2001
    Location
    Italy
    Posts
    922
    Blog Entries
    17

    int 20

    hi to all,
    it's possible detect sice using this piece of code:

    int 20 vxdcall vxdldr_getdevicelist
    xor ebp, ebp
    mov ebx, [eax+5]
    cmp ebx, 0xC0000000
    pushfd
    and dword ptr [esp], 01

    maybe i'm wrong but think that the last three instructions are potentially dangerous. any hint?


    thanks in advance,
    ZaiRoN

  2. #2
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,143
    Blog Entries
    5

    Exclamation

    Hi ZaiRoN

    In what way do you mean dangerous? This is one pretty slick code snippet.

    I think I'm going to leave this one up to the user to explore, but basically what is returned in [EAX+05] is the VxD_Desc_Block structure (DDB or Device Description Block) for the most recent VxD in the list of devices maintained by VXDLDR.

    The CMP EBX,C0000000 statement is the amazing one in that it returns the Device_ID for Softice in esp-4. [WRONG, DUMMY!!, see later comment on how Numega may have chosen their Device_ID...] The pushfd statement is simply accessing that stack parameter. I assume there's a conditional jump statement somewhere later on.

    Are you at liberty to say where you found this code? Like some nasty virus or cryptor we may want to defend ourselves against? Some might consider this code potentially dangerous...

    Kayaker

  3. #3
    Red wine, not vodka! ZaiRoN's Avatar
    Join Date
    Oct 2001
    Location
    Italy
    Posts
    922
    Blog Entries
    17
    Hi Kayaker,

    first of all i'd like to thank u for the reply

    I assume there's a conditional jump statement somewhere later on.
    perfect! you have hit the centre of the target
    the problem is that jump (absolute, non conditional!).

    you can found this code snippets in the hinte's crackme#6 (download it from the crackme site).

    ZaiRoN

    ps. maybe it would be possible to move the discussion to the mini project area...

  4. #4
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,143
    Blog Entries
    5
    OK ZaiRoN, this is one hell of a crackme, it might make one hell of a project. I'll up the target file here as well.

    To start with, I have to ask if you managed to break into the crackme to start tracing. Loader32 and Icedump failed to break at WinMain. I was able to start the crackme with Frogsice, which reported there were various Code 00 attempts being made to detect Softice. If I tried to use hmemcpy to monitor the s/n being inputted I got some lovely BSOD's. Needless to say I haven't progressed on the keygen routine or even found the SI detection code you listed.

    I did find a few interesting things out though because I was able to break at WinMain and start tracing in a traditional way by cheating and using my own loader, part of the Softice backtrace disassembler proggy Clandestiny and I are working on. It uses a dll injection technique that allows you to *jump* into the program OEP. No way to detect it since it's non-traditional, so no way to prevent it ;-)

    I was able to put together a few SI backtraces of the actual code sequence the program starts up with. There was much zeroing of code bytes every so often, so I had to break up the backtraces and nop out the actual REPZ STOSB lines so the disassembler could disassemble the results properly. Anyway, here is some of the output I got from our tool (TraceDump). The numbers on the left are the trace output line numbers and will vary depending on where I broke up the backtracing and snipped the code. It doesn't progress towards the keygen at all, but it does show some interesting protection code. Not sure exactly what all the code is doing, but there's some interesting snippets nonetheless

    Remember this is the *actual* sequence of code executed, resolved from any SMC, because this is what the Softice backtrace is actually recording, our tool just disassembles those addresses which are stored in the backtrace buffer, while the program is loaded in memory. It starts at the OEP of 403E8F and there is much playing with the stack to produce valid jump addresses, here's a small snippet:

    Code:
    01	403E8F	688DE7F6C681		PUSH  DWORD C6F6E78D	;OEP
    02	403E94	8104241657493983	ADD  DWORD [ESP], 39495716
    03	403E9B	83C404FF		ADD  ESP, BYTE +4
    04	403E9E	FF6424FCEA		JMP  NEAR [ESP-4]	; jmp 403EA3
    05	403EA3	BB1D2216B881		MOV  EBX, B816221D
    06	403EA8	81C32AF6294868		ADD  EBX, 4829F62A
    07	403EAE	689CE7F6C681		PUSH  DWORD C6F6E79C
    08	403EB3	8104242657493983	ADD  DWORD [ESP], 39495726
    09	403EBA	83C404FF		ADD  ESP, BYTE +4
    0A	403EBD	FF6424FCEA		JMP  NEAR [ESP-4]	; jmp 403EC2
    0B	403EC2	5150			PUSH  ECX
    0C	403EC3	5033			PUSH  EAX
    0D	403EC4	33C0B9			XOR  EAX, EAX
    0E	403EC6	B942000000BF		MOV  ECX, 42
    0F	403ECB	BFC5E5675981		MOV  EDI, 5967E5C5
    10	403ED0	81EF36A7275990		SUB  EDI, 5927A736
    11	403ED7	9058			NOP
    12	403ED8	5859			POP  EAX
    13	403ED9	59FF			POP  ECX
    14	403EDA	FFD368			CALL  EBX		; call 401847
    15	401847	5B68			POP  EBX
    etc.

    Notice the NOP at 403ED7 (should actually be 2 nops). This is the first REPZ STOSB statement which normally would have zeroed out the previous code. I nopped it out to continue producing a usable trace for outputting. Eventually we'd like to do *real-time* dumping of the code so this wouldn't be necessary. So far nothing too interesting, I just wanted to show the general way the code works with all the stack jumps produced from adding a value to another value on the stack to produce a valid address.

    ...continued
    Attached Files Attached Files

  5. #5
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,143
    Blog Entries
    5
    The code continues on in this fashion for a while. There is a Structured Exception Handler (SEH) set up and an invalid opcode produced, but I wasn't able to break on the handler routine so I won't bore you with the code. The next interesting thing occurs here:

    Code:
    3C 4018EB  83C40483	ADD  ESP, BYTE +4
    3D 4018EE  83C404FF	ADD  ESP, BYTE +4
    3E 4018F1  FF6424FCEA	JMP  NEAR [ESP-4]


    Notice the two ADD ESP, BYTE +4 lines. If you allow both of them to execute you jump to Kernel32 code at address BFF8B560, which leads directly into an ExitThread call and the app never opens. It doesn't actually terminate, it's still listed as a 'task', but it never opens up. However, if you nop out one of the ADD lines, then the jump is instead back into valid program code. I'm not sure exactly what is happening here, whether the invalid opcode (F1) is being detected or what. The IDT hasn't been changed at this point so it's not a standard INT 6 invalid opcode hook or anything.

    Anyhow, the code goes on to access the starting address of the GDT and pops it into EBX:
    Code:
    2F 4026CC  0F014424FE5B		SGDT  [ESP-2]
    30 4026D1  5B33			POP  EBX
    
    Then it finds the LDT from the GDT address:
    
    36 4026E8  0F00C024		SLDT  AX
    37 4026EB  24F803		AND  AL, F8		
    ; al = D0h
    38 4026ED  03D868		ADD  EBX, EAX		
    ; add to GDT address
    39 4026EF  685CCD16B981		PUSH  DWORD B916CD5C
    3A 4026F4  810424A759294783	ADD  DWORD [ESP], 472959A7
    3B 4026FB  83C404FF		ADD  ESP, BYTE +4
    3C 4026FE  FF6424FCEA		JMP  NEAR [ESP-4]
    3D 402703  8A6B078A		MOV  CH, [EBX+7]	
    ; ch = 80	
    3E 402706  8A4B04C1		MOV  CL, [EBX+4]	
    ; cl = 0
    3F 402709  C1E11068		SHL  ECX, 10
    ; ecx = 80000000
    
    ECX is now 80000000, close to the LDT address...
    
    40 40270C  68AE5748C881		PUSH  DWORD C84857AE
    41 402711  81042472CFF73783	ADD  DWORD [ESP], 37F7CF72
    42 402718  83C404FF		ADD  ESP, BYTE +4
    43 40271B  FF6424FCEA		JMP  NEAR [ESP-4]
    44 402720  668B4B028D		MOV  CX, [EBX+2]
    ; cx = 3000
    ECX is now 80003000, the start of the LDT (at least on my system, type 'ldt' in SI)

    Then it writes into the LDT a valid call address. Note that an entry in the LDT, like the IDT, takes up two dwords (64-bits), and is laid out in a 'table' format like this:

    -------------------------------------------
    016F:80003008 34C7 0028 EC00 0040
    ; Icedump screendump of my LDT after the crackme code writes to it

    34C7h are bits 31...16 of the address
    0028h is the Target Segment Selector
    EC00 is a bunch of flags we don't care about
    0040h are bits 15...0 of the address

    So the real address coded here is 28:004034C7
    -------------------------------------------

    ...continued

  6. #6
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,143
    Blog Entries
    5
    And the LDT writing routine in the code:
    Code:
    Stores the Least Significant Word of the call address (34C7h):
    
    45	402724	8D7908FC	LEA  EDI, [ECX+8]
    46	402727	FC8B		CLD
    47	402728	8BC666		MOV  EAX, ESI
    48	40272A	66AB68		STOSW
    
    Stores the Segment Selector and the bullshit flags we don't care about:
    
    4D	402740	B8280000ECAB	MOV  EAX, EC000028
    4E	402745	AB0F		STOSD
    
    Stores the Most Significant Word of the call address (0040h):
    
    4F	402746	0FA4F01068	SHLD  EAX, ESI, 10
    ...
    54	40275E	66AB61		STOSW
    
    
    And finally this address, which the proggy cleverly 
    inserted into the LDT is called:
    
    8C	40284C	9A000000000F0051	CALL  F:00000000

    which is to 28:004034C7. Since this uses the segment selector normally reserved for vxds, I couldn't use TraceDump to output trace from it because the SI backtrace BPR doesn't allow it, and Icedump /screendump similarly failed. So you'll have to take my word for it that the code is:
    Code:
    28:4034C7 PUSH 6B3CAE82
    28:4034CC SUB DWORD PTR [ESP], 6AFC8B9E
    28:4034D3 ADD ESP, 4
    28:4034D6 CALL [ESP-4]
    28:4034DA RETF

    After returning to the regular segment selector the code continues on (seemingly forever, sigh):
    Code:
    8D	402853	5150		PUSH  ECX
    ...
    96	40286B	C3EA		RET

    Actually, you don't have to take my word for it. There is no breakpoint detection at least in this part of the code, so if you set a BPM on any of the addresses I gave above (using your own normal CS selector) you *should* break freely. i.e.
    BPM 167:4026CC X
    should get you at where the GDT is read:
    4026CC 0F014424FE5B SGDT [ESP-2]

    Anyway, I'll hope you'll forgive me for going off on a tangent, I just enjoy ferreting out sneaky little code snippets like this. If we're to protect ourselves from questionable code practices (viral perhaps), then we need to start by being aware of them.

    Cheers,
    Kayaker

  7. #7
    my new hair style :) +SplAj's Avatar
    Join Date
    Feb 2001
    Location
    Afghanistan, Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria
    Posts
    373

    Question ????

    Hi Kayaker

    thanx for the indepth analysis. those SEH redirections are the 'vogue' thing right now

    I d/l said target and of course it won'r run on WinNT/2K platform. Interesting point is no IAT or IT in header ?

    Is it packed or just re-aligned very aggressively to 0x200 ?

    I don't have Win98 here to analyze further...........

    Spl/\j
    Carve my name into your arm :)

  8. #8
    Red wine, not vodka! ZaiRoN's Avatar
    Join Date
    Oct 2001
    Location
    Italy
    Posts
    922
    Blog Entries
    17
    HI Kayaker

    i agree with +SplAj, your analysis sounds good

    my initial goal is to study how the program detect the sice. no keygen for the moment...maybe another mini project

    the serious thing:
    fundamentally i have found 3 kinds of protection against sice: seh, ldt and the int20.

    1) seh:
    here is how it installed the seh:

    401876: push 49975D87
    40187B: sub dword ptr [esp], 49572959
    401882: xor eax, fs:[ebx]
    401885: push eax
    401886: mov fs:[ebx], esp

    after the sub, [esp]=40342E. 40342E is the handler u are looking for
    so, when you found the invalid opcode (at 4018BE) redirect the flow to the routine handler.

    for the ldt i think you have just said everything..but i have a question for u:
    8C 40284C 9A000000000F0051 CALL F:00000000
    Since this uses the segment selector normally reserved for vxds
    it's necessary to use this segment?
    when u are in the call above try to redirect the flow to the 4034C7 of the original segment. some lines and you'll find the int20 code...

    for +SplAj:
    Is it packed or just re-aligned very aggressively to 0x200 ?
    i don't know...i think it's certainly re-aligned.

    all for the moment, i think that there will be very much to learn from this crackme

    ZaiRoN

  9. #9
    Red wine, not vodka! ZaiRoN's Avatar
    Join Date
    Oct 2001
    Location
    Italy
    Posts
    922
    Blog Entries
    17

    another little thing

    hi Kayaker

    8C 40284C 9A000000000F0051 CALL F:00000000
    maybe i'm wrong but i think that hinte wants to bring us in the wrong way forcing the flow in the segment reserved for the vxd.
    if you try to jump to 4034C7 (in the original segment) and step a little you'll found a very interesting decryption routine (4022F8/402354).
    after that routine the bytes from 403DD5 to 403E8E turn out very intersting. i've found things like user32.dll, Getmodulehandle, MessageBox etcetc...
    maybe it's a good thing

    ZaiRoN

  10. #10
    Red wine, not vodka! ZaiRoN's Avatar
    Join Date
    Oct 2001
    Location
    Italy
    Posts
    922
    Blog Entries
    17
    hi,
    someone is working to the project?

    i have a little question for u:
    The CMP EBX,C0000000 statement is the amazing one in that it returns the Device_ID for Softice in esp-4.
    if Softice is not in the device list which it's the value of ebx?

    ZaiRoN

  11. #11
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,143
    Blog Entries
    5
    Hi ZaiRoN

    I'm definitely still working on this as I get the chance. Your last posts were very helpful! Redirect the LDT call using a regular code segment and sure enough lots of interesting things appear. Now we know where the IT went to

    Strange how the jump after the Int 20 call goes to address 000282. Actually I got the exact same address if I tried to trace into the jump that was in the 0028 segment LDT Call F:00000000 . You can F10 step over this call, but just don't try tracing into it without redirecting it into a regular code segment.

    BTW, this funny looking call can be understood by typing 'LDT' in Softice before and after you've run the crackme for the first time and you see how it's created a Ring3 gated call:
    Code:
    LDTbase=80003000  Limit=3FFF
    0004  Reserved  00000000  00000000  0    NP
    000F  CallG32   0028:004034C7       3    P
    0014  Reserved  00000000  00000000  0    NP
    As for what's happening on that VXDLDR_GetDeviceList Int 20 call:

    I don't think the value of EBX itself changes if SI isn't loaded, it still seems to be the DDB of the most recent VxD. The reason I say this is that I had inserted the code you initially posted into my own vxd code, and the value in mov ebx, [eax+5] was the DDB of my own vxd, which was easy to recognize from the DDB_Name field in the DDB structure.

    Here's the output and structure just for reference. Note that there seems to be more than one define of the VxD_Desc_Block (DDB) structure around, this one is from vmm.inc and seems to be comparable to what you see in Softice.
    Code:
    EBX=D56A78F0
    0030: D56A78F0 C01677D8  0000040A  80020001  43415254      .w..........TRAC
    0030: D56A7900 504D5544  80000000  CAA05730  00000000      DUMP....0W......
    0030: D56A7910 00000000  00000000  00000000  00000000      ................      
    0030: D56A7920 00000000  00000000  00000000  D56EBD00      ..............n.      
    0030: D56A7930 00000050  52737631  52737632  52737633      P...1vsR2vsR3vsR     
    
    VxD_Desc_Block	STRUC
    DDB_Next	DD	?
    DDB_SDK_Version	DW	DDK_VERSION
    DDB_Req_Device_Number	DW	UNDEFINED_DEVICE_ID
    DDB_Dev_Major_Version	DB	0
    DDB_Dev_Minor_Version	DB	0
    DDB_Flags	DW	0
    DDB_Name	DB	"        "
    DDB_Init_Order	DD	UNDEFINED_INIT_ORDER
    DDB_Control_Proc	DD	?
    DDB_V86_API_Proc	DD	0
    DDB_PM_API_Proc	DD	0
    DDB_V86_API_CSIP	DD	0
    DDB_PM_API_CSIP	DD	0
    DDB_Reference_Data	DD	?
    DDB_Service_Table_Ptr	DD	0
    DDB_Service_Table_Size	DD	0
    DDB_Win32_Service_Table	DD	0
    DDB_Prev	DD	'Prev'
    DDB_Size	DD	SIZE(VxD_Desc_Block)
    DDB_Reserved1	DD	'Rsv1'
    DDB_Reserved2	DD	'Rsv2'
    DDB_Reserved3	DD	'Rsv3'
    VxD_Desc_Block	ENDS
    ------------------------------------------------

    I had said that the CMP EBX,C0000000 statement returns the Device_ID for Softice in esp-4 because, well because it seemed to, id 202 kept appearing there. But I've just been noticing sometimes a slightly different return value as well under different conditions. I wouldn't mind if someone could confirm this.

    The real question is what Device_ID is returned if SI isn't loaded, which I'm sure is what you really meant Zairon. I'm going to try to test this later tonight by passing that value in esp-4 via DeviceIOControl and outputting it to a MessageBox.

    BTW, for those wanting to mess with this, an easy way to get into the code is to use Icedump with /PROTECT on. This will break when the GDT gets accessed for the 1st time. Turn protect off and you can start tracing. Not to worry, any BSOD's aren't harmful and don't reboot, just refresh with F5. You can change the LDT segment selector in memory to redirect jumps simply by changing the 0028 to your own CS.

    Kayaker

  12. #12
    Red wine, not vodka! ZaiRoN's Avatar
    Join Date
    Oct 2001
    Location
    Italy
    Posts
    922
    Blog Entries
    17

    Exclamation doubts...

    Hi Kayaker,

    your last post has made me think a little bit. in particular a single phrase:
    I don't think the value of EBX itself changes if SI isn't loaded
    that's the point! i asked in another forum if it's possible detect softice using this method (int20blablabla); this is the (translate badly from italian to english...sorry) explanation given by Kill3xx (thanks a lot):

    "the services of the VxD loader are to appanage of the dynamics (loadable) vxd.. and consequently the device_info list (and the ddb) not includes vxd loaded statically or "dynamically" by the vmm at the boot..."

    so, the question is: why use this function??? which it is the sense??? is this only a trick to gain the r0 mode ?!?!!

    another thing: i've given a look to the code that follows the damned jump. there's a little routine that slides entire the ddb. it will be another trick to bring us on the wrong way or ...something else

    bha...

    that's all friend,

    ZaiRoN

  13. #13
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,143
    Blog Entries
    5
    OK, I see what you mean Zairon, VxDCall VXDLDR_GetDeviceList is only used for dynamically loaded vxds, and I found that VMMCall VMM_GetVxDLocationList is used for statically loaded vxds:

    Code:
    VMMCall VMM_GetVxDLocationList
    jz      ErrorHandler
    mov     [TableAddress], eax
    mov     [VxDCount], edx
    mov     [TableSize], ecx
     
    Returns the address of the VxD location list in EAX,
    returns the count of VxDs in EDX, and 
    returns the list size (in bytes) in ECX.
    Uses EAX, ECX, and EDX. 
    
    Returns the address of the VxD if the function
    succeeds; otherwise, sets the zero flag. 
    The VxD location list is a packed array of variable
    length Device_Location_List structures.
    The Device_Location_List structure will similarly give you a linked DDB list for statically loaded vxds:

    Code:
    Device_Location_List	STRUC
    DLL_DDB	DD	?
    DLL_NumObjects	DB	?
    DLL_ObjLocation	DB	SIZE ObjectLocation * 1 DUP (?)
    I threw this in some code and by following the DDB_Prev field of the VxD_Desc_Block confirmed the static vxds I had loaded - VMM, CSHOOK, SHELL, VFBACKUP,... Eventually I assume I would have hit SIWVID and WINICE but I didn't want to scroll through my 56 vxd entries to find it.


    So, with these 2 calls, VMMCall VMM_GetVxDLocationList and VxDCall VXDLDR_GetDeviceList, you can get a list of all the static and dynamically loaded vxds on your system.

    In fact, this is how Softice generates the list you see when you type 'vxd'. You can find these addresses in winice.exe here:

    Code:
    C005E004	mov esi, offset aVxdNameAddress 
    ; "VxD Name  Address   Length  Seg   ID   "...
    C005E009	call    sub_C0018A8A
    ...
    C0082FD2	VxDcall VXDLDR_GetDeviceList
    ...
    C008E6F7	VMMcall VMM_GetVxDLocationList
    As a sideline, you ever used IceClimber by Trapflag? It allows you to set breakpoints within Softice itself. Makes for some interesting bedtime tracing I haven't tried it with this crackme, but it *may* allow you to set bp's within those 0028: code segments as well, just a thought.


    So you're right about the use of VXDLDR_GetDeviceList, why use this function if all it returns is the most recent dynamically loaded vxd in EBX? But tell me, if you type 'd ebx' in SI what vxd name do you see? If you've got Icedump loaded, what name do you see?... If you follow the DDB_Prev field back 2 or 3 links does this not look like the (dynamic) list you get with 'vxd' in SI?

    I still don't know how this relates to what happens after the VXDLDR_GetDeviceList call or what is happening on the stack though, and I haven't been able to get past that jmp esp-4 statement yet.

    Back to the drawing board...

    Kayaker

  14. #14
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,143
    Blog Entries
    5
    Hi

    Just a quick note to set the record straight. I see I was *way* off base thinking that this code had anything to do with the Device_ID for Softice. It was just (bad) luck that I first saw the value of 0202h appearing on the stack. This *is* actually the ID for winice, which is what threw me at first, but has nothing to do with that.

    Instead this is simply the value of the Flags register, and changes on any command that changes the flags. Check the Art of Assembly Language Chapter 6 or the Intel Developers Manual 1 under EFLAGS for a detailed explanation. The latter states that "When a call is made to an interrupt or exception handler procedure, the processor automatically saves the state of the EFLAGS registers on the procedure stack", explaining its presence there.

    The flags you see in the Softice Register window and the hex value you see on the stack can be understood by changing the value to binary and following the bit pattern.

    Bit 0 - C (Carry flag)
    Bit 1 - Reserved, set to 1
    Bit 2 - P (Parity flag)
    Bit 3 - Reserved, set to 0
    Bit 4 - A (Auxiliary carry flag)
    Bit 5 - Reserved, set to 0
    Bit 6 - Z (Zero flag)
    Bit 7 - S (Sign flag)
    Bit 8 - Trace (Trap) flag, not shown by Softice
    Bit 9 - I (Interrupt flag)
    Bit 10 - D (Direction flag)
    Bit 11 - O (Overflow flag)
    Bits 12-31 not shown by Softice

    So the value of 202h I just happened to see (binary 001000000010) corresponded to the flags being set like this (remember Bit 1 is set to 1 by default):
    o d I s z a p c

    If it was 206h (001000000110) the flags would be:
    o d I s z a P c

    You can actually test this in the crackme code (or your own vxd verion) by changing the flags with 'R FL <flag>' and seeing how the value on the stack changes.


    Knowing this we can start to look at what the rest of the code is doing.
    Code:
    int 20 vxdcall vxdldr_getdevicelist
    xor ebp, ebp
    mov ebx, [eax+5]
    cmp ebx, 0xC0000000
    pushfd
    and dword ptr [esp], 01
    - mov ebx, [eax+5]
    we know moves the VxD_Desc_Block structure (DDB or Device Description Block) for the most recent dynamically loaded VxD into ebx.

    - cmp ebx, 0xC0000000
    is something I have seen documented in some viral code, followed by a jc @@next_vxd (Jump if Carry, follow DDB_Next to next VxD_Desc_Block, repeat loop).

    - pushfd
    - and dword ptr [esp], 01
    pushes the EFLAGS register onto the stack and ANDS the value with 01, checking the Carry flag.

    Now the CMP statement modifies the Carry flag in the following way:

    cmp ax, bx
    C: The carry flag is set after a cmp operation if subtracting bx from ax requires a borrow. This occurs only when ax is less than bx where ax and bx are both unsigned values.

    So I would hazard this code may be checking for what vxds are loaded. If it's using the DDB_Next field as in the viral example, then you can trace this yourself from the initial DDB obtained and see that you can get into the *statically* loaded vxds as well.

    There is further code going on after this, including a CDQ division, but I haven't looked at it yet in this new light. All the viral coders are probably snickering behind their hands right now, but that's OK, either snicker or help.

    Cheers,
    Kayaker

  15. #15
    Red wine, not vodka! ZaiRoN's Avatar
    Join Date
    Oct 2001
    Location
    Italy
    Posts
    922
    Blog Entries
    17
    hi,

    as always your posts were very interesting
    sorry me but i can't understand the role of the flags. maybe i'm wrong but your are saying that this code:
    Code:
    cmp ebx, 0xC0000000
    pushfd
    and dword ptr [esp], 01
    is used for sliding all the vxds (stat. or dyn.)?


    for the rest:
    If it's using the DDB_Next field as in the viral example...
    i think we have read the same article
    perhaps it is this:
    Code:
    call vxd                                ;VXDLDR GetDeviceList
      @@next:
           mov ebx, [eax+5]                        ;VxD_Desc_Block *DI_DDB
           sub ebx, 0C0000000h
           jc @@next_vxd
           lea ecx, [ebx+0C000000Ch]               ;Name_0
           cmp [ecx], 'DIPS'                       ;'SPIDER  '
           je @@patch
           cmp [ecx], '9PVA'                       ;'AVP95   '
           jne @@next_vxd
    here is what the crackme is doing! i have take a look to the code beyond the "and dword ptr [esp], 01" and i have found something like that:

    cmp [ecx], 'FILE'

    try lo load filemon and run the crackme. you'll see what i'm saying

    maybe something more tonight...

    ZaiRoN

Similar Threads

  1. Need help with crackme
    By lucid_dream in forum The Newbie Forum
    Replies: 4
    Last Post: January 12th, 2005, 04:32
  2. help with this crackme
    By chitech in forum Mini Project Area
    Replies: 2
    Last Post: August 28th, 2002, 11:41
  3. try this crackme
    By SaNGa in forum Mini Project Area
    Replies: 11
    Last Post: June 4th, 2002, 20:13
  4. A little crackme
    By raven58 in forum Advanced Reversing and Programming
    Replies: 1
    Last Post: February 14th, 2001, 18:19

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •