How to send EOF from command prompt *without newline*? - windows

Sure, to send EOF from command prompt, Enter followed by Ctrl-Z does the trick.
C:\> type con > file.txt
line1
line2
^Z
This works, and file.txt contains line1\r\nline2\r\n. But how can you do the same without the last newline, so that file.txt contains line1\r\nline2?
In Linux, the solution is to hit Ctrl-D twice1. But what is the equivalent on Windows? Command prompt will happily print ^Zs at the end of a line without doing sending EOF. (And if you press Enter, then any ^Zs you typed get written to the file as literal escape characters!)
If there is no way to do this on Windows, then why?
1 https://askubuntu.com/questions/118548/how-do-i-end-standard-input-without-a-newline-character

The command type con > file.txt doesn't have any special handling for ^Z in the cmd shell, since the target file isn't con and the type command wasn't run in Unicode (UTF-16LE) output mode. In this case, the only ^Z handling is in the ReadFile call itself, which for a console input buffer has an undocumented behavior to return 0 bytes read if a line starts with ^Z.
Let's examine this with a debugger attached, noting that the number of bytes read (lpNumberOfBytesRead) is the 4th argument (register r9 in x64), which is returned by reference as an output parameter.
C:\Temp>type con > file.txt
Breakpoint 1 hit
KERNELBASE!ReadFile:
00007ffc`fb573cc0 48895c2410 mov qword ptr [rsp+10h],rbx
ss:00000068`c5d1dfa8=000001e3000001e7
0:000> r r9
r9=00000068c5d1dfd0
0:000> pt
line1
KERNELBASE!ReadFile+0xa9:
00007ffc`fb573d69 c3 ret
0:000> dd 68c5d1dfd0 l1
00000068`c5d1dfd0 00000007
As you see above, reading "line1\r\n" is 7 characters, as expected. Next let's enter "\x1aline2\r\n" and see how many bytes ReadFile reportedly reads:
0:000> g
Breakpoint 1 hit
KERNELBASE!ReadFile:
00007ffc`fb573cc0 48895c2410 mov qword ptr [rsp+10h],rbx
ss:00000068`c5d1dfa8=0000000000000000
0:000> r r9
r9=00000068c5d1dfd0
0:000> pt
^Zline2
KERNELBASE!ReadFile+0xa9:
00007ffc`fb573d69 c3 ret
0:000> dd 68c5d1dfd0 l1
00000068`c5d1dfd0 00000000
As you see above, this time it reads 0 bytes, i.e. EOF. Everything typed after ^Z was simply ignored.
However, what you want instead is to get this behavior in general, wherever ^Z appears in the input buffer. type will do this for you, but only if it's executed in Unicode mode, i.e. cmd /u /c type con > file.txt. In this case cmd does have special handling to scan the input for ^Z. But I bet you don't want a UTF-16LE file, especially since cmd doesn't write a BOM to allow editors to detect the UTF encoding.
You're in luck, because it happens that copy con file.txt does exactly what you want. Internally it calls cmd!ZScanA to scan each line for a ^Z character. We can see this in action back in the debugger, but this time we're in completely undocumented territory. On inspection, it appears that this function's 3rd parameter (register r8 in x64) is the number of bytes read as an in-out argument.
Let's begin again by entering the 7 character string "line1\r\n":
C:\Temp>copy con file.txt
line1
Breakpoint 0 hit
cmd!ZScanA:
00007ff7`cf4c26d0 48895c2408 mov qword ptr [rsp+8],rbx
ss:00000068`c5d1e9d0=0000000000000000
0:000> r r8; dd #r8 l1
r8=00000068c5d1ea64
00000068`c5d1ea64 00000007
On output, the scanned length remains 7 characters:
0:000> pt
cmd!ZScanA+0x4f:
00007ff7`cf4c271f c3 ret
0:000> dd 68c5d1ea64 l1
00000068`c5d1ea64 00000007
0:000> g
Next enter the 23 (0x17) character string "line2\x1a Ignore this...\r\n":
line2^Z Ignore this...
Breakpoint 0 hit
cmd!ZScanA:
00007ff7`cf4c26d0 48895c2408 mov qword ptr [rsp+8],rbx
ss:00000068`c5d1e9d0=0000000000000000
0:000> r r8; dd #r8 l1
r8=00000068c5d1ea64
00000068`c5d1ea64 00000017
This time the scanned length is only the 5 characters that precede the ^Z:
0:000> pt
cmd!ZScanA+0x4f:
00007ff7`cf4c271f c3 ret
0:000> dd 68c5d1ea64 l1
00000068`c5d1ea64 00000005
We expect file.txt to be 12 bytes, which it is:
C:\Temp>for %a in (file.txt) do #echo %~za
12
More generally, if a Windows console program wants to implement Ctrl+D handling that approximates the behavior of a Unix terminal, it can use the wide-character console function ReadConsoleW, passing a CONSOLE_READCONSOLE_CONTROL struct by reference as pInputControl. This struct's dwCtrlWakeupMask field is a bit mask that sets which control characters will immediately terminate the read. For example, bit 4 enables Ctrl+D. I wrote a simple test program that demonstrates this case:
C:\Temp>.\test
Enter some text: line1
You entered: line1\x04
You can't see this in the above example, but this read was immediately terminated by pressing Ctrl+D, without even pressing enter. The ^D control character (i.e. '\x04') remains in the input buffer, which is useful in case you want different behavior for multiple control characters.

