There is a single player PC game with an in-game console which allows users to execute commands and set variables. My goal is to be able to, with an external program, execute commands as if they were entered through the console and to change the value of the variables.
I have experience programming, but have never done any game development and I also don't have very much knowledge on the inner-workings of programs.
As a start, I entered the command "set myvar myval" in the console and then did a search for "myval" in the program's memory (using HxD). I found multiple instances of the complete command "set myvar myval" and only one instance of just the value of the variable alone. Changing the value at this location changed the value in game, so I know it was the correct location of the variable's value. In a program, however, how would I know where to look for this variable's value? Are there only certain locations in the game's memory which would house the value, and within that space, would the values of the variables always be stored in the same range of memory? How would I increase the length of the value without crashing the program?
Are there any resources available online where I can learn about what I'm trying to do?
What you are trying to do is not so easy. There are no "certain locations" and you certainly can't rely on the location being always the same (which it most likely wont). And if the games has configurable variables, it likely will allocate memory on the fly for it. So the only chance I can see is, that you disassemble the code and look where the function is that creates such a variable. then you can call it with the appropriate parameters.
In the golden age of WoW game, there was one tool that was doing thing you want by seaching program memory for certain values. So if you wanted very expensive item, you just had to search for that item´s ID, and then you replaced every occurence of your current item´s ID with ID of that expensive item. It was perfect, but it worked only until you tryied to log-out and log-in again. ID of your new item wasn't saved on server, so old item stayed on it`s place in you inventory.
Back on topic. You were able to find instances of set myvar myval string, but these instances aren't actually code of operation and of course the value of the myvar. Game commands are usually parsed and interepreted. If they were compiled, everything would be easier (as you would only need to find location of compiled code, and then put there your own code), but currently, you must find find the location of your variables by many tests.
The only two ways of finding the memory locations used by game are to disassembly, or to perform tests and statistically find the location - but in the world of dynamic memory allocation, this is almost impossible.
Changing 'length of the value' will usually surely cause problems in program, as the value`s exceed in memory can affect values of another ´variables´ important for program run.
Related
NetLogo being interactive makes debugging easy, but I yet to find any tools available for setting breakpoints and stepping through code.
Please guide me if such exist. Or I can achieve the same with the current setup available.
I am not aware of such a tool if one exists. For debugging I use meaningful print statements. First I make a switch as a global parameter to set the debug mode on and off, then I add a statement to each method that prints which method updates which variable and in which order they were called (if debug mode is on).
I also use profiler extension which shows how many times each method was called and which one is the most or least time consuming one.
Not existing currently. Still, you can use one of the alternatives from above or you might take a look at user-message (https://ccl.northwestern.edu/netlogo/docs/dictionary.html#user-message), which will pop up a dialog. This will also block the execution at that step, although not providing you with a jump-to-next-line mechanism, for me this solution proved to be the best.
Another possibility is to do the debugging in any modern browser if/when NetLogo Web produces source maps. This way one can set breakpoints in the NetLogo code and use Chrome or FireFox or IE11's developer tools on the NetLogo code.
I have used user-message and inspect together as the debugging tool for NetLogo. Here is a video demo on how to use them to identify the cause of an error.
the reason for using inspect is to examine all properties of an object when we are not sure where exactly went wrong
using user-message to print out some instruction, output some outcome and halt the program
I found Netlogo somewhat difficult to debug until I discovered print statements.
I basically zone in on the module that is causing problems and I add print statements within critical blocks to inspect the state of the variables. I have find this to be an effective way to debug.
I do wish the documentation was more comprehensive, with more code examples. Perhaps some good Samaritan will take it up as a project.
NB: Note that this approach is not just a convoluted way to achieve the exact same benefit that using random-seed gives. Using random-seed is an ex-ante way to reproduce a run. However, for rare errors, it is impractical to manually change random-seed (maybe a few hundred times) until you hit by chance a run in which the error appears. This approach, instead, makes you able to reproduce the error after it occurred, potentially saving tons of time by letting you reproduce that rare run ex-post.
Feel free to download this blueprint from the Modelling Commons if anyone finds it useful and wants to save the time to set it up.
Not a NetLogo feature, but an expedient I've devised recently.
Some errors might occur only rarely (for example, every few hundred runs). If that is the case, even just reproducing the error can become time consuming.
In order to avoid this problem, the following arrangement can be used (note that the code blocks only contain very few lines of code, the vast majority is only comments).
globals [
current-seed
]
to setup
clear-all
reset-ticks
manage-randomness
end
to manage-randomness
; This procedure checks if the user wants to use a new seed given by the 'new-seed' primitive, or if
; they want to use a custom-defined seed. In the latter case, the custom-defined seed is retrieved
; from the 'custom-seed' global variable, which is set in the Interface in the input box. Such variable
; can be defined either manually by the user, or through the 'save-current-seed-as-custom' button (see
; the 'save-current-seed-as-custom' procedure below).
; In either case, this selection is mediated by the 'current-seed' global variable. This is because
; having a global variable storing the value that will be passed to the 'random-seed' primitive is the
; only way to [1] have such value displayed in the Interface, and [2] re-use such value in case the
; user wants to perform 'save-current-seed-as-custom'.
ifelse (use-custom-seed?)
[set current-seed custom-seed]
[set current-seed new-seed]
random-seed current-seed
end
to save-current-seed-as-custom
; This procedure lets the user store the seed that was used in the current run (and stored in the
; 'random-seed' global variable; see comment in 'manage-randomness') as 'custom-seed', which will
; allow such value to be re-used after turning on the 'use-custom-seed?' switch in the Interface.
set custom-seed current-seed
end
This will make it possible to reproduce the same run where a rare error occurred, just by saving that run's seed as the custom seed and switching on the switch.
To make things even more useful, the same logic can be applied to ticks: to jump exactly to the same point where the rare error occurred (maybe thousands of ticks after the start of the run), it is possible to combine the previous arrangement about seeds and the following arrangement for ticks:
to go
; The first if-statement allows the user to bring the run to a custom-defined ticks value.
; The custom-defined ticks value is retrieved from the 'custom-ticks' global variable,
; which is set in the Interface in the input box. Such variable can be defined either
; manually by the user, or through the 'save-current-ticks-as-custom' button (see the
; 'save-current-ticks-as-custom' procedure above).
if (use-custom-ticks?) AND (ticks = custom-ticks) [stop]
; Insert here the normal 'go' procedure.
tick
end
to save-current-ticks-as-custom
; This procedure lets the user store the current 'ticks' value as 'custom-ticks'. This will allow
; the user, after switching on the 'use-custom-ticks?' switch, to bring the simulation to the
; exact same ticks as when the 'save-current-ticks-as-custom' button was used. If used in combination
; with the 'save-current-seed-as-custom' button and 'use-custom-seed?' switch, this allows the user
; to surely and quickly jump to the exact same situation as when a previous simulation was interrupted.
set custom-ticks ticks
end
This will make it possible not only to quickly jump to where an otherwise rare error would occur, but also, if needed, to manually change the custom-ticks value to a few ticks earlier, in order to be able to observe how things build up before the error occurring. Something that, with rare errors, can otherwise become quite time-consuming.
NetLogo is all about keeping the code in one spot. When I run a simulation in 2D or 3D, I usually have an idea what my whole system is going to produce at timepoint X. So when I'm testing, I usually color code my agents, the "turtles", around a variable I'm tracking (like number of protein signals etc.)
It can be as simple as making them RED when the variable your wondering about is over a threshold or BLUE when under. Or you can throw in another color, maybe GREEN, so that you track when the turtles of interest fall within the "optimal" range.
This is probably a simple question, but:
is it possible to see the value for the last variables calculated as we go through the debugging process step-by-step?
I know I can set the variables I want in the Watch windows when debugging, or see the values of each variable during debugging by placing the mouse over the variable in the code, but this is annoying and time consuming.
The "Locals" window seemed initially that it could do the trick, but I only manage to make it show the variables in an order that is totally random, and I have hundreds of variables (many are arrays), so it becomes useless.
Any thought on this would be more than welcomed! :)
Best
As the title says, I want to associate a random bit of data (ULONG) with a running process on the local machine. I want that data persisted with the process it's associated with, not the process thats reading & writing the data. Is this possible in Win32?
Yes but it can be tricky. You can't access an arbitrary memory address of another process and you can't count on shared memory because you want to do it with an arbitrary process.
The tricky way
What you can do is to create a window (with a special and known name) inside the process you want to decorate. See the end of the post for an alternative solution without windows.
First of all you have to get a handle to the process with OpenProcess.
Allocate memory with VirtualAllocEx in the other process to hold a short method that will create a (hidden) window with a special known name.
Copy that function from your own code with WriteProcessMemory.
Execute it with CreateRemoteThread.
Now you need a way to identify and read back this memory from another process other than the one that created that. For this you simply can find the window with that known name and you have your holder for a small chunk of data.
Please note that this technique may be used to inject code in another process so some Antivirus may warn about it.
Final notes
If Address Space Randomization is disabled you may not need to inject code in the process memory, you can call CreateRemoteThread with the address of a Windows kernel function with the same parameters (for example LoadLibrary). You can't do this with native applications (not linked to kernel32.dll).
You can't inject into system processes unless you have debug privileges for your process (with AdjustTokenPrivileges).
As alternative to the fake window you may create a suspended thread with a local variable, a TLS or stack entry used as data chunk. To find this thread you have to give it a name using, for example, this (but it's seldom applicable).
The naive way
A poor man solution (but probably much more easy to implement and somehow even more robust) can be to use ADS to hide a small data file for each process you want to monitor (of course an ADS associated with its image then it's not applicable for services and rundll'ed processes unless you make it much more complicated).
Iterate all processes and for each one create an ADS with a known name (and the process ID).
Inside it you have to store the system startup time and all the data you need.
To read back that informations:
Iterate all processes and check for that ADS, read it and compare the system startup time (if they mismatch then it means you found a widow ADS and it should be deleted.
Of course you have to take care of these widows so periodically you may need to check for them. Of course you can avoid this storing ALL these small chunk of data into a well-known location, your "reader" may check them all each time, deleting files no longer associated to a running process.
When I'm debugging, I'm usually looking at about 5000 processes, each of which could be one of about 100 gen_servers, fsms, etc. If I want to know WHAT an erlang process is, I can do:
process_info(pid(0,1,0), initial_call).
And get a result like:
{initial_call,{proc_lib,init_p,5}}
...which is all but useless.
More recently, I hit upon the idea (brace yourselves) of registering each process with a name that told me WHO that process represented. For example, player_1150 is the player process that represents player 1150. Yes, I end up making a couple million atoms over the course of a week-long run. (And I would love to hear comments on the drawbacks of boosting the limit to 10,000,000 atoms when my system runs with about 8GB of real memory unused, if there are any.) Doing this meant that I could, at the console of a live system, query all processes for how long their message queue was, find the top offenders, then check to see if those processes were registered and print out the atom they were registered with.
I've hit a snag with this: I'm moving processes from one node to another. Now a player process can have 3 different names; player_1158, player_1158_deprecating, player_1158_replacement. And I have to make absolutely sure I register and unregister these names with precision timing to make sure that a process is always named and that the appropriate names always exist, AND that I don't try to register a name that some dying process already holds. There is some slop room, since this is only used for console debugging of a live system Nonetheless, the moment I started feeling like this mechanism was affecting how I develop the system (the one that moves processes around) I felt like it was time to do something else.
There are two ideas on the table for me right now. An ets tables that associates process ids with their description:
ets:insert(self(), {player, 1158}).
I don't really like that one because I have to manually keep the tables clean. When a player exits (or crashes) someone is responsible for making sure that his data are removed from the ets table.
The second alternative was to use the process dictionary, storing similar information. When my exploration of a live system led me to wonder who a process is, I could just look at his process dictionary using process_info.
I realize that none of these solutions is functionally clean, but given that the system itself is never, EVER the consumer of these data, I'm not too worried about it. I need certain debugging tools to work quickly and easily, so the behavior described is not open for debate. Are there any convincing arguments to go one way or another (other than the academic "don't use the _, it's evil" canned garbage?) I'd be happy to hear other suggestions and their justifications.
You should try out gproc, it's a very convenient application for keeping process metadata.
A process can be registered with several names and you can associate arbitrary properties to a process (where the key and value can be any erlang term). Also gproc monitors the registered processes and unregisters them automatically if they crash.
If you're debugging gen_servers and gen_fsms while they're still running, I would implement the handle_info functions for these behaviors. When you send each process a {get_info, ReplyPid} tuple, the process in question can send back a term describing its own state, what it is, etc. That way you don't have to keep track of this information outside of the process itself.
Isac mentions there is already a built in way to do this
I've been using ReadDirectoryChangesW to monitor a particular portion of the file system. It rather nicely provides a partial pathname to the file or directory which changed along with a clue about the nature of the change. This may have spoiled me.
I also need to monitor a particular portion of the registry, but it looks as if RegNotifyChangeKeyValue is very coarse. It will tell me that something under the given key changed, but it doesn't seem to want to tell me what that something might have been. Bummer!
The portion of the registry in question is arbitrarily deep, so enumerating all the sub-keys and calling RegNotifyChangeKeyValue for each probably isn't a hot idea because I'll eventually end up having to overcome MAXIMUM_WAIT_OBJECTS. Plus I'd have to adjust the set of keys I'd passed to RegNotifyChangeKeyValue, which would be a fair amount of effort to do without enumerating the sub-keys every time, which would defeat a fair amount of the purpose.
Any ideas?
Unfortunately, yes. You probably have to cache all the values of interest to your code, and update this cache yourself whenever you get a change trigger, or else set up multiple watchers, one on each of the individual data items of interest. As you noted the second solution gets unwieldy very quickly.
If you can implement the required code in .Net you can get the same effect more elegantly via RegistryEvent and its subclasses.