MHS not searching all memory regions?

[fabsyi]

I was testing MHS 4.0.0.5 on the game Escape Velocity Nova by Ambrosia Software (http://www.ambrosiasw.com/games/evn/), and was doing a simple DWORD search for the players current credits.
I knew prior to the search that the credits were stored at address 2fbb901eh. However in my search in the default memory range (400000h - 7fffffffh) revealed no value.
The value is contained in a RAM region of type MEM_PRIVATE, which has a starting address of 100e0000h and a size of 1ff7f000h.

I tried a search just over this region with a value of 'unknown' to try and get it to return everything in this region, but no results were found. It looks to me, like it is not searching this RAM chunk for some reason (perhaps the region is too big??). I have the MEM_PRIV setting in the search options checked.

Is this a bug in the software, or is it some simple setting I have missed?

Thanks

[L. Spiro]

It is unlikely to be a bug.
Chunks larger than 128 megabytes are broken into 128-megabyte chunks so it doesn’t matter how big the chunk is.
Furthermore, if it fails to scan a chunk it tells you so via an error message.

You need to verify the data is where and what you think it is; the address you gave is on the heap and will be in a new place every time you start the game, or in a new place depending on which other processes are running on your computer at the time the game loads (where it can allocate RAM).


Use the Hex Editor to verify there is no funny business.
If the Hex Editor shows red at that location, then there simply is no data there, period.


My routine for reading RAM is custom and not detected, so it is sure that you are not dealing with an anti-read anti-cheat.


L. Spiro

[fabsyi]

Thanks for the reply.
I have tried looking up the address in the Hex editor, and it is there and accessable. It is coloured white, and I am able to change its value in the Hex Editor, which correctly changes the value in the game.

If you look at the sample image I took below, it will show you what I mean.
The image shows the selected address in the Hex Editor correctly. Underneath, is the memory map window from OllyDbg, which has the RAM region of interest highlighted.
Above that, the results of my search are shown, as well as the search parameters I used.
As you can see, there is a jump from the region starting at 100d5000 to the region at 4fdd0000.



From all this information, can you see if I've done anything wrong?

Thanks

[L. Spiro]

I will look into it tonight.


It breaks chunks into pieces of 128 so the largest chunk is always 128 megabytes no matter how big it really is.

Which leaves me with a few puzzles.

#1: It allocates enough memory for the largest chunk and uses the same buffer over and over. If that buffer is too big, it would return 0 results period and throw an error.
#2: If it fails to allocate any buffers anywhere, it throws an error and the search fails. It’s a 100% safe/stable routine.


So it will require some investigation. It must be a problem with the part that splits the chunks, since #1 I never got to test it much since I don’t have anything with big chunks and #2 last time I looked at that code I thought to myself, “WTF is this doing?”.


L. Spiro

[fabsyi]

Thankyou for looking into this.
If you need something which allocated a large memory chunk to test it with, the shareware version of this game can be downloaded from the link in my first post.
If you need me to test anything to assist you, I would be more than willing to help.

[fabsyi]

I have tried your new debug version of MHS that you posted on another thread with this problem, and it all works well!
The problem seems to have been fixed.
Thanks for the good work.

[L. Spiro]

I looked into the problem but found nothing wrong.
I modified the chunk breaker but my old code was in fact correct; my new code just makes a little more sense to humans but does the same thing.

The only thing I effectively modified was the chunk size, which went down from 128 to 32. I could only guess that 128 was too much for some computers.


L. Spiro

[fabsyi]

I've tried searching through this process again with your new release version of the software. Exact value search works good now and finds the value in question.
However, something wierd still seems to be going on when I do an 'Unknown' search.
I do an 'unknown' search, long, aligned between memory address 0x20000000 to 0x20001000, and the search returns 66,880,512 results. When I look at the list of returned values, there are addresses found as high as 0x21F20FFC. In addition, many address seem to be duplicated, the addresses seem to start again after it reaches this upper limit, as if it is wrapping around.
When I do the same search unaligned, I receive 267,522,024 results, and nothing is known in the found address windows, perhaps because there are too many?
Do you have an explanation, as to why I might be getting these wierd results?

Thanks

[L. Spiro]

If you had gotten that problem after doing a “Range” search I would know what the problem is, but if you got that after an “Unknown” search, well, it’s impossible.

I can not replicate this problem. My searches are working perfectly, and the problem you describe can happen only on Range, Not Equal To, Lower Than, and Greater Than searches, or on Exact Value searches if the exact value is 0 or -1.
It is impossible on Unknown searches, unless the target process is messing with MHS (unlikely).


L. Spiro

[fabsyi]

Yes, the problem does seem rather strange.
I thought it was my computer that was at fault, so I tried this out on other computers, but alas the problem was still there.
I believe it is something to do with the target process, but I think it is not trying to mess with MHS...the opposite actually, I think it isn't coded too well, and heaps of memory is just allocated everywhere for no reason (just a guess).
So, I think this problem will not occur with any other processes, it seems unique to this one, in that something about it seems to be not compatiable with MHS.
I guess there will be no way to fix this problem, unless you actually try MHS with this process itself, since it doesn't seem to me that this issue would arise with most other processes.
Anyhow, I am happy that I can still search for what I want, since the exact value search is what I needed anyway, so thanks for the good work.