Inspecting Win32 ReadFile lpBuffer parameter with windbg - winapi

Question

I'm using the following function from the book "Windows System Programming 4th" by Johnson M. Hart. To acquaint myself with the Win32 API. I'm also inspecting the function with Windbg.
When inspecting the parameter that points to the buffer that receives the data read from the file. I get the output below from the debugger. Can someone explain how to use windbg to inspect the lpBuffer?
#include "Everything.h"
#define BUF_SIZE 256
BOOL cci_f (LPCTSTR fIn, LPCTSTR fOut, DWORD shift)
{
HANDLE hIn, hOut;
DWORD nIn, nOut, iCopy;
BYTE buffer [BUF_SIZE], bShift = (BYTE)shift;
BOOL writeOK = TRUE;
hIn = CreateFile (fIn, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (hIn == INVALID_HANDLE_VALUE) return FALSE;
hOut = CreateFile (fOut, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if (hOut == INVALID_HANDLE_VALUE) {
CloseHandle(hIn);
return FALSE;
}
while (writeOK && ReadFile (hIn, buffer, BUF_SIZE, &nIn, NULL) && nIn > 0) {
for (iCopy = 0; iCopy < nIn; iCopy++)
buffer[iCopy] = buffer[iCopy] + bShift;
writeOK = WriteFile (hOut, buffer, nIn, &nOut, NULL);
}
CloseHandle (hIn);
CloseHandle (hOut);
return writeOK;
}
0:000> bp kernel32!readfile
0:000> g
Breakpoint 1 hit
eax=00000000 ebx=00000000 ecx=0018bf0c edx=00000030 esi=00000030 edi=0018ff20
eip=77383f11 esp=0018bddc ebp=0018be20 iopl=0 nv up ei ng nz ac po cy
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000293
kernel32!ReadFile:
77383f11 ff25ec093877 jmp dword ptr [kernel32!_imp__ReadFile (773809ec)] ds:002b:773809ec={KERNELBASE!ReadFile (75efdc4a)}
0:000> k
ChildEBP RetAddr
0018be20 00411551 kernel32!ReadFile
0018ff44 00411b50 cpW!main+0x181 [c:\microsoft_press\wsp4_examples\chaptr01\cpw.c # 31]
0018ff88 7738338a cpW!__tmainCRTStartup+0x122 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c # 555]
0018ff94 779b9f72 kernel32!BaseThreadInitThunk+0xe
0018ffd4 779b9f45 ntdll!__RtlUserThreadStart+0x70
0018ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> dd ebp
0018be20 0018ff44 00411551 00000030 0018bf0c
0018be30 00004000 0018ff20 00000000 0041757c
0018be40 00000001 00000000 cccccccc cccccccc
0018be50 cccccccc cccccccc cccccccc cccccccc
0018be60 cccccccc cccccccc cccccccc cccccccc
0018be70 cccccccc cccccccc cccccccc cccccccc
0018be80 cccccccc cccccccc cccccccc cccccccc
0018be90 cccccccc cccccccc cccccccc cccccccc
0:000> da 0018bf0c
0018bf0c "................................"
0018bf2c "................................"
0018bf4c "................................"
0018bf6c "................................"
0018bf8c "................................"
0018bfac "................................"
0018bfcc "................................"
0018bfec "................................"
0018c00c "................................"
0018c02c "................................"
0018c04c "................................"
0018c06c "................................"
Additional debug output below after suggestions.
0:000> lm
start end module name
00400000 0040a000 cci (deferred)
71580000 71656000 MSVCR110 (deferred)
71660000 71703000 MSVCR90 (deferred)
72660000 72666000 Utility_4_0 (deferred)
76630000 76677000 KERNELBASE (deferred)
76950000 76a60000 kernel32 (deferred)
771d0000 77350000 ntdll (pdb symbols) c:\symbol\wntdll.pdb\69DDFBCBBC14421D8CB974F8EDC414102\wntdll.pdb
0:000> .sympath+ C:\Microsoft_Press\WSP4_Examples\Projects2008\cci\Debug
Symbol search path is: SRV*c:\symbol*http://msdl.microsoft.com/download/symbols;C:\Microsoft_Press\WSP4_Examples\Projects2008\cci\Debug
Expanded Symbol search path is: srv*c:\symbol*http://msdl.microsoft.com/download/symbols;c:\microsoft_press\wsp4_examples\projects2008\cci\debug
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred SRV*c:\symbol*http://msdl.microsoft.com/download/symbols
OK C:\Microsoft_Press\WSP4_Examples\Projects2008\cci\Debug
0:000> bp cci!main
*** WARNING: Unable to verify checksum for cci.exe
0:000> g
Breakpoint 0 hit
eax=71648634 ebx=00000000 ecx=0048e198 edx=00000000 esi=00000001 edi=00000000
eip=00401020 esp=0018ff4c ebp=0018ff88 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
cci!main:
00401020 55 push ebp
0:000> bp kernel32!Readfile
0:000> g
Breakpoint 1 hit
eax=00000000 ebx=00000000 ecx=0018fd24 edx=0000003c esi=0000003c edi=0018fe44
eip=76963f11 esp=0018fbdc ebp=0018fc20 iopl=0 nv up ei ng nz ac po cy
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000293
kernel32!ReadFile:
76963f11 ff25ec099676 jmp dword ptr [kernel32!_imp__ReadFile (769609ec)] ds:002b:769609ec={KERNELBASE!ReadFile (7663dc4a)}
0:000> k
ChildEBP RetAddr
0018fc20 004011f3 kernel32!ReadFile
0018fe68 004010a3 cci!cci_f+0xe3 [c:\microsoft_press\wsp4_examples\chaptr02\cci_f.c # 29]
0018ff48 00401765 cci!main+0x83 [c:\microsoft_press\wsp4_examples\chaptr02\cci.c # 24]
0018ff88 7696338a cci!__tmainCRTStartup+0xfd [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c # 536]
0018ff94 77209f72 kernel32!BaseThreadInitThunk+0xe
0018ffd4 77209f45 ntdll!__RtlUserThreadStart+0x70
0018ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> r esp
esp=0018fbdc
0:000> dd 0018fbdc
0018fbdc 76963ee7 0000003c 0018fd24 00000100
0018fbec 0018fe44 00000000 988c6ffa 0018fe68
0018fbfc 0018fc3c 00000000 769653d0 0018fbf4
0018fc0c 0018fc3c 0018ff78 76a04643 ee02ad2a
0018fc1c fffffffe 0018fe68 004011f3 0000003c
0018fc2c 0018fd24 00000100 0018fe44 00000000
0018fc3c 0018ff48 0018fe7c 00000000 cccccccc
0018fc4c cccccccc cccccccc cccccccc cccccccc
0:000> !handle 0000003c f
Handle 3c
Type File
Attributes 0
GrantedAccess 0x120089:
ReadControl,Synch
Read/List,ReadEA,ReadAttr
HandleCount 2
PointerCount 19
No Object Specific Information available
0:000> da 0018fd24
0018fd24 "................................"
0018fd44 "................................"
0018fd64 "................................"
0018fd84 "................................"
0018fda4 "................................"
0018fdc4 "................................"
0018fde4 "................................"
0018fe04 "................................"
0018fe24 "................................"
0018fe44 ""
0:000> r ebp
ebp=0018fc20
0:000> dd 0018fc20
0018fc20 0018fe68 004011f3 0000003c 0018fd24
0018fc30 00000100 0018fe44 00000000 0018ff48
0018fc40 0018fe7c 00000000 cccccccc cccccccc
0018fc50 cccccccc cccccccc cccccccc cccccccc
0018fc60 cccccccc cccccccc cccccccc cccccccc
0018fc70 cccccccc cccccccc cccccccc cccccccc
0018fc80 cccccccc cccccccc cccccccc cccccccc
0018fc90 cccccccc cccccccc cccccccc cccccccc
0:000> da 0018fd24
0018fd24 "................................"
0018fd44 "................................"
0018fd64 "................................"
0018fd84 "................................"
0018fda4 "................................"
0018fdc4 "................................"
0018fde4 "................................"
0018fe04 "................................"
0018fe24 "................................"
0018fe44 ""
Dumping the Kernel32!Writefile lBuffer shows the data to be written to the file. I'm unclear on why the kernel32!ReadFile is not showing the data in it lpBuffer argument.
0:000> bp kernel32!writefile
0:000> g
Breakpoint 2 hit
eax=00000040 ebx=00000000 ecx=0018fe38 edx=00000000 esi=0018fc3c edi=0018fe68
eip=769617ad esp=0018fc08 ebp=0018fc20 iopl=0 nv up ei ng nz ac po cy
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000293
kernel32!WriteFile:
769617ad ff25e4099676 jmp dword ptr [kernel32!_imp__WriteFile (769609e4)] ds:002b:769609e4={KERNELBASE!WriteFile (7663ddbc)}
0:000> k
ChildEBP RetAddr
0018fc20 0040125b kernel32!WriteFile
0018fe68 004010a3 cci!cci_f+0x14b [c:\microsoft_press\wsp4_examples\chaptr02\cci_f.c # 36]
0018ff48 00401765 cci!main+0x83 [c:\microsoft_press\wsp4_examples\chaptr02\cci.c # 24]
0018ff88 7696338a cci!__tmainCRTStartup+0xfd [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c # 536]
0018ff94 77209f72 kernel32!BaseThreadInitThunk+0xe
0018ffd4 77209f45 ntdll!__RtlUserThreadStart+0x70
0018ffec 00000000 ntdll!_RtlUserThreadStart+0x1b
0:000> dd 0018fc20
0018fc20 0018fe68 0040125b 00000040 0018fd24
0018fc30 00000100 0018fe38 00000000 0018ff48
0018fc40 0018fe7c 00000000 cccccccc cccccccc
0018fc50 cccccccc cccccccc cccccccc cccccccc
0018fc60 cccccccc cccccccc cccccccc cccccccc
0018fc70 cccccccc cccccccc cccccccc cccccccc
0018fc80 cccccccc cccccccc cccccccc cccccccc
0018fc90 cccccccc cccccccc cccccccc cccccccc
0:000> da 0018fd24
0018fd24 "9:(86:::##98<?8:#;<A<;..9:(86:::"
0018fd44 "##98<?8:#;<A<;..9:(86:::##98<?8:"
0018fd64 "#;<A<;..9:(86:::##98<?8:#;<A<;.."
0018fd84 "9:(86:::##98<?8:#;<A<;..9:(86:::"
0018fda4 "##98<?8:#;<A<;..9:(86:::##98<?8:"
0018fdc4 "#;<A<;..9:(86:::##98<?8:#;<A<;.."
0018fde4 "9:(86:::##98<?8:#;<A<;..9:(86:::"
0018fe04 "##98<?8:#;<A<;..9:(86:::##98<?8:"
0018fe24 "........"
Thanks to the insight provided by the community. I'm able to view data within lpBuffer by first setting a breakpoint at Kernel32!ReadFile. Then executing gu (The gu command causes the target to execute until the current function is complete). Thereafter I can dump the buffer. Which now shows the data I'm interested in.

Answer 1

BOOL WINAPI ReadFile(
_In_ HANDLE hFile,
_Out_ LPVOID lpBuffer,
_In_ DWORD nNumberOfBytesToRead,
_Out_opt_ LPDWORD lpNumberOfBytesRead,
_Inout_opt_ LPOVERLAPPED lpOverlapped
);
When you have broken on ReadFile the lpBuffer will contain rubbish/ garbage/ zeros/ or pre initialised content based on how you allocated and initialised the buffer this buffer will be filled up with the content of the file only after you return from the API to step out of the function use gu (goup) and examine the buffer (save the address of buffer first for examining later address of buffer should be at #esp+08 when you have broken on ReadFile in kernel32.dll on a 32 bit system
the walk through below creates a new file in current directory then writes to it then resets the file position for reading to beginning of the file reads the file and prints the content to stdout and quits after Closing the handle .
cdb is console mode windbg
-c switch takes commands to execute on events
g main executes file till main to avoid uninteresting breaks in
ReadFile
bp kernel32!ReadFile sets a breakpoint on the API
g to execute the file so that it breaks in our breakpoint
bc * to clear any breakpoints (advisable to form this habit when
scripting)
r $t0 = poi(#esp+8) to save the pointer to lpBuffer
poi(#esp+0) is always return address
poi(#esp+4) is always first argument when broken on Function Start
in 32 bit systems.
.echo is to output a comment .
db #$t0 l20 prints the 1st 20 bytes of lpBuffer prior to Executing ReadFile()
gu is to goup
.echo is to output a comment .
db #$t0 l20 prints the 1st 20 bytes of lpBuffer post Execution of ReadFile()
g;q is to continue and quit when finished executing the file
readfile>type readfile.cpp & %compile% readfile.cpp & readfile.exe
#include <stdio.h>
#include <Windows.h>
int main(void) {
char writein[] = {"Iam going to write me in\n"};
char readin [] = {"Iam rubbish Iam garbage Readfile will clean me up\n" };
DWORD bytesreadoutin = 0;
BOOL result = FALSE;
HANDLE hFile = CreateFileA("mynewtxt.txt",GENERIC_ALL,FILE_SHARE_WRITE |
FILE_SHARE_READ,NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL,NULL);
if (INVALID_HANDLE_VALUE != hFile) {
if ((result = WriteFile(
hFile,writein,sizeof(writein),&bytesreadoutin,NULL)) == TRUE ) {
if (bytesreadoutin == sizeof(writein)) {
if ( INVALID_SET_FILE_POINTER != SetFilePointer(
hFile,NULL,NULL,FILE_BEGIN) ) {
if (( result = ReadFile(
hFile,readin,sizeof(writein),&bytesreadoutin,
NULL))== TRUE) {
printf(readin);
}
}
}
}
CloseHandle(hFile);
}
return 0;
}Setting environment for using Microsoft Visual Studio 2010 x86 tools.
readfile.cpp
Press any key to continue . . .
I am going to write me in
with windbg
readfile>cdb -c "g main;bp kernel32!ReadFile;g;bc *;r $t0 = poi(#esp+8);.echo =============buffer contents pre readfile================;db #$t0 l20;gu;.echo ======================buffer contents post readfile=================;db #$t0 l20;g;q" readfile.exe
ntdll!DbgBreakPoint:
7c90120e cc int 3
0:000> cdb: Reading initial command 'g main;bp kernel32!ReadFile;g;bc *;r $t0 =
poi(#esp+8);.echo =============buffer contents pre readfile================;db #
$t0 l20;gu;.echo ======================buffer contents post readfile============
=====;db #$t0 l20;g;q'
Breakpoint 0 hit
=============buffer contents pre readfile================
0013ff34 49 20 61 6d 20 72 75 62-62 69 73 68 20 49 20 61 I am rubbish I a
0013ff44 6d 20 67 61 72 62 61 67-65 49 20 77 69 6c 6c 20 m garbageI will
======================buffer contents post readfile=================
0013ff34 49 20 61 6d 20 67 6f 69-6e 67 20 74 6f 20 77 72 I am going to wr
0013ff44 69 74 65 20 6d 65 20 69-6e 0a 00 77 69 6c 6c 20 ite me in..will
I am going to write me in
quit:
To Log All ReadFile calls write a simple script with all the commands in .block {} and set a conditional breakpoint like bp kernel32!ReadFile "$$>a< X:\\blah.ext"
be aware that ReadFile is a Very Busy Api and in general you do not want
to set permanent breaks in busy apis as that may lead to very poor performance
or an undesirable slowness in the session and may introduce severe problems when debugging problems with time dependent code
script file contents
0:004> .shell -ci " " type c:\\readfile.txt
.block {
r $t0 = poi(#esp+0x8);
.echo ========================================pre&post===========================
db #$t0 l10;
gu;
db #$t0 l10;
g;
}.shell: Process exited
result
0:002> $$ start of logging ReadFile
0:002> bl
0 e 7c801812 0001 (0001) 0:**** kernel32!ReadFile "$$>a< c:\\readfile.txt"
0:002> .bpcmds
bp0 0x7c801812 "$$>a< c:\\readfile.txt";
0:002> g
========================================pre&post===========================
0011fa10 00 00 00 00 00 00 00 00-60 00 00 00 00 00 00 00 ........`.......
0011fa10 49 54 53 46 03 00 00 00-60 00 00 00 01 00 00 00 ITSF....`.......
========================================pre&post===========================
001271d8 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
001271d8 49 54 53 50 01 00 00 00-54 00 00 00 0a 00 00 00 ITSP....T.......
========================================pre&post===========================
000e9038 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
000e9038 50 4d 47 4c 10 0b 00 00-00 00 00 00 ff ff ff ff PMGL............
========================================pre&post===========================
009eed38 f0 f9 11 00 a8 ed 9e 00-fd f3 e2 65 f0 f9 11 00 ...........e....
009eed38 1e 00 11 00 a8 ed 9e 00-fd f3 e2 65 f0 f9 11 00 ...........e....
========================================pre&post===========================
0011ef42 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0011ef42 02 00 0c 00 55 00 6e 00-63 00 6f 00 6d 00 70 00 ....U.n.c.o.m.p.
========================================pre&post===========================
009ef018 50 0a 15 00 d8 6b 3d 00-34 f0 9e 00 6c f0 9e 00 P....k=.4...l...
009ef018 03 00 00 00 d8 6b 3d 00-34 f0 9e 00 6c f0 9e 00 .....k=.4...l...
========================================pre&post===========================

Answer 2

Here is a sequence of Windbg commands to see what bytes received in lpBuffer when ReadFile is called.
bp ReadFile
r $t1 = dwo(esp+8) ;lpBuffer
pt ;execute till return
db #$t1 ;dump bytes in lpBuffer
You can find a simple Windbg script of intercepting ReadFile calls here.