4 ms·

There's no magic anywhere and 99.1% of it is documented. IA-32e/AMD64 is basically an extension of IA-32/x86. What you're looking for is to understand the diff

There's no magic anywhere and 99.1% of it is documented. IA-32e/AMD64 is basically an extension of IA-32/x86. What you're looking for is to understand the difference between real mode, 386 protected mode, PAE, paging and long mode because the registers, instructions, addressing and sizes of structures differ. You can learn all of this by reading the Intel software manuals and digging into it yourself. Tools you need (for non-Windows): - gdb/lldb - assemblers: yasm, nasm, binutils (contains "as") Optional tools: - IDA Pro - Virtualization/emulation such as VMware Fusion/Workstation (because it supports being a gdbserver), VirtualBox or QEMU - Intel's CPUID app You also need good references like: - the Intel manual set (a giant PDF or a collection of several) https://software.intel.com/en-us/articles/intel-sdm https://software.intel.com/en-us/articles/intel-sdm - https://sandpile.org https://sandpile.org (fairly current) - https://ref.x86asm.net https://ref.x86asm.net (outdated by useful) Another helpful exercise is writing a toy operating system in Rust or only assembly. https://osdev.org https://osdev.org has many resources and guides.

Godel_unicode 7y ago
In addition to IDA, I highly recommend looking into ghidra. It's open source, so you can peak under the hood and see how it does things. https://github.com/NationalSecurityAgency/ghidra https://github.com/NationalSecurityAgency/ghidra
- anonsivalley652 7y ago
  Yep. It's a FOSS-quality disassembler; good if you don't have IDA (I wish), supports maybe 10% of what IDA does in total but has some other niceities that it doesn't (think: disassembler-equivalent of LLVM). (Ideally, you'd have both.) For those who don't know, IDA disassembles basically every unclassified, commercially-available architecture and executable/library/object container format (think: disassembler-equivalent of GCC if it were an IBM or Green Hills product -:P). It also has a built-in scripting API in Python(?), IIRC. An interesting semi-abandonware static disassembler that was really good is Sourcer 8.01 from V-Communications. I think it supports Pentium II/Pro/III at most, which would include real, protected mode and long mode DOS/DOS extended/Win16/Win32 EXEs and COMs IIRC. It did a lot of memory typing and clever analysis long before IDA existed, and still interesting for retro computing. https://www.vetusware.com/download/Sourcer%208.01%208.01/?id=8677 https://www.vetusware.com/download/Sourcer%208.01%208.01/?id...
  - Godel_unicode 7y ago
    You might be interested in this talk from the creator of IDA, Ilfak Guilfanov, explaining how he used Sourcer and it's shortcomings lead directly to him creating IDA. https://m.youtube.com/watch?v=hLBlck1lTUs https://m.youtube.com/watch?v=hLBlck1lTUs
- zelly 7y ago
  It's way better than IDA Pro. I have used the Pro version with the Hex-Rays decompiler. Ghidra is legitimately better. I wouldn't recommend IDA to anyone at this point because I don't see it having much of a future (sorry not sorry). It's worth learning the Ghidra Scripting API because you can write ad-hoc scripts with Jython syntax to automate tasks/do custom analysis.
  - ackbar03 7y ago
    I was using ghidra for one of my uhh research projects earlier and I actually found the decompiler from hex rays still does better in some cases. In ghidra sometimes it times out and fails to decompile. Maybe I'm not using it correctly? I haven't begun exploring what kind of plug-ins and stuff it has, maybe that helps?
    - gallexme 7y ago
      For me ghidra is better with c++ disassembling than hex ray, but hex ray is better with c style assemblies Thanks to the better RTTI Analyzer
    - zelly 7y ago
      It depends massively on platform, architecture, and programming language. Hex-Rays is probably still ideal for embedded and obscure platforms. Ghidra's decompiler seems optimized for ARM and amd64 userland consumer-level stuff that the NSA was most interested in hacking.
chrisseaton 7y ago
> IA-32e I’ve never seen this name before. Where does it come from? AMD call it AMD64. Intel call it Intel 64. Why do we need even more names for the same thing beyond these two?! x86_64, x86-64, x64, AMD64, amd64, Intel 64, EM64T, all mean the same thing!
- unilynx 7y ago
  Wild guess, naming it '32bit extended' allowed Intel to still refer to Itanium as the 'real 64 bit' back in those days. Intel didn't want the x86 to be 64bit.. they wanted the world to switch to Itanium for that. I figure a lot of the naming mess can be traced back to Intel's marketing.
- lizknope 7y ago
  It's an older reference but it checks out. When Intel was developing Itanium they named the new architecture IA-64 and retroactively named their 32-bit x86 line IA-32. After AMD released "AMD64" Intel started copying the AMD 64-bit extensions. IA-32e was a short lived name and Intel started using "Intel 64" to refer to the 64-bit extension of x86 and continued using IA-64 for the Itanium VLIW CPU line. https://en.wikipedia.org/wiki/X86-64#History_2 https://en.wikipedia.org/wiki/X86-64#History_2 After several years of denying its existence, Intel announced at the February 2004 IDF that the project was indeed underway. Intel's chairman at the time, Craig Barrett, admitted that this was one of their worst-kept secrets. Intel's name for this instruction set has changed several times. The name used at the IDF was CT (presumably[original research?] for Clackamas Technology, another codename from an Oregon river); within weeks they began referring to it as IA-32e (for IA-32 extensions) and in March 2004 unveiled the "official" name EM64T (Extended Memory 64 Technology). In late 2006 Intel began instead using the name Intel 64 for its implementation, paralleling AMD's use of the name AMD64.
  - chrisseaton 7y ago
    I wonder where the x86-64, x86_64, and (the most strange of all) x64 names came from. I think we should call it AMD64, since that's what the people who actually designed it wanted it to be called.
