How to use GMS V55 Window mode ?

[pozxnm123]

Do not use dxwnd related programs

Memory changes can be achieved?

 

[Eric]

Yes, a simple client edit will fix this. Unfortunately I don't have a v55 client IDB on me, nor a v55 client, so I can't get you the address directly myself.

However, assuming you know how to use OllyDbg, it's relatively easy to find:
- Open up OllyDbg and load your v55 localhost.exe.
- Make sure you're in the PE module (base 00400000) ; if not, move to it via the executable modules sub-window
- Within the module, open up the binary string search (shortcut CTRL + B)
- Copy to clipboard 66 C7 45 CC 03 40 (the AoB I use to locate CWvsApp::InitializeInput)
- Inside the binary search window, right-click in the ASCII text section and paste (shortcut Shift + INS)

It should look like this:

Click OK to search and move to the first result (if found -- which it will be), and it'll look something like this:

Now, highlighted in red are the three important instructions. The first one is the AoB you searched for to get here. It should be moving 0x4003 into a register. After that comes a mov word ptr[x], 3 instruction which helps us identify the important instruction right below it (the mov dword ptr). Here, you'll see that it's moving eax into the register, but if v55 is anything like v50 then you should see it moving a 0x10 into the register. If you see it moving a 0x10, simply change the 0x10 to a 0 and save -- voila, window mode! However, if it is moving eax like v62 is doing, then up at the top where you see mov eax, 0 will be something like mov eax, dword ptr [address]. Simply change mov eax, dword ptr [address] to mov eax, 0 and save.

Hope this helps!

 

[br1337]

Yes, a simple client edit will fix this. Unfortunately I don't have a v55 client IDB on me, nor a v55 client, so I can't get you the address directly myself.

However, assuming you know how to use OllyDbg, it's relatively easy to find:
- Open up OllyDbg and load your v55 localhost.exe.
- Make sure you're in the PE module (base 00400000) ; if not, move to it via the executable modules sub-window
- Within the module, open up the binary string search (shortcut CTRL + B)
- Copy to clipboard 66 C7 45 CC 03 40 (the AoB I use to locate CWvsApp::InitializeInput)
- Inside the binary search window, right-click in the ASCII text section and paste (shortcut Shift + INS)

It should look like this:

Click OK to search and move to the first result (if found -- which it will be), and it'll look something like this:

Now, highlighted in red are the three important instructions. The first one is the AoB you searched for to get here. It should be moving 0x4003 into a register. After that comes a mov word ptr[x], 3 instruction which helps us identify the important instruction right below it (the mov dword ptr). Here, you'll see that it's moving eax into the register, but if v55 is anything like v50 then you should see it moving a 0x10 into the register. If you see it moving a 0x10, simply change the 0x10 to a 0 and save -- voila, window mode! However, if it is moving eax like v62 is doing, then up at the top where you see mov eax, 0 will be something like mov eax, dword ptr [address]. Simply change mov eax, dword ptr [address] to mov eax, 0 and save.

Hope this helps!

Tested with bms v8 and it works, thanks for sharing Eric.

 

[pozxnm123]

Thanks, GMS V55 is successful

I try to use a different version

But I can't find it with AOB 66 C7 45 CC 03 40
 
Only found 66 C7 45 CC 03 00

Attached figure

 

[br1337]

Yes, a simple client edit will fix this. Unfortunately I don't have a v55 client IDB on me, nor a v55 client, so I can't get you the address directly myself.

However, assuming you know how to use OllyDbg, it's relatively easy to find:
- Open up OllyDbg and load your v55 localhost.exe.
- Make sure you're in the PE module (base 00400000) ; if not, move to it via the executable modules sub-window
- Within the module, open up the binary string search (shortcut CTRL + B)
- Copy to clipboard 66 C7 45 CC 03 40 (the AoB I use to locate CWvsApp::InitializeInput)
- Inside the binary search window, right-click in the ASCII text section and paste (shortcut Shift + INS)

It should look like this:

Click OK to search and move to the first result (if found -- which it will be), and it'll look something like this:

Now, highlighted in red are the three important instructions. The first one is the AoB you searched for to get here. It should be moving 0x4003 into a register. After that comes a mov word ptr[x], 3 instruction which helps us identify the important instruction right below it (the mov dword ptr). Here, you'll see that it's moving eax into the register, but if v55 is anything like v50 then you should see it moving a 0x10 into the register. If you see it moving a 0x10, simply change the 0x10 to a 0 and save -- voila, window mode! However, if it is moving eax like v62 is doing, then up at the top where you see mov eax, 0 will be something like mov eax, dword ptr [address]. Simply change mov eax, dword ptr [address] to mov eax, 0 and save.

