Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited

  • Days Won


Diab last won the day on February 10

Diab had the most liked content!

Community Reputation

6 Neutral

About Diab

  • Rank


  • Country
  • Languages

The recent visitors block is disabled and is not being shown to other users.

  1. Diab

    JE to JMP

    That can be achieved by editing the instruction bytes at run-time. There are two types of JE/JZ which are Near and Short jumps and the main difference is short jumps only jump a distance of a byte while near can jump a distance up to 4 bytes. You will need to identify which it is because the new bytes representing the JMP instruction will vary based on the jump distance, if the distance is a short then the new byte should be 0xEB while the near jump will be 0xE9 , keep in mind that a near JE instruction code is 2 bytes long while the near JMP code is 1 byte long so you will need to keep that in mind.
  2. Diab

    Client : Editing resolution

    I've done it only once for an uncompleted project a while back, from what I remember I placed a breakpoint on the fopen function to see which file is getting read and when it was readying server.dat I would trace it to see where it's getting decrypted. I might do a tutorial with some c++ as well.
  3. Happy to see another person interested in C++ for networking I prefer to use boost.asio I like the way they handle asynchronous sockets and they are up to date and use newer c++ features , I'd say use boost generally since they have a lot of different libraries that can go along way helping you develop with c++ , it's also very well documented. as for GUI I can't really suggest a library since I use winapi when I rarely need to do UI work but I would say Qt is one of the better options. Good luck with your coding adventures.
  4. Diab

    Client : Editing resolution

    Introduction Conquer Online's older clients do not support higher resolution by default so in this guide I will be explaining how to edit the client's resolution to support higher resolutions, There will be no coding an I will try to explain the assembly instructions as I go, I will be using a 5095 client for this guide but the process should remain the same. Note that this is simply a guide to how it can be accomplished and I recommended doing through coding a dll instead of directly editing the executable to be able to configure it to any resolution without the need of multiple executables. All the numbers shown in the pictures are in hexadecimal (base16). Finding Window Resolution By doing a simple search in the client's executable (Conquer.exe) for the constant values 1024 or 768, we find two occurrences which are being stored in a global variable. In the first image we have the value of ecx register being set to 2 and being compared to the value of eax , if they aren't equal it jumps to the other image where the value is being compared against 3 by doing some backtracking we realize that the value of ScreenMode in GameSetUp.ini is being checked with 2 in the first and the 3 in the second image which represent 1024x768 window and full screen modes respectively, now by simply editing those values (400h and 300h) we can change the window resolution to any value we want which will only take effect if the client is in 1024x768 resolution mode, I.e. only if the ScreenMode value is set to 2 or 3. Having accomplished that we are faced with a few problems one being the client doesn't render the map edges properly if the resolution exceeds a certain value, to fix this we look for another two constants, which after doing some research and debugging ourselves we notice that aren't 1024 or 768 so by trying to identify/link any values to the ScreenMode value we find that there is no such value meaning that there is no actual correlation between the ScreenMode and the rendering resolution so by then trying the other default resolution to the client 800x600 we find the following. In that instruction block we find that there is some calculation being made and loop being executed just after that, by changing those values to our desired resolution values we fix the rendering problem , our next problem to fix is the alignment of the UI elements. Changing UI Alignment Since we aren't doing any coding, we will have to change the positions in the GUI.ini but we quickly find that some UI elements do not use the GUI.ini values but rather are hard-coded one of which is the player's heath/action bar/panel,(Skip this part if you don't want to center the player's panel) to find it we use the value we find to be the actual size or position of the panel by doing some searching in the GUI.ini and using the mouse position at the topmost pixel of the panel and the bottommost pixel and subtracting we find that the panel height is 141 ,we obtained the height specifically because we realize that the panel is being correctly positioned on the Y-Axis regardless of the resolution which means that the client uses it's height to determine the y value (being Screen Height - Panel Height) and after looking for that value we find the following. we see at the bottom a call to the function CWnd::MoveWindow which takes x,y,width,height and a repaint Boolean as parameters now depending on the function's calling convention the parameters are pushed to the stack in a specific order, since this is a _thiscall function we push the parameters in reverse order repaint>height>width>y>x which storing the class instance in ECX (being CWnd in this case), and so by looking at the instructions we see a call to GetWindowRect which we will ignore as the return value isn't being used then we see a 1 being pushed to the stack which represent a true value as the repaint parameter and then a 8Dh(141) which represent the height and so on. and as we look down we see a call to GetScreenHeight after which 141 is subtracted from the return value stored in EAX(being height) and later on pushing EAX to the stack as the Y parameter, we also see 0 being pushed as the x parameter which we need to change to center the panel but we notice that there is only a space enough for signed byte which can only take up to 0x7f or (127) as a positive number to fix this we will have to rewrite/change the instructions to push a constant Y value and skip the calculation. ("db 0" represent an empty byte) As seen above, we can edit the to push the y value directly so we have enough space to push a bigger x value as well. Other elements like the help window button follow similar principles but it's redrawn in a block of code than the original drawing so you will need to patch it twice and the arrow's quiver is a bit trickier but can be done (hint:It's being drawn constantly in a loop, and has several parts that are drawn a few bytes away from each other). IDA is used to disassemble the executable.

Important Information

By using this site, you agree to our Terms of Use.