For a small project that I'm working on, I need to prevent ".exe" files from running and know the path of the file that was trying to run. Maybe windows API hooking can help me, but I am unsure, and I haven't worked with it.
Can anyone guide me about how I can do it, possibly with API hooking?
Hooking in usermode is going to be unreliable, to really do this you should write a driver and use PsSetCreateProcessNotifyRoutine.
If you only want "safe" applications, use Windows S-mode.
If you want to do this without writing code, use AppLocker.
Related
I've been going through the windows documentation for the Dism API with the goal of writing an exe in C++ (or whatever language can accomplish this) that can create a WIM image while running in Windows PE. I found a .NET Wrapper for the Dism API that seems like it might be useful for this purpose, but I'm unsure if a .NET app will successfully run in Windows PE. Overall, my problem is that I don't see a function that can create--and doesn't simply modify--a wim file.
If I didn't care about encapsulating this in an .exe file, the Dism documentation does show how to initially create a wim--which makes me curious why a similar function wouldn't exist within the api. Please advise if the simplest solution is to have my code call a function such as system() within the code.
To summarize, I'm looking for a way to create a wim file programmatically (called from executing an exe file) from within Windows PE.
As always, thank you for the help and advice.
I work on a project that works with DISM in WinPE quite a bit. We configure WinPE with all the .net packages as described here. Then WinPE can be configured to start an application.
I use c#, but you can do managed apps in c++ as I'm sure you know. I find putting c# code into WinPE substantially easier, but that's more a function of my experience, I suppose.
The main way we use to interact with DISM is run a command using System.Diagnostics.Process. The process runs in a separate thread, but the API is simple, and you can wait on (and/or timeout) your process for synchronization purposes. This just uses the DISM command line interface, although you can also use powershell cmdlets if you've added that package to your WinPE image. It may seem like a hacky "interface" from your app to DISM, but it works reliably, and you can keep the process window from showing up on the screen. This makes for a decent asynchronous platform for running bunches of windows imaging utilities, such as DISKPART, DISM and BCDEDIT.
The principal way you'd capture a new image is with DISM /Capture-Image. Sounds like you've already discovered this fact. Lots of options that are somewhat beyond the scope of this q/a, but I hope this gets you on a useful path.
Even though this post is a bit older, here is a possibly still relevant resource for you. Perhaps this one will help.
I've written a small GUI-based tool, project-named WIM-Backup, that uses the Windows Imaging Format (WIM) to create full backups of computer systems (operating system images) within WinPE and then restore them.
The application is hosted on GitHub, is open source, and is offered under the Apache 2.0 license.
In addition, the repository includes an illustrated step-by-step guide to help get it up and running.
Brief summary:
WIM-Backup always requires an external bootable media such as a USB flash drive.
From this drive WinPE is booted to perform a backup or restore to or from an external medium (e.g. a USB hard drive).
On the bootable USB flash drive the WinPE must be set up before (is documented illustrated in the readme).
After completion of the respective operation, a status message is displayed whether the operation was successful or failed.
After restoring a backup, you can boot normally from the destination drive.
Both the backup and restore process are relatively simple (not "rocket science").
To set up the solution, you need about 30 minutes time in the best case due to the necessary downloads (e .g. ADK)
Last but not least: it has a permissive license (non-proprietary) and is open source.
The project can be found here: WIM-Backup
Currently I'm developing an extension for Premiere Pro that should use .exe file to make things happen.
The main algorithm is written in python and works with actual video files: reads them frame by frame, processes the information in pixel level... I'm thinking of making an executable from it and call it from extendscript to make things happen...
Is this the right way to go ? Or should I consider other technics like writing a plugin using the PPro SDK and call it from extendscript ? Is it possibe to access the actual video-files, read them, get pixel values with SDK ?
Thanks.
I'm not sure how good the Premiere SDK is, but the drawback I can see to use the SDK you would have to port everything to C++. If that's less work than creating the Extendscript bridge it would be the way to go.
The PPro Extendscript documentation is notoriously non-existent.
I'm writing a program to maintain computers at my workplace. I want to use msinfo32 to automatically collect system information about computers in network remotely and use this data in my program.
The only way I found is to manually connect using interface of msinfo32, export all data and then parse it with my program. But I want to improve this process and do it automatically, update all info automatically etc.
Is there any way I could collect all pc info remotely using msinfo32 from inside of my program?
Please, send me link to how-to with code examples, or explain why I can not do this or how I could.
Sorry for my english, thank you for your attention.
UPD: possibly, I can run msinfo32.exe from inside, but I rather use library than running external program in cmd.
Depends on what exactly do you need to gather. You have some WinApi functions and classes that can give you the system info.
GetSystemInfo() or Computer System Hardware Classes
But I think it's not that bad to use msinfo32.exe directly if it works.
You can't. You should use WINAPI functions, because msinfo32 does not provide console output interface, which could be best solution.
Related: How do I get hardware info such as CPU name, total RAM, etc. with VB6?
You can also use registry keys to check any system settings, all documentation is in the net. Getting system information using registry is not reliable, though.
Msinfo32 documentation
I don't know if in 2015 there was already the "/nfo" option that allows you to have all the results exported to a file.
So just execute:
msinfo32 /nfo "c:\delme\msinfo32.nfo"
and then, via XML, read the desired results.
How do you debug lua code embedded in a c++ application?
From what I gather, either I need to buy a special IDE and link in their special lua runtime (ugh). Or I need to build a debug console in to the game engine, using the lua debug API calls.
I am leaning toward writing my own debug console, but it seems like a lot of work. Time that I could better spend polishing the other portions of the game.
There are several tools floating around that can do at least parts of what you want. I have seen references to a VS plugin, there is a SciTE debugger extension in Lua for Windows, and there is the Kepler project's RemDebug, as well as their LuaEclipse.
RemDebug may be on the track of what you need, as it was built to allow for debugging CGI scripts written in Lua. It does require access to the LuaSocket module to provide a communications channel between the target script and a controller as well as a couple of other modules.
A bigger issue might be the ability to load arbitrary modules from within whatever sandbox the game engine has put around your scripts. If you have some control over the engine, then that won't be as big an issue.
This isn't currently possible for developers of Adobe Lightroom plugins, for example, because Lightroom does not expose require inside the plugin's sandbox.
A surprise to me has been how rarely I have felt a need for a debugger when working with Lua. I've built several small applications in it for various projects and have been surprised at how well a combination of complete stack backtraces and the occasional print call works to locate the bugs that require "strict" didn't prevent in the first place.
How about Decoda?? there is a video that explains how to use it, and it works pretty darn well for embedded lua source. (i am a happy customer). and it's pretty cheap.
You don't need to write your own console as you may want to start with one of the existing ones. RemDebug has already been suggested; I have been developing MobDebug, which is a debugger based on RemDebug, but with a host of new features and bug fixes. The detailed list of the changes is in the README.
Enabling debugging in your script may be as simple as adding require('mobdebug').start() (if you are running your app and the debugger server on the same machine). This should try to connect to the debugger listening on a default port on localhost. You can use a command-line interface included in MobDebug, or you can use a ZeroBrane Studio, which is a Lua IDE that integrates with MobDebug to provide debugging capabilities. The IDE supports debugging for Love2d, Moai, and other Lua engines and may well work for your set up too.
You can use my debugger: GRLD (graphical remote lua debugger). Like RemDebug it uses a socket connection, but unlike RemDebug it has a nice graphical interface. The source code is provided, so you can make it work on any platform. It works with the standard lua runtime. Free of charge for non-commercial use.
EDIT: sorry, I had to close the website, so the software is not available for download anymore. I might release it as open source software later, if I ever find the time.
EDIT 2: link updated, now hosted in github under the MIT license (open source)
I don't see how calling DebuggerBreak should work, since that is .NET specific. I would assume that only works with the forked Lua targeting the CLR.
If you are using standard Lua you have some rudementary debugging facilities through the lua function call debug.debug(). That will throw Lua into your console, so if you are running lua from a console, you should be able issue lua commands interactively to inspect your current state. debug.debug() wont put you into the current stack frame, so you have to use debug.getlocal() to read the values of your variables.
I haven't tried it myself yet, but I actually don't think making your own workable debug console is that much work. Remember Lua is not as complicated language as C++, so doing this is a lot easier than making a real C++ debugger like say gdb.
I think there are a lot of people who have done similar things already, whos code you could look at. Here is CLI debugger written in only lua. Just one lua file. Shouldn't be to hard use and modify for your needs.
If you are using windows and VS - Can you use the trick we use?
Copy the lua code in a file. Then in the lua code make a call to the Debugger api (in C++ this is DebuggerBreak() I think - see here). then when the lua code executes the debugger will fire up and you should be able to specify the file. Then debug as normal?
I am trying to snoop on a log file that an application is writing to.
I have successfully hooked createfile with the detours library from MSR, but createfile never seems to be called with file I am interested in snooping on. I have also tried hooking openfile with the same results.
I am not an experienced Windows/C++ programmer, so my initial two thoughts were either that the application calls createfile before I hook the apis, or that there is some other API for creating files/obtaining handles for them.
You can use Sysinternal's FileMon.
It is an excellent monitor that can tell you exactly which file-related system calls are being
made and what are the parameters.
I think that this approach is much easier than hooking API calls and much less intrusive.
Here's a link which might be of use:
Guerilla-Style File Monitoring with C# and C++
It is possible to create a file without touching CreateFile API but can I ask what DLL injection method you're using? If you're using something like Windows Hooks your DLL won't be installed until sometime after the target application initializes and you'll miss early calls to CreateFile. Whereas if you're using something like DetourCreateProcessWithDll your CreateFile hook can be installed prior to any of the application startup code running.
In my experience 99.9% of created/opened files result in a call to CreateFile, including files opened through C and C++ libs, third-party libs, etc. Maybe there are some undocumented DDK functions which don't route through CreateFile, but for a typical log file, I doubt it.
Process Monitor from sysinternals could help too.