Linking with Windows Projected File System DLL/LIB - c++

I am trying to build the RegFS sample to better understand the Windows Projected File System. My code is building without a warning, but I am getting dynamic linking errors. Below is a sample error, with the code causing it right below.
"The procedure entry point PrjWritePlaceholderInfo could not be located in the dynamic link library."
HRESULT VirtualizationInstance::WritePlaceholderInfo(
LPCWSTR relativePath,
PRJ_PLACEHOLDER_INFO* placeholderInfo,
DWORD length
) {
return PrjWritePlaceholderInfo(
_instanceHandle,
relativePath,
placeholderInfo,
length);
}
I'm sure I did something wrong when I was linking. Under [Project Property Pages] > Linker > Input, I prepended "ProjectedFSlib.lib" to "Additional Dependencies."
This is my first time using Visual Studio with libraries not linked in by default, and I've been unable to find instructions on how to locate and link libraries within the Windows SDK.
Thanks for your help!
EDIT:
The DUMPBIN output is:
Dump of file ProjectedFSLib.lib
File Type: LIBRARY
Exports
ordinal name
PrjAllocateAlignedBuffer
PrjClearNegativePathCache
PrjCloseFile
PrjCommandCallbacksInit
PrjCompleteCommand
PrjConfigureVolume
PrjConvertDirectoryToPlaceholder
PrjCreatePlaceholderAsHardlink
PrjDeleteFile
PrjDetachDriver
PrjDoesNameContainWildCards
PrjFileNameCompare
PrjFileNameMatch
PrjFillDirEntryBuffer
PrjFreeAlignedBuffer
PrjGetOnDiskFileState
PrjGetVirtualizationInstanceIdFromHandle
PrjGetVirtualizationInstanceInfo
PrjMarkDirectoryAsPlaceholder
PrjOpenFile
PrjReadFile
PrjStartVirtualizationInstance
PrjStartVirtualizationInstanceEx
PrjStartVirtualizing
PrjStopVirtualizationInstance
PrjStopVirtualizing
PrjUpdateFileIfNeeded
PrjUpdatePlaceholderIfNeeded
PrjWriteFile
PrjWriteFileData
PrjWritePlaceholderInfo
PrjWritePlaceholderInformation
PrjpReadPrjReparsePointData
Summary
D8 .debug$S
14 .idata$2
14 .idata$3
8 .idata$4
8 .idata$5
14 .idata$6
A DUMPBIN of the executable imports results in:
Dump of file regfs.exe
File Type: EXECUTABLE IMAGE
Section contains the following imports:
PROJECTEDFSLIB.dll
14006D2A0 Import Address Table
14006D9E0 Import Name Table
0 time date stamp
0 Index of first forwarder reference
1E PrjWritePlaceholderInfo
1D PrjWriteFileData
19 PrjStopVirtualizing
17 PrjStartVirtualizing
C PrjFileNameMatch
D PrjFillDirEntryBuffer
E PrjFreeAlignedBuffer
0 PrjAllocateAlignedBuffer
11 PrjGetVirtualizationInstanceInfo
12 PrjMarkDirectoryAsPlaceholder
B PrjFileNameCompare
KERNEL32.dll
14006D098 Import Address Table
14006D7D8 Import Name Table
0 time date stamp
0 Index of first forwarder reference
389 IsProcessorFeaturePresent
382 IsDebuggerPresent
466 RaiseException
1B1 FreeLibrary
BA CreateDirectoryW
116 DeleteFileW
59A TerminateProcess
4BD RemoveDirectoryW
621 WriteFile
C2 CreateFile2
86 CloseHandle
267 GetLastError
3F2 MultiByteToWideChar
21D GetCurrentProcess
57B SetUnhandledExceptionFilter
5BC UnhandledExceptionFilter
4E1 RtlVirtualUnwind
4DA RtlLookupFunctionEntry
4D3 RtlCaptureContext
477 ReadFile
2B5 GetProcAddress
5DD VirtualQuery
2BB GetProcessHeap
60D WideCharToMultiByte
450 QueryPerformanceCounter
21E GetCurrentProcessId
2F0 GetSystemTimeAsFileTime
36C InitializeSListHead
352 HeapFree
34E HeapAlloc
27E GetModuleHandleW
2D7 GetStartupInfoW
222 GetCurrentThreadId
ADVAPI32.dll
14006D000 Import Address Table
14006D740 Import Name Table
0 time date stamp
0 Index of first forwarder reference
299 RegQueryValueExW
293 RegQueryInfoKeyW
28C RegOpenKeyExW
27D RegEnumValueW
27A RegEnumKeyExW
25B RegCloseKey
281 RegGetValueW
ole32.dll
14006D438 Import Address Table
14006DB78 Import Name Table
0 time date stamp
0 Index of first forwarder reference
2A CoCreateGuid
MSVCP140D.dll
14006D228 Import Address Table
14006D968 Import Name Table
0 time date stamp
0 Index of first forwarder reference
A5 ??1_Lockit#std##QEAA#XZ
6D ??0_Lockit#std##QEAA#H#Z
296 ?_Xlength_error#std##YAXPEBD#Z
297 ?_Xout_of_range#std##YAXPEBD#Z
VCRUNTIME140D.dll
14006D360 Import Address Table
14006DAA0 Import Name Table
0 time date stamp
0 Index of first forwarder reference
3C memcpy
3D memmove
1 _CxxThrowException
E __CxxFrameHandler3
36 _purecall
3B memcmp
21 __std_exception_copy
22 __std_exception_destroy
8 __C_specific_handler
9 __C_specific_handler_noexcept
25 __std_type_info_destroy_list
2E __vcrt_GetModuleFileNameW
2F __vcrt_GetModuleHandleW
31 __vcrt_LoadLibraryExW
ucrtbased.dll
14006D498 Import Address Table
14006DBD8 Import Name Table
0 time date stamp
0 Index of first forwarder reference
2B6 _register_thread_local_exe_atexit_callback
B5 _configthreadlocale
2CE _set_new_mode
4D __p__commode
11D _free_dbg
52C strcpy_s
528 strcat_s
68 __stdio_common_vsprintf_s
2C2 _seh_filter_dll
B6 _configure_narrow_argv
171 _initialize_narrow_environment
172 _initialize_onexit_table
9F _c_exit
E5 _execute_onexit_table
C2 _crt_atexit
C1 _crt_at_quick_exit
54B terminate
39C _wmakepath_s
3B8 _wsplitpath_s
564 wcscpy_s
A4 _cexit
48D getchar
60 __stdio_common_vfwprintf
35 __acrt_iob_func
4 _CrtDbgReport
567 wcslen
176 _invalid_parameter
4B __p___wargv
49 __p___argc
2CB _set_fmode
EA _exit
450 exit
175 _initterm_e
174 _initterm
13E _get_initial_wide_environment
173 _initialize_wide_environment
B7 _configure_wide_argv
5B __setusermatherr
2C6 _set_app_type
561 wcscmp
5 _CrtDbgReportW
4D8 malloc
2B5 _register_onexit_function
A1 _callnewh
2C3 _seh_filter_exe
Summary
1000 .00cfg
1000 .data
2000 .idata
1000 .msvcjmc
5000 .pdata
17000 .rdata
1000 .reloc
1000 .rsrc
37000 .text
18000 .textbss
As evident, it imports all the necessary functions from PROJECTEDFSLIB.dll