Hope this helps!

Eric, what about jump down for older versions?

 

[Eric]

Thanks, GMS V55 is successful

I try to use a different version

But I can't find it with AOB 66 C7 45 CC 03 40
 
Only found 66 C7 45 CC 03 00

Attached figure

Looks like it's moving it the alternate way I had mentioned. Refer back to my notes where if it isn't doing directly moving 0x10, then it's going to be doing "mov [address], eax" instruction. Based on the above assembly, where ebp-0x1C looks unchaged, it's being initialized above the highlighted address:

The highlighted instruction is what's moving the value. From there, scroll up a bit and find a "mov eax, [xxx]" instruction and change it to "mov eax, 0". You should be fine from there.

Eric, what about jump down for older versions?

What about it? It's definitely possible to add, but I wouldn't bother implementing it unless you're using hooks. You'd hook UseFuncKeyMapped and check if the avatar's OneTimeAction is "Prone" or whatever upon keydown for their jump key. From there you'd inline asm code your jumpdown functionality. The process isn't too too horrible, you would copy the checks from jump (seduce/weakness buffstats from preventing it), and then just check for a foothold below the user and assign it to their vector control's foothold pointer. Since you're moving still, and your foothold has been assigned to be the platform below you (if valid), then you'll begin falling down as you should be. The only thing that might be weird about it is how Nexon handled item renders in the background (which is why they have falldown checks in their movement packets). Not something I plan on doing myself, but hopefully this gives you the general idea. You might understand how it works a whole lot better after you look at CUserLocal::FallDown and how it gets called.

 

[pozxnm123]

Looks like it's moving it the alternate way I had mentioned. Refer back to my notes where if it isn't doing directly moving 0x10, then it's going to be doing "mov [address], eax" instruction. Based on the above assembly, where ebp-0x1C looks unchaged, it's being initialized above the highlighted address:

The highlighted instruction is what's moving the value. From there, scroll up a bit and find a "mov eax, [xxx]" instruction and change it to "mov eax, 0". You should be fine from there.



What about it? It's definitely possible to add, but I wouldn't bother implementing it unless you're using hooks. You'd hook UseFuncKeyMapped and check if the avatar's OneTimeAction is "Prone" or whatever upon keydown for their jump key. From there you'd inline asm code your jumpdown functionality. The process isn't too too horrible, you would copy the checks from jump (seduce/weakness buffstats from preventing it), and then just check for a foothold below the user and assign it to their vector control's foothold pointer. Since you're moving still, and your foothold has been assigned to be the platform below you (if valid), then you'll begin falling down as you should be. The only thing that might be weird about it is how Nexon handled item renders in the background (which is why they have falldown checks in their movement packets). Not something I plan on doing myself, but hopefully this gives you the general idea. You might understand how it works a whole lot better after you look at CUserLocal::FallDown and how it gets called.

The address I found above

changed to

Seems invalid
I don't know if my modification is correct?

I am attaching IDB
For your reference

You must be registered to see links

 

[Eric]

The address I found above

changed to

Seems invalid
I don't know if my modification is correct?

I am attaching IDB
For your reference

You must be registered to see links

According to your IDB:

00A13F19                 mov     dword ptr [ebp-24h], 10h

My AoB doesn't work for this one so I had to use some IDA xrefs through PCOM in order to trace it back to an IWzGr2D call. Anyways, changing the 0x10 to 0 on the above address will enable window mode for that client.

 

[pozxnm123]

Test has work, thanks Eric

 

[Helskrim]

I'd like to use this chance to ask the opposite question.
How would I go about hex editing executable to force it to launch in fullscreen always as I've seen other servers have this Fullscreen client option and can this process be done in HxD? Thank you for your help.

Edit:Forgot to mention I'd like to modify v83 client.

Edit2: Nvm, I got it working for v83, used 009F7A9B offset provided by Eric in other thread and found Mov Eax 0 and simply did it the reversed way by taking a look into clean localhost which is fullscreen already and copying whatever was written there and replacing with Mov Eax 0.

You can also do the easier way of simply editing hex of this offset and from what I see the hex values for this address is same for every v83 client.

B8 00 00 00 is Windowed
A1 C8 1A BF is Fullscreen

I assume the same goes for other versions just different offset to search for and different hex values.

 

[EdoTense]

hey. Have adress for v 75 ?

 

[Helskrim]

hey. Have adress for v 75 ?

Sorry for late reply, this is what I have. I haven't tested on v75 though.

v62: 008276B2
v75: 008FC396
v83: 009F7A9B

 

[0911]

Window mode, thank you Eric