[Cypher]

Originally Posted by beagle

This is probably a REALLY noob question, but is it possible to get the address for fall damage using a memory editor for say, Age of Conan? Sorry for asking here but theres nothing really about fall damage on the Conan forums. The reason I ask here is because i thought maybe it might be similar to this game, plus you are all very knowledgable on these kinds of things, so i thought i might as well ask .

First things first:
Wrong thread, wrong section, wrong forum, gtfo idiot.

Secondly:
StartedFalling and StoppedFalling are in the n3Vehicle vtable, run a string search for 'falling' and they're really easy to find. Goto the top of the StoppedFalling function and force the second JZ to a JMP to disable fall damage.

This is all from memory so it may be a tiny bit off but if you can't get it working from that info then you're probably too retarded to do it at all and should just stick to downloading 'point and click' hacks.

PS. Yes, it WAS a really noob question because you were obviously too retarded to realise it is totally inapropriate to ask about a different game in this thread.

PSS. Yes I am an *******, deal with it, if you want information from me and you're being a retard you can take a bit of flaming along with the info I supply.

[KuRIoS]

sry to say it but chazz is right.. consider ur infractions points his flame

[suicidity]

I can always seem to agree with Chazz for some reason?

[Xarg0]

Does the Return Adress need to be a relative one too?
If so I'm quite shure that's what's causing the crash...

[Shynd]

No, I don't believe so. Seriously, your CALL needs to be relative from the -end- of the CALL opcodes, not the beginning. I'm positive that's the problem. Load up OLLYDBG, breakpoint the fall address, inject your code, and single-step through it.

[beagle]

Thank you very much for the information Chaz. And yes, you are right, i posted in the wrong forum. No, i do not believe you are an *******, i broke the "rules" and i can live with that. I got the information i needed and i thank you for helping me.

On a side note though, calling some retarded because they are not as knowledgeable on this subject as yourself is in itself rather silly. Everyone has to start from somewhere, and since you know absolutley nothing about me, it is rather pointless to insult my intelligence. I tried to be as polite as i could, and i pointed out that i was indeed sorry for asking on this thread, making it quite ovbious that i knew it was the wrong place. This thread was exactly what i was looking for, although unfortunately it was for a different game, and for that i appologize. Please dont take me for a 13 year old "PLZ GIV ME H4X TY" kid. I am trying my best on the spare time that i have to learn how to do these things myself, so please dont criticise or berate me for it.

Thanks again though, i certainly appreciate the help .

[Xarg0]

I went back to using a call struct, like bwh does in it's sendmessagehook

#pragma pack(push)
#pragma pack(1)
typedef struct _CALLINSTRUCTION
{
	BYTE bOpcode;
	DWORD dwAddress;
	BYTE Nop;
} CALLINSTRUCTION, *PCALLINSTRUCTION;
#pragma pack(pop)

writing this struct to the memory works fine, it writes the call correctly to wow and the JE stays intact, I calculate the call offset like bubba did for his sendmessage detour,

PtrToUlong(NoFallDamage_Detour)-(DetourAddress+sizeof(origbyte))

origbyte is a bytearray that contains the original bytes.

BYTE origbyte[] = {0x8B ,0x4F ,0x7C ,0x89 ,0x4E, 0x3C};

My call code now looks ok in olly but I still crash with a memory error, this time it's a the memory could not be written error, my code tried to write at the Adress 0x0000000

[sweeper18]

Originally Posted by Xarg0

I went back to using a call struct, like bwh does in it's sendmessagehook

#pragma pack(push)
#pragma pack(1)
typedef struct _CALLINSTRUCTION
{
	BYTE bOpcode;
	DWORD dwAddress;
	BYTE Nop;
} CALLINSTRUCTION, *PCALLINSTRUCTION;
#pragma pack(pop)

writing this struct to the memory works fine, it writes the call correctly to wow and the JE stays intact, I calculate the call offset like bubba did for his sendmessage detour,

PtrToUlong(NoFallDamage_Detour)-(DetourAddress+sizeof(origbyte))

origbyte is a bytearray that contains the original bytes.

BYTE origbyte[] = {0x8B ,0x4F ,0x7C ,0x89 ,0x4E, 0x3C};

My call code now looks ok in olly but I still crash with a memory error, this time it's a the memory could not be written error, my code tried to write at the Adress 0x0000000

Then I guess you need to look for a bad pointer? That is what 0x0000000 sounds like to me. I haven't read the thread though so I wouldn't know lol

[suicidity]

It sounds like this is happening when your trying to actually call, perhaps this is an overflow like suggested before?

Sorry I can't be much of service; other than suggestions. I'll try finding my old CS Source stuff to see if it could be much of service to you.

