Considering an editor...

I had an idea last weekend. Given the successful outcome of Discrete, my mini-assembler, I figured I could modularize it and implement it in other projects.

What I'm thinking of doing is to create an editor, but not the wussy point-and-click cookie-cutter-hack-producing kind. It'd be an editor that relies on one's skills as a hacker to produce a decent hack, and not their aptitude at clicking on buttons and leeching off somebody else's research.

For instance, the enemy editor would contain a pointer to a pointer tbale of enemies (so the table could be relocated, and thus, expanded.) It will then list the pointers for each enemy, and their code. For the sake of convinience, it will also add their npc.tbl data.

The amount of skill one has will reflect itself in what they can do with the editor. But this project won't be ready for quite some time. I'll have a demo out sometime, though.

To make it even more complete, it will feature a raw hex/assembly editor as well for things the editor doesn't support.

Expect screenshots this weekend.

 

COOOOL ^^ very nice, could I be a Beta Tester?
Well it's maybe a little Test too: is your editor ialso nice for people who don't have any Assembler e.t.c. knowhow?

 

I think that's exactly what he's saying. I'm definitely looking forward to it, even a simple Beta/demo, since I can't find anything in the Dump (Well, i've found loads, I just don't recognize it.).

 

Well yes, it CAN be used without any assembly knowhow, but why bother? Might as well stick to Sue's Workshop and a hex editor.

The main use of the editor will be to simplify assembly hacks, but there's no reason why I wouldn't include other relevant data (say, the exp table for weapons.) You both should be familiar with my ROM hacking views, so it should be obvious this isn't going to be a watered-down let-the-editor-do-all-the-work thing.

I don't need beta testers, I'll make periodic releases as I get interesting stuff up and running. In any event, I'd need someone with assembly experience if it came to betatesting...

@Sontreal:
You can establish a good foothold in the code by looking through the exe for offsets. Say you find the string "Hello world" at offset $89F6. This means it's at 0x004089F6 in addressing space. Just look for a push instruction with this and you've pretty much found what accesses this.

Better yet, find data and try to find a part of the code which MOVs data from the first byte of this structure. You'll not only find yourself a loader for something, but with a bit of digging around, a few offsets in RAM.

 

Slowly we are weaking him. Soon he will succumb to making an easy editor! >=D

 

I'll give it a try for one.
But knowing me, I'll most likely keel over after looking at what it outputs.

 

I don't need beta testers, I'll make periodic releases as I get interesting stuff up and running. In any event, I'd need someone with assembly experience if it came to betatesting...

Nice. Ok ^^

Say you find the string "Hello world" at offset $89F6. This means it's at 0x004089F6 in addressing space. Just look for a push instruction with this

kabooom! now i know why the adresses in the assembly dump are such as this ^^

Slowly we are weaking him. Soon he will succumb to making an easy editor! >=D

LOOOOOOOOOL, maybe? Osmose you're a funny guy looooool
hmm maybe: pls pls pls rune pls pls pls! XD

 

lol, you guys rock. I'm toying with the idea of writing an editor deeply mired in 80x86 assembly knowledge and you all act like it's going to be some uber-easy-to-use program. It's still assembly, no matter how glorified the interface is going to be.

What will make it easier is not having to dig around for the offset to function x or callback y. And being able to tweak pointer tables without copying a whole slew of code... But that's just automating a task that could be done with a hex editor (albeit in far more time...)

Still, if it makes working with assembly easier and motivates some of you to learn enough assembly to get a few basic hacks out there, then I'll be quite glad I've invested the effort in making this.

But making something "easy"? I shall never yield. lol

 

You can establish a good foothold in the code by looking through the exe for offsets. Say you find the string "Hello world" at offset $89F6. This means it's at 0x004089F6 in addressing space. Just look for a push instruction with this and you've pretty much found what accesses this.

Better yet, find data and try to find a part of the code which MOVs data from the first byte of this structure. You'll not only find yourself a loader for something, but with a bit of digging around, a few offsets in RAM.

