Printable View
:lol: Phew. I'm glad to hear that. I don't like to insult people... but dumb programs deserve all the flames we can throw at them. Stupid Hex-Rays.
Actually, the page does sayC-like not C++-like. Which is probably Hex-Rays excuse for the mess I observed. :wink:Quote:
It converts executable programs into a human readable C-like pseudocode text.
SheenBR how about using this to encrypt your dll that you trying to protect? :)
"compile -> hex-rays -> compile -> hex-rays" x10 times and it should be encrypted ;)
IDA itself is actually one of the best debuggers and hex-rays is there only for ...reference... I guess. Here is the real guide for RE.
But to defend hex-rays I like how its naming unknown variables and arguments v1, v2, v3, a1, a2, a3 :)
Its also not bad for functions that not making any sense and are pure adding, xoring or shifting functions, like cryption functions in PT server/client.
I think hex-rays is good because in some functions it'll show the variable type.
function (a1 as Integer) or as DWORD, LPCSTR you know? But the code itself is too messy.. and in that DDRAW procedure, there are several calls further to DDRAW but they are all like
CALL DWORD PTR DS:[ECX+number] and it doesnt show the DDRAW function name priston is calling, only the offset, so its pretty hard to know which functions we would need to patch... and I was reading about ddraw, A LOT of people DOES NOT recommend to build applications using DDRAW, AFAIK DDRAW should be some part of DX6, IDK, and everyone said that the best thing to do is change your application to use the new DirectX functions... I also read that DX SDK doesnt even adds ddraw libs anymore...
That's because DDraw is only being used as an entry point for DirectX. It makes a surface and attaches a DirectX scene to it, then does everything in C++ OOP paradigm which can't be represented in "C-Like" syntax. It can be represented as Assembler, or C++ (or Delphi, or even classic VB) but not as C. (not without wrappers or reducing the C to pseudo assembler)
I found this document pretty invaluable in decompiling C++, but I'm still struggling to understand it 100%.
As to using DDraw for access to DirectX... that was the norm in DX3, and still used in DX5, but "depreciated" for comparability. DX6 is when they dropped that method from the API, as far as I am aware. It certainly wasn't used in any 3D demos, but was still the way to create a DirectX surface for 2D (say, watching movies) up to DX7. For 3D scenes you where supposed to link to D3Dwhatever.dll. (I think, I don't have all the DirectX SDKs any more)
Most DirectX developers don't really know, because the SDK smooths over the internal changes from one API to another... but I'm pretty sure SDKs after DX7 won't even allow you to build source using such an old method any more.
well, you can go to that routine, analyse it in pure assembly and then you could explain that routine to us,, couldnt you?
---------- Post added at 06:03 PM ---------- Previous post was at 05:59 PM ----------
well, DDRAW.dll contains only 16 methods. Hooking all of them to detect which one is being called by the game would do any good or its just a waste of time?
LMAO. If I could ever understand it all.
As I say, I can get past the part where it has identified all the old crappy cards which needed some work-around or other. (your decompile includes the start of that routine, where it checks for the first "special needs" card on the list)
Then you start getting into 3D geometry stuff that I don't understand in 3D Studio, let alone x86 or C++. :lol:
what about hooking all ddraw.dll methods to see which one is being called?
BTDT. The only one called is DDrawCreate(). End of story. :lol:
The game isn't calling DDraw APIs other than that, it's calling methods of a DirectX object it creates. XD (no API to hook... as such)
So I repeat... What we need is the source to the WindowMode forcer Wrapper DLL. Then we could base our Object Hooks (not API hooks) on that. Monitor what methods and properties it accesses with what parameters where.
lol, I have seen a call to DirectSoundCreate, if you follow that routine and put a BP in those CALL DWORD PTR you'll see also calls that points to ddraw.dll...
@edit
Oh now, my bad... its DSOUND not DDRAW :P
004B788D |. FF52 3C CALL DWORD PTR DS:[EDX+3C] ; DSOUND.6EDA5211
AFAIK this is the functions called from DDRAW: (the exported functions only)
DirectDrawCreate
ReleaseDDThreadLock
But they are called by some ddrawex module, according olly...
Here is part of D3DWindower source code. Knowing life its probably GUI :)
I would rather isolate functions in D3dHook.dll that make PT faster and than revers them to C++. Does _frmDDraw hit the spot?
It's DelphC! (aka Borland C++ Buidler VCL project)
Anything TForm:: is just related to the VCL UI... as is the whole of WinMain (which is generated by BCB IDE, and pretty hidden from the user during programming) XD
--- EDIT ---
BCB 5.03 project to be precise. (still have on CD, but not installed... updated project to BCB 6, on my old NT4 Development VM)
http://i.imgur.com/yZuTT.png
Just builds a single GUI executable. Nothing else. So you are correct, it's just the GUI. :D: (turn that smiley on his head)
Maybe asking author for full source code/part we are interested would not be bad idea, if he speak english.
Even GDI in it is faster than directdraw, we don't need direct2d than badly.
DirectDraw (Direct2D) was only implemented to be a faster (more closely tied to hardware) implementation of GDI. (completely performed on CPU) Fact is, once you run under DWM, then DWM maps GDI to DirectX function to improve performance globally. :lol:Spoiler:
Original author seems to speak only Japanese, and the version you have has been translated by another, who doesn't seem to understand the DLL, but only the VCL executable. (to me)
It's worth a try though.
Why there is Direct2D in parentheses? :)
Should I write e-m@il? I think he would understand you better.
PS. O yes there is GDI+ in D3DWindower, forgot about that.
Yes, I've said before that I suspected that the F11 speed-up would be much less noticeable if the UI and text was rendered via GDIPlus.dll. (GDI+ is also more readable in x86 than DirectX)
Direct2D is in brackets, because it is only the new name for DirectDraw... essentially. DDraw.dll (from my understanding) now does nothing except wrap DirectDraw APIs to Direct2D. :lol: Though it must also wrap DirectDraw DirectX scene object creation on a DirectDraw viewport surface to Direct3D as well... I suppose. (Microsoft don't ever care to tell you how any functionality is implemented below the C++ / C# headers they provide you with)
Very well, I shall write the eMail on behalf of the RaGEZONE Priston Tale community.
--- EDIT ---
Quote:
Originally Posted by yahoo.co.jp