windbg script causes memory access violation - windbg

I am using the following windbg script to break when a certain value is encountered in the buffer when reading a file
bp ReadFile
.while(1)
{
g
$$ Get parameters of ReadFile()
r $t0 = dwo(esp+4)
r $t1 = dwo(esp+8)
r $t2 = dwo(esp+0x0c)
$$ Execute until return is reached
pt
$$ Read magic value in the buffer
$$ CHANGE position in buffer here
r $t5 = dwo(#$t1+0x00)
$$ Check if magic value matches
$$ CHANGE constant here
.if(#$t5 == 0x70170000)
{
$$db #$t1
$$ break
.break
}
}
$$ Clear BP for ReadFile (assume it is the 0th one)
bc 0
I get the following memory access violation when I run this script.
Memory access error at ');; $$ Check if magic value matches; $$ CHANGE constant here; .if(#$t5 == 0x70170000); {; $$db #$t1;; $$ break; .break; };'
Why is this the case?

If you need to read the buffer contents at kernel32!ReadFile you need to save the buffer address and step out of the function using gu (goup or step out)
when broken on ReadFile esp+8 points to the buffer so save it and step out
r $t1 = poi(#esp+8);gu
the first Dword of the buffer is poi(#$t1) compare it with the required Dword
and take necessary action with .if .else
.if( poi(#$t1) != 636c6163 ) {gc} .else {db #$t1 l10;gc}
putting this all together in one line the script shoule be
bp k*32!ReadFile "r $t1 =poi(#esp+8);gu;.if((poi(#$t1))!=636c6163){gc}.else{db #$t1 l10;gc}"
here 636c6163 is 'clac' (calc reversed ) use the dword you want instead of this
a sample run on calc.exe xp sp3 32 bits
bl
bp k*32!ReadFile "r $t1=poi(#esp+8);gu;.if((poi(#$t1))!=636c6163){gc}.else{db #$t1 l10;gc}"
.bpcmds
bp0 0x7c801812 "r $t1 = poi(#esp+8);gu;.if( (poi(#$t1))!=636c6163){gc}.else{db #$t1 l10;gc}"
0:002> g
00b865b0 63 61 6c 63 5f 77 68 61-74 69 73 5f 69 6e 74 72 calc_whatis_intr
00374df0 63 61 6c 63 00 ab ab ab-ab ab ab ab ab fe ee fe calc............

Related

file read using fgetc adds FF at the end

I'm reading a file using fgetc. File reading starts at an offset.At the end I see 8'hFF getting appended at the end of file.I'm expecting 6 bytes in the file but see 7 in them.I'm not sure why this is happening. Any ideas?
Below is my code:
module file_read();
integer fd,fd1,file_char,status;
logic [7:0] captured_data;
initial begin
fd = $fopen("input_file", "rb");
fd1 =$fopen("write_file","w");
status=$fseek(fd,1872,0);
assert (status);
// while ($fgetc(fd) != `EOF) begin
while (!$feof(fd)) begin
file_char=$fgetc(fd);
$display("file char is %h",file_char);
end
end // initial begin
Below are the file contents(in hex):
last line of input_file(total file size =1878):
0000750: 0000 1567 d48d ...g..
write_file:
0000000: 0000 1567 d48d ff ...g...
Thanks!
The reason you are getting the extra 'hff at the end of the written file is due to how $feof (or generally the foef C function) works. Simply put, it doesn't check if the next read is off the end of the file but if the previous read read off the end of the file. So, if you are reading character by character (byte by byte) using $fgetc, $feof will only return true once $fgetc reads off the end of the file, and returns EOF itself (ie, -1 or 'hff if converted to logic [7:0]). You should be checking for this error condition each time you read a byte, something like this:
integer fd, ch;
...
fd = $fopen("file.bin", "rb");
...
while ((ch = $fgetc(fd)) != -1) begin
$display(ch);
end

How do I print a string in one line in MARIE?

I want to print a set of letters in one line in MARIE. I modified the code to print Hello World and came up with:
ORG 0 / implemented using "do while" loop
WHILE, LOAD STR_BASE / load str_base into ac
ADD ITR / add index to str_base
STORE INDEX / store (str_base + index) into ac
CLEAR / set ac to zero
ADDI INDEX / get the value at ADDR
SKIPCOND 400 / SKIP if ADDR = 0 (or null char)
JUMP DO / jump to DO
JUMP PRINT / JUMP to END
DO, STORE TEMP / output value at ADDR
LOAD ITR / load iterator into ac
ADD ONE / increment iterator by one
STORE ITR / store ac in iterator
JUMP WHILE / jump to while
PRINT, SUBT ONE
SKIPCOND 000
JUMP PR
HALT
PR, OUTPUT
JUMP WHILE
ONE, DEC 1
ITR, DEC 0
INDEX, HEX 0
STR_BASE, HEX 12 / memory location of str
STR, HEX 48 / H
HEX 65 / E
HEX 6C / L
HEX 6C / L
HEX 6F / O
HEX 0 / carriage return
HEX 57 / W
HEX 6F / O
HEX 72 / R
HEX 6C / L
HEX 64 / D
HEX 0 / NULL char
My program ends up halting past two iterations. I can't seem to figure out how to print a set of characters in one line. Thanks.
Your value of STR_BASE is almost certainly incorrect. Based on what is here I would say it needs to be 18 instead of 12. Also you would either want to remove current null char that is between "HELLO" and "WORLD" and replace it with a space or simply remove that line, depending on your intended output.

Why Groovy file write with UTF-16LE produce BOM char?

Do you have idea why first and secod lines below do not produce BOM to the file and third line does? I thought UTF-16LE is correct encoding name and that encoding does no create BOM automatically to beginning of the file.
new File("foo-wo-bom.txt").withPrintWriter("utf-16le") {it << "test"}
new File("foo-bom1.txt").withPrintWriter("UnicodeLittleUnmarked") {it << "test"}
new File("foo-bom.txt").withPrintWriter("UTF-16LE") {it << "test"}
Another samples
new File("foo-bom.txt").withPrintWriter("UTF-16LE") {it << "test"}
new File("foo-bom.txt").getBytes().each {System.out.format("%02x ", it)}
prints
ff fe 74 00 65 00 73 00 74 00
and with java
PrintWriter w = new PrintWriter("foo.txt","UTF-16LE");
w.print("test");
w.close();
FileInputStream r = new FileInputStream("foo.txt");
int c;
while ((c = r.read()) != -1) {
System.out.format("%02x ",c);
}
r.close();
prints
74 00 65 00 73 00 74 00
With Java is does not produce BOM and with Groovy there is BOM.
There appears to be a difference in behavior with withPrintWriter. Try this out in your GroovyConsole
File file = new File("tmp.txt")
try {
String text = " "
String charset = "UTF-16LE"
file.withPrintWriter(charset) { it << text }
println "withPrintWriter"
file.getBytes().each { System.out.format("%02x ", it) }
PrintWriter w = new PrintWriter(file, charset)
w.print(text)
w.close()
println "\n\nnew PrintWriter"
file.getBytes().each { System.out.format("%02x ", it) }
} finally {
file.delete()
}
It outputs
withPrintWriter
ff fe 20 00
new PrintWriter
20 00
This is because calling new PrintWriter calls the Java constructor, but calling withPrintWriter eventually calls org.codehaus.groovy.runtime.ResourceGroovyMethods.writeUTF16BomIfRequired(), which writes the BOM.
I'm uncertain whether this difference in behavior is intentional. I was curious about this, so I asked on the mailing list. Someone there should know the history behind the design.
Edit: GROOVY-7465 was created out of the aforementioned discussion.

How to skip a line from execution in windbg everytime it hits?

Suppose I want to skip line 3 of function func everytime it is called
int func() {
int a = 10, b =20;
a = 25;
b = 30;
return a+b
}
so everytime It should be returning 40 (ie doesn't execute 3rd line a=25)
Is there any similar command in windbg like jmp in gdb?
again a very late answer but if messing with assembly is not preferable
set a conditional breakpoint to skip executing one line
in the example below 401034 is the line you do not want to execute
so set a conditional breakpoint on that line to skip it
bp 401034 "r eip = #$eip + size of current instruction";gc"
7 in this case gc = go from conditionl break
jmptest:\>dir /b
jmptest.c
jmptest:\>type jmptest.c
#include <stdio.h>
int func()
{
int a = 10 , b = 20;
a = 25;
b = 30;
return a+b;
}
int main (void)
{
int i , ret;
for (i= 0; i< 10; i++)
{
ret = func();
printf("we want 40 we get %d\n",ret);
}
return 0;
}
jmptest:\>cl /nologo /Zi jmptest.c
jmptest.c
jmptest:\>dir /b *.exe
jmptest.exe
jmptest:\>cdb -c "uf func;q" jmptest.exe | grep 401
00401020 55 push ebp
00401021 8bec mov ebp,esp
00401023 83ec08 sub esp,8
00401026 c745fc0a000000 mov dword ptr [ebp-4],0Ah
0040102d c745f814000000 mov dword ptr [ebp-8],14h
00401034 c745fc19000000 mov dword ptr [ebp-4],19h
0040103b c745f81e000000 mov dword ptr [ebp-8],1Eh
00401042 8b45fc mov eax,dword ptr [ebp-4]
00401045 0345f8 add eax,dword ptr [ebp-8]
00401048 8be5 mov esp,ebp
0040104a 5d pop ebp
0040104b c3 ret
jmptest:\>cdb -c "bp 401034 \"r eip = 0x40103b;gc\";g;q " jmptest.exe | grep wan
t
we want 40 we get 40
we want 40 we get 40
we want 40 we get 40
we want 40 we get 40
we want 40 we get 40
we want 40 we get 40
we want 40 we get 40
we want 40 we get 40
we want 40 we get 40
we want 40 we get 40
jmptest:\>
If you're familiar with assembly, you can use the a command to change the assembly (i.e. turn the opcodes for, "a = 25;" into all NOPs). This is what I typically do when I want to NOP out or otherwise change an instruction stream.
Occasionally people will rely on the fact that the byte code for the NOP instruction is 0x90 and use the e command to edit the memory (e.g. "ew #eip 0x9090"). This is the same result as using the a command.
Lastly, if you're hitting this operation infrequently and just want to manually skip the instruction you can use the, "Set Current Instruction" GUI operation:
http://msdn.microsoft.com/en-us/library/windows/hardware/ff542851(v=vs.85).aspx
There is a tutorial here that explains how to do this, you can set the offset so that it skips the line: http://cfc.kizzx2.com/index.php/tutorial-using-windbg-to-bypass-specific-functions-windbg-kung-fu-series/ and set the register eip to this value.
Also, you can set the breakpoint and put the command into the breakpoint to do the same: http://japrogbits.blogspot.co.uk/2010/01/using-breakpoints-to-skip-function-in.html and another blog: http://www.shcherbyna.com/?p=1234 and also you can use the .call to achieve the same: http://blogs.msdn.com/b/oldnewthing/archive/2007/04/27/2292037.aspx

Command to get GDI handle count from a crash dump

I have a crash dump and I suspect GDI leaks to be a cause of the crash
From the full crash dump is there anyway to find out the number of GDI handles used by my process when it crashed?
I have created a Windbg script to dump all GDI Handles from the GDI Handle table. See https://aloiskraus.wordpress.com/2016/06/25/show-gdi-handles-by-type-in-windbg/
When you dump it e.g. two times you can see what has changed there:
0:013> $$>a<"D:\GdiDump\DumpGdi.txt"
GDI Handle Table 00000000013e0000 0000000001561000
GDI Handle Count 14
DeviceContexts: 4
Regions: 2
Bitmaps: 2
Palettes: 0
Fonts: 3
Brushes: 3
Pens: 0
Uncategorized: 0
0:013> g
0:014> $$>a<"D:\GdiDump\DumpGdi.txt"
GDI Handle Table 00000000013e0000 0000000001561000
GDI Handle Count 1021
DeviceContexts: 8
Regions: 3
Bitmaps: 1003
Palettes: 0
Fonts: 3
Brushes: 4
Pens: 0
Uncategorized: 0
Here is the script
$$ Run as: $$>a<DumpGdi.txt
$$ Written by Alois Kraus 2016
$$ uses pseudo registers r0-5 and r8-r14
r #$t1=0
r #$t8=0
r #$t9=0
r #$t10=0
r #$t11=0
r #$t12=0
r #$t13=0
r #$t14=0
$$ Increment count is 1 byte until we find a matching field with the current pid
r #$t4=1
r #$t0=$peb
$$ Get address of GDI handle table into t5
.foreach /pS 3 /ps 1 ( #$GdiSharedHandleTable { dt ntdll!_PEB GdiSharedHandleTable #$t0 } ) { r #$t5 = #$GdiSharedHandleTable }
$$ On first call !address produces more output. Do a warmup
.foreach /pS 50 ( #$myStartAddress {!address #$t5} ) { }
$$ Get start address of file mapping into t2
.foreach /pS 4 /ps 40 ( #$myStartAddress {!address #$t5} ) { r #$t2 = #$myStartAddress }
$$ Get end address of file mapping into t3
.foreach /pS 7 /ps 40 ( #$myEndAddress {!address #$t5} ) { r #$t3 = #$myEndAddress }
.printf "GDI Handle Table %p %p", #$t2, #$t3
.for(; #$t2 < #$t3; r #$t2 = #$t2 + #$t4)
{
$$ since we walk bytewise through potentially invalid memory we need first to check if it points to valid memory
.if($vvalid(#$t2,4) == 1 )
{
$$ Check if pid matches
.if (wo(#$t2) == #$tpid )
{
$$ increase handle count stored in $t1 and increase step size by 0x18 because we know the cell structure GDICell has a size of 0x18 bytes.
r #$t1 = #$t1+1
r #$t4 = 0x18
$$ Access wType of GDICELL and increment per GDI handle type
.if (by(#$t2+6) == 0x1 ) { r #$t8 = #$t8+1 }
.if (by(#$t2+6) == 0x4 ) { r #$t9 = #$t9+1 }
.if (by(#$t2+6) == 0x5 ) { r #$t10 = #$t10+1 }
.if (by(#$t2+6) == 0x8 ) { r #$t11 = #$t11+1 }
.if (by(#$t2+6) == 0xa ) { r #$t12 = #$t12+1 }
.if (by(#$t2+6) == 0x10 ) { r #$t13 = #$t13+1 }
.if (by(#$t2+6) == 0x30 ) { r #$t14 = #$t14+1 }
}
}
}
.printf "\nGDI Handle Count %d", #$t1
.printf "\n\tDeviceContexts: %d", #$t8
.printf "\n\tRegions: %d", #$t9
.printf "\n\tBitmaps: %d", #$t10
.printf "\n\tPalettes: %d", #$t11
.printf "\n\tFonts: %d", #$t12
.printf "\n\tBrushes: %d", #$t13
.printf "\n\tPens: %d", #$t14
.printf "\n\tUncategorized: %d\n", #$t1-(#$t14+#$t13+#$t12+#$t11+#$t10+#$t9+#$t8)
It is unlikely since the only debugger extension gdikdx.dll tailored at gdi tasks is not actively maintained since the w2k version and i believe they stopped shipping it since not that many folks are into hacking into gdi internals - according to someone's statement i stumbled upon in a newsgroup - therefore it is no longer invested into.
You're left with only a few options all of which are unfortunately about runtime troubleshooting.
You could start with a tool like nirsoft's GDIView to monitor the use of GDI resources from your app and then progress to any of the runtime instrumentation options:
gdi leaks detector tool described on msdn
bug browser
leaktrap
P.S. could you be more specific on the actual reason of your particular crash?
Tess talks about a similar situation, perhaps this will give you a lead...
http://blogs.msdn.com/tess/archive/2009/02/03/net-memory-leak-to-dispose-or-not-to-dispose-that-s-the-1-gb-question.aspx
Here is an alternative script that dumps the gdi handles from GdiSharedHandleTable it can be used in live usermode / live kernelmode / dump mode
it can also be used in !for_each_process command string to dump gdi handles from all running process in a kernel mode debugging
it uses a .catch block to print the summary
in kd some times the GdiSharedhandleTable page will be paged out / truncated to less than its allocation size The peb header paged out etc problems arise
so this script tries to read as much as it is possible and when a memory access violation happens leaves the catch block and prints a summary of
what it was able to salvage
btw this script is for 32 bit for 64 bit the Pseudo registers need to be adjusted as needed
r $t19=0;r $t18=0;r $t17=0;r $t16=0;r $t15=0;r $t14=0;r $t13=0;r $t12=0;
r $t0 = ##c++(#$Peb->GdiSharedHandleTable)
r $t1 = (##c++(#$Peb->GdiSharedHandleTable) + 0xffffff )
r $t2 = 0
.catch {
.printf /D "<b>gdioffs Kaddr Pid Count Handle Type Tname
IsLive UAddr </b>\n";
.while(#$t0 < #$t1) {
.while( wo(#$t0+4) != #$tpid) {
r $t0 = #$t0+0x10 ; r $t2 = #$t2+1
}
.printf "%08x " , #$t0 ; .printf "%08x " , dwo(#$t0)
.printf "%08x " , wo(#$t0+4) ;.printf "%08x " , wo(#$t0+6)
.printf "%08x " , (wo(#$t0+8)<<0x10)+#$t2 ; .printf "%08x " , by(#$t0+a)
.if( by(#$t0+a) == 1 ) {r $t19=#$t19+1;.printf "DC "}
.elsif( by(#$t0+a) == 4 ) {r $t18=#$t18+1;.printf "Region "}
.elsif( by(#$t0+a) == 5 ) {r $t17=#$t17+1;.printf "Bitmap "}
.elsif( by(#$t0+a) == 8 ) {r $t16=#$t16+1;.printf "Pallete "}
.elsif( by(#$t0+a) == a ) {r $t15=#$t15+1;.printf "Font "}
.elsif( by(#$t0+a) == 10) {r $t14=#$t14+1;.printf "Brush "}
.elsif( by(#$t0+a) == 30) {r $t13=#$t13+1;.printf "Pen "}
.else {r $t12=#$t12+1;.printf "Unknown "}
.printf "%08x " , by(#$t0+b)
.printf "%08x\n" , dwo(#$t0+c)
r $t0 = #$t0+0x10
r $t2 = #$t2+1
}
}
r? #$t11 = ##c++(#$peb->ProcessParameters->ImagePathName.Buffer)
.printf /D "<b>Gdi Handles for %mu</b>\n", #$t11
.printf "Total Gdi Handles = %d\n", (#$t19+#$t18+#$t17+#$t16+#$t15+#$t14+#$t13+#$t12)
.printf "DC = %d\n" , #$t19 ; .printf "Font = %d\n" , #$t18
.printf "Region = %d\n" , #$t17 ; .printf "Brush = %d\n" , #$t16
.printf "Bitmap = %d\n" , #$t15 ; .printf "Pen = %d\n" , #$t14
.printf "Pallete = %d\n" , #$t13 ; .printf "Unknpown = %d\n" , #$t12
result of execution
0:000> $$>a< c:\wdscr\dumpgdi.txt
gdioffs Kaddr Pid Count Handle Type Tname ;IsLive UAddr
00472b30 fe6b5728 00000ca4 00000000 0d0102b3 00000001 DC 00000040 000e0cb0
00472be0 fdf73da8 00000ca4 00000000 420502be 00000005 Bitmap 00000040 00000000
004737b0 fddac108 00000ca4 00000000 9605037b 00000005 Bitmap 00000040 00000000
00474030 fe76eda8 00000ca4 00000000 eb050403 00000005 Bitmap 00000040 00000000
00474c90 fddde008 00000ca4 00000000 d70a04c9 0000000a Font 00000040 001fb1e8
0047ab80 fddab008 00000ca4 00000000 ba050ab8 00000005 Bitmap 00000040 00000000
0047f270 fddbcda8 00000ca4 00000000 16050f27 00000005 Bitmap 00000040 00000000
0047fef0 fdee4da8 00000ca4 00000000 cd050fef 00000005 Bitmap 00000040 00000000
004809f0 fe72eda8 00000ca4 00000000 3405109f 00000005 Bitmap 00000040 00000000
00480e50 fdda5aa8 00000ca4 00000000 0e0510e5 00000005 Bitmap 00000040 00000000
00481cf0 ffb0fda8 00000ca4 00000000 df0511cf 00000005 Bitmap 00000040 00000000
00481d70 fddb0da8 00000ca4 00000000 930511d7 00000005 Bitmap 00000040 00000000
00482020 ff4a1da8 00000ca4 00000000 d4051202 00000005 Bitmap 00000040 00000000
00482060 fddd4008 00000ca4 00000000 39051206 00000005 Bitmap 00000040 00000000
00482170 fddb6008 00000ca4 00000000 20051217 00000005 Bitmap 00000040 00000000
00483140 ff4a0008 00000ca4 00000000 4e051314 00000005 Bitmap 00000040 00000000
00483870 ff427980 00000ca4 00000000 6d051387 00000005 Bitmap 00000040 00000000
00483d80 fe7d04b0 00000ca4 00000000 bd0513d8 00000005 Bitmap 00000040 00000000
00484620 ff437eb8 00000ca4 00000000 0d101462 00000010 Brush 00000040 000f0fd8
004846a0 fddc2da8 00000ca4 00000000 d305146a 00000005 Bitmap 00000040 00000000
00484b80 fdf1a728 00000ca4 00000000 530114b8 00000001 DC 00000040 000e0ae0
Memory access error at ') != #$tpid) <-------- jumps out of catch block here
Gdi Handles for C:\Windows\system32\calc.exe
Total Gdi Handles = 21
DC = 2
Font = 0
Region = 17
Brush = 0
Bitmap = 1
Pen = 1
Pallete = 0
Unknpown = 0