You make it sound so easy. It's not as easy as that though, is it? I'm not going to find something like that somewhere, am I? Because if I see a Call sommand, it almost always leads me to a "push ebp/ebx" line, followed by a couple of lines, then another call command, and follows this pattern until a) It gives a Call command to a string not in the Dump, or b) It leads me to something, but I don't know how to test it...

In any case, I'm looking forward to this editor, despite any difficulties it may produce. This way it will be easier to find stuff, and make a weapon which fires 50 misssiles at once in all directions doing 999 damage per missile.

 

Well it's not rocket science - it's as easy as telling the computer what to do... only you have to be really specific.

The hard part is figuring out what someone else was trying to tell it. But there are plenty of ways to figure out little tidbits here and there. Every little bit helps and opens up new possibilities (for instance, once you've figured out where your health is stored, you can go picking around in other functions that refer to that offset.)

Another trick is to try to follow the logic in a function that doesn't refer to anything but parameters. Finding general-purpose functions really helps. For instance, you find a function that copies an image to the screen - picture just how useful that'd be...

Little trick. If you see [ebp-????] that's a local variable that exists only for the scope of that function. As for [ebp+???], that's a parameter that was pushed onto the stack before the call took place.

push 0x50
push 0x0A
call ??

In the above, when the program jumps to ??, [ebp+0008] will equal 0x0A and [ebp+000C] will equal 0x50. Note that [ebp+0004] will contain the return address (where to go back to once the function ends) and should not be messed around with.

For Original Sin, I've tweaked missiles quite a bit to get the explosive charges working. Not only is it easy to change the number of missiles fired, you can create really awesome explosions by tweaking very little code. I saw some awesome stuff, crazy explosions that pour out clouds of flames, after just a few moments tweaking the function. It's fun. Still trying to figure out how to change the range though... having a HUGE explosion that only hits when a few pixels away from its epicenter isn't very fun.

 

lol, you guys rock. I'm toying with the idea of writing an editor deeply mired in 80x86 assembly knowledge and you all act like it's going to be some uber-easy-to-use program. It's still assembly, no matter how glorified the interface is going to be.

Hmm maybe we shall please him a bit more? ; ) pls pls pls rune XD

Well it's not rocket science - it's as easy as telling the computer what to do... only you have to be really specific.

LOOOOOL! XD

Well iam lookin forward to you programm ^^ Good luck *waits for screenshots*

 

Here's a screenshot of what I've written so far.



I haven't been able to work on this consistently in the past week, seeing as I've been getting involved with a few old friends I hadn't seen since college, went out to celebrate someone's birthday (and ended up going back to my rather small appartment with 7 other people to mix drinks and have a good time... cramped!), and focused mainly on Endless Saga. But at least I can load info on weapons.

 

I had an idea last weekend. Given the successful outcome of Discrete, my mini-assembler, I figured I could modularize it and implement it in other projects.

What I'm thinking of doing is to create an editor, but not the wussy point-and-click cookie-cutter-hack-producing kind. It'd be an editor that relies on one's skills as a hacker to produce a decent hack, and not their aptitude at clicking on buttons and leeching off somebody else's research.

For instance, the enemy editor would contain a pointer to a pointer tbale of enemies (so the table could be relocated, and thus, expanded.) It will then list the pointers for each enemy, and their code. For the sake of convinience, it will also add their npc.tbl data.

The amount of skill one has will reflect itself in what they can do with the editor. But this project won't be ready for quite some time. I'll have a demo out sometime, though.

To make it even more complete, it will feature a raw hex/assembly editor as well for things the editor doesn't support.

Expect screenshots this weekend.

Your poor old grandmother wants to make a cave story hack, but she doesn't know assembly, she doesn't even know the numerous benefits of right clicking. Imagine her pain when you say to her "I'm not making a wimpy point & click editor I want to make it challenging to ones skills as an hacker.

Do you really want to put her through that?

 

well it looks cooool but that assembly-thing on right side? Oo

A nice challenge would be a easy script like TSC or something...
But other way... yeh poor grandmother

 

Well as far as I know cave story already has editors for the "wimpy point and click" stuff, and reinventing those would be a waste of time. Also from the screenshot it doesn't look too hard to figure out. it COULD be simplified but not without imposing restrictions on what you can do with it.

 

