Slight Suggestions

[Shynd]

Let me start by saying that I've been using TSearch since I can't remember when (Windows 98 or Windows ME, anyway) and switching over to MHS has been one of the most difficult--though also most rewarding--things I've done. If you feel that some of these suggestions are just me asking for things to be similar to TSearch and are unnecessary, they probably are and I'll completely understand if they're 100% ignored

Your hex editor is far superior except for one aspect: if I do a ctrl+g for a certain address and it's not within the current scope of the hex editor, it'll just bring me to the last address in the current scope. It seems to me that this annoyance could be resolved by either automatically opening the memory NEAR where the user wants to GoTo in a new tab or adding it to the current scope. This is probably something that I can't live without simply because I'm so used to TSearch's hex editor, so disregard if it's not a quick, simple fix and/or too low on the todo list to attend to until you get entirely bored (which I don't see happening anytime soon =p).

When you override the simple address of a cheat table entry with an expression AND the entry is of type 'string,' it only displays the first 8 characters of the string. Say I have a multi-level pointer expression that points to the string 'abcdefghijklmnop' and add it to the cheat table: it displays 'abcdefgh.' If I add that same address as a static, simple address to the cheat table, it displays the full null-terminated string.

Would it be possible to switch out the right-click menu in the disassembler based upon whether a line has a breakpoint on it or not? If I set a bp on, say, 0x680EF8, it adds it to the breakpoint table. If I right-click on the operation at 0x680EF8 in the disassembler, it still asks me if I'd like to add a breakpoint instead of, perhaps, edit the breakpoint or remove the breakpoint.

The 'Close' button at the bottom of the allocator doesn't do anything.


I thought I had more, but apparently not; I'l continue to use it today and see what I can come up with to help, but I hope these (few) suggestions help get you closer to a final release product.

Hopefully, as I get more and more versed with MHS, I'll write a few in-depth tutorials for some of the more common (to me) but also more complex and less talked about uses.

Keep up the good work

-Shynd


Edit1: Oh, in the breakpoint table, it'd be wonderful if a 'goto breakpoint in disassembler' option was added to the right-click menu. I feel like I'm being nitpicky, now, and I promise that's not the case; I hope you don't find this post annoying.

[L. Spiro]

automatically opening the memory NEAR where the user wants to GoTo in a new tab or adding it to the current scope

I plan to open a new tab if it is outside of the range. It is a simple addition and will be in the next release. I already worked on other parts of the Hex Editor for this release.

When you override the simple address of a cheat table entry with an expression AND the entry is of type 'string,' it only displays the first 8 characters of the string.

That seems absolutely bizarre, but I will look into it. The display output is not changed at all by the code used to calculate addresses (virtual class inheritance makes this all very clean and tidy).

Would it be possible to switch out the right-click menu in the disassembler based upon whether a line has a breakpoint on it or not?

I have been planning this but low on the list. Since someone mentioned it, it will be in the next release.

Oh, in the breakpoint table, it'd be wonderful if a 'goto breakpoint in disassembler' option was added to the right-click menu.

Same as above. Will be in the nest release.


Tutorials would help if you wanted to make them…


L. Spiro

[Shynd]

Thanks, man.

I'll see what I can do about tutorials in my free time as soon as I'm finished with my current project. I'm sure you've probably already covered most of the bases I'm thinking about covering, but having two points of view on the same issue never hurts

[L. Spiro]

I found no problems with using complex addresses with strings.
The string length depends on the length text in the Value When Locked combo, which will be 8 characters long if you converted from UINT64 to string.

Everything else is already added and ready for the next release.


L. Spiro

[Shynd]

I was playing around with a code-injection script earlier (just to see exactly how much can be done with MHS scripts as I haven't played with them much yet) and noticed that the On_Close function is called only after the process handle is closed. I understand the need for this--what if On_Close is called with a process handle to a process that just crashed?--but it does make it somewhat difficult to clean up code injection.

For instance, I'm doing the normal codecave thing, overwriting a few game opcodes with a jump to my cave, etc. I was trying to find a way to clean up the overwritten opcodes when I either a) close MHS or b) start hacking another process. Nothing I tried seemed to work.

Is it even possible to tell if the process is being closed because it crashed or if MHS is closing / targeting another process? I know this causes all kinds of problems--say someone puts a MessageBox in the On_Close function that blocks MHS from closing / targeting the other process because it's waiting for On_Close to finish before moving on. Is there a way around these problems with still giving at least PARTIAL ability to clean up injection?

Something like On_Close(bool safeClose, HANDLE hProcess, DWORD dwProcessId) and then the user checks for safeClose to be true before trying to access memory.

Anyway, going to post my first MHS code injection tutorial here in a little bit. Thanks a lot for the fixes; methinks I'm going to be an MHS devotee after seeing my gripes with the program fixed within a day

[L. Spiro]

The only reason I opted not to pass the HANDLE is because, if the program crashed or closed, it would sometimes be NULL and people could possibly be confused as to why (and would not need to clean anything up as a result).

In retrospect, a better system would be to always pass the (active) HANDLE to the function and if they work they work and if they don’t they don’t.
In this case if they work it allows you to clean up and if they don’t it means there is nothing to clean up anyway.


Within the short time it has taken to write this reply I have already leaned over and moved 2 lines of code to fix this problem.
However the release will not be immediate so in the meantime you can get around this problem by storing your own copy of the handle and process ID and use those. You can remove them in the next release.

Message boxes are already able to delay the script function and therefore the detach routine, but this is up to the writer of the script. If he or she does not want to delay execution then he or she has the option of creating the message box on a second thread.


L. Spiro

[Shynd]

For whatever reason, I swore I had tried that, but now that I add it back in not only does it work but it seems like I THOUGHT about trying it but never got around to it =p Odd how those things happen.

[Shynd]

Okay, now that I've been playing around with breakpoints...


Pretty sure there's no problems with the breakpoint (none that I see anyway).

Now then, when I define the handling function as...

Code: Select all

void On_BP_TROSE_EXE_1(LPVOID lpvAddress, LPPROC_INFO_MHS lpProcInfo)
{
   MessageBox(MBS_OK, "Breakpoint!", "You just sent a packet!\n\nBreakpoint hit at 0x%08X", (DWORD)lpvAddress);
}

...it doesn't break.

However, when it's...

Code: Select all

void On_BP_1(LPVOID lpvAddress, LPPROC_INFO_MHS lpProcInfo)
{
   MessageBox(MBS_OK, "Breakpoint!", "You just sent a packet!\n\nBreakpoint hit at 0x%08X", (DWORD)lpvAddress);
}

...it breaks. This is using 4.0.0.6.

[L. Spiro]

You have to use Cur Proc Script Function.


L. Spiro

[Shynd]

Is that supposed to be an option in the dropdown where one chooses Script Function / Sys Beep / Single Step? Maybe I have the wrong version but I don't have that option. Unless it's somewhere else and I'm just missing it =p

[L. Spiro]

I added it so quickly after releasing MHS 4.0.0.6 that I forgot it wasn’t actually in that release.


It will be in (is already in) MHS 4.0.0.7.


L. Spiro

[Shynd]

Sounds good.

[Shynd]

Another thing: I still find myself using TSearch or CheatEngine for the Auto-Assembler portions because I dislike how MHS' AA works. For instance, say I want to create a static address for the value of ESI: in CE or TS, I overwrite one game instruction with a JMP to a codecave, replace that instruction, mov [whatever_address], ESI, and JMP back. In MHS, it copies like 25 bytes after the single instruction I want to overwrite and puts those in the codecave which inflates it larger than I need it. A simple 5-byte JMP and one NOP is all I need to overwrite a 6-byte instruction and it seems a little unnecessary to overwrite 6 lines of ASM for a 3 line codecave. I hope that was clear enough, it's late and I'm tired

[L. Spiro]

Is this a complaint for this or for MHS 4.0.0.6 and below?

If you are using the Injection suite, it is meant to provide a quick way for simple injections and so does most of the work for you, even if it is doing work you did not really want it to do.
This is the difference between the Injection Suite and Auto-Assembly which is found in MHS4.0.0.6.Preview.rar (which is still not complete).


In MHS 4.0.0.7 you will have both options available to you and the Auto-Assembler will be much easier to use and more feature-rich than in TSearch or Cheat Engine.


L. Spiro

[Shynd]

Oh, yeah, it was for the Injection Suite. I really liked it as it formatted it in a way I could easily understand, it just did a lot more than I needed it to. I haven't played with the Auto-Assembler yet as I'm really, really tired and I've been reading about threads and thread context for hours longer than I've ever wanted to =p

I apologize if it seemed like a complaint, by the way; I really only bring these things up because I know how it is to write a program that does everything I want it to do but I can't, for the life of me, figure out how to make it popular with everyone else unless I get suggestions from the outside. I'm a firm believer in bringing attention to anything that I'd do differently to the programmer just in case you look at something and say "Hmm, I didn't think of it like that..." If my 'complaints' get annoying, let me know, as I don't want to detract from a program with which I've become so infatuated in the past few days.