[Release] Modified AF v0.5 [Broken]

[[P2933]Step29]

NOTE: THIS DOES NOT FIX PAKE, MORE DETAILS BELOW.

Hello everyone. Let's just get straght into the details

Sometime in March, Patch #236 of Luoqi contained a new network update that killed ReadFromNetworkBuffer.
This also made the Morrighan Proxy not work in Luoqi for a while.
Today, we got the same update in the new NA Client.


I went ahead and updated the pattern, when it was updated another pattern broke down, All patterns eventually got updated.
The new problem now lies within DINPUT8. After logging in, the client will just crash.
I don't know why it crashes (I've been told that we got a new packet structure/protocol) , I just know that it crashes inside DINPUT8.
Last Trigger would be around DINPUT8.Recv+40, You can breakpoint that and figure it out yourself if you want





So this contains the Fixed version of AllisaFix with all patterns up to date.
I'm givng it out since I have no use for it anymore, and that I no longer have the time to waste hours and hours upon experimenting why it crashes.
I'm leaving it up to you people now (Presumably the 2ch.net People for the DINPUT8 error or YYDZH Moderators to figure out the problem and reverse engineer it themselves if they wanted too.)


I don't believe pake is dead.
after all, pake will never get patched, right?

Download:

Well, I'm off.
See you in another realm I guess?

 Spoiler

[tliu0c]

Firstly You should not release the files that I specifically only gave to you. It was not intended for the public.

Secondly you released a non-working AF binary...what the? It is totally useless.

Thirdly anyone who doesn't have working pake and can fix it all along won't be able to fix it now. Even if they have AF source.

[[P2933]Step29]

Originally Posted by tliu0c

Firstly You should not release the files that I specifically only gave to you. It was not intended for the public.

Oh Shoot, I do apologize for that.
It's the Dinput8 correct? If you want I can just remove that and replace it with the other dinput8, if I can find it
Please let me know anytime.

Secondly you released a non-working AF binary...what the? It is totally useless.

That is incorrect. This version of AF is fixed on the newest NA Client (and the Luoqi CH Client). All the Hooks and patterns are corrected for this version. As I've previously said the new problem lies around dinput8. It will not work as soon as you log in regardless of all the hooks being corrected in AF. When I attached a debugger on this, the main file of AF has no problems, however Dinput8 itself will crash due to an incorrect structure/format and I would assume Dinput8 has to be recompiled again with the correct structure/format.


As far as I know, no source code of dinput8 exist anywhere. It's created by 1 anon of 2ch and it's most likely to believe that he doesn't play mabinogi anymore.

Thirdly anyone who doesn't have working pake and can fix it all along won't be able to fix it now. Even if they have AF source.

I would assume it's because of the new protocol packet structure?
I'm not really too sure on this, due to the lack of time I have experimenting it. But I probably wouldn't even understand it as well due to the fact that the RFNB function is encrypted

Edit: dinput8 is now back to it's original state
Only thing that I modifed is DINPUT8.SEND+BA in order to correct an improper jmp.
( jmp DINPUT8.RECV+140 -> jmp DINPUT8.RECV+143)

[jackpot100]

does this hack work if yes sweet i been looking forever to for some one to do it + link is broken

+ can you tell me all i need to hack it like the programs and all that
to bypass and all that i want to learn how to hack mabi and to update hacks

[Seren30]

Originally Posted by jackpot100

does this hack work if yes sweet i been looking forever to for some one to do it + link is broken

+ can you tell me all i need to hack it like the programs and all that
to bypass and all that i want to learn how to hack mabi and to update hacks

Wow, you really don't know how to read, do you?

[jackpot100]

Originally Posted by Seren30

Wow, you really don't know how to read, do you?

dude don't be a jack *** i no you need Visual Studio but i don't no how to get source or how to make it in to like a injector or some **** i'm new to this kind of ****
and o i just read it all i see now my bad

[KouLeifou]

Originally Posted by [P2933]Step29

I would assume it's because of the new protocol packet structure?
I'm not really too sure on this, due to the lack of time I have experimenting it. But I probably wouldn't even understand it as well due to the fact that the RFNB function is encrypted

There's no new protocol. Everything works exactly as it did before.

Pretty sure what he's talking about with not being able to fix mabipake's dinput8 is that it expects a fixed number of bytes for it's jmp hook, which is no longer the right size.