Well as far I know (and Iam longer here than you ) Cave Story has only Sue's Workshop... (its not a wimpy point and click editor -.-) Sue's Workshop is only for simple Map and Script editing and not a assembly editor...

 

Ah, but my oor grandmother is not a ROM hacker. And if she were, she'd have no business working on something she doesn't understand before trying to learn it herself. Much less getting angry on the intar-web over not knowing assembly, there being someone who does, and feeling the need to take out her jealous rage on every post that person makes instead of learning assembly herself, this without ever actually having acheived anything too important herself other than things that have already been done. No offense Caveoholic, but if you can't be bothered to learn assembly, then don't touch the assembly-related stuff and use the rest of the editor. You're not being forced to use it, or the editor, by anyone, so I have no idea what you're complaining about this time.

It should be noted that you don't need any assembly know-how to click on a checkbox or to change a number. Although I DO suppose you could write a program in assembly to grab the window handle, enumerate its children, locate the checkbox and grab its handle, and send a WM_CLICK message to it... but that's beside the point.

I should note the interface has changed slightly last night. Turns out there's only one set of flags. The other one was range. While trying to figure out what was what in those flags, I noticed what appeared to be some binary pattern in the shooting star, and came to the conclusion it was a number. My bad.

I'm still debating wether to give it a nice, graphical interface, or to leave it at Win32 controls. Functional, orpurdy and sparkly? The extra bloat from additional graphic files is a factor to consider.

Next step, writing a decompiler module, shortly after which I'll write a recompiler module based on Discrete. Then I can move on to other interfaces (probably effects next, since that'll be short...) One thing not pictured in the screenshot is the helper windows, which are little topmost windows holding lists (faces, weapon IDs, sound IDs, supported mnemonics...) Useful feature that I might make fully customizable.

 

Yeah, my point is that making a simplified editor for assembly limits what you can do with it severely. Also TOO simple can be a bad thing. you can't piss out a window without hitting a poorly made super mario world hack, all because lunar magic is so easy to use. having to get used to what you're doing will seperate the serous from those who will just quit after a couple of early demos.

Must just be that I have been following the romhacking scene since 2000, and seeing anyone with a mouse create cookie cutter "hacks" without even making an effort to stand out has made me a bit critical. Hell, I'm all for simplicity but like I said generally the simpler it is the less you can do.

edit:

enumerate its children

Hey now, lets leave the children out of this

 

Ah, but my oor grandmother is not a ROM hacker. And if she were, she'd have no business working on something she doesn't understand before trying to learn it herself. Much less getting angry on the intar-web over not knowing assembly, there being someone who does, and feeling the need to take out her jealous rage on every post that person makes instead of learning assembly herself, this without ever actually having acheived anything too important herself other than things that have already been done.

Yeh, its very easy to change a number too
Well I hope you not mean me...

Must just be that I have been following the romhacking scene since 2000, and seeing anyone with a mouse create cookie cutter "hacks" without even making an effort to stand out has made me a bit critical. Hell, I'm all for simplicity but like I said generally the simpler it is the less you can do.

Generally? Hmmm... I would disagree. But thats your sight of the things...

Hey now, lets leave the children out of this

You confuse me, back to topic pls...

 

"Child" is just a way of talking about some sub-element, in programming. For instance, if a window has a frame in which are 8 checkboxes, the checkboxes are child elements of the frame. Or more Cave Story oriented, if you fire a projectile, the projectile object is a child object of the Quote object, because it was created by the Quote object. Hopefully that clears up confusion.

@SpaceDolphin:
Your name sounds familiar. Ever worked on any projects or had an active role in the ROM hacking scene? I'm sure I've seen that name somewhere...

I used to spend a lot of time on Mnrogar's, where we pretty much ripped apart Final Fantasy III/VI start to finish. I dunno what it's like over there nowadays, but I'll bet there are still plenty of assembly dumps, all well-commented, floating around. Fun times...

Ahh... nostalgia... I remember the late evenings spent discussing bits of code and various script parsers with other board members, arguing over processor flags and unusual addressing modes. Nostalgia!!