By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,919 Members | 1,096 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,919 IT Pros & Developers. It's quick & easy.

logical OR obfuscation

P: n/a
Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition
Nov 13 '05 #1
Share this Question
Share on Google+
23 Replies


P: n/a
Mantorok Redgormor wrote:

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


if (!(!a && !b))

--
pete
Nov 13 '05 #2

P: n/a
Greetings.

In article <41**************************@posting.google.com >, Mantorok
Redgormor wrote:
Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


if (a)
do_something();
if (b && !a)
do_something();

or

if (a||b||!(really_complicated_expression))

where really_complicated_expression is a tautology (i.e., necessarily true).

There are an infinite number of variations.

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you
Nov 13 '05 #3

P: n/a

"Mantorok Redgormor" <ne*****@tokyo.com> schrieb im Newsbeitrag
news:41**************************@posting.google.c om...
Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


#include <stdlib.h>
#include <stdio.h>

int hide_or(int a, int b)
{
int c = 0;
if(a)
{
c = 1;
}
if(b)
{
c = 1;
}
return c;
}
int hide_and(int a, int b)
{
int c = 0;
if(a)
{
if(b)
{
c = 1;
}
}
return c;
}
int main(void)
{
int a = 0;
int b = 0;
int c;

c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 0;
b = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
return EXIT_SUCCESS;
}

Robert
Nov 13 '05 #4

P: n/a
Mantorok Redgormor wrote:

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


if (!(!a && !b)) ;
else {
/* whatever */
}

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #5

P: n/a

"Tristan Miller" <ps********@nothingisreal.com> schrieb im Newsbeitrag
news:69****************@ID-187157.news.dfncis.de...
Greetings.

In article <41**************************@posting.google.com >, Mantorok
Redgormor wrote:
Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


if (a)
do_something();
if (b && !a)
do_something();


This is not an exact equivalent, because it does not account for the lazy
evaluaton.

cheers
Robert


Nov 13 '05 #6

P: n/a


Mantorok Redgormor wrote:
Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


if (a ? 1 : (b ? 1 : 0)) {
do something
}

Regards,

Ed.

Nov 13 '05 #7

P: n/a

"Tristan Miller" <ps********@nothingisreal.com> wrote in message news:69****************@ID-187157.news.dfncis.de...
Greetings.

In article <41**************************@posting.google.com >, Mantorok
Redgormor wrote:
Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition
if (a)
do_something();
if (b && !a)
do_something();

Caution: This assumes the first "do_something()" does not have a side effect that can change a or b.


or

if (a||b||!(really_complicated_expression))

where really_complicated_expression is a tautology (i.e., necessarily true).

There are an infinite number of variations.

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you

Nov 13 '05 #8

P: n/a
On Mon, 29 Sep 2003, Mantorok Redgormor wrote:
Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


Yes. The ||, && and ! come from boolean logic. Any introduction to boolean
logic will teach you to write OR in terms of AND and NOT.

More importantly, why would you want to?

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@whitehouse.gov
Nov 13 '05 #9

P: n/a

"Robert Stankowic" <pc******@netway.at> schrieb im Newsbeitrag
news:3f***********************@newsreader02.highwa y.telekom.at...

"Mantorok Redgormor" <ne*****@tokyo.com> schrieb im Newsbeitrag
news:41**************************@posting.google.c om...
Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


#include <stdlib.h>
#include <stdio.h>

int hide_or(int a, int b)
{
int c = 0;
if(a)
{
c = 1;
}
if(b)
{
c = 1;
}
return c;
}
int hide_and(int a, int b)
{
int c = 0;
if(a)
{
if(b)
{
c = 1;
}
}
return c;
}
int main(void)
{
int a = 0;
int b = 0;
int c;

c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 0;
b = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
return EXIT_SUCCESS;
}


Oops, this does not emulate the lazy evaluation :(
sorry
Nov 13 '05 #10

P: n/a
pete wrote:

Mantorok Redgormor wrote:

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


if (!(!a && !b))

--
pete


Now I know you, pete de Morgan. Very good. :-)
--
Joe Wright mailto:jo********@earthlink.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 13 '05 #11

P: n/a

"Robert Stankowic" <pc******@netway.at> schrieb im Newsbeitrag
news:3f***********************@newsreader02.highwa y.telekom.at...

"Mantorok Redgormor" <ne*****@tokyo.com> schrieb im Newsbeitrag
news:41**************************@posting.google.c om...
Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


