Issue with using Ollydbg with ROM

[openstrife]

I have been trying to figure out how I can use Ollydbg with ROM to try to find where the Winsock Send function is called, so I can hopefully locate packet data before it is encrypted. I originally tried modifying the packets with WPE but soon realized they're encrypted.

I've read around that if you can find the send function, you can trace it back and modify the packet data before it is sent by breaking on when "Send" is called.

The only issue is, I can not get Ollydbg to breakpoint when Send is called. Typically this Send would be called whenever you move, rotate screen, or send anything in the chat, as well as with casting spells, etc. When I try to do is in the command line for Ollydbg type "bp send". I've seen this work in another guide with breakpointing the send function... but it has no effect when Olly is attached to RoM.

I only recently installed Ollydbg, and I have been running it as administrator.

Sorry if this is the wrong place to be asking this, but after searching all day on the net(literally), it seemed to me that this forum would be the most suitable place for my question, at least, it seemed to have more people on here who know what they're talking about xD.

Any advice is great... and if you know anything about sending packets with WPE like you can in WoW... then please say.

Thanks c:

Edit:

I can only seem to get it to breakpoint on the send function at login & the char select screen. Everything after that when I am in-game, it doesn't really breakpoint anywhere as if the send function isn't being called.... but WPE says otherwise. WPE shows it being called many times even with a slight screen rotation. How come Ollydbg doesn't pick up on this?

Edit:

I managed to figure it out. 'Send' only seems to be called before you're in game. After you're ingame only WSASend is called. Now comes the hard part... finding the point in the assembly before the data is encrypted... If you have any tips, please say.

[Administrator]

Good luck and keep us updated. I remember messing around with this a few years back and ran into exactly the same issue you did. I completely forgot about how the game used WSASend().

What, exactly, are you attempting to do? In my project, I think I ended up hooking the function and modifying it's contents.

[openstrife]

Hi ,

Ultimately my end-goal is to hook the point right before the packets are encrypted so perhaps I can step in and modify them before they are encrypted. The client I find has a lot of checks in it preventing you from modifying certain values then sending them. Modifying these values then performing certain actions can cause the client to instantly freeze before the packet can even make it out. Though if you were to modify the packets after the client has verified them... there's so many things that could be done, which I'll leave to your imagination.

Firstly I just want to successfully modify a packet just before it is encrypted. If I can get to that point, then I will continue on. Then later maybe make some program that behaves in a similar manner to WPE... though instead of modifying the packets after they are encrypted, do so before hand. I've only been using WPE for a few days, do you know if there's a way I can hook it to the pre-encrypted packet location(after I find it) instead of it's current?

As of recently, I have spent the past several hours following assembly instructions from where WSASend is triggered, literally trying break points on what I think was hundreds of different related lines... but I could not at all find the unencrypted data. I've been following this as a guide: [Can't post link, but the tutorial is called "Packet Hacking and Reversing HASH1 in mmo Water Margin"], It's taught me a lot but I'm at a dead end.

I can't convince myself that the encryption is too difficult. I've read many sources saying it[RoM Encryption] is very weak. Many of these people claimed to have found & hooked that unencrypted point easily, which I cannot seem to do myself.

[Administrator]

Once you open client.exe with Olly, right click the CPU window and Search for, Name (label) in current module. Find WSASend() in the list, select it, press ENTER. The new window shows you every instance of WSASend() being called. Start with the 2nd or 3rd instances; those look promising to me. Analyze (CTRL+A) the client, scroll up to the start of the function, and right click it. Go to, CALL FROM xxxx.

If you look at some of the strings there, you'll find some interesting stuff. You may have to go back a few levels, but I think you get the idea.

[openstrife]

About 5 instances came up. Break-pointing the 3rd one causes the game to pause(for the break point) every time I send something. All this did was show me the spot in the disassembler that I already knew WSASend was being called. From that single point I probably tried to break point the next 100 lines before and after that point in an attempt to find the unencrypted spot. All of them yielded gibberish in the Hex/ASCII dump. A large number of them that I tried to breakpoint on worked as a break point but alas, no unencrypted data.

Am I missing something here? Out of the 5 instances in that list, only the 3rd one works as a breakpoint for when I send messages, cast spells, or move my character. Have I maybe already passed over the unencrypted location and not looked in the correct spot?

