Need help in item routing.

Hi there,
I noticed that in one of the server.exe i downloaded had a route for items at the bottom of the file, i was wondering how it can be done to a client.exe too, meaning making a separated list of the items at the bottom of the exe instead of using the existing list inside the exe, coz i notice many of them were replacing lower items. which i know is the easiest but not the best way.

Thanks in advance.

oh ya, does anyone has client that's not very bugged?
i haven found one which works well enough, those i found either doesnt level, or double registers the user in the server. The one from quantumfusion i was unable to get it running despite changing the ip at the bottom of the exe.

I attempted this recently, and was confident everything was going well until... it didn't. The process should be exactly the same as the many guides on moving and increasing the Exp:Level table both ends... however, in practice the task requires you to remember so many pointers and variables over quite some considerable time in Olly that most people seem not to be able to get to the end of it without making a mistake somewhere.

I can only presume this must be what I did, and though I plan to make another attempt and make a guide on it when I get it correct I can only wish you the best of luck with your attempt for now, unless you have some specific questions about the various stages.

Basic stage breakdown:-

1. Add a section big enough for your table, if there isn't a completely free space already existing.
2. Locate all links to the various fields of the table.(There are some 5-8 fields all references point to the first record, and some pointers to the end, or just beyond, of the table, there are some 8-10 routines that point to some or all of those fields in that table... most can be clearly identified as iterating through pointer shifts of 300 and odd bytes that constitute a record... [315,312; It's not a round figure in either hex or decimal.] There is also information in the table which I could not see referenced directly, [that may be where my mistake lay] and some of the 00 space is filled with data at run time. IMS)
3. Update each group of similar pointers from the old table to the new one.
4. Optionally zero fill the old table... this is the point you will KNOW you have succeed or not, because if there is anything still referencing the old table it will just get back zeros. :wink: This also makes you end exe cleaner, less confusing and more compressible (you're gonna have to distribute it, the client at least, right?)

You will have to go through this process on both the server and the client executables, unless you already have a shifted table on your server. But even then, you may want to extend the table end pointers if you are adding items to it. :wink:

Again... best of luck to you, and please keep and share your notes with us if you succeed.:thumbup1:

ok this is what i've attempted b4 i posting my help
basically, i wipe all the weapons off from the original table in the item table inside the client, and replaced it with a table i build, each item is +788 apart from each other and it starts -3 from the name
eg. 01 01 01 W E A P O N N A M E .... aefaoiefoiej

i successfully rebuilt the list (and removing all the mace unfortunately coz i think they're redundant and to make some space).

everything was fine, u can drop them in codes and pick them up eg. /@get wa305
but when everything seem fine.....!!!!
this is what happened, when i use the item, from wa101 till wa115 it's normal, but from wa116 till 15 later, it's hold as a claw, i believe it's because originally, in the list the pointer were for 15 axe then 15 claw etc etc, but sadly, i do not know how to move the pointers elsewhere, and help there? i believe this is also how the extended list below the exe can be done.
am i not right?

Okay... I looked again a little. I should have said 0x314 = 788... Still not bad for late at night and off the top of my head. :s

No, the record starts 4 bytes (1 word / 32 bits) before the item name. The word before the item name is an item count, but it is not 01 00 00 00, 02 00 00 00, 03 00 00 00 etc as one might expect. It starts 00 01 01 01 and progresses 00 01 01 02, 00 01 01 03 etc.

And your problem (axes acting like claws) won't be solved by moving the table... it will be solved by understanding the data within the table and how the game uses that data.

Example record 1:-http://a.imagehost.org/0641/ItemHex.png

32 bytes after the count word are reserved for the textural name... this is usually never seen by the user, as it is replaced for each item by the name used on the server.

16 bytes reserved for the item code name. This is recorded twice in each record, one copy is checked against the code that dropped items use, the other is merged into the itwBLA101 name used to pick up inventory images, and display meshes from the local client data files.

2 Words or one Double/Quad (8 bytes) are recorded next, the purpose of which I am unsure of. But they are used and relevant to the client. (If the later field I point out isn't the one you need, this is the next best candidate)

128 bytes reserved for a string describing the type of item. This isn't determinate of how the item acts, but is filled with "Weapon", "Armor", "Accessory", "Premium" etc. I have no idea how much notice the client actually takes of the information which is stored here.

1 Word for another code that I don't yet know the meaning of.

Another 16 bytes of Item Code. I don't remember which code was used for what, but it does seem odd that it's the same data recorded twice.

The information that follows is largely empty, there are two chunks that are filled with dynamic data by the client at run-time, and in-between them, at about [record offset]+0x0C is a bunch of codes which you will notice are all the same for similar types of item, but differ from one item type to another.

That code at ~0x0C from the record start is what I think will be causing your Claw axes.

Again this info is coming off the top of my head, so it could be inaccurate... but there is a code in one of those fields I'm unsure of that produces the effect you describe... I've had to fix it for an item before. Hunt your table, look at real axes, and real claws and it will jump out at you, I'm sure. :wink:

Again... good luck, and I hope this helps.

oh, i've actually looked into the codes for them, yes thou they were hold as claw for the 15 after axes other other items (be it axe or bow or other items), it acts as the item it is suppose to be, just that the stance they're using were of those in the original table, 15axes then 15 claws then 15 mace etc etc etc, and when they overflow into the table meant for accessories, they were hold as random stance every time u click to move, funny lol! the main thing is locating where the pointer is, correct me if i'm wrong =x

ya, i checked for 0x0C codes too, those axe at the 15th onwards do match those of axes and claws match those of claws.

Well... when I checked for pointers mid way through the table, I found none.

It's possible that it isn't a pointer, but a count of 15 records, but that would show up in the loop routines. It's both interesting that the stance doesn't come from the kind of weapon code, and that the stance over bounds is random.

On the server end, you have the advantage that it isn't going to render stances and animations... so although the code is the same (pretty much) what information actually gets executed and used is different. I noticed there where fields used in the server that the client doesn't actually touch... it looks like you've found some information that the client uses.

I still think it will be some field in the table, because I wouldn't hard code a number count of each weapon into a program, I would write the type of item in it's data array. Then again, I wouldn't link that array into the Game executable, I'd keep it as a separate data file, so I could update it without rebuilding the executable. PT is largly written in a way that makes no sense to me, or the training in "good coding practices" that I have ever received. :wink:

hm, ok, what software do u use to find pointers and such anyway? i haven really know how to use ollydbg, still figuring things.

Oh goodie. :D: Check the tutorial sections and Gregoorys' "Let's learn together" tutorials in particular. You will have fun and it will tell you the things you need to know. :) If you get a craving for it, you can check with many Reverse Software Engineering forums and blogs to learn more about the general process. (Most concern themselves with removing nag screens or CD protection locks and reversing registration codes and serial numbers, but many of the principals they teach are the same, whatever result you are looking for.)

There really is no other way to check pointers than to disassemble, and while you can do that off-line (with the executable not loaded into a debugger) Olly is to competent not to use. There are very few debuggers that can compete with Olly's skills, and none that I know of in active development. W32DAsm was good, and SoftICE is still the best kernel level debugger that I know of for the Win32 platform... but AFAIK neither are still in development.

Unless you already know another debugger well, most ppl here use, and write guides for Olly, so I can't think of a good reason to choose another.

If it comes to pure Hex editing, there are many choices... but that alone will not get the result you are looking for here. You would need someone else to do the debug work for you, and provid a guide on how to apply the changes in a hex editor.

oh ya, i always wanted to ask this, when using topo (refers to topo V1.2 thread), the section they add and named as xptable, it automatically gets assigned to be the default exp table in the exe? o.0

Quote:

---

Originally Posted by jjoshh

oh ya, i always wanted to ask this, when using topo (refers to topo V1.2 thread), the section they add and named as xptable, it automatically gets assigned to be the default exp table in the exe? o.0

---

Of course not. That would be far too easy. :wink:

All executable files on Win32 OS are comprised of several "sections". When an executive kernel (the part of the OS that loads a program into memory and adds it to the task roster for execution) is asked to load a binary executable in memory, it has to understand the executable file format. In simple early OS, this may have been a simple flat file containing no external references, not relocation fixups and running single tasked, like a DOS .com file. That really isn't practical on modern multi-tasking OS.

If Windows, or Linux where to use a .com file there would be problems... Each .com file requires the same fixed start and load address... execution begins from the start of the file, and everything fits in a single 16-bit page of memory... Do this in a multi-tasking environment and every program you loaded would overwrite the last one. >_<

So you need to be able to remap the memory addresses of the program to a free hole. Virtual addressing helps this process a lot on modern systems. But we also use a lot of shared libraries to reduce the code per program, ensure compatibility, and increase standardisation accross the system as a whole. These have to be linked into the executable at load time, or dynamically at run time. All of that is the job of the executive kernel.

Windows OS (Win*** WinDotNet WinCE & WinX64, as well as WinPPC & WinAlpha etc) use an executable encapsulation called PE (Portable Executable) based on standard COFF binary format. Microsoft had to change the format, because they already use MZ format in DOS and wanted to keep compatibility. They had also used LE, and NE formats on OS/2 and Windows 2/3 varients which where similar to modified COFF files, but 16-bit.

The primary "sections" in a PE file, are the header, (or group of headers) which describes all the other sections, ".text" curiously where the code is stored, ".rdata" which is the relocation fixup table for DLL import, ".data" where constant declairations and some variable storage is pre-allocated fixed space, and more recently (since NT4) a ".rsrc" section for Icons, pre-configured window dialogues and such can be stored. Prior to NT4, these where typically stored outside the executabe file in a .res file... It was all an attempt to match Apple Mac's Resource Fork without implementing multiple data forkes for individual files to keep compatability with the FAT filesystem.

Okay... those are the sections Windows needs, and knows how to deal with... They are normally created during program build time by your development environments "link" tool, which will take all the static linked code (all the .obj files) and link them together in a single file which is executable on the target OS.

The "make" or "build" process on modern development environments hides a lot of this behind very automated interfaces, but we used to pre-compile to get forward jumps and fix-ups in the compiler. Then issue another command to compile which gave us an assembly listing. We could issue another command to assemble that to get binary objects that we could use with our linker to link into an executable file for our OS. Then, and only then did our program actually load and do something. ^_^

The PE format (and COFF and ELF files for other OSs) allows us to add sections from binary files with any name we like. But to do so in any modern development environment, you would have to alter the standard build process and issue very specific instructions to the linker, telling it to add a section to the executable, give it a name and execution permissions and a prefered start address in the memory map, and point it to the binary file containing the initial data for that section.

Using a tool like ToPo, we essentially un-link the executable into it's constituant sections and fix-up data, then re-link it with a new empty section. In practice ToPo only half does this job, and does it in memory for speed and because it's perpose is very specific, compared to that of a linker. The end result is indentical however.

If you where to do this during the initial build of a program you had source code for, you would either be doing it because you wanted to make changes to the source assembly produced by your compiler, or because you used specific meta-assembler in your source (as can be done in some languages) which addressed this table directly... even though the compiler has no idea what it contains.

It's really not something anyone would ever need to do, but could be desirable in certain situations, if you have a large table of constant binary data you'd rather not turn into C source, or for some reason don't want to use OS mallocs or define a massive array just to get some free memory. This can be faster, because you know the addresses of the data before hand and don't need to reference it against a malloc return, and easier because you can leave the OS to deal with "insufficient memory" problems. But it's still "dirty" and more the sort of thing that hackers, crackers and Demo coders do than something you should add to standard decent coding practices.

So... once we've linked in a new empty section... we can move any data into there that we need more room for, and we can point the code (in Olly) to use it. But you have to find the code that is pointing to the original data, and adjust the pointers to point to our new data section... of course.:cool:

Hope the history lesson isn't too much... but I find looking at how the first wheel was invented, and developed explains why Alloys are so good better than anything else.:lol: