What would it take to make a JASS debugger for WC3?

[MeMeMe123]

So, I'm posting this here because at this point, it doesn't feel right to ask in the other forums since this isn't just about WC, but about learning a bit about the tools of the trade.

I can program, though it's been years since I've used something more serious than python (which I love, but doesn't seem like the tool of choice when you're serious about messing with WC/WE).

I'm interested in hacking together a debugger for myself <fantasy> if it's not too difficult to pull off (I don't expect it is, but worth asking some questions - at worst I might learn something), and - if the result is not too bad - I'll even share (hell, I'd love to share just in the hopes of others improving upon it) </fantasy>

But right now, all I've got is "hooking" - I understand the basic idea: intercept function calls.

But:
- How do you figure out what to intercept? I know the JASS is interpreted, not compiled. But how do I find the component which interprets it?
- What would my code need to do once I manage to intercept the calls? aside from the obvious:

stop the execution if we want to look at the code; let it through otherwise
Somehow get the data (by injecting JASS code that will somehow allow us to read the data? how?)
Interpret the data structures used
​

Thank you!

​

 

[GhostWolf]

Jass debuggers are fairly limited. You can't quite implement pausing without side effects, and I assume there are many other issues.

The real problem though, is that you are too late.

Starting from patch 1.30, things are probably going to significantly change, hacks are going to break, and new hacks won't work.

If you want to make something out of interest for older versions (e.g. most likely 1.26), I suggest you to look around at existing tools, and see what they did.

 

[MeMeMe123]

Jass debuggers are fairly limited. You can't quite implement pausing without side effects, and I assume there are many other issues.

The real problem though, is that you are too late.

Starting from patch 1.30, things are probably going to significantly change, hacks are going to break, and new hacks won't work.

If you want to make something out of interest for older versions (e.g. most likely 1.26), I suggest you to look around at existing tools, and see what they did.

Things change, we adapt

Whatever limits there may be, I'm willing to give it a try. One of the guys who made a debugger for an earlier version said he did it "for fun", and I've always enjoyed figuring out things as I go.

Problem is, in this case, just figuring things out is extra hard for me, since reverse engineering isn't as easy as the other things I've done so far.

I've already used some windows tool to get the call stacks of the process. My knowledge of reverse-engineering is very limited atm, so I'm trying to figure out how to do something right now.


ofc I don't want it to be too hard, which is why I'm hoping someone with a great deal of experience would throw some keywords to google my way, or recommend some resource I can learn from

Edit: figured it wouldn't hurt elaborating a bit about what I've done so far (which is very little, been a bit lazy lately):
I made a map which writes a text file, and filtered the API monitor based on access to the file. I need to cross all the relevant stacks to find the lines of code that are responsible for the reading & interpratation of the code. problem is I'm looking at the code in OllyDbg, and the offsets I get in the stack within the .exe file don't match up to what I see in OllyDbg.

I guess my next step would be to figure out how to use OllyDbg to get the stack trace, maybe I'll get the right offsets.