Why haven't you guys made your own version of Mabipake yet? It's so much easier to maintain than having to pander to out-dated code.

[[P2933]Step29]

Originally Posted by KouLeifou

Pretty sure what he's talking about with not being able to fix mabipake's dinput8 is that it expects a fixed number of bytes for it's jmp hook, which is no longer the right size.

Checking around Dinput8 and AF's copying bytes coding, you actually did gave me an idea.

DINPUT8.Send+86 and DINPUT8.Send+77F has been fixed with the correct offset of DINPUT8.RECV+140 -> 143 and I've reuploaded it again . However I am still crashing, I've checked all the JMPS in both Send and Recv functions of the DINPUT8 and other then AF copying the bytes of the RTNB function incorrectly due to the lack of bytes required to correctly allocate dinput8, every other function seems to be copying and jmping the bytes to the correct positions

 Spoiler

(Recv+140 has 6 Bytes to allocate before it can create a new JMP to RTNB, the new RTNB function looks like this:

[55 PUSH EBP //1 Bytes
8B EC MOV EBP,ESP //3 Bytes
81 EC 90] 00 00 00 SUB ESP,90 //9 Bytes

We cannot allocate enough bytes for SUB ESP,90 to fit into DINPUT8.RECV+140, and as for some reason, I cannot tell AllisaFix to write down only 3 bytes and make it JMP back to RTNB correctly, in order to combat this I did the following.

[CC INT3 //1 Bytes
CC INT3 //2 Bytes
CC INT3 //3 Bytes
55 PUSH EBP //4 Bytes
8B EC] MOV EBP,ESP //6 Bytes

But the problem is we cannot have the functions jump to the INT3s, so we have to rewrite DINPUT8 to jump and call at DINPUT8.RECV+143 instead of DINPUT8.RECV+140.



)

But even with that being corrected, I am still crashing, debugging further to my tracer it appears that I crash

@ DINPUT8.Recv+40 (Start)
-DINPUT8+10960
-DINPUT8+2EA2
-ntdll.RtlAllocateHeap (from DINPUT8+2F19)
-ntdll.RtlpNtSetValueKey+2BFE
- ntdll.ResetRTLTranslations+E8
-ntdll.NtQueryInformationProcess (Crash Here)

At this point, I just don't know what to do about this whole thing, I'm running out of ideas why it would be crashing around this area.

Why haven't you guys made your own version of Mabipake yet? It's so much easier to maintain than having to pander to out-dated code.

Because I'm too stupid to figure it out via C++/C# for me to code anything for myself . It took me 2 months to fix pake by reading thur AllisaFix's Uncommented codes and about >500 failed crash testings when the Client got upgraded to vc2010+

[KouLeifou]

Originally Posted by [P2933]Step29

 Spoiler

(Recv+140 has 6 Bytes to allocate before it can create a new JMP to RTNB, the new RTNB function looks like this:

[55 PUSH EBP //1 Bytes
8B EC MOV EBP,ESP //3 Bytes
81 EC 90] 00 00 00 SUB ESP,90 //9 Bytes

We cannot allocate enough bytes for SUB ESP,90 to fit into DINPUT8.RECV+140, and as for some reason, I cannot tell AllisaFix to write down only 3 bytes and make it JMP back to RTNB correctly, in order to combat this I did the following.

[CC INT3 //1 Bytes
CC INT3 //2 Bytes
CC INT3 //3 Bytes
55 PUSH EBP //4 Bytes
8B EC] MOV EBP,ESP //6 Bytes

But the problem is we cannot have the functions jump to the INT3s, so we have to rewrite DINPUT8 to jump and call at DINPUT8.RECV+143 instead of DINPUT8.RECV+140.



)

You don't want to overwrite the interrupts, that push ebp is the correct spot to write the hook. The problem is that mabipake expects to overwrite, IIRC, 7 bytes and you now have something which is 9.

When your bucket is too small to catch the rain, you don't move it out from under the hole, you get a bigger bucket.

[hettp1123]

so.. Have not still working FIX for now ?

[Seren30]

Originally Posted by hettp1123

so.. Have not still working FIX for now ?

Someone posted it a few days ago, didn't you see?

[mark2165]

what is the password ? thanks!