[Blackhawk]

Okay, Reasking...I'm not that fit in Assembler, so excuse if i am talking bullshit

Base of DLL in this particular moment is hex 01050000
The pointer is at hex 0127B4E8
Value will be pointer + hex 134

/edit: OK, found out - more or less

I got somethin like this

new Pointer = memhack_get_pointer(193794...,MEM_DLLBASE,MEMTYPE_DATA)
new Target = Pointer + 308
server_print("Float value (rounded): %.2f",memhack_get_float(Target,MEM_DLLBASE,MEMTYPE_DATA)
memhack_set_float(Target,MEM_DLLBASE,200.0,MEMTYPE_DATA)
server_print("Float value (rounded): %.2f",memhack_get_float(Target,MEM_DLLBASE,MEMTYPE_DATA)

The first server print shows the expected value clearly
Whatsoever, the set_float resets the value to 0, no matter what i say.
So the second printout in this function gets me a 0 back...
Can you tell me where i got my error?

/Edit2:
Debugger shows the following

mov ecx,[esp + 1c]
mov [esi],ecx

however [esp + 1c] is realy set to 0 here. I can toggle a breakpoint and change this to something that gets then transfered to the right offset, but it is always 0 when the brakpoint is reached. Maybe a bug or stupidity on my side?

[Twilight Suzuka]

The piece of memory might be write protected or some such, or you are setting it incorrectly. Make sure it isn't a quad or something.

[Blackhawk]

Tripple checked now...ok, here we go:

1) Memory can be read by the function shown above. (as float)
2) Trying to read it as quad will cripple the results. Float is OK.
3) When i try to set it, it will become 0, no matter what i'll try. But it proves it can't be write protected, because it get set to 0.
4) The particular memory is type float. Can be seen by memory editor as float and is editable as float.
5) Results in 0, too:

memhack_set_float(Target,MEM_DLLBASE,memhack_get_float(Target,MEM_DLLBASE,MEMTYPE_DATA),MEMTYPE_DATA)

What else can i check?

Btw: OS: Win2003

[Twilight Suzuka]

Are you sure it is type MEM_DATA?

[Blackhawk]

I think, yes...

Hmm, interesting - it doesn't matter what type of data i specify......MEM_DATA, RODATA and CODE will all result in the same value of zero.....

Memory region specified as followed:

State: Commit Access: Read + Write Type: Private

[Twilight Suzuka]

Well, I tested the module, and it seemed to work fine.

Sorry, can't help you ^^;

[Blackhawk]

That isn't quite the answer i would like to hear...

What would be needed to verify where the problem is? As i said, the debugger shows that a value is moved from the memhack module to the right point - but it also 0. There should be a cause to this behaviour.

If you need, there would be also the possibilty for remote access to the test machine.

[Twilight Suzuka]

For every test I've made, its worked ^^;

It isn't my module, unless there is something absurd I missed.

Does your debugger say memhack is setting the value to 0, or what?

[Blackhawk]

I'm sorry to say: Yes, it says so.
The debugger shows the following: The Memhack module is accessing the right address for writing operations, as expected. But it is setting it to 0

Ok, for references, here is the complete process:

The variable to change is at 00bd76e4. This adsress is know via a pointer, so here comes the first part:

new Pointer = memhack_get_pointer(19379432,MEM_DLLBASE,MEMTYPE_DATA)
new Target  = Pointer + 308
server_print("Memhack get float: %.2f",memhack_get_float(Target,MEM_DLLBASE,MEMTYPE_DATA))

This works perfectly: The value stored there in float is 100.0 and is shown corrctly. When the value changes, this is also shown correct. So READING the value is flawless in every way.

Now i was trying to change the value with the folling code:

new memhack_set_float(Target,MEM_DLLBASE,200.0,MEMTYPE_DATA)

Very simple, just for testing purposes.. It will be set to 0. I then let the debugger checked every write acess to the target and it was shown: Memhack realy accesses this value and changes it - this is the good part
The code that archives this at the end is simple:

 memhack assembler code:
mov ecx,[esp + 1c]
mov [esi],ecx

But this particular address [esp + 1c] is set to 0 when time has come.
So i think memhack does it's job perfectly: it writes a new value to the target, but not the value expected. ^^
What makes me think there may be a handler problem in the function MEMHACK_SET_FLOAT for the new float value...
All still happens under Windows, the test machine is windows xp.

/Edit:
it appears that i can't even set char's - alway 0 is the set value.....So, there are two possibilities: First one, and maybe the right: i am using this module wrong. The other one is: The dll misses something on windows...

[Twilight Suzuka]

I'll create a debug win32 version of the module tonight.
Use it and it will tell you each and every step of the set process.

Then we can locate and eliminate this problem ^^