Prolem examining JavaScript with SpiderMonkey.pm

Discussion in 'Perl Misc' started by Jan Schmidt, Sep 2, 2008.

  1. Jan Schmidt

    Jan Schmidt Guest

    Hi all,

    I have the feeling I must have missed something in the documentation of
    JavaScript::SpiderMonkey. It seems to execute simple JavaScript fine.
    However, when generic browser elements like "window" or "document" are
    referenced, an error occurs.

    ReferenceError: document is not defined at line 0: (null)

    I can work around this by creating such objects explicitly using the
    object_by_path() method:

    use JavaScript::SpiderMonkey;
    my $js = new JavaScript::SpiderMonkey;
    $js->init();
    my $document = $js->object_by_path("document");
    $js->function_set("write", sub {print "JS> @_\n"}, $document);
    $js->eval(qq{x=5; y=3; document.write(x+y);}) or die "js error: $@\n";

    Although this works, it does not seem practical to me. Is there any
    framework handling creation of objects existing in browsers?

    The following js code also executes fine and prints "axc" as expecyed:
    x=new String("abc"); y = x.replace(/b/, "x"); document.write(y);

    In a browser, however, I could do something like this, which in
    SpiderMonkey would require implementing a self-written replace method
    for the object "window.location.href".
    x=window.location.href.replace(/x/, "y");

    I do not control the JavaScript I am going to inspect with SpiderMonkey.
    So this workaround (implementing methods for used objects in perl) seems
    unfeasible. It would be great if SpiderMonkey would know
    window.location.href exists *and* really can be used as a string with
    all its methods.

    Any suggestions?
    Jan
     
    Jan Schmidt, Sep 2, 2008
    #1
    1. Advertising

  2. Jan Schmidt <> writes:

    > Hi all,
    >
    > I have the feeling I must have missed something in the documentation
    > of JavaScript::SpiderMonkey. It seems to execute simple JavaScript
    > fine. However, when generic browser elements like "window" or
    > "document" are referenced, an error occurs.
    >
    > ReferenceError: document is not defined at line 0: (null)


    That's because JavaScript::SpiderMonkey only interfaces with the
    spidermonkey js interpreter. Which does not implement a browser model,
    just the javascript core.

    > I can work around this by creating such objects explicitly using the
    > object_by_path() method:
    >
    > use JavaScript::SpiderMonkey;
    > my $js = new JavaScript::SpiderMonkey;
    > $js->init();
    > my $document = $js->object_by_path("document");
    > $js->function_set("write", sub {print "JS> @_\n"}, $document);
    > $js->eval(qq{x=5; y=3; document.write(x+y);}) or die "js error: $@\n";
    >
    > Although this works, it does not seem practical to me. Is there any
    > framework handling creation of objects existing in browsers?


    Not as far as I know. You're probably much better off using
    Mozilla::Mechanize, IE::Mechanize or WWW::Selenium, which run the
    javascript code in an actual browser.

    > The following js code also executes fine and prints "axc" as expecyed:
    > x=new String("abc"); y = x.replace(/b/, "x"); document.write(y);


    Yes, that's part of the javscript core / ecmascript specification.

    > In a browser, however, I could do something like this, which in
    > SpiderMonkey would require implementing a self-written replace method
    > for the object "window.location.href".
    > x=window.location.href.replace(/x/, "y");


    I'm not sure what you'd expect that to do in SpiderMonkey, since there
    is no window.

    > I do not control the JavaScript I am going to inspect with
    > SpiderMonkey. So this workaround (implementing methods for used
    > objects in perl) seems unfeasible. It would be great if SpiderMonkey
    > would know window.location.href exists *and* really can be used as a
    > string with all its methods.


    Changing the location of a window in a browser does quite a bit more
    than just changing the properties of a string, so again, I'm not sure
    what you actually want to achieve.

    --
    Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
     
    Joost Diepenmaat, Sep 2, 2008
    #2
    1. Advertising

  3. Jan Schmidt

    John Bokma Guest

    Joost Diepenmaat <> wrote:

    > Jan Schmidt <> writes:


    [..]

    >> I do not control the JavaScript I am going to inspect with
    >> SpiderMonkey. So this workaround (implementing methods for used
    >> objects in perl) seems unfeasible. It would be great if SpiderMonkey
    >> would know window.location.href exists *and* really can be used as a
    >> string with all its methods.

    >
    > Changing the location of a window in a browser does quite a bit more
    > than just changing the properties of a string, so again, I'm not sure
    > what you actually want to achieve.


    Maybe what I did some time ago: running JavaScript in a sandbox to find
    out where it redirects to. Blogspot, Geocities - to name a few - have been
    pestered for quite some time with this (JS). Google [1] and Yahoo don't
    seem to care much about it, but prefer to rely on external sources to
    report this (while they simply could automatically scan for this, or
    better: prevent it in the first place).

    @Jan - if you're doing that, drop me an email, maybe we can work on it
    together :).

    [1] it took me weeks to find someone at Google who was willing to process
    the list I had compiled of thousands (!) of spamvertized blogs doing
    nothing but redirecting to actual sites of spammers.

    --
    John http://johnbokma.com/ - Hacking & Hiking in Mexico

    Perl help in exchange for a gift:
    http://johnbokma.com/perl/help-in-exchange-for-a-gift.html
     
    John Bokma, Sep 2, 2008
    #3
  4. Jan Schmidt

    Jan Schmidt Guest

    Joost Diepenmaat writes:
    >> Although this works, it does not seem practical to me. Is there any
    >> framework handling creation of objects existing in browsers?

    >
    > Not as far as I know. You're probably much better off using
    > Mozilla::Mechanize, IE::Mechanize or WWW::Selenium, which run the
    > javascript code in an actual browser.


    Well, having an X server running to analyze JavaScript is not what I want.

    > I'm not sure what you'd expect that to do in SpiderMonkey, since there
    > is no window.


    Having no browser objects is the point. The aim is analyzing obfuscated
    JavaScript, especially redirects in my case (see [1] and [2], which both
    evaluate to [3]). I did not mention this in the first place, because I
    think a more generic solution would be the best. I would like to see a
    framework having objects like a browser, have them manipulated by random
    JavaScript and then being able to read each property of any object.

    If no such thing exists (really?), I'd think about implementing it. Any
    hints appreciated :)

    Jan


    [1]
    var fhuqy=0;
    var kshl;
    var zdho="dcpzetgicmjknfyixnax";
    var sowxi, gkp,
    vcu="580B0417094A5B1A001F031B1A4615081609141903064D300402063A001F031B1A580E00160A0E0F4A0F1F1904000E060D43180E1E0A180A1D464310101700404A5B5650554358455F5F41474A5A50571A1116194A45484B4A5145180D1410190C505D570C171D165B";
    gkp="";
    for( sowxi=0;sowxi < vcu.length;sowxi+=2){
    kshl = unescape( "%" + vcu.substr( sowxi,2));
    gkp += String.fromCharCode( kshl.charCodeAt(0) ^
    zdho.charCodeAt(fhuqy++) );
    if ( fhuqy >= zdho.length ) fhuqy = 0;
    }
    document.write(gkp);

    [2]
    var gczod=0;
    var
    zqyvc=[{"5":3},{"6":4},{"1":2},{"6":4},{"7":4},{"6":3},{"7":4},{"3":3},{"7":4},{"7":4},{"6":4},{"7":4},{"3":3},{"6":3},{"4":3},{"2":3},{"8":4},{"1":2},{"4":3},{"3":3},{"6":4},{"2":3},{"5":3},{"5":3},{"7":4},{"7":4},{"6":4},{"3":3},{"5":3},{"9":4},{"4":3},{"1":2},{"5":3},{"4":3},{"6":4},{"3":3},{"9":4},{"4":3},{"6":4},{"7":4},{"2":2},{"3":3},{"4":3},{"4":3},{"8":4},{"7":4},{"5":3},{"7":4},{"8":4},{"9":4},{"1":2},{"5":3},{"2":3},{"6":4},{"9":4},{"8":4},{"3":3},{"6":3},{"2":2},{"8":4},{"5":3},{"5":3},{"9":4},{"1":2},{"9":4},{"6":3},{"4":3},{"8":4},{"9":4},{"9":4},{"6":3},{"1":2},{"2":2},{"1":2},{"5":3},{"9":4},{"7":4},{"1":2},{"7":4},{"6":3},{"9":4},{"7":4},{"1":2},{"1":2},{"3":3},{"1":2},{"9":4},{"6":3},{"6":3},{"2":2},{"5":3},{"2":3},{"6":4},{"4":3},{"3":3},{"6":4},{"1":2},{"6":3},{"5":3},{"9":4},{"5":3},{"1":2},{"1":2},{"6":4},{"1":2}];
    var mrpwk=0;
    var
    biah="7891A19F41B4D3615F951E0B383318339181A5D38033AE8166CF1986E07CD75931319CD18F7A694030803B0B184B28BC76E408687EEE833F91DC8350DC026541BD53B8FB63686FC62761123A0ED2A37896E125C1CF1CB01CB1B14C202630E32AA0C9B6814E80E8EE006725E05BCD31039086C075C02C8347C1707165C0D1917691882BCFFC173917D3D0162C55E0F88DA40F15FF1D118CB72B3591C0CF3F8178B5E11D02E9D91B1A70";
    var hpfr="axoiolocnuqzlxcjbonycjbh";
    var vthn="";
    var edzj="hasdzydxmmlybnlvelgbnqd";
    for(cxda in zqyvc){
    var flyvl, thq;
    for(rdynx in zqyvc[cxda]){
    flyvl=parseInt(rdynx,10);
    thq=parseInt(zqyvc[cxda][rdynx],10);
    }
    var amts = "0x"+biah.substr(mrpwk,thq);
    mrpwk=mrpwk+thq;
    vthn +=
    String.fromCharCode((((amts.toString(10)^hpfr.charCodeAt(vgb++)))^edzj.charCodeAt(gczod++))
    >> flyvl);

    if(vgb>=hpfr.length) vgb=0;
    if(gczod>=edzj.length) gczod=0;
    }
    document.write(vthn);

    [3]
    <html><script
    language=JavaScript>window.location.replace("http://196.2.198.241/~rfc/l/")</script></html>
     
    Jan Schmidt, Sep 3, 2008
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mans
    Replies:
    3
    Views:
    425
    Simon Green
    Jan 28, 2004
  2. roN

    html table prolem

    roN, Feb 6, 2006, in forum: HTML
    Replies:
    2
    Views:
    418
    Martin Clark
    Feb 7, 2006
  3. manish
    Replies:
    1
    Views:
    329
    Christopher Benson-Manica
    Apr 2, 2004
  4. Manpreet
    Replies:
    1
    Views:
    1,370
    Victor Bazarov
    Nov 2, 2004
  5. Replies:
    1
    Views:
    118
    Martin Honnen
    Jan 6, 2005
Loading...

Share This Page