Working on PW 1.8.0 - 1.8.8 (source/emulator)

[afriendlyguy]

just wanted to show my progress so far, I was able to login on the Bard using an 1.8.0 PW client.


There is still much work to do left, but I think it's a great advance already and I'd like to share it here in case of any questions I am free to help ONLY on this thread. =)

updates on 188:

 

[HyperSin]

Did you have to use a modified 1.8.0 client or did the original pwi client work for you? Would be fantastic if that was the case

 

[afriendlyguy]

Did you have to use a modified 1.8.0 client or did the original pwi client work for you? Would be fantastic if that was the case

I downloaded the clean 1.8.0 client from PWBR, but it could be PWI too, then I modified it on IDA to load a .dll file (PW_API64.dll) as a hook. (this already existed on some previous versions, (I even think that probably someone posted a PWI API for an old client here on this forum already)

so on this .dll file I am basically doing what already existed on the old ones, finding addresses for patching and fixing things on the 1.8.0 version.
Many things have changed on the server side too (protocols and structures, but using this dll hook, it's possible to see what the cliend sends and what it gets from server, so it becomes a bit easier to understand the process).

 

[Ahmed Karawia]

Did you have to use a modified 1.8.0 client or did the original pwi client work for you? Would be fantastic if that was the case

You made server or not yet?

 

[afriendlyguy]

You made server or not yet?

I don't know if you asked me or HyperSin about that, but I am working on upgrading my server based on the 1.7.4 source that was released some months ago here.

I already had a lot of progress on that because I needed to update from 174 to 180 (skipping 176 and 178).

There is still much of work to do, but it would be great if someone could share or have any ideas on the new structures for the gshop/tasks.data for this version.

 

[HyperSin]

我来自中国，我也从事该领域的开发和研究。我从事的是正向开发，没有使用过任何 API，但我对这个 API 非常感兴趣。我不知道它的工作原理。我尝试检查了 1.7.4 版的源代码和 API。

I am from China, and I am also engaged in development and research in this field. I am engaged in forward development and have not used any API, but I am very interested in this API. I don't know how it works. I tried to check the source code and API of version 1.7.4.

Translated

 

[afriendlyguy]

我来自中国，我也从事该领域的开发和研究。我从事的是正向开发，没有使用过任何 API，但我对这个 API 非常感兴趣。我不知道它的工作原理。我尝试检查了 1.7.4 版的源代码和 API。

I am from China, and I am also engaged in development and research in this field. I am engaged in forward development and have not used any API, but I am very interested in this API. I don't know how it works. I tried to check the source code and API of version 1.7.4.

Translated

thanks for translating
andelie
You can download the PW API 174 source from this link ()
and then you will need to replace the old addresses from the 174 EC.exe with the 180 EC.exe's new addresses. (for that you will need to use IDA or Ghidra)

just replace those addresses for the new ones on the main.cpp and also on the config.h
also, you will probably need to update the informer.cpp class with all new addresses and offsets used by new .exe.

With the API, you will be able to log the packets which are sent and received, then everything becomes easier to implement, but there is still much work to do on the server side.

And while on the server side:
1. Need to update rpcalls.xml (gnet protocols)
2. Need to update elements.data structure for reading v531 (1.8.0 data)
3. Need to update c2s (protocol) and s2c (structures)

and many other things which I don't recall now

 

[andelie]

thanks for translating
andelie
You can download the PW API 174 source from this link ()
and then you will need to replace the old addresses from the 174 EC.exe with the 180 EC.exe's new addresses. (for that you will need to use IDA or Ghidra)

just replace those addresses for the new ones on the main.cpp and also on the config.h
also, you will probably need to update the informer.cpp class with all new addresses and offsets used by new .exe.

With the API, you will be able to log the packets which are sent and received, then everything becomes easier to implement, but there is still much work to do on the server side.

And while on the server side:
1. Need to update rpcalls.xml (gnet protocols)
2. Need to update elements.data structure for reading v531 (1.8.0 data)
3. Need to update c2s (protocol) and s2c (structures)

and many other things which I don't recall now

Thank you. I understand everything you said, but I don't know how the PWApi_64.dll is encapsulated into the EXE.

编辑
分享

 

[afriendlyguy]

Thank you. I understand everything you said, but I don't know how the PWApi_64.dll is encapsulated into the EXE.

编辑
分享

Got it. You need to open it with IDA and look for an entry point where you can add the function. A good idea for finding things on the .exe is to search by text, you can download the client source code (152) here on the forum and compare with this .exe and use some texts to go to specific functions, it'll make your lfie easier maybe.
This sub_140D60620 function is being called along with many startup things for instance and inside of it (CECHostPlayer), I start my dll.

But for adding a function itself to the .exe, you'll need some knowledge on that

 

[sinchik97]

I downloaded the clean 1.8.0 client from PWBR, but it could be PWI too, then I modified it on IDA to load a .dll file (PW_API64.dll) as a hook. (this already existed on some previous versions, (I even think that probably someone posted a PWI API for an old client here on this forum already)

View attachment 283498

so on this .dll file I am basically doing what already existed on the old ones, finding addresses for patching and fixing things on the 1.8.0 version.
Many things have changed on the server side too (protocols and structures, but using this dll hook, it's possible to see what the cliend sends and what it gets from server, so it becomes a bit easier to understand the process).

Yo, is it C++ code? My eyes hurts from naming and syntax)))) (coding on Unity C# usual)

 

[brucedeity2]

thanks for translating
andelie
You can download the PW API 174 source from this link ()
and then you will need to replace the old addresses from the 174 EC.exe with the 180 EC.exe's new addresses. (for that you will need to use IDA or Ghidra)

just replace those addresses for the new ones on the main.cpp and also on the config.h
also, you will probably need to update the informer.cpp class with all new addresses and offsets used by new .exe.

With the API, you will be able to log the packets which are sent and received, then everything becomes easier to implement, but there is still much work to do on the server side.

And while on the server side:
1. Need to update rpcalls.xml (gnet protocols)
2. Need to update elements.data structure for reading v531 (1.8.0 data)
3. Need to update c2s (protocol) and s2c (structures)

and many other things which I don't recall now

Can you give some examples on "log the packets which are sent and received" with the api ? i mean, the output messages, i'm trying to find an easy way to get the structures from some packets from the elementclient using ida + dll api, so i can fix they accordingly in the server side

 

[afriendlyguy]

Can you give some examples on "log the packets which are sent and received" with the api ? i mean, the output messages, i'm trying to find an easy way to get the structures from some packets from the elementclient using ida + dll api, so i can fix they accordingly in the server side

I just capture the packets sent and received from C2S and S2C and just adapt it to my server. Some structure sizes have changed from 1.7.4 to 1.8.0 not only from GNET, but also from GS. I barely used IDA, I just used it to find the addresses which I need to hook on the PWAPI

this log file above is created from the PW API

Yo, is it C++ code? My eyes hurts from naming and syntax)))) (coding on Unity C# usual)

yes, both pwapi and server source are c++, and quite messy to be honest

 

[brucedeity2]

View attachment 284707
I just capture the packets sent and received from C2S and S2C and just adapt it to my server. Some structure sizes have changed from 1.7.4 to 1.8.0 not only from GNET, but also from GS. I barely used IDA, I just used it to find the addresses which I need to hook on the PWAPI

this log file above is created from the PW API

yes, both pwapi and server source are c++, and quite messy to be honest

Ah, I get it now, I had understood that you could use pwapi to print the structure of the packets themselves before sending them, something like "packet 1 = 2 ints, 1 float, 1 char", it would be a dream.. about printing the packets, I did it on the server side, printing the outgoing and incoming packets in the chat, version 162

 

[sinchik97]

View attachment 284707
I just capture the packets sent and received from C2S and S2C and just adapt it to my server. Some structure sizes have changed from 1.7.4 to 1.8.0 not only from GNET, but also from GS. I barely used IDA, I just used it to find the addresses which I need to hook on the PWAPI

this log file above is created from the PW API

yes, both pwapi and server source are c++, and quite messy to be honest

What is pwapi? its just a some kind of libs, or fully client source code?

 

[afriendlyguy]

Ah, I get it now, I had understood that you could use pwapi to print the structure of the packets themselves before sending them, something like "packet 1 = 2 ints, 1 float, 1 char", it would be a dream.. about printing the packets, I did it on the server side, printing the outgoing and incoming packets in the chat, version 162

Well, there is also the dump folder which basically captures the structure of each protocol sent/received and you can analyze using a hex editor like. I like the way you did, but if you want to capture packets from new clients the best way is just to hook the gamedatasend and game data receive functions in the pw api

What is pwapi? its just a some kind of libs, or fully client source code?

It's basically a .dll for hooking functions from the .exe.

For instance, let's suppose you want to modify or log everything that your client sends to the server, then you just need to find the Game datasend function address using IDA, and "override" it on your own .dll. You can make any modifications on the client side for any function without having its source code, it's not so easy though and it takes some time.

And... the client source code for 1.5.5 or 1.5.2 (can't remember now) was already leaked here, so what I do sometimes is:
I find a string (text) for a text I want and just look up on the assembly code (ctrl + t) on IDA for newer versions, and then I can kinda search and find the addresses I want.

I am not an expert on it, but I am learning it, it's hard to find any info about this to be honest, maybe some day I would make a guide or something like that

 

[jv90]

Why don't we upgrade the 1.5.X source code build for ElementClient to support 1.8.0 while we're at it or is no one willing to tackle Angelica3D / GFX related headaches and structures with all these methods?

Not to be a pessimist or anything since it is a useful library to load into or inject onto the binary, but why are we doing a half job? The client source code is way more important than the server source code, or just as important!..........

 

[afriendlyguy]

Why don't we upgrade the 1.5.X source code build for ElementClient to support 1.8.0 while we're at it or is no one willing to tackle Angelica3D / GFX related headaches and structures with all these methods?

Not to be a pessimist or anything since it is a useful library to load into or inject onto the binary, but why are we doing a half job? The client source code is way more important than the server source code, or just as important!..........

it would be cool and I guess way harder than upgrading the server since there would be plenty of CG related stuff.
I never tried to compile the client source code to be honest, I just look at it as a reference sometimes, but I have no idea on how hard it would take to upgrade from the current version to a newer one for example.

 

[brucedeity2]

Why don't we upgrade the 1.5.X source code build for ElementClient to support 1.8.0 while we're at it or is no one willing to tackle Angelica3D / GFX related headaches and structures with all these methods?

Not to be a pessimist or anything since it is a useful library to load into or inject onto the binary, but why are we doing a half job? The client source code is way more important than the server source code, or just as important!..........

I had the same thought until I migrated my client's compilation to Visual Studio 2022, put it into production, and a good portion of the players complained about compatibility issues and crashes. Some didn't even know how to install the Visual C++ runtime and related programs to fix the problem. At the same time, when compiling with Visual Studio 2005, NONE of these problems appeared.
That's where the question comes in: on the server side we can use recent technologies without any problems, since we are the ones who will run it, while on the client side, it's more worthwhile to use something that has already been well tested by Wanmei and its distributors than to risk "RECREATING the wheel" for nothing, running the risk of a good portion of people not even being able to play what you are proposing.

At least that's my opinion for the scenario and context of Perfect World itself. Obviously I would like to make the client's source code to support recent versions, but it looks like people will want to wait for the next leak from Wanmei.

Well, there is also the dump folder which basically captures the structure of each protocol sent/received and you can analyze using a hex editor like. I like the way you did, but if you want to capture packets from new clients the best way is just to hook the gamedatasend and game data receive functions in the pw api

View attachment 284735


It's basically a .dll for hooking functions from the .exe.

For instance, let's suppose you want to modify or log everything that your client sends to the server, then you just need to find the Game datasend function address using IDA, and "override" it on your own .dll. You can make any modifications on the client side for any function without having its source code, it's not so easy though and it takes some time.

And... the client source code for 1.5.5 or 1.5.2 (can't remember now) was already leaked here, so what I do sometimes is:
I find a string (text) for a text I want and just look up on the assembly code (ctrl + t) on IDA for newer versions, and then I can kinda search and find the addresses I want.

I am not an expert on it, but I am learning it, it's hard to find any info about this to be honest, maybe some day I would make a guide or something like that

Your comment helped me a lot, I was able to understand the part about logging on the client side, I read it from a pwapi that I found and I was able to incorporate it into my own version that I'm building, I even added imgui and made my own window to see the input and output logs.

 

[afriendlyguy]

I had the same thought until I migrated my client's compilation to Visual Studio 2022, put it into production, and a good portion of the players complained about compatibility issues and crashes. Some didn't even know how to install the Visual C++ runtime and related programs to fix the problem. At the same time, when compiling with Visual Studio 2005, NONE of these problems appeared.
That's where the question comes in: on the server side we can use recent technologies without any problems, since we are the ones who will run it, while on the client side, it's more worthwhile to use something that has already been well tested by Wanmei and its distributors than to risk "RECREATING the wheel" for nothing, running the risk of a good portion of people not even being able to play what you are proposing.

At least that's my opinion for the scenario and context of Perfect World itself. Obviously I would like to make the client's source code to support recent versions, but it looks like people will want to wait for the next leak from Wanmei.





Your comment helped me a lot, I was able to understand the part about logging on the client side, I read it from a pwapi that I found and I was able to incorporate it into my own version that I'm building, I even added imgui and made my own window to see the input and output logs.

View attachment 284819

good job, bro! now you can log in on a newer version like PWBR/PWI/PWRU/PWCH and see what client/servers sends and just implement the changes you need. (that's what I am doing)

 

[Bola]

Source code and Emulation have downsides, not always you will be able to figure out the entire structure, neither recreate the behavior client expect to have.

and yeah source code you have to write both sides instead of a single one, but you know every single piece of information being exchanged and how it will be treated in each side of conversation, plus many advantages in strategic game redesign that wouldnt be so possible through DLL injection leading to garbage solutions only.