Call a WINAPI Function from a shared object(.so) that is loaded into the wine process - reverse-engineering

I have a windows program that is run under wine. If i understand correctly, the pe-executable is mapped into the wine process.
I use LD_PRELOAD to load a .so into the wine process. This .so hooks into the vulkan rendering pipeline. That makes me able to execute code in the winows programĀ“s main thread.
From there i would now like to call a WINAPI function as if it was called by the windows program. For example GetModuleHandle() from kernel32.dll. But i do not know how to retrieve the address of it.
Is there any possibility to access functions from the dlls that got loaded by wine or windows program?
If i use dl_iterate_phdr the only library i find that seems to have to do with windows is ntdll.so

Related

Octave runs but graph not displayed

num=[1];
den=[1 3 1];
G=tf(num,den);
H=1;
T=feedback(G,H);
step(T);
hold on;
Kp=23;
Ki=0;
Kd=0;
C=pid(Kp,Ki,Kd);
T=feedback(C*G,H);
step(T);
When run this script nothing happen in Octave but works fine in octave-online.net
online octave
Octave Windows
I will put a proper answer here for future users, even though OP has already solved their problem from the comments.
octave-online.net is an excellent cloud service providing an instance of octave on the cloud.
Contrary to a typical installation of octave on linux or windows, the octave-online client autoloads some of the more popular packages, one of which is control.
You can confirm this by typing pkg list in the octave-online console.
In your normal linux / windows installation however, this needs to be loaded explicitly before use, e.g. in the case of the control package, by doing pkg load control.
Your code uses the functions feedback and pid, both of which rely on the control package, therefore in your windows instance, your code failed, because you tried to use these functions without loading the package first.
Presumably there was also an error in your terminal informing you of this fact, that you may have missed.

Communication between 2 Maya plugins

I am developing 2 Maya plugins in C++ and would like to call a function in plugin #1 from plugin #2 and send parameters along with the function.
The caller plugin is an MPxNode and the called plugin should be "general" functions whose role are to create some rendering VRayPlugins.
How should I proceed to declare and call the appropriate functions ?
Maya plug-ins are not different from standard DLL whether you run on Windows, OSX, or Linux. There is multiple approach you can use here. You can link the utility dll to your plug-in, and as long the OS can find it, it will be loaded in Maya address space whenever the plug-in loads in Maya (like any DLL, including the Maya DLLs). The other way is to export symbols from the DLL, but link the function/class at runtime (LoadLibrary() / GetProcAdress()). This time, you need to load the utility DLL yourself, and search for the export signatures before calling them. For these 2 methods, this is standard C++ programming, nothing special regarding Maya.
Now if you work with the Maya DG, you could also think about MMessage / MPxNode to transport and evaluate data. This is specific to the Maya DG and API. But I am not sure you need that level of complexity for what you described above.

Box-API: How can I add a strong name to a 3rd party assembly written for the .NET Portable Subset

I am trying to strongly name a 3rd party API that I have the code for but it's using a 3rd party DLL/NuGet Package that is also not strongly named and I'm having a lot of trouble.
I'm using the Box Windows SDK and the API was written in the .NET portable subset and supports .NET for Windows Store Apps, .NET Framework 4 and higher, SL4 and higher, and Windows Phone 7 and higher. Granted, I do not need all of these but I do need the .NET 4 and Silverlight versions. The API already works wonderfully and runs fine on its own. It would with my application also, if all my projects were unsigned but they aren't. We use strongly named assemblies for our Silverlight application in order to make use of application library caching.
Anyway, I have the source code for the API so I simply added my PFX file to the project to sign it. I then get an error that a dependency that this API is using called NitoAsnycEx.dll is not signed. I do not have the code for Nito.AsyncEx.dll but normally this isn't such a problem, more of an annoyance. So now I have an age-old problem of needing to take a 3rd party DLL of which I don't have code for and sign it with my PFX or another SNK file.
I can do either and normally I use one of the processes so wonderfully explained in this post by Ian Picknell: http://ianpicknell.blogspot.com/2009/12/adding-strong-name-to-third-party.html. So I have followed that process and the IL signing tools seem to sign the DLL just fine.
To make a long story shorter, let's use the simplest version of the signing process where I already have a simple SNK file ready to go. Basically, I do this:
I can run ILDASM to get the .il file for this 3rd party EXE:
ILDASM Nito.AsyncEx.dll /out:Nito.AsyncEx.il
I can then run ILASM to get the signed DLL:
ILASM Nito.AsyncEx.il /dll /resource=Nito.AsyncEx.res /key=NPSAssemblyKeyNoPassword.snk
It works great and I get this result:
Method Implementations (total): 118
Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Signing file with strong name
Operation completed successfully
So now I have a signed DLL. I go back to my 3rd Party API code and remove the old reference to NitoAsyncEx.dll and put a new one to this. I try to compile and then I get an error like this:
Error 44 The base class or interface 'System.Object' in assembly 'System.Runtime, Version=1.5.11.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' referenced by type 'Nito.AsyncEx.AsyncLock' could not be resolved r:\Data\GM\Source\GrantManagement\GrantManagement\3rd Party\Nito\Nito.AsyncEx.dll
I figure there is some problems using the portable .net library here but I'm not sure what it is. This same process normally works for me for Silverlight 4+ and Full .NET 4.5 framework libraries. Is there another ILASM or ILDASM set somewhere that will disassemble and reassemble the portable code correctly? Is this even possible?
I also tried to go and get the source code for the NitoAsyncEx.dll, which is open source btw, and compile it but that source code will not compile as it's missing some files. So currently I'm stuck with my integration of this API into my project and need a little assistance from any experts in the community.
Is there a way to sign this DLL correctly so we're not missing references to basic classes such as System.Object?
Is there a way to get around needing to sign this DLL at all and having it referenced from my projects?
UPDATED
The Box SDK has been updated and is now strong-named on nuget. This is thanks to the recent update to AsyncEx which strong-named the assembly.
As you mentioned, it's unfortunately out of our control that the NitoAsyncEx library is not strongly named. This library provides the ability to properly lock resources during an async/await call, and I do not believe there is a better alternative at the moment.
This being said, I may have a (hopefully temporary) workaround for you. I've downloaded the source from https://nitoasyncex.codeplex.com/ and was able to get it to compile. These are the steps I performed:
Removed the reference to MSBuild in the csproj
Copied the missing Dequeue.cs file from the packages folder
Resolved missing nuget references
Regenerated the AssemblyInfo.cs
Excluded the .tt template files from the project
Unloaded all other projects the SDK does not use
Here's the resulting solution:
https://cloud.box.com/s/7ikurtyajqmhq9p8q52x
I've successfully ran the resulting dll through the SDK's tests so hopefully this should cover what you need. I cannot guarantee the stability of this method, but having a working source should allow you to do any signing you need. From there, you should be able to drop the signed assembly into the SDK source and sign that assembly as well.

