Doesn't compile on Kali

[cdefender]

Hey domas, take a look at it:

t@kali:~/Desktop/Tools/sandsifter# make cc -c injector.c -o injector.o -Wall injector.c:321:93: warning: excess elements in array initializer .start={.bytes={0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}, .len=0}, ^~~~ injector.c:321:93: note: (near initialization for ‘total_range.start.bytes’) injector.c:322:91: warning: excess elements in array initializer .end={.bytes={0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}, .len=0}, ^~~~ injector.c:322:91: note: (near initialization for ‘total_range.end.bytes’) injector.c: In function ‘inject’: injector.c:817:2: warning: asm operand 7 probably doesn’t match constraints asm volatile ("
^~~~~~~ injector.c:817:2: error: impossible constraint in ‘asm’ Makefile:38: recipe for target 'injector.o' failed make: *** [injector.o] Error 1

[paulmenzel]

This happens only when building with -fPIC, right? On Debian Sid/unstable, just running make I get the error below.

$ make
cc  -c injector.c -o injector.o -Wall
[…]
cc  injector.o -O3 -Wall -l:libcapstone.a -o injector -pthread
/usr/bin/ld: injector.o: relocation R_X86_64_32S against undefined symbol `dummy_stack' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Makefile:35: recipe for target 'injector' failed
make: *** [injector] Error 1

Then building with -fPIC, your error can be reproduced.

$ make CFLAGS="-fPIC"
cc -fPIC -c injector.c -o injector.o -Wall
[…]
injector.c: In function ‘inject’:
injector.c:778:2: warning: asm operand 15 probably doesn’t match constraints
  __asm__ __volatile__ ("\
  ^~~~~~~
injector.c:778:2: error: impossible constraint in ‘asm’
Makefile:38: recipe for target 'injector.o' failed
make: *** [injector.o] Error 1

[ggramaize]

I reproduce exactly paulmenzel's result on Debian stretch with the following environment:

# cc --version
cc (Debian 6.3.0-18) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# apt-cache policy python3-capstone libcapstone3 libcapstone-dev python-capstone
python3-capstone:
  Installé : 3.0.4-1
  Candidat : 3.0.4-1
 Table de version :
 *** 3.0.4-1 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status
libcapstone3:
  Installé : 3.0.4-1
  Candidat : 3.0.4-1
 Table de version :
 *** 3.0.4-1 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status
libcapstone-dev:
  Installé : 3.0.4-1
  Candidat : 3.0.4-1
 Table de version :
 *** 3.0.4-1 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status
python-capstone:
  Installé : 3.0.4-1
  Candidat : 3.0.4-1
 Table de version :
 *** 3.0.4-1 500
        500 http://ftp.fr.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status

[f4grx]

probably unrelated but I compiled capstone master from scratch instead of using version from package managers.

[LeoAdamek]

@f4grx have a look at #2 -- Try adding -no-pie to the linker step, it resolves the exact same issue I had on Arch.

[paulmenzel]

Yes, doing the change below fixes the problem.

-       $(CC) $(CFLAGS) $< -O3 -Wall -l:libcapstone.a -o $@ -pthread
+       $(CC) $(CFLAGS) $< -O3 -Wall -no-pie -l:libcapstone.a -o $@ -pthread

[Thiefyface]

I can get it to compile by changing the following:

+ [esp]"p"(&dummy_stack.dummy_stack_lo),
-  [esp]"i"(&dummy_stack.dummy_stack_lo),

But I'm not entirely sure if the p constraint is correct. The binary tends to only run through 1 iteration after compilation. I'm thinking that the issue has to do with the fact that since I'm running this on an x86 system, and the dummy_stack struct members are both 64 bits, it's trying to read in a 64 bit value into a memory operand, which is probably no bueno.

Could prob just patch to add a macro based on system architecture for this structure.