| View previous topic :: View next topic |
| Author |
Message |
gir489
Grandmaster Cheater
![]() Reputation: 14
Joined: 03 Jan 2012
Posts: 835
Location: Maryland, United States
|
 Posted: Sun Feb 05, 2017 10:01 pm Post subject: Need help with Process.NET PatternScan |
 |
|
I couldn't figure out a way to get atom0s' C# SigScanner to work under 64-bit compile mode, as it would just always return 0. So, I've had to instead rely on Process.NET. The code for using atom0s' SigScanner was awful, but it was fast and it worked. The code for Process.NET looks beautiful, but it's super slow. It takes 23 seconds to finish the scan for two signatures, whereas atom0s' SigScanner.cs took <1 per scan.
This is how I'm doing it:
| Code: | System.Diagnostics.Process[] process = System.Diagnostics.Process.GetProcessesByName("re7");
processHandle = OpenProcess(0x38, false, process[0].Id);
ps = new ProcessSharp(process[0], Process.NET.Memory.MemoryType.Remote);
var module = ps["re7.exe"];
var scanner = new PatternScanner(module);
ammoLocation = scanner.Find(new DwordPattern("0F 85 ? ? ? ? 45 89 F1 C6 44 24")).BaseAddress;
medkitLocation = scanner.Find(new DwordPattern("0F 84 ? ? ? ? 41 B9 ? ? ? ? C6 44 24 ? ? E8")).BaseAddress; |
It seems to be doing everything to limit its search area, such as using the BaseAddress from re7.exe's module location, and its size, which is nice. Like I said, makes the code look nice, but it runs AWFULLY slow. My only guess looking at the code is LINQ isn't very fast at doing binary compares...
Ideas? |
|
| Back to top |
|
 |
STN
I post too much
 Reputation: 42
Joined: 09 Nov 2005
Posts: 2672
|
| Posted: Sun Feb 05, 2017 10:46 pm Post subject: |
|
|
You can optimize it all you want but you will still be limited by the speed of the language. .Net languages are slow so maybe it's not the algo?
I use Quick Search Algorithm (saw someone else use it, copied) and it's fast. Combined with multi-threading, you can reduce the time to a few seconds. Before that, i used dll injection and the results were blazing fast even with shitty code (masm).
I don't know about C# examples though so can't help but maybe you can implement multithreading ?
_________________
|
|
| Back to top |
|
|
gir489
Grandmaster Cheater
![]() Reputation: 14
Joined: 03 Jan 2012
Posts: 835
Location: Maryland, United States
|
|
| Back to top |
|
|
Dark Byte
Site Admin
 Reputation: 458
Joined: 09 May 2003
Posts: 25291
Location: The netherlands
|
| Posted: Mon Feb 06, 2017 12:03 am Post subject: |
|
|
One frequent cause for slow scanning is calling readProcessMemory too often with too little sizes
_________________
Do not ask me about online cheats. I don't know any and wont help finding them.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
gir489
Grandmaster Cheater
![]() Reputation: 14
Joined: 03 Jan 2012
Posts: 835
Location: Maryland, United States
|
| Posted: Mon Feb 06, 2017 12:29 am Post subject: |
|
|
| Dark Byte wrote: | | One frequent cause for slow scanning is calling readProcessMemory too often with too little sizes |
I thought of that as well, but the PatternScanner class loads the entire module to a buffer. Albeit, that's probably not the best way to do it, since you could run in to memory exhaustion issues real fast, it only calls ReadProcessMemory once, and that takes <1 second. The biggest time consumers are the two Scan methods, each taking about 12 seconds a piece.
EDIT: So I found the problem. It mostly had to do with RE7's EXE being half empty.
Basically from 0x140000000 to 0x1473B1000, is all garbage (About 121MBs). So I wrote a reimplementation of PatternScanner, and added an overloaded constructor that takes an offset, that allowed me to add an offset to the base address when calling PatternScanner.
So now my use case looks like this:
| Code: | ps = new ProcessSharp(process[0], Process.NET.Memory.MemoryType.Remote);
var module = ps["re7.exe"];
var scanner = new PatternScanner(module, 0x73B1000);
ammoLocation = scanner.Find(new DwordPattern("0F 85 ? ? ? ? 45 89 F1 C6 44 24")).BaseAddress;
medkitLocation = scanner.Find(new DwordPattern("0F 84 ? ? ? ? 41 B9 ? ? ? ? C6 44 24 ? ? E8")).BaseAddress; |
Only takes about 3 seconds now to find both patterns. |
|
| Back to top |
|
|
panraven
Grandmaster Cheater
![]() Reputation: 55
Joined: 01 Oct 2008
Posts: 942
|
| Posted: Mon Feb 06, 2017 2:33 am Post subject: |
|
|
@STN:
Is your "Quick Search Algorithm" a modified one of this
http://www-igm.univ-mlv.fr/~lecroq/string/node19.html ?
As the original algorithm seems doesn't handle wildcard/mask,
it would be a good example to learnt if can be shared.
bye~
_________________
- Retarded. |
|
| Back to top |
|
|
gir489
Grandmaster Cheater
![]() Reputation: 14
Joined: 03 Jan 2012
Posts: 835
Location: Maryland, United States
|
|
| Back to top |
|
|
panraven
Grandmaster Cheater
![]() Reputation: 55
Joined: 01 Oct 2008
Posts: 942
|
| Posted: Mon Feb 06, 2017 3:53 am Post subject: |
|
|
Thank you gir489.
It seems DarthTon has include the said algorithm with a sub-pattern before first wildcard of the original pattern.
_________________
- Retarded. |
|
| Back to top |
|
|
atom0s
Moderator
 Reputation: 198
Joined: 25 Jan 2006
Posts: 8517
Location: 127.0.0.1
|
| Posted: Mon Feb 06, 2017 10:04 pm Post subject: |
|
|
The SigScanner I wrote in C# was just a direct port of dom1n1k and Patricks from ages ago. This was back when processes were less than like 600MB of RAM. In current age games I would not recommend it as it is not that optimized and does not handle how many games today handle memory.
You are better off writing your own interpretation of things, using threads and dividing up the workflow based on pages/CPU cores etc. to take the most advantage out of current hardware.
_________________
- Retired. |
|
| Back to top |
|
|
gir489
Grandmaster Cheater
![]() Reputation: 14
Joined: 03 Jan 2012
Posts: 835
Location: Maryland, United States
|
| Posted: Tue Feb 07, 2017 2:56 pm Post subject: |
|
|
| atom0s wrote: | The SigScanner I wrote in C# was just a direct port of dom1n1k and Patricks from ages ago. This was back when processes were less than like 600MB of RAM. In current age games I would not recommend it as it is not that optimized and does not handle how many games today handle memory.
You are better off writing your own interpretation of things, using threads and dividing up the workflow based on pages/CPU cores etc. to take the most advantage out of current hardware. |
I ended up using Boyer-Moore-Horspool, as it produced the fastest results. The original project was using Naive search, which took about 1,337 milliseconds to find the pattern for RE7's ammo address, with the BaseAddress shifted by 0x73B1000. It takes the BMH algorithm 31 milliseconds. |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
