recursiveloop
asked on
Help with X86_64 Assembly commands
Hi, can someone tell me what exactly these commands are doing. These are inside a jump table. I have a few hunches, but GDB says all my hunches are wrong. The expected input is in the format
d c d, where I am assuming the first d is the case
I am giving you the case = 0;
4011a3: b8 66 00 00 00 mov $0x66,%eax
//copying asccii value of 0x66 = f to eax
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
//compare d value of 0x296 = 662 to the value contained in the address $rsp + 10
4011b0: 0f 84 e5 00 00 00 je 40129b
40129b: 3a 44 24 0f cmp 0xf(%rsp),%al
//no idea why there's this statement??? Is it trying to compare the value stored in $rsp + 15 with the lower byte of the low word in the eax register?
Let me know if you have questions. I can tell you what GDB is telling me, none of which makes sense!! Please help!
Disclosure: This is from the infamous Binary Bomb Lab Phase 3
d c d, where I am assuming the first d is the case
I am giving you the case = 0;
4011a3: b8 66 00 00 00 mov $0x66,%eax
//copying asccii value of 0x66 = f to eax
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
//compare d value of 0x296 = 662 to the value contained in the address $rsp + 10
4011b0: 0f 84 e5 00 00 00 je 40129b
40129b: 3a 44 24 0f cmp 0xf(%rsp),%al
//no idea why there's this statement??? Is it trying to compare the value stored in $rsp + 15 with the lower byte of the low word in the eax register?
Let me know if you have questions. I can tell you what GDB is telling me, none of which makes sense!! Please help!
Disclosure: This is from the infamous Binary Bomb Lab Phase 3
ASKER
>>You meant the address %rsp + 0x10 = %rsp + 16 I assume ?
Oh yeah, sorry mistyped it.
So I think I am doing everything right. Here's the entire relevant part of the quote for you to refer:
401161: 48 83 ec 18 sub $0x18,%rsp
401165: 48 8d 4c 24 0f lea 0xf(%rsp),%rcx
40116a: 48 8d 54 24 14 lea 0x14(%rsp),%rdx
40116f: 4c 8d 44 24 10 lea 0x10(%rsp),%r8
401174: be 3b 1c 40 00 mov $0x401c3b,%esi
401179: b8 00 00 00 00 mov $0x0,%eax
40117e: e8 2d fa ff ff callq 400bb0 <sscanf@plt>
401183: 83 f8 02 cmp $0x2,%eax
401186: 7f 05 jg 40118d <phase_3+0x2c>
401188: e8 3e 04 00 00 callq 4015cb <explode_bomb>
40118d: 83 7c 24 14 07 cmpl $0x7,0x14(%rsp)
401192: 0f 87 f9 00 00 00 ja 401291 <phase_3+0x130>
401198: 8b 44 24 14 mov 0x14(%rsp),%eax
40119c: ff 24 c5 50 1c 40 00 jmpq *0x401c50(,%rax,8)
4011a3: b8 66 00 00 00 mov $0x66,%eax
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
4011af: 00
4011b0: 0f 84 e5 00 00 00 je 40129b <phase_3+0x13a>
4011b6: e8 10 04 00 00 callq 4015cb <explode_bomb>
.
.
.
.
.//various other cases
.
..
401296: b8 61 00 00 00 mov $0x61,%eax
40129b: 3a 44 24 0f cmp 0xf(%rsp),%al
40129f: 74 05 je 4012a6 <phase_3+0x145>
4012a1: e8 25 03 00 00 callq 4015cb <explode_bomb>
4012a6: 48 83 c4 18 add $0x18,%rsp
4012aa: c3 retq
4012ab: 90 nop
So I am inputting the following: 0 f 662
But it seems for the following line
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
I am getting this:
print *(int *) ($rsp+16)
$2 = 66
Playing arounds I get
99 for 996 etc...
So it's only comparing the first two digits while I want it to compare it with 662..all the three digits. Do you know why it's doing that? I don't think my order of input is wrong. It is as
x /s 0x401c3b
0x401c3b <__dso_handle+419>: "%d %c %d"
Please help!
Oh yeah, sorry mistyped it.
So I think I am doing everything right. Here's the entire relevant part of the quote for you to refer:
401161: 48 83 ec 18 sub $0x18,%rsp
401165: 48 8d 4c 24 0f lea 0xf(%rsp),%rcx
40116a: 48 8d 54 24 14 lea 0x14(%rsp),%rdx
40116f: 4c 8d 44 24 10 lea 0x10(%rsp),%r8
401174: be 3b 1c 40 00 mov $0x401c3b,%esi
401179: b8 00 00 00 00 mov $0x0,%eax
40117e: e8 2d fa ff ff callq 400bb0 <sscanf@plt>
401183: 83 f8 02 cmp $0x2,%eax
401186: 7f 05 jg 40118d <phase_3+0x2c>
401188: e8 3e 04 00 00 callq 4015cb <explode_bomb>
40118d: 83 7c 24 14 07 cmpl $0x7,0x14(%rsp)
401192: 0f 87 f9 00 00 00 ja 401291 <phase_3+0x130>
401198: 8b 44 24 14 mov 0x14(%rsp),%eax
40119c: ff 24 c5 50 1c 40 00 jmpq *0x401c50(,%rax,8)
4011a3: b8 66 00 00 00 mov $0x66,%eax
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
4011af: 00
4011b0: 0f 84 e5 00 00 00 je 40129b <phase_3+0x13a>
4011b6: e8 10 04 00 00 callq 4015cb <explode_bomb>
.
.
.
.
.//various other cases
.
..
401296: b8 61 00 00 00 mov $0x61,%eax
40129b: 3a 44 24 0f cmp 0xf(%rsp),%al
40129f: 74 05 je 4012a6 <phase_3+0x145>
4012a1: e8 25 03 00 00 callq 4015cb <explode_bomb>
4012a6: 48 83 c4 18 add $0x18,%rsp
4012aa: c3 retq
4012ab: 90 nop
So I am inputting the following: 0 f 662
But it seems for the following line
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
I am getting this:
print *(int *) ($rsp+16)
$2 = 66
Playing arounds I get
99 for 996 etc...
So it's only comparing the first two digits while I want it to compare it with 662..all the three digits. Do you know why it's doing that? I don't think my order of input is wrong. It is as
x /s 0x401c3b
0x401c3b <__dso_handle+419>: "%d %c %d"
Please help!
ASKER
I think I have another possible hunch which has also led me to discover how little I know about addressing and byte ordering! even though I understand what this is doing
40129b: 3a 44 24 0f cmp 0xf(%rsp),%al
//no idea why there's this statement??? Is it trying to compare the value stored in $rsp + 15 with the lower byte of the low word in the eax register?
I am confused about what lower order essentially means! Please help.
I am feeing the data 0 f 662
But I should feed something else instead of f, please help!!
40129b: 3a 44 24 0f cmp 0xf(%rsp),%al
//no idea why there's this statement??? Is it trying to compare the value stored in $rsp + 15 with the lower byte of the low word in the eax register?
I am confused about what lower order essentially means! Please help.
I am feeing the data 0 f 662
But I should feed something else instead of f, please help!!
>> I am confused about what lower order essentially means! Please help.
Lower order means the least significant byte.
If you have a value 0x12345678, then 0x78 is the least significant byte.
>> But I should feed something else instead of f, please help!!
Have a look at these lines first :
>> 40118d: 83 7c 24 14 07 cmpl $0x7,0x14(%rsp)
>> 401192: 0f 87 f9 00 00 00 ja 401291 <phase_3+0x130>
I don't know where that jump leads, but you should be able to determine whether you want that jump to be made or not :)
There's some information missing from the code you posted (you skipped quite a bit of the function, and you haven't posted any of the supporting functions), so I can't make a complete analysis of the code.
Lower order means the least significant byte.
If you have a value 0x12345678, then 0x78 is the least significant byte.
>> But I should feed something else instead of f, please help!!
Have a look at these lines first :
>> 40118d: 83 7c 24 14 07 cmpl $0x7,0x14(%rsp)
>> 401192: 0f 87 f9 00 00 00 ja 401291 <phase_3+0x130>
I don't know where that jump leads, but you should be able to determine whether you want that jump to be made or not :)
There's some information missing from the code you posted (you skipped quite a bit of the function, and you haven't posted any of the supporting functions), so I can't make a complete analysis of the code.
ASKER
>>Lower order means the least significant byte.
>>If you have a value 0x12345678, then 0x78 is the least significant byte.
What if the value is 0x76?
Have a look at these lines first :
>> 40118d: 83 7c 24 14 07 cmpl $0x7,0x14(%rsp)
>>I don't know where that jump leads, but you should be able to determine whether you want that jump >>to be made or not :)
This line just checks for the jump control cases upper bound, which is 7, if it is not it jumps to explode the bomb!
>>There's some information missing from the code you posted (you skipped quite a bit of the function, >>and you haven't posted any of the supporting functions), so I can't make a complete analysis of the
>>code.
Here's the entire code for you to look at. I appreciate the help. It's kinda becoming urgent now, because I need to get to the following phases as I have the assignment due tonight :(
0000000000401161 <phase_3>:
401161: 48 83 ec 18 sub $0x18,%rsp
401165: 48 8d 4c 24 0f lea 0xf(%rsp),%rcx
40116a: 48 8d 54 24 14 lea 0x14(%rsp),%rdx
40116f: 4c 8d 44 24 10 lea 0x10(%rsp),%r8
401174: be 3b 1c 40 00 mov $0x401c3b,%esi
401179: b8 00 00 00 00 mov $0x0,%eax
40117e: e8 2d fa ff ff callq 400bb0 <sscanf@plt>
401183: 83 f8 02 cmp $0x2,%eax
401186: 7f 05 jg 40118d <phase_3+0x2c>
401188: e8 3e 04 00 00 callq 4015cb <explode_bomb>
40118d: 83 7c 24 14 07 cmpl $0x7,0x14(%rsp)
401192: 0f 87 f9 00 00 00 ja 401291 <phase_3+0x130>
401198: 8b 44 24 14 mov 0x14(%rsp),%eax
40119c: ff 24 c5 50 1c 40 00 jmpq *0x401c50(,%rax,8)
4011a3: b8 66 00 00 00 mov $0x66,%eax
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
4011af: 00
4011b0: 0f 84 e5 00 00 00 je 40129b <phase_3+0x13a>
4011b6: e8 10 04 00 00 callq 4015cb <explode_bomb>
4011bb: b8 66 00 00 00 mov $0x66,%eax
4011c0: e9 d6 00 00 00 jmpq 40129b <phase_3+0x13a>
4011c5: b8 73 00 00 00 mov $0x73,%eax
4011ca: 81 7c 24 10 82 01 00 cmpl $0x182,0x10(%rsp)
4011d1: 00
4011d2: 0f 84 c3 00 00 00 je 40129b <phase_3+0x13a>
4011d8: e8 ee 03 00 00 callq 4015cb <explode_bomb>
4011dd: b8 73 00 00 00 mov $0x73,%eax
4011e2: e9 b4 00 00 00 jmpq 40129b <phase_3+0x13a>
4011e7: b8 76 00 00 00 mov $0x76,%eax
4011ec: 83 7c 24 10 3a cmpl $0x3a,0x10(%rsp)
4011f1: 0f 84 a4 00 00 00 je 40129b <phase_3+0x13a>
4011f7: e8 cf 03 00 00 callq 4015cb <explode_bomb>
4011fc: b8 76 00 00 00 mov $0x76,%eax
401201: e9 95 00 00 00 jmpq 40129b <phase_3+0x13a>
401206: b8 6d 00 00 00 mov $0x6d,%eax
40120b: 81 7c 24 10 db 01 00 cmpl $0x1db,0x10(%rsp)
401212: 00
401213: 0f 84 82 00 00 00 je 40129b <phase_3+0x13a>
401219: e8 ad 03 00 00 callq 4015cb <explode_bomb>
40121e: b8 6d 00 00 00 mov $0x6d,%eax
401223: eb 76 jmp 40129b <phase_3+0x13a>
401225: b8 6e 00 00 00 mov $0x6e,%eax
40122a: 81 7c 24 10 c0 02 00 cmpl $0x2c0,0x10(%rsp)
401231: 00
401232: 74 67 je 40129b <phase_3+0x13a>
401234: e8 92 03 00 00 callq 4015cb <explode_bomb>
401239: b8 6e 00 00 00 mov $0x6e,%eax
40123e: eb 5b jmp 40129b <phase_3+0x13a>
401240: b8 69 00 00 00 mov $0x69,%eax
401245: 81 7c 24 10 db 01 00 cmpl $0x1db,0x10(%rsp)
40124c: 00
40124d: 74 4c je 40129b <phase_3+0x13a>
40124f: e8 77 03 00 00 callq 4015cb <explode_bomb>
401254: b8 69 00 00 00 mov $0x69,%eax
401259: eb 40 jmp 40129b <phase_3+0x13a>
40125b: b8 68 00 00 00 mov $0x68,%eax
401260: 81 7c 24 10 39 03 00 cmpl $0x339,0x10(%rsp)
401267: 00
401268: 74 31 je 40129b <phase_3+0x13a>
40126a: e8 5c 03 00 00 callq 4015cb <explode_bomb>
40126f: b8 68 00 00 00 mov $0x68,%eax
401274: eb 25 jmp 40129b <phase_3+0x13a>
401276: b8 6c 00 00 00 mov $0x6c,%eax
40127b: 81 7c 24 10 0a 03 00 cmpl $0x30a,0x10(%rsp)
401282: 00
401283: 74 16 je 40129b <phase_3+0x13a>
401285: e8 41 03 00 00 callq 4015cb <explode_bomb>
40128a: b8 6c 00 00 00 mov $0x6c,%eax
40128f: eb 0a jmp 40129b <phase_3+0x13a>
401291: e8 35 03 00 00 callq 4015cb <explode_bomb>
401296: b8 61 00 00 00 mov $0x61,%eax
40129b: 3a 44 24 0f cmp 0xf(%rsp),%al
40129f: 74 05 je 4012a6 <phase_3+0x145>
4012a1: e8 25 03 00 00 callq 4015cb <explode_bomb>
4012a6: 48 83 c4 18 add $0x18,%rsp
4012aa: c3 retq
4012ab: 90 nop
>>If you have a value 0x12345678, then 0x78 is the least significant byte.
What if the value is 0x76?
Have a look at these lines first :
>> 40118d: 83 7c 24 14 07 cmpl $0x7,0x14(%rsp)
>>I don't know where that jump leads, but you should be able to determine whether you want that jump >>to be made or not :)
This line just checks for the jump control cases upper bound, which is 7, if it is not it jumps to explode the bomb!
>>There's some information missing from the code you posted (you skipped quite a bit of the function, >>and you haven't posted any of the supporting functions), so I can't make a complete analysis of the
>>code.
Here's the entire code for you to look at. I appreciate the help. It's kinda becoming urgent now, because I need to get to the following phases as I have the assignment due tonight :(
0000000000401161 <phase_3>:
401161: 48 83 ec 18 sub $0x18,%rsp
401165: 48 8d 4c 24 0f lea 0xf(%rsp),%rcx
40116a: 48 8d 54 24 14 lea 0x14(%rsp),%rdx
40116f: 4c 8d 44 24 10 lea 0x10(%rsp),%r8
401174: be 3b 1c 40 00 mov $0x401c3b,%esi
401179: b8 00 00 00 00 mov $0x0,%eax
40117e: e8 2d fa ff ff callq 400bb0 <sscanf@plt>
401183: 83 f8 02 cmp $0x2,%eax
401186: 7f 05 jg 40118d <phase_3+0x2c>
401188: e8 3e 04 00 00 callq 4015cb <explode_bomb>
40118d: 83 7c 24 14 07 cmpl $0x7,0x14(%rsp)
401192: 0f 87 f9 00 00 00 ja 401291 <phase_3+0x130>
401198: 8b 44 24 14 mov 0x14(%rsp),%eax
40119c: ff 24 c5 50 1c 40 00 jmpq *0x401c50(,%rax,8)
4011a3: b8 66 00 00 00 mov $0x66,%eax
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
4011af: 00
4011b0: 0f 84 e5 00 00 00 je 40129b <phase_3+0x13a>
4011b6: e8 10 04 00 00 callq 4015cb <explode_bomb>
4011bb: b8 66 00 00 00 mov $0x66,%eax
4011c0: e9 d6 00 00 00 jmpq 40129b <phase_3+0x13a>
4011c5: b8 73 00 00 00 mov $0x73,%eax
4011ca: 81 7c 24 10 82 01 00 cmpl $0x182,0x10(%rsp)
4011d1: 00
4011d2: 0f 84 c3 00 00 00 je 40129b <phase_3+0x13a>
4011d8: e8 ee 03 00 00 callq 4015cb <explode_bomb>
4011dd: b8 73 00 00 00 mov $0x73,%eax
4011e2: e9 b4 00 00 00 jmpq 40129b <phase_3+0x13a>
4011e7: b8 76 00 00 00 mov $0x76,%eax
4011ec: 83 7c 24 10 3a cmpl $0x3a,0x10(%rsp)
4011f1: 0f 84 a4 00 00 00 je 40129b <phase_3+0x13a>
4011f7: e8 cf 03 00 00 callq 4015cb <explode_bomb>
4011fc: b8 76 00 00 00 mov $0x76,%eax
401201: e9 95 00 00 00 jmpq 40129b <phase_3+0x13a>
401206: b8 6d 00 00 00 mov $0x6d,%eax
40120b: 81 7c 24 10 db 01 00 cmpl $0x1db,0x10(%rsp)
401212: 00
401213: 0f 84 82 00 00 00 je 40129b <phase_3+0x13a>
401219: e8 ad 03 00 00 callq 4015cb <explode_bomb>
40121e: b8 6d 00 00 00 mov $0x6d,%eax
401223: eb 76 jmp 40129b <phase_3+0x13a>
401225: b8 6e 00 00 00 mov $0x6e,%eax
40122a: 81 7c 24 10 c0 02 00 cmpl $0x2c0,0x10(%rsp)
401231: 00
401232: 74 67 je 40129b <phase_3+0x13a>
401234: e8 92 03 00 00 callq 4015cb <explode_bomb>
401239: b8 6e 00 00 00 mov $0x6e,%eax
40123e: eb 5b jmp 40129b <phase_3+0x13a>
401240: b8 69 00 00 00 mov $0x69,%eax
401245: 81 7c 24 10 db 01 00 cmpl $0x1db,0x10(%rsp)
40124c: 00
40124d: 74 4c je 40129b <phase_3+0x13a>
40124f: e8 77 03 00 00 callq 4015cb <explode_bomb>
401254: b8 69 00 00 00 mov $0x69,%eax
401259: eb 40 jmp 40129b <phase_3+0x13a>
40125b: b8 68 00 00 00 mov $0x68,%eax
401260: 81 7c 24 10 39 03 00 cmpl $0x339,0x10(%rsp)
401267: 00
401268: 74 31 je 40129b <phase_3+0x13a>
40126a: e8 5c 03 00 00 callq 4015cb <explode_bomb>
40126f: b8 68 00 00 00 mov $0x68,%eax
401274: eb 25 jmp 40129b <phase_3+0x13a>
401276: b8 6c 00 00 00 mov $0x6c,%eax
40127b: 81 7c 24 10 0a 03 00 cmpl $0x30a,0x10(%rsp)
401282: 00
401283: 74 16 je 40129b <phase_3+0x13a>
401285: e8 41 03 00 00 callq 4015cb <explode_bomb>
40128a: b8 6c 00 00 00 mov $0x6c,%eax
40128f: eb 0a jmp 40129b <phase_3+0x13a>
401291: e8 35 03 00 00 callq 4015cb <explode_bomb>
401296: b8 61 00 00 00 mov $0x61,%eax
40129b: 3a 44 24 0f cmp 0xf(%rsp),%al
40129f: 74 05 je 4012a6 <phase_3+0x145>
4012a1: e8 25 03 00 00 callq 4015cb <explode_bomb>
4012a6: 48 83 c4 18 add $0x18,%rsp
4012aa: c3 retq
4012ab: 90 nop
>> >>If you have a value 0x12345678, then 0x78 is the least significant byte.
>>
>> What if the value is 0x76?
The least significant byte of the value 0x76 is 0x76.
>> This line just checks for the jump control cases upper bound, which is 7, if it is not it jumps to explode the bomb!
The reason I didn't know where the jump went, is because you didn't include the code at the jump address 401291.
So, you want to avoid that jump, so 0x14(%rsp) has to be <= 7. Make sure that it is :)
>>
>> What if the value is 0x76?
The least significant byte of the value 0x76 is 0x76.
>> This line just checks for the jump control cases upper bound, which is 7, if it is not it jumps to explode the bomb!
The reason I didn't know where the jump went, is because you didn't include the code at the jump address 401291.
So, you want to avoid that jump, so 0x14(%rsp) has to be <= 7. Make sure that it is :)
>> It's kinda becoming urgent now, because I need to get to the following phases as I have the assignment due tonight :(
I'll be available for the next few hours.
I'll be available for the next few hours.
ASKER
Thanks. So here's the status:
I have the following input
0 f 662
So the case is 0, and these are the statements that should be executed:
4011a3: b8 66 00 00 00 mov $0x66,%eax
//it moves 0x66 to eax. Now because the input format expected is "%d %c %d"
//this should mean that the it expects a character with the ASCII value of
//0x66 which is "f". Before doing this comparison however it compares the 3rd input
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
4011af: 00
4011b0: 0f 84 e5 00 00 00 je 40129b <phase_3+0x13a>
everything works fine till
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
$0x296 is 662, so my 3rd input is 662. But the problem is
when I do
print *(int *) ($rsp+16)
I get 66!!
I have tried other values it always ignores the last digit, so for instance if I input 58
it gives me 5. Now obviously this will not equate!
Moving on, if this comparison succeeds it jumps to
40129b: 3a 44 24 0f cmp 0xf(%rsp),%al
Where it compares (what I think should be) the 2nd input (f = 0x66) to the lower
byte of %eax (which should be ) x66. But doing this
print *(int *) ($rsp+15)
gives me some weird value like 1398! I don't know if it will fix itself once the previous
comparison for the 2nd inpit works. I have no idea. Please help! I am in big trouble!
I have the following input
0 f 662
So the case is 0, and these are the statements that should be executed:
4011a3: b8 66 00 00 00 mov $0x66,%eax
//it moves 0x66 to eax. Now because the input format expected is "%d %c %d"
//this should mean that the it expects a character with the ASCII value of
//0x66 which is "f". Before doing this comparison however it compares the 3rd input
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
4011af: 00
4011b0: 0f 84 e5 00 00 00 je 40129b <phase_3+0x13a>
everything works fine till
4011a8: 81 7c 24 10 96 02 00 cmpl $0x296,0x10(%rsp)
$0x296 is 662, so my 3rd input is 662. But the problem is
when I do
print *(int *) ($rsp+16)
I get 66!!
I have tried other values it always ignores the last digit, so for instance if I input 58
it gives me 5. Now obviously this will not equate!
Moving on, if this comparison succeeds it jumps to
40129b: 3a 44 24 0f cmp 0xf(%rsp),%al
Where it compares (what I think should be) the 2nd input (f = 0x66) to the lower
byte of %eax (which should be ) x66. But doing this
print *(int *) ($rsp+15)
gives me some weird value like 1398! I don't know if it will fix itself once the previous
comparison for the 2nd inpit works. I have no idea. Please help! I am in big trouble!
Assuming that the code is generated in a logical way, this :
>> 401165: 48 8d 4c 24 0f lea 0xf(%rsp),%rcx
>> 40116a: 48 8d 54 24 14 lea 0x14(%rsp),%rdx
>> 40116f: 4c 8d 44 24 10 lea 0x10(%rsp),%r8
>> 401174: be 3b 1c 40 00 mov $0x401c3b,%esi
>> 401179: b8 00 00 00 00 mov $0x0,%eax
>> 40117e: e8 2d fa ff ff callq 400bb0 <sscanf@plt>
would indicate that 0x10(%rsp) will hold the first value from the string, 0x14(%rsp) the second, and 0xf(%rsp) the last.
It seems this might not be the case, since you're using them differently.
Can you verify immediately after the sscanf call, which of these three hold which values ?
>> 401165: 48 8d 4c 24 0f lea 0xf(%rsp),%rcx
>> 40116a: 48 8d 54 24 14 lea 0x14(%rsp),%rdx
>> 40116f: 4c 8d 44 24 10 lea 0x10(%rsp),%r8
>> 401174: be 3b 1c 40 00 mov $0x401c3b,%esi
>> 401179: b8 00 00 00 00 mov $0x0,%eax
>> 40117e: e8 2d fa ff ff callq 400bb0 <sscanf@plt>
would indicate that 0x10(%rsp) will hold the first value from the string, 0x14(%rsp) the second, and 0xf(%rsp) the last.
It seems this might not be the case, since you're using them differently.
Can you verify immediately after the sscanf call, which of these three hold which values ?
ASKER
So for the input 0 f 662, here's what I get
(gdb) print *(int *) ($rsp+20)
$2 = 0
(gdb) print *(int *) ($rsp+15)
$3 = 16998
(gdb) print *(int *) ($rsp+16)
$4 = 66
So 0x14(%rsp) holds the first value 0.
0xf(%rsp) is holding some random crazy number!!
0x10(%rsp) ignores the last digit of the 3rd input and holds the first two!
Any idea?
(gdb) print *(int *) ($rsp+20)
$2 = 0
(gdb) print *(int *) ($rsp+15)
$3 = 16998
(gdb) print *(int *) ($rsp+16)
$4 = 66
So 0x14(%rsp) holds the first value 0.
0xf(%rsp) is holding some random crazy number!!
0x10(%rsp) ignores the last digit of the 3rd input and holds the first two!
Any idea?
ASKER
Thanks for the quick response though. Truly appreciate it!
ASKER
>>(gdb) print *(int *) ($rsp+15)
>>$3 = 16998
>>0xf(%rsp) is holding some random crazy number!!
Sorry was using the wrong cast. I think it's working as expected:
(gdb) print *(char *) ($rsp+15)
$6 = 102 'f'
So the only problem is with input 3!
>>$3 = 16998
>>0xf(%rsp) is holding some random crazy number!!
Sorry was using the wrong cast. I think it's working as expected:
(gdb) print *(char *) ($rsp+15)
$6 = 102 'f'
So the only problem is with input 3!
ASKER
Done!!!!! All I did was inputed 6621 instead of 662! And it accepted it. Phase defused! Why didn't I think of it before????!!! I have spent 2 days on this!
Thanks for you r help though!
4 more phases to go. Can I be shameful enough, to ask for you help if I need ? :D
Thanks for you r help though!
4 more phases to go. Can I be shameful enough, to ask for you help if I need ? :D
ASKER
* I meant shameless ;)
>> Done!!!!! All I did was inputed 6621 instead of 662! And it accepted it.
Glad you did it :)
It's a bit weird though. Are you sure that right before the call to sscanf, the string actually contains "0 f 662" ? Or does it just contain "0 f 66" ?
In the former case, the sscanf call should work just fine.
In the latter case, something happened to the string before calling the phase_3 function.
Glad you did it :)
It's a bit weird though. Are you sure that right before the call to sscanf, the string actually contains "0 f 662" ? Or does it just contain "0 f 66" ?
In the former case, the sscanf call should work just fine.
In the latter case, something happened to the string before calling the phase_3 function.
>> Can I be shameful enough, to ask for you help if I need ? :D
No problem. Just ask a question in the assembly zone (I'm monitoring that for new questions), and I'll do my best to assist you.
No problem. Just ask a question in the assembly zone (I'm monitoring that for new questions), and I'll do my best to assist you.
ASKER
>>It's a bit weird though. Are you sure that right before the call to sscanf, the string actually contains "0 f >>662" ? Or does it just contain "0 f 66" ?
>>In the former case, the sscanf call should work just fine.
>>In the latter case, something happened to the string before calling the phase_3 function.
I know. This isn't really a very elegant problem/solution. I will come back and look at it after I am done with the rest. Will let you know what I figure out!
>>No problem. Just ask a question in the assembly zone (I'm monitoring that for new questions), and I'll do >>my best to assist you.
Thanks. Expect a couple of questions from me then ;)
>>In the former case, the sscanf call should work just fine.
>>In the latter case, something happened to the string before calling the phase_3 function.
I know. This isn't really a very elegant problem/solution. I will come back and look at it after I am done with the rest. Will let you know what I figure out!
>>No problem. Just ask a question in the assembly zone (I'm monitoring that for new questions), and I'll do >>my best to assist you.
Thanks. Expect a couple of questions from me then ;)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
na
ASKER
solved
You meant the address %rsp + 0x10 = %rsp + 16 I assume ?
Or, that's 16 bytes below the top of the stack.
>> //no idea why there's this statement??? Is it trying to compare the value stored in $rsp + 15 with the lower byte of the low word in the eax register?
Yes. It's comparing the byte at %rsp + 15 to the lowest byte in %rax.