From: m3gaman3g3nd
i enjoy your support brandon, i also enjoy your ogl hooking technique… i have personally attempted to test it but failed after a couple trys (i put the dll in the runesape live folder where all the bin files are. i set my graphics to open gl,, (not sure if that was what i was supposed to do)) i tried the pascal script method and not lape yet but thats because im an a different machine.
anywho ive been thinking that whatever goes to your agp or graphics card is only graphical data and that it. the rest is up to the main cpu to give functionality towards the graphical arrays… this will lead to cpu hooking…
cpu hooking sounds far more fun as it will process all the information to where things are drawn and other functions of anything that may be processed by it.
it will process where things will be drawn and thats all you need to know.
it sounds more complicated though because it seems thats some information will bestore in memory instead making somethings out of reach. in jagex bin files to their servers, encrypted game information is sent. hopfully theres a way to intecept all cpu information for interpretating.
trees in runescape are everywhere, so the cpu needs to send data to the gpu(graphics processor?) of which where to be drawn… meh ill keep reading up on articles trying to figure out meathods to intecepting information let alone sorting it out one by one…
There is no such thing as CPU hooking :S Well.. Not that I know of.
Here is what happens.. Hopefully I can explain it easily:
File is sent from Server to client containing VertexShader information.
File is sent from Server to client containing FragmentShader information.
Client initializes itself and starts receiving data.
Shader is fully downloaded so the client then creates its interface.
GDI is invoked on Windows and a DC (Device context is created.. Aka a Canvas for drawing on)
The DC is prepared for the type of rendering that will be done.
Client COMPILES the shaders at runtime as you cannot pre-compile these.
Any and all errors are thrown if there are any that is.
A backbuffer aka vertex buffer is created (VBO's).
A front buffer aka vertex buffer is created (VBO's).
Another "Set" of buffers are created for a total of 8 running at once.
More are created but are deleted right after being used.
Client begins drawing and shading in models and textures on BackBuffer.
Client "Swaps" buffers. (Front and Back switch.. Now the backbuffer is displaying on screen).
Client Draws on the new backbuffer (the old front one).
Client "Swaps" buffers. (Back and Front switch.. Now the Front is back to the screen).
Repeats the last 4 steps. Requests data only when needed for new scenarios/areas/models.
Server sends what the client starts requesting from here on out. Only way to get the data is to inject into the client or "packet sniff". Nothing is done on the CPU unless you're in safe-mode.
Only things that come from the CPU is the vertices and colours which it receives from the server and sends to the graphics card directly. The interception part comes in because you sit in the middle of the client and the API (DirectX/OpenGL/GDI).
Sitting in the middle means everything goes through you first before it gets to the graphics drivers/screen.
Other information is just stored in the client itself or in downloaded files. Basically, what you see is what you get. What you cannot see requires injection/reflection since it's java.
So yes.. No CPU "hooking". It's either Injection, Reflection, Interception, Packet-Sniffing. Nothing more, nothing less. Well not that I know of anyway.
