点击进入下载－KO_Editor.rar

5月21日更新：7楼

啊那位帮我发的？密码都知道了。我硬盘里的东西还好吧，都论坛下载的。看看还有什么需要的？直接说QQ传给你。。306752627  宓码我我就不改了。。您用着。。

现在都出V1.06啊

木马，报的很厉害。怎么弄？

木马，报的很厉害。怎么弄？

好像是中了

KO Ebenezer/Client Editor 1.07 (BETA R7)

UPDATED TO VERSION 1.07 (BETA R7) - USE THIS INSTEAD OF ANY PRIOR VERSION TO AVOID ANY PROBLEMS WITH EBENEZER!

Description
"Ebenezer/Client Editor" is a tool that was developed that does exactly what it states. It edits the Knight Online client EXE, Ebenezer (game server), and even the Launcher. I have, however, only made support for all the standard unpacked copies of said files (for - at the time of posting - 1.298, 1.310 and 1.351/1.397). As of 1.07 though, you can implement your own files (or add your own patches!) to the new configuration file - settings.xml.

At the current time, the 'ECE' can modify:

Client
- Game server port (note: on 1.310 it's sent in the server-list - from the server - so you're not able to change it client-side),
- Login server port ,
- Power-up store URL (as of 1.07, it no longer pads it with spaces [some webservers had issues with this]),
- Version,
As of 1.07 it also supports:
- TBL filenames,
- TBL extension (e.g. _us.tbl)
- The window title,
- The private cryption key (this must match on both server and client to be able to talk to each other - I suppose it's one means of forcing people to use your client)

Server
- Server port,
- Level cap,
- Version,
- Default database details (anyone else sick of creating a bunch of duplicate DSNs just so that the server's happy?),
- Including the DSNs from above, database username, and database password,
- The INI's filename (didn't bother reimplementing that in 1.07, was only used to create unnecessary confusion),
- Clan grade requirements,
- Zone entry-level requirements (also dropped, a few of the other zone checks relied on these values, changing them just stuffs things up - sorry about that),
- Command names (occasional glitch with this has finally been fixed in 1.07)
As of 1.07 it also supports:
- The private cryption key (this must match on both server and client to be able to talk to each other - I suppose it's one means of forcing people to use your client) * Global var added to 1.07r6, so it works completely now *
- 1.310 completely
- 1.351/1.397 completely

Launcher
- Home page URL (button),
- Client's filename that it runs when you hit "Start",
- Super-secret (sarcasm) command-line arguments for KnightOnline.exe,
- FTP details (user/pass),
- Browser URL!
As of 1.07 it also supports:
- All 5 different copies of standard unpacked launchers I was able to provide support for (I asked, but nobody offered me any - so if you have any standard unpacked launchers that this doesn't support, feel free to send it my way and I'll throw in support),
- HTTP args for the newest USKO launcher.

Stuff you don't have to read, but I'd appreciate it if you did (if you need help, READ HERE FIRST):

1. 1.07 notes
   
2. 
   
3. So it's been 3 years now since I wrote the original Ebenezer/Client Editor. Since, I lost the updated source for it, so I ceased to support it (though I'd been meaning to write it fresh, because - let's face it - it was horrible).
   
4. 
   
5. 1.07 is a complete rewrite of the Ebenezer/Client Editor. This time around, I wanted it to be a lot more configurable (and.. obviously, reliable) - so I decided on using a simple list, and fleshing it out with dynamic settings from a config file (settings.xml), that way anybody would be able to update it in future for new (or even old!) files, or simply new settings - without needing to even touch the source.
   
6. 
   
7. What I want to make clear, however, I also decided to stray from the all-in-one app that I initially wanted the Ebenezer/Client Editor to be, so with all the required patches of late (& the undoubtedly many more to come), and the fact I'd previously written & released BytePatcher for this purpose.

复制代码

I completely dropped support for non-setting patches.
(basically anything that didn't require a simple value change was dropped)

The Ebenezer/Client Editor will no longer support this or anything like it, instead... use the BytePatcher for it - it's what it was designed for, just as this was (re-)designed for the modification of hardcoded settings/values.

That said, I actually had a lot of fun writing the new Ebenezer/Client Editor - unlike the old one, this one's basically clean and simple. No clutter, no fuss at all - just load & configure.

So I hope you guys like the new ECE, I know I certainly hated referring people to use it while aware of one of the main bugs (padding strings with spaces... at the time, wasn't aware webservers were so... specific). This version should address those issues (so now I can move onto other tools I haven't updated which really, really need to be).

A look at 1.07's settings.xml file

Now, to be brutally honest, the settings.xml file is really simple to work with - I tried to keep it all as verbose as I could.

As with the BytePatcher, each file is separated into "definitions" (in this, however, I use an XML file - seemed much more fitting for this task than my standard INI config).

Each definition node contains patch nodes, which can either be "one-liners" (changing one setting in one place), or "multi-liners" (changes the same setting in multiple places, e.g. the server's level cap).

Here's an excerpt from the file containing an example of pretty much everything the Ebenezer/Client Editor supports.

1. <settings>
   
2. <definition name="Ebenezer (1.298)" signature_offset="0x3C56" signature_value="0x6E792E9">
   
3. <patch name="Level cap" type="byte">
   
4. <offset>0xB5100</offset>
   
5. <offset>0x9F77E</offset>
   
6. ...
   
7. </patch>
   
8. <patch name="Server port" type="ushort" value_modifier="-1" offset="0x219BF"/>
   
9. <patch name="Server version" type="ushort">
   
10. <offset>0x9141B</offset>
    
11. ...
    
12. </patch>
    
13. <patch name="Private key" type="long" offset="0xD1729-0xD1722" hex="true"/>
    
14. <patch name="Knight_Account DSN" type="string" max_length="19" offset="0x25F0C8"/>
    
15. [... other settings here ...]
    
16. </definition>
    
17. [... other definitions here ...]
    
18. </settings>

复制代码

As usual, the definition node supports the following attributes:
- name: Name/description of the definition block. Describes what file we're loading/supporting - only used for display/identification purposes, you can pretty much set it to whatever you want.
- signature_offset: A location in the file (can be quite random) where we can pull a 4-byte value (from anywhere in the file) unique to this file, for identification purposes (so that when the Ebenezer/Client Editor loads this file, it'll check the location specified in signature_offset against the signature_value (next attribute listed) to test if it's the file we're looking for.
- signature_value: As with the previous setting, this is the value it checks (at the offset signature_offset in the file we're loading) to see if it's the file we're looking for.

Don't be too fussed about where the signature_offset is (or what the value is), you'll be fine just as long as the value there is unique between your files. I just picked a random, low offset and stuck with it across all of those files currently in settings.xml.

The patch node supports the following attributes:
- name: Name/description of the patch (listed in the Ebenezer/Client Editor).
- type: Datatype of the value we're retrieving. Possible values are:
sbyte/SByte (signed byte), byte/Byte (unsigned byte),
short/Int16 (signed word [2 bytes]), ushort/UInt16 (unsigned word [2 bytes]),
int/Int32 (signed dword [4 bytes]), uint/UInt32 (unsigned dword [4 bytes]),
long/Int64 (signed qword [8 bytes]), ulong/UInt64 (unsigned qword [8 bytes]),
string (null-terminated string)

Either of the values listed mean the same thing for the purposes of our config, so for example, you can use either sbyte or SByte if you're reading a (single) signed byte.

- max_length: This is only used when the type attribute is set to string. It specifies the maximum length of the string.
- hex: This indicates whether the value should be displayed as hexadecimal or not (useful for some values, like the private key). It'll also force any changes to be converted back to hexadecimal (e.g. if you specify "80" [as decimal], it'll convert & display it as 0x50 [hexadecimal]) - the reverse is true by default (e.g. if you specify "0x50" for a value not forced to display as hex, it'll convert & display it as decimal [80]).
It's only used for integer-based values (so, not strings) and is set to false by default. Set it to "true" (or anything) to enable. To disable, remove this attribute.

- value_modifier: This is a really simple (and I'm stressing the "really") setting used to display expected values. It's useful for cases such as the server port (it's -1 by default [because it's affected by the INI], so the actual value for a default port [15001] is actually 15000), and of course the clan grade NP requirements (which are actually stored as /36 of what they really are [I assume this is because they wanted to keep it flexible, in case they changed the clan member limit again]).
So, for example, to set the server port to 15002, we would need to set it 15001 instead... which is confusing, huh? That's why this setting exists - it'll assume it's -1 of what you set it to, and adjust it accordingly behind-the-scenes, so that you can change it to whatever you want to change it to, instead of what it needs to be changed to.

As stated, it is a simple setting, so it currently (as of beta R5) only supports the 4 standard mathematical operations (division (/), multiplication (*), addition (+), subtraction (-)) - and with only one operand.

This means you can only use it for ONE operation, not multiple (I didn't see any need for multiple operations).

- ...and of course, offset: Specifies the file offset of the patch. With 64 bit integers (ONLY) that are spread out over 2 dwords in 32-bit files, you can break this up into two consecutive offsets indicating both halves of the integer by separating them with a hyphen (-), e.g. "0xD1729-0xD1722" (just make sure they're in the correct order).

For multiple patches of the same value (in different locations) - like the level cap patch - you can use offset nodes inside the patch node instead, for example (again, with the level cap patch):

1. <patch name="Level cap" type="byte">
   
2. <offset>0xB5100</offset>
   
3. <offset>0x9F77E</offset>
   
4. <offset>0x9BC45</offset>
   
5. <offset>0x20DA3</offset>
   
6. </patch>

复制代码

The same 64 bit hack applies to these offset nodes (specifying a hyphen between the two offsets), like so (with the private key patch):

1. 
   
2. <patch name="Private key" type="long" hex="true">
   
3. <offset>0x504A1-0x504A6</offset>
   
4. <offset>0x505BE-0x505C3</offset>
   
5. <offset>0x5079C-0x507A1</offset>
   
6. <offset>0x50898-0x5089D</offset>
   
7. <offset>0x2477AF-0x2477B4</offset>
   
8. <offset>0x270639-0x270632</offset>
   
9. </patch>

复制代码

It should be noted that any integer input allows you to use either decimal or hexadecimal notation. To specify a hexadecimal number, it must either be prefixed with 0x or &H (although simply specifying an "x" or [an uppercase] "H" are both acceptable too).

Using this file you can implement support for any unpacked file (KO or otherwise) you'd like, hopefully you do find it useful for other purposes.

That said, if you have any suggestions on additions, feel free to let me know here and/or add them yourself.

Download links
http://pan.baidu.com/share/link?shareid=487606&uk=2568474030

Edited by twostars, 07 April 2013 - 02:32 PM.
Updated to fix a bad patch (login server port). If you've used this patch, use the old tool to revert the value back to "15100" and then you can just use the updated config file.