Either add ProjectedFSLib.lib to your libraries or add a:
#pragma comment(lib, "ProjectedFSLib.lib")
line in your code. Also, make sure you are using version 10.0.17763.0 of the SDK. If you are using mingw it would not surprise me if this library has not been made available yet.

The Projected FS is still an optional feature of Windows that requires manual installation to use. Go to Control Panel -> Programs and Features -> Turn Windows Features on or off. In that list of optional features, scroll down to "Windows Projected File System" and make sure that it is enabled there. Only after that is done will you have a ProjectedFSLib.dll show up in your system32 directory.
It's also probably worth noting that it looks like there's only an x64 version of this DLL, so if you're building an x86 program, that might be the reason why you're unable to dynamically link with that DLL.

Related

Cachegring file very small

I am new to profiling. I am trying to profile my PHP with xdebug.
The cachegrind file is created but has no significant content
I have set xdebug.profiler_enable_trigger = 1
xdebug.profiler_output_name = cachegrind+%p+%H+%R.cg
I call my page with additional GET parameter ?XDEBUG_PROFILE=1
My cachegrind file is generated but has no significant content
Here is my output:
version: 1
creator: xdebug 2.7.0alpha1 (PHP 7.0.30-dev)
cmd: C:\WPNserver\www\DMResources\Classes\VendorClasses\PHPMySQLiDatabase\MysqliDb.php
part: 1
positions: line
events: Time Memory
fl=(1)
fn=(221) php::mysqli->close
1244 103 -14832
fl=(42)
fn=(222) MysqliDbExt->__destruct
1239 56 0
cfl=(1)
cfn=(221)
calls=1 0 0
1244 103 -14832
That's it - I must be missing something fundamental.
I think you hit this bug in xdebug.
As suggested by Derick in the issue tracker, you can workaround this by adding %r to the profiler output name. eg: xdebug.profiler_output_name = cachegrind+%p+%H+%R+%r.cg
(with %r adding a random number to the name)

