Let's see why Dependency Walker wasn’t in it. If you press F9, then we will see that the same crack works several more times before finally a window appears with a list of current processes.
We put the breaks on the places where these lines are accessed, click on the “Target program” button in WPE Pro and look at the place we stopped at: This time everything is exactly the opposite - there was found both the line “CreateToolhelp32Snapshot” and “EnumProcesses”. Perhaps the application gets their address in run-time using the WinAPI function GetProcAddress, so let's look at referenced text strings. We look at the intermodular calls of the module and see that neither CreateToolhelp32Snapshot nor EnumProcesses are here. If you wish, you can read about the difference between these methods, for example, here. Using the EnumProcesses function (an example can be found, for example, here ).Using a bunch of CreateToolhelp32Snapshot, Process32First and Process32Next functions (an example can be found, for example, here ).There are two main ways to get the list of current processes in WinAPI: For example, let's launch the 64-bit version of Dependency Walker and find out why WPE Pro cannot display it in the list of processes available for interception. Then we take OllyDbg into our hands and load “”. It seems that this time we don’t have to shoot anything. Have you downloaded? Now let's check if it is covered with some kind of packer or tread: We will consider version 0.9a, because it works on the latest versions of Windows.
You can do this on the official sniffer website, where two versions are offered for download at once - 0.9a and 1.3. So what needs to be done first? That's right, download WPE Pro itself. How the process went and what came of it, read under the cut. Googling a little, I found that there are no ready-made analogues of WPE Pro with 圆4 support (if they do exist, I would be grateful for the links in the comments - please note that this is about Windows). Unfortunately, using it in this situation was not very convenient - the application under study sent data to different IP addresses, each time opening a new port. It just so happened that for one of the problems that arose, I just needed to intercept packets from a 64-bit application, and I looked in the direction of Wireshark.
He performs his task perfectly, but he has one unpleasant drawback - he does not know how to work with 64-bit applications. Perhaps many of you have heard about him in various forums devoted to online games, because it is precisely in order to gain advantages in various games that this sniffer is used. Perhaps the most popular sniffer to date, working on the principle of intercepting calls to certain WinAPI functions, is WPE Pro. In this case, there is no need to find out the IP addresses and ports that this program uses (especially considering the fact that there can be quite a lot of them), and you can simply say "I want to intercept all the packets of this application." Convenient, isn't it? Both this and the other method have their pros and cons, however, if the task requires packet capture from a specific well-known application, then the second option is usually more convenient.
Some software listens to the specified network interface (for example, Wireshark, where it is implemented using the Pcap library ), and some intercepts the calls of those responsible for interacting with the WinAPI network. Despite the fact that their ultimate goal is the same (intercepting packets that meet certain criteria), they achieve it in completely different ways. I think that most of the local inhabitants are familiar with the concept of sniffer.