Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Dec 2017 20:44:12 +0100
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Compiling John as a shared object

On Tue, Nov 28, 2017 at 03:17:43PM +0100, harrim4n wrote:
> I'm trying to compile John as a shared object to use in python bindings
> for a project I'm working on. I'm using the latest version from
> https://github.com/magnumripper/JohnTheRipper/tree/bleeding-jumbo.

Great.

> However I'm running into some issues doing so, namely the x86-64.S file.
> As this file is assembly, I can't simply recompile it with -fPIC.
> 
> This causes the following error when trying to create a "libjohn.so" file:
> 
> /usr/bin/ld: x86-64.o: relocation R_X86_64_PC32 against symbol
> `nt_buffer8x' can not be used when making a shared object; recompile
> with -fPIC
> 
> However, to me, the assembly already looks to be position independent.

Unfortunately, it is not.  For PIC code, the RIP-relative addressing
should be used to access the GOT entry, through which the actual
"non-local" variables (not in the same translation unit) are accessed.
Accessing them directly via RIP-relative addressing is not enough.

> Does anyone have pointers as to how I could either modify the assembly
> to be PI

Here's the kind of changes needed:

$ cat x.c
extern int x;
int f(void) { return x; }
$ gcc -S -O2 x.c -o x1.s
$ gcc -S -O2 x.c -o x2.s -fPIC
$ diff -U0 x1.s x2.s
[...]
-	movl	x(%rip), %eax
+	movq	x@...PCREL(%rip), %rax
+	movl	(%rax), %eax

> or any other way I could create python bindings for John?

You could drop the assembly files altogether.  We have equivalent (and
sometimes superior) C code for everything contained in there, except for
the runtime CPU detection.  You just need to set the corresponding *_ASM
defines in arch.h (a file that's generated when you ./configure, or is
symlinked to e.g. x86-64.h) to 0 and "#undef NT_X86_64" to tell the rest
of JtR not to expect assembly code for any of the crypto.

Yet another option might be to look at and reuse some experience from
this project:

https://github.com/L0phtCrack/jtrdll

This is how JtR is integrated with LC7, so it focuses on Windows builds
and is not usable for you directly.

> I am aware that I could rebuild the python interpreter and use static
> linking, however I would like to avoid this option because of obvious
> maintainability issues. I also tried simply using a statically built lib
> in the setup.py file, but then I get
> 
> ImportError: /usr/lib/python2.7/site-packages/pyJohn.so: undefined
> symbol: fmt_nsec3

I suppose you merely include samples of these errors, and you actually
got a lot more of similar errors?  It's hard to debug this via a mailing
list.  I guess you'd need to investigate it on your own.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