Addresses 9.1

[maozao]

Well, I just saw that those people that worked was using an modified client(MC), so that's why they got the base address of windows XP (0x400000)

I will do more tests soon, I'm working right now.

[Blaster_89]

Just to add more infor to this post: http://tpforums.org/forum/thread-8812-post-77801.html#pid77801

Again it is working in some computers(using Windows 7) and other it is not, I'm doing more tests to find what's going on, but if someone have an idea just tell me xD

That's totally crazy! =O

Maybe some have EMET installed? I never had seen or heard of EMET till I googled ASLR. "A registry setting is available to forcibly enable or disable ASLR for all executables and libraries, found at "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages".[8] ASLR can be disabled in Windows 7, by using the Enhanced Mitigation Experience Toolkit provided by Microsoft, (the MoveImages registry setting has no effect in Windows 7)." - http://en.wikipedia.org/wiki/Address_space_layout_randomization I got windows XP 64bit 32bit and windows 7 64bit if you want me to test for you?

Here is a link to EMET by MS http://support.microsoft.com/kb/2458544

I certainly don't have EMET installed and I've already beaten ASLR. I substract the baseaddress from all addresses, then add it in SetAddresses(). Note that my SetAddresses() takes a string fileversion and int32 baseaddress, so the end result is like this:
Map.Pointer = baseAddress + 0x471FB8;

[klusbert]

Working to send packet by memory using stepler method now, when using blaster_89 method.
But as Darkstar said they have added some kind of memory protection I can send the packet and then the client get bugged I cant walk etc.

Edit I tried to send a packet again and then this came up nice error

[muttley]

Hmm, I'll check how internall calls are working in few hours. I'll post results in this post.

[DarkstaR]

Working to send packet by memory using stepler method now, when using blaster_89 method.
But as Darkstar said they have added some kind of memory protection I can send the packet and then the client get bugged I cant walk etc.

Edit I tried to send a packet again and then this came up nice error

Using a parser hook I'm able to send packets to client such as text messages and channel open packets.
My outgoing packet codecave also seems to work fine.

Problems I'm having now are with TriggerEvent which now takes its first arg on ESI, doesn't clean the stack (like a __cdecl), and likes to debug when passed sufficient parameters (I know the parameters are sufficient because when I call it from Olly, it doesnt debug and shows what I want it too).

Also, calling delete [] on any char* allocated inside my program causes a debug similar to the TriggerEvent one, which is also seems to b e exactly the same as the error I got when changing access rights on the FPSNop or at any other hook.
This leads me to believe many problems are caused by the access rights of memory, there must be some checking in the client for it. (This is also supported by the fact that Olly prevent access right debugs when attached, as it is doing here)

[Aggressive Prefector]

Also noted in many articles I read that 64bit OS and the more free ram you have will result in better randomization in the ASLR then in a computer with less ram and less memory locations like 32bit. EMET is another program by MS that will try and force and stop any intrusions of programs with the ASLR tag attached. I wounder if the base value you are looking for is being affected by EMET or size of the ram or amount of memory locations. Like making it randomize better and using multiple base values instead of one?

ASLR seems very flawed to me because the program needs to know where the information is stored in the memory so all you have to do is look for what the program uses as a guide to finding it's own information in the ram that has been randomized. It is completely redundant and pointless. It is a waste of CPU time and ram. It has little to no security value at all. Personally I would disable it to save cpu cycles and ram.

[muttley]

Personally I would disable it to save cpu cycles and ram.

Yeah, the Tibia's very advanced 3D graphics requires the best optimization of the code.
CipSoft won't disable it, why?
They prevented us from updating the bots for some time and that's what they want to do.

[klusbert]

anyone knows the new mcbyte, it was 0xEB before.

[muttley]

I'm not sure, but it seems unchanged, from BlackD MC source
[code=vb];TIBIA 9.1
adrMulticlient=&H50F23F
adrASRL=&H15E[/code]
BlackD first disables the ASLR in exe and then patches the client on runtime.
So with dynamic base it may be base + 0x10F23F (not sure)

[Svenskpopis]

RedSquare = &H81CE58

didn't find this anywhere so i found it myself, not so sure but should be accurate