[Release] Documentation on fixing W8/w10 compatibility for v9x~12x

[moshe23]

Hopefully I can figure this out for 117.2. Still a damn noob with these sort of things even after all these years..

OMG so out the client

 

[Halcyon]

You can, but v117.2 will be a bit harder as you'll not be editing a localhost directly, but instead the process memory like the rest of your LEN client hacks. ;P

Yeah, screw this. I can't figure it out because I can't run the MapleStory.exe by itself without my computer going apeshit about it. I was able to do client hacks on v83 and stuff because it was a localhost. But, figuring this out is too much for me due to the whole LEN client hack type stuff so I gave up. lol

 

[satoshinakamoto]

Even though it does not work all the time, but dramatically reduces the rate of the client not loading at all. I'm still looking at other ways of fixing this instead.. meantime you may use it.


Here's the full patched instruction.

int __thiscall sub_594EF0(void *this, int a2, int a3)
{
  char *v3; // esi@1
  int v4; // ebx@1
  signed int v5; // edi@1
  int *v6; // ebp@1
  int v7; // eax@2
  int v8; // eax@4
  unsigned int v9; // eax@6
  int v10; // ecx@7
  int v11; // edx@7
  int v12; // ST0C_4@8
  LONG v13; // eax@12
  int v14; // edi@14
  int v15; // eax@16
  VARIANTARG pvarg; // [sp+28h] [bp-1Ch]@12
  int v18; // [sp+40h] [bp-4h]@8

  v3 = (char *)this;
  v4 = a3;
  *(_DWORD *)this = a2;
  v5 = 0;
  v6 = (int *)((char *)this + 20);
  while ( 1 )
  {
    v7 = v0(0, 0, 0, 0);
    *v6 = v7;
    *(_DWORD *)(v4 + 4 * v5) = v7;
    if ( !v7 )
      break;
    ++v5;
    ++v6;
    if ( v5 >= 3 )
    {
      v4 = 0;
      v8 = v0(0);
      if ( DirectInput8Create(v8, 2048, dword_D57DDC, v3 + 4, 0) < 0 )
        Sleep(0x7D0u);
      break;
    }
  }
  sub_B0BE10(v3 + 36, v4, 1024);
  sub_B0BE10(v3 + 1060, v4, 1024);
  v9 = 0;
  do
  {
    *(_DWORD *)&v3[4 * (unsigned __int8)byte_DFA208[v9] + 36] = (unsigned __int8)byte_DFA209[v9];
    v10 = (unsigned __int8)byte_DFA208[v9];
    v11 = (unsigned __int8)byte_DFA209[v9];
    v9 += 2;
    *(_DWORD *)&v3[4 * v11 + 1060] = v10;
  }
  while ( v9 < 0xCC );
  *((_DWORD *)v3 + 8) = v4;
  sub_783620();
  v12 = *(_DWORD *)sub_402D70(&a2, 2570);
  sub_42A050(v12, v3 + 2500, v4);
  v18 = -1;
  if ( a2 != v4 )
    sub_4027A0((volatile LONG *)(a2 - 12));
  if ( !v4 )
    sub_B0B880(-2147467261);
  v13 = *(_DWORD *)sub_43ACD0(&a3);
  v18 = 1;
  pvarg.vt = 13;
  pvarg.lVal = v13;
  if ( v13 != v4 )
    (*(void (__stdcall **)(LONG))(*(_DWORD *)v13 + 4))(v13);
  v14 = *((_DWORD *)v3 + 625);
  LOBYTE(v18) = 2;
  if ( v14 == v4 )
    sub_B0B880(-2147467261);
  v15 = (*(int (__stdcall **)(int, _DWORD, ULONG, LONG, __int32))(*(_DWORD *)v14 + 100))(
          v14,
          *(_DWORD *)&pvarg.vt,
          pvarg.decVal.Hi32,
          pvarg.lVal,
          pvarg.cyVal.Hi);
  if ( v15 < v4 )
    _com_issue_errorex(v15, v14, dword_CA8DB0);
  LOBYTE(v18) = 1;
  if ( pvarg.vt == 8 )
  {
    pvarg.vt = 0;
    if ( pvarg.lVal != v4 )
      v0(pvarg.lVal - 4);
  }
  else
  {
    VariantClear(&pvarg);
  }
  v18 = -1;
  if ( a3 != v4 )
    (*(void (__stdcall **)(int))(*(_DWORD *)a3 + 8))(a3);
  sub_593980(*((_DWORD *)v3 + 590), *((_DWORD *)v3 + 591));
  sub_B0BE10(v3 + 2360, v4, 44);
  *((_DWORD *)v3 + 590) = sub_A2BD70() / 2;
  *((_DWORD *)v3 + 591) = sub_A2BD80() / 2;
  sub_594C70(v3);
  return sub_594140(v4);
}

