[1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED

  • Konbuyu başlatan Konbuyu başlatan Reflex
  • Başlangıç tarihi Başlangıç tarihi
Durum
Üzgünüz bu konu cevaplar için kapatılmıştır...
Kayıtlı Üye
Katılım
17 Nisan 2013
Mesajlar
401
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



Tesekkurler !
 
Kayıtlı Üye
Katılım
20 Eylül 2012
Mesajlar
588
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



tesekkurler
 
Katılım
29 Temmuz 2013
Mesajlar
994
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



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.





P4uPQ.png






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):



Kod:
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).



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.



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







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.



Kod:
<settings>

<definition name="Ebenezer (1.298)" signature_offset="0x3C56" signature_value="0x6E792E9">

<patch name="Level cap" type="byte">

<offset>0xB5100</offset>

<offset>0x9F77E</offset>

...

</patch>

<patch name="Server port" type="ushort" value_modifier="-1" offset="0x219BF"/>

<patch name="Server version" type="ushort">

<offset>0x9141B</offset>

...

</patch>

<patch name="Private key" type="long" offset="0xD1729-0xD1722" hex="true"/>

<patch name="Knight_Account DSN" type="string" max_length="19" offset="0x25F0C8"/>

[... other settings here ...]

</definition>

[... other definitions here ...]

</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)



Kod:
<patch name="Level cap" type="byte">

<offset>0xB5100</offset>

<offset>0x9F77E</offset>

<offset>0x9BC45</offset>

<offset>0x20DA3</offset>

</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):



Kod:
<patch name="Private key" type="long" hex="true">

<offset>0x504A1-0x504A6</offset>

<offset>0x505BE-0x505C3</offset>

<offset>0x5079C-0x507A1</offset>

<offset>0x50898-0x5089D</offset>

<offset>0x2477AF-0x2477B4</offset>

<offset>0x270639-0x270632</offset>

</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 ***Hidden content cannot be quoted.***

Primary mirror





Older versions?

Sorry, don't support them anymore. Don't like them, don't trust them - please don't learn from them.



If you have any questions regarding this, feel free to post them here.







lket me test it now
 
Kayıtlı Üye
Katılım
19 Nisan 2015
Mesajlar
163
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



hope this helps
 
Kayıtlı Üye
Katılım
7 Mayıs 2014
Mesajlar
397
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



tyyyyyyyyy
 
Kayıtlı Üye
Katılım
1 Aralık 2012
Mesajlar
71
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



twostars is king ;)
 
Yeni Üye
Katılım
15 Mayıs 2015
Mesajlar
7
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



Thanks..
 
Kayıtlı Üye
Katılım
13 Temmuz 2015
Mesajlar
34
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



Ill try a thing
 
Kayıtlı Üye
Katılım
12 Mayıs 2015
Mesajlar
40
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



tytytytytytyty
 
Kayıtlı Üye
Katılım
13 Ekim 2012
Mesajlar
972
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



Dasdasdasdsdasadasadasaasas
 
Kayıtlı Üye
Katılım
15 Ocak 2015
Mesajlar
176
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



teşekkürler hemen deniyorum
 
Kayıtlı Üye
Katılım
19 Ağustos 2015
Mesajlar
378
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



+++++++++++++++++
 
Katılım
29 Ağustos 2015
Mesajlar
10,718
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



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.





P4uPQ.png






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):



Kod:
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).



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.



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







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.



Kod:
<settings>

<definition name="Ebenezer (1.298)" signature_offset="0x3C56" signature_value="0x6E792E9">

<patch name="Level cap" type="byte">

<offset>0xB5100</offset>

<offset>0x9F77E</offset>

...

</patch>

<patch name="Server port" type="ushort" value_modifier="-1" offset="0x219BF"/>

<patch name="Server version" type="ushort">

<offset>0x9141B</offset>

...

</patch>

<patch name="Private key" type="long" offset="0xD1729-0xD1722" hex="true"/>

<patch name="Knight_Account DSN" type="string" max_length="19" offset="0x25F0C8"/>

[... other settings here ...]

</definition>

[... other definitions here ...]

</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)



Kod:
<patch name="Level cap" type="byte">

<offset>0xB5100</offset>

<offset>0x9F77E</offset>

<offset>0x9BC45</offset>

<offset>0x20DA3</offset>

</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):



Kod:
<patch name="Private key" type="long" hex="true">

<offset>0x504A1-0x504A6</offset>

