I cannot mount some IMAGE on the MacOSX 10.10 via C function mount().
I use following code
...
char ImgPath[m_IMGName.size() + 1];
memcpy(ImgPath, m_IMGName.c_str(), m_IMGName.size() + 1);
struct hfs_mount_args data;
data.fspec = ImgPath;
if(mount("hfs+", m_TargetPath.c_str(), MNT_RDONLY, &data)){
throw SysCallTestExeption(errno, "mount() is failed!", GET_FILE_LINE_FUNC_ARG);
}
...
And when I start the program I get the error "mount() is failed! Error(Operation not supported by device)."
And image was mounted if I use the following command:
sudo hdiutil attach -mountpoint "${MountPointPath}" "${Image}"
Also, when I use mount() on the Linux - All is OK.
Following Linux code:
...
if(mount(m_IMGName.c_str(), m_TargetPath.c_str(), m_FSType.c_str(), 0, m_Opts.c_str())){
throw SysCallTestExeption(errno, "mount() is failed!", GET_FILE_LINE_FUNC_ARG);
}
...
There is no hfs+ type in
mount("hfs+", m_TargetPath.c_str(), MNT_RDONLY, &data)
You should use hfs to handle both HFS and HFS+. Look for example at mount_hfs command source:
#define HFS_MOUNT_TYPE "hfs"
Related
I was taking a look at this Github project: https://github.com/LloydLabs/delete-self-poc
This project uses the SetFileInformationByHandle API (https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfileinformationbyhandle) in a somewhat creative way to allow the deletion from disk of a locked file. I am attempting to implement this as part of a larger program, however I have ran into an issue when compiling for x86. I use mingw-w64 on a debian machine to compile my program and when doing compatibility checks for x86, I found a very strange issue.
#include "main.h"
static
HANDLE
ds_open_handle(
PWCHAR pwPath
)
{
return CreateFileW(pwPath, DELETE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
}
static
BOOL
ds_rename_handle(
HANDLE hHandle
)
{
FILE_RENAME_INFO fRename;
RtlSecureZeroMemory(&fRename, sizeof(fRename));
// set our FileNameLength and FileName to DS_STREAM_RENAME
LPWSTR lpwStream = DS_STREAM_RENAME;
fRename.FileNameLength = sizeof(lpwStream);
RtlCopyMemory(fRename.FileName, lpwStream, sizeof(lpwStream));
return SetFileInformationByHandle(hHandle, FileRenameInfo, &fRename, sizeof(fRename) + sizeof(lpwStream));
}
static
BOOL
ds_deposite_handle(
HANDLE hHandle
)
{
// set FILE_DISPOSITION_INFO::DeleteFile to TRUE
FILE_DISPOSITION_INFO fDelete;
RtlSecureZeroMemory(&fDelete, sizeof(fDelete));
fDelete.DeleteFile = TRUE;
return SetFileInformationByHandle(hHandle, FileDispositionInfo, &fDelete, sizeof(fDelete));
}
int
main(
int argc,
char** argv
)
{
WCHAR wcPath[MAX_PATH + 1];
RtlSecureZeroMemory(wcPath, sizeof(wcPath));
// get the path to the current running process ctx
if (GetModuleFileNameW(NULL, wcPath, MAX_PATH) == 0)
{
DS_DEBUG_LOG(L"failed to get the current module handle");
return 0;
}
HANDLE hCurrent = ds_open_handle(wcPath);
if (hCurrent == INVALID_HANDLE_VALUE)
{
DS_DEBUG_LOG(L"failed to acquire handle to current running process");
return 0;
}
// rename the associated HANDLE's file name
DS_DEBUG_LOG(L"attempting to rename file name");
if (!ds_rename_handle(hCurrent))
{
DS_DEBUG_LOG(L"failed to rename to stream");
return 0;
}
DS_DEBUG_LOG(L"successfully renamed file primary :$DATA ADS to specified stream, closing initial handle");
CloseHandle(hCurrent);
// open another handle, trigger deletion on close
hCurrent = ds_open_handle(wcPath);
if (hCurrent == INVALID_HANDLE_VALUE)
{
DS_DEBUG_LOG(L"failed to reopen current module");
return 0;
}
if (!ds_deposite_handle(hCurrent))
{
DS_DEBUG_LOG(L"failed to set delete deposition");
return 0;
}
// trigger the deletion deposition on hCurrent
DS_DEBUG_LOG(L"closing handle to trigger deletion deposition");
CloseHandle(hCurrent);
// verify we've been deleted
if (PathFileExistsW(wcPath))
{
DS_DEBUG_LOG(L"failed to delete copy, file still exists");
return 0;
}
DS_DEBUG_LOG(L"successfully deleted self from disk");
return 1;
}
When compiling the base code found in the linked repository (and shown above) as x86, attempting to run the program fails at the SetFileInformationByHandle call in the ds_rename_handle function. Calling GetLastError() returns 123:
ERROR_INVALID_NAME
123 (0x7B)
The filename, directory name, or volume label syntax is incorrect.
The very bizarre part is that the program succeeds when ran from an Administrator prompt. Even stranger, compiling the same code for x64 works both in a normal and an Administrator prompt.
As a sanity check I copied the code verbatim over to VS2019 and compiled there, and the resulting x86 program was able to run without Administrator privileges.
The only changes to the source code made on the debian system were made in the header file:
#pragma once
#pragma comment(lib, "Shlwapi.lib")
#include <Windows.h>
#include <shlwapi.h>
#include <stdio.h>
#include <stdlib.h>
#define DS_STREAM_RENAME L":wtfbbq"
#define DS_DEBUG_LOG(msg) wprintf(L"[LOG] - %s\n", msg)
Where <Windows.h> was changed to <windows.h> and the DS_DEBUG_LOG line changed to %ls so that the entire log message would print.
The GCC command used to compile for x86 was:
i686-w64-mingw32-gcc main.c -o delete32.exe -s -DUNICODE -Os -lshlwapi
I have tried removing all switches and compiling and it still fails.
As a note, the shlwapi library is only required for the very last call in main(), PathFileExistsW. I have commented out that portion and removed shlwapi from imports and from the gcc command to no effect.
The x64 gcc command which succeeded was:
x86_64-w64-mingw32-gcc main.c -o delete32.exe -s -DUNICODE -Os -lshlwapi
In the issues tab of the github repo there are some mentions of errors in the code which I have looked at separately. However I would desperately like to know why mingw is causing an issue with the 32 bit version of this program. Unfortunately "just compile with VS" isn't an option, as I use a program to generate and compile the program that this bit of code will be part of on my linux machine.
Thanks for any insight.
RtlCopyMemory(fRename.FileName, lpwStream, sizeof(lpwStream)); writes 4 or 8 bytes into a 2 byte buffer! Who knows where the remaining bytes are going, the program behavior is probably undefined.
The concept of deleting a running exe like this might work but the code indicates that the author does not have a full understanding of Windows and C. You are better off rewriting it from scratch...
Edit:
After playing with your uploaded files I can with confidence say that it is the lack of a application manifest that causes it to fail when it is not elevated. Your vc file has a requestedExecutionLevel element which gives it Vista operating system context. If you remove the manifest resource in the vc exe it stops working. If you add a manifest to the mingw exe it starts working.
the ds_rename_handle function is wrong implemented.
the FILE_RENAME_INFO is variable size structure.
as result declaration
FILE_RENAME_INFO fRename;
almost always wrong (it will ok only if FileName containing 1 or 2 symbols)
really we need first calculate FileNameLength and then allocate PFILE_RENAME_INFO based on this
as example:
ULONG FileNameLength = (ULONG)wcslen(DS_STREAM_RENAME) * sizeof(WCHAR);
ULONG dwBufferSize = FIELD_OFFSET(FILE_RENAME_INFO, FileName) + FileNameLength;
PFILE_RENAME_INFORMATION fRename = (PFILE_RENAME_INFORMATION)alloca(dwBufferSize);
so complete code for ds_rename_handle can be next:
ULONG ds_rename_handle(HANDLE hHandle, PCWSTR DS_STREAM_RENAME)
{
ULONG FileNameLength = (ULONG)wcslen(DS_STREAM_RENAME) * sizeof(WCHAR);
ULONG dwBufferSize = FIELD_OFFSET(FILE_RENAME_INFO, FileName) + FileNameLength;
PFILE_RENAME_INFO fRename = (PFILE_RENAME_INFO)alloca(dwBufferSize);
fRename->ReplaceIfExists = TRUE;
fRename->RootDirectory = 0;
fRename->FileNameLength = FileNameLength;
memcpy(fRename->FileName, DS_STREAM_RENAME, FileNameLength);
return SetFileInformationByHandle(hHandle, FileRenameInfo,
fRename, dwBufferSize) ? NOERROR : GetLastError();
}
but documentation of FILE_RENAME_INFO is very bad. unclear - in what form - full pathname, file name or a relative pathname - must be FileName ?!
from my research - it must be full pathname only (not file name) or begin with a colon : ( The new name for the stream )
much more better use NtSetInformationFile with FileRenameInformation
compare description of FILE_RENAME_INFORMATION structure with FILE_RENAME_INFO !
here exist detailed description - in what form FileName it should be.
so i always use
NTSTATUS ds_rename_handle_nt(HANDLE hHandle, PCWSTR DS_STREAM_RENAME)
{
ULONG FileNameLength = (ULONG)wcslen(DS_STREAM_RENAME) * sizeof(WCHAR);
ULONG dwBufferSize = FIELD_OFFSET(FILE_RENAME_INFO, FileName) + FileNameLength;
PFILE_RENAME_INFORMATION fRename = (PFILE_RENAME_INFORMATION)alloca(dwBufferSize);
fRename->ReplaceIfExists = TRUE;
fRename->RootDirectory = 0;
fRename->FileNameLength = FileNameLength;
memcpy(fRename->FileName, DS_STREAM_RENAME, FileNameLength);
IO_STATUS_BLOCK iosb;
return NtSetInformationFile(
hHandle, &iosb, fRename, dwBufferSize, FileRenameInformation);
}
As a first step on a larger project I was trying to display the imagem from my webcam using OpenCV:
#include <stdlib.h>
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
int
main()
{
cv::VideoCapture cap(-1);
if (!cap.isOpened())
exit(EXIT_FAILURE);
cv::Mat frame;
bool done = false;
while (!done) {
cap >> frame;
cv::imshow("webcam", frame);
done = (cv::waitKey(30) >= 0);
}
return EXIT_SUCCESS;
}
This returns an error code (!cap.isOpened() passes ,confirmed with gdb). Initially I had 0 instead of -1. When searching this site -1 was suggested, but it was to no avail. I also tried 1 through 3, as another user suggested it.
I can display my webcam using mplayer, more specifically mplayer tv:// -tv driver=v4l2.
v4l2 is the "video for linux" driver. I noticed OpenCV can be installed with such driver by compiling it with -DWITH_V4L and -DWITH_LIBV4L (v4l USE flag in Gentoo). After recompiling OpenCV with it, it successfully recognized the webcam. GTK support seems to be needed to display the image.
I've successfully created an OpenCL context by calling clCreateContextFromType:
const cl_context_properties context_props[] = {
CL_CONTEXT_PLATFORM, (cl_context_properties)cl->platform,
CL_GL_CONTEXT_KHR, (cl_context_properties)interop_context->glx_context,
CL_GLX_DISPLAY_KHR, (cl_context_properties)interop_context->x11_display,
0,
};
cl->context = clCreateContextFromType(context_props, CL_DEVICE_TYPE_GPU, cl_error_cb, NULL, NULL);
if(!cl->context) {
LOG_ERROR("Failed to create OpenCL context");
free(cl);
return NULL;
}
Then I've queried said context for the actual device via a call to clGetContextInfo with CL_CONTEXT_DEVICES parameter, and used the first (and, on my computer, only) device id listed in the result:
clGetContextInfo(cl->context, CL_CONTEXT_DEVICES, num_devices * sizeof(cl_uint), cl_devices, NULL);
cl->device = cl_devices[0];
Yet, when I try to create a command queue via a call to clCreateCommandQueue it fails with CL_INVALID_DEVICE error:
cl_command_queue_properties props = CL_QUEUE_PROFILING_ENABLE;
cl_int error;
cl_command_queue queue = clCreateCommandQueue(cl->context, cl->device, props, &error);
if(!queue) {
LOG_ERROR("Failed to create CL command queue: %d", error);
return NULL;
}
OpenCL documentation clearly states that CL_INVALID_DEVICE is returned "if device is not a valid device or is not associated with context".
The device id I pass to clCreateCommandQueue is the same id that was returned by clGetContextInfo call so it definitely should be valid for this context.
Why am I getting this error then? Is there anything wrong with my code?
I'm running this on Linux x86_64 with a NVIDIA GeForce GTX 1070 GPU and NVIDIA's proprietary driver version 375.26. clinfo runs fine and returns correct information about 1 OpenCL platform with 1 device (my GPU). I tried running some OpenCL code samples and they all worked.
I'm trying to use gaddr2line to print a prettier version of backtrace symbols. I'm just getting the addresses from backtrace() then feeding them to gaddr2line by executing it using popen. Using addr2line under linux works fine, but for some reason I'm getting strange errors when using gaddr2line on OS X. When trying this on Mac OS I keep getting BFD: ... : unknown load command ... I saw some posts metioning GDB, so I tried installing that with homebrew, but that didn't help.
Here is my code:
// set to the maximum possible path size
char exe_path[4096];
// Used to check if an error occured while setting up command
bool error = false;
// Check if we are running on Mac OS or not, and select appropriate command
char* command;
#ifdef __APPLE__
// Check if 'gaddr2line' function is available, if not exit
if( !system( "which gaddr2line > /dev/null 2>&1" ) ) {
command = "gaddr2line -Cfspe";
pid_t pid = getpid();
int path_length = proc_pidpath( pid, exe_path, sizeof( exe_path ) );
if( path_length <= 0 ) {
writeLog( SIMPLOG_LOGGER, "Unable to get execution path. Defaulting to standard backtrace." );
error = true;
}
exe_path[path_length] = 0;
} else {
writeLog( SIMPLOG_LOGGER, "Function 'gaddr2line' unavailable. Defaulting to standard backtrace. Please install package 'binutils' for better stacktrace output." );
error = true;
}
#endif
Here is the output:
gaddr2line -Cfspe /Users/nate/git/SimpleLogger/build/test 7408927
BFD: /Users/nate/git/SimpleLogger/build/test: unknown load command 0x2a
BFD: /Users/nate/git/SimpleLogger/build/test: unknown load command 0x28
BFD: /Users/nate/git/SimpleLogger/build/test: unknown load command 0x29
BFD: /Users/nate/git/SimpleLogger/build/test: unknown load command 0x2b
Part of a program named =program.c
int memoryPercent()
{
int memoryPercent=0;
FILE *pipe1 = NULL;
pipe1=popen("/home/jatin/scripts/memoryPercent.sh","r");
if(!pipe1)
{
snmp_log(LOG_ERR,"popen failed in temp(),errno:%d\n",errno);
return -1;
}
if( fscanf(pipe1,"%d",&memoryPercent) != 1)
{
snmp_log(LOG_ERR,"fscanf failed in temp fun(),errno:\n");
return -2;
}
pclose(pipe1);
return memoryPercent;
}
above is my calling code /home/jatin/scripts/memoryPercent.sh
on this location a scripts is given and it is returning a INTEGER value.
in UBUNTU 12.04 when I compile and execute this code it is running perfectly.
but in my VM-WARE
I have copied all the necessary dependencies at the location /var/snmp3 and executing this binary with CHROOT the syntax is
/usr/sbin/chroot /var/snmp3/ /usr/local/bin/program
it is showing value "-1" only !!
Can anyone tell me what I am missing ?
the script is at the same location in /var/snmp3/home/jatin/scripts/memoryPercent.sh
as well as /home/jatin/scripts/memoryPercent.sh in 775 mode....
Try running the script manually from a chrooted shell.
I think you are missing the shell used by memoryPercent.sh. Have you copied the shell to the chrooted environment?