Edit:

And I could never find "CALL FROM ...." (when searching about 100-300 lines up from the break point instance)

Edit:

Ahh Okay I figured out the CALL FROM thing, though, how do I identify the top of the function when scrolling up after I have analyzed it?

[Administrator]

Ahh Okay I figured out the CALL FROM thing, though, how do I identify the top of the function when scrolling up after I have analyzed it?

The functions will have braces. Follow the brace to it's top.

[openstrife]

Oh when you said scroll up I figured you meant an amount greater than the 5 lines of the function :p.

Here's a screen shot of where I'm at now. I don't see the CALL FROM .... anywhere. I also have breakpointer'd and followed each piece connected to this and none lead to any unencrypted text.

http://oi50.tinypic.com/3462786.jpg

[Administrator]

I see. It's not picking up the bounds for that function; the brace should be on the left.
Anyways, that function starts at 0x6EBD60.

[openstrife]

Good Catch, that off the top of your head haha c:?

I stumbled upon that 0x6EBD60 SUB ESP,1C earlier and did a lot of breakpoint and follow play with it but I couldn't find it to anywhere unencrypted. As of this point I'm just lost and taking shots in the dark hoping I get lucky.. :/. I feel like such a noob lol....but I refuse to give up. Figuring this out is the only thing on my mind.

[openstrife]

Okay so I managed to trace the function back to where it is called from...
Though it seems every single thing I follow backwards from this point has to do with game functions other than the packets. Typically when I have a breakpoint on the packet-related functions, the game will only break when I send a packet through or during it's periodic checks which it does randomly every couple seconds(with packets).

All of the functions/calls before this point freeze the game constantly, what seems to be every single milisecond. So because of that, I can't really do any packet checking if I can't send any 'controlled' packets out of text in the chat to check. I've been tinkering with this case 3 for a while but no luck finding any unencrypted data. The cases before it seem to have to do with WSARecv & Other game monitoring functions.

The only theory I can come up with right now is that the packets get sent to this point already encrypted(or so I believe) along with a flood of other data. It seems this constant stream of mixed up data is being fed through these cases so it ends up in the right spot....Now I haven't the slightest clue how I can backtrack through those to find the source of where the packet data comes from.

[openstrife]

I figure I'd continue to update this on some of my findings...incase anyone finds a way to chime in.

After further probing, I have come to a few realizations(referring to the picture in the above post)

The above cases have to do with the general handling of packets. The packets are fed through the case check & are sent to the correct destination based on the packet size. With the use of WPE I noticed that all outgoing packets were of select sizes. Certain sizes indicate RCV packets and others Send.

Case 3 is what I am calling the GameSend function. All send packets go through here
Arg4 = Packet Size
Arg3 = 568 - This seems to be very consistent. I have not noticed a different number go through there and it never seems to change.
Arg2 = Address to where the packet size seems to be. I should note that each ingame action has it's own packet size. Casting spells has their own, jumping, etc. Cannot find any other relevant packet information in this address.
Arg1= Address that appears to be empty. Nothing appears to enter it.

This is as far up as I can go. I can't go up any further to any previous functions because the break-points seem to hit every other milisecond. It is only in this Case 3 where the WSASend packets are passing that I can tell.

This also leaves me with another issues. I believe at this point the packets are already encrypted. If this were not the case then I would be able to find the raw-packet data with a simple cheat-engine search of whatever I put into the chat, right? Please correct me if I am wrong. If I had a way to breakpoint the code further up only on the send packets then I could just use cheat engine to find the raw-data location by searching for my packet data.

One thing that bothers me is that if I type any text into my chat, but do not press enter, and then I try to search for that text in cheat engine, it does not come up anywhere? How come? It definitely should I think. If it's already visible typed in the client waiting for me to press enter, then I should be able to find it in the clients memory? Perhaps could this explain why I am unable to search for the data after I press enter to send it? Maybe that data is stored in the same location as the data I type, but don't send. If this was the case, then there is a possibility that the data has not been encrypted at Case 3. This just leaves the question as to how to find it.

One other thing I noticed is that following through after-case 3 seems to show hundreds and hundreds of data flowing, some of which I believe to be the encryption process, though probing around it doesn't seem to show any evidence that it is. Perhaps someone else can chime in off these ideas?