• Morkl (unregistered) in reply to Jupiter

    Truly amusing (or is that scary?): The fact that my municipality government uses a variation of the same technique to black out names and private parts from public documents.

  • lokey (unregistered) in reply to snoofle
    snoofle:
    steenbergh:
    If there were programming licenses, most of this crap could be prevented in the first place...
    Ever heard of an incompetent doctor? Lawyer? Accountant? Plumber?

    All have licenses. Government issued paperwork does not guarantee competence.

    But the wieners that went to school for years to learn how to code badly want something to hide behind, as in "how dare you criticize my code, you'r not even licensed!"

  • fletch (unregistered)

    Ugh, the folks calling this a backdoor and saying code can get evaluated: FALSE.

    The base64_decode() call returns a string. THAT STRING is what's getting evaluated, NOT the string returned by file_get_contents():

    <pre>eval(base64_decode('QCRlbmFi ... aXQ7'));</pre>
becomes:

<pre>eval('@$enabled = trim(file_get_contents("http://initrode-global.com/rg_initrode.txt")); if(!$enabled) exit;');</pre>

    which behaves the same as the raw code:

    @$enabled = trim(file_get_contents("http://initrode-global.com/rg_initrode.txt")); if(!$enabled) exit;

    The result of the eval() can only exit() or not. Putting some code instead of the zero or one would just ... end up putting the code string (NOT evaluated results) into $enabled. Since a non-empty string would be the same as boolean true or the "1" condition, putting code on that remote website would accomplish exactly nothing.

    Sorry guys, this is not a backdoor, it's just a simple obfuscated killswitch.

  • fletch (unregistered)

    Heh and after I wrote my reply I realized how trivial it would be to actually make this into a backdoor.

    In order to work as some folks in this thread suggest, a second eval() call needs to be made inside the base64 encoded code.

    The outer eval(base64_decode()) combo is just a way to put obfuscated code into the source, that's it.

    But if you replaced the trim() call that's inside the evaluated code with another eval(), it would then act as a backdoor that could work as described by certain people in this thread. The value loaded from the remote website would be evaluated. As I said though, the code as given does not do that.

    Also BTW OT but: DRUPAL IS NOT FULL OF SECURITY HOLES. It's actually a vibrantly developed piece of software with a ton of active devs. The update system in recent versions makes it trivial to update module versions to patch holes as they appear, just a few clicks. Now, custom module developers OTOH could certainly write software full of holes that cannot be easily patched. But that is true of ALL environments. For example, Drupal has a loverly built-in parameter based query system. But that does not stop a naieve developer from concat-ing strings from CGI variables into the query directly.

  • Dieter H (unregistered) in reply to steenbergh

    Given the standards of university programming education, such a programming license would almost spell "bad programmer".

  • pharmacepticacom (unregistered)

    prescription tadalafil online https://pharmaceptica.com/

  • cheap cialis (unregistered)

    https://cialiswithdapoxetine.com/ cialis price

  • culccjni (unregistered)
    Comment held for moderation.
  • odznervq (unregistered)
    Comment held for moderation.
  • Jimmyanten (unregistered)
    Comment held for moderation.

Leave a comment on “The Jammed Killswitch”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article