DLL functions not exported when build in release configuration

In my C++ DLL project, when I build the project in Debug configuration, it works perfectly.
Functions are exported using a .def file:
LIBRARY "calc"
EXPORTS
findMaxFreqEXL = findMaxFreq
findMinSpeedEXL = calcMinSpeed
findMaxSpeedEXL = calcMaxSpeed
createProfileEXL = createProfile
arrayTestEXL = arrayTest
setLimitsEXL = setLimits
And those functions are all defined in my project as:
double _stdcall findMaxFreq(double &dCutLength, double &dCutTime, double &dSealTime, double &dCutSpeed, double &dDoughHeight, double* limitArray)
{
Calc *calcObj = new Calc();
calcObj->setLimits((int)limitArray[0], (int)limitArray[1], (int)limitArray[2], (int)limitArray[3], limitArray[4], limitArray[5], (int)limitArray[6], (int)limitArray[7], (int)limitArray[8], (int)limitArray[9], (int)limitArray[10]);
double maxFreq = calcObj->calcMaxFreq((float) dCutLength, (float) dCutTime, (float) dSealTime, (float) dCutSpeed, (float) dDoughHeight);
//delete calcObj;
return maxFreq;
}
And so on for the rest of the functions.
The generated DLL file is 192 kb in size, and according to dumpbin, these are the exported functions:
Dump of file C:\Redacted\Debug\calcDLL.dll
File Type: DLL
Section contains the following exports for calc.dll
00000000 characteristics
57B17EE6 time date stamp Mon Aug 15 10:35:50 2016
0.00 version
1 ordinal base
6 number of functions
6 number of names
ordinal hint RVA name
1 0 00013339 arrayTestEXL = #ILT+820(?arrayTest##YGHPAN#Z)
2 1 00013460 createProfileEXL = #ILT+1115(?createProfile##YGHAAN00000PAN11#Z)
3 2 000138E8 findMaxFreqEXL = #ILT+2275(?findMaxFreq##YGNAAN0000PAN#Z)
4 3 00013744 findMaxSpeedEXL = #ILT+1855(?calcMaxSpeed##YGNAAN00#Z)
5 4 00013500 findMinSpeedEXL = #ILT+1275(?calcMinSpeed##YGNAAN00#Z)
6 5 000134F6 setLimitsEXL = #ILT+1265(?setLimits#Calc##QAEXHHHHHHHHHHH#Z)
Summary
1000 .data
2000 .idata
5000 .rdata
2000 .reloc
1000 .rsrc
28000 .text
12000 .textbss
In Release configuration the file is only 10 kb and dumpbin says this:
Dump of file C:\Redacted\Release\calcDLL.dll
File Type: DLL
Summary
1000 .data
1000 .rdata
1000 .reloc
1000 .rsrc
2000 .text
I use Visual Studio Express 2013. Any idea on what I am missing?
Evertything you show is sort of ok, so my guess is you just forgot to set the exports file in the project settings for the release configuration. Go to project properties->Linker->Input and set the Module Definition File.
Also: you have a memory leak because you don't delete calcObj. But actually there's no reason to use the heap here, just use Calc calcObj; on the stack. Also know that casting double to int is truncating, and have you thought of what will happen if the number is > 2^31 ?