sorry, the code did not correctly deal with side effects and lazy evaluation
:((
maybe this one is better

#include <stdlib.h>
#include <stdio.h>

int foo;

int bar(int val)
{
foo++;
return val;
}

int baz(int val)
{
foo++;
return val;
}

void do_something(void)
{
}

int main(void)
{
int i;
int j;

for(i = 0; i < 2; i++)
{
for(j = 0; j < 2; j++)
{
foo = 0;
if(bar(i))
{
do_something();
continue;
}
if(baz(j))
{
do_something();
}
}
}

for(i = 0; i < 2; i++)
{
for(j = 0; j < 2; j++)
{
foo = 0;
if(bar(i))
{
if(baz(j))
{
do_something();
}
}
}
}

return EXIT_SUCCESS;
}
Robert
Nov 13 '05 #12

P: n/a
Mantorok Redgormor wrote:
Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition


#define BLUE_MEANIES ||

if (a BLUE_MEANIES b) ...

NR

Nov 13 '05 #13

P: n/a
>> int hide_or(int a, int b)
{
int c = 0;
if(a)
{
c = 1;
}
if(b)
{
c = 1;
}
return c;
}

[remaining code snipped]
Oops, this does not emulate the lazy evaluation :(
sorry


I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}

I'm not sure, but might still have some side effects, though.

--
Martijn
http://www.sereneconcepts.nl
Nov 13 '05 #14

P: n/a
In article <3f***********************@news.xs4all.nl>,
"Martijn" <su*********************@hotNOFILTERmail.com> wrote:
int hide_or(int a, int b)
{
int c = 0;
if(a)
{
c = 1;
}
if(b)
{
c = 1;
}
return c;
}


[remaining code snipped]
Oops, this does not emulate the lazy evaluation :(
sorry


I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}

I'm not sure, but might still have some side effects, though.


If you _call_ the function, both arguments that you pass will be
evaluated before they are passed to your function. Example:

int test1 (int* p) { return p == NULL || *p == 0; }
int test2 (int* p) { return hide_or (p == NULL, *p == 0); }

The second function will crash if you call it with a null pointer as its
argument because it will evaluate *p. There is no "lazy" evaluation here
at all.
Nov 13 '05 #15

P: n/a
Martijn wrote:
int hide_or(int a, int b)
{
int c = 0;
if(a)
{
c = 1;
}
if(b)
{
c = 1;
}
return c;
}


[remaining code snipped]
Oops, this does not emulate the lazy evaluation :(
sorry


I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}

I'm not sure, but might still have some side effects, though.


I don't see any side effects.

N869
5.1.2.3 Program execution
[#2]
Accessing a volatile object,
modifying an object,
modifying a file,
or calling a function that does any of those operations
are all side effects,
which are changes in the state of the execution environment.

--
pete
Nov 13 '05 #16

P: n/a

"pete" <pf*****@mindspring.com> schrieb im Newsbeitrag
news:3F***********@mindspring.com...
Martijn wrote:
> int hide_or(int a, int b)
> {
> int c = 0;
> if(a)
> {
> c = 1;
> }
> if(b)
> {
> c = 1;
> }
> return c;
> }


[remaining code snipped]
Oops, this does not emulate the lazy evaluation :(
sorry


I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}
No, because if the function is called, both arguments, which can cause
side-effects, are evaluated, in if(a || b) only if a yields 0.
I'm not sure, but might still have some side effects, though.


I don't see any side effects.

N869
5.1.2.3 Program execution
[#2]
Accessing a volatile object,
modifying an object,
modifying a file,
or calling a function that does any of those operations
are all side effects,
which are changes in the state of the execution environment.


If the function is called with for example
hide_or(foo(), bar());
foo() and bar() are both called, in if(foo() || bar()){} only if foo()
returns 0.
I am totally sure you know that :)

regards
Robert
Nov 13 '05 #17

P: n/a
Robert Stankowic wrote:

"pete" <pf*****@mindspring.com> schrieb im Newsbeitrag
news:3F***********@mindspring.com...
Martijn wrote:

>> int hide_or(int a, int b)
>> {
>> int c = 0;
>> if(a)
>> {
>> c = 1;
>> }
>> if(b)
>> {
>> c = 1;
>> }
>> return c;
>> }

[remaining code snipped]

> Oops, this does not emulate the lazy evaluation :(
> sorry

I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}

No, because if the function is called, both arguments, which can cause
side-effects, are evaluated, in if(a || b) only if a yields 0.
I'm not sure, but might still have some side effects, though.


I don't see any side effects.

N869
5.1.2.3 Program execution
[#2]
Accessing a volatile object,
modifying an object,
modifying a file,
or calling a function that does any of those operations
are all side effects,
which are changes in the state of the execution environment.


If the function is called with for example
hide_or(foo(), bar());
foo() and bar() are both called, in if(foo() || bar()){} only if foo()
returns 0.
I am totally sure you know that :)


.... or even

hide_or(a++, b);

Those side effects are from the function *call*.
They are not side effects from the function.
Some functions, like memset(), have side effects.
The function defined above, has no side effects.

--
pete
Nov 13 '05 #18

P: n/a

"pete" <pf*****@mindspring.com> schrieb im Newsbeitrag
news:3F***********@mindspring.com...
Robert Stankowic wrote:

"pete" <pf*****@mindspring.com> schrieb im Newsbeitrag
news:3F***********@mindspring.com...
Martijn wrote:
>
> >> int hide_or(int a, int b)
> >> {
> >> int c = 0;
> >> if(a)
> >> {
> >> c = 1;
> >> }
> >> if(b)
> >> {
> >> c = 1;
> >> }
> >> return c;
> >> }
>
> [remaining code snipped]
>
> > Oops, this does not emulate the lazy evaluation :(
> > sorry
>
> I'd would if you'd write:
>
> int hide_or(int a, int b)
> {
> if (a)
> return 1;
> if (b)
> return 1;
>
> return 0;
> }
>


No, because if the function is called, both arguments, which can cause
side-effects, are evaluated, in if(a || b) only if a yields 0.
> I'm not sure, but might still have some side effects, though.

I don't see any side effects.

N869
5.1.2.3 Program execution
[#2]
Accessing a volatile object,
modifying an object,
modifying a file,
or calling a function that does any of those operations
are all side effects,
which are changes in the state of the execution environment.


If the function is called with for example
hide_or(foo(), bar());
foo() and bar() are both called, in if(foo() || bar()){} only if foo()
returns 0.
I am totally sure you know that :)


... or even

hide_or(a++, b);

Those side effects are from the function *call*.
They are not side effects from the function.
Some functions, like memset(), have side effects.
The function defined above, has no side effects.


Ah, OK, my misunderstanding - I had the whole code in mind.
In the context of the function only you are right of course

regards
Robert
Nov 13 '05 #19

P: n/a
Joe Wright wrote:
pete wrote:
if (!(!a && !b))

Now I know you, pete de Morgan. Very good. :-)


He prefers to be called "Captain" de Morgan. Arrr!

--
Tom Zych
This is a fake email address to thwart spammers.
Real address: echo 'g******@cbobk.pbz' | rot13
Nov 13 '05 #20

P: n/a
Tom Zych <tz******@pobox.com> writes:
Joe Wright wrote:
pete wrote:

if (!(!a && !b))

Now I know you, pete de Morgan. Very good. :-)


He prefers to be called "Captain" de Morgan. Arrr!


International Talk Like a Pirate Day was a couple of weeks ago.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #21

P: n/a
Tom Zych wrote:
Joe Wright wrote:
pete wrote:

if (!(!a && !b))

Now I know you, pete de Morgan. Very good. :-)


He prefers to be called "Captain" de Morgan. Arrr!


I'll go along if he tells where he buried his treasure. It's
supposedly right around here.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 13 '05 #22

P: n/a
CBFalconer <cb********@yahoo.com> writes:
Tom Zych wrote:
Joe Wright wrote:
pete wrote:

> if (!(!a && !b))

Now I know you, pete de Morgan. Very good. :-)


He prefers to be called "Captain" de Morgan. Arrr!


I'll go along if he tells where he buried his treasure. It's
supposedly right around here.


Or not.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #23

P: n/a
Keith Thompson wrote:

CBFalconer <cb********@yahoo.com> writes:
Tom Zych wrote:
Joe Wright wrote:
> pete wrote:

> > if (!(!a && !b))

> Now I know you, pete de Morgan. Very good. :-)

He prefers to be called "Captain" de Morgan. Arrr!


I'll go along if he tells where he buried his treasure. It's
supposedly right around here.


Or not.


http://www.johnbetts-fineminerals.co...rips/fonda.htm

I'll probably be digging at Treasure Mountain on Sunday.
After that, the season's over for me, too cold.

--
pete
Nov 13 '05 #24

This discussion thread is closed

Replies have been disabled for this discussion.