I wrote a little trainer in VB6 for Diablo II and I'm using the following assembly instruction:

mov dword ptr [Pointer], EDI
#Proper return sequence back to process down here

My entire assembly code is working fine. All I did was convert it over into VB using the WriteProcessMemory function among others. Nothing hard about it. Anyway, no compiling errors or anything and I KNOW my assembly code is solid. I've debugged it several times before starting the VB project. It's 100% flawless and works perfect in .dat format! After launching Diablo II and creating a game I fire up my VB trainer and load everything into memory. I double check in SoftICE to make sure everything is loaded into the correct memory locations and all the instructions are the same as my assembly version. My final step in making sure everything is running smoothly is to turn Faults ON just to be safe. When I tested my hack SoftICE catches a fault and it's on the instruction above. Which was "mov dword ptr [Pointer], EDI" It will not write to ANY static pointer I give it. It completely ignores my instruction, even though it's there in memory plain as day! On NT I receieve a STATUS_ACCESS_VIOLATION. So I get to thinking, something is fucked up with the actual WriteProcessMemory function in Windows 2000 or the way VB compiles the program. I'm running Windows 2000 btw.  It seems once it hits that instruction it returns STATUS_ACCESS_VIOLATION and crashes the application or even Windows itself. I'm completely and utterly stumped. Any of you out there run into similar problems? Do you have a VB6 solution???

Everything is declared properly in my module. Here is what it looks like:

Public Declare Function WriteProcessMemory Lib "kernel32" (ByVal hProcess As Long, ByVal lpBaseAddress As Any, lpBuffer As Any, ByVal nSize As Long, lpNumberOfBytesWritten As Long) As Long

Public Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal Classname As String, ByVal WindowName As String) As Long

Public Declare Function GetWindowThreadProcessId Lib "user32" (ByVal hWnd As Long, lpdwProcessId As Long) As Long

Public Declare Function OpenProcess Lib "kernel32" (ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, ByVal dwProcessID As Long) As Long

Public Declare Function CloseHandle Lib "kernel32" (ByVal hObject As Long) As Long

Public Const PROCESS_ALL_ACCESS = &H1F0FFF

My form is laid out using 4byte max Writes. I could have used arrays, but this was much quicker. Here's a sample

WriteProcessMemory pHandle, &Haddress, &Hreverse opcodes, 4, 0&
etc.

If any of you are familiar with NT programming in VB6 I could really use some help. I don't want to release the source to my D2 hack, but if it means learning what's wrong I might. It just doesn't make any sense to me. I sent my compiled VB version to a friend running 98SE and it works fine, but not under 2K and no doubt XP.

