Reverse engineering

So, I didn't really expect to make this thread. But, in case anyone cares, I've decided to try and reverse engineer specific parts of the NFS:W executable, including:

- UDP checksum validation (unless someone figured that out)
- WTH do the different values in the freeroam packets mean?
- How does the P2P system that is mentioned in the code work? (If there is one)


This is the first thing I've ever tried to reverse engineer, and it's going fairly well so far. I'm finding a bunch of debugging statements, which leads me to think that I can find the actual code near them.


This is also my first time using IDA on an actual executable. I'd say I'm doing fairly well for a newbie.


I'm not sure if anyone actually cares anymore. I just figured I'd let people know what I'm up to (because I remember I was talking about my freeroam project a few months ago; this has to do with that, and yes, i'm still working on it)

TL;DR I'm trying to figure out various parts of the game, and see if I can make any important discoveries.


~ Leo

EDIT ONE: Found some debugging statements, NFS:W's custom networking library seems to be called PacMan; handles races, P2P, and some other stuff, it seems like.

Nice. I do care about it.

Once you get the info, I will help to make it happen.

Alright, thanks! Maybe I'll actually find something useful :D

Sorry for the double post, but I'm not sure if mentions are processed when a post is edited.
@[Only registered and activated users can see links. Click Here To Register...] I know that you have some experience with reverse engineering, perhaps you could help me with a little problem I'm having. I know about the IsDebuggerPresent calls, and I attempted to disable them, but once I try to run the game, it just exits and IDA says that a bunch of messages with a % were logged.

I'm using the local Win32 debugger. How did you get it to run? I'm sort of stuck.

Alright, just a little update. I've been messing around with the current UDP server, and it appears that the game will not display players on the map or in the world if the freeroam packets take too long to come.

Basically:
> put a very short delay between packets, the game sees the data and accepts it, but lags a bit
> put a slightly longer delay, lags a bit less
> put a delay longer than, say, 450-500ms, and the game just ignores the packets


I'm not quite sure why this is. If anyone can provide some input or advice, it would be greatly appreciated.

Update: it seems like all freeroam UDP packets from C->S start with the same three hexadecimal numbers/bytes: 78, 31, c1; content varies

server responses seem to start with 40, 8d, 5c; content varies

That guy deserves a some likes atleast! So, all that people, who get a working online, have a ping less than 400ms...

The latest: I think I've managed to collect a few examples of freeroam packets that are delivered to the server. I'm not completely sure, but based on what I saw, they do appear to have something to do with the player.

What I've been able to figure out:

• the game sometimes won't send freeroam packets for a little while. I might just be forgetting to turn on the server though.
• Pretty much every packet the client sends starts with the same bytes: 78 31 c1 be 3d 16 40 8d 5c

I'm going to try sending fake packets to the client, with dummy data, to see what happens.



Anyway, have a few pictures!


[Only registered and activated users can see links. Click Here To Register...]


[Only registered and activated users can see links. Click Here To Register...]



(If you don't see anything special in the picture above, look at the highlighted area + the arrows. That data is most likely a free-roam packet.)

This: 78 31 c1 be 3d 16 40 8d 5c is part of hello packet. Game start sending position packets when server send hello-ok.

@[Only registered and activated users can see links. Click Here To Register...] that's what i figured. it seems to send quite a few hello packets though before the server finally accepts it, not sure why.

I still have to figure out why players will sometimes totally vanish from the map if you move them.

The latest: I'm going to try a slightly different approach at this; instead of rebroadcasting every single packet, make it random. To do that, I'm just generating a random number out of 1000, and if it's divisible by 10, send the packet back.

Let's see if this works.

UDP checksum is a pain in the ass.

ASLR address: 767B80 -> almost always ends up on:
.text:00767BF4 jmp .text:00767BFF // modified for no checksum

There are at least 3 gateways, which I presume to be a fast-fetch type of structure (a.k.a. a switch in modern languages). This part of NFS:W has proper language semantics implemented and probably was mangled by hand. Odds are they are left over from BlackBox beta times, as almost everything is.

I was gone for a while because of, well, Turkey. Even GitHub was blocked for like a week recently, don't know what the fuck is even going on to be honest.

If you want to debug NFS:W with flashtraces or local debug lines, find and disable:

1. Injection check loops (there are 2)
2. WinVerifyTrust
3. CheckRemoteDebuggerPresent
4. IsDebuggerPresent
5. Module name check (EnumProcessModules)

You can disable interference checks (2, 3, and 4) by just nulling their imports. When you are done, modify the assembly to make it "BuildType.Debug;NotOptimized;Level.Debug", then you can read everything with Dbgview.

@[Only registered and activated users can see links. Click Here To Register...] Might need help finding the loops but everything else I should be able to do. Thanks

I don't have my notes around since I left my other desktop back at home. I won't be able to assist you with the hook detection, sorry. Focus on UDP, game doesn't log anything about it so just try to understand the code. Disassemble->Decompile->Refactor->Try repeat until you reach the final working code, that's how I did it with the xmpp packet validation.

Alright, thanks anyway! I think I'm close to removing the hook detection anyway.

@[Only registered and activated users can see links. Click Here To Register...] What exactly do you mean by:

Quote:

When you are done, modify the assembly to make it "BuildType.Debug;NotOptimized;Level.Debug"...

I don't know what you mean by "BuildType.Debug", "Level.Debug", etc. I looked around a bit and can't find anything referencing "BuildType" or whatever. I'm new to this, so I might be missing something obvious.

Alright everyone...

I'm looking for some volunteers to help out. This isn't an easy thing to do alone, so if anyone wants to help, that would be appreciated.


Volunteers need to have experience with:
- networking/multiplayer games
- reverse engineering (I'm still learning, so that's the reason for this requirement)
- Wireshark (to watch the packets that are being sent)
- Know how to use IDA effectively (same reason as "reverse engineering", I'm still learning how to use it)


Additionally, if anyone happens to have a modified version of the NFSW executable that removes the anti-debugger code, PM me.


Anyone who's interested, please PM me!