Improved _Mem() UDF's

[Nomad]

That's good to know. Because I couldn't figure out any other reason for the errors you were getting.

I guess nobody else has had any problems with potential bugs then? If something doesn't appear to be working as expected, let me know.

I'm almost done with a scan tool I've been working on. I've really put some time into the features of the GUI, and I think it's turning out rather well. Right now I'm just reworking the scanner to speed it up. It's a bit sluggish because I have it scanning all available memory for the specified range, which isn't necessary. If you scanned every address from 0x00000000 to 0xFFFFFFFF that would be 4,294,967,296 addresses, and if it took say 10 milliseconds per address that would be 42,949,673 seconds (497 days), hehe. So, I'm working on ways to cut the time down significantly. For example, only scanning memory pages which are committed and have read access, and scanning either 16-bit or 32-bit memory. I'm also looking into some more options.

It's based on my functions listed here, but doesn't actually use them. If I used them directly to read this amount of addresses it would greatly multiply the scan time. Check the loop-time for reading one address and you'll see why.

Hopefully I'll get the bottlenecks worked out soon. When I do I'll be posting the finished product.

Nomad

[Nomad]

This is driving me nuts. I'm not sure if this is going to be possible with AutoIt or not. I can read all of the addresses in a matter of minutes now, but comparing the millions, and sometimes billions, of addresses read against the value being searched for is what's taking a LOT of time. I've got it down to where it takes a few hours, give or take depending on a variety of factors, to read and compare the addresses. But an initial scan that is taking about 4 hours, only takes about 3 minutes with Cheat Engine or T-Search. I'm also reading all of the same addresses, and perhaps even less.

I've considered writing the data to a file, and then reading the file, but I can't see how that would be faster than simply doing $Array[$var][$var] = $DataForAddressRead. I've also considered writing a Dll, but my intention is to do this completely with AutoIt and the native system Dlls. I want this script to be a stand-alone project.

Anyway, I'll keep trying to work out the kinks. In the meantime, if anyone has any good ideas to dramatically speed up the comparing and sorting portion of this script, I'm open to suggestions.

Heres an example of how I'm doing it now:

For $i = 1 to $MemoryPages[0][0]
    
    Local $Size = ($MemoryPages[$i][1] / DllStructGetSize($LocalType))
    
    Local $Buffer = DllStructCreate($LocalType & '[' & $Size & ']')
    
    DllCall($Handle[0], 'int', 'ReadProcessMemory', 'int', $Handle[1], 'int', $MemoryPages[$i][0], 'ptr', DllStructGetPtr($Buffer), 'int', DllStructGetSize($Buffer), 'int', '')

    Local $Data
    
    For $j = 1 to $Size ;<<== This loop is what's taking so long
    
        $Data = DllStructGetData($Buffer, 1, $j)
        
        If $SearchValue = $Data Then
            
            $k += 1
            $DataArray[$k][0] = $MemoryPages[$i][0]
            $DataArray[$k][1] = $Data
            
        EndIf
        
    Next
    
    GUICtrlSetData($ProgressBar, ($i / $MemoryPages[0][0] * 100))

Next

Nomad Edited July 13, 2006 by Nomad

[w0uter]

One way would be to inject assembly code into autoit and run that.

But i have a feeling you dont want to take the time for that

[Nomad]

One way would be to inject assembly code into autoit and run that.

But i have a feeling you dont want to take the time for that

Ew, you said a bad word... assembly.

After all of the work I've put into this project, I'd hate to scrap it because AutoIt isn't capable of performing the required tasks in a timely manner. If I can't get the initial scan time down to less than 5 minutes with my current scan settings (scanning 'all' available memory is time consuming even for Cheat Engine, etc..), then I'll be willing to explore other options, such as your suggestion. But if it is possible to do this without having to go outside of AutoIt, with exception of kernel32.dll for performing the memory reading/writing tasks, then I'd rather keep it that way.

The time required to complete the task isn't really an issue. The longer it takes me, the more gratification I'll get when I have a fully functioning finished product (not to mention the knowledge gained on the journey).

Thanks for the suggestion,

Nomad

Edited July 13, 2006 by Nomad

[w0uter]

You could inject assembly (when i say assembly i mean byte code) and transfer data using DllStructCreate/DllStructGetData

Then thread it using CreateThread from Kernel32.dll

100% autoit

Edited July 13, 2006 by w0uter

[Nomad]

You could inject assembly (when i say assembly i mean byte code) and transfer data using DllStructCreate/DllStructGetData

Then thread it using CreateThread from Kernel32.dll

100% autoit

I'll do some research on that and see how well it works. I didn't even think about using a kernel32.dll function for this aspect of the script.

Thanks for the tip.

[Nomad]

Yeah, this is going to take some time to iron out, but I'm working on it. Once I'm done I'll probably have some new UDF's to post as well, which makes this all the more worthwhile. Two birds with one stone.