[Shynd]

Let OLLY catch the exception and see where it originates from. That, or single-step through (or 'execute-til-ret' through) your code and see if any of the registers that are accessed right after your detour is called are changed to something they shouldn't be, causing them to screw up. It may be as simple as the stack getting out of sync with what the program thinks it should be, or something else that's easy to overlook but simple to solve.

Edit: wait, if you're detouring by using a CALL opcode instead of a JMP opcode, you don't need to push dwOrig onto the stack before RETNing; CALLs already do that. I bet you're getting a stack error because dwOrig is pushed onto the stack twice and taken off only once. May be wrong, but that's what it looks like to me.

[Xarg0]

Thanks, Shynd I'll try that, my asm knowlegde is very limited since I didn't find any good tutorials or references, most tutorials deal with some ASM IDE that uses a lot of macros to make the use easier so I couldn't find tutorials on real x86 asm.

[Cypher]

Okay, I downloaded the DLL, injected it, fired up a disassembler and these are the results:

Original Code

.text:00760D90                 mov     ecx, [edi+7Ch]
.text:00760D93                 mov     [esi+3Ch], ecx
.text:00760D96                 jz      short loc_760DB6

Your code

.text:00760D90                 call 0b2210b9
.text:00760D95                 cmp al,74
.text:00760D97                 push ds

What is at that call address:

.text:0b2210b9 jmp 0b222370
<Lots more jmps below this>

I have no idea what the hell you've done in your implementation of the hook to mangle shit that bad, but yeah, you ****ed up.

Its actually quite simple, just follow these steps:
An unconditional jump is 5 bytes. The code you're overwriting is 6. Write your unconditional jump and a NOP. Also, make sure you're writing the hook function to memory properly, caus that's messed up too. Then just jump back to the line 00760D96 (or, your base address + 6).

This is what your code should look like:

.text:00760D90                 jmp deadbeef
.text:00760D95                 nop
.text:00760D96                 jz      short loc_760DB6

Obviously DEADBEEF would be the location of the replacement code. To make things simple you can just write the code to a code cave if you don't know how to use a DLL properly.

[Xarg0]

That DLL was just ****ed up ^^

It's working now
[Only registered and activated users can see links. ]
Thanks to everyone here who posted usefull stuff espacially Shynd :-)
<3 you

[Cypher]

Originally Posted by Xarg0

That DLL was just ****ed up ^^

It's working now
[Only registered and activated users can see links. ]
Thanks to everyone here who posted usefull stuff espacially Shynd :-)
<3 you

I figured as much given that your target call address was full of retarded and nonsensical crap.

[lanman92]

This thread is old, but how did you make it undetectable? I get D/C'd as soon as I jump/fall after inserting the detour + codecave. I didn't think this address was scanned by warden.

Here's the code I'm using, please don't be angry at my C# asm... Lol.

 
byte[] newBytesFirst = new Byte[] {0xE9, 0x26, 0xFB, 0x0C, 0x00, 0x90};                       //My JMP to the codecave
byte[] newBytesNext = new Byte[] {0x8B, 0x4F, 0x7C, 0x83, 0xF8, 0x00, 0x90, 0x90, 0x7D, 0x03, 0x89, 0x4E, 0x3C, 0x68, 0xC6, 0xA4, 0x7B, 0x00, 0xC3};                                                                                                 //My codecave
uint unimportant, unimportant3, unimportant2;
int vpex = VirtualProtectEx(hWow, (IntPtr)0x7BA4B0, (UIntPtr)0xF, (uint)0x40, out unimportant);
vpex = VirtualProtectEx(hWow, (IntPtr)0x889FEB, (UIntPtr)0x13, (uint)0x40, out unimportant2);
vpex = VirtualProtectEx(hWow, (IntPtr)0x7BA4C0, (UIntPtr)0xFF, (uint)0x40, out unimportant3);
Memory.WriteMemory(hWow, (long)0x7BA4C0, newBytesFirst);
Memory.WriteMemory(hWow, (long)0x889FEB, newBytesNext);
vpex = VirtualProtectEx(hWow, (IntPtr)0x7BA4B0, (UIntPtr)0x40, unimportant, out unimportant);
vpex = VirtualProtectEx(hWow, (IntPtr)0x889FEB, (UIntPtr)0x40, unimportant2, out unimportant2);
vpex = VirtualProtectEx(hWow, (IntPtr)0x7BA4C0, (UIntPtr)0x40, unimportant3, out unimportant3);

Yes, I am aware that I should use VirtualAllocEx(). But this works on private servers, so I am just curious how you did it... I have set a mem access breakpoint at 7BA4C0 and it never get's paused except while executing.