I would like to ask what EwfSysprepSpecialize does exactly do.
So far, I know it seems to be an entry point within the ewfcfg.dll and must be related somehow to HORM and EWF. It does not activate the Ewf protection for any volume. Also, it does not bring the system into hibernate.
I experienced, that whenever the call Rundll32 ewfcfg.dll, EwfSysprepSpecialize was NOT executed before I activate Ewf, the system does not automatically restart. Whereas when this mysterious routine was executed before, the system automatically restarts.
Here someone gave the hint to use it, but I can't find any documentation about it.
Is there any expert who can provide me some information about this secret?
This is an old question, but one I also wanted to know the answer for so I'll leave this here.
Far as I can tell, it's primary purpose is to create the tiny type-45 partition at the end of the disk to enable EWF-RAM (as opposed to EWF-RAM-Reg). If you already have a type-45 partition, it is deleted and re-created. If you don't have enough free space, it won't do anything.
It's half of the solution for fixing EWF-related problems stemming from cloned images. The other is making sure the partition offset and disk signature registry entries are updated. In my own deployment I used a PHP CLI script and a couple disk utilities for that part.
Hope that helps!
Related
How can I get the same data that the Screen Time app is returning on macOS?
Specifically I'd like to know — programmatically — the hours I'm spending each day on Visual Studio Code.
The data screenTime is stored in
/private/var/db/CoreDuet/Knowledge
/Users/wgnb/Library/Application Support/Knowledge
read Sarah blog for details
I don't have enough reputation to comment
I've been trying to figure all of this out too.
The closest I've come is this Github Repo: https://github.com/Evian-Zhang/ScreenTimeController
He confirmed the research I had already done by looking at the open file descriptors for the Screen Time agent. The ScreenTime database is stored here:
/var/folders/XYZ/xxxxxxxxxx/0/com.apple.ScreenTimeAgent/Store
You can read more about this part of the filesystem here
In this folder, there are several SQLite files which is what the agent writes to. Unfortunately, this folder is really locked down by MacOS.
You can read about how its locked down here and here.
The short answer is, as far as I can tell, you can't do it unless you disable System Integrity Protection either for those files or entirely. It is also likely that a software update would break your tweaks and you'd have to re-disable SIP on those files.
It really sucks because ScreenTime aggregates all of my devices and I would love to mess around with the data.
I have been searching everywhere for all the combinations of things that I want to accomplish hoping something would pop but I can't find anything. Additionally, I am not sure if I am "crafting" my query properly enough so I am hoping I can get some assistance on that here.
What I would like to accomplish is this (pseudo logic)
Create a single container file, for example: vdata.x which will contain everything in it as a single data file
Mount this file as an actual drive/folder in Windows so that you can write to, read from, delete/modify the content as if you were using Windows Explorer. Visible to FS, applications, system/commandline like any other "real" folder on the machine.
Prefer the ability to have this file reside on a thumbdrive and have it mounted either automatically or manually after plugged in and have it show up not as the thumbdrive but as the file inside it, or mount both doesn't matter.
Additionally the ability for that file to be locked, encrypted and accessible (despite auto mounting, if that's the case) after it have been authenticated with a password, random token or whatnot.
Finally a housekeeping element, such as being aware of its available "host" space (aka the thumbdrive) so that as it reaches a certain threshold of expansion, it says, hey move me to a larger device, make room or stop adding more, something akin to, running out of space warning.
I thought about putting this in software recommendation SE but that is not fully up and running yet (at last check) and plus the range of who access that sub-se might very limited, so I am asking here to get feedback and discussion to see if we can answer it better here or it needs to move to there.
Thank you in advance and hope to get some brilliant minds out there to help me accomplish this.
PS. I am not averse to building something like this myself but I am limited in time and health and plus if its already done, why reinvent the wheel right? But if anything could help launch the development of such a tool, I would take that input as well, thank you.
Let me first explain my situation:
I have an old application and don't have any possibility of changing it. This application works with sqlite tables, one of them being a "temporary" database, but does not create temporary tables in memory but rather uses normal tables.
I install this application in a terminal server and the problem is that the application tries to read from a static path from the temporary table.
I need to redirect the "open syscall" to another file, so I want to know if I could do that with some software or by programming it.
Several options in order of "preferableness":
Create a junction. Click the link to get a tool for doing this.
Use a shim if possible.
If the above are not possible then you could use Madshi's madCodeHook lib to intercept the(*) call. Somebody over here is having a similar question, the discussion there also applies to your situation.
Be careful though when using API hooking and always ask yourself what would happen if two programs are doing it at the same time. This would likely result in an unstable system a.k.a. a mess.
(*) You would also have to figure out which call you actually need to hook.
You should be able to do that with a junction point.
I have an application, which displays me some data. I need to attach to this app's process, find the data I need in memory (one single number, actually), and save it somewhere. This application doesn't seem to use standard windows controls, so things aren't going to be as simple as reading controls data using AutoIt or something similar.
Currently I'm a self-learner database guy and have quite shallow knowledge about windows apps debugging. Not even sure if I asked my question correctly enough.
So, can you give me some starter guidelines about, say, what should I read first, and general directions I should work on?
Thanks.
To read memory of other application you need to open the process with respect of OpenProcess with at least PROCESS_VM_READ access rights and then use ReadProcessMemory to read any memory address from the process. If you are an administrator or have debug privilege you will be able to open any process with maximal access rights, you need only to enable SeDebugPrivilege before (see for example http://support.microsoft.com/kb/131065).
If you don't know a much about the memory of the destination process you can just enumerate the memory blocks with respect of VirtualQueryEx (see How does one use VirtualAllocEx do make room for a code cave? as an example where I examine the program code. The program data you can examine in the same way).
The most practical problem which I see is that you ask your question in too general way. If you explain more what kind of the data you are looking for I could probably suggest you a better way. For example if you could see the data somewhere you could examine the corresponding windows and controls with respect of Spy++ (a part of Visual Studio Tools). The most important are the class of windows (or controls) and the messages which will be send at the moment when the most interesting window are displayed. You can also use Process Monitor to trace all file and registry access at the time when the windows with the interesting information will be displayed. At least at the beginning you should examine the memory of the process with ReadProcessMemory at the moment when the data which you are looking for are displayed on the window.
If you will have no success in your investigations I'd recommend you to insert in your question more information.
My primary advice is: try to find any other method of integration than this. Even if you succeed, you'll be hostage to any kinds of changes in the target process, and possibly in the Windows O/S. What you are describing is behaviour most virus scanners should flag and hinder: if not now, then in the future.
That said, you can take a look at DLL injection. However, it sounds as if you're going to have to debug the heck out of the target process at the disassembly level: otherwise, how are you going to know what memory address to read?
I used to know the windows debugging API but it's long lost memory. How about using ollydbg:
http://www.ollydbg.de/
And controlling that with both ollydbg script and autoit?
Sounds interesting... but very difficult. Since you say this is a 'one-off', what about something like this instead?
Take a screenshot of this application.
Run the screenshot through an OCR program
If you are able to read the text you are looking for in a predictable way, you're halfway there!
So now if you can read a OCR'd screenshot of your application, it is a simple matter of writing a program that does the following:
Scripts the steps to get the data on the screen
Creates a screenshot of the data in question
Runs it through an OCR program like Microsoft Office Document Imaging
Extracts the relevant text and does 'whatever' with it.
I have done something like this before with pretty good results, but I would say it is a fragile solution. If the application changes, it stops working. If the OCR can't read the text, it stops working. If the OCR reads the wrong text, it might do worse things than stop working...
As the other posters have said, reaching into memory and pulling out data is a pretty advanced topic... kudos to you if you can figure out a way to do that!
I know this may not be a popular answer, due to the nature of what this software is used for, but programs like CheatEngine and ArtMoney allow you to search through all the memory reserved by a process for a given value, then refine the results till you find the address of the value you're looking for.
I learned this initially while trying to learn how to better protect my games after coming across a trainer for one of them, but have found the technique occasionally useful when debugging.
Here is an example of the technique described above in use: https://www.youtube.com/watch?v=Nv04gYx2jMw&t=265
I wonder if it is possible to figure out what keys user was pressing while his Mac OS was starting up?
Any way will do. As far as I understand it there is no easy way to simply hook an app/script to start working and capturing keystrokes simultaneously along with the OS. But maybe there is a way to some kind of reverse engineer this? Maybe looking into a specific log file or something like that?
Any results will do. Basically what I'm interested in is in finding out, which key the user pressed/held during the OS startup. It may be string, a character code or a hex, doesn't really matter.
UPDATE: guided by Pekka's advice I've found a kernel extension that should do the job. And it, hopefully, will do it, after this follow-up question - Why this keyboard intercepting kernel extension doesn’t work? is answered. :)
I'm no OS guru, but I think very, very, very hardly. I don't suppose stuff like this is automatically recorded anywhere.
I guess you would have to look whether the part of the system that handles the startup keys is somehow accessible, and can be extended to invoke a command defined by you.
The second best thing that comes to mind is for you to write some sort of custom device driver or startup script that gets loaded at startup, and listens to keypress events.
How to approach this depends completely on what point in the boot process you want to check for keys.
If you want to check really early, your only choice is to play with the EFI (firmware) environment -- maybe you could modify rEFIt to do what you want?
After the firmware, control passes to boot.efi (BootX on PPC Macs). This could presumably be replaced/hacked, and I'd expect the source to be available from as part of Darwin, but I don't see it on a quick inspection.
After that, the kernel loads (you could build your own kernel) with a minimal set of cached drivers (you could write a driver, not sure how to get it to be cached, though).
After that, all sorts of things happen more or less at once. Normal drivers get loaded, /etc/rc.local gets run, launchd items in /System/Library/LaunchDaemons and Library/LaunchDaemons become active... If you're willing to wait until this phase of the boot process, you have many options.
It's not just not recorded anywhere, for quite a while during startup there is no keyboard driver. So from the point of view of software, during that interval the keyboard simply doesn't exist.