While not specifically related to Frida's use of V8, I was reading this Frida release page and noticed it made the following reference:
Short of writing the whole agent in C, one could go ahead and build a
native library, and load it using Module.load(). This works but means
it has to be compiled for every single architecture, deployed to the
target, etc.
The comment by Ole alludes to this being possible, though I can't find any references other than the NodeJS C++ Addons features that are, of course, specific to NodeJS (though NodeJS does use V8).
tl;dr
How does one load a generic object such that all of its exported functions are callable from Javascript? Is this possible?
I was misinterpreting the context of the comment in the original link, it seems. I was under the impression that Module.load was a v8-ism, while it in fact appears to be a Frida-API.
https://frida.re/docs/javascript-api/#module
I figured this out about the time I was writing code to use Module.getExportByName to just pass the addresses of dlopen and dlsym to the entry of my CModule code.
Related
Can you please tell me if there are pre-compiled binaries of the v8 library somewhere?
Because building from source is just some kind of hell.
V8 developer here. We do not distribute any official binaries.
Building from source should be quite straightforward using the instructions at https://v8.dev/docs/source-code and https://v8.dev/docs/build-gn.
That said, guessing from your other question, you may want to look elsewhere right away, as V8 is not going to help you for that use case: it's a pure ECMAScript engine, so it doesn't know anything about the DOM or related browser functionality. For example, if it saw document.createElement(...), it'd say ReferenceError: document is not defined.
https://webassembly.studio/ allows inspection of WebAssembly (WASM) files and the corresponding SpiderMonkey-generated x86 code. I'd like to similarly inspect instructions generated by V8's WASM compilers (Liftoff and TurboFan).
I'm entirely unfamiliar with V8's codebase/API (I compiled & linked it and followed some tutorials, though). There seems to be a v8::CompiledWasmModule class available, but it does not seem to expose access to generated x86/x64 instructions by either Liftoff or TurboFan.
WebAssembly - adding a new opcode describes the process of adding a WASM opcode to V8. Seemingly appropriate functions for WASM compilation/execution are available in the mentioned classes. Though, these seem rather deeply layered within the V8 codebase and would be difficult to access were I to link V8 as a library. Also, I'm unsure if this corresponds to Liftoff or TurboFan.
Could anybody familiar with the V8 codebase give me some pointers as to how I can access Liftoff and/or TurboFan's WebAssembly compilation module, as to obtain x86/x64 code?
To inspect generated code, you can run the d8 shell with the --print-wasm-code flag. You'll need either a debug build, or a release build with the v8_enable_disassembler = true GN arg.
There's no existing way to retrieve generated code via V8's API; so if that's what you want, then you'd have to add it. Keep in mind that V8 is not designed to be a standalone compiler, which means generated code assumes that it's going to run "inside V8", so if you wanted to use it for anything else, you'd have to make significant modifications.
I have asked this question on linux, but now I need the same info on macos... The question is (adapted to macos):
I am trying to create a shared library, libbar.dylib, that embeds a commercial static library (licensing is fine). The commercial library has 4 versions: libfoo-seq.a, libfoo-mt.a, libfoo-seq.dylib, and libfoo-mt.dylib (they all provide the same symbols, just the code is sequential/multi-threaded, and the lib is static/shared). Of these four I want my code always to use the sequential foo library, so when I create libbar.dylib I link together my object files and libfoo-seq.a.
The problem is that the users of my library may have already pulled in libfoo-mt.dylib by the time they pull in my libbar.dylib, thus all symbols from libfoo are already present by the time libbar.dylib is read in, so my calls to the functions in foo are resolved to the multithreaded version. At least I think this is happening. Is there any way to double check?
If this is really what is happening, I wonder how can I resolve this issue? What kind of magic flags do I need to use when I compile to create my object files and when I link my object files with libfoo-seq.a to create libbar.dylib?
I'm trying to build an old application that depends on fftw. It was written against fftw2 and I am currently on fftw3 (specifically 3.3.8). It fails to link because of undefined reference to fftw_create_plan and fftw_one. Indeed, my libfftw does not have those functions anymore; the following returns nothing:
readelf -s /usr/lib/libfftw3.so | grep 'fftw_create_plan\|fftw_one'
It looks like the api has changed significantly since the code was written. Is there a compatibility layer I can use or should I just go learn fftw3's new interface?
You cannot link an FFTW2 code against FFTW3 libraries, as you are coming to realize yourself. There is also no complete interface between the two, cause the apis are really not compatible.
Having said that, you may of course link your code against FFTW2 libraries. You still can obtain them. Why is that not an option?
My project is using ACE library, and need link another library libsdk.so, it's using another version ACE library.
The link order like : ...-lMyAce -lsdk -lAnotherAce
When application running, libsdk.so called method in MyAce(I checked the core dump), and the application crash.
If I change link order to: ...-lsdk -lAnotherAce -lMyAce
My code called method in AnotherAce, it's also crash.
If I only link my ACE, it's crash. There are some link error if only link AnotherAce.
Let the libsdk.so call its ACE library, and my code call my ACE library.
How can I resolve the problem?
The Solaris linker has an option that may help, though really redesigning your application to not need two sets of libraries with the same names in the same program
is going to be the best solution.
Direct Bindings record in each library or program which library it found a symbol in, so if libsdk.so is built with -B direct -lAnotherAce, it will record each of its references go to AnotherAce, not MyAce. You'd then link your code with -B direct -lsdk -lMyAce (do not include -lAnotherAce, as the libsdk dependencies take care of that), and your code would record that it's calls to to MyAce.