You must be registered to see links

 

[WallyNL]

any could fix this on a v83 client and release it? most of us dont know how to PE =[ well atleast i dont.

 

[Rarukia]

Thanks for the awesome info @satoshinakamoto!

A couple of friends and I got this working for v62 and v83. The fix mentioned in this thread will not work for these specific versions.

v62 address: 5262F0
v83 address: 599F50

The fix was a LOT simpler than we thought it'd be:

JGE checks for the DirectInput8Create return value and raises an exception if it doesn't pass, so changing it to JMP will skip the check entirely.

So far we haven't gotten a single incorrect parameter error on 3-4 computers with windows 8/10 after a ton of testing, so we can assume that it works 100%.


S/O to ShinobiHao & Thor

 

[satoshinakamoto]

Just jumping over that won't help, the client would still crash nevertheless.
You need to call kernel32.Sleep with some delay, there might be a good chance that it might work.

 

[Rarukia]

Just jumping over that won't help, the client would still crash nevertheless.
You need to call kernel32.Sleep with some delay, there might be a good chance that it might work.

It might not work in v9x~12x (haven't tried), but it definitely will in v62 and v83. We've tested many times on multiple computers without getting a single incorrect parameter error or crash.

Feel free to try it on said versions.

 

[Eric]

It might not work in v9x~12x (haven't tried), but it definitely will in v62 and v83. We've tested many times on multiple computers without getting a single incorrect parameter error or crash.

Feel free to try it on said versions.

No.. maybe you're missing the big picture. You're jumping the call entirely, regardless if it succeeded or not to initialize the library. Why do you think we're calling sleep for? The reason everything is failing is due to the fact that the initialization gets delayed and fails to load immediately, so when we try to access it, it is going throw an exception due to failure. So how are we "fixing" this issue for most of the people who receive it? We delay it by implementing a code-cave section, jump to it and not the original call you've modified, call a kernel32 sleep to give it a 2 second load delay, then jump back to the address location and continue execution. Your fix will not work 100% as intended, but it will remove the exception that it's throwing. Another thing to note is if you just ignore the exception and it failed to initialize, that would end up not working out so well.

Also, using your fix on v83 and v90, both did not always work when I had tests done, but with the patch/fix provided in the original post, all of the times it would fail went away and nobody has had an issue. v93 and above load it differently and this is why you see he has to NOP twice as much as we do in older clients (another reason why the AoB will not work for all versions < 93, using 90 as an example). However, don't take it as your fix is wrong, it's just that it's not as reliable as the OP's.

 

[br1337]

Here's what worked for me on a v83 client:

Hook the call to DInput8Create, make it a jmp to this assembly:

sub esp, 20
mov eax, 0
jmp address after the hooked call.

 

[Kimberly]

Just jumping over that won't help, the client would still crash nevertheless.
You need to call kernel32.Sleep with some delay, there might be a good chance that it might work.

I am not too sure about it. For v62 I had 2 people trying his fix now, and myself could never trigger parameter is incorrect anymore, same for one of my friends.

I even did like toggle between 2 clients where the first one triggered it immediately and then his fix one didn't.

Maybe its luck or not, I don't know.

v62 already had the Windows compatibility way but I much prefer parameter being fixed and w8+ users no longer have to use Windows 98/me mode (even though my installer does this automatically).
---
Just did another round of tests by booting each client 10 times:
Unpatched: Run 4 out of 10 times sucessfully (parameter is incorrect obviously)
Patched: Run 10 out of 10 times successfully (worked all time)

Maybe it doesn't work all time for v83 or maybe me (and his friends) are incredible lucky. But if that's the case this should massively remove the chance for parameter then...

 

[BLa7kCaT]

edit: gonna do more testing (v83 user)

 

[Kimberly]

Decided to do a follow up on my post on the previous page for v83. Just for science since I don't play nor run v83. Since this is first time, I will test 20 times.

Unpatched: Failed: 13 Success: 7
Patched: Crashed 2 times in row so stopped testing. It seems I indeed crash on v83. No parameter but a simple 'MapleStory has stopped responding'

Rarukia Are you a v62 user or v83? Maybe the patch for v83 is incorrect? I don't know... However, if they are both the same than indeed we are either lucky for v62 or it doesn't crash for v62, same how 98/me mode fixes it 100% for v62 and not for v83...

EDIT: Yeah I am really trying my hardest to get the same crash in v62 but it isn't. Seems this is only working 100% right now for v62... v83 crashes.

 

[Rarukia]

No.. maybe you're missing the big picture. You're jumping the call entirely, regardless if it succeeded or not to initialize the library. Why do you think we're calling sleep for? The reason everything is failing is due to the fact that the initialization gets delayed and fails to load immediately, so when we try to access it, it is going throw an exception due to failure. So how are we "fixing" this issue for most of the people who receive it? We delay it by implementing a code-cave section, jump to it and not the original call you've modified, call a kernel32 sleep to give it a 2 second load delay, then jump back to the address location and continue execution. Your fix will not work 100% as intended, but it will remove the exception that it's throwing. Another thing to note is if you just ignore the exception and it failed to initialize, that would end up not working out so well.

I completely agree, but it still significantly decreases the amount of incorrect parameter errors you receive with no negative effects (as far as we know), and all of the people who we've had try it didn't get a single one.

Also, using your fix on v83 and v90, both did not always work when I had tests done, but with the patch/fix provided in the original post, all of the times it would fail went away and nobody has had an issue. v93 and above load it differently and this is why you see he has to NOP twice as much as we do in older clients (another reason why the AoB will not work for all versions < 93, using 90 as an example). However, don't take it as your fix is wrong, it's just that it's not as reliable as the OP's.

I noticed that I said in an earlier post that the OP's fix will not work in v62/v83, which is a mistake on my part - we just couldn't get it to work in those versions. If your fix for v83 is more reliable, could you post it here please?

Decided to do a follow up on my post on the previous page for v83. Just for science since I don't play nor run v83. Since this is first time, I will test 20 times.

Unpatched: Failed: 13 Success: 7
Patched: Crashed 2 times in row so stopped testing. It seems I indeed crash on v83. No parameter but a simple 'MapleStory has stopped responding'

@Rarukia Are you a v62 user or v83? Maybe the patch for v83 is incorrect? I don't know... However, if they are both the same than indeed we are either lucky for v62 or it doesn't crash for v62, same how 98/me mode fixes it 100% for v62 and not for v83...

I play both. Did you get that 'MapleStory has stopped responding' error as soon as you ran the client or a few seconds later? The error/crash you received could be what you're getting instead of the 'Incorrect Parameter' error after it tries to skip the exception. Like @Eric mentioned, this "fix" isn't as perfect as I had hoped it would be, or perhaps at least not in v83. Nevertheless, I still consider this to be an improvement in comparison to the amount of parameter errors you'd usually get. Edit: At least for me and the people who haven't had any issues with it the past few hundred tries. :/

 

[Kimberly]

I play both. Did you get that 'MapleStory has stopped responding' error as soon as you ran the client or a few seconds later? The error/crash you received could be what you're getting instead of the 'Incorrect Parameter' error after it tries to skip the exception. Like @Eric mentioned, this "fix" isn't as perfect as I had hoped it would be, or perhaps at least not in v83. Nevertheless, I still consider this to be an improvement in comparison to the amount of parameter errors you'd usually get.

The client like boots up and about 10 seconds later I get the crash. For parameter I get it like 1-2 seconds after client bootup. For v62 it works all time and it never crashes (so far).

For v83 it doesn't crash all time, but it does as much paremeter is incorrect would appear, but instead of giving me that error it waits like 10 seconds and crashes. I guess v83 can't handle the skip while v62 can?

 

[br1337]

The client like boots up and about 10 seconds later I get the crash. For parameter I get it like 1-2 seconds after client bootup. For v62 it works all time and it never crashes (so far).

For v83 it doesn't crash all time, but it does as much paremeter is incorrect would appear, but instead of giving me that error it waits like 10 seconds and crashes. I guess v83 can't handle the skip while v62 can?

In v83 you have to skip the call to Directinput8Create. I've being using on windows 8 without any error message.

You can do this by hooking the function or skipping it and returning zero in eax register.

 

[Kimberly]

In v83 you have to skip the call to Directinput8Create. I've being using on windows 8 without any error message.

You can do this by hooking the function or skipping it and returning zero in eax register.

I know there's alternative ways provided. I do not need a v83 fix since I don't run v83. I just tested the fix Rarukia provided.

 

[HTML]

DOes it work for 149? It seems not.

 

[Eric]

DOes it work for 149? It seems not.

Nexon had implemented client support for newer OS's after 144 or so, so v149 shouldn't need this fix afaik.

 

[br1337]

I had to some workaround to make it work on v90(a ret in a specific function which was crashing the client).

 

[Karthus]

I know there's alternative ways provided. I do not need a v83 fix since I don't run v83. I just tested the fix @Rarukia provided.

I'm using a c# app (launcher) to write a registry key for that.

string key = Path.GetFullPath("localhost.exe");
RegistryKey Keys = Registry.CurrentUser.CreateSubKey(@"SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers");
Keys.SetValue(key, "RUNASADMIN WIN7RTM");
Keys.Close();