Problems with strcpy/memcpy

Blackened Justice · 05-19-2012, 07:03 PM

Hey everyone,

I've been reading up a bit on obfuscation techniques, including the following article: http://www.brandonparker.net/code_obf.php

In helloworld-4.c, he beforehand uses a small C program to get the pair of doubles whose values correspond to the string "Hello World". To do that, he uses strcpy to copy into the double array the string "Hello World", and then prints out the values of the array members. Well, I can't seem to get this to work. The first float prints out the right value (219144411970...), but the second just prints out 0.000000... What's happening here? I have checked, and sizeof double == 8 in my machine, so I should be getting the same outcome.

Cheers

lej · 05-20-2012, 12:38 AM

As far as I can see, he is not properly initializing str[1], i.e. he is writing 'Hello Wo' into str[0] (no problem), but only 'rld\0' into str[1], leaving the upper 4 bytes uninitialized, so the second number he got was essentially random!

Blackened Justice · 05-20-2012, 08:22 AM

Quote:

Originally Posted by lej

As far as I can see, he is not properly initializing str[1], i.e. he is writing 'Hello Wo' into str[0] (no problem), but only 'rld\0' into str[1], leaving the upper 4 bytes uninitialized, so the second number he got was essentially random!

But even if I place the array outside main (globals are initialized to zeros) or if I memset it to zero, it still prints out 0.000000 as the second number. I don't expect it to print out the same number that he got, he probably did have garbage remaining, I just want to have a non-zero value

It probably has to do with the internal representation of a double. If I print it out using %g, I get 3.25162e-317, so maybe its filling up the fraction bits but not the exponent ones.

lej · 05-20-2012, 08:54 AM

Blackened Justice, I tested the code and got the same numbers as you. Yeah, it seems to be precision related, %f only prints to so many decimal places, while %g uses significant digits. The exponent and sign are the high 12 bits, which will be in the highest bytes on x86, so as the code doesn't write to those bytes, they were presumably zeroed to start with, resulting in a tiny number that %f just truncates to zero.

johnsfine · 05-20-2012, 09:32 AM

A double is 8 bytes long and the most significant bytes are last. Not every pattern of 8 bytes is a double that can be uniquely translated for printing. Doubles that end with zeroes are especially tricky.

"Hello World" has 11 non zero bytes. So your second double has three non zero bytes followed by five zero bytes.

I suggest initializing the second double to some reasonable value, then do the strcpy, which will overwrite the four least significant bytes of the second double. Then you still have a value you can print and maybe a value that can be reconstructed from what you print.

I tried this on my system. I put both translations in one program for ease of testing:

Code:

#include <stdio.h>

int main(){
  double str[2] = {0.0, 1e16 };
  strcpy((char*)str,"Hello World");
  printf("%.17g\n%.0f\n",str[0],str[1]);

  double x[] = { 2.1914441197069634e228, 9999998138243300 };
  printf("%s\n", x);
}

That works, at least on my system. I tested a few times to discover how many significant digits were needed. I expected it to take 16, but the first number seems to need 18 (one before the dot and 17 after).

Blackened Justice · 05-20-2012, 01:03 PM

Thank you all for your help, I ended up learning a lot from this whole thing