[Nomad]

Update: Added a new function. An example will follow shortly.

On a side note: The AutoIt code tags seem to be broken. Everytime I try to use them, every place in the code that there should be a carriage return there's a <br /> instead. I spent an hour trying to remove them with no luck, so I changed to the regular code tags instead.

Nomad

Edit: Example posted.

Edited July 15, 2006 by Nomad

[Nomad]

You could inject assembly (when i say assembly i mean byte code) and transfer data using DllStructCreate/DllStructGetData

Then thread it using CreateThread from Kernel32.dll

100% autoit

Ok, I've definately got in over my head this time. I don't know enough about multi-threading (which is essentially what this is) to implement it into AutoIt, yet. Perhaps with some more time, or maybe even a few pointers to speed up the process, I'll be able to figure this out. I've searched the forums somewhat, and so far this example is about the closest I've got to getting this to work, but it doesn't:

expandcollapse popup

Func NewThread($Func)

    Local $modHandle, $LoadLibraryA, $Thread
    
    Local $kernel32 = DllOpen("kernel32.dll")
    $modHandle = DllCall($kernel32, "long", "GetModuleHandle", "str", "kernel32.dll")
    If IsArray($modHandle) Then
        If $modHandle[0] > 0 Then
            $modHandle = $modHandle[0]
        Else
            SetError(-1)
            Return False
        EndIf
    Else
        SetError(-2)
        Return False
    EndIf
    $LoadLibraryA = DllCall($kernel32, "long", "GetProcAddress", "long", $modHandle, "str", "LoadLibraryA")
    If IsArray($LoadLibraryA) Then
        If $LoadLibraryA[0] > 0 Then
            $LoadLibraryA = $LoadLibraryA[0]
        Else
            SetError(-3)
            Return False
        EndIf
    Else
        SetError (-4)
        Return False
    EndIf
 $ThreadID = DllStructCreate('int')
    $Thread = DllCall($kernel32, "int", "CreateThread", "int", 0, "int", 0, "long", $LoadLibraryA, "long", $Func, "int", 0, "int", DllStructGetPtr($ThreadID))
    If IsArray($Thread) Then
        ConsoleWrite($Thread[0] & @CR)
        If $Thread[0] > 0 Then
            $Thread = $Thread[0]
        Else
            SetError(-5)
            Return False
        EndIf
    Else
        SetError(-6)
        Return False
    EndIf
 
    DllCall($kernel32, "int", "CloseHandle", "int", $Thread)
    
    DllClose($kernel32)

EndFunc

Credit to Busti on that. I think I also seen another example involving something with WTC_Ports' Invoke.dll. The problem is that at the current moment I don't have the knowledge required to successfully apply these examples and make them work correctly, or efficiently, for my needs.

I also seen the CoRoutine scripts, but those aren't exactly what I'm looking for, and I don't think they will get the loop time down to a reasonable amount. Any pointers or other options would be greatly appreciated. The way things stand right now, I'm considering writing a Dll in C++, but as I already stated, I'd prefer to keep it all within a single AutoIt script and the native system Dlls.

Nomad

Edited July 16, 2006 by Nomad

[Busti]

I don't remember what topic I got it from, so I can't give credit to the person who did it.

me,i removed some code from other script and changed the createremotethread to createthread, and then i asked wouter to get it work

[Nomad]

me,i removed some code from other script and changed the createremotethread to createthread, and then i asked wouter to get it work

Ok, then credit to Busti. So, did he get it to work for you?

[w0uter]

ofcourse not. its not possible the way he wanted too

[Valik]

When are people going to learn that AutoIt is not designed for multi-threading? You're trying to thread a needle with an electric line by forcing AutoIt to do things it's not designed to do.

[Nomad]

When are people going to learn that AutoIt is not designed for multi-threading? You're trying to thread a needle with an electric line by forcing AutoIt to do things it's not designed to do.

Try reading. I'm looking for any method which is going to accomplish what it is I need. If I didn't have to eat up so much time by extracting the information from the Dll Structure, which I needed for the DllCall, which I needed because AutoIt has no other way to do this... This portion of my script would only be taking 5 minutes or less of processing time instead of 4+ hours.

Instead of stating what AutoIt is not capable of, why not try offering solutions using what AutoIt is capable of. You're a Developer after all, you should know more than anyone what AutoIt can do.

[Valik]

Try reading.

Okay. *Reads*. Hmm, I see a call to CreateThread(). Damn, sure looks to me like you're trying to do multi-threading.

I'm looking for any method which is going to accomplish what it is I need. If I didn't have to eat up so much time by extracting the information from the Dll Structure, which I needed for the DllCall, which I needed because AutoIt has no other way to do this... This portion of my script would only be taking 5 minutes or less of processing time instead of 4+ hours.