Python HMAC-SHA1 calculation goin wrong

I stuck in python while developing security access python script using HMAC-SHA1 algorithm key.
I have python version 2.7 which already includes HMAC-SHA1 libraries. Using library I tried to write script in the below mentioned way. But unfortunately when I execute the script the key calculated is different from the expected key given to me.
---------------Code Start--------------------------
from hashlib import sha1
import hmac
import base64
import hashlib, binascii
SecurityConst_key = "121a3ace5827a3b6" #(0x12 1A 3A CE 58 27 A3 B6)
msg = "4272696C6C69616E63655F6175746F21" # Brilliance_auto!
key = hmac.new(SecurityConst_key, msg, sha1).digest()
key = base64.b64encode(key)
print binascii.hexlify(key)
----------------Code End----------------------
Key calculated is : 4d416963747a41737a546f774530464373536e4d646b6c323972673d
Which is different from the leftmost 128 bits.
Expected key is: 0x15 4A ED 59 CF B3 2E DC 37 8D 30 6B 0F 02 AB 6B
(Truncate the 160 bits result. Output the leftmost 128 bits of the HMAC, it is the Key)
Can some one please help me to fix the possible issue.
So,what you need to be really careful of is understanding whether something is a byte-string or a hex-string. In python, most crypto and mac and sha's take binary strings. So your line:
SecurityConst_key = "121a3ace5827a3b6" #(0x12 1A 3A CE 58 27 A3 B6)
is not true. Thats actually 0x31 32 31 ... You need to get your data right first. Try hex decoding your key and your data before passing it in. "121a3ace5827a3b6".decode("hex").
On the other hand, for the data, you could just use the raw string.
Secondly you are also base64 encoding your output of the mac before printing that off as hex. That seems - wrong. You either base64 it and look at that, or you hex-encode it, and look at that. Base64 by design is ascii-printable (for hashes you traditionally print in hex)

python pandas dataframe index, error TypeError: Input must be iterable, pandas version perhaps wrong

