How to get the debuggee's command line in WinDbg? - windbg

Is there any extension command could to do so? I just want to the the whole command line including all parameters.

Information like the command line args are stored in the PEB (Process Environment Block).
You can find a list of common commands here.
!peb will display the PEB.

try vercommand
it's a lot simpler than !peb
this is a good place to get you started:
http://windbg.info/doc/1-common-cmds.html#2_general_cmds

Related

Prevent printing to command line in MATLAB

Before you answer, I'm not looking for the functionality of ; to suppress command line printing.
I have a set of scripts which are not mine and I do not have the ability to change. However, in my scripts I make a call to these other scripts through evalin('base', 'scriptName'). Unfortunately, these other scripts do a lot of unnecessary and ugly printing to the command window that I don't want to see. Without being able to edit these other scripts, I would like a way to suppress output to the command line for the time that these other scripts are executing.
One potential answer was to use evalc, but when I try evalc(evalin('base', 'scriptName')) MATLAB throws an error complaining that it cannot execute a script as a function. I'm hoping there's something like the ability to disable command window printing or else redirecting all output to some null file much like /dev/null in unix.
I think you just need to turn the argument in your evalc example into a string:
evalc('evalin(''base'', ''scriptName'')');
Have you tried this solution
here ?
echo off;
I don't know if it will fit your needs, but another solution can be to open a new session of Matlab, and use there only minimized -nodesktop form (-just the command window). You can run from there the annoying scripts, and work on the main session as usual.
The problem here is that the sessions can't be synchronized, so if you need to work with the results of the scripts all the time, it'll be a little bit complicated. Maybe you can save the result to disk, than call it from the main session...
But it mainly depends on your workflow with those scripts.

How to pass inputs from a script to command line

I am a new newbie to scripting, fuzzing, and buffer overflows. I understand the basic concepts behind them though.
I am looking for a way to pass input from a script (I am thinking perl) to a command line.
I am trying to create a fuzzer for a buffer overflow.
I have a basic C program that takes input from the command line
I need a script that I can pass patterns through to this external program on the command line.
Any help would be appreciated. Thank you.
You can create a file for the inputs, with 11 lines in it (last line is just an empty line to simulate enter key for the last command line input), and then redirect this file to the C program:
./c_program < file_with_10_inputs
You can save the above line as a wrapper script (e.g., auto_exec.sh) and in perl do:
system("sh auto_exec.sh");
I think you have to handle the stdin an stdout of the external process, so it's a good idea use a module like IO::Async, which helps you a lot.

NtQueryInformationProcess seems to return wrong command line

I am using NtQueryInformationProcess() to retrieve the command line of another process (via the RTL_USER_PROCESS_PARAMETERS in the PEB returned by NtQueryInformationProcess()) on Windows 7.
This generally works fine, but when multiple instances of the same executable are started the command line string is the same for all instances: it always is the command line of the first instance that was started. GetCommandLine() returns the correct command line for each process though.
Can someone confirm or falsify this?
What you are probably missing is that each pointer in PEB is only relevant in address space of the PEB's process rather than the process that called NtQueryInformationProcess and retrieved the PEB. You have to use ReadProcessMemory to derference pointers. Otherwise, since processes are likely to be laid out similarly, you end up reading the command line of the NtQueryInformationProcess caller and not that of the PEB's process.
I can confirm that Using NtQueryInformationProcess and ReadProcessMemory for each level of pointer indirection you can get command lines of all processes correctly. See https://stackoverflow.com/a/13408150/1236546 for source code example.

interactive lua: command line arguments

I wish to do
lua prog.lua arg1 arg2
from the command line
Inside prog.lua, I want to say, for instance
print (arg1, arg2, '\n')
Lua doesn't seem to have argv[1] etc and the methods I've seen for dealing with command line arguments seem to be immature and / or cumbersome. Am I missing something?
You're missing the arg vector, which has the elements you want in arg[1], arg[2], and so on:
% lua -i -- /dev/null one two three
Lua 5.1.3 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> print(arg[2])
two
>
More info in the Lua manual section on Lua standalone (thanks Miles!).
In addition to the arg table, ... contains the arguments (arg[1] and up) used to invoke the script.
% lua -i -- /dev/null one two three
Lua 5.1.3 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> print(...)
one two three
Lua stores arguments in a table. This table is the "arg" table. You can access the passed arguments inside using arg[1], arg[2], ...
arg[0] is the name of the lua program. arg[1] is the first argument passed, arg[2] is the second argument passed and so on...
If you run file.lua in cmd of freeswitch
freeswitch> luarun prog.lua arg1
You can use prog.lua:
#print(argv[1])
And run: $lua prog.lua arg1 (run in script folder)
You can use prong.lua:
#print(arg[1])
For OP and future visitors,
The library of Lua doesn't contain injecting a table 'args' into globals from command line switches. The program built from lua.c does, however, it is near impossible to use. The reason it is impossible to use is that program does NOT like multiple switches.
This is one of the reasons why my REPL/code executor LuaConsole was built. It gives you the table args as well as sends a tuple to the root pcall function (your executing environment is really a top-level pcall with probably an error handler attached). So both args[n] and local a = {...}; a[n] ...; all work properly with as many switches as you want. For example, -e to execute code from cmd line, -l to specify libraries, etc. It supports anything lua51 and up.
If you are having troubles with the program in the library, I highly suggest you check out https://www.github.com/tilkinsc/LuaConsole as it will save you the headache of dealing with a broken-feeling program. There are also other alternatives out there such as for web, fengari.
Hope this helps you!

How to discover command line options (if any) for an undocumented executable of unknown origin?

Take an undocumented executable of unknown origin. Trying /?, -h, --help from the command line yields nothing. Is it possible to discover if the executable supports any command line options by looking inside the executable? Possibly reverse engineering? What would be the best way of doing this?
I'm talking about a Windows executable, but would be interested to hear what different approaches would be needed with another OS.
In linux, step one would be run strings your_file which dumps all the strings of printable characters in the file. Any constants chars will thus be shown, including any "usage" instructions.
Next step could be to run ltrace on the file. This shows all function calls the program does. If it includes getopt (or familiar), then it is a sure sign that it is processing input parameters. In fact, you should be able to see exactly what argument the program is expecting since that is the third parameter to the getopt function.
For Windows, you can see this question about decompiling Windows executables. It should be relatively easy to at least discover the options (what they actually do is a different story).
If it's a .NET executable try using Reflector. This will convert the MSIL code into the equivalent C# code which may make it easier to understand. Unfortunately private and local variable names will be lost, as these are not stored in the MSIL but it should still be possible to follow what's going on.