|
You can only capture what the game sends to you.
|
|
|
|
|
Feedback will depend on the hardware and software in use. Check the documentation for the game.
|
|
|
|
|
So you want to use "some" output from the game, so that you can generate e.g. seat vibration, gun recoil, flashing of LEDs etc - is that right?
If I get it right: You want to generate seat vibration, gun recoil etc., based on some other feedback from the game. What kind of game output do you want to capture to generate these effects? Text messages? Synthetic speech or other sounds generated by the game? Visual effects on the screen? Are you expecting to capture the image of a gun being fired, recognize it as such, and from that generate your recoil effect?
For a vintage text-only game (such as classical Adventure or MUD), text capture would be trivial and analyzing it reasonably simple. But if you want to generate additional effects triggred by sound or graphics, and do it in a general, game-independent way, then you are up for a huge task. You simply can't do it in any reasonable way. If text output is available only as graphic character images on the screen, you cannot even do text anlysis. (Well, you might try with some OCR functionality, but chances are that it would fail miserably.)
If you had access to the source code of the game, you could probably - as the game initiates sound/visible effects - write to a textual log an indication of the effect genereated, and route it to some output available to your recoil or vibration or whatever functions you want to add. It would require that you can modify the game source code, and it would be specific to that game.
If you are hoping to capture non-text output from an arbitrary game, without having to "get under the hood" of the game, I cannot see how you can make it.
|
|
|
|
|
Let me try a simple thing. Games send rumble (vibration) or FFB data to gamepad right? which gives information like how much vibration applied to which motor. Is there a way I can capture that messages?
|
|
|
|
|
It seems as if you assume that all sorts of output more or less by definition go through some standard code that is instrumented for hooking up listeners (or piping the information through a plugin for processing before bneing passed on).
While such hook (/plugin) mechanisms have become increasingly more common in recent years, they are always explicitly programmed in the software you want to hook into. It could be implemented in some library, not necessarily in the application specific code.
Games have always had extreme performace requirements, and they use a big bag of tricks to avoid a waste of resources. This is not where you would expect the developers to waste CPU cycles on checking the list of hooked procedures, both because there usually wouldn't be any, and because it could mess up time dependent routines, introducing unexpected delays. Game software often works at a low level with the hardware available, for performance reasons, avoiding over-generalized, less efficient libraries.
If these games e.g. use standard Windows message passing to communicate with that gamepad, you might be able to intercept those Windows messages. Don't expect it to be straightforward - sitting outside a process and spying on every Widows message it sends, opens a well of security holes. I wouldn't waste too much enery on it: Most likely, the game code talks directly to a harware driver that implements no hook mechanism.
Your safest bet would be to make a physical probe that senses the signal going to the gamepad. What kind of interface is used? For USB, you can find "breakout boxes" that listens to the data in and out lines: The very most primitive ones give you the physical line voltage; more fancy ones process it into digital messages. For wireless systems, e.g. Bluetooth, probes usually give you the payload of the BT frame, but don't expect any higher level protocol interpretation - these probes are essentially used by people working at the level of signal transmission, not application level protocols. Furthermore, BT traffic is frequently encrypted, which might give you trouble. Even though a USB breakout requires intercepting the cable, in may be a lot easier because the channel is nor likely to be encrypted.
|
|
|
|
|
The only thing that comes close to what you need is TV with "captions". If the game has a logging / PLAYBACK ability, you might be able to tap into that.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Hello,
I have seen a retry loading in JAVA using "Quote: AjaxElementLocatorFactory
". Are there any equivalent class or usage in c# selenium automation library ?
Quote: public GoogleResultsPage() {
PageFactory.initElements(new AjaxElementLocatorFactory(driver, 15), this);
}
|
|
|
|
|
I have a standard C# .exe-file and inside it I have a byte[256] array with a counting sequence (0,1,2...254,255). If I open the .exe-file in a hex-editor, then I can easily find my counting sequence and edit the data in the array. But what if I want to make the array larger, what should I then do? I still want the .exe-file to work fine after the changes, so the purpose of the .exe-file is not just to hold array data.
|
|
|
|
|
Unless you have the sourcek, you can't. It's not just about the length of the declaration, but most loops inside the application would not expect a larger value.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: Unless you have the source, you can't.
Now, now, Mr. Vluggen. That's not a can-do attitude!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: That's not a can-do attitude!
Never claimed one; I'm rational.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
So what's the workaround? In embedded C-programming you can place things at specific addresses through the linker script. Is there not something similar in C# so I can place the array in the end of the file?
|
|
|
|
|
You could decompile the assembly; there's tools for that. That would probably be a breach of copyright.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Could you please provide more information on what that would allow me to do and how I would do that? Breach of copyright will not be a problem because I will write the code myself.
|
|
|
|
|
arnold_w wrote: Breach of copyright will not be a problem because I will write the code myself.
It is; if you had written the assembly, you'd already have the sourcecode. Meaning you are modifying something that isn't yours. Also, copyright would mean that such things aren't allowed - even though it is technically possible.
If you can write the code, then the best way would be to indeed write the code yourself - meaning, a new application that does the same as the one you are now trying to hack.
See, most people here write code and it is their source of income. You are asking here how to change a compiled program - that code you want to change might be written by a member 
If you seriously want to decompile, change the code to your needs and recompile (and no, not going to explain "what that allows you to do and how"), then Google should be able to explain that within a day.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
??? Conspiratorial much? I want to bake in an array of server paths into my .exe-file so I don't need an external file with that information. The number of paths could increase and hence I would need to make the array larger. Of course, I could assume a worst case scenario and allocate an array with a lot of empty space, but surely there must be a way to accomplish this? And btw, the .exe will modify the paths in the array itself, I don't want to have to recompile the code each time there are more paths.
|
|
|
|
|
arnold_w wrote: ??? Conspiratorial much?
Not going to answer your questions anymore.
Enjoy.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
What you're trying to do is something that very, very few people ever mess around with let alone succeed at.
You're going to put FAR more work into writing another application that can modify your compiled application than you would EVER do by simply adding the servers to the source code and recompiling!
That's what you're doing with modifying an .EXE anyway, but you're just trying to do it the super-difficult way.
|
|
|
|
|
If he owned the source and knew what to do with it, there wouldn't be a question. For all we know, this might be a medical application.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Yeah. I see no reason at all for him to do what he's describing unless he didn't have the source for the app. Like you, to me that means a vendors application.
|
|
|
|
|
If you read above, you'll see that I was asking if there was something similar to a C-programming linker script in C# and I asked if it was possible to place the array in the end of the .exe-file. Why would I be interested in those approaches if I didn't have the source code and am able to recompile it?
I was thinking someone would suggest something along the lines of putting the array in a separate dll and then do something clever with assemblies (which I have no experiences with). If this is possible, this would be perfectly fine with me. Again, how could I use this if I was trying to hack someone else's .exe-file and not implement in my own project?
If you think about it, this would be very useful to avoid having a (separate) file that remembers the user's preferences (e.g. list of recently used documents, use spaces instead of spaces, etc). When you exit the application, you would just update the array that contains the user preferences (of course, since the executing file it locked, you first rename the executing file, then create a new file with the original file name and then self-destruct the original file).
modified 4-May-20 4:30am.
|
|
|
|
|
arnold_w wrote: If you think about it, this would be very useful to avoid having a (separate) file that remembers the user's preferences (e.g. list of recently used documents, use spaces instead of spaces, etc). When you exit the application, you would just update the array that contains the user preferences (of course, since the executing file it locked, you first rename the executing file, then create a new file with the original file name and then self-destruct the original file).
Huh? Are you serious? Or do I completely misunderstand what you want to do?
It sounds to me as if you want to save one user's preferences in the executable file itself, writing back a modified .exe after removing the old one. Right? If that is it, it is the craziest proposal I have seen for a while!
Re. user preferences: We are not in the Linux world. Using separate files (type ".ini" or ".rc_something") is NOT the proper way to do it. User preferences are stored in under HKCU in the registry. How do you plan to handle different users of the same executable - or do you plan to give each user his own executable for his own private modification?
Under any circumstances: Consider executables as non-writable files - most of all in a managed world. You have left the management of modules to dotNet, and you cannot poke around with a long stick into that management. What you are suggesting is a sort of self-modifying code. Leave that to the assembler guys! Self-modifying code is completely unmanagable! (not only in the sense of dotNet, but generally speaking)
Sure, you are only modifying parameters to some funcitons, but it is not seen as external input at run time, it is hidden within the code itself. So it appears as the code has been changed from one run to another, with no external input. That is functionally identical to the code modifying itself.
In a managed runtime, you do not control the memory location of the managed modules - that is an essential part of the management (that you have left to others). Although you can build a single, fully compiled .exe-file from C#, this is really not the standard way: Assemblies are distributed in a "half-compiled" form, as CIL (Common Intermediate Language), where the final compilation steps are done when the assembly is first used. Until this last complilation is done (this is where differnet instruction sets etc. are taken into consideration), memory addresses are not known. At run time, the addresses may vary from one machine/CPU to another.
So there is no "linker script" for the entire application the way you seem to expect. It is all done dynamically. When you create a self-contained .exe, you are really doing part of the run time handling in advance. But since the "real" dotNet assumes that this is done dynamically, there are no provisions for e.g. controlling memory addresses from outside. Memory placement is handled in other ways, so there is no need to. Or reason to. It doesn't belong in a managed environment.
If you feel that your proposed solution is the only viable alternative, then I don't think managed code is for you. Consider assembly code, or possibly pure C.
|
|
|
|
|
arnold_w wrote: something similar to a C-programming linker script in C#
No, there isn't.
arnold_w wrote: possible to place the array in the end of the .exe-file
No, it's not.
arnold_w wrote: this would be very useful to avoid having a (separate) file that remembers the user's preferences
It's also the most insecure way of storing options. .EXE's are locked by the system while they are loaded into a process, so a running .EXE cannot "rewrite itself" (without going though extraordinary lengths) to update options selected by the user. This has nothing to do with C#, or any language, but with how Windows itself works.
Why is storing writable options in an executable insecure? Think about it. What else is very desperate to "rewrite" an .EXE? Hint: Viruses.
|
|
|
|
|
I would strongly question the suitabilty of C# (or any other sort of "managed" code, e.g JVM based) for embedded code.
If your embedded code is executed on a processor with at gigabyte of RAM, you might successfully run e.g. a user interface written in a dotNET (or JVM) language. But for hardware-related functions, such as handling I/O device buffers or interrupt handlers, managed code is not your first choice.
|
|
|
|
|
I'm not writing an embedded application, it will be executed on a standard PC running Windows 10. The embedded exempel was just an analogy.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
