the question is to print the answer for b+c-d
but i m not getting the anwser...help!!! instead of getting 12 i m getting 49
[here b=10 c=7 d= 5]
C:\>debug
-e 2000
0AFC:2000 0D.10 0A.7 36.5
-a 1000
0AFC:1000 mov al, [2000]
0AFC:1003 add al, [2001]
0AFC:1007 sub al, [2002]
0AFC:100B mov [2003], al
0AFC:100E hlt
0AFC:100F
-g 1000 100F
Program terminated normally
-d 2000 2003
0AFC:2000 10 07 05 49 ...I
-g= 1000 100F
Related
I would like to see the first few instructions that my machine executes at startup. On x64 the reset vector is at physical address FFFFFFF0. I have enabled local kernel debugging on my Windows 10, restarted the PC and started WinDbg as Administrator. When doing a kernel debug (File -> Kernel Debug...), I am not sure what to type at the lkd> prompt to unassemble the code. I can do "!db FFFFFFF0" which displays some bytes:
#fffffff0 90 90 e9 83 e8 00 00 00-fc 00 00 00 00 00 e1 ff ................
#100000000 bb 00 fc 6a 00 00 e1 a9-00 00 bb 00 fc 6a 00 00 ...j.........j..
#100000010 01 aa 00 00 bb 00 fc 6a-00 00 21 aa 00 00 bb 00 .......j..!.....
#100000020 fc 6a 00 00 41 aa 00 00-bb 00 fc 6a 00 00 61 aa .j..A......j..a.
#100000030 00 00 bb 00 fc 6a 00 00-81 aa 00 00 bb 00 fc 6a .....j.........j
#100000040 00 00 a1 aa 00 00 bb 00-fc 6a 00 00 c1 aa 00 00 .........j......
#100000050 bb 00 fc 6a 00 00 e1 aa-00 00 bb 00 fc 6a 00 00 ...j.........j..
#100000060 01 ab 00 00 bb 00 fc 6a-00 00 21 ab 00 00 bb 00 .......j..!.....
then I tried "!u FFFFFFF0" which returns:
Op:
Dest:
Dest: 0
Src:
Srct: 0
it is just two nops and a jump if you mean you need to disassemble it as 16 bit
use ur
i patched the first 16 bytes from your query and disassemble it as 16 bit for demo below
0:000> db . l10
772805a6 90 90 e9 83 e8 00 00 00-fc 00 00 00 00 00 e1 ff ................
0:000> ur . l3
ntdll!LdrpDoDebuggerBreak+0x2c:
772805a6 90 nop
772805a7 90 nop
772805a8 e983e8 jmp EE2E
0:000>
Local Kernel Debugging is not Live it is Dead Debugging it operates on a snap shot
livekd operates on a state as the system was when dumped
!u is undocumented iirc and doesn't disassemble it provides a verbose details of a single instruction
0:000> u .+1 l1
ntdll!LdrpDoDebuggerBreak+0x2d:
772805a7 8975fc mov dword ptr [ebp-4],esi
0:000> !u 772805a7
Op: mov
Dest: esi
Dest: fffffffe
Src: dword ptr [ebp-4]
Srct: 0
0:000>
if you are looking for disassembling something like bios code use up
unassemble physical
kd> up cs:7c00 l1
0008:00007c00 eb52 jmp 00007c54
kd> up cs:7c54 l20
0008:00007c54 fa cli
0008:00007c55 33c0 xor eax,eax
0008:00007c57 8ed0 mov ss,ax
0008:00007c59 bc007cfb68 mov esp,68FB7C00h
0008:00007c5e c0071f rol byte ptr [edi],1Fh
0008:00007c61 1e push ds
0008:00007c62 686600cb88 push 88CB0066h
0008:00007c67 16 push ss
0008:00007c68 0e push cs
0008:00007c69 006681 add byte ptr [esi-7Fh],ah
0008:00007c6c 3e0300 add eax,dword ptr ds:[eax]
0008:00007c6f 4e dec esi
0008:00007c70 54 push esp
0008:00007c71 46 inc esi
0008:00007c72 53 push ebx
0008:00007c73 7515 jne 00007c8a
0008:00007c75 b441 mov ah,41h
0008:00007c77 bbaa55cd13 mov ebx,13CD55AAh
0008:00007c7c 720c jb 00007c8a
0008:00007c7e 81fb55aa7506 cmp ebx,675AA55h
0008:00007c84 f7c101007503 test ecx,3750001h
0008:00007c8a e9dd001e83 jmp 831e7d6c
i dont think debug.com is shipped in windows 10 x64 if you can get yourhands on win732bit etc you can use debug to disassemble the address
:>debug
-u f000:fff0 l1
F000:FFF0 EA5BE000F0 JMP F000:E05B
-u f000:e05b l1
F000:E05B EA3D3A00F0 JMP F000:3A3D
-u f000:3a3d l1
F000:3A3D FA CLI
-u f000:3a3d
F000:3A3D FA CLI
F000:3A3E B800F0 MOV AX,F000
F000:3A41 8ED0 MOV SS,AX
F000:3A43 BC493A MOV SP,3A49
F000:3A46 E93A8E JMP C883
F000:3A49 4B DEC BX
F000:3A4A 3ABB1DF1 CMP BH,[BP+DI+F11D]
F000:3A4E 2E CS:
F000:3A4F F747020800 TEST WORD PTR [BX+02],0008
F000:3A54 740E JZ 3A64
F000:3A56 32C0 XOR AL,AL
F000:3A58 BC5E3A MOV SP,3A5E
F000:3A5B E9E50B JMP 4643
-
I don't think you can step or disassemble the Physical Address f000:ffff in windbg.
I don't think it is mapped at all
I saw your post !db showing output so I wasn't quiet sure if it is available in x64.
afaik these codes are executed in Real Mode and you cant access them in protected mode with a software debugger like windbg
anyway back to the point
if you want to step through reset vector to MBR use a hardware emulator like bochs.
install bochs (2.6.11 x64 latest at the time of this edit) with the dlx demo
if you installed bochs in windows 10 you may need to give permissions to the bochs folder
(right click bochs folder->properties->security->edit full or write as the case may be)
once permission is granted you can double click the run.bat and you should land on LILo boot prompt
if you are here then close the bochs
open an elevated cmd prompt
and execute ../bochsdbg -f bochsrc
it will stop on Reset Vector
C:\Program Files\Bochs-2.6.11\dlxlinux>..\bochsdbg.exe -f ./bochsrc.bxrc
========================================================================
Bochs x86 Emulator 2.6.11
Built from SVN snapshot on January 5, 2020
Timestamp: Sun Jan 5 08:36:00 CET 2020
========================================================================
00000000000i[ ] reading configuration from ./bochsrc.bxrc
00000000000i[ ] installing win32 module as the Bochs GUI
00000000000i[ ] using log file bochsout.txt
Next at t=0
(0) [0x0000fffffff0] f000:fff0 (unk. ctxt): jmpf 0xf000:e05b ; ea5be000f0
set a breakpoint at 0x7c00 using lb 0x7c00 (MBR START)
use s or n to step through
if you single step using s you may need to press s or ENTER 42.5 million times to reach MBR
here is a step through from reset vector to MBR using n or next
<bochs:5> blist
Num Type Disp Enb Address
1 lbreakpoint keep y 0x0000000000007c00
<bochs:6> u
00000000fffffff0: ( ): jmpf 0xf000:e05b ; ea5be000f0
<bochs:7> n
Next at t=1
(0) [0x0000000fe05b] f000:e05b (unk. ctxt): xor ax, ax ; 31c0
<bochs:8>
Next at t=2
(0) [0x0000000fe05d] f000:e05d (unk. ctxt): out 0x0d, al ; e60d
<bochs:9>
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cut off
Next at t=32
(0) [0x0000000fe0c4] f000:e0c4 (unk. ctxt): rep stosw word ptr es:[di], ax ; f3ab
<bochs:39>
Next at t=160
(0) [0x0000000fe0c6] f000:e0c6 (unk. ctxt): call .+13763 (0x000f168c) ; e8c335
<bochs:40>
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cut off
Next at t=5078
(0) [0x0000000fe0cf] f000:e0cf (unk. ctxt): mov word ptr ds:0x0413, ax ; a31304
<bochs:43>
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cut off
Next at t=330285
(0) [0x0000000fe1f5] f000:e1f5 (unk. ctxt): call .-18344 (0x000f9a50) ; e858b8
<bochs:146>
Next at t=1403926
(0) [0x0000000fe1f8] f000:e1f8 (unk. ctxt): mov cx, 0xc000 ; b900c0
<bochs:147>
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cut off
Next at t=1877324
(0) [0x0000000fe21e] f000:e21e (unk. ctxt): call .+14565 (0x000f1b06) ; e8e538
<bochs:161>
Next at t=5333736
(0) [0x0000000fe221] f000:e221 (unk. ctxt): call .+21186 (0x000f34e6) ; e8c252
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx cut off
(0) [0x0000000fe230] f000:e230 (unk. ctxt): call .+12532 (0x000f1327) ; e8f430
<bochs:167>
Next at t=42311959
(0) [0x0000000fe233] f000:e233 (unk. ctxt): sti ; fb
<bochs:168>
Next at t=42311960
(0) [0x0000000fe234] f000:e234 (unk. ctxt): int 0x19 ; cd19
<bochs:169>
(0) Breakpoint 1, 0x0000000000007c00 in ?? () <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Next at t=42409977 <<<<< 42.5 million instructions until MBR is reached
(0) [0x000000007c00] 0000:7c00 (unk. ctxt): cli ; fa
<bochs:170> q
(0).[42409977] [0x000000007c00] 0000:7c00 (unk. ctxt): cli ; fa
Bochs is exiting. Press ENTER when you're ready to close this window.
I am used to getting nice listing files from C code where I can see lovely source code intertwined with opcodes and hex offsets for debugging as seen here: List File In C (.LST) List File In C (.LST)
And the -S directive gets me the assembler code only from g++ for Ada.... but I can't seem to get it to give up the good stuff so I can debug a nasty elaboration crash.
Any thoughts on the GNAT compiler switches to send in?
Maybe this helps. The next command generates something similar to what you refer to:
$ gnatmake -g main.adb -cargs -Wa,-adhln > main.lst
The -cargs (a so-called mode switch) causes gnatmake to pass the subsequent arguments to the compiler. The compiler subsequently passes the -adhln switches to the assembler (see here). But you might as wel use objdump -d -S main.o to see the assembly/source code after build.
main.adb
with Ada.Text_IO; use Ada.Text_IO;
procedure Main is
begin
Put_Line ("Hello, world!");
end Main;
output (main.lst)
1 .file "main.adb"
2 .text
3 .Ltext0:
4 .section .rodata
5 .LC1:
6 0000 48656C6C .ascii "Hello, world!"
6 6F2C2077
6 6F726C64
6 21
7 000d 000000 .align 8
8 .LC0:
9 0010 01000000 .long 1
10 0014 0D000000 .long 13
11 .text
12 .align 2
13 .globl _ada_main
15 _ada_main:
16 .LFB1:
17 .file 1 "main.adb"
1:main.adb **** with Ada.Text_IO; use Ada.Text_IO;
2:main.adb ****
3:main.adb **** procedure Main is
18 .loc 1 3 1
19 .cfi_startproc
20 0000 55 pushq %rbp
21 .cfi_def_cfa_offset 16
22 .cfi_offset 6, -16
23 0001 4889E5 movq %rsp, %rbp
24 .cfi_def_cfa_register 6
25 0004 53 pushq %rbx
26 0005 4883EC08 subq $8, %rsp
27 .cfi_offset 3, -24
28 .LBB2:
4:main.adb **** begin
5:main.adb **** Put_Line ("Hello, world!");
29 .loc 1 5 4
30 0009 B8000000 movl $.LC1, %eax
30 00
31 000e BA000000 movl $.LC0, %edx
31 00
32 0013 4889C1 movq %rax, %rcx
33 0016 4889D3 movq %rdx, %rbx
34 0019 4889D0 movq %rdx, %rax
35 001c 4889CF movq %rcx, %rdi
36 001f 4889C6 movq %rax, %rsi
37 0022 E8000000 call ada__text_io__put_line__2
37 00
38 .LBE2:
6:main.adb **** end Main;
39 .loc 1 6 5
40 0027 4883C408 addq $8, %rsp
41 002b 5B popq %rbx
42 002c 5D popq %rbp
43 .cfi_def_cfa 7, 8
44 002d C3 ret
45 .cfi_endproc
46 .LFE1:
48 .Letext0:
You might want to look at the section on debugging control in the top-secret GNAT documentation, especially the -gnatG switch.
This question already has answers here:
Why do the addresses in my assembler dump differ from the addresses of registers?
(1 answer)
GDB - Address of breakpoint
(1 answer)
Closed 2 years ago.
Having this:
0000000000001135 <f1>:
1135: 55 push %rbp
1136: 48 89 e5 mov %rsp,%rbp
1139: c7 45 fc 01 00 00 00 movl $0x1,-0x4(%rbp)
1140: c7 45 f8 02 00 00 00 movl $0x2,-0x8(%rbp)
1147: c7 45 f4 03 00 00 00 movl $0x3,-0xc(%rbp)
114e: 90 nop
114f: 5d pop %rbp
1150: c3 retq
....
I want to break at the beginning address (0x0000000000001135) with
gdb:
Reading symbols from a.out...done.
(gdb) break *0x0000000000001135
+break *0x0000000000001135
Breakpoint 1 at 0x1135: file a.c, line 3.
(gdb) layout asm
+layout asm
(gdb) r
+r
Starting program: /home/shepherd/Desktop/bin/a.out
[4]+ Stopped gdb -q -tui a.out
result: crash after spcifying the address explicitly.
however, being used symbol, no problem:
Reading symbols from a.out...done.
(gdb) layout asm
+layout asm
(gdb) break *f1
+break *f1
Breakpoint 1 at 0x1135: file a.c, line 3.
(gdb) r
+r
Starting program: /home/shepherd/Desktop/bin/a.out
Breakpoint 1, f1 () at a.c:3
(gdb) si
+si
(gdb)
...
I have observered two addresses. Before break *f1 and after break *f1. The first one was 0x0000000000001135. after however was
0x555555555135 <f1>. Why is gdb lying about addresses then? And how can I find out which what to use?
I have a question about symbol tables. Now according to my textbook the rules of a symbol table are as follows:
Find the .ORIG statement,
which tells us the address of the first instruction and initialize location counter (LC), which keeps track of the
current instruction.
For each non-empty line in the program:
a) If line contains a label, add label and LC to symbol table.
b) Increment LC.
– NOTE: If statement is .BLKW or .STRINGZ,
increment LC by the number of words allocated.
Stop when .END statement is reached.
I'm having a problem with the second rule. Specifically, the statement about .BLKW or .STRINGZ (increment LC by the number of words allocated). I could not find any example in the textbook that could help me understand this, but I did find some code online.
In my example code, what are the addresses of the statements that contain .BLKW and .STRINGZ?
01 .ORIG x 3000
02
03 INIT
04 LEA R0, START.STR
05 JSR PRINST.STR
06 LD R0, TEN
07 LEA R1, DATA.B
08
09 STORE_LOOP
10 STR RO, R1, %0
11 ADD R1, R1, %1
12 ADD R0, R0, %-1
13 BRp ST.LOOP
14
15 LD R0, TEN
16 ADD R1, R1, %-1
17 AND R2, R2, %0
18
19 ADD_LOOP
20 LDR R3, R1, %0
21 ADD R2, R3, R2
22 ADD R1, R1, %-1
23 ADD R0, R0, %-1
24 BRp ADD_LOOP
25
26 STORE_SUM
27 ST R2, RESULT
28 TRAP %25
29
30 PRINT_STR
31 ST R7, SAVE.R7
32 PUTS
33 LD R7, SAVE.R7
34 RET
35
36 TEN .FILL #10
37 SAVE.R7 .BLKW #1
38 DATA.B .BLKW #10
39 START_STR .STRINGZ "Starting..."
40 RESULT .FILL #0
41 END
Code annotated with comments showing the address of each one.
01 .ORIG x 3000
02
03 INIT ; x3000
04 LEA R0, START.STR ; x3000
05 JSR PRINST.STR ; x3001
06 LD R0, TEN ; x3002
07 LEA R1, DATA.B ; x3003
08
09 STORE_LOOP ; x3004
10 STR RO, R1, %0 ; x3004
11 ADD R1, R1, %1 ; x3005
12 ADD R0, R0, %-1 ; x3006
13 BRp ST.LOOP ; x3007
14
15 LD R0, TEN ; x3008
16 ADD R1, R1, %-1 ; x3009
17 AND R2, R2, %0 ; x300A
18
19 ADD_LOOP ; x300B
20 LDR R3, R1, %0 ; x300B
21 ADD R2, R3, R2 ; x300C
22 ADD R1, R1, %-1 ; x300D
23 ADD R0, R0, %-1 ; x300E
24 BRp ADD_LOOP ; x300F
25
26 STORE_SUM ; x3010
27 ST R2, RESULT ; x3010
28 TRAP %25 ; x3011
29
30 PRINT_STR ; x3012
31 ST R7, SAVE.R7 ; x3012
32 PUTS ; x3013
33 LD R7, SAVE.R7 ; x3014
34 RET ; x3015
35
36 TEN .FILL #10 ; x3016
37 SAVE.R7 .BLKW #1 ; x3017
38 DATA.B .BLKW #10 ; x3018
39 START_STR .STRINGZ "Starting..."; x3022
40 RESULT .FILL #0 ; x302E
41 END
Things to note.
Whenever you encounter a BLKW you add however many addresses it is reserving.
Whenever you encounter a .stringz you add however many characters that are in the string PLUS 1 for the NUL terminator character.
Also (for at least the tools I work with) some assemblers / simulators will generate a symbol table file when assembling, and some simulators will visibly show what labels are at what addresses.
There appear to be some similar-looking long alphanumeric strings that commonly occur in Mach-O 64 bit executables and ELF 64-bit LSB executables among other symbols that are not alphanumeric:
cat /bin/bash | grep -c "AWAVAUATSH"
has 181 results, and
cat /usr/bin/gzip | grep -c "AWAVAUATSH"
has 9 results.
What are these strings?
Interesting question. Since I didn't know the answer, here are the steps I took to figure it out:
Where in the file does the string occur?
strings -otx /bin/gzip | grep AWAVAUATUSH
35e0 AWAVAUATUSH
69a0 AWAVAUATUSH
7920 AWAVAUATUSH
8900 AWAVAUATUSH
92a0 AWAVAUATUSH
Which section is that in?
readelf -WS /bin/gzip
There are 28 section headers, starting at offset 0x16860:
Section Headers:
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000 000000 00 0 0 0
[ 1] .interp PROGBITS 0000000000400238 000238 00001c 00 A 0 0 1
[ 2] .note.ABI-tag NOTE 0000000000400254 000254 000020 00 A 0 0 4
[ 3] .note.gnu.build-id NOTE 0000000000400274 000274 000024 00 A 0 0 4
[ 4] .gnu.hash GNU_HASH 0000000000400298 000298 000038 00 A 5 0 8
[ 5] .dynsym DYNSYM 00000000004002d0 0002d0 000870 18 A 6 1 8
[ 6] .dynstr STRTAB 0000000000400b40 000b40 000360 00 A 0 0 1
[ 7] .gnu.version VERSYM 0000000000400ea0 000ea0 0000b4 02 A 5 0 2
[ 8] .gnu.version_r VERNEED 0000000000400f58 000f58 000080 00 A 6 1 8
[ 9] .rela.dyn RELA 0000000000400fd8 000fd8 000090 18 A 5 0 8
[10] .rela.plt RELA 0000000000401068 001068 0007e0 18 A 5 12 8
[11] .init PROGBITS 0000000000401848 001848 00001a 00 AX 0 0 4
[12] .plt PROGBITS 0000000000401870 001870 000550 10 AX 0 0 16
[13] .text PROGBITS 0000000000401dc0 001dc0 00f1ba 00 AX 0 0 16
[14] .fini PROGBITS 0000000000410f7c 010f7c 000009 00 AX 0 0 4
... etc.
From above output, we see that all instances of AWAVAUATUSH are in .text section (which covers [0x1dc0, 0x10f7a) offsets of the file.
Since this is .text, we expect to find executable instructions there. The address we are interested in is 0x401dc0 (.text address) + 0x35e0 (offset of AWAVAUATUSH in the file) - 0x1dc0 (offset of .text in the file) == 0x4035e0.
First, let's check that the above arithmetic is correct:
gdb -q /bin/gzip
(gdb) x/s 0x4035e0
0x4035e0: "AWAVAUATUSH\203\354HdH\213\004%("
Yes, it is. Next, what are the instructions there?
(gdb) x/20i 0x4035e0
0x4035e0: push %r15
0x4035e2: push %r14
0x4035e4: push %r13
0x4035e6: push %r12
0x4035e8: push %rbp
0x4035e9: push %rbx
0x4035ea: sub $0x48,%rsp
0x4035ee: mov %fs:0x28,%rax
0x4035f7: mov %rax,0x38(%rsp)
0x4035fc: xor %eax,%eax
0x4035fe: mov 0x213363(%rip),%rax # 0x616968
0x403605: mov %rdi,(%rsp)
0x403609: mov %rax,0x212cf0(%rip) # 0x616300
0x403610: cmpb $0x7a,(%rax)
0x403613: je 0x403730
0x403619: mov $0x616300,%ebx
0x40361e: mov (%rsp),%rdi
0x403622: callq 0x4019f0 <strlen#plt>
0x403627: cmp $0x20,%eax
0x40362a: mov %rax,0x8(%rsp)
These indeed look like normal executable instructions. What is the opcode of push %r15? This table shows that 0x41, 0x57 is indeed push %r15, and these opcodes just happen to spell AW in ASCII. Similarly, push %r14 is encoded as 0x41, 0x56, which just happens spell AV. Etc.
P.S. My version of gzip is fully stripped, which is why GDB shows no symbols in the above disassembly. If I use a non-stripped version instead, I see:
strings -o -tx gzip | grep AWAVAUATUSH | head -1
6be0 AWAVAUATUSH
readelf -WS gzip | grep text
[13] .text PROGBITS 0000000000401b00 001b00 00d102 00 AX 0 0 16
So the string is still in .text.
gdb -q ./gzip
(gdb) p/a 0x0000000000401b00 + 0x6be0 - 0x001b00
$1 = 0x406be0 <inflate_dynamic>
(gdb) disas/r 0x406be0
Dump of assembler code for function inflate_dynamic:
0x0000000000406be0 <+0>: 41 57 push %r15
0x0000000000406be2 <+2>: 41 56 push %r14
0x0000000000406be4 <+4>: 41 55 push %r13
0x0000000000406be6 <+6>: 41 54 push %r12
0x0000000000406be8 <+8>: 55 push %rbp
0x0000000000406be9 <+9>: 53 push %rbx
0x0000000000406bea <+10>: 48 81 ec 38 05 00 00 sub $0x538,%rsp
...
Now you can clearly see the ASCII 0x4157415641554154... sequence of opcodes.
P.P.S. The original question asks about AWAVAUATSH, which does appear in my Mach-O bash and gzip, but not in Linux ones. Conversely, AWAVAUATUSH does not appear in my Mach-O binaries.
The answer is however the same. The AWAVAUATSH sequence is the same as AWAVAUATUSH, but with push %rbp omitted.
P.P.P.S Here are some other "fun" strings of the same nature:
strings /bin/bash | grep '^A.A.A.' | sort | uniq -c | sort -nr | head
44 AWAVAUATUSH
27 AVAUATUSH
16 AWAVAUA
15 AVAUATUH
14 AWAVAUI
14 AWAVAUATUH
12 AWAVAUATI
8 AWAVAUE1
8 AVAUATI
6 AWAVAUATU