What are you actually talking about? I don't see anything posted from you in the last 3 days as to what you might be talking about. All I see is an attempt to do multi-threading from somebody who obviously does not know how to use the advanced functions they are trying to use.

Instead of stating what AutoIt is not capable of, why not try offering solutions using what AutoIt is capable of. You're a Developer after all, you should know more than anyone what AutoIt can do.

Instead of spending time trying to solve your problem in a way I have repeatedly stated is impossible, why don't you spend your time not researching dead ends and actually look for finding a real method? I'm not in the habit of telling people what they can do, I tell them what they can't do.

[Nomad]

Okay. *Reads*. Hmm, I see a call to CreateThread(). Damn, sure looks to me like you're trying to do multi-threading.

What are you actually talking about? I don't see anything posted from you in the last 3 days as to what you might be talking about. All I see is an attempt to do multi-threading from somebody who obviously does not know how to use the advanced functions they are trying to use.

Did you try looking back to the post where that idea originated? Obviously not. I asked for any suggestions to get this processing time down, and wOuter suggested CreateThread. So I looked into it. I have since then stated that this concept was too complicated for me and again asked for any suggestions. Do I need to give you the post numbers... ?

The only posts I ever see from you are ragging on people and telling them they are wrong, while not suggesting a more appropriate method. Try being more helpful. If you can't show somebody a correct, or more appropriate method when you say they are wrong, then how much do you really know?

Edited July 17, 2006 by Nomad

[Valik]

The only posts I ever see from you are ragging on people and telling them they are wrong, while not suggesting a more appropriate method.

You'll never learn to think for yourself if I do all the thinking for you.

Try being more helpful.

Try being more grateful for any help you do get, especially when your code is as bad as that example is.

If you can't show somebody a correct, or more appropriate method when you say they are wrong, then how much do you really know?

Can't? Are you implying that I can't? I absolutely can. I don't. There is a difference.

[Nomad]

You'll never learn to think for yourself if I do all the thinking for you.

Try being more grateful for any help you do get, especially when your code is as bad as that example is.

Can't? Are you implying that I can't? I absolutely can. I don't. There is a difference.

That example wasn't mine, it was Busti's. I'm sure he appreciates the comment though. I have no problem thinking for myself, but everyone needs points in the right direction. We all know that you weren't born with your "vastly superior" AutoIt knowledge (or any language for that matter), you had to learn somehow.

Arrogance is a sign of weakness. You don't help because you're afraid that someone else is going to know as much as you, and then you won't be special anymore. Isn't that right? Now, if you're not going to offer help or some constructive criticism, then either ban me, or stay out of my topic.

Nomad.

[Valik]

Arrogance is a sign of weakness.

People tell me I'm arrogant but there are members on this forum who are significantly more arrogant than I am. Why don't you bitch to them sometime? I don't run around saying I'm the expert on everything/something (At least that is very rare). People say that for me. People have built up my perceived ego and level of arrogance much higher than it really is.

You don't help because you're afraid that someone else is going to know as much as you, and then you won't be special anymore. Isn't that right?

Not even close. I don't give a damn if somebody knows as much as I do. I don't give a damn about being "special". I currently have 17 AutoIt projects, 15 C++ projects and a handful of other projects in other languages to work on. I'm not going to waste my time working on other people's problems. If I spent half as much time helping as some of the forum regulars, I'd never get these projects done.

Now, if you're not going to offer help or some constructive criticism, then either ban me, or stay out of my topic.

Nomad.

Let me explain something to you. You posted some code trying to do multi-threading. Then you stated that you didn't know how to make the examples work. Given that the code you posted wasn't even remotely close to how a thread is created, I somehow came to the conclusion, based on your statement that you couldn't make the examples work that you were.... wait for it... trying to do multi-threading. It was something about the code and the text that gives off that impression - I bet it was the wording of the words. Maybe it's just me; maybe I don't understand English or something, I don't know. At any rate, I posted for the 4982 time stating that multi-threading wasn't possible. Now, at this point you went all dumbass on us. As far as I'm concerned, there was your constructive criticism. Now you know that you don't need to waste hours learning how to try and fail making a multi-threaded AutoIt script. Then you get all bitchy because I didn't read posts for the last several days to go back and find what it is that you wanted to do. I apparently made the unreasonable assumption that your stand-alone post was relevant at all.

So I guess this is all my fault. I should have realized that a post with broken code and text stating that you couldn't get it to work was in fact not related at all to anything in particular and that the world should ignore it. Instead everybody should just automatically know to go back several days worth of posts and find the actual problem that is trying to be solved. I guess it was not very constructive for somebody to come along and tell you not to waste your time pursuing a dead-end when the only sign you showed of starting down that road was a post showing broken code and stating you couldn't get it to work (Which, as stated previously, is how a significant portion of people ask for help). I mean, I'm completely in left field here. Your meaning was so clear based on your text that I'm just a moron for not getting it, right?

[Busti]

valik....youre like a machine... without errors...