4

Is there a method/plugin/addon in place to ignore the following clause (for some c/c++ compiler)? To reorder the declaration of members in a struct during the same stage as the preprocessor or similar? Perhaps by adding a keyword like volatile or something similar to the front of the struct declaration.

I was thinking: a compiler option, a built-in keyword, or a programming method.

C99 §6.7.2.1 clause 13 states:

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared.

C++ seems to have a similar clause, and I am interested in that as well. The clauses both specify a reasonable feature to have in terms of later declarations have greater memory offsets. But, I often do not need to know the declaration order of my struct for interface purposes or some other. It would be nice to write some code like:

scrambled struct foo {
    int a;
    int bar;
};

or, suppose order doesn't really matter with this struct.

scrambled struct foo {
    int bar;
    int a;
};

And so, have the declaration of a and b swapped randomly each time I compile. I believe that this also applies to setting aside stack memory.

main() {
    scrambled int a;
    scrambled int foo;
    scrambled int bar;
    ..

Why do I ask?

I was curious to see how program bots were created. I watched some people analyzing memory offsets for changes while running the program to which a hack will be created.

It seems the process is: watch the memory offsets and take note of the purpose for the given offsets. Later, hack programs will inject desired values into memory at those offsets.

Now suppose those memory offsets changed every single time the program is compiled. Maybe it would hinder or dissuade individuals from taking the time to understand something you would rather they not know.

Community
  • 1
  • 1
Leonardo
  • 1,452
  • 3
  • 15
  • 26
  • Why not reorder structs etc. yourself? And what someone is doing *on his/her ow computer, without influencing anything else* is none of your concern. Let them be. If it could harm (etc.) other people, you´ll need additional security measures anyway, much better ones than variable reordering. – deviantfan Nov 28 '14 at 19:17
  • One can imagine an extension that does this but for performance reasons: it would allow to have members alignment with minimal padding between members. No compiler I know of has such an extension. – ouah Nov 28 '14 at 19:18
  • @deviantfan They can do so, it would only affect them if they expect the behavior to persist between versions they download. – Leonardo Nov 28 '14 at 19:19
  • @ouah The padding can persist because I was thinking of something that would re-order during a preprocessor-like stage. – Leonardo Nov 28 '14 at 19:20
  • @Leonardo If they break their program settings or whatever, it´s their own fault. I wouldn´t be too concerned about that. (And if someone does things by changing memory locations, he/she should find the remaining registry keys etc. too) – deviantfan Nov 28 '14 at 19:22
  • @deviantfan The idea is to help ensure their program breaks if they attempt to do so. – Leonardo Nov 28 '14 at 19:25
  • Visual C++ produces executable with on-load random reordering by default, although not reordering of individual structs. – Cheers and hth. - Alf Nov 28 '14 at 19:31

2 Answers2

1

Run-time foxing is the best way, then you only have to release a single version. Where a struct has several fields of the same type, you can use an array instead. Step 1. Instead of a structure with three int fields use an array

#define foo 0
#define bar 1
#define zee 2

struct abc {
    int scramble [3];
};

...
value = abc.scramble[bar];

Step 2, now use an indexing array which is randomised every time the program is run.

int abcindex [3];               // index lookup 
int abcpool  [3];               // index pool for randomise

for (i=0; i<3; i++)             // initialise index pool
    abcpool[i] = i;

srand (time(NULL));
for (i=0; i<3; i++) {           // initialise lookup array
    j = rand()%(3-i);
    abcindex[i] = abcpool[j];   // allocate random index from pool
    abcpool[j] = abcpool[2-i];  // remove index from pool
    }

value = abc.scramble[abcindex[bar]];

Another way to try to fox a hacker is to include subterfuge variables that behave as if they have something to do with it but make the program exit if tampered with. Lastly you can keep some kind of checksum or encrypted copy of key variables, to check if they have been tampered with.

Weather Vane
  • 33,872
  • 7
  • 36
  • 56
  • Thanks, this is great input. I wonder if there are any nice libraries that will encapsulate using the array in this manner. I want to minimize the amount of effort needed to implement these practices for programmers, while remaining difficult to circumvent for malicious users. – Leonardo Nov 28 '14 at 20:20
  • 2
    Anti-tamper methods will put off some but not all. A skilled malicious user will disassemble your program and patch out the checks. – Weather Vane Nov 28 '14 at 22:59
0

Your intention is good, but the solution isn't (sorry). Usually you can't recompile your program before each run. The attacker will hack the inspected program. However, there's a solution, called ASLR. The operating system could change the load address for you, thus making "return oriented programming" and "return to libc like hacks harder".

erenon
  • 18,838
  • 2
  • 61
  • 93
  • If we were talking about a client that must always connect to a server and update itself before use, wouldn't that require the attacker to always come up with a solution dynamically? – Leonardo Nov 28 '14 at 19:27
  • If the attacker runs the program locally, on his own machine, you already lost that instance. Nothing is trusted on an untrusted computer. E.g: computer games. There's none without a hack/crack. – erenon Nov 28 '14 at 19:32
  • I see, so you mean never rely on a lack of ingenuity. From what I saw it just seemed like hacking something simple was heavily reliant on finding memory offsets, and having them change could cause grief. I am really interested in a pragmatic approach to dissuasion, not making an air-tight secure system. – Leonardo Nov 28 '14 at 19:35