Related

Value can't be converted to integer while debugging with gdb

I am trying to debug assembler code with gdb in ubuntu x64 command line.
A disassemble command shows the following
0x0000000000401247 <+10>: mov %r12,-0x8(%rsp)
=> 0x000000000040124c <+15>: sub $0x18,%rsp
0x0000000000401250 <+19>: mov %rdi,%rbx
and after stepi command I want to explore the memory with address $0x18 to check the result of command.
I am using the following command x $0x18 and getting error Value can't be converted to integer.
And after trying the command x 0x18 it gives Cannot access memory at address 0x18 error.
How can I check the result of command in memory with address 0x18?
I want to explore the memory with address $0x18
There is no memory at address 0x18. The assembly instruction you are looking at: sub $0x18,%rsp subtracts a constant 0x18 from previous value of the RSP register (that's what $ in front of 0x18 means).

Write windbg command output to file, but not console

In windbg, I'm looking for a mechanism to take the output of a command (specifically, a command inside of a breakpoint) and have it appended to a file, and not written to a console.
Currently I setup the process with .logappend C:\path\to\log and then enable a few breakpoints with:
bp WIN32U!{function} ".echo '===WIN32K-START==='; k; .echo '===WIN32K-END==='; g"
This works great, except the volume of output written to the console causes serious performance issues. I'm hopeful there's a way to get the same output to my log file, without the overhead of writing to the windbg console.
You want the .outmask meta-command: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/-outmask--control-output-mask-
.outmask allows you to control which message types are sent to the output window and log file. The /l switch can allow you to change just the types that reach the output window, without affecting which types will reach the log file.
For example, this command will turn off all output to the output window while still sending normal messages to the log file:
.outmask- /l 0xffff
Although probably .outmask- /l 1 is all you need, which turns off just normal message output, but errors and warnings will still show up in the output window. Use .outmask /d to reset output settings back to the default when you're done.
In combination with the ability of .printf to output different message types, you can make it so you still have some idea what's going on, as well. Turn off normal message output to the window with .outmask- /l 1. Now you can use .printf /oe "message" in a breakpoint command somewhere to write an error message, which will still be sent to the output window so you can tell what's happening at certain points in the process.
you can patch dbgeng!g_OutputControl global to disable writing to console and only write to log file
but I don't know if you will have a performance gain or not
looking for a txt file
C:\>dir /b *.txt
File Not Found
opening a debugging session
C:\>cdb calc
Microsoft (R) Windows Debugger Version 10.0.15063.400 X86
ntdll!LdrpDoDebuggerBreak+0x2c:
774005a6 cc int 3
in the opened debugging session
spawn a parent debugger to debug the windbg running your debuggee
0:000> .dbgdbg
Debugger spawned, connect with
"-remote npipe:icfenable,pipe=cdb_pipe,server=xxxx"
in the spawned parent patch the global and detach
ed dbgeng!g_OutputControl 0
.detach
q
open a logfile in your debugging session
0:000> .logappend c:\foo.txt
Opened log file 'c:\foo.txt'
set a conditional breakpoint and start the session
0:000> bp ntdll!RtlEnterCriticalSection "kb;gc"
0:000> bl
0 e 773a7790 0001 (0001) 0:**** ntdll!RtlEnterCriticalSection "kb;gc"
0:000> g
there is no console output here
doing a ctrl+c to stop session and quitting the session
eax=7ffde000 ebx=00000000 ecx=00000000 edx=773ff1d3 esi=00000000 edi=00000000
eip=77394108 esp=016ef8a8 ebp=016ef8d4 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77394108 cc int 3
0:001> q
quit:
check for the log file and confirm if it has voluminous data written to it
RtlEnterCriticalSection Api is a very hot Api
C:\>dir /b *.txt
foo.txt
C:\>ls -l foo.txt
-rw-rw-rw- 1 0 **1754920** 2017-09-15 00:27 foo.txt
C:>head foo.txt
Opened log file 'c:\foo.txt'
0:000> bp ntdll!RtlEnterCriticalSection "kb;gc"
0:000> bl
0 e 773a7790 0001 (0001) 0:**** ntdll!RtlEnterCriticalSection "kb;gc"
0:000> g
ChildEBP RetAddr Args to Child
000cf114 77425f4b 000d0138 7724d80b 00000000 ntdll!RtlEnterCriticalSection
000cf158 773ea40a 000d0000 50180162 00000044 ntdll!RtlDebugAllocateHeap+0x9d
000cf23c 773b5ae0 00000044 00000000 00000000 ntdll!RtlpAllocateHeap+0xc4
000cf2c0 77384726 000d0000 40180060 00000044 ntdll!RtlAllocateHeap+0x23a
there are more tha 22k lines written to this file
C:\>wc -l foo.txt
22543 foo.txt
C:>tail foo.txt
000cf838 773c37be 00462d6c 7ffdb000 00000000 ntdll!__RtlUserThreadStart+0x70
000cf850 00000000 00462d6c 7ffdb000 00000000 ntdll!_RtlUserThreadStart+0x1b
(c80.8ec): Break instruction exception - code 80000003 (first chance)
eax=7ffde000 ebx=00000000 ecx=00000000 edx=773ff1d3 esi=00000000 edi=00000000
eip=77394108 esp=016ef8a8 ebp=016ef8d4 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!DbgBreakPoint:
77394108 cc int 3
0:001> q
quit:
C:\>

ASM: INT 20 doesn`t work on Debug DOSbox [duplicate]

I'm trying to use DOSBox with debug.exe on a 64-bit system. It works perfectly fine if I enter the commands manually. When I redirect input from a file with:
debug < [file]
it doesn't work. On every line except for the first it displays an error similar to this:
DOSBox will eventually hang and crash. Is there any way to fix this?
The input file I am trying to process as commands is:
a 100
jmp 145
db 'Hello, World!', 0D, 0A, 'Press any key to continue . . .$'
a 145
mov ah, 09
mov dx, 102
int 21
mov ah, 08
int 21
int 20
rcx
100
n hello.com
w
q
I can reproduce the behavior you are seeing in this scenario:
DOSBox 0.74 on Windows and Linux
DEBUG.EXE from Windows XP copied to DOSBox
DEBUG.EXE from various versions of MS-DOS will cause problem including unexpected hangs. See this Stackoverflow question for another related problem.
I found a version of DEBUG.COM from FreeDOS that works as expected. I have made DEBUG.COM available for download from my website. Alternatively you can download the ZIP File from Softpedia and extract DEBUG.COM.
When I run DEBUG.COM I get this:
S:\>debug.com <hello.asm
-a 100
0BFB:0100 jmp 145
0BFB:0102 db 'Hello, World!', 0D, 0A, 'Press any key to continue . . .$'
0BFB:0131
-a 145
0BFB:0145 mov ah, 09
0BFB:0147 mov dx, 102
0BFB:014A int 21
0BFB:014C mov ah, 08
0BFB:014E int 21
0BFB:0150 int 20
0BFB:0152
-rcx
CX 0000
:100
-n hello.com
-w
Writing 00100 bytes
-q
S:\>hello
Hello, World!
Had same problem in DosBox 0.74 with DEBUG.EXE script redirection. Discovered that it could be fixed by changing the end-of-line characters in the script file from [CR][LF] to just [CR] when redirecting into DEBUG.EXE.
Pasting your file into the Scite editor and viewing the line-end characters showed this:
a 100{CR][LF]
jmp 145[CR][LF].... et cetera
I used an option in Scite to change the EOL characters to [CR] alone, getting
a 100{CR]
jmp 145[CR].... et cetera
saved the file, and was able to redirect it into DEBUG.EXE with no problem.
Not sure why [CR][LF] causes the issue with DEBUG.EXE, but hope this helps.
DEBUG.COM handles either EOL sequence with no glitch, so makes sense to use it instead, especially with its extended features. But one can use DEBUG.EXE it seems, with this fix, FWIW. The Scite editor is a neat tool.
I found the same problem running a script file for Debug within Dosbox.
but I found another editor: Notepad2. runs great and small and changes color to highlight assembler words.
Had to use debug ver 1.25 though.
Than you Michael Petch. I was trying everything to get the output of FreeDos clone of MS-DEBUG to save into a text file. But it was not the path, the speed, or the memory allotment that was blocking the redirection of output. It was indeed the line feed and cursor return combination. I quickly wrote a program to take out cursor return and leave line feed. It now redirects! I can also take out the line feed and leave the cursor returns, and DEBUG redirects to file as well. The small glitch is I have to access Windows outside the or close the DosBox window, for the outputted DEBUG code to become visible in a directory listing.
This is how I redirect DEBUG output to a file:
DEBUG < game.dbg > game.lst

Remove address from instruction disassembled via dbgeng's DisassembleWide()

I am disassembling instructions by passing their offset to DisassembleWide() function while writing an extension for Windbg. However, with the disassembled instruction, it adds the address of the instruction + hex opcode for that instruction.
I was able to remove the opcode by specifying DEBUG_ASMOPT_NO_CODE_BYTES flag in SetAssemblyOptions(). However I can't seem to get rid of the instruction offset. Neither DEBUG_ASMOPT_DEFAULT | DEBUG_ASMOPT_NO_CODE_BYTES, nor (DEBUG_ASMOPT_DEFAULT | DEBUG_ASMOPT_NO_CODE_BYTES) & ~DEBUG_ASMOPT_VERBOSE seem to work.
Am I missing something? Is there a way I can cleanly remove the offset from the instruction, or will I have to do it the manual way?
no Address will always be printed you have to parse it out yourself
if you are on a windbg session you can achieve this with .shell and awk
0:000> .asm no_code_bytes
Assembly options: no_code_bytes
0:000> .shell -ci "u #eip l4" awk "{$1=\"\";print $0}"
int 3
ret
mov edi,edi
int 3
.shell: Process exited

DEBUG how to display, increment, loop in a cmd debug environment

a 0100
mov cx,59
mov ah,02
mov dl,20
int 21
inc dl
loop 0105
int 20
g
i am trying to loop and increment the value in DL but when i run it .it does not show anyting or rather it shows the 'space' character only
.i wanted to do this on DEBUG environment so please don't tell me to use TASM xD
You should change your loop instruction, because right now it resets dl with 20h, that's why it prints only the space character. Try looping directly on the int 21h instruction.

Resources