GithubHelp home page GithubHelp logo

Comments (4)

jbremer avatar jbremer commented on July 18, 2024

Nice that you're trying to make this work :-) My first assumption would be: you looked at the 64-bit .dll, but wscript.exe loads the 32-bit .dll (or the other way around, but I think that's less likely). So in that case - different dll with different PE timestamp etc.

from monitor.

baxitaurus avatar baxitaurus commented on July 18, 2024

Thanks for your reply @jbremer, but actually I did look at the 32-bit version of vbscript.dll because I saw that wscript was loading it (through IDA), so the offsets I used in the hook definition are referred to the 32-bit version 😄

Looking at the insn/flash.yml I saw an interesting comment:

  5 BaseExecMgr_setNative:
  6   module: flash32_20_0_0_228
  7   init: flash_init
  8   offsets:
  9     0x565123f2:
 10       # The BaseExecMgr::setNative method starts at 0x6d7900, however, it has
 11       # to process a flag in order to determine the real native address of the
 12       # method. We just await this computation before fetching it.
 13       offset: 0x705230
 14       stack: 4 8
 15       logging:
 16         - S method_name length, name
 17         - p offset flash_module_offset(stk1)
 18       pre: |
 19           uint32_t length = 0; const char *name;
 20           name = flash_get_method_name(stk0, &length);

I was wondering if something similar should be done with the new definition of the COleScript::Compile function in the version of vbscript.dll i'm working on. Maybe here the start address of the function is not the "real" start address of the function?

Below i screenshot of the function in the DLL used in the article (the hook definition in the master branch refers to it):
old_vbscript

And here you can find "my" version of it:
new_vbscript1
new_vbscript2

from monitor.

jbremer avatar jbremer commented on July 18, 2024

Well, all those screenshots show 64-bit x86, so ;-)

from monitor.

baxitaurus avatar baxitaurus commented on July 18, 2024

Ok, I do have to study the definitions of 32/64 bit and x86/x64, I admit it 😆 Despite of this I'm sure the DLL that wscipt is loading is that one (under C:\Windows\System32), or at least this is what I see with WinDBG:
wscript_vbscript_loading

So the problem here should be not the DLL I'm looking at, am i wrong?

from monitor.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.