what is clan ze][2o's site?

Inline asm in VB? lol

I'm surprised it even compiles :P

Actually, he's using WriteProcessMemory so it's all good.

The easiest solution would be, of course, to tell you to use VB for what it's meant for (for example, not for hacking).  But, since it's doubtful that you'd listen to me, I can't really help you.

If I remember my assembly right, you can't assign directly to a memory address, only to a register, so try moving the address to a register first, then try assigning to it:

lea eax, Pointer
mov eax, EDI

or something like that
also, if eax is being used for something else, you might want to try push eax/pop eax before and after.

No, you can mov dword ptr [mem], value.  See http://www.valhallalegends.com/files/386INTEL.TXT...

"3.1.1  General-Purpose Data Movement Instructions

MOV (Move) transfers a byte, word, or doubleword from the source operand to
the destination operand. The MOV instruction is useful for transferring data
along any of these paths
There are also variants of MOV that operate on segment registers.  These
are covered in a later section of this chapter.:

 þ  To a register from memory
 þ  To memory from a register
 þ  Between general registers
 þ  Immediate data to a register
 þ  Immediate data to a memory
"

Yes, VB's quite the toy for hacking (not). Standard Win32 API WriteProcessMemory() is passing the address of the buffer to a procedure instead of passing the value. So maybe you could try passing the value instead?

I know VB isn’t the ideal language. That’s why I’ve programmed my entire hack in MASM and also dumped the opcodes into .dat format so I can load it with Temp’s Dhack. I mostly just wanted to see if I could do it in VB. I don’t know C++ at all or how to use VC++. I’m an Assembly junkie.

I would have passed the value directly to my static pointer, but you see I can't ;-) I'm going to spill the beans when I tell you why. Monster ID#s are random each game you enter on D2. I've made a PvM Auto Attack w/ Cursor Selecting on D2 realms that allows me to highlight a monster and continually attack it using a hotkey if I want. It's pretty handy on main bosses. I can highlight them and run into a corner. Press my hotkey and keep attacking them while they are unable to harm me, but anyway that's why I can't mov a static value into my pointer spht.

What stumps me though is it compiles and runs perfect on Win 98, but not 2K. Any explanation for that? I was under the impression that…

Public Const PROCESS_ALL_ACCESS = &H1F0FFF  

… would let me access the pid from the windowhandle and give me full rights to memory in NT. Is there something I need to do before writing to memory in 2K?
If I trace the code in SoftICE once it hits the instruction and I trace once and “D mystaticPointeraddy” It doesn’t move the info from EDI, but in 9X it does. It has to be something stupid like memory rights access. I can’t find anywhere on google.com or msdn any info on it though.

Anyway, I’ll try your idea iago. Thanks for atleast replying to my cheese post! ;-P

Ugh, YaBB screws up my post. Hopefully it's still readable because I'm not going to run through and fix it.

[code]
'Necessary flags for NT
Public Const STANDARD_RIGHTS_REQUIRED = &HF0000
Public Const SYNCHRONIZE = &H100000
Public Const PROCESS_ALL_ACCESS = (STANDARD_RIGHTS_REQUIRED Or SYNCHRONIZE Or &HFFF)
[/code]
Yes, that's the same as yours just a little bit neater...

Try adding this, my friend told me it's necessary when writing memory in Win2k/xp, although I don't know why:
[code]'for determining OS version
Declare Function GetVersionExA Lib "kernel32" (lpVersionInformation As OSVERSIONINFO) As Integer
'User defined type for OSVERSIONINFO
   Public Type OSVERSIONINFO
      dwOSVersionInfoSize As Long
      dwMajorVersion As Long
      dwMinorVersion As Long
      dwBuildNumber As Long
      dwPlatformId As Long           '1 = Windows 95.
                                     '2 = Windows NT

      szCSDVersion As String * 128
   End Type[/code]

stupid why did you post that on this topic? lol.  It moved to http://exodeus.net/zer0/ and its not clan ze][2o, its clan ZeR0

You might need to use VirtualProtectEx to change the access permissions on the memory you're writing to in the other process.  Windows 9x doesn't enforce those permissions very reliably, but Windows NT does.

[quote]You might need to use VirtualProtectEx to change the access permissions on the memory you're writing to in the other process.  Windows 9x doesn't enforce those permissions very reliably, but Windows NT does.[/quote]

Indeed, I was surprised that that was not the first suggestion he received from all the talented programmers frequenting this forum.

Paul, if your going to make a d2hack why note just make d2hackitmodule? theres already a module for attacking a monster like 10 times everytime you click on it

you could just log the packet of when you click on an entity, and keep sending it.

for your problem with monster id changing, just check the 0x55 packet it's got all your entity needs

I like challenging myself to code everything. I've seen d2hackit but never actually used it. Like I mentioned to spht, this is all a learning experience to put under my belt. I've finally reached the point with assembly programming that it's getting monotonous and it's time to learn something new. Now I'm working with VB6 because it's all I have. The VS6 download had too many crc errors so VC++ doesn't install properly.

0x55 hrm.. I'm using 0x0a right now with cursor selecting as a way of targetting new monsters. I haven't even seen 0x55 yet I don't think. I guess I'll have to do more logging.  :) That sort of bums me out though, I was hoping I had an original idea for D2. Apparently not!