Using stl in an Android adb shell native program

I'm trying to port a C++ utility program that I want to be run from the Android ADB shell.
For that, I'm using the Android NDK's make-standalone-toolchain.sh script, and compiling my program with it.
Unfortunately, when I try to run it, I get this error:
reloc_library[1315]: 16304 cannot locate '_ZNKSs5c_strEv'...
CANNOT LINK EXECUTABLE
After some research, I saw that this means that the c_str function doesn't exist in libstdc++.so in the NDK. I also couldn't find the symbol in stlport.so either, and actually only found it in the ./sources/cxx-stl/gnu-libstdc++/libs/ version of the C++ libraries. These libraries are not included in the standalone toolchain I made, and I also couldn't find them on the device (the device is running Honeycomb).
The text in the NDK clearly states that there's support for the entire STL when I use stlport. Is this something that is only true in Ice Cream Sandwich? The libstlport.so or in libsupc++.so on the device and in the NDK didn't have any signature like the one that wasn't found.
So my question has two parts:
Is there something I'm missing in the build process/Android setup? Can I set up things differently so that the program will compile without needing the gnu-libstc++, or at least fail with a compilation/link error instead of failing to load on the device?
If linking with gnu-libstc++ is the only way, how can I do that? I think I can manage statically link to it but I'd rather not.
How can I add the gnu-libstdc++ version to my
If someone else is looking for a solution, I ended up adding a dependency using the -l switch on libgnustl_shared.so. You can find it inside the NDK at
sources/cxx-stl/gnu-libstdc++/libs/&ltarchitecture&gt/
I then pushed this .so together with the program to the device, and made a script that adds the current directory to LD_LIBRARY_PATH. It seems similar to what the NDK does when you use the make scripts to create a program that depends on gnustl.

Remote CUDA profiling?

Is it possible to remotely execute a CUDA profile execution (similar to computeprof) and then bring the profile back for analysis?
The particular remote machine is headless and not-under-my-control, so no X, no Qt libraries, etc.
Yes you can. The CUDA driver has built-in profiling facilities. How to do it is discussed in the Compute_Profiler.txt file you will find in the doc directory of the toolkit, but the basic idea is something like this:
$ COMPUTE_PROFILE=1 COMPUTE_PROFILE_CSV=1 COMPUTE_PROFILE_LOG=log.csv COMPUTE_PROFILE_CONFIG=config.txt ./app
which tells the runtime to turn on profiling, use csv format output written to log.csv, including the profile statistics read from config.txt. After the app has run, the runtime will drop an output file with the raw profiling results in them. You can then use the tool of your choice to look at them. The visual profiler can be convinced open to the output, but a lot of the fancy synchronization it does requires the output to be generated using its own profile configuration files (under the hood it is dynamically doing the same thing you do manually, but on the fly). I have done some digging around and scraped copies of the configuration files so I could regenerate specific application profiling runs without the profiler on headless cluster nodes. Not too much fun, but it can be done.