2ton_jeff 7y ago
Flat Assembler is actually easier to get your head around early on than any of the *asm variants IMO: https://flatassembler.net/ https://flatassembler.net/

Godel_unicode 7y ago

In addition to IDA, I highly recommend looking into ghidra. It's open source, so you can peak under the hood and see how it does things. https://github.com/NationalSecurityAgency/ghidra https://github.com/NationalSecurityAgency/ghidra

anonsivalley652 7y ago
Yep. It's a FOSS-quality disassembler; good if you don't have IDA (I wish), supports maybe 10% of what IDA does in total but has some other niceities that it doesn't (think: disassembler-equivalent of LLVM). (Ideally, you'd have both.) For those who don't know, IDA disassembles basically every unclassified, commercially-available architecture and executable/library/object container format (think: disassembler-equivalent of GCC if it were an IBM or Green Hills product -:P). It also has a built-in scripting API in Python(?), IIRC. An interesting semi-abandonware static disassembler that was really good is Sourcer 8.01 from V-Communications. I think it supports Pentium II/Pro/III at most, which would include real, protected mode and long mode DOS/DOS extended/Win16/Win32 EXEs and COMs IIRC. It did a lot of memory typing and clever analysis long before IDA existed, and still interesting for retro computing. https://www.vetusware.com/download/Sourcer%208.01%208.01/?id=8677 https://www.vetusware.com/download/Sourcer%208.01%208.01/?id...
- Godel_unicode 7y ago
  You might be interested in this talk from the creator of IDA, Ilfak Guilfanov, explaining how he used Sourcer and it's shortcomings lead directly to him creating IDA. https://m.youtube.com/watch?v=hLBlck1lTUs https://m.youtube.com/watch?v=hLBlck1lTUs
zelly 7y ago
It's way better than IDA Pro. I have used the Pro version with the Hex-Rays decompiler. Ghidra is legitimately better. I wouldn't recommend IDA to anyone at this point because I don't see it having much of a future (sorry not sorry). It's worth learning the Ghidra Scripting API because you can write ad-hoc scripts with Jython syntax to automate tasks/do custom analysis.
- ackbar03 7y ago
  I was using ghidra for one of my uhh research projects earlier and I actually found the decompiler from hex rays still does better in some cases. In ghidra sometimes it times out and fails to decompile. Maybe I'm not using it correctly? I haven't begun exploring what kind of plug-ins and stuff it has, maybe that helps?
  - gallexme 7y ago
    For me ghidra is better with c++ disassembling than hex ray, but hex ray is better with c style assemblies Thanks to the better RTTI Analyzer
  - zelly 7y ago
    It depends massively on platform, architecture, and programming language. Hex-Rays is probably still ideal for embedded and obscure platforms. Ghidra's decompiler seems optimized for ARM and amd64 userland consumer-level stuff that the NSA was most interested in hacking.

chrisseaton 7y ago

> IA-32e I’ve never seen this name before. Where does it come from? AMD call it AMD64. Intel call it Intel 64. Why do we need even more names for the same thing beyond these two?! x86_64, x86-64, x64, AMD64, amd64, Intel 64, EM64T, all mean the same thing!

unilynx 7y ago
Wild guess, naming it '32bit extended' allowed Intel to still refer to Itanium as the 'real 64 bit' back in those days. Intel didn't want the x86 to be 64bit.. they wanted the world to switch to Itanium for that. I figure a lot of the naming mess can be traced back to Intel's marketing.
lizknope 7y ago
It's an older reference but it checks out. When Intel was developing Itanium they named the new architecture IA-64 and retroactively named their 32-bit x86 line IA-32. After AMD released "AMD64" Intel started copying the AMD 64-bit extensions. IA-32e was a short lived name and Intel started using "Intel 64" to refer to the 64-bit extension of x86 and continued using IA-64 for the Itanium VLIW CPU line. https://en.wikipedia.org/wiki/X86-64#History_2 https://en.wikipedia.org/wiki/X86-64#History_2 After several years of denying its existence, Intel announced at the February 2004 IDF that the project was indeed underway. Intel's chairman at the time, Craig Barrett, admitted that this was one of their worst-kept secrets. Intel's name for this instruction set has changed several times. The name used at the IDF was CT (presumably[original research?] for Clackamas Technology, another codename from an Oregon river); within weeks they began referring to it as IA-32e (for IA-32 extensions) and in March 2004 unveiled the "official" name EM64T (Extended Memory 64 Technology). In late 2006 Intel began instead using the name Intel 64 for its implementation, paralleling AMD's use of the name AMD64.
- chrisseaton 7y ago
  I wonder where the x86-64, x86_64, and (the most strange of all) x64 names came from. I think we should call it AMD64, since that's what the people who actually designed it wanted it to be called.

2ton_jeff 7y ago

Flat Assembler is actually easier to get your head around early on than any of the *asm variants IMO: https://flatassembler.net/ https://flatassembler.net/