Yearly Archives: 2022

Inserting data into other processes’ address space, part 1a

Posted on by

I never thought I will write the part 1a of my old post, but here it is.

As usual, I have not explored the below topic in-depth, but have certainly noticed the opportunities and since this is how many interesting developments start, I guess it is still worth … talking…

How do we copy data between processes?

In my old post I have listed a number of inter-process data exchange ideas, but I missed the one that I believe is the most important — at least in 2022 — the non-native stuff. And by that, I mean all these proprietary mechanisms of data exchange that have been developed over the years by vendors different than Microsoft. Many, of course, utilizing the core components of Windows OS, and the very same inter-process communication and cross-process access API functions. Being the ‘genuine’ software and all that, I bet it had to somehow pop up on the radar, and the be filtered out, with time by the likes of AV, EDR, and any other ‘watchmen’… cuz it’s genuine. It’s a stretch, of course, but to their credit, security solutions are getting better and better at detecting any sort of trickery…

With that in mind I started poking around DLLs of known vendors.

I soon discovered a DLL from NVidia (NvIFR.dll) that offers a particular set of exported functions:

  • NvIFR_ConnectToCrossProcessSharedSurfaceEXT
  • NvIFR_CopyFromCrossProcessSharedSurfaceEXT
  • NvIFR_CopyFromSharedSurfaceEXT
  • NvIFR_CopyToCrossProcessSharedSurfaceEXT
  • NvIFR_CopyToSharedSurfaceEXT
  • NvIFR_Create
  • NvIFR_CreateCrossProcessSharedSurfaceEXT
  • NvIFR_CreateEx
  • NvIFR_CreateSharedSurfaceEXT
  • NvIFR_DestroyCrossProcessSharedSurfaceEXT
  • NvIFR_DestroySharedSurfaceEXT
  • NvIFR_GetSDKVersion

hmmm Cross-Process, Shared, and Connect To, and Copy … that certainly sounds interesting!

I don’t have access to any native Nvidia setup, and I don’t play games, so it’s hard to test what these functions really do :(. Quick google for NvIFR_ConnectToCrossProcessSharedSurfaceEXT brought only this interesting reddit conversation.

Poking around the available code, we can speculate that Cross-process Surface interface seems to be accessible via this pipe:

\.\pipe\NVIFR_CPSS_%lld

After you write “[\x7F” to it, you can read a buffer of 2136 bytes (in the DLL version I looked at). The buffer we can then read will contain a name of the shared section we can now open, map, and … hopefully write to. The analysis of the code that follows is not straightforward, there are other DLLs being loaded, APIs resolved, and the complexities encountered would really benefit from ‘live’ analysis, but… c’est la vie.

And this is where this blurb ends. I know, I know, it’s not much, but imagine the possibilities. We can find more similar pieces of code, legitimate, genuine software, and cross-process data exchange snippets present inside these signed DLLs or executables… we may as well come up with many new ways of bypassing security solutions that might have not been possible in the past…

Adobe: JSX and JSXBIN files

Posted on by

I wrote about older Adobe scripting before. I recently discovered that Adobe products support scripting using so-called ExtendScript language with code being stored either in a source-level JSX file, or its binary equivalent – JSXBIN (it’s actually considered legacy at this stage). Add these file extensions to your watch list.

The documentation [PDF warning] suggests that some security precautions are in place, and:

1.5 Activating full scripting features
The default is for scripts to not be allowed to write files or send or receive communication over a network. To allow
scripts to write files and communicate over a network, choose Edit > Preferences > General (Windows) or After Effects Preferences > General (Mac OS), and select the Allow Scripts To Write Files And Access Network option.
Any After Effects script that contains an error preventing it from being completed generates an error message from the application. This error message includes information about the nature of the error and the line of the script on which it occurred. The ExtendScript Toolkit (ESTK) debugger can open automatically when the application encounters a script error. This feature is disabled by default so that casual users do not encounter it. To activate this feature, choose Preferences > General, and select Enable JavaScript Debugger

I don’t have access to Adobe products, but these seem to be interesting features.

Defenders should look for:

  • unusual processes spawn by Adobe products
  • invocations of afterfx.exe – scrutinize its command line
  • on macOS: use of AppleScript to invoke DoScript
  • presence/invocation of autostart scripts in Adobe’s Startup and Shutdown folders (the exact location is unknown to me; if you have Adobe products, please let me know and I will update this post)

1.6.5 Running scripts automatically during application startup or shutdown
Within the Scripts folder are two folders called Startup and Shutdown. After Effects runs scripts in these folders
automatically, in alphabetical order, on starting and quitting, respectively

Yes, it’s not a lot to pivot from, but if you have an access to a large number of systems, you may want to keep an eye on process trees spawn around Adobe products. Just to be ahead of time.

Other info: