Differences in disassembling 32 bit and 64bit
I started my adventure with reverse engineering but I have some problems which I can't solve from the very beginning. I'm following tutorials on YT and I meet some differences. So, when I work with this code from the tutorial:
#include <stdio.h>
#include <string.h>
int main(int argc, char** argv)
{
char buffer[500];
strcpy(buffer, argv[1]);
return 0;
}
I should get disassembly result as the guy from the tutorial:
But when I compile my program on a 32bit virtual machine withgcc -g -z execstack -fno-stack-protector and get result like this:
When I compile the same same cod on 64bit virtual machine with gcc -g -z execstack -fno-stack-protector -m32 I get the same result. However if I compile it with gcc -g -z execstack -fno-stack-protector I get something like this:
So it looks like the screenshot from the tutorial but it's 64bit version. So my question is, am I doing something wrong or I shoulg change something? I don't know if I should learn working with 64bit system or find a way to repair 32bit one. Anyone can help me?
c reverse-engineering disassembly
asked Nov 12 '18 at 18:36
ShirakumoShirakumo
324
|
show 4 more comments
I started my adventure with reverse engineering but I have some problems which I can't solve from the very beginning. I'm following tutorials on YT and I meet some differences. So, when I work with this code from the tutorial:
#include <stdio.h>
#include <string.h>
int main(int argc, char** argv)
{
char buffer[500];
strcpy(buffer, argv[1]);
return 0;
}
I should get disassembly result as the guy from the tutorial:
But when I compile my program on a 32bit virtual machine withgcc -g -z execstack -fno-stack-protector and get result like this:
When I compile the same same cod on 64bit virtual machine with gcc -g -z execstack -fno-stack-protector -m32 I get the same result. However if I compile it with gcc -g -z execstack -fno-stack-protector I get something like this:
So it looks like the screenshot from the tutorial but it's 64bit version. So my question is, am I doing something wrong or I shoulg change something? I don't know if I should learn working with 64bit system or find a way to repair 32bit one. Anyone can help me?
c reverse-engineering disassembly
asked Nov 12 '18 at 18:36
ShirakumoShirakumo
324
Try with-no-pie
– Havenard
Nov 12 '18 at 18:56
That call toget_pc_thunktells it's position independent code according to this answer, so it might be the case why it is different. Disabling this feature at the compiler with-no-piemight make them look more alike. Also, the optimizer works in mysterious ways, disabling it with-O0may also help you recognize your code once it gets transformed in assembly.
– Havenard
Nov 12 '18 at 19:00
But as you know my previous question, may it be the case why my payload doesn't work? Or it's just an appearance and has nothing to do with a shellcode and memory?
– Shirakumo
Nov 12 '18 at 19:03
As long aseip/ripoverwrite theretaddress of the function by the address of the shellcode or any of thex90before it, the shellcode should work.
– Havenard
Nov 12 '18 at 19:05
Theretaddress of the function, in any function implemented using__cdecl(default calling convention of the C language) is at the addressebp-4(32-bit) orrbp-8(64-bit).
– Havenard
Nov 12 '18 at 19:07
|
show 4 more comments
I started my adventure with reverse engineering but I have some problems which I can't solve from the very beginning. I'm following tutorials on YT and I meet some differences. So, when I work with this code from the tutorial:
#include <stdio.h>
#include <string.h>
int main(int argc, char** argv)
{
char buffer[500];
strcpy(buffer, argv[1]);
return 0;
}
I should get disassembly result as the guy from the tutorial:
But when I compile my program on a 32bit virtual machine withgcc -g -z execstack -fno-stack-protector and get result like this:
When I compile the same same cod on 64bit virtual machine with gcc -g -z execstack -fno-stack-protector -m32 I get the same result. However if I compile it with gcc -g -z execstack -fno-stack-protector I get something like this:
So it looks like the screenshot from the tutorial but it's 64bit version. So my question is, am I doing something wrong or I shoulg change something? I don't know if I should learn working with 64bit system or find a way to repair 32bit one. Anyone can help me?
c reverse-engineering disassembly
asked Nov 12 '18 at 18:36
ShirakumoShirakumo
324
I started my adventure with reverse engineering but I have some problems which I can't solve from the very beginning. I'm following tutorials on YT and I meet some differences. So, when I work with this code from the tutorial:
#include <stdio.h>
#include <string.h>
int main(int argc, char** argv)
{
char buffer[500];
strcpy(buffer, argv[1]);
return 0;
}
I should get disassembly result as the guy from the tutorial:
But when I compile my program on a 32bit virtual machine withgcc -g -z execstack -fno-stack-protector and get result like this:
When I compile the same same cod on 64bit virtual machine with gcc -g -z execstack -fno-stack-protector -m32 I get the same result. However if I compile it with gcc -g -z execstack -fno-stack-protector I get something like this:
So it looks like the screenshot from the tutorial but it's 64bit version. So my question is, am I doing something wrong or I shoulg change something? I don't know if I should learn working with 64bit system or find a way to repair 32bit one. Anyone can help me?
c reverse-engineering disassembly
c reverse-engineering disassembly
asked Nov 12 '18 at 18:36
ShirakumoShirakumo
324
asked Nov 12 '18 at 18:36
ShirakumoShirakumo
324
asked Nov 12 '18 at 18:36
ShirakumoShirakumo
324
asked Nov 12 '18 at 18:36
ShirakumoShirakumo
324
asked Nov 12 '18 at 18:36
ShirakumoShirakumo
324
324
Try with-no-pie
– Havenard
Nov 12 '18 at 18:56
That call toget_pc_thunktells it's position independent code according to this answer, so it might be the case why it is different. Disabling this feature at the compiler with-no-piemight make them look more alike. Also, the optimizer works in mysterious ways, disabling it with-O0may also help you recognize your code once it gets transformed in assembly.
– Havenard
Nov 12 '18 at 19:00
But as you know my previous question, may it be the case why my payload doesn't work? Or it's just an appearance and has nothing to do with a shellcode and memory?
– Shirakumo
Nov 12 '18 at 19:03
As long aseip/ripoverwrite theretaddress of the function by the address of the shellcode or any of thex90before it, the shellcode should work.
– Havenard
Nov 12 '18 at 19:05
Theretaddress of the function, in any function implemented using__cdecl(default calling convention of the C language) is at the addressebp-4(32-bit) orrbp-8(64-bit).
– Havenard
Nov 12 '18 at 19:07
|
show 4 more comments
Try with-no-pie
– Havenard
Nov 12 '18 at 18:56
That call toget_pc_thunktells it's position independent code according to this answer, so it might be the case why it is different. Disabling this feature at the compiler with-no-piemight make them look more alike. Also, the optimizer works in mysterious ways, disabling it with-O0may also help you recognize your code once it gets transformed in assembly.
– Havenard
Nov 12 '18 at 19:00
But as you know my previous question, may it be the case why my payload doesn't work? Or it's just an appearance and has nothing to do with a shellcode and memory?
– Shirakumo
Nov 12 '18 at 19:03
As long aseip/ripoverwrite theretaddress of the function by the address of the shellcode or any of thex90before it, the shellcode should work.
– Havenard
Nov 12 '18 at 19:05
Theretaddress of the function, in any function implemented using__cdecl(default calling convention of the C language) is at the addressebp-4(32-bit) orrbp-8(64-bit).
– Havenard
Nov 12 '18 at 19:07
Try with
-no-pie– Havenard
Nov 12 '18 at 18:56
Try with
-no-pie– Havenard
Nov 12 '18 at 18:56
That call to
get_pc_thunk tells it's position independent code according to this answer, so it might be the case why it is different. Disabling this feature at the compiler with -no-pie might make them look more alike. Also, the optimizer works in mysterious ways, disabling it with -O0 may also help you recognize your code once it gets transformed in assembly.– Havenard
Nov 12 '18 at 19:00
That call to
get_pc_thunk tells it's position independent code according to this answer, so it might be the case why it is different. Disabling this feature at the compiler with -no-pie might make them look more alike. Also, the optimizer works in mysterious ways, disabling it with -O0 may also help you recognize your code once it gets transformed in assembly.– Havenard
Nov 12 '18 at 19:00
But as you know my previous question, may it be the case why my payload doesn't work? Or it's just an appearance and has nothing to do with a shellcode and memory?
– Shirakumo
Nov 12 '18 at 19:03
But as you know my previous question, may it be the case why my payload doesn't work? Or it's just an appearance and has nothing to do with a shellcode and memory?
– Shirakumo
Nov 12 '18 at 19:03
As long as
eip/rip overwrite the ret address of the function by the address of the shellcode or any of the x90 before it, the shellcode should work.– Havenard
Nov 12 '18 at 19:05
As long as
eip/rip overwrite the ret address of the function by the address of the shellcode or any of the x90 before it, the shellcode should work.– Havenard
Nov 12 '18 at 19:05
The
ret address of the function, in any function implemented using __cdecl (default calling convention of the C language) is at the address ebp-4 (32-bit) or rbp-8 (64-bit).– Havenard
Nov 12 '18 at 19:07
The
ret address of the function, in any function implemented using __cdecl (default calling convention of the C language) is at the address ebp-4 (32-bit) or rbp-8 (64-bit).– Havenard
Nov 12 '18 at 19:07
|
show 4 more comments
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53268159%2fdifferences-in-disassembling-32-bit-and-64bit%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53268159%2fdifferences-in-disassembling-32-bit-and-64bit%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Try with
-no-pie– Havenard
Nov 12 '18 at 18:56
That call to
get_pc_thunktells it's position independent code according to this answer, so it might be the case why it is different. Disabling this feature at the compiler with-no-piemight make them look more alike. Also, the optimizer works in mysterious ways, disabling it with-O0may also help you recognize your code once it gets transformed in assembly.– Havenard
Nov 12 '18 at 19:00
But as you know my previous question, may it be the case why my payload doesn't work? Or it's just an appearance and has nothing to do with a shellcode and memory?
– Shirakumo
Nov 12 '18 at 19:03
As long as
eip/ripoverwrite theretaddress of the function by the address of the shellcode or any of thex90before it, the shellcode should work.– Havenard
Nov 12 '18 at 19:05
The
retaddress of the function, in any function implemented using__cdecl(default calling convention of the C language) is at the addressebp-4(32-bit) orrbp-8(64-bit).– Havenard
Nov 12 '18 at 19:07