What is this and what is it purpose. I notice that when i compile my console apps in c++ is dynamically links it. I'm just curious what purpose this file serves and is it exploitable in the sense that if it has to be on every ones machine to run c code , is there some way for Microsoft or some other entity to exploit it for malicious ends.
That is the Standard C++ Library for native code, here you can read more about these libraries: http://msdn.microsoft.com/en-us/library/8kche8ah%28v=vs.90%29.aspx
Related
I am trying to port an existing C++ application running on linux currently to freertos.
My application has various custom libraries ( prj_lib1, prj_lib2, … prj_lib9) which I wanna link to one .exe(Project_main.exe)
I just need a bit of clarification on how to proceed in this scenario.
Do I need to create freertos static library for each library to link in the Project_main.exe or normal c++ static library should be good enough?
Currently what I am doing is, I have generated Project_main.exe by modifying an existing demo application. And then created normal C++ static library for different libraries which I link in the Project_main.exe.
Is this the correct way to go ahead? Or should I modify existing demo application to generate libraries too?
If there’s some other way please do let me know.
I need to call a function which belongs to a native Android code written in C . i just need one function and the native code is huge. What would be the way to achieve this in best possible way?
Do you mind to disclose the name of the function? I am asking because native non-documented APIs in Android can be crudely divided into three categories: code that is ODM dependent, code that is relatively stable, and code that is unstable or not exported by system libraries.
Regarding the first, you have no choice but to use the device-specific library. Usually, you can download such library from one device, and, not without great care, your library that dynamically links to that system lib, may work on other devices. Typical example is the OpenMAX family of libraries (see for example Creating Android app using OpenMAX library in GB, but showing not found?).
Regarding the second, the purists will download parts of the source tree and compile them into their local shared lib, but the practice of reusing a system lib is widespread (see for example shared memory in android ndk).
For the third, you have no choice but to recompile the AOSP code yourself.
I have dll project in Visual Studio 2012, which is compiled with /MT (static multi-threaded runtime library). It also links third-party static lib, also compiled with /MT (library A), no problem so far.
The problem comes with another static lib (library B), which is unfortunatelly compiled with /MD. In my dll, i need to link both and there is no alternative to any of them (and I cannot recompile them with different option). I was able to successfully link everything together, but now I have problems with memory allocation and deletion - sometimes it fails to delete allocated object, sometimes another weird errors occurs. I believe it's caused by mixed memory managment functions, used by different parts of my dll - when new is called, object is created in library B, but when delete is called, it tries to release memory using different set of functions-, but I might be wrong.
So my question is, is this really caused by mixed memory-managment functions? And if so, is there any way to get this work together?
The only solution I think of is to wrap library B in another dll compiled with /MD and then use it from original dll to ensure different memory managment functions will be used. I'm not sure, if this would help and I would like to avoid it.
You already seem to have understood the cause of the problems you're seeing, and it is described on MSDN as follows
If it's really not possible to get all your linked libraries to use the same version of the CRT, then your only possible choice is to avoid passing CRT objects across the boundaries of these modules. Whether or not you can do this with your scenario is entireley dependent on your application. The crucial point in the above article is this sentence:
If you design your DLL so that it passes CRT objects across the boundary or allocates memory and expects it to be freed outside the DLL, you restrict the DLL users to use the same copy of the CRT library as the DLL. The DLL and its users use the same copy of the CRT library only if both are linked with the same version of the CRT DLL.
I know you've stated that it is not possible to obtain or build compatible modules to link to your application but I would recommend that you revisit this exhaustively and avoid mixing different CRT libraries at all costs.
first things first , i have seen nwsnapshot. and its not helping.
i am building an inventory management system as a desktop app using node-webkit . the project being built is using compoundjs (mvc javascript library). which have a definite folder structure (you know mvc) and multiple javascript files inside them.
the problem is nwsnapshot allows the app to have only a single snapshot file but the logic of application is spread over all the folders in different javascript files.
so how do i secure my source code before shipping it to client? Or any other work-around Or smarter way (yes, i know about obfuscating).
You can use nodewebkit command called nwsnapshot to compile the javascript code into binary which will be loaded into the app without specifying any js file
nwsnapshot --extra-code application.js application.bin
in your package.json add this:
snapshot: 'application.bin'
It really depends on what you mean by "secure".
You can obfuscate your javascript code fairly well (as well as potentially improve performance) by using the Google Closure Compiler.
I'm not aware of any off-the-shelf solutions to encrypt/decrypt your javascript, and honestly I would question the need for that.
Some people think they need to make it impossible to view their source code, because they're used to dealing with compiled languages where you only ship binaries to users. The fact is, reverse-engineering that binary code was never as difficult as some people think it is, so if there's any financial incentive, there is practically no difference between shipping source code and the traditional shipping of binaries.
Some languages have offered genuine encryption of deployed assets, such as Microsoft's SLPS. It seems to me that the market for this was so small that Microsoft gave it to a partner (just my view). The truth is that most customers are not interested in taking your source code; they're far more interested in your ability to service and support that code in an efficient manner, while they get on with their job.
You may consider to merge the JS files into one in the build process and compile it.
Due to MonoTouch using dll's within the actual app, how secure is this approach? For instance, if someone is using the Mono.Security.dll, couldn't someone swap out that dll with one which implemented the methods and perform a code injection attack on an app?
how secure is this approach?
As much as any existing ones I know :-)
couldn't someone swap out that dll
No for several reasons.
You cannot change the applications files. That would break the digital signature and iOS won't execute it. That alone removes a MitM attack;
the code from every .dll is already compiled to native code (by the AOT compiler) and part of the main executable binary. Swapping a new .dll won't change the code that is executed;
the .dll that is deployed on devices is stripped (for release builds). There's no IL (code) inside it since it would not be useful (we can't JIT on iOS). Even if you add a .dll with IL code (e.g. a debug build) it won't be executed (again it would require JITting);
Why are the .dll deployed ? for their metadata (e.g. if you use reflection)
Final note: MonoTouch produce native ARM executables just like Objective-C would.