<offset>0x505BE-0x505C3</offset>

<offset>0x5079C-0x507A1</offset>

<offset>0x50898-0x5089D</offset>

<offset>0x2477AF-0x2477B4</offset>

<offset>0x270639-0x270632</offset>

</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 ***Hidden content cannot be quoted.***

Primary mirror





Older versions?

Sorry, don't support them anymore. Don't like them, don't trust them - please don't learn from them.



If you have any questions regarding this, feel free to post them here.



thxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
Kayıtlı Üye
Katılım
1 Nisan 2013
Mesajlar
381
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



tyyyyyyyyyyyyyyyyy
 
Kayıtlı Üye
Katılım
11 Mart 2012
Mesajlar
161
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



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.





P4uPQ.png






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):



Kod:
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).



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.



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







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.



Kod:
<settings>

<definition name="Ebenezer (1.298)" signature_offset="0x3C56" signature_value="0x6E792E9">

<patch name="Level cap" type="byte">

<offset>0xB5100</offset>

<offset>0x9F77E</offset>

...

</patch>

<patch name="Server port" type="ushort" value_modifier="-1" offset="0x219BF"/>

<patch name="Server version" type="ushort">

<offset>0x9141B</offset>

...

</patch>

<patch name="Private key" type="long" offset="0xD1729-0xD1722" hex="true"/>

<patch name="Knight_Account DSN" type="string" max_length="19" offset="0x25F0C8"/>

[... other settings here ...]

</definition>

[... other definitions here ...]

</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)



Kod:
<patch name="Level cap" type="byte">

<offset>0xB5100</offset>

<offset>0x9F77E</offset>

<offset>0x9BC45</offset>

<offset>0x20DA3</offset>

</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):



Kod:
<patch name="Private key" type="long" hex="true">

<offset>0x504A1-0x504A6</offset>

<offset>0x505BE-0x505C3</offset>

<offset>0x5079C-0x507A1</offset>

<offset>0x50898-0x5089D</offset>

<offset>0x2477AF-0x2477B4</offset>

<offset>0x270639-0x270632</offset>

</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 ***Hidden content cannot be quoted.***

Primary mirror





Older versions?

Sorry, don't support them anymore. Don't like them, don't trust them - please don't learn from them.



If you have any questions regarding this, feel free to post them here.





thank you for resharing
 
Yeni Üye
Katılım
29 Ekim 2015
Mesajlar
1
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



Thanks.... need it badly
 
Kayıtlı Üye
Katılım
13 Kasım 2015
Mesajlar
59
Cevap: [1.298, 1.310/1.351/1.397/'2.0'] Ebenezer/Client Editor 1.07 BETA R7 UPDATED



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.





P4uPQ.png






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):



Kod:
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).



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.



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







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.



Kod:
<settings>

<definition name="Ebenezer (1.298)" signature_offset="0x3C56" signature_value="0x6E792E9">

<patch name="Level cap" type="byte">

<offset>0xB5100</offset>

<offset>0x9F77E</offset>

...

</patch>

<patch name="Server port" type="ushort" value_modifier="-1" offset="0x219BF"/>

<patch name="Server version" type="ushort">

<offset>0x9141B</offset>

...

</patch>

<patch name="Private key" type="long" offset="0xD1729-0xD1722" hex="true"/>

<patch name="Knight_Account DSN" type="string" max_length="19" offset="0x25F0C8"/>

[... other settings here ...]

</definition>

[... other definitions here ...]

</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)



Kod:
<patch name="Level cap" type="byte">

<offset>0xB5100</offset>

<offset>0x9F77E</offset>

<offset>0x9BC45</offset>

<offset>0x20DA3</offset>

</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):



Kod:
<patch name="Private key" type="long" hex="true">

<offset>0x504A1-0x504A6</offset>

<offset>0x505BE-0x505C3</offset>

<offset>0x5079C-0x507A1</offset>

<offset>0x50898-0x5089D</offset>

<offset>0x2477AF-0x2477B4</offset>

<offset>0x270639-0x270632</offset>

</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 ***Hidden content cannot be quoted.***

Primary mirror





Older versions?

Sorry, don't support them anymore. Don't like them, don't trust them - please don't learn from them.



If you have any questions regarding this, feel free to post them here.



谢谢 来自 china :)
 
Durum
Üzgünüz bu konu cevaplar için kapatılmıştır...
Üst Alt
Reklam
Reklam