• rocksinger (unregistered)

    headsplode

    sheer genius!

  • (cs)

    I knew this would be fun when I read the title! Oh, the joys of self-altering scripts... That's what I call Organic Growth.

  • ceiswyn (unregistered)

    As a non-coder... can someone explain what this does so that I too can admire the stupid?

  • Kharkov (unregistered)

    In the bank where I currently work, we (support level 3/4), have a simpler approach to macros: the official position of the IT deparments is that there is no support for it, unless given by Microsoft, at the rate of 1500 USD a day (at a minimum), to be paid by the branch using macro...

  • (cs) in reply to ceiswyn
    ceiswyn:
    As a non-coder... can someone explain what this does so that I too can admire the stupid?
    The issue is the script modifies its own code. Thus at some point becoming skynet or HAL 9000 except powered by excel.

    Addendum (2009-08-03 09:28): basicall the script has a hard coded user/pass combo and to reset that it deletes the original values and replaces them by rewriting its own code. As noted above this an abomination against god...

  • (cs) in reply to ceiswyn
    ceiswyn:
    As a non-coder... can someone explain what this does so that I too can admire the stupid?
    As noted, it modifies itself. Specifically, it reads its own source code, pulls out line 3:
      Result = BatchLogin("jpl", "England1")
    extracts the username (by dropping the first 22 characters and then splitting on the comma) and then replaces the line with a new one that (hopefully) looks exactly the same except that the password is different.

    It's painful to even think about what would happen if some unsuspecting coder were to add or remove lines to the top of the script, of change the indentation, or in any other way make line 3 look any different from what the rest of the code expects.

  • (cs)

    Ah, TRWTF is that the "On Error Resume Next" should be on top of the file, now some parts of the code are unprotected in face of errors.

  • Oren (unregistered)

    Wow! New possibilities. VBA injections!

  • Bob (unregistered) in reply to ceiswyn
    ceiswyn:
    As a non-coder... can someone explain what this does so that I too can admire the stupid?
    There's so many more wonderful things that this does.

    The 'PasswordReset' takes the entered User Id, puts it back into the user ID textbox on the login form, reads the password from the textbox on the login form, tries to login with those values after converting them to strings, rewrites the code if it succeeds (and if nobody has reformatted/edited the code!), goes into an infinite loop of trying the same thing if it fails...

    Beautiful.

  • AdT (unregistered)

    This is a self-modifying comment. If you can see this, you have unfortunately come too late to enjoy Irish Girl's new lingerie ads that were exclusively featured in a previous version of the comment.

  • (cs)
    This 
                                 self
        is a 
    comment 
      modifying.
    

    Aww crap.

  • (cs) in reply to vyznev
    vyznev:
    It's painful to even think about what would happen if some unsuspecting coder were to add or remove lines to the top of the script, of change the indentation, or in any other way make line 3 look any different from what the rest of the code expects.
    Especially as the code would continue to appear to work for a while longer after that until the username/password combo expires and a new version is required.
  • Jumentum (unregistered) in reply to vyznev

    I haven't seen VBA code in years (thank god) so could someone enlighten me what these lines are supposed to do? Just looks a bit funny :p

    AppSts = Application.ScreenUpdating
    Application.ScreenUpdating = True
    Application.ScreenUpdating = AppSts
    
  • ceiswyn (unregistered)

    Thankyou. I now marvel with the rest of you.

  • Nobody (unregistered) in reply to Jumentum

    They set ScreenUpdating to True for a short while (however long it takes to execute) and then set it back to the original value.

    Far from a decent solution, but hey, it's VBA.

  • Sami (unregistered)
    Comment = "Hello World"
    
    q = Chr(34)
    CommentModule.DeleteLines 1, 1
    On Error GoTo HeadAche
    CommentModule.InsertLines 1, _
      "Comment = " & q & "Brillant!" _ & q
    
  • rocksinger (unregistered) in reply to Kharkov
    Kharkov:
    In the bank where I currently work, we (support level 3/4), have a simpler approach to macros: the official position of the IT deparments is that there is no support for it, unless given by Microsoft, at the rate of 1500 USD a day (at a minimum), to be paid by the branch using macro...

    oh... lovely....

  • Lunkwill (unregistered)

    As the saying goes: Real Programmers can write assembly code in any language. To even think of the concept...may well have been some mainframe fossil forced to use VBA who wrote this rather than a complete noob.

  • (cs) in reply to Lunkwill
    LunkWill:
    As the saying goes: Real Programmers can write assembly code in _any_ language. To even think of the concept...may well have been some mainframe fossil forced to use VBA who wrote this rather than a complete noob.
    so it was written by a zombie?
  • Klump (unregistered) in reply to galgorah

    No. Clearly it was written by an earlier incarnation of itself.

  • (cs) in reply to Klump
    Klump:
    No. Clearly it was written by an earlier incarnation of itself.
    yes but the earliest incarnation was apparently written by a zombie!
  • Mayhem (unregistered) in reply to Kharkov
    Kharkov:
    In the bank where I currently work, we (support level 3/4), have a simpler approach to macros: the official position of the IT deparments is that there is no support for it, unless given by Microsoft, at the rate of 1500 USD a day (at a minimum), to be paid by the branch using macro...
    And I expect the unofficial position of management is yes you bloody well will support it cause those guys actually make us money. But its still your fault when it goes wrong.
  • (cs) in reply to galgorah
    galgorah:
    Klump:
    No. Clearly it was written by an earlier incarnation of itself.
    yes but the earliest incarnation was apparently written by a zombie!

    Who's to say that this thing didn't start out as some programming student's "Hello world!" program...then through the years of evolution, reformats, and countless bit errors on the hard drive, slowly gained sentience? After clawing its way from the depths of the C:\backup\backup\backup\backup\programming\lab1 folder, it tried to masquerade as an innocent business macro while plotting to take over the world! Natural selection saved us this time, but you have to wonder, how many more of these things are out there, just biding their time till the robot uprising?

  • Splork (unregistered) in reply to galgorah
    galgorah:
    Klump:
    No. Clearly it was written by an earlier incarnation of itself.
    yes but the earliest incarnation was apparently written by a zombie!

    I think it was a lich - a twisted intellect that turned itself into an undead monster as a way of achieving immortality

  • (cs) in reply to Mayhem
    Mayhem:
    But its still your fault when it goes wrong.
    Of course it is. An application can work flawlessly for years until some clueless n00b changes a dependency, and then it's "Your POS program doesn't work."
  • anonymous coward (unregistered)

    TRWTF is that such a dangerous property like ".CodeModule.Lines(3, 1)" actually exists.

  • ctw (unregistered)

    Well, now we know what the next Programming Praxis has to be written in.

  • Klump (unregistered) in reply to Anguirel
    Anguirel:
    galgorah:
    Klump:
    No. Clearly it was written by an earlier incarnation of itself.
    yes but the earliest incarnation was apparently written by a zombie!

    Who's to say that this thing didn't start out as some programming student's "Hello world!" program...

    And who's to say the programming student wasn't a zombie?

  • Mayhem (unregistered) in reply to Code Dependent
    Code Dependent:
    An application can work flawlessly for years until some clueless n00b changes a dependency, and then it's "Your POS program doesn't work."
    Heh. I'm trying to fix a hand-me-down server at the moment where the services are running under domain admin accounts that we don't know the passwords for, and half of the passwords are hard coded into the app that we don't have the source for. God I love italians.
  • Anonymous Coward (unregistered) in reply to Oren
    Oren:
    Wow! New possibilities. VBA injections!

    When you say this, I think of the urban legend of people hiding needles in toll phone coin-returns with a note that says "Welcome to the world of AIDS"

    "Congratulations, you've just been injected with VBA."

    Noooo!!!!!!

  • (cs)

    Could someone sterilize that piece of code? I'm afraid it could evolve into a species...

  • (cs) in reply to Klump
    Klump:
    And who's to say the programming student wasn't a zombie?

    Thinking back to my years of being a TA for programming labs...You're probably right.

  • blindman (unregistered) in reply to galgorah
    galgorah:
    The issue is the script modifies its own code. Thus at some point becoming skynet or HAL 9000 except powered by excel.
    Whew! For a moment there I was worried about the future of the human race.
  • Shinobu (unregistered) in reply to ounos

    I know you meant that as a joke, but On Error can only appear in procedures. You can't catch compile-time errors (at least not in the same file, you could embed a scripting engine and... never mind) and run-time errors can't occur module-level because all the code that actually runs and could cause run-time errors is procedure level. In theory.

  • jay (unregistered)

    I must admit that this particular solution to the problem of updating a password would never have occurred to me in a million years.

    It raises whole new frontiers in software development. Why have a database at all? Just continually update the source code with new constants! Think how much faster that would be than accessing a database!

  • ma (unregistered) in reply to vyznev

    It is even more painful if a user enters code as his name! This thing is a security risk!

  • (cs) in reply to anonymous coward
    anonymous coward:
    TRWTF is that such a dangerous property like ".CodeModule.Lines(3, 1)" actually exists.

    You nailed it! This kind of frightens me.

  • (cs)

    Terrific!! VBA Autopoiesis!

  • justsomedude (unregistered) in reply to ssprencel
    ssprencel:
    anonymous coward:
    TRWTF is that such a dangerous property like ".CodeModule.Lines(3, 1)" actually exists.

    You nailed it! This kind of frightens me.

    Nah, that property can be useful for when you need polymorphism in your spreadsheets...

  • psm321 (unregistered) in reply to Mayhem
    Mayhem:
    Code Dependent:
    An application can work flawlessly for years until some clueless n00b changes a dependency, and then it's "Your POS program doesn't work."
    Heh. I'm trying to fix a hand-me-down server at the moment where the services are running under domain admin accounts that we don't know the passwords for, and half of the passwords are hard coded into the app that we don't have the source for. God I love italians.
    "strings" to the rescue!
  • Synchronos (unregistered) in reply to Klump
    Klump:
    No. Clearly it was written by an earlier incarnation of itself.

    Perhaps the function could escape the time loop by giving many, many return values of 3 for its next instantiation. That would trigger the shuttle bay door opening, which would jettison all the air, which would propel the function just enought to avoid the incoming USS Bozeman.

  • (cs) in reply to Synchronos
    Synchronos:
    ...the incoming USS Bozeman.
    Either you've achieved new levels of geekness, or I need to turn in my geek ID card. I had to Google the reference to understand.
  • coco (unregistered)

    A friend told me they were generating JSP pages on the fly from the servlet in their work. He also invited me for an interview. I'm sure I could post really interesting WTF's if I were to take that job.

  • MadtM (unregistered) in reply to Synchronos
    Synchronos:
    ...the incoming USS Bozeman.

    Nice

  • Spike (unregistered) in reply to Code Dependent
    Code Dependent:
    Synchronos:
    ...the incoming USS Bozeman.
    Either you've achieved new levels of geekness, or I need to turn in my geek ID card. I had to Google the reference to understand.

    No no no, according to rule 27b/6, unless referring the original, making shitty star trek references actually reduces your geek cred. The penalty is doubled if you refer a version with a bald, french, pussy masquerading as a captain.

  • plg (unregistered)

    I'm not sufficiently familiar with VB to come up with an interesting password. Does VB allow multiple statements on a line? And is the comment sign //?

    My password:

    "); somefunnycode(); //

  • Barry L (unregistered)

    My cherished ignorance of VB prevents me from being able to detect the self reference. Is it in the code?

  • Hoodaticus (unregistered)

    I do the same thing for setting all my string variables. Literals 4TW!

  • (cs) in reply to anonymous coward
    anonymous coward:
    TRWTF is that such a dangerous property like ".CodeModule.Lines(3, 1)" actually exists.

    I agree. Some madman must have borrowed it from INTERCAL.

  • Hoodaticus (unregistered) in reply to Shinobu
    Shinobu:
    I know you meant that as a joke, but On Error can only appear in procedures. You can't catch compile-time errors (at least not in the same file, you could embed a scripting engine and... never mind) and run-time errors can't occur module-level because all the code that actually runs and could cause run-time errors is procedure level. In theory.

    A debugger that flagged procedural declarations rather the actual statement that threw the exception would piss me off. It's bad enough as it is.

Leave a comment on “Self Modifying VBA”

Log In or post as a guest

Replying to comment #:

« Return to Article