Hi
does anybody know how can I set a bpx to hmemcpy? I use Softice 4.05 on WinNT4; set the dll files into winice.dat but in softice command line: bpx hmemcpy --> I get a message symbol undefined. I read a few essay where they use this bpx but how did they set? I also checked all dll's which are in winice.dat file but noone has this function inside?I will be very appreciate anybody who can help me.
Dipsy

For Windows NT and Windows 2000 try memcpy instead.
Look back in this forum and at the Reverse Forum. This topic has been discussed in depth before.

Regards,

Bratsch

Thanks to answer me. So this is the function from a particular dll and if I set bpx to this function ( or maybe some one else ) and softice don't pop up, it means that program doesn't use it. Am I correct? Which functions use the program I can check by disasembler also?
Denis

hmemcpy and memcpy are found in the kernel of windows and windows NT respectively, they do not belong to a particular .dll in a software package.
hmemcpy is extensively used by Windows API functions to copy a string from one place to another. For example: you write a serial number in a dialog provided by your application. when you click "OK" or "register" or whatever button the dialog has, it may activate one of several API functions: GetWindowTextA or GetDlgTextItemA, GetDlgStringA, GetDlgItemInt etc. This functions in turn will use hmemcpy to perform the simple process of moving your input from place A (the buffer where windows stored temporarily, to place B, the memory buffer that your app set aside to store the user input.
The advantage of hmemcpy or memcpy is that you do not have to guess what API function the programmer used to read your input, it is at a lower level and is independent of the calling API function. Once you determined the destination of your input serial (or name or whatever), you may set up a BPR or BPM to at the relevant asddress and catch the App. evaluating/manipulating it. for more details consult a copy of the CracKnotes http://crknotez.cjb.net/, a handy HTML compilation where the use of hmemcpy is explained in detail.

You are correct, if Sice does not break, the function you set a BPX on has not been called. The program may still use it later, it depends on the which path in the flow of the program you are.

With a dissasembler you can check the list of imported API functions, which may be very large. Knowing which functions are imported and used by the program may or may not help you in reversing it. The trick is knowing WHICH function is called at the relevant moment. The same function may be called multiple times to perform other services that may not be relevant for your reversing purposes.

Hope this helps.

That function is actually inside the MS C runtime library. It's implemented this way on all C supportive platforms (just about all of'em )

Check out the MSVCRT*.DLL at windows\system.

LS


-------------------------------------
hmemcpy and memcpy are found in the kernel of windows and windows NT respectively, they do not belong to a particular .dll in a software package.

