I've got a toy x86 assembly program that I'm writing and compiling with as and ld:
.text
.global _start
_start:
movq $1, %rax
movq $0x7FFFFFFF, %rbx
L1:
cmp %rbx, %rax
je L2
addq $1, %rax
jmp L1
L2:
movq %rax, %rbx
movq $1, %rax
int $0x80
And then to build:
as -o test.o test.S
ld -s -o test test.o
The second step of this -- ld -- generates an additional note:
$ objdump -D test
test: file format elf64-x86-64
Disassembly of section .note.gnu.property:
00000000004000e8 <.note.gnu.property>:
4000e8: 04 00 add $0x0,%al
4000ea: 00 00 add %al,(%rax)
4000ec: 10 00 adc %al,(%rax)
4000ee: 00 00 add %al,(%rax)
4000f0: 05 00 00 00 47 add $0x47000000,%eax
4000f5: 4e 55 rex.WRX push %rbp
4000f7: 00 01 add %al,(%rcx)
4000f9: 00 00 add %al,(%rax)
4000fb: c0 04 00 00 rolb $0x0,(%rax,%rax,1)
4000ff: 00 01 add %al,(%rcx)
400101: 00 00 add %al,(%rax)
400103: 00 00 add %al,(%rax)
400105: 00 00 add %al,(%rax)
...
Disassembly of section .text:
0000000000401000 <.text>:
401000: 48 c7 c0 01 00 00 00 mov $0x1,%rax
401007: 48 c7 c3 ff ff ff 7f mov $0x7fffffff,%rbx
40100e: 48 39 d8 cmp %rbx,%rax
401011: 74 06 je 0x401019
401013: 48 83 c0 01 add $0x1,%rax
401017: eb f5 jmp 0x40100e
401019: 48 89 c3 mov %rax,%rbx
40101c: 48 c7 c0 01 00 00 00 mov $0x1,%rax
401023: cd 80 int $0x80
Is there a way to eliminate or prevent generation of the .note.gnu.property section?
I didn't find a direct flag to pass to ld to prevent this section's generation (neither -s nor -s -x work), even calling strip --strip-all doesn't remove this section, however, strip --remove-section=.note.gnu.property test did remove the section:
$ as -o test.o test.s
$ ld -o test test.o
$ objdump -D test
test: file format elf64-x86-64
Disassembly of section .note.gnu.property:
00000000004000e8 <.note.gnu.property>:
4000e8: 04 00 add $0x0,%al
4000ea: 00 00 add %al,(%rax)
4000ec: 10 00 adc %al,(%rax)
4000ee: 00 00 add %al,(%rax)
4000f0: 05 00 00 00 47 add $0x47000000,%eax
4000f5: 4e 55 rex.WRX push %rbp
4000f7: 00 01 add %al,(%rcx)
4000f9: 00 00 add %al,(%rax)
4000fb: c0 04 00 00 rolb $0x0,(%rax,%rax,1)
4000ff: 00 01 add %al,(%rcx)
400101: 00 00 add %al,(%rax)
400103: 00 00 add %al,(%rax)
400105: 00 00 add %al,(%rax)
...
Disassembly of section .text:
0000000000401000 <_start>:
401000: 48 c7 c0 01 00 00 00 mov $0x1,%rax
401007: 48 c7 c3 ff ff ff 7f mov $0x7fffffff,%rbx
000000000040100e <L1>:
40100e: 48 39 d8 cmp %rbx,%rax
401011: 74 06 je 401019 <L2>
401013: 48 83 c0 01 add $0x1,%rax
401017: eb f5 jmp 40100e <L1>
0000000000401019 <L2>:
401019: 48 89 c3 mov %rax,%rbx
40101c: 48 c7 c0 01 00 00 00 mov $0x1,%rax
401023: cd 80 int $0x80
$ strip --remove-section=.note.gnu.property test
strip: test: warning: empty loadable segment detected at vaddr=0x400000, is this intentional?
$ objdump -D test
test: file format elf64-x86-64
Disassembly of section .text:
0000000000401000 <.text>:
401000: 48 c7 c0 01 00 00 00 mov $0x1,%rax
401007: 48 c7 c3 ff ff ff 7f mov $0x7fffffff,%rbx
40100e: 48 39 d8 cmp %rbx,%rax
401011: 74 06 je 0x401019
401013: 48 83 c0 01 add $0x1,%rax
401017: eb f5 jmp 0x40100e
401019: 48 89 c3 mov %rax,%rbx
40101c: 48 c7 c0 01 00 00 00 mov $0x1,%rax
401023: cd 80 int $0x80
objcopy --remove-section .note.gnu.property test
works for me.
Related
I'm currently trying to extract the raw payload from an ICMP packet.
I've managed to trim it down to the format I like (without the first 5 characters on each line and without the ....... stuff).
Original format:
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 10 b4 00 00 00 00 50 4b 03 04 14 00 c.........PK....
0030 09 00 08 00 92 ac 88 51 e2 f5 38 a1 6d 70 03 00 .......Q..8.mp..
0040 94 72 03 00 08 00 1c 00 66 6c 61 67 2e 6a 70 67 .r......thing.jpg
0050 55 54 09 00 03 d3 e3 cf 5f e7 UT......_.
Scripts:
awk '{x="";x=substr($0,5,50);gsub(/ +/,"",x);print x}' nontrimmed.txt > raw.txt
tr -d "\n" < raw,txt > newraw.txt
Result:
cafe0000babedead0000beef08004500004c0001000040019b48c0a801c8b9f56302080010b400000000504b030414000900080092ac8851e2f538a16d7003009472030008001c00666c61672e6a70675554090003d3e3cf5fe7cafe0000babedead0000beef08004500004c0001000040019b48c0a801c8b9f5630208005b5000000000e3cf5f75780b000104e803000004e80300003bc....ect
However, I'd like to get a specific number of bytes every x characters - i.e this:
ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00
00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5
63 02 08 00 10 b4 00 00 00 00 50 4b 03 04 14 00
09 00 08 00 92 ac 88 51 e2 f5 38 a1 6d 70 03 00
94 72 03 00 08 00 1c 00 66 6c 61 67 2e 6a 70 67
55 54 09 00 03 d3 e3 cf 5f e7
Would become this:
504b030414000900080092ac8851e2f538a16d7003009472030008001c00666c61672e6a70675554090003d3e3cf5fe7
Instead of this:
cafe0000babedead0000beef08004500004c0001000040019b48c0a801c8b9f56302080010b400000000504b030414000900080092ac8851e2f538a16d7003009472030008001c00666c61672e6a70675554090003d3e3cf5fe7cafe0000babedead0000beef08004500004c0001000040019b48c0a801c8b9f5630208005b5000000000e3cf5f75780b000104e803000004e80300003bc....ect
But for multiple different ones of the same format:
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 10 b4 00 00 00 00 50 4b 03 04 14 00 c.........PK....
0030 09 00 08 00 92 ac 88 51 e2 f5 38 a1 6d 70 03 00 .......Q..8.mp..
0040 94 72 03 00 08 00 1c 00 66 6c 61 67 2e 6a 70 67 .r......flag.jpg
0050 55 54 09 00 03 d3 e3 cf 5f e7 UT......_.
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 5b 50 00 00 00 00 e3 cf 5f 75 78 0b c...[P......_ux.
0030 00 01 04 e8 03 00 00 04 e8 03 00 00 3b c1 7d b7 ............;.}.
0040 30 0b ce 53 1e 99 d2 3a 1b 83 4c 7c be cd ef fa 0..S...:..L|....
0050 54 86 4d 24 19 58 c5 a9 b1 4d T.M$.X...M
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 3e f4 00 00 00 00 dd 56 4c 00 11 bf c...>......VL...
0030 42 22 2a 52 86 75 01 0a e2 90 90 f5 2b ec d0 67 B"*R.u......+..g
0040 74 5a 17 70 05 b6 27 35 21 cf 98 fb a2 5e 82 a8 tZ.p..'5!....^..
0050 56 f9 05 05 3d 3e 80 3f 68 23 V...=>.?h#
Any ideas? Thanks!
Is this what you're trying to do?
$ awk -v OFS= '{$1=$NF=""; x=x $0} END{print substr(x,85)}' file
504b030414000900080092ac8851e2f538a16d7003009472030008001c00666c61672e6a70675554090003d3e3cf5fe7
The above was run against your "Original format" input file:
$ cat file
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 10 b4 00 00 00 00 50 4b 03 04 14 00 c.........PK....
0030 09 00 08 00 92 ac 88 51 e2 f5 38 a1 6d 70 03 00 .......Q..8.mp..
0040 94 72 03 00 08 00 1c 00 66 6c 61 67 2e 6a 70 67 .r......thing.jpg
0050 55 54 09 00 03 d3 e3 cf 5f e7 UT......_.
If your input file can contain multiple records then:
$ awk -v OFS= '{$1=$NF=""; $0=$0; x=x $0} !NF{print substr(x,85); x=""} END{print substr(x,85)}' file
504b030414000900080092ac8851e2f538a16d7003009472030008001c00666c61672e6a70675554090003d3e3cf5fe7
e3cf5f75780b000104e803000004e80300003bc17db7300bce531e99d23a1b834c7cbecdeffa54864d241958c5a9b14d
dd564c0011bf42222a528675010ae29090f52becd067745a177005b6273521cf98fba25e82a856f905053d3e803f6823
That second script was run against the block of 3 records under "But for multiple different ones of the same format:" at the end of your question but you didn't provide the expected output for it so idk if that's the expected output or not:
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 10 b4 00 00 00 00 50 4b 03 04 14 00 c.........PK....
0030 09 00 08 00 92 ac 88 51 e2 f5 38 a1 6d 70 03 00 .......Q..8.mp..
0040 94 72 03 00 08 00 1c 00 66 6c 61 67 2e 6a 70 67 .r......flag.jpg
0050 55 54 09 00 03 d3 e3 cf 5f e7 UT......_.
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 5b 50 00 00 00 00 e3 cf 5f 75 78 0b c...[P......_ux.
0030 00 01 04 e8 03 00 00 04 e8 03 00 00 3b c1 7d b7 ............;.}.
0040 30 0b ce 53 1e 99 d2 3a 1b 83 4c 7c be cd ef fa 0..S...:..L|....
0050 54 86 4d 24 19 58 c5 a9 b1 4d T.M$.X...M
0000 ca fe 00 00 ba be de ad 00 00 be ef 08 00 45 00 ..............E.
0010 00 4c 00 01 00 00 40 01 9b 48 c0 a8 01 c8 b9 f5 .L....#..H......
0020 63 02 08 00 3e f4 00 00 00 00 dd 56 4c 00 11 bf c...>......VL...
0030 42 22 2a 52 86 75 01 0a e2 90 90 f5 2b ec d0 67 B"*R.u......+..g
0040 74 5a 17 70 05 b6 27 35 21 cf 98 fb a2 5e 82 a8 tZ.p..'5!....^..
0050 56 f9 05 05 3d 3e 80 3f 68 23 V...=>.?h#
I like to modify config files directly (like .gitignore and .git/config) instead of remembering arbitrary commands, but I don't know where Git stores the file references that get passed to "git update-index --assume-unchanged file".
If you know, please do tell!
It says where in the command - git update-index
So you can't really be editing the index as it is not a text file.
Also, to give more detail on what is stored with the git update-index --assume-unchanged command, see the Using “assume unchanged” bit section in the manual
As others said, it's stored in the index, which is located at .git/index.
After some detective work, I found that it is located at the: assume valid bit of each index entry.
Therefore, before understanding what follows, you should first understand the global format of the index, as explained in my other answer.
Next, I will explain how I verified that the "assume valid" bit is the culprit:
empirically
by reading the source
Empirical
Time to hd it up.
Setup:
git init
echo a > b
git add b
Then:
hd .git/index
Gives:
00000000 44 49 52 43 00 00 00 02 00 00 00 01 54 e9 b6 f3 |DIRC........T...|
00000010 2d 4f e1 2f 54 e9 b6 f3 2d 4f e1 2f 00 00 08 05 |-O./T...-O./....|
00000020 00 de 32 ff 00 00 81 a4 00 00 03 e8 00 00 03 e8 |..2.............|
00000030 00 00 00 00 e6 9d e2 9b b2 d1 d6 43 4b 8b 29 ae |...........CK.).|
00000040 77 5a d8 c2 e4 8c 53 91 00 01 62 00 c9 a2 4b c1 |wZ....S...b...K.|
00000050 23 00 1e 32 53 3c 51 5d d5 cb 1a b4 43 18 ad 8c |#..2S<Q]....C...|
00000060
Now:
git update-index --assume-unchanged b
hd .git/index
Gives:
00000000 44 49 52 43 00 00 00 02 00 00 00 01 54 e9 b6 f3 |DIRC........T...|
00000010 2d 4f e1 2f 54 e9 b6 f3 2d 4f e1 2f 00 00 08 05 |-O./T...-O./....|
00000020 00 de 32 ff 00 00 81 a4 00 00 03 e8 00 00 03 e8 |..2.............|
00000030 00 00 00 00 e6 9d e2 9b b2 d1 d6 43 4b 8b 29 ae |...........CK.).|
00000040 77 5a d8 c2 e4 8c 53 91 80 01 62 00 17 08 a8 58 |wZ....S...b....X|
00000050 f7 c5 b3 e1 7d 47 ac a2 88 d9 66 c7 5c 2f 74 d7 |....}G....f.\/t.|
00000060
By comparing the two indexes, and looking at the global structure of the index, see that the only differences are:
byte number 0x48 (9th on line 40) changed from 00 to 80. That is our flag, the first bit of the cache entry flags.
the 20 bytes from 0x4C to 0x5F. This is expected since that is a SHA-1 over the entire index.
This has also though me that the SHA-1 of the index entry in bytes from 0x34 to 0x47 does not take into account the flags, since it did not changed between both indexes. This is probably why the flags are placed after the SHA, which only considers what comes before it.
Source code
Now let's see if that is coherent with source code of Git 2.3.
First look at the source of update-index, grep assume-unchanged.
This leads to the following line:
{OPTION_SET_INT, 0, "assume-unchanged", &mark_valid_only, NULL,
N_("mark files as \"not changing\""),
PARSE_OPT_NOARG | PARSE_OPT_NONEG, NULL, MARK_FLAG},
{OPTION_SET_INT, 0, "no-assume-unchanged", &mark_valid_only, NULL,
N_("clear assumed-unchanged bit"),
PARSE_OPT_NOARG | PARSE_OPT_NONEG, NULL, UNMARK_FLAG},
so the value is stored at mark_valid_only. Grep it, and find that it is only used at one place:
if (mark_valid_only) {
if (mark_ce_flags(path, CE_VALID, mark_valid_only == MARK_FLAG))
die("Unable to mark file %s", path);
return;
}
CE means Cache Entry.
By quickly inspecting mark_ce_flags, we see that:
if (mark)
active_cache[pos]->ce_flags |= flag;
else
active_cache[pos]->ce_flags &= ~flag;
So the function basically sets or unsets the CE_VALID bit, depending on mark_valid_only, which is a tri-state:
mark: --assume-unchanged
unmark: --no-assume-unchanged
do nothing: the default value 0 of the option set at {OPTION_SET_INT, 0
Next, by grepping under builtin/, we see that no other place sets the value of CE_VALID, so --assume-unchanged must be the only command that sets it.
The flag is however used in many places of the source code, which should be expected as it has many side-effects, and it is used every time like:
ce->ce_flags & CE_VALID
so we conclude that it is part of the ce_flags field of struct cache_entry.
The index is specified at cache.h because one of its functions is to be a cache for creating commits faster.
By looking at the definition of CE_VALID under cache.h and surrounding lines we have:
#define CE_STAGEMASK (0x3000)
#define CE_EXTENDED (0x4000)
#define CE_VALID (0x8000)
#define CE_STAGESHIFT 12
So we conclude that it is the very first bit of that integer (0x8000), just next to the CE_EXTENDED, which is coherent with my earlier experiment.
I'm trying to create a minimal C example on a boot sector for educational purposes.
However, I noticed that my example was not being recognized as a boot sector because he magic 0x55aa bytes were not present as the 511th and 512th bytes.
Then, I investigated further, and it seems that this is because the .eh_frame section was getting included in the image, even though it was never mentioned in the linker script.
Why is that?
The exact setup is present here and reproduced below
build.sh:
as -ggdb3 -o entry.o entry.S
gcc -c -ggdb3 -nostartfiles -nostdlib -o main.o main.c
ld -o main.elf -T linker.ld entry.o main.o
ld --oformat binary -o main.img -T linker.ld entry.o main.o
qemu-system-x86_64 -hda main.img
linker.ld
ENTRY(mystart)
SECTIONS
{
.text : {
entry.o(.text)
*(.text)
*(.rodata)
*(.data)
/**(.eh_frame)*/
. = 0x1FE;
SHORT(0xAA55)
}
/* Reserve 16 MiB of stack. */
__stack_bottom = .;
. = . + 0x1000000;
__stack_top = .;
}
entry.S:
.text
.global mystart
mystart:
mov %rsp, __stack_top
call main
jmp .
main.c:
void main(void) {
while (1);
}
If I uncomment the .eh_frame frame above, then it gets included at the specified location, and things work, although it is not ideal and I would rather ignore that section completely.
But why does it try to include the .eh_frame in the final image if I never mention it?
I found out about .eh_frame by doing:
hd main.img
which gives:
00000000 14 00 00 00 00 00 00 00 01 7a 52 00 01 78 10 01 |.........zR..x..|
00000010 1b 0c 07 08 90 01 00 00 1c 00 00 00 1c 00 00 00 |................|
00000020 27 00 00 00 06 00 00 00 00 41 0e 10 86 02 43 0d |'........A....C.|
00000030 06 00 00 00 00 00 00 00 48 89 24 25 38 02 00 01 |........H.$%8...|
00000040 e8 02 00 00 00 eb fe 55 48 89 e5 eb fe 66 2e 0f |.......UH....f..|
00000050 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
00000060 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000070 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000080 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000090 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
000000a0 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
000000b0 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
000000c0 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
000000d0 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
000000e0 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
000000f0 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
00000100 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000110 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000120 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000130 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
00000140 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
00000150 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000160 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000170 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000180 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
00000190 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
000001a0 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
000001b0 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
000001c0 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
000001d0 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f |...f.........f..|
000001e0 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 |.......f........|
000001f0 00 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 |.f.........f....|
00000200 00 00 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 |.....f.........f|
00000210 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84 00 00 |.........f......|
00000220 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 0f 1f |...f.........f..|
00000230 84 00 00 00 00 00 55 aa |......U.|
00000238
and then:
objdump -D main.o
which contains:
Disassembly of section .eh_frame:
0000000000000000 <.eh_frame>:
0: 14 00 adc $0x0,%al
2: 00 00 add %al,(%rax)
4: 00 00 add %al,(%rax)
6: 00 00 add %al,(%rax)
8: 01 7a 52 add %edi,0x52(%rdx)
b: 00 01 add %al,(%rcx)
d: 78 10 js 1f <.eh_frame+0x1f>
f: 01 1b add %ebx,(%rbx)
11: 0c 07 or $0x7,%al
13: 08 90 01 00 00 1c or %dl,0x1c000001(%rax)
19: 00 00 add %al,(%rax)
1b: 00 1c 00 add %bl,(%rax,%rax,1)
1e: 00 00 add %al,(%rax)
20: 00 00 add %al,(%rax)
22: 00 00 add %al,(%rax)
24: 06 (bad)
25: 00 00 add %al,(%rax)
27: 00 00 add %al,(%rax)
29: 41 0e rex.B (bad)
2b: 10 86 02 43 0d 06 adc %al,0x60d4302(%rsi)
31: 00 00 add %al,(%rax)
33: 00 00 add %al,(%rax)
35: 00 00 add %al,(%rax)
...
so we can see that in the hd main.img, the first bytes are exactly the same as those in .eh_frame, and the image size is 512 + sizeof(.eh_frame) instead of the expected 512.
Tested on Ubuntu 18.04, GCC 7.3.0, binutils 2.30.
I'm doing some Office automation with MS Word from a C# application, and I'm finding that Word sometimes hangs. I can't reproduce the hang in a developer environment, so I'm hoping I can diagnose exactly why Word is hanging by taking a core dump and then analyzing it using WinDbg.
If I run kb, I get this stack trace (I've left off everything after the warning as it's probably irrelevant):
ChildEBP RetAddr Args to Child
003bc94c 762ed846 00037b72 00000008 00000000 user32!NtUserWaitMessage+0x15
003bc988 762eda5c 00047b12 00037b72 00000008 user32!DialogBox2+0x222
003bc9b4 762ed98a 59870000 0089aa30 00037b72 user32!InternalDialogBox+0xe5
003bc9d4 762ed70e 59870000 0089aa30 00037b72 user32!DialogBoxIndirectParamAorW+0x37
003bc9f4 59acdf5e 59870000 0089aa30 00037b72 user32!DialogBoxIndirectParamW+0x1b
WARNING: Stack unwind information not available. Following frames may be wrong.
So this seems to indicate that Word is hanging because it's showing a dialog box. How can I get the contents of that dialog box?
If I look at the memory at address 0089aa30, I see this:
........................3....
.M.i.c.r.o.s.o.f.t. .W.o.r.d.
........T.a.h.o.m.a..........
....P#.!.*...........O.K.....
...........PW.!.*...........&
.H.e.l.p..................P..
.............................
....P+...r.......M.S.O.U.N.I.
S.T.A.T...W.o.r.d. .c.a.n.n.o
.t. .o.p.e.n. .t.h.e. .e.x.i.
s.t.i.n.g. .f.i.l.e..... .(.N
.o.r.m.a.l.)................#
..+.........M.S.O.U.N.I.S.T.A
.T...2.0.0.5.2.1.............
So to me this says that the message in the dialog is "Word cannot open the existing file (Normal)".
Am I on the right track? Am I looking at the right bit of memory?
Is there any way to get the exact memory address of the message? (I feel like I'm guessing a bit, because the above message just happens to be close by in memory to a parameter to DialogBoxIndirectParam.) I have looked at the MSDN docs for DialogBoxIndirectParam, hoping to figure out exactly where in memory I should expect to see the dialog's message, but didn't get very far.
Edit: After seeing blabb's (absolutely incredible) answer, I have attempted to perform the same steps in WinDbg for my MS Word core dump. Here's the output:
0:000> ub 762ed98a
user32!DialogBoxIndirectParamAorW+0x1f:
762ed972 83c801 or eax,1
762ed975 50 push eax
762ed976 ff7518 push dword ptr [ebp+18h]
762ed979 ff7514 push dword ptr [ebp+14h]
762ed97c ff7510 push dword ptr [ebp+10h]
762ed97f ff750c push dword ptr [ebp+0Ch]
762ed982 ff7508 push dword ptr [ebp+8]
762ed985 e809000000 call user32!InternalDialogBox (762ed993)
0:000> .frame /r 2
02 003bc9b4 762ed98a user32!InternalDialogBox+0xe5
eax=00000000 ebx=00037b72 ecx=00000000 edx=00000000 esi=003bc97c edi=003bc918
eip=762eda5c esp=003bc990 ebp=003bc9b4 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
user32!InternalDialogBox+0xe5:
762eda5c 5f pop edi
0:000> dc /c 1 003bc990 l8
003bc990 00047b12 .{..
003bc994 00037b72 r{..
003bc998 00000008 ....
003bc99c 00000000 ....
003bc9a0 00000000 ....
003bc9a4 00037b72 r{..
003bc9a8 003bcb98 ..;.
003bc9ac 00000000 ....
I know I'm looking at the wrong bit of memory (i.e. the address I'm passing to dc is incorrect), but I don't know why. I used ".frame /r 2" to fetch the address of esp, what did I do wrong?
The InternalDialogBox Api Takes Six Arguments
C:\>cdb -c ".fnent user32!InternalDialogbox;q" cdb | grep Params
Params: 0n6 (0x18 bytes)
you can try deciphering this call by doing a backward disassembly on the return address on stack
0:000> kb 1
# ChildEBP RetAddr Args to Child
00 0017fad8 778be0d5 77860000 001ec4f0 00000000 USER32!InternalDialogBox
0:000> ub #$ra
USER32!SoftModalMessageBox+0x66d:
778be0b8 e87c48fdff call USER32!MessageBeep (77892939)
778be0bd 56 push esi
778be0be 53 push ebx
778be0bf 6848d68b77 push offset USER32!MB_DlgProc (778bd648)
778be0c4 ff75ac push dword ptr [ebp-54h]
778be0c7 ff75e4 push dword ptr [ebp-1Ch]
778be0ca ff35d0908c77 push dword ptr [USER32!hmodUser (778c90d0)]
778be0d0 e8a059fdff call USER32!InternalDialogBox (77893a75)
in a crash dump you can substitute address instead of register or you can
do .frame /r {frame number} to fetch the address of esp
0:000> dc /c 1 #esp l8
0017fadc 778be0d5 ...w
0017fae0 77860000 ...w
0017fae4 001ec4f0 ....
0017fae8 00000000 ....
0017faec 778bd648 H..w
0017faf0 0017fcd8 ....
0017faf4 00000000 ....
0017faf8 00000001 ....
1) The first argument is hModUser a global variable
2) The fourth argument is a DialogProc callback that is documented
3) 3rd and 6th argument are NULL
the second argument consits of an array of DLGTEMPLATE followed by DLGITEMTEMPLATE structure read the document for the format of this variable sized array
the fifth argument is MSGBOXPARAMS structure
a sample dump and deciphering the dump for the variable sized array as follows
0:000> db 1ec4f0 l f8
001ec4f0 c5 01 c8 80 00 00 00 00-02 00 1a 01 9b 00 a7 00 ................
001ec500 3e 00 00 00 00 00 54 00-68 00 69 00 73 00 20 00 >.....T.h.i.s. .
001ec510 69 00 73 00 20 00 4d 00-79 00 20 00 43 00 61 00 i.s. .M.y. .C.a.
001ec520 70 00 74 00 69 00 6f 00-6e 00 20 00 46 00 6f 00 p.t.i.o.n. .F.o.
001ec530 72 00 20 00 32 00 30 00-31 00 35 00 20 00 43 00 r. .2.0.1.5. .C.
001ec540 6f 00 6d 00 6d 00 75 00-6e 00 69 00 74 00 79 00 o.m.m.u.n.i.t.y.
001ec550 20 00 76 00 73 00 00 00-ff 7f 00 00 01 00 03 50 .v.s..........P
001ec560 00 00 00 00 71 00 2a 00-32 00 0e 00 01 00 ff ff ....q.*.2.......
001ec570 80 00 4f 00 4b 00 00 00-00 00 00 00 80 20 02 50 ..O.K........ .P
001ec580 00 00 00 00 07 00 0e 00-8c 00 09 00 ff ff ff ff ................
001ec590 82 00 54 00 68 00 69 00-73 00 20 00 69 00 73 00 ..T.h.i.s. .i.s.
001ec5a0 20 00 6d 00 79 00 20 00-66 00 69 00 72 00 73 00 .m.y. .f.i.r.s.
001ec5b0 74 00 20 00 54 00 65 00-73 00 74 00 20 00 77 00 t. .T.e.s.t. .w.
001ec5c0 69 00 74 00 68 00 20 00-32 00 30 00 31 00 35 00 i.t.h. .2.0.1.5.
001ec5d0 20 00 63 00 6f 00 6d 00-6d 00 75 00 6e 00 69 00 .c.o.m.m.u.n.i.
001ec5e0 74 00 79 00 00 00 00 00 t.y.....
0:000> dt ConsoleApplication1!DLGTEMPLATE 1ec4f0
+0x000 style : 0x80c801c5
+0x004 dwExtendedStyle : 0
+0x008 cdit : 2
+0x00a x : 0x11a
+0x00c y : 0x9b
+0x00e cx : 0xa7
+0x010 cy : 0x3e
0:000> du 1ec504
001ec504 ""
0:000> du 1ec506
001ec506 "This is My Caption For 2015 Comm"
001ec546 "unity vs"
0:000> dt ConsoleApplication1!DLGITEMTEMPLATE 1ec55c
+0x000 style : 0x50030001
+0x004 dwExtendedStyle : 0
+0x008 x : 0x71
+0x00a y : 0x2a
+0x00c cx : 0x32
+0x00e cy : 0xe
+0x010 id : 1
0:000> $$ 80 is a predfined button and the text is OK
0:000> dt ConsoleApplication1!DLGITEMTEMPLATE 1ec57c
+0x000 style : 0x50022080
+0x004 dwExtendedStyle : 0
+0x008 x : 7
+0x00a y : 0xe
+0x00c cx : 0x8c
+0x00e cy : 9
+0x010 id : 0xffff
0:000> $$ 82 is a predfined static text and the text is
0:000> du 1ec592
001ec592 "This is my first Test with 2015 "
001ec5d2 "community"
here is a MSGBOXPARAMSW dump
0:000> dt ConsoleApplication1!MSGBOXPARAMSW 0017fcd8
+0x000 cbSize : 0x28
+0x004 hwndOwner : (null)
+0x008 hInstance : (null)
+0x00c lpszText : 0x01172150 "This is my first Test with 2015 community"
+0x010 lpszCaption : 0x011720f8 "This is My Caption For 2015 Community vs"
+0x014 dwStyle : 0
+0x018 lpszIcon : (null)
+0x01c dwContextHelpId : 0
+0x020 lpfnMsgBoxCallback : (null)
+0x024 dwLanguageId : 0
EDIT
created a dump from taskmanager and loaded it
0:000> .shell -ci "version" grep DMP
Full memory user mini dump: C:\Users\HP\Desktop\cons.DMP
command line: 'windbg -z cons.DMP' Debugger Process 0x17CC
.shell: Process exited
just to be sure resetting the context record
0:000> .cxr
Resetting default scope
dumping stacktrace 9the frame of interest is not at top here)
0:000> kb 5
# ChildEBP RetAddr Args to Child
00 0028f6fc 778766c9 7789382a 00000000 00000000 ntdll!KiFastSystemCallRet
01 0028f700 7789382a 00000000 00000000 00000000 user32!NtUserWaitMessage+0xc
02 0028f734 77893b27 00aa0350 00000000 00000000 user32!DialogBox2+0x207
03 0028f758 778be0d5 77860000 002f63f0 00000000 user32!InternalDialogBox+0xcb
04 0028f7fc 778be659 00000000 69d52104 69d52108 user32!SoftModalMessageBox+0x68a
overriding local context for frame number of interest
0:000> .frame /c /r 04
04 0028f7fc 778be659 user32!SoftModalMessageBox+0x68a
eax=00000001 ebx=0028f958 ecx=0028f458 edx=77ad70f4 esi=005fab18 edi=00000001
eip=778be0d5 esp=0028f760 ebp=0028f7fc iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
user32!SoftModalMessageBox+0x68a:
778be0d5 8945e8 mov dword ptr [ebp-18h],eax ss:0023:0028f7e4=00000000
checking esp you can use esp as it is instead of groping for address
0:000> dc /c 1 #esp l 8
0028f760 77860000 ...w
0028f764 002f63f0 .c/.
0028f768 00000000 ....
0028f76c 778bd648 H..w
0028f770 0028f958 X.(.
0028f774 00000000 ....
0028f778 00000001 ....
0028f77c 0028f958 X.(.
dumping DLGTEMPLATE second arg
0:000> db 2f63f0 lf8
002f63f0 c5 01 c8 80 00 00 00 00-02 00 1a 01 9b 00 a7 00 ................
002f6400 3e 00 00 00 00 00 54 00-68 00 69 00 73 00 20 00 >.....T.h.i.s. .
002f6410 69 00 73 00 20 00 4d 00-79 00 20 00 43 00 61 00 i.s. .M.y. .C.a.
002f6420 70 00 74 00 69 00 6f 00-6e 00 20 00 46 00 6f 00 p.t.i.o.n. .F.o.
002f6430 72 00 20 00 32 00 30 00-31 00 35 00 20 00 43 00 r. .2.0.1.5. .C.
002f6440 6f 00 6d 00 6d 00 75 00-6e 00 69 00 74 00 79 00 o.m.m.u.n.i.t.y.
002f6450 20 00 76 00 73 00 00 00-ff 7f 00 00 01 00 03 50 .v.s..........P
002f6460 00 00 00 00 71 00 2a 00-32 00 0e 00 01 00 ff ff ....q.*.2.......
002f6470 80 00 4f 00 4b 00 00 00-00 00 00 00 80 20 02 50 ..O.K........ .P
002f6480 00 00 00 00 07 00 0e 00-8c 00 09 00 ff ff ff ff ................
002f6490 82 00 54 00 68 00 69 00-73 00 20 00 69 00 73 00 ..T.h.i.s. .i.s.
002f64a0 20 00 6d 00 79 00 20 00-66 00 69 00 72 00 73 00 .m.y. .f.i.r.s.
002f64b0 74 00 20 00 54 00 65 00-73 00 74 00 20 00 77 00 t. .T.e.s.t. .w.
002f64c0 69 00 74 00 68 00 20 00-32 00 30 00 31 00 35 00 i.t.h. .2.0.1.5.
002f64d0 20 00 63 00 6f 00 6d 00-6d 00 75 00 6e 00 69 00 .c.o.m.m.u.n.i.
002f64e0 74 00 79 00 00 00 00 00 t.y.....
typeinfo (you need proper private pdb or hack load a binary which you compiled into address space or add the DLGTEMPLATE struct into the official pdb for user32 from ms ( i thought i had a post explaining this in se but i cant seem to find) ill link it later if i find it or sitesearch google for how to add typeinfo to pdb in site:woodmann.com
0:000> dt cons!DLGTEMPLATE poi(#esp+4)
+0x000 style : 0x80c801c5
+0x004 dwExtendedStyle : 0
+0x008 cdit : 2
+0x00a x : 0n282
+0x00c y : 0n155
+0x00e cx : 0n167
+0x010 cy : 0n62
0:000> du poi(#esp+4)+16
002f6406 "This is My Caption For 2015 Comm"
002f6446 "unity vs"
edit 2 this is for a live session in dump mode you need to modify a pdb as you cant use execution commands
we are in a live dbg session we can use step commands which arent available in dmp mode
0:000> .tlist -c -v
0n3324 Msgbox.exe
Session: 1 User: HP-PC\HP Command Line: Msgbox.exe
lets search for some typeinfo we need
0:000> dt *!*DLGTEMPLATE*
0:000> $$ no the thype info is not available
0:000> $$ we know ole32.dll has it
0:000> $$ so lets hack load it
allocate some memory
0:000> .dvalloc 1000
Allocated 1000 bytes starting at 00020000
save the current eip
0:000> ? #eip
Evaluate expression: 2008221094 = 77b305a6
embed the modulename string at some address in the allocated memory
0:000> ea 20100 "ole32.dll"
0:000> db 20100 l20
00020100 6f 6c 65 33 32 2e 64 6c-6c 00 00 00 00 00 00 00 ole32.dll.......
00020110 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
Assemble a LoadLibraryA call inline
0:000> a 20000
00020000 push 20100
push 20100
00020005 call kernel32!LoadLibraryA
call kernel32!LoadLibraryA
0002000a
change eip to the detour address
0:000> r eip = 20000
single step to load a dll into the address space
0:000> p
eax=00000000 ebx=00000000 ecx=0026f80c edx=77ad70f4 esi=fffffffe edi=00000000
eip=00020005 esp=0026f824 ebp=0026f854 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
00020005 e852395877 call kernel32!LoadLibraryA (775a395c)
0:000> p
ModLoad: 77930000 77a8c000 C:\Windows\system32\ole32.dll
ModLoad: 75ee0000 75f81000 C:\Windows\system32\RPCRT4.dll
ModLoad: 77530000 7754f000 C:\Windows\system32\IMM32.DLL
ModLoad: 76030000 760fc000 C:\Windows\system32\MSCTF.dll
eax=77930000 ebx=00000000 ecx=77ae6570 edx=002b0174 esi=fffffffe edi=00000000
eip=0002000a esp=0026f828 ebp=0026f854 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
0002000a 0000 add byte ptr [eax],al ds:0023:77930000=4d
reset eip back
0:000> r eip = 77b305a6
we research the typeinfo and bingo we have it
0:000> dt *!*DLGTEMPLATE*
ole32!LPDLGTEMPLATEA
ole32!LPDLGTEMPLATE
ole32!LPDLGTEMPLATEW
ole32!LPCDLGTEMPLATE
ole32!LPCDLGTEMPLATEA
ole32!LPCDLGTEMPLATEW
ole32!DLGTEMPLATE
ole32!DLGTEMPLATE
I need to disassemble an executable file made from C .
My lecturer said to use GDB (I need to use a linux platform , so I'm using Eclipse Indigo
under VMWARE virtual machine) but I don't like GDB .
What I have at the moment is only a .exe file . Can I use Eclipse to disassemble that file ?
I have 6 phases that I need to decipher , the program is known as "Defusing a Binary Bomb"
. So , in order to do that I need to disassemble that file , but I can't seem to find a way to do that in Eclipse ...
Can you please explain how do I do disassembly in Eclipse ?
Why not use objdump?
$ objdump -d print_jmp_buf
print_jmp_buf: file format elf64-x86-64
Disassembly of section .init:
00000000004003f8 <_init>:
4003f8: 48 83 ec 08 sub $0x8,%rsp
4003fc: e8 7b 00 00 00 callq 40047c <call_gmon_start>
<... snip ... >
0000000000400534 <main>:
400534: 55 push %rbp
400535: 53 push %rbx
400536: 48 81 ec d8 00 00 00 sub $0xd8,%rsp
40053d: 48 89 e7 mov %rsp,%rdi
400540: e8 fb fe ff ff callq 400440 <_setjmp#plt>
400545: ba 08 00 00 00 mov $0x8,%edx
40054a: be 40 00 00 00 mov $0x40,%esi
40054f: bf 7c 06 40 00 mov $0x40067c,%edi
400554: b8 00 00 00 00 mov $0x0,%eax
400559: e8 c2 fe ff ff callq 400420 <printf#plt>
40055e: 48 89 e3 mov %rsp,%rbx
400561: 48 8d 6c 24 40 lea 0x40(%rsp),%rbp
400566: 48 8b 33 mov (%rbx),%rsi
400569: bf 83 06 40 00 mov $0x400683,%edi
40056e: b8 00 00 00 00 mov $0x0,%eax
400573: e8 a8 fe ff ff callq 400420 <printf#plt>
400578: 48 83 c3 08 add $0x8,%rbx
40057c: 48 39 eb cmp %rbp,%rbx
40057f: 75 e5 jne 400566 <main+0x32>
400581: b8 00 00 00 00 mov $0x0,%eax
400586: 48 81 c4 d8 00 00 00 add $0xd8,%rsp
40058d: 5b pop %rbx
40058e: 5d pop %rbp
40058f: c3 retq
<...snip...>