macaw-base's PLT-stub detection machinery is currently equipped to handle x86-64 and AArch32, but not any other architectures. Recently, I found myself wanting to extend these heuristics to PowerPC. Unfortunately, the current heuristics that we use for detecting PLT stubs in macaw-base is not equipped to handle the layout of PLT stubs in PowerPC. To see what I mean, observe that if you compile the following program using a PPC32 cross compiler:
#include <stdlib.h>
int main(void) {
int* x = malloc(sizeof(int));
*x = 42;
free(x);
return 0;
}
This looks quite different from how PLT stubs work on x86-64 and AArch32. Unlike on those architectures, on PowerPC we see that the main function invokes PLT stubs that are located in the .text section rather than the .plt section. This is bad news for macaw's current heuristics, which always assume that PLT stubs are located in a .plt or .plt.got section. What's more, there is a .plt section, but it contains the addresses of PLT entries (which refer to a special __glink function) rather than the PLT stubs themselves. In this sense, the .plt section on PowerPC behaves more like the .got/.got.plt section on other architectures. (This blog post explains the nuances better than I can.)
As such, macaw's heuristics will return incorrect PLT stub addresses when used on a PowerPC binary. It is likely possible to generalize the heuristics to make it work over PowerPC, but we may need to revisit some assumptions that we currently make about what things live where.
macaw-base's PLT-stub detection machinery is currently equipped to handle x86-64 and AArch32, but not any other architectures. Recently, I found myself wanting to extend these heuristics to PowerPC. Unfortunately, the current heuristics that we use for detecting PLT stubs inmacaw-baseis not equipped to handle the layout of PLT stubs in PowerPC. To see what I mean, observe that if you compile the following program using a PPC32 cross compiler:The
objdumpoutput will show the following:This looks quite different from how PLT stubs work on x86-64 and AArch32. Unlike on those architectures, on PowerPC we see that the
mainfunction invokes PLT stubs that are located in the.textsection rather than the.pltsection. This is bad news formacaw's current heuristics, which always assume that PLT stubs are located in a.pltor.plt.gotsection. What's more, there is a.pltsection, but it contains the addresses of PLT entries (which refer to a special__glinkfunction) rather than the PLT stubs themselves. In this sense, the.pltsection on PowerPC behaves more like the.got/.got.pltsection on other architectures. (This blog post explains the nuances better than I can.)As such,
macaw's heuristics will return incorrect PLT stub addresses when used on a PowerPC binary. It is likely possible to generalize the heuristics to make it work over PowerPC, but we may need to revisit some assumptions that we currently make about what things live where.