• (cs) in reply to tdog
    Anonymous:

    I love the word "obfuscated".  It sounds kewl, it looks kewl, it is kewl.  I have been trying to use the word atlease three times a day for the last few weeks.  It just rocks.  Dats all I gut tu say bout dat.

    tdog



    This gives me a great idea to write a piece of software called -- PHP Obfuscator!!! Secure your sensitive PHP code by obfuscating it from hackers and DOS attacks! Don't wait until it is too late - get PHP Obfuscator now to ensure that your code is obfuscated!

    Boy, I could sell this for $10 and make it rich in no time! It'll be more popular than the PHP To HTML Converter! MUAHAHAHAHHAHAHAHAHA!!!!!!
  • (cs) in reply to friday13

    bleh, un-editable forum software... :$

    I meant HTML To PHP Converter...

  • Thijs Leibbrand (unregistered)
    Alex Papadimoulis:

    Richard's company builds, hosts, and maintains a variety of small- and mid-sized web-based applications for their clients. Recently, one of their clients asked Richard to help audit a fraudulent transaction, which meant that Richard needed to dig through the code to see how to decrypt bank account numbers stored in the database. The search led him to H88493247329(), the method responsible for encrypting customer data. After spending a minute to add linebreaks and rename the variables, Richard asked his coworker why he obfuscated the code. His coworker scoffed, you should always encrypt your encryption functions -- it's completely insecure otherwise

    function H88493247329($B89424235)
    {
    //ED: Linkebreaks added global $a,$e,$m,$H;
    $X42342234 = $H . "." . $m . "-" . $a;

    $KJD234 = fopen($X42342234,"r");
    $MMNVUD884 = fread($KJD234,filesize($X42342234));
    fclose($KJD234);

    $MQUFI3 = mcrypt_module_open('','',''');
    $MMNVUD884 = substr($MMNVUD884,0,mcrypt_enc_get_key_size($MQUFI3));

    $JF8_size = mcrypt_enc_get_iv_size($MQUFI3);
    $JF8 = mcrypt_create_iv($JF8_size, MCRYPT_RAND);

    if (mcrypt_generic_init($MQUFI3,$MMNVUD884,$JF8)!=-1)
    {
    $KIDO83R4234FFS = mcrypt_generic($MQUFI3,$B89424235);
    mcrypt_generic_deinit($MQUFI3);
    mcrypt_module_close($MQUFI3);
    }
    return $KIDO83R4234FFS;
    }



    Minor type, did not read all the comments but the following line will produce a fatal error:

    $MQUFI3 = mcrypt_module_open('','',''');

    last part is wrong, you open, close and then open the single bracket again.. Or you should atleast backslash if it is supposed to be there.

    (I know this is edited for posting to hide the real module that is being used here to prevent possible hacks from someone if they recognize this code.)

  • (cs) in reply to Thijs Leibbrand

    <font style="font-family: Courier New;" size="2">Even if the typo in "mcrypt_module_open" (as mentioned above) was fixed, it still wouldn't work.  The first parameter specifies the algorithm to use - a blank value is not allowed.  Thus, "mcrypt_module_open" would always return FALSE (NULL etc.) rather than a valid handle.  What happens after that is an exercise in hilarity.

    If "mcrypt_generic_init" fails for any reason the return value of the function is undefined (the value of an undefined local variable). ie. NULL (zero/FALSE).

    Meanwhile, since the salt key is obviously stored in a file on the local filesystem, I wonder if the WWW server was told not to serve it up to a remote client?

    </font><font size="2"></font>

  • (cs) in reply to friday13
    friday13:


    This gives me a great idea to write a piece of software called -- PHP Obfuscator!!!

    http://pobs.mywalhalla.net/ - Open Source
    http://www.ioncube.com/ - commercial

    Of course, in the meantime the guys at www.php.net have released a bytecode compiler for PHP, so obfuscators are no longer needed...
  • Donald (unregistered) in reply to felix

    <HTMLTag>The forum software...that's the WTF!</HTMLTag>

    Get it? I'm making fun of the fact that most posts show the HTML tags.

  • Ray Magini (unregistered) in reply to Darax The Good
    Darax The Good:
    ejsy sm ofopy


    snik fnu ptha!
  • Chris (unregistered) in reply to rbriem
    rbriem:

    Now how do you say, "Go ahead - fire me" in Latin?

    A very loose translation: "Age! Depone me!"

  • lft (unregistered) in reply to Xarium

    The IV is generated randomly and used in the encryption. Then the IV is thrown away, making the encrypted data meaningless. Or am I missing something?

  • (cs)

    H88493247329() ??? Sounds like even the method name has been encrypted!!

  • (cs) in reply to frosty
    frosty:
    Umm... aren't you f***ed if the hacker gets as far as being able to look at your source code anyway?


    Yes, but it sounds as if the programmer was confused about where his code was being executed - on the server or on the client.  Not a good sign!!


  • (cs) in reply to Joe Blow

    well spotted, poindexter...

  • Kleag (unregistered) in reply to kipthegreat

    Well, another "good" reason: to try to circumvent antivirus tools if you're writing a virus or other malware... This is one of the methods used by virus authors.

  • (cs) in reply to kipthegreat
    masklinn:
    Anonymous:

    You can use LISP, no obfuscation needed...

     

    Actually you would, the only languages that don't really need encryption are esoteric languages (Moo, Chef, Whitespace, Java2k) and most of them can be translated to more common languages (Java2k can't, but it's quite tough to use to code anything)



    There's a difference between obfuscation and encryption.

    At first I wondered why you were saying that, and then I re-read my post... dho, I of course meant obfuscation not encryption, my point being that Lisp isn't obfuscated "out of the box" (it requires a good indentation though, but most Lisp editors have no trouble whatsoever indenting Lisp code nicely) but that so-called esoteric languages are.

    Yet that most of them can be fairly easily transcoded to more classic languages (such as C), the only esoteric language that I know of that couldn't be easily transcoded to C being Java2k, first of all because it's probabilistic (nearly every built-in has 90% chances of doing what it's supposed to do, and 10% chance of doing something completely different, every function has two different implementations and which one is used is chosen at runtime) to be more in line with common physicalist assumptions about the nature of the universe (there is never absolute security, there is always only probability) and second because it uses base 11 "which is a very good approximation of base 10 for many purposes, including counting up to 9".

    Oh yeah, and it uses numbers to name objects and functions. In fact, "Using numbers as names-of-objects is a lot easier than using functions as integer values, so lets just do the easy thing first. Numbers are, as specified in the introduction, 11-based digits." The only restriction is that numbers-as-names must be divisible by 7. Oh, and the 10th elevengit is the space, so "19+1" computes to "1 ".

  • HwAoRrDk (unregistered)

    A further WTF...

    I note that neither the filename string in the $X42342234 variable nor the call to fopen() specifies a particular path to the file to be opened (which I assume contains the encryption key). Therefore, one can probably assume that the encryption key file(s) are kept within the publicly-accessible web root. Doh!

  • (cs) in reply to Kippesoep
    Kippesoep:
    It's PHP.

    Who cares?  That's like seeing a wreck on the side of the freeway and then rolling your eyes and saying, "Of course they wrecked, they drive a Ford".  I think that a WTF programmer will create a WTF no matter what language (s)he uses.
  • (cs) in reply to Monday
    And now you can!


           #! /usr/local/bin/perl -w
            use Lingua::Romana::Perligata;
            maximum inquementum tum biguttam egresso scribe.
            meo maximo vestibulo perlegamentum da.
            da duo tum maximum conscribementa meis listis.
            dum listis decapitamentum damentum nexto
                fac sic
                    nextum tum novumversum scribe egresso.
                    lista sic hoc recidementum nextum cis vannementa da listis.
                cis.
  • (cs) in reply to treefrog

    treefrog:
    Kippesoep:
    It's PHP.

    Who cares?  That's like seeing a wreck on the side of the freeway and then rolling your eyes and saying, "Of course they wrecked, they drive a Ford".  I think that a WTF programmer will create a WTF no matter what language (s)he uses.

    Good observation.  I agree.

    With bad tools or great tools, an artist can make a masterpiece and an idiot can make a mess.

  • (cs) in reply to Nimrand
    Anonymous:

    Hmm...that was exactly my point.  The precaution taken by the programmer to secure his/her code by obfuscating it hasn't helped secure the application at all.  My contention is that programmers do things like this because they have no training about writing secure programs.  If they had such training, they would know that encryption algorithms work because the key is secret, not the code.

    I agree until then all that is needed is to encrypt the programmer and not the program... and stuff...

     

  • (cs) in reply to Nimrand
    Anonymous:

    Hmm...that was exactly my point.  The precaution taken by the programmer to secure his/her code by obfuscating it hasn't helped secure the application at all.  My contention is that programmers do things like this because they have no training about writing secure programs.  If they had such training, they would know that encryption algorithms work because the key is secret, not the code.

    I agree until then all that is needed is to encrypt the programmer and not the program... and stuff...

     

  • bob (unregistered) in reply to Kippesoep

    >It's PHP.

    And it looks as good as any other PHP code I've seen. I don't see the WTF, personally...

    In fact, from a distance, it looks like pretty readable PERL...

  • (cs) in reply to treefrog

    treefrog:
    Kippesoep:
    It's PHP.

    Who cares?  That's like seeing a wreck on the side of the freeway and then rolling your eyes and saying, "Of course they wrecked, they drive a Ford".  I think that a WTF programmer will create a WTF no matter what language (s)he uses.

    Still I prefer not to drive a Ford [:D]

  • (cs) in reply to kipthegreat
    kipthegreat:
    masklinn:
    You're not supposed to be, by definition a secure application is still secure even if you can see the code (see OpenSSH, code is open, it's still secure). The only breach of security that can compromise a secure application is (direct) access to the database or (direct/physical) access to the server or server farm hosting the application, and compromission of the machine via (for example) OS flaws.

    If someone had access to view your PHP source files, they have at least as much access as the webserver has (which is usually not very much).


    Um... no? Unless you're insane enough to keep your only copy of the source code on the production system, somone can have access to your source code on a test system, through the CVS repository, by looking at a backup... lots of possibilities to see the code without having any kind of access to the production environment.

  • Josh (unregistered)

    Even funnier that he tried to write maintainable obfuscated encrypted code.  If you're writing obfuscated code anyway, you ought to do it like this:

    function H88493247329($B89424235)
    {
    global $a,$e,$m,$H;
      $MMNVUD884 = substr(
    fread($KJD234 = fopen($H . "." . $m . "-" . $a,"r"),
    filesize($H . "." . $m . "-" . $a)),
    0,mcrypt_enc_get_key_size($MQUFI3 = mcrypt_module_open('','',''')));
      if (mcrypt_generic_init($MQUFI3,$MMNVUD884,mcrypt_create_iv(mcrypt_enc_get_iv_size($MQUFI3), MCRYPT_RAND))!=-1)
    {
    $KIDO83R4234FFS = mcrypt_generic($MQUFI3,$B89424235);
    mcrypt_generic_deinit($MQUFI3);
    mcrypt_module_close($MQUFI3);
    }
      fclose($KJD234);
    return $KIDO83R4234FFS;
    }

  • (cs) in reply to jannes
    jannes:

    treefrog:
    Kippesoep:
    It's PHP.

    Who cares?  That's like seeing a wreck on the side of the freeway and then rolling your eyes and saying, "Of course they wrecked, they drive a Ford".  I think that a WTF programmer will create a WTF no matter what language (s)he uses.

    Still I prefer not to drive a Ford [:D]



    I agree.  If they were driving a Toyota they'd be fine now. [:)]
  • Anonymous (unregistered) in reply to daniel
    Anonymous:

    You can use LISP, no obfuscation needed...

     

    (do-p you (by (mean) obfuscated))

  • (cs)
    Alex Papadimoulis:

     The search led him to H88493247329(), the method responsible for encrypting customer data.



    Well, it could have been worse - he could have been using encraption instead.

    http://www.thedailywtf.com/forums/39689/ShowPost.aspx

  • shaun merifield (unregistered)

    What a complete boob. Anybody who would subscribe to that kind of logic should have the fingers of both hands slammed in a kitchen drawer, thereby stopping 'turd code' like this.

  • (cs) in reply to Anonymous
    Anonymous:
    (do-p you (by (mean) obfuscated))

    (with-obfuscation
      (do-stuff-here))
  • Markus (unregistered) in reply to ParkinT
    ParkinT:

    With bad tools or great tools, an artist can make a masterpiece and an idiot can make a mess.

    But I noticed that there's a strong correlation between some tools and the idiot/artist property.

  • (cs) in reply to Markus
    Anonymous:
    ParkinT:

    With bad tools or great tools, an artist can make a masterpiece and an idiot can make a mess.

    But I noticed that there's a strong correlation between some tools and the idiot/artist property.



    I still disagree that something becomes a WTF simply because it's written in PHP.  The tool/language used to create enterprise WTF-ups are irrelevant.  While I do agree that PHP is flexible enough to allow WTF's to crop up more frequently...it doesn't mean that java programmers haven't attempted to create WTF code only to find it doesn't compile and are able to escape the potential of showing up here.  PHP just makes it easier to ignore WTFs (and later have them exposed) because you can turn off errors and warnings in the .ini file and pretend that nothing went wrong.

  • Zygo Blaxell (unregistered)

    Am I the only one reminded of the Monty Python sketch "How Not To Be Seen"...

    "Here, we have Mr. Encryption Function.  Encryption Function, would you please stand up?"

    [pause]

    "Mr. Function has learned the first rule of not being seen--not to stand up; however, Mr. Function has chosen an implementation with an obvious control flow that doesn't hide anything at all from the casual code inspector."

    [sound of large explosion complete with smoky fireball and scream of violent death]

  • (cs) in reply to HwAoRrDk
    Anonymous:

    A further WTF...

    I note that neither the filename string in the $X42342234 variable nor the call to fopen() specifies a particular path to the file to be opened (which I assume contains the encryption key). Therefore, one can probably assume that the encryption key file(s) are kept within the publicly-accessible web root. Doh!



    The encryptionkey.txt is next to passwords.txt in his web root.
  • (cs) in reply to kipthegreat
    kipthegreat:
    jannes:

    treefrog:
    Kippesoep:
    It's PHP.

    Who cares?  That's like seeing a wreck on the side of the freeway and then rolling your eyes and saying, "Of course they wrecked, they drive a Ford".  I think that a WTF programmer will create a WTF no matter what language (s)he uses.

    Still I prefer not to drive a Ford [:D]



    I agree.  If they were driving a Toyota they'd be fine now. [:)]


    Maybe they should have just caught a cab.
  • (cs)
    perl -e "foreach $ch (split(',','66,82,73,76,76,65,78,84,33')) { print chr($ch); }"
  • (cs) in reply to masklinn
    masklinn:

    Actually you would, the only languages that don't really need encryption are esoteric languages (Moo, Chef, Whitespace, Java2k) and most of them can be translated to more common languages (Java2k can't, but it's quite tough to use to code anything)



    Amazing, there's actually someone else out there who's heard of MOO programming.  I was starting to think that all of the core code must have been delivered by pixies.

    Actually, MOO's got a significant advantage when it comes to obfuscating, comments are so annoying to insert that you're lucky if you see one line for every 30 or so lines of code, and that one's usually "Changed on 04/20/1998 by Soandso."  One less step in the process.

    -FunnyMan
  • Miral (unregistered) in reply to FunnyMan

    I like to think that's because most MOO code is inherently readable, so that it doesn't need comments.  And they're not all that hard to insert anyway.

    As for obfuscation: I've actually obfuscated the PHP code that contains my database passwords.  The code is outside the webroot and obfuscated, but I have no illusions that it's actually secure.  If someone managed to get access to the source they'd be able to decipher it fairly easily.

    But what can you do?  The webserver needs to be able to access the passwords in plaintext, therefore you have to have them readable in plain text somewhere.  The best you can do is to obfuscate it a bit and not include the "admin" password, only the general read/write password.  (Unfortunately I can't limit it to a read-only password.  Bah.)

  • (cs) in reply to Miral

    Anonymous:
    I like to think that's because most MOO code is inherently readable, so that it doesn't need comments.  And they're not all that hard to insert anyway.

    As for obfuscation: I've actually obfuscated the PHP code that contains my database passwords.  The code is outside the webroot and obfuscated, but I have no illusions that it's actually secure.  If someone managed to get access to the source they'd be able to decipher it fairly easily.

    But what can you do?  The webserver needs to be able to access the passwords in plaintext, therefore you have to have them readable in plain text somewhere.  The best you can do is to obfuscate it a bit and not include the "admin" password, only the general read/write password.  (Unfortunately I can't limit it to a read-only password.  Bah.)

    That is a battle that can never be won.  You don't even need to de-obfuscate the code to get the passwords.  Just replace the database client library with a set of similar routines that log connection attempts.  If you don't trust the admin of the box, you are screwed.  The problem you are having is the same one the RIAA is having with DRM.  If you give someone the decryption engine and the key, how do you keep them from decrypting stuff?

    It's not even really worth trying.  Any effort will be useless against the people who really matter and will just take up some of your time and make maintenance a pain.  Obuscated functions also attract attention.  Obviously you are hiding something valuable....

  • Nick (unregistered) in reply to frosty
    frosty:
    merreborn:
    frosty:
    Umm... aren't you f***ed if the hacker gets as far as being able to look at your source code anyway?


    This is PHP, btw.


    Yeah... definately not C.

    Even with PHP the hacker shouldn't have access to the source, right?  I mean, it's not like JavaScript where it's sent to the browser.  It stays on the server side to handle the posts/gets and to generate the html... right?


    Depends on who the hacker is.  If he is a disgruntled employee (maybe he got fed up trying to maintain code like this), he may well have seen the code during development.  You should never rely on the fact that the user does not have access to your source code for your application's security.

    In fact, this makes you much less secure as its easy for someone to put in a backdoor to the system that would allow them to hack into it at a later date.
  • Nick (unregistered) in reply to treefrog
    treefrog:
    Kippesoep:
    It's PHP.

    Who cares?  That's like seeing a wreck on the side of the freeway and then rolling your eyes and saying, "Of course they wrecked, they drive a Ford".  I think that a WTF programmer will create a WTF no matter what language (s)he uses.


    I believe he was responding to someone thinking that the heart of this WTF is that since C is compiled, the code is not visible anyways...
  • (cs) in reply to FunnyMan
    Reply to an Existing Message
    [image] masklinn wrote:

    Actually you would, the only languages that don't really need encryption are esoteric languages (Moo, Chef, Whitespace, Java2k) and most of them can be translated to more common languages (Java2k can't, but it's quite tough to use to code anything)



    Amazing, there's actually someone else out there who's heard of MOO programming.  I was starting to think that all of the core code must have been delivered by pixies.

    Actually, MOO's got a significant advantage when it comes to obfuscating, comments are so annoying to insert that you're lucky if you see one line for every 30 or so lines of code, and that one's usually "Changed on 04/20/1998 by Soandso."  One less step in the process.

    -FunnyMan

    I love MOOSE too!  It's so versatile.  Especially in the kitchen! [8-)]

  • (cs) in reply to Iago

    http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html

    Old and well-known, but still damn funny.

    (I won't even try to make the URL into a link.  I fear this board software like none other.)


    I think Alex gets some kind of perverse pleasure from hearing all the complaints about the forum software, that or he is trying to be enterprisy with it. ^o)

  • (cs) in reply to ntroutman

    F***ing forum software, how the heck do you put in the emoticons?
    ^o)

  • A simple simple man (unregistered) in reply to John Hensley

    (
        (
              (
                   (
                       (cadddar(cdr(caaadr(1,2,3,4,5,I don't agree))))
                   )
              )
        )
    )

  • (cs) in reply to frosty
    frosty:
    merreborn:
    frosty:
    Umm... aren't you f***ed if the hacker gets as far as being able to look at your source code anyway?


    This is PHP, btw.


    Yeah... definately not C.

    Even with PHP the hacker shouldn't have access to the source, right?  I mean, it's not like JavaScript where it's sent to the browser.  It stays on the server side to handle the posts/gets and to generate the html... right?


    Are you sure? You obviously haven't heard about <a HREF="/forums/68115/ShowPost.aspx">Client Side PHP</a>
  • (cs) in reply to Miral
    Anonymous:
    I like to think that's because most MOO code is inherently readable, so that it doesn't need comments.  And they're not all that hard to insert anyway.


    I tend to agree, at least in part.  If nothing else, you really learn the value of descriptive variable names.  Still, I've seen some stuff that badly needed ccommenting, but either people forget or they just can't be bothered.

    -FM
  • Pete (unregistered) in reply to Not Telling
    Not Telling:


    I used to work on a J2SE implementation. I inserted some code, written using unicode escapes, that would execute if a specific condition was met.

    So I trust, on reflection, that we trust you?

    :-)

    Pete

  • SeHE (unregistered) in reply to rbriem
    rbriem:

    Iago:
    Anonymous:
    I always code in Latin....cause seriously, who still knows Latin?

    http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html

    Old and well-known, but still damn funny.

    (I won't even try to make the URL into a link.  I fear this board software like none other.)

    Great link!

    Now how do you say, "Go ahead - fire me" in Latin?

    "Procede - me dimitte"
  • SeHE (unregistered) in reply to TomCo
    TomCo:
    perl -e "foreach $ch (split(',','66,82,73,76,76,65,78,84,33')) { print chr($ch); }"

    Learn to spell:

    perl -e "foreach $ch (split(',','66,82,73,76,76,<font color="#ff0000">73,</font>65,78,84,33')) { print chr($ch); }"
  • SeHE (unregistered) in reply to SeHE

    an apology:

    perl -e foreach  (split(',','0x49,0x20,0x6b,0x6e,0x6f,0x77,0x20,0x6f,0x66,0x20,0x6e,0x6f,0x20,0x66,0x2a,0x63,0x6b,0x69,0x6e,0x67,0x20,0x50,0x61,0x75,0x6c,0x61,0x20,0x6e,0x6f,0x72,0x20,0x61,0x6e,0x79,0x20,0x42,0x72,0x69,0x6c,0x6c,0x61,0x6e,0x74,0x20,0x6f,0x6e,0x65,0x73,0x20,0x3a,0x29,0x0a')) { print chr(eval()); }

Leave a comment on “Functional Encryption”

Log In or post as a guest

Replying to comment #:

« Return to Article