Is there a way to create BCRYPT_ECCKEY_BLOB from a compressed key (say P256) using Windows API only and without linking to a big number library and performing EC math manually.
Related
I have an encrypted 7z file which has some binary data files.
I am on windows platform (Windows 10 - Customers are also on same platform).
I am using C++ 17.
I am using a third party library (C standard) that can load these binary files only from disk (not from memory streams) into memory.
Loading the bin files from disk to memory takes a few milliseconds.
I don't want to let the users of my software to be able to read the content of the binary files.
I can't use a online service to host these bin files because the customers should be able to use the software on a standalone computer without any network connectivity.
The way I am planning it now is as follows:
Choose a random folder path at runtime (in the windows temp folder)
Extract the encrypted 7z file to the above random path.
Immediately acquire a exclusive lock on the bin files using https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-lockfileex
Read the bin files
After the reading is done, overwrite the files with zeros
Delete the extracted files
Things that can go wrong in the above approach:
Customers having admin privileges can potentially perfectly time the bin file loading in software and kill the process before the files are overwritten.
Customers can potentially get a memory dump and read the data directly (not sure if this is so easy to pull off)
Potentially more ways..
Is there any better way to deal with the situation?
Should I live with the potential of IP loss.
Is there really no way to copy a local file by
using some portable way
using built in golang calls ...
... which in turn use the native API of the operating system ?
All ways I found make use of some kind of Reader / Writer or use buffers to copy the content of the source to the target, either bytewise or blockwise or - even worse - spawn commands like cp.
Even add on libraries like [gut/yos][1] that I found by searching awesomego internally do the same
The downside of just reading the source file and writing the content to a new file is that you have to take care that these "properties" (depending on the OS you are using) of the source and destination match:
timestamps
permissions
setuid bits
(soft/hard) links
alternate data streams
I know there are specialized libraries that for example expose the Windows API and enable one to call CopyFileEx. But this approach would be limited to Windows and I need at least to support Linux.
My understanding is that the Windows PE executable file format has specific areas for data.
Currently, I am appending data to an executable, and it quickly declares it as being a virus in quite a few different anti-virus programs. It's at the point where any produced EXE triggers it.
Besides constantly sending false positive notes to vendors, is there a more appropriate method for appending data to an executable on Windows without being limited by data size?
We have a 3rd party native application (written in C I believe) which we want to run multiple instances of on a machine.
however the application reads and writes from one particular registry key in order to find the location of a config file. It reads this location continuously during its running. The registry key is in HKLM. this means that if we try and run 2 different instances of the app with 2 different locations for the config file the processes tread on each others toes.
Is it possible to 'virtualise' the registry (or run each process in a sandbox) that the processes are using so that they can both think they are writing to a single location, but actually they are writing and reading from somewhere different and they won't step on each others toes?
There are several options to virtualize a program:
https://en.wikipedia.org/wiki/Portable_application_creators
Creating your own virtualization software is much more complicated and would require an entire coarse on programming and hooking library calls using the windows SDK.
However an easier option that doesn't require setting up and running additional software for each copy of the program I suggest creating multiple copies of the program and hex editing each executable.
Make as many copies of the application as you need to run, then open the application file in a hex editor and search for the name of the registry key, ie:
HKLM\System\CurrentControlSet\Control\Session Manager
Then change the last byte to a digit for each different version (1 byte, 0-9) ie:
HKLM\System\CurrentControlSet\Control\Session Manage1
HKLM\System\CurrentControlSet\Control\Session Manage2
HKLM\System\CurrentControlSet\Control\Session Manage3
For more than 10 differences (2 bytes, 00-99) use the last two bytes:
HKLM\System\CurrentControlSet\Control\Session Manag01
HKLM\System\CurrentControlSet\Control\Session Manag02
HKLM\System\CurrentControlSet\Control\Session Manag03
While the solution from Joshua will work for this particular application, it might not work for others (f.e. where the registry path is constructed in code or when the application is signed).
Therefore, I would suggest using DLL injection and intercept calls to RegOpenKey(Ex), RegCreateKey(Ex), etc. That way, you can fiddle with the registry path before passing the call down to the real Windows Advapi32.dll.
Some great articles about API hooking:
API Hooking and DLL Injection on Windows
API Hooking with MS Detours
Yes, Sandboxie can run multiple instances of an app, each in it's own "Sandbox" which it believes to be the entire universe. But you can also access the data directly through the normal ways if you need to.
So in other words, Sandboxie lets you see all the registry changes that were made in the app's operations, and you can roll them back if you like.
Yes, you can virtualize the application, this technology is called Application Virtualization.
Try http://www.cameyo.com/. Cameyo is a software used to build virtual application.
A virtual application is a single EXE file that holds an entire application including files, DLLs and registry. Virtual apps are isolated from your system and can be copied & moved from one computer to another without installation.
I have been trying to find a way to "defragment" the registry on my Windows machine. Firstly, does this make sense? Any benefits in doing this? (Not much love on superuser.com) Secondly, I am looking for a way to rewrite the registry using C/C++ with Windows API. Is there a way to read the registry and write it to a new file getting rid of unused bytes along the way? (I might have to write the new file and then boot into another OS/disk before I can overwrite the original... but I am willing to take that risk.)
Microsoft's PageDefrag does exactly this, as it states on its page "PageDefrag uses the standard file defragmentation APIs to defragment the files."
(A copy of the linked article is here because in typical MSDN style their link is dead.)
http://www.larshederer.homepage.t-online.de/erunt/ - NTREGOPT NT Registry Optimizer
Similar to Windows 9x/Me, the registry files in an NT-based system
can become fragmented over time, occupying more space on your hard
disk than necessary and decreasing overall performance. You should
use the NTREGOPT utility regularly, but especially after installing
or uninstalling a program, to minimize the size of the registry files
and optimize registry access.
The program works by recreating each registry hive "from scratch",
thus removing any slack space that may be left from previously
modified or deleted keys.
http://reboot.pro/index.php?showtopic=11212 - Offreg.dll MS WDK Offline Registry Library
The offline registry library (Offreg.dll) is used to modify a registry hive outside the active system registry. This library is intended for registry update scenarios such as servicing an operating system image. The library supports registry hive formats starting with Windows XP.
Developer Audience
http://reboot.pro/topic/11312-offline-registry/ - Offline Registry MS WDK Command-Line Tool
A command line tool that will allow one to read and write to an offline registry hive.
Reading the values should be possible.
But I've never seen any spec for how the registry files are written to disk, and unless you could find one you'd have to reverse engineer those files in your OS (might be differences between XP and 7 etc). Then you have to remember that the registry isn't just one file, it's multiple files and some of them belongs to certain users and I think they use SIDs rather than user names so even if you move them to a new computer, you have to be sure it's the same OS version with the same users with the same SIDs set up on it.
All this for little or no gain so I'd agree with the superuser users that it wouldn't make sense.