Jump to content

Search the Community

Showing results for tags 'patch guide'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Bulletin Centre
    • Community News
    • Repository News
    • Ragnarok News
  • Hercules Development Centre
    • Development Discussion
    • Suggestions
    • Development Centre Archives
  • Support & Releases
    • General Server Support
    • Database
    • Scripting
    • Source
    • Plugin
    • Client-Side
    • Graphic Enhancements
    • Other Support & Releases
  • Hercules Community
    • General Discussion
    • Projects
    • Employment
    • Server Advertisement
    • Arts & Writings
    • Off Topic
  • 3CeAM Centre
    • News and Development
    • Community
  • International Communities
    • Filipino Community
    • Portuguese Community
    • Spanish Community
    • Other Communities


  • Client Resources
  • Graphic Resources
    • Sprites & Palettes
    • Maps & Textures
    • Other Graphics
  • Server Resources
    • Server Managers / Editors Releases
    • Script Releases
    • Source Modifications
    • Plugins
    • Pre-Compiled Server
  • Web Resources

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





IRC Nickname

Website URL




Found 1 result

  1. Now Before we delve into the details, lets consider a few things - this is meant for newbies. If you have made patches before skip ahead. Introduction to patching When we say we patch a client what it means is we change few bytes with a different set of bytes. (essentially we change a few opcodes or assembly instructions for e.g. a JNE to JMP so that the client behaves differently) Now these codes will be different for each client date and/or their location will change. So how do we make it generic? For this you need a sort of flow-chart to follow to get to the locations where modification needs to be made and for getting the replace logic. If you know how the original bytes were found , try to make note of the procedure you followed and you can usually make a patch following same logic. For e.g. like find a string -> find where its pushed -> 8 bytes later there is a JNE -> change to JMP Another step that helps out is finding a common pattern in a set of clients around where your modification is to be done. For e.g. Lets say i find '75 C0 E8 09 22 04 00 68 44 65 97 00' in 20130612 and '75 C0 E8 10 23 04 00 68 54 44 98 00' in 20130626 common pattern => '75 C0 E8 ?? ?? ?? 00 68 ?? ?? ?? 00' where ?? can be anything so you can use this common pattern instead of the individual ones. Not sure whether I made it clearer or confused you with that Intro. To summarize - making a patch is a combination of finding byte patterns, finding referenced addresses, changing instructions, finding vacant spaces and adding new codes, updating calls etc. If you know assembly language then it should be easy for you. If you don't know already try to read up on it at-least a little before going forward Now then back to topic Patches in NEMO The patches for NEMO are written in QtScript which follows ECMAScript format guidelines same as ... Javascript Therefore almost all of the functions & behaviors offered by Javascript you will find is also there in QtScript (well except for the actual web development part ) So I am not going to concentrate on the language itself. But rather I would be focussing on What all aspects are there specific to NEMO. NEMO Patch Instructions For NEMO to recognize a patch it needs to be registered. This is done in _patchlist.qs file in the patches folder. FORMAT for registering patch : registerPatch(patch id, functionName, patch Name, category, group id, author, description, recommended [true/false] ); patch id - a unique number used for referring to the patch internally in NEMO. functionName - the name of the function which will be called when a patch is enabled in NEMO. This function will contain your logic for making modifications into the client. patch Name - Name of the patch (displayed in the table) category - Category of the patch (like UI , Data, etc. displayed in the table) group id - id of the registered group to which this patch will belong. (details below) author - Patch Maker's Name (displayed in the table) description - Description of what the patch does (displayed in the table) recommended - boolean value showing whether this belongs to the recommended list of patches. Each Patch will belong to a Patch Group (if its not supposed to be part of any specific group use group id 0). All Patch Groups must be registered before they are used (except for 0 which is the Generic Patch Group registered by default) FORMAT for registering group : registerGroup(group id, group Name, mutualexclude [true/false]); group id - a unique number used internally in NEMO as well as when registering a patch. group Name - Name of the group (displayed in the table for all member Patches) mutualexclude - boolean value determining whether member patches are mutually exclusive i.e. Only 1 can be selected at a time or not. Once a patch is registered you need to make the function (name specified while registering). You can make it in any .qs file and save it in patches folder. It will be read automatically. Now to facilitate writing patches there are some ready-made variables & functions available to you. Now to facilitate writing patches there are some ready-made variables & functions available to you. 1) Reserved Keywords (well in a sense) i) Section Types - The following four can be used for referring to a section instead of using the section name itself as an alternative. CODE = 0, DATA = 1, IMPORT = 2, DIFF = 3 ii) User Input Types - These are the available input types in NEMO that you need to specify while getting an input value from user with the getUserInput() Function. Based on the types a different prompt appears for the user to select the value. You will understand more once you see function later on. XTYPE_NONE = 0, XTYPE_BYTE = 1, XTYPE_WORD = 2, XTYPE_DWORD = 3, XTYPE_STRING = 4, XTYPE_COLOR = 5, XTYPE_HEXSTRING = 6, XTYPE_FONT = 7, XTYPE_FILE = 8 iii) Pattern Types - You can specify a string in two forms : PTYPE_STRING => 0) Regular C Style string with Null termination - i.e. anything after '0' or "x00" will be ignored. E.g. "Ragnarok" PTYPE_HEX => 1) Hex String with spacing - You specify each byte with a space prefixed before it. E.g. " 68 90 00 95 00" As you might have guessed already if you have a null byte in your hex string always use PTYPE_HEX. iv) Address Types - Currently it is only used in findString() function to specify the type of value you want returned RAW = 0, RVA = 1 i.e. RAW/real address or Relative Virtual Address 2) Global Variables APP_PATH = path where NEMO is run from. CLIENT_FILE = path of the currently loaded client exe. Whenever your client exe gets loaded the object gets updated to refer to the loaded client. To access the bytes inside the exe we make use of the various methods of this object (Client Access functions detailed below). 3) Client Access Functions 3.1) - Fetching data i) exe.fetchByte(offset) - Extract 1 Byte and return it as a signed number. ii) exe.fetchWord(offset) - Extract 2 Bytes and return it as a signed number (little endian) iii)exe.fetchDWord(offset) - Extract 4 Bytes and return it as a signed number (little endian) iv) exe.fetchQWord(offset) - Extract 8 Bytes and return it as a signed number (little endian) v) exe.fetch(offset, num) - Extract <num> Bytes and return it as a string ( PTYPE_STRING ). vi) exe.fetchHex(offset, num) - Extract <num> Bytes and return it as a hex string ( PTYPE_HEX ). Do note that the returned hex string will already have space prefixed. 3.2) - Searching for data i) exe.find(pattern, type, useWildCard = false, wildCard = "xAB", start = -1, finish = -1) This is the core searching function available in NEMO. All the others are just extended versions of this function. This function searches for the <pattern> you provide in the client between the <start> and <finish> offsets. You need to specify the pattern <type> (PTYPE_STRING or PTYPE_HEX) for the client to use it accordingly. if start is -1 then it will automatically shift to beginning of the file i.e. 0, similarly if finish is kept at -1 it automatically shifts to the end of the file. Sometimes you wish to search for a pattern like " 68 ?? ?? ?? 00 74 ?? 83" where ?? actually means you dont care what is there in those areas. So how to search in those scenarios? First replace the ?? with a byte you dont have in your original pattern. For e.g. " 68 AA AA AA 00 74 AA 83" and call exe.find() with useWildCard as true and wildCard as "xAA" like shown below. var offset = exe.find(" 68 AA AA AA 00 74 AA 83", PTYPE_HEX, true, "xAA") - i didnt set the start and finish since i want the full client searched. If a match is not found then this function returns -1. ii) exe.findAll(pattern, type, useWildCard = false, wildCard = "xAB", start = -1, finish = -1) Same functionality as exe.find except that exe.find() stops at the first matched location but this one returns array of all matched locations. If no matches are found returned array is empty. iii)exe.findCode( pattern, type = PTYPE_HEX, useWildCard = false, wildCard = "xAB") - Extended version of exe.find() function with searching limited to CODE section iv) exe.findCodes(pattern, type = PTYPE_HEX, useWildCard = false, wildCard = "xAB") Extended version of exe.findAll() function with searching limited to CODE section v) exe.findString(pattern, rtype = RVA, prefixZero = true) - Extended version of find function with searching limited to DATA section. pattern can only be a PTYPE_STRING. rtype argument here refers to what type of address should be returned when found (RAW or RVA). If you want to search for isolated strings (i.e. NULL on both sides) set prefixZero to true vi) exe.findFunction(pattern, type = PTYPE_STRING, isString = true) - Extended version of find function for getting the address of an imported function. You can either specify the function's original name or the address of the function name in IMPORT section. vii)exe.findZeros(zsize) - Extended version of find function used for locating empty space in DIFF section for inserting new code. The function always looks for zsize+2 null bytes to make sure each inserted code is seperated by atleast 1 null byte. 3.3) - Modifying data i) exe.replace(offset, code, type = PTYPE_STRING) The core function used for replacing bytes in the client file. code is the pattern which will replace the original - don't forget to mention the pattern type. There is no return value for replace functions. You can also provide the variable name you used in exe.getUserInput() function earlier as the code (NEMO will pick up the value inside). ii) exe.replaceWord(offset, code) - Extended version of exe.replace(). Here code is expected to be a 16 bit signed number. iii)exe.replaceDWord(offset, code) - Extended version of exe.replace(). Here code is expected to be a 32 bit signed number. iv) exe.insert(offset, allocSize, code, type = PTYPE_STRING) - Extended version of exe.replace() used for Inserting code into Null areas. offset should be the value you got from exe.findZeros(allocSize). 3.4) - User Interaction i) exe.getUserInput(varname, valtype, title, prompt, value, min=0, max=2147483647) - Prompts the user for a value. Based on the valtype you get different windows for value entry and the value selected by the user is also returned by the function. varname used should be unique across patches and can be used in replace & insert functions to refer to the user entered value. title is the text displayed on the input window title bar prompt is the text displayed as prompt next to the input box. in case there is no input box. for e.g. like in XTYPE_COLOR , the prompt is suffixed to the title bar itself. value is the initial value to use for the input. If the variable was set previously or reloaded from a profile/from a previous applied patch, this value is ignored. 3.5) Section information All the four functions mentioned below gets 1 information of a section specified by key. key can be either the section name or section type (mentioned at top) i) exe.getROffset(key) - Real Offset ii) exe.getRSize(key) - Real Size iii)exe.getVOffset(key) - Virtual Offset iv) exe.getVSize(key) - Virtual Size 3.6) Miscellaneous i) exe.getClientDate() - Need i say more? ii) exe.isThemida() - return true if its a 2013 unpacked client. iii)exe.Raw2Rva(rawaddr) - Converts a RAW/real address to Relative Virtual Address. iv) exe.Rva2Raw(rvaaddr) - inverse of above. In case you are still wondering: RAW address is the physical offset of a code (bytes) from beginning of the client which you see in a Hex Editor such as HxD. Relative Virtual Address or RVA is the address you see for the same code when you open the client in a debugger such as Ollydbg. RVA is relative to a value called imagebase hence the name Relative Virtual Address. RVA - imagebase = VA. 4) Utility Functions There are a few utility functions written in QtScript (you will find them in the core folder) to facilitate some commonly done routines. i) "string".replaceAt(i, newstring) - by default strings have a replace command but no command to replace at a specific offset this one does that. For e.g. "abracadabra".replaceAt(4,"k") will return "abrakadabra" ii) "string".repeat(i) - returns new string with the "string" repeated i times e.g. "na".repeat(4) will return "nananana" .... ... batman? iii)"hexstring".hexlength() - returns the number of bytes in the hex string (PTYPE_HEX). For e.g. " 90 49 54".hexlength() returns 3 iv) "string".toHex() - converts string to hex string (from PTYPE_STRING to PTYPE_HEX) e.g. "AM".toHex() returns " v) "string".toHexUC() - converts string to hex string (similar to above but extra null byte padding is provided - like ASCII in Unicode) vi) "hexstring".toAscii() - reverse of iv) vii) (Number).packToHex(size) - packs a number to its little endian hex string with the size number of bytes used up size can be maximum 4. the number or expression needs to be in a bracket or a variable. e.g. (123456).packToHex(4) => " 40 E2 01 00" viii) getInputFile(f, varname, title, prompt, fpath) - repeatedly loops until a valid file is specified as input or the form is cancelled => patch should be disabled. 5) TextFile class Since I found no suitable types in QtScript for accessing files. I have added a new class called TextFile for accessing textfiles.To use the class first we need to make an object of the class (yes i mean in the patch file itself) var fp = new TextFile(); Methods i) fp.open(<absolute file path>, <mode>) - once fp is assigned we need to use the open method to use it to access a file. mode can be "r" or "w" ii) fp.readline() - currently only reading full line is available, since i needed full lines at a time. iii)fp.write(data) - writes the specified data onto file. iv) fp.writeline(data) - same as above but also adds a carriage return + form feed (goes to new line) v) fp.eof() - true when end of the file has been reached. vi) fp.close() - closes the file opened by fp.open() You can check the TranslateClient.qs file in patches folder for an example of its use. --------------------------------------------------------------------------------------------------------------------------------------------------------- Hmm what else .... so now that you have gone through this guide, hopefully you can better understand what is written in the patches already there. and maybe bring in your own ideas? Let me know if any part of this guide didn't make sense, needs elaborations, clarifications etc. FYI: I know it doesn't look pretty right now. But this was done in a hurry since I will be gone for a week . I will clean things up later on.
  • Create New...

Important Information

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