Silkut
April 23rd, 2007, 14:44
Hello all,
@admins: feel free to move this topic if it's location is not correct, I did read the FAQ, and I think no animals were hurt during this topic redaction.
Silver recommended me to post this publicly, to have more thoughts from pros and skilled reversers.
Since some days I started to think about D3D reverse in video game because a guy asked about what follows:
The original background is some korean MMORPG game, the Field Of View (FoV) is a bit too far (to his taste), making the game apparently lagging (I'm not telling this is exactly the cause of this issue). The idea was to modify the game to easily change this FoV (firstly to reduce it) as it isn't an option in settings. I wanted to help him and now, I'm more interested about the overall question.
So the guy started to seek variables responsible of FoV. He found one that apparently have a range value from 0 to 3. (I personnally didn't checked the code out). He tried to modify this value (with OllyDbg I guess) and then he found this modification didn't changed anything in the game.
The questions: Is the code integrity controled by routines ? Did the wanted modification was done on the right level (DX libraries, DX calls, variables..) ?
I contacted a friend who is game developper (note: he's not one of the korean game developpers, it was just to have his professional point of view), told the story and asked those questions.
He told about the patching that it was a very bad idea, in a first time because korean developpers surely implemented some home-made code integrity control, totally different from usual commercial apps hashes or checksums, to avoid cheat.
In a second time, the fact that the modification didn't worked is due to a lots of change in the matrix projection state with operations like LODs, etc... That sounds normal after all, that the patching failed if it's oftenly modified.
The gamedev believes in solving this problem by modifying the projection matrix on-the-fly when it's called, since it is responsible of far/near plane. That would make us able to do whatever we wants with the FoV. He told to look after lpD3DDevice->SetTransform().
Since the gamedev is not reverser, I asked Silver to give his advice, but clearly failed to properly present my problem as he misunderstood some details. He was not totally convinced about the tricks utility, though.
I would like your advice as it seems to be DX gurus out there (Maximus, Silver named you
). I lurked around and found piles of posts mentionning D3D, requiring Softice for easy debugging, also Silver's pure DX crackme about disassembled DX code aspect. I used to code with OpenGL and DirectX (samples and demo scenes, nothing very outstanding) but i'm not a pro reverser. The idea isn't to totally change the game, cheat on it or making my own omg-mmorpg-game. Just such introduction into D3D reversing and why not, exploring the rabbit hole. The home-made control is less interesting to my mind (particularly if I start reversing on a home-made DX app).
I hope this post is clear enough, don't hesitate to ask about details, I don't have the game code though, but every little DX game would be perfect I think. I'm still learning english, mistakes and typos must be common in my topic.
Regards.
Silkut~
@admins: feel free to move this topic if it's location is not correct, I did read the FAQ, and I think no animals were hurt during this topic redaction.
Silver recommended me to post this publicly, to have more thoughts from pros and skilled reversers.
Since some days I started to think about D3D reverse in video game because a guy asked about what follows:
The original background is some korean MMORPG game, the Field Of View (FoV) is a bit too far (to his taste), making the game apparently lagging (I'm not telling this is exactly the cause of this issue). The idea was to modify the game to easily change this FoV (firstly to reduce it) as it isn't an option in settings. I wanted to help him and now, I'm more interested about the overall question.
So the guy started to seek variables responsible of FoV. He found one that apparently have a range value from 0 to 3. (I personnally didn't checked the code out). He tried to modify this value (with OllyDbg I guess) and then he found this modification didn't changed anything in the game.
The questions: Is the code integrity controled by routines ? Did the wanted modification was done on the right level (DX libraries, DX calls, variables..) ?
I contacted a friend who is game developper (note: he's not one of the korean game developpers, it was just to have his professional point of view), told the story and asked those questions.
He told about the patching that it was a very bad idea, in a first time because korean developpers surely implemented some home-made code integrity control, totally different from usual commercial apps hashes or checksums, to avoid cheat.
In a second time, the fact that the modification didn't worked is due to a lots of change in the matrix projection state with operations like LODs, etc... That sounds normal after all, that the patching failed if it's oftenly modified.
The gamedev believes in solving this problem by modifying the projection matrix on-the-fly when it's called, since it is responsible of far/near plane. That would make us able to do whatever we wants with the FoV. He told to look after lpD3DDevice->SetTransform().
Since the gamedev is not reverser, I asked Silver to give his advice, but clearly failed to properly present my problem as he misunderstood some details. He was not totally convinced about the tricks utility, though.
I would like your advice as it seems to be DX gurus out there (Maximus, Silver named you

I hope this post is clear enough, don't hesitate to ask about details, I don't have the game code though, but every little DX game would be perfect I think. I'm still learning english, mistakes and typos must be common in my topic.

Regards.
Silkut~