I figured out what's going on. This is a glibc security measure where they scramble pointers people might try to maliciously tamper with. If you change the pointer, you (supposedly) can't easily tell what you're changing it too. The problem here is that the pointer it's unscrambling is just a normal pointer so it's really scrambling it. A likely reason I've never seen this before is that this mechanism isn't used for static binaries for some reason.
Gabe Gabe Black wrote: > I figured part of this out (objdump is my new best friend), but I > ran into another mystery. The problem I'm trying to diagnose is that the > init process gets a segfault at some point as it comes up because it > jumps to a totally bizarre and meaningless pc. The dynamic linker has > finished settup up the executable, and /lib/libc.so.6 is doing something > for a while. Eventually, it loads a value from memory, rotates it right > by 17 bits, xors it against something it got out of TLS, and then jumps > to the (totally wrong) address. I have no idea how this is supposed to > do anything but break horribly, so I was wondering if anyone else has > ever seen something like this before and knows what the heck libc is > trying to do. I've verified that the this piece of code really does > exist in libc (below), but unfortunately there's no debug information so > I can't easily trace it to the originating C. The fact that the REX > prefix (0x48) exists in there an unusually large number of times makes > me confident this is actually code. > > Gabe > > 6a383: 48 8b 05 e6 3a 2d 00 mov > 0x2d3ae6(%rip),%rax # 33de70 <argp_program_version_hook+0x1a0> > 6a38a: 48 c1 c8 11 ror $0x11,%rax > 6a38e: 64 48 33 04 25 30 00 xor %fs:0x30,%rax > 6a395: 00 00 > 6a397: ff d0 callq *%rax > > Gabe Black wrote: > >> Recently I've had the good fortune of discovering what a pain it is >> to try to debug user level code in FS with no symbols. I'm going to >> think about ways to make the process easier, and I was wondering if >> there are any tricks other people know of that might help. Also, does >> anyone know of a good way to use gdb on the dynamic linker binary? I >> know /sbin/init is dynamically linked and I know where the linker gets >> stuck in memory, but I haven't been able to get gdb to tell me anything >> useful about it (/lib64/ld-linux-x86-64.so.2). For instance, I'd like to >> disassemble its entry point, but gdb insists it can't read it for some >> reason. The entry point according to the elf headers is 0xb10, and from >> tracing m5 it appears that that's being relocated to 0x2b8ff0abfb10. I'm >> sure I can get the bytes I need with, for instance, hexedit, but that's >> a little too masochistic I think. >> >> Gabe >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