I'm working with the eda-explorer python library from MIT, which allows one to import physiological data files from particular wearable biosensors. This libraray uses pandas DataFrames to store the physiological timeseries. I've been using this libarary in different computing set-ups. When I try to use it in my ubuntu 15.10 environment I get an error message I don't understand. It is related to the following function which is instrumental in getting the data into a DataFrame and doing some intitial transformations:
def loadData_E4(filepath):
# Load data
data = pd.DataFrame.from_csv(os.path.join(filepath,'EDA.csv'))
data.reset_index(inplace=True)
# Get the startTime and sample rate
startTime = pd.to_datetime(float(data.columns.values[0]),unit="s")
sampleRate = float(data.iloc[0][0])
data = data[data.index!=0]
data.index = data.index-1
This results in the following error messages:
In [1]:
run batch_edaexplorer_template.py
Classifying data for ...[my file location]...
---------------------------------------------------------------------
TypeError Traceback (most recent call last)
/...mypath/eda-explorer-master/batch_edaexplorer_template.py in <module>()
69 elif dataType=='e4':
70 print "Classifying data for " + filepath
---> 71 labels,data = classify(filepath,classifierList,pickleDirectory,lf.loadData_E4)
72 elif dataType=="misc":
73 print "Classifying data for " + filepath
/...mypath/eda-explorer-master/EDA_Artifact_Detection_Script.pyc in classify(filepath, classifierList, pickleDirectory, loadDataFunction)
225
226 # Load data
--> 227 data = loadDataFunction(filepath)
228
229 # Get pickle List and featureNames list
/...mypath/eda-explorer-master/load_files.pyc in loadData_E4(filepath)
58 sampleRate = float(data.iloc[0][0])
59 data = data[data.index!=0]
---> 60 data.index = data.index-1
61
62 # Reset the data frame assuming 4Hz samplingRate
/usr/lib/python2.7/dist-packages/pandas/core/index.pyc in __sub__(self, other)
1161 warnings.warn("using '-' to provide set differences with Indexes is deprecated, "
1162 "use .difference()",FutureWarning)
-> 1163 return self.difference(other)
1164
1165 def __and__(self, other):
/usr/lib/python2.7/dist-packages/pandas/core/index.pyc in difference(self, other)
1314
1315 if not hasattr(other, '__iter__'):
-> 1316 raise TypeError('Input must be iterable!')
1317
1318 if self.equals(other):
TypeError: Input must be iterable!
I don't get this error message on my windows PC. I'm using pandas version 0.15.0 in the ubuntu environment. Is this perhaps the problem that the particular syntax related to the index is only allowed in higher versions of pandas? How should I correct the syntax so that it works with older version of pandas? Or am I missing the point?
Try data.index = pd.Index(data.index.values-1) instead of data.index = data.index-1.

How to debug a raw binary with gdb

I have a executable for an embedded device.
It does not have header information that gdb recognizes, but instead uses a proprietary header specified by the vendor.
I can analyse the file just fine using IDA-pro, but I'd like to run some code to see what it does.
The executable is loaded at address 0x52000000
However if I just load the file using
exec-file myfile
I get
"myfile": not in executable format: File format not recognized
And if I restore the memory at the correct location using:
restore myfile 52000000
I get:
You can't do that without a process to debug.
How do I get out of this chicken-and-egg problem?
I just want to jump in the middle of the code, set some registers to predetermined values and run some code to see what happens.
Note that I'm using the gdb ARM toolchain from ARM itself.
As per #artless_noise suggestion I did the following:
objcopy.exe
--output-target=elf32-bigarm
--input-target=binary
--change-start=0x52000000
INPUTFILE OUTPUTFILE
This adds an elf header to the file.
However it does not fix the whole problem.
The output of
readelf.exe -a OUTPUTFILE
gives:
ELF Header:
Magic: 7f 45 4c 46 01 02 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: REL (Relocatable file)
Machine: ARM
Version: 0x1
Entry point address: 0x52000000
Start of program headers: 0 (bytes into file)
Start of section headers: 57316 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 5
Section header string table index: 2
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .data PROGBITS 00000000 000034 00df8c 00 WA 0 0 1
.....
Note that the .data section still has an address of 0x00000000. This should be 0x52000000.
To fix this I opened up a hex editor at address 0xdf8c.
This is close the where the section headers are.
The structure of the section headers is as follows, along with the data I expect to be there.
typedef struct {
Elf32_Word sh_name;
Elf32_Word sh_type; = 1 {.data}
Elf32_Word sh_flags; = ?
Elf32_Addr sh_addr; = 0x00000000
Elf32_Off sh_offset; = 0x00000034
Elf32_Word sh_size; = 0x0000df8c
Elf32_Word sh_link;
Elf32_Word sh_info;
Elf32_Word sh_addralign;
Elf32_Word sh_entsize;
} Elf32_Shdr;
The first header is always all zeros, the second header is the .data section.
So I look for the magic numbers and fill in the starting address, save the file and reload it into gdb.
Now it works