-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Call With Another Arguments #3
Comments
I kinda solved it by creating small console app, that was called instead, received all arguments, that was originally passed to javaw.exe and then modyfing them and calling it in a right way. But I couldn't solve recursive calls to my console app, so it run in cycle. But still, the problem is, that it changes something for that process, so it crashes after I do all of this. "After all that said, we can finally proceed to the most exciting part: How to spoof an arbitrary process on the fly without messing things up for it. In theory, it sounds simple. There are several apparent steps we should take when re-launching the program after the interception. The process might depend on the inherited handles or the current directory, so we need to reproduce everything as precisely as possible. Which means:
But would you please explain it a little bit more, exactly how you achieve this? For example, I can't achieve to use same StartupInfo |
Image File Execution Options can determine which file to execute after interception either based on the image name or on the full path (when
I think you're on the right track with this approach. To avoid recursion, you can start the new process via CreateProcess supplying
Hmm... If you are sure that the arguments for the new process are correct, maybe it gets the wrong current directory. Some tools, such as Process Hacker, can help you to check these things.
All these steps try to mimic the way the original process was created as close as possible.
In the end, you should get something similar to the executable from #2 which does everything mentioned above but preserves the arguments. Note that, when replacing arguments, you cannot simply prefix the string with |
Wooow, you are awesome man, thanks soooo much for your help :) But anyway, wouldn't you consider to update this utility to create another option to change silently the arguments of that intercepted executable without messing anything? That would be a fantastic feature, because you can do it now by programing it yourself as I am trying to do and using your last option to call another .exe instead of original, but then there is this problem that you already solved that anybody would have to solve again :D |
I already solved it for myself successfully, so thanks again bro :) But I overcame recursion by switching javaw.exe with java.exe, but I will try to modify it to work with just a single executable by using DEBUG_PROCESS and NtRemoveProcessDebug(), because for my use case, DebugActiveProcessStop wasn't working, probably because of what you said in your article:
I will post this solution here immediately after I successfully do it, so you can improve this fantastic utility by this ability to modify arguments silently :) |
Hi,
I found your program and is very cool :) So thanks so much !!!
But I have a question: Is it possible to have the same program executed as it should originally but with some arguments added?
To explain it more, I need to add debug arguments to javaw.exe to be able to run something in debug mode.
It's called from one process like this: javaw.exe --lots-of-original-arguments.
what I need to do is to intercept javaw.exe with your tool and do this:
javaw.exe --few-added-arguments --lots-of-original-arguments.
And actually, to say exactly what are those arguments of mine, I want to call it like this:
javaw.exe -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 --lots-of-original-arguments
Is it possible?
Thanks so much!!!
The text was updated successfully, but these errors were encountered: