Finding Opcodes
I have been working the past week to try to understand the processes of finding opcodes in an attempt to help fill out some missing ones for Titanium. And, to see if it would be possible to find the Anniversary opcodes without having packet collects from Live when Anniversary was being used.
The wiki pages we have on finding opcodes are far from complete and don't give quite as much information as I would like. Opcode Questions: 1. Are all opcodes 2-way? What I mean is; are the opcodes that the client sends to the server the same ones that the server sends back to the client? I need to know if there is something we actually MUST have live packet collects for, or if everything we need should be somewhere in the client itself. If everything is in the client, then maybe we can find them without using Live packet collects. 2. Do all opcodes change with every release of the client, or do some stay the same? Did SoE purposely change them so that it was hard for programs like MQ, Showeq, and EQEmu to keep up with live? Or is it the source that changes these automatically? 3. What would it take to get the packet collector updated so that it could at least collect opcodes as they came in? Does anyone have the source for any of the Packet Collectors? I imagine that if the packet collector has some logic or filters to pull opcodes from packet sniffs, then even if the packet collector itself would be too much work to get updated, maybe we could use another packet sniffer like Wireshark and just put a filter on it to only pull opcode packets. Using Wireshark, I can definitely see the opcodes, but without already knowing what you are looking for, it would be near impossible to get the ones that are still unknown. My Tests So far: Here is what I did to start trying to find them using Wireshark. Note that this is a learning process for me, so I used one that we are already aware of (Rewind - 0x4cfa): I loaded up Wireshark and ran EQ (connecting to my EQEmu Server, NOT Live) and then I set a couple of filters just to keep unnecessary traffic from showing up. Mainly, I set it to only show UDP packets and also only anything from 192.168.1.101 or to 192.168.1.100, which are my server and client IPs on my LAN. This blocked out most other web or whatever traffic so I was only seeing client to server packets. Then, I got EQ ready by creating a hotkey for /rewind. At this point, I started the sniffer collecting packets, and immediately switched back to EQ and spammed the crap out of my /rewind hotkey for about 30 secs. Then, I stopped the packet sniff so I could analyze. What I found was that the client was sending alot of packets to the server that had the opcode in them, but the opcode was backwards with the FA first and then the 4C, so it was showing up as "FA4C". But, this code wasn't just standing alone, it was mixed in with packets that were mostly 17 in size, but sometimes varied to be even bigger. For the most part, the FA4C showed up right before the last 4 characters in the data of the packet. So, if the packet was (not a real example), "FB 04 16 00 A9 90 00 20 B8 09 C2 85 3B FA 4C 8B 20", then the text in bold is where the opcode normally was (but not every time). More Notes: I can't seem to get the emu collector to run on my PC, even for Titanium. But, it seems to be a problem with it not finding my NIC card for some reason, and not the version I am trying to collect from. But, I think that if I could get it running, maybe it would show all of the missing opcodes we need just by sniffing the communication from emu server to emu client. So, the emu collector packet sniffers might not need to be updated very much to get to the point that they are needed. Though, it would probably be more work to get them updated to sniff Anniversary. Another thing I noticed is that some of the log files actually make note of opcodes, and I think even ones that are unknown. So, the source must have some way to convert these so they are easily readable. Maybe that part of the source could be used to help develop a working opcode packet collector. Idea to get Anniversary Edition working: My idea for Anniversary is that if we had a working sniffer that can see the opcodes and pull them out so they are easy to find, then we could use a step-by-step process to get anniversary working. By that, I mean that we could start an Anniversary client while already running a packet sniff and then collect the opcodes as they come in. It will get to a point where it fails, and we just find the opcode before that and figure out which opcode it is and add it to the .conf file and then start again. Basically just trying over and over until it gets logged in. Then, it is just figuring out the commands and what not, which should probably be much quicker since you shouldn't have to restart every time it fails. Another possibility would maybe be using IDA Pro to check the code of the client for opcodes listed. But, so far I have been completely unsuccessful in finding even a single known opcode in there. And, I have done quite a lot of searching and research. Though, my understanding of disassembly files is still very weak. If I could figure out how to get opcodes this way, I think it would make this a piece of cake. Some references I used when researching how to find opcodes: Method for hacking from the hackersquest forums that has some good disassembly information: http://hackersquest.org/boards/viewt...ghlight=opcode Page in the wiki for finding Opcodes, that I can't really make much sense from at all: http://www.eqemulator.net/wiki/wikka...vOpcodeFinding ASM Hunting: http://www.eqemulator.net/wiki/wikka...DevAsmRoutines Assembly Tools and Information Links: http://www.eqemulator.net/wiki/wikka...ka=DevAsmTools HexVis - A little tool for converting hex or other data to different types of output: http://www.eqemulator.net/wiki/wikka.php?wakka=HexVis To convert Decimal to Hex, you can just use windows Calculator and set it to Scientific mode. Then, put the number you want to convert and change the radio button to hex and it automatically converts it. Also, the eqstr_us.txt and eqls_us.txt both have some information in them that may relate to opcodes and could help in defining what the opcode itself relates to in the code. The hackersquest post above mentions the lines in these files. Though, I haven't been able to find their related hex versions in the ASM of the eqgame file. If anyone out there has info that might help this process, please respond here or PM me. I am sure we could all appreciate a working Anniversary edition, and it would be worth the work to get to that point. Once we find a good procedure for it, I don't think it will be too bad to get these. But, for now, I am still trying to refine a way to actually gather the opcodes without having to do too much guessing. |
After doing a bit more research on Anniversary Edition, it seems like we might be almost too late to use it to put a lot of work in getting an updated version of the emu working. It seems like copies are still easier to get than Platinum, but apparently many stores have already stopped selling the Anniversary Edition and it can even be a little hard to find any online. I am sure it will get even harder soon.
Here are some links to places that should normally be easy to get games from: http://www.newegg.com/Product/Produc...82E16832135022 http://www.ebgames.com/Catalog/Produ...spx?sku=647003 http://www.amazon.com/Everquest-I-Th...4879400&sr=8-1 As you can see, it appears that the games aren't being shipped much if at all anymore. It seems like they are just trying to sell off remaining stock and that will be it. I don't quite understand how SoE expects people to get their game if it isn't on shelves or even available to buy the CDs online. I don't suspect that everyone would want to just get a downloaded game file to play it. The only way I see to reliably get the game is online from SoE directly as a download only. But, we would need to decide on the version to find opcodes for so everyone could get it. https://store.station.sony.com/ Click on Everquest under the Digital Download section on the lower left. Then, you have to login and you should be able to click cancel on the subscription section. That will take you right to the digital downloads. I am wondering if those are just standard unpatched downloads, which I imagine they are. If so, then for 20$ we could have the option to go with the ""Starter Pack" which seems to be the exact same thing as Anniversary Edition. Or for 40$, we could go with "The Serpent Spine All-In-One" package that includes every expansion currently out. If I can figure out how to find opcodes well enough, I will either just get a copy of anniversary, or maybe one of these download packages and start working on finding the opcodes right away. Though, I would prefer an actual CD pack so we don't have to worry about SoE changing the opcodes by changing the versions of the download files. Maybe they will have another CD release soon :P |
From what I recall, vaguely, they downloads are, or at least used to be, unpatched versions. They don't update the downloads.
|
We use a protocol similar to the one used in eq2 I believe though it really isn't documented anywhere outside of the code. It's kind of difficult to put together via the code because of the layers of abstraction on abstraction. It would just be a matter of decoding the packets further to get them to load from something like WireShark.
Usually the opcodes change from exe version to version though some don't; sony does seem to like to change a lot of the ingame ones every patch; probably to hinder stuff like showeq. Usually if the client sends a packet and expects a direct response packet for it they will use the same opcode; example would be pickpocket or click object. It's a shame nothing ever came of openeq and we still have to deal with this. =/ |
Heh KLS... this sounds hauntingly familiar.
|
Sir, I thought I was leaving you alone with this!
Anyway basically the packets are encrypted or compressed, there's a flag on the session request for the stream that indicates which it will be; I believe it can be both as well. The server generates a key to send to the client to decode the data as well. You have larger packets that make up the protocol, things like session requests, whole packets and combined packets etc. Contained within can be the smaller packets, encoded with the key sent from the server etc. I think we send the key always as 11223344 but obviously were you to do this from live or something you would need to retrieve the actual one to decode the data into readable packets. in common/EQPacket.cpp there are several functions that deal with compression and encoding of the data as well. |
Thanks for the info KLS, it seems like it has been a while since anyone has considered taking on opcodes and I wouldn't mind giving it a try as long as I can find a viable option for it.
Here are some code sections from the source common directory that just skimming through caught my eye as being related to helping find opcodes: packetfile.h - Guessing this holds the string you were mentioning that the server sends the client, maybe? Code:
#ifndef PACKET_FILE_H Code:
#ifndef _EQPACKET_H Code:
#include "debug.h" Code:
#copy this file into your server's dir Code:
#!/usr/bin/perl Code:
#!/usr/bin/perl Code:
#ifndef LOG_CATEGORY It would also be nice if that was working and you could somehow filter out all of the known opcodes, so only ones you are looking for (unknowns) will show up to make finding them much easier and quicker. Then, once we were able to get enough opcodes to get a client logged all of the way in, the rest would probably be pretty easy. |
Hmm, I may have answered my own question about using the logs to find opcodes. To watch them as they come in, simply open a terminal window in Linux and type:
Code:
cd /home/eqemu/server/logs Unfortunately my other PC is windows only, and I don't know how to do a tail in windows so I can grep for OpCodes only. So, I may have to build my other PC as dual boot to Debian Linux. Unless I can figure out how to run another server from the same PC I run my main server on. So, I will have 1 that only I can use. Maybe if I make another directory and set the config to use different zone ports... I dunno, but I don't think it would talk right on port 9000 with both server sessions wanting to use the same port to communicate with the login server. |
Looks like I might be able to do this on my server even with players on it after-all. This tail shows the name of the char that sent the opcode, so if I am testing, I will just look for my own.
It has already found a few unknown opcodes from my players and these seem to be somewhat common. OP_Unknowns: 0x6a5f 0x45ff 0x7085 0x3b21 0x1241 I will do some testing tonight to see if I can force it to produce more opcodes and hopefully get some of the unknowns defined. I will let you all know of any progress I make. If this actually works, it is far easier than I could have ever expected lol. Maybe I was thinking too hard, but I imagine that if it was this easy, someone else would have been using this method already... |
I took a quick peek into the source, and it looks like this is where those OpCode errors you found are spit out:
zone/client_packet.cpp: Code:
375 case CLIENT_CONNECTED: { Code:
337 #if EQDEBUG >= 9 Code:
15 DFLAGS=-DEQDEBUG=5 -DCATCH_CRASH -DNO_PIDLOG -DSHAREMEM -DSPELL_EFFECT_SPAM -DFIELD_ITEMS -DCOMBINED -DAPP_OPCODE_SIZE=2 -Di386 |
I put some code into the server just to see how the code works further. To analyze live packets I believe you would need something to analyze the entire stream; or at least the session request since right now it appears the client receives a key from the server used to encode and decode.
Right now the emu always sends back: 287454020 which is (0x11223344), I actually added some logging to see what it was since the code has no commenting and can be kinda hard to follow at times, so I guess I got that part right the first time. Basically: Client creates protocol packet of OP_SessionRequest Code:
pragma pack(1) Code:
pragma pack(1) Client <- OP_SessionResponce <- Server the uint32 key is what we use to decode the packet if the flag for encoding (0x04) is set in format, and clearly the session would be the session id, format is the bitfield to store the encode and compression flags for the stream. I'm still trying to understand it myself though, wtb code commenting -.-. Oh yeah, also if we're trying to find a client -> server opcode that's pretty simple because you can just have it dump to log or terminal over the emu as stated above but a lot of the ops we're missing aren't client -> server and the ones we are is because the functionality hasn't been implemented and if it were finding the opcodes wouldn't be an issue obviously. |
Here is what I have found so far just from running the tail I mentioned above. I am sure some things I have tested must be sending opcodes in another format or something, because they don't seem to send the server anything even though I think they would be unknowns. One example would be when you right click an adventure merchant. Unless the opcode is just assigned to the wrong OP_ name in the .conf file for it already. Then, it wouldn't be getting logged by my tail, because it is currently only able to see opcodes that error for one reason or another.
Errors (unhandled): 0x381d - OP_WeaponUnequip2 - unequip weapon 2 or unequip weapon 1 0x63da - OP_WeaponEquip2 - equip weapon 2 0x6c5e - OP_WeaponEquip1 - unequip weapon 1 0x63da - OP_WeaponEquip2 - equip weapon 1 0x6c5e - OP_WeaponEquip1 - equip weapon 1 0x6f0c - OP_Bandolier - Added and named new bandolier name - same when bandolier is used to swap weapons 0x1ee9 - OP_BazaarSearch - /Bazaar Search or clicking "welcome" on the /bazaar window 0x5891 - OP_RaidInvite - Invited a player with /raid - got some packet info as well 0x6f82 - OP_LFPCommand - Shown on the player when they accepted group invite 0x7f9d - OP_Report - /report playername 0x5306 - OP_Feedback - /feedback and filled out a feedback and hit send. Got some packet as well I know that unhandled doesn't mean there are problems. But, in some cases, it might be useful to have the notes I made just in case someone decides to write some code to handle them. Unknowns: 0x524e - Begin /trader mode or Closed /trader window even if Begin Trader mode hadn't been started (on off toggle?) 0x6a5f - Comes in after not moving the mouse for exactly 15 minutes. And comes in again as soon as the mouse is moved again - Toggle Auto-AFK? 0x19d8 - /viewpetition command ran 0x5fc7 - Clicked "View Stats" on the Adventure Window - Same for clicking the Refresh button there 0x230a - Clicked "Leaderboard" on the View Stats Window for LDoN Adventures - Same for clicking the Refresh button there 0x48fe - Used the "Who" button in the friends window - Same for typing /who all friends or friend 0x224c - /zone command 0x35e8 - Right click a player in /becomenpc mode in bazaar (basically trader mode on) 0x3d05 - /veteranReward 0x5eba - Used Shift+T to open the Titles window And some of these probably aren't considered issues, because there are no systems in place for them. But, I am sure someone would love to get bazaar working, and Titles, and the petition manager window would be nice too. Also, I didn't even know EQ had an auto-afk feature, but that one opcode really seems to be auto AFK. It comes in exactly 15 minutes every time after the mouse hasn't moved on that window and comes in again as soon as it is moved again. That would be a cool feature to have IMO. Notes: Starting trader mode by opening the /trader window and setting items for sale in a Trader's Satchel didn't make my character show up on the /bazaar search window to be listed under "Traders". BUT, using /becomenpc on myself changes my name to add "Trader" in front of it the way that trader mode is supposed to on Live. Then, once I had /becomenpc on, I now showed up as a trader in the /bazaar search window. It still wouldn't list the items I had for sale from the search results though. I will continue looking for more opcodes and I am going to mess around with other versions of EQ as well to see how difficult it would be to get them working for the emu. If most of the opcodes to get another version of EQ working can be attained with the tail I have been running, then it really shouldn't be all too tough. I still need to check into those IDA Pro scripts as well to see what they do and if they are still useful in any way. I guess some progress is better than nothing. Might as well get as many opcodes in place as possible, so if someone wants to write code to get the systems working, they can do so without worrying about opcodes. |
the SWGemu people have a pretty decent writeup of the basic UDP transmission protocol sony uses for apparently all their MMOGs. Including a section on encryption, definitely easier to understand the code after reading it. I think it may differ in the footer a bit from the protocol sony uses in EQ, but it's similar enough to give a good idea of what's going on.
http://trac2.assembla.com/swgemu/wiki/Packets |
It's really really close actually, I wrote a small collector today that can identify separate streams and reveal their relevant information. Can't decode packets yet but hey that stuff's hard for an afternoon of work. Trying to devise a system for combined packets doesn't sound very fun at least since they can be combined as many times as the client wants apparently.
|
Unless I am mistaken, it looks like any change to the .conf files requires a server reset to take effect. Or, is there a way to do it via command or something without a complete reload? That would help quicken things up. Especially since I am testing on a live server with lots of players.
For anyone wondering if the Digital Downloads from SoE are a packaged set of files, I wanted to clarify that they are NOT. I went ahead and purchased the 20$ digital download "Starter Pack", but it didn't give me any actual link to download a package. The only way I was able to get the new files was to use the new beta sony patcher, which unfortunately patches to live. So, it looks like we are currently stuck with Anniversary Edition as being our only option for upgrading the emu unless we want to chase live, which is probably very unlikely. It is unfortunate that the Anniversary Edition is already almost as hard to get as Titanium. Very few stores still have copies on the shelf and many don't even sell it online either. Though, if someone wanted a copy, I don't think it would be too hard to get just yet. And, thanks KLS, for working on this. If you can come up with something, I am sure it would make a big difference and help the project to keep moving forward. I am still investigating the opcodes as well, but your knowledge and experience far exceeds my own lol. |
#opcode should reload all opcodes
|
Well, I tried #opcode and it doesn't seem to reload any saved changes to my .conf files for opcodes. I still get an Unknown message about opcodes that I have assigned in the config file and saved.
|
yeah my mistake it's #opcode reload it should give you a client message about reloading all opcode patches.
|
Thanks, I actually just found that out while experimenting a little after posting that lol. Was just about to come and post the correction.
After figuring that out, I was about to get /zone to work for GMs instead of only #zone working. Here are the changes to get /zone working. Still working on figuring out more. Code:
#GM/guide opcodes |
That's awesome Trev. I hope that I can get some free time soon - I'd LOVE to come help with OpCodes, it was the last one thing for which I had been trying to make time.
Keep rocking it out, THESE are the things that have been holding back this project from becoming polished. Muchos Kudos! Dax |
Took forever to figure out the correct byte order to get everything to work but finally got the CRC working on live packets and if I can CRC them I can decode them... eventually.
Code:
Request session reply(0x0002) found, stream between You and |
Ooh, nice! Sounds like a very nice start. What are you using to get the packets from live? Wireshark?
Then, you are running a script to decode the packets? Whatever it is, it sounds like a very handy tool when it is complete :D If I had your knowledge, I could do some real damage :P For now, I will just keep fumbling around and researching. I imagine that getting the friends list and maybe even titles working wouldn't be way too hard. I think I have all of the needed opcodes, so it would be a matter of pulling out the names that are sent for the friends list and doing a who query on them for the client. And for Titles, I imagine we would need a new table that includes the Title name and multiple fields for requirements to meet (like total AAs, etc). I know friends list and titles seem small, but every little thing adds up IMO. I know that one of the main ones everyone wants to see working are LDoN Adventures, including the points and merchant systems. This would probably be considerably more complex to get working. I think bazaar would be a really cool one as well. And, I don't even think bazaar would be all that hard to get working. Mainly, everything that /becomenpc does is what turning /trader mode on needs to do. Then, just have a table for items for sale, and maybe gather a couple more missing opcodes for purchases and stuff. Still, getting any of these system working is over my head. Eventually I hope to understand the code well enough to get at least some working. I have already learned quite a bit since I first started looking at the code. |
I used pcap; in this winpcap and just made my own program; hardest part was getting emu code to work outside of the emu(could use some portability) and figuring out that ntohl() can change the byte order of const* data if I'm not careful. -.-
The biggest problem probably isn't the opcodes; even on titanium there's only a few opcodes missing here and there, changing structures is what is really hard. And is also why anniv is stalled; we have the opcodes to get in to the game but once you do everything is messed up because the structure of packets has significantly changed. |
Ya, I figured that the packet structures were changing and causing issues as well.
So, if we do ever start working on getting anniversary edition or another version of EQ working, we have to update the opcodes in the .conf files, but we also have to update the /common/patches/<client version>_structs.h? Looks like maybe the /common/patches/<client version>.cpp might need to be updated as well. In general, are the packet structure changes a complete restructure, or just minor changes that still keeps most of the previous packet structure in place? Or would the entire structure need to be redone from scratch for any that change? Last night I made a discovery that I am sure some of you were already aware of, but I wasn't and I thought it was worth mentioning here; ShowEQ is still being updated and is current with EQLive! I had just assumed that ShowEQ was abandoned in 2003 or 2005 and was replaced by MQ. I know that much of the info in the opcodes .conf files was attained from ShowEQ. So, wouldn't ShowEQ be a useful tool in finding Opcodes and maybe packet structure as well? I would think that it might be a good packet collector for this project, but I could be wrong. Maybe even some of the source code in ShowEQ could be useful in updating the Emulator source to work with later versions of EQ. I haven't found an archive of ShowEQ versions, so I don't know if there is a version that might work with Titanium or Anniversary Edition. But, I think the current one could be useful in maybe getting fully patched version of EQ working with the emu. ShowEQ has install instructions for Redhat and Mandrake, but I run Debian, so I am still working to get it to compile properly. I have been able to get the ./configure to run, which is supposed to auto configure so that the make will run without errors, but the make is still erroring on pcab stuff. I will keep messing with it. Hopefully, once I get it running, I can find out more info on if it will be useful for this project or not. I have already pulled many of the opcodes in the current Live version of ShowEQ and put them in my live.conf file. But, I haven't reset my server yet to see what results from that. I am trying to look in every direction possible to find a helpful solution for getting the emu updated. Ultimately, I think it would be best if I could understand the output from IDA Pro, but I can't make much of that yet... So, I am trying it from other angles until I learn more. Here is the link to the showeq website: http://www.showeq.net/ It includes a link on that page to the current version of the source. |
Quote:
Quote:
|
Thanks for the input AndMetal. I saw that post, but I guess I forgot about it lol.
I was looking for packet structure as well, because I assume they have to have at least some of it defined for showeq to be able to read data packets and pull what they need from them. From what I could tell, they do seem to have some kind of packet structure code, but it is done in a completely different format that what the emu uses. Someone with more code knowledge would have to look into that to see if there is anything useful, because I can't tell. Though, they did seem to have some info on systems that the emu still needs to get working, like bazaar, ldon, titles, and others. I did finally get showeq running on my Debian box, but I need to move both PCs to share a hub so that the packets can be sniffed and I didn't want to do that last night since it would affect my players obviously. I will try to put a hub in the next time I reboot the server. Then, I can get a look at what it shows for Live at least. And see if there is anything useful coming into it. I would still like to find the source for one of the eq packet collectors that were developed to help find all of this stuff. Maybe the packet decoding, compression and other stuff from the showeq source could be used to update the packet collector. |
Talked with fnw a little bit about this in regards to live he listed 3 steps that he would take to find out opcodes and structures for any given client:
1: Steal from showeq 2: eqopfinder used to be good at finding recognizable packets once you had a good foundation and that the info gained from showeq was probably enough. 3: after that just digging through logs with collector and trying to identify any OP_Unknowns. Of course how well these methods work now is up in the air as well ...it's been a while. |
So, other than eqopfinder, I think we might be on the right track so far. If only I could make heads or tails from the SEQ source for packet structure lol.
|
/keys appears to be 0x68c4. I don't see it in the Titanium Opcode file.
Also, /emoteworld and /delcorpse appear to have the correct opcodes, but do not work. |
Quote:
The main current issue with the /blahblah client commands (as far as GM level commands) is that they're all flagged at the same level within the source. That is, if you can /zone, then you can also /summon. You would also be able to /delcorpse and /worldemote, etc. At some point, those client commands needs to be added to the commands table (or possibly a separate client_commands table) where permission levels can be assigned more granularly. Dax |
This thread delivers.
SEQ should be an excellent source for opcodes, but I wonder about the structures. Would SEQ even be interested in the structures for, say, bazaar or ldon stuff? Isn't SEQ just interested showing you mob pops, loot drops, etc? If that's the case, there's a fair chance they wouldn't implement any of the data structures since they wouldn't have a use for it. |
They'd have the hard to find structures like player profile and spawn structures. (They tend to change a lot from patch to patch.) Things like ldon could be figures out via packet collecting and viewing. Though I can't get the packet collector to compile nor the pre-compiled to work. =x Guess I get to keep making mine.
|
Quote:
What I did was to run Wireshark on my PC, perform the actions I wanted to collect, then stop the capture and save the packets as a .pcap file. I then transferred the capture file over to my Linux box and ran ShowEQ in replay mode: showeq --playback-tcpdump-file=/tmp/livecap.pcap --log-zone --zone-log-file=/tmp/livecap.txt Once the GUI has loaded and processed the capture, quit and you have a text version of the capture in, e.g. /tmp/livecap.txt Code:
[OPCode: 0x0e98] |
Oh, nice! I will definitely check that out. I already have wireshark and showeq setup, so that wouldn't take much to get going. I guess I better do it soon before the free live thing stops lol...
I still plan to work on Opcodes, but have been pretty busy the past few weeks with RL stuff. Hopefully I can start going on it again really soon :) I know it could make a big difference for the project if we can get more systems working and things like opcodes and packet structures figured out. |
Here is a quick and dirty tutorial on how I found the OP_Charm opcode for Titanium, based on information in the Wiki on
disassembly using IDA. Requirements: The 6.2 Client, The Titanium Client, and an OpCode that is known for the 6.2 client but unknown in Titanium (this is what we want to find). Download IDA Freeware 4.9 from: http://www.hex-rays.com/idapro/idadown.htm Fire up IDA, Select 'New', Select PE Executable, then navigate to your 6.2 eqgame.exe, then let IDA analyse it. This will take several minutes. It will say 'Idle' in the status bar when it has finished. In 6.2, Opcodes are handled in the 'Dispatch' routine at address 45A8B6. To Jump to this address, press G and enter the address 45A8B6. The routine looks like this ( I added the comments down near the bottom): Code:
.text:0045A8B6 We know that for 6.2, OP_Charm is 0x10A1, so the first test that will pass is, is opcode > 0x0A2A, and we jump to loc_45AB94. Move the cursor over the loc_45AB94 in the ja instruction, right click, and select jump to operand, which takes us to 45AB94: Code:
.text:0045AB94 loc_45AB94: ; CODE XREF: sub_45A8B6+77j loc_45ACAC. (Jump to operand as before). Code:
.text:0045ACAC loc_45ACAC: ; CODE XREF: sub_45A8B6+2E5j 0x10A1 - F66 - 9E - 9D = 0, so we jump to 45AD58. Code:
.text:0045AD58 loc_45AD58: ; CODE XREF: sub_45A8B6+413j Code:
.text:00457270 sub_457270 proc near ; CODE XREF: sub_45A8B6+4A3p Now we need to find the same routine in Titanium. Close IDA and start it up again, this time selecting the Titanium eqgame.exe. Let it do it's thing for a few minutes. When IDA is done processing, our goal is to find a routine in the Titanium client that looks the same, or very similar to the one above. In this case, what I did was search for the 'immediate' value, 0x1B3. Press Alt-I, and enter 0x1b3 in the search box. After a few seconds, a list of matches will be displayed. What we are after is one that is: Code:
cmp byte ptr [ebx+1B3h], 0 after. Double click on it and it will take you to the routine. Scroll up a bit and it looks like this: Code:
.text:00453D7B sub_453D7B proc near ; CODE XREF: sub_45B8F0+D1Dp Now we need to work our way backwards. Click on the 'Sub_453D7B' which precedes 'proc near', and then press the X key. This will produce a list of locations that this subroutine is called from. There is only one place, so double click it, and it takes us to: Code:
.text:0045C60C loc_45C60C: ; CODE XREF: sub_45B8F0+BD0j from (just the one location). Double click on it in the result dialog box. This looks more interesting. Code:
.text:0045C4BA loc_45C4BA: ; CODE XREF: sub_45B8F0+B6Fj charm routine if the result is zero. We could continue moving back through the call tree to find if there are any other subtractions being done on the opcode value, but in this case there isn't, 0x12e5 is the opcode for OP_Charm in Titanium. |
Very nice! Much better info than what I was seeing in the Wiki itself lol. So, by using that same logic, I imagine that the known opcodes in Titanium could be used to find opcodes for anniversary or even live. It sounds a bit involved and I don't know much about looking at the IDA output yet, but I think If I can get the hang of it that it might start getting easier.
I guess we would still need to figure out packet structure, and other than packet sniffing, I haven't seen it done really. SOE just needs to give us a peak at their source hehe :P |
As long as Sony doesnt change compilers or their C code for handling Opcodes, you could make what ya might call templates that could easily find any opcodes.
You take the current client, look at the hex before and after the opcode and build these templates to quickly search for new opcodes. Template for a opcode would be like HH HH HH ?? ?? HH HH, where HHs are the common hex codes and the ?? are the unknown/possible opcodes. Then you search the new client using these templates. |
Quote:
|
All times are GMT -4. The time now is 07:48 PM. |
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.