Once again, we are lucky that what is going on is really simple. Once our score value changes, we should see something similar to this: We’ve now attached a debugger to Solitaire, and we can view what is happening by clicking the “AutoHack” menu item, then selecting “AutoHack window”. We begin by clicking on the “AutoHack” menu item and then selecting “Enable Debugger.” Once this is done, right-clicking on the blank area before the address in our addresses window pops up a context menu – select AutoHack from it. Fortunately, TSearch makes this easy for us. So, where do we go from here? We need to find something called the static pointer, which, we will see, stores the score in a register. With this, the score value will be at a different memory address each time. Well, it turns out that Solitaire uses dynamic memory allocation (DMA). 2.0.2 Solitaire has DMA? Seriously.? Solitaire? 0? If we were to repeat the TSearch process, we would find that our score is now at a different memory address. Restarting Solitaire and executing that line again – the score is. But, let’s restart the game, and see if this holds for all instances. ReadProcessMemory(hProcess, (LPVOID) 0xAA268, &score, sizeof( int), 0) We see that our score is stored at the address 0xAA268 (yours may be different). Note: If you’re following this and happen to still get more than one address, then see which one changes with the Solitaire score. My score happened to decrease to 24, so I searched for 24. This will search through the 74 addresses for our new value. Once the score decreases again, you can search for a new value, clicking the Search Next button (to the right of Search, the magnifying glass with … below it). 74 is still quite a lot, so where to go from here? We can just wait a few seconds since Solitaire decreases the total score by two every ten seconds. I went back to TSearch, and searched for this value (as a four byte type), getting 74 results. Going back to the Solitaire window, I just clicked on an Ace or two, and revealed a few cards to get a score of 30. To cut down on the time, we need to raise our score to something else. For memory searching, zero is not such a good number. We notice that the starting score of Solitaire is zero. Now that TSearch is focused on Solitaire, we can begin. What we’re going to do is search for our score value in memory. To get started, we need to open TSearch, hit the “Open Process” button (top left), and then find our Solitaire process ( SOL.EXE, most likely). So, the easy way sounds better? 2.0.1 Getting the current score Or, you can take the easy way, and find the static pointer and trace it to the score in memory (this takes a minute or two). You can choose to go through hundreds (thousands?) of lines, segment by segment, setting breakpoints on interesting parts, in hopes of getting that elusive address (that poor guy who did this). The long (and painful) way is what the author of the other Solitiare high score program did. After all, what use is there in making a high score table without being able to get high scores? There are a few ways to get the score, mainly the long way and the short way. Probably, the most important thing in this whole project is getting the score. This article will be using TSearch and OllyDbg v1.10. There will be a tiny amount of x86 ASM in one of the sections, but it is simple enough that it doesn’t require any real knowledge of ASM to understand.
A decent knowledge of C++ Win32 API programming is needed.
In this article, I will detail the process of making such a handy plug-in. After a few minutes of searching, I realized that it was hopeless – so I decided to make my own. There would be no need to run the Solitaire game through another process, or have anything that would require the user to do anything. What I wanted was something that would integrate with the actual Solitaire game. However, none had the functionality that I desired. I even happened to come across an article on this very site.
Solitaire greatest hits 2.0 windows#
0 kommentar(er)