just out of curiousity....I know hmemcpy doesn't work on NT....but does BozosLiveHere?
(Probably not useful info for as often as that API gets called, but as I said...I'm curious)

hmemcpy, Bozoslivehere are 16 bit routines; you can't find them in any NT version.
Memcpy is the 32bit version of hmemcpy, but it doesn't perform the same function as hmemcpy in Win 9x (inside the Operating System, I mean); you cannot use "bpx memcpy" in NT and obtain same effects as "bpx hmemcpy"

hmemcpy is a 32 bit function Alright, check it in Sice:
it uses extended registers.
This is a code snipet from inside hmemcpy taken directly from the cracknotes:

PUSH ECX
SHR ECX,2 ; number of words to copy
REPZ MOVSD ; copies from DS:ESI (32-Bit) to ES:EDI (32-Bit)
POP ECX
AND ECX,3
REPZ MOVSB ; same as REPZ MOVSD, but only 1 Byte
XOR DX
XOR AX

16 bit code cannot use ESI, ECX or EDI.

The function as stated by Sice is part of the KERNEL!HMEMCPY code. Check the code upper margin of the code window in Sice.

I don't know anything about the cracknotes, and don't figure why ppl feel the need to speak about arguments that don't know at all.
HMEMCPY was implemented first in Windows 3.0 (16 bit) and was, and still is, exported by KRNL386.EXE, a 16 bit (obviously) module; its name corresponds to ordinal 348, at least in Windows 3.1, Windows 95, Windows 98, Windows NT 4 and Windows 2000. This is part of the disassembly listing of the function from the KRNL386 module part of Windows 2000 Build 2128 (a pre-release version); the implementation in Windows NT, 9x and 3.1 is almost identical.

cseg01:8976 ; Attributes: bp-based frame
cseg01:8976
cseg01:8976 public HMEMCPY
cseg01:8976 HMEMCPY proc far ; CODE XREF: sub_0_9AFC+5Ep
cseg01:8976
cseg01:8976 var_2 = word ptr -2
cseg01:8976 arg_0 = word ptr 6
cseg01:8976 arg_2 = word ptr 8
cseg01:8976 arg_4 = dword ptr 0Ah
cseg01:8976 arg_8 = dword ptr 0Eh
cseg01:8976
cseg01:8976 enter 2, 0 ; KERNEL_348
cseg01:897A push ds
cseg01:897B push si
cseg01:897C push di
cseg01:897D mov ds, cs:word_0_30
cseg01:8982 mov bx, word_128B_464
cseg01:8986 mov [bp+var_2], bx
cseg01:8989 mov dx, [bp+arg_2]
cseg01:898C mov ax, [bp+arg_0]
cseg01:898F xor cx, cx
cseg01:8991 lds si, [bp+arg_4]
cseg01:8994 les di, [bp+arg_8]
cseg01:8997 cld
cseg01:8998
cseg01:8998 loc_0_8998: ; CODE XREF: HMEMCPY+7Fj
cseg01:8998 mov cx, 8000h
cseg01:899B cmp cx, si
cseg01:899D jnb loc_0_89A1
cseg01:899F mov cx, si
cseg01:89A1
cseg01:89A1 loc_0_89A1: ; CODE XREF: HMEMCPY+27j
cseg01:89A1 cmp cx, di
cseg01:89A3 jnb loc_0_89A7
cseg01:89A5 mov cx, di
cseg01:89A7
cseg01:89A7 loc_0_89A7: ; CODE XREF: HMEMCPY+2Dj
cseg01:89A7 neg cx
cseg01:89A9 or dx, dx
cseg01:89AB jnz loc_0_89B3
cseg01:89AD cmp cx, ax
cseg01:89AF jbe loc_0_89B3
cseg01:89B1 mov cx, ax
cseg01:89B3
cseg01:89B3 loc_0_89B3: ; CODE XREF: HMEMCPY+35j
cseg01:89B3 ; HMEMCPY+39j
cseg01:89B3 sub ax, cx
cseg01:89B5 sbb dx, 0
cseg01:89B8 test [bp+var_2], 2Ch
cseg01:89BD jnz loc_0_89CA
cseg01:89BF shr cx, 1
cseg01:89C1 repe movsw
cseg01:89C3 adc cx, 0
cseg01:89C6 repe movsb
cseg01:89C8 jmp short loc_0_89D7
...
...
; CODE XREF: HMEMCPY+65j
cseg01:89FF pop di
cseg01:8A00 pop si
cseg01:8A01 pop ds
cseg01:8A02 assume ds:dseg04
cseg01:8A02 leave
cseg01:8A03 retf 0Ch
cseg01:8A03 HMEMCPY endp

This means that if you add "EXP %SystemRoot%\system32\krnl386.exe " to the export list in SoftICE, on any NT system, SoftICE will accept the "bpx hmemcpy" command; however, SoftICE will never break on it because HMEMCPY is a 16 bit function and neither the Win32 subsystem, nor the NT DOS Virtual Machine will never call it. HMEMCPY is still implemented for backward compatibility, just in case some program called it directly, but I've never seen a program that referenced it. In Windows 9x, as many OS function are implemented by thunking on 16bit modules, HMEMCPY is widely used in order to perform memory chunks copying;therefore, the related EXP line is present in default .DAT file. Not so on NT system; beside MEMCPY DO NOT perform same functions as HMEMCPY in 9x system, so setting a such breakpoint is useless for cracking purposes.
Regards

Sorry anonymous, I talked to fast.
And I had extra beers when I answered your post. (Take this as an apology).
Hmemcpy is 16 code.
I did the homework now.

yup, anonymous here is right again. In fact, it appears that the 16 bit code of many windows functions are actually mixed 16 and 32 bit routines. That means they've got both 16 bit code and 32 bit code. Even more, MS designed a compiler specifically for this purpose, which is to compile to this kind of hybrid thunked down code. It's an interesting approach, but not too great heh

Anyways, it's still a good thing to sometimes use a low level function such as this to copy chunks of memory, but usually
a win32 program doesn't need to do that.

LS