I have a function I want to bounce to shellcode. for ease of use in the future, i'd like to not have to separately compile it or induce strict compiler settings on projects that may use it.
I have 3 things i'd like to do
disable JMC _CheckForMyDebugger call generation
disable _Check_ESP call generation (done with __declspec(safebuffer))
disable function comdat linking/jmp function linking
All on a per function basis, any clues into what I can use to do this using MSVC?
If you found this question, through hours of searching here's what I've figured out:
Declare functions with __declspec(safebuffers) and wrap them in the following pragma defines :
#pragma runtime_checks( "", off )
[function here]
#pragma runtime_checks( "", restore )
This removes the ESP checks
As for JMC and comdat linking, you must adjust the project settings. Unfortunately MSVC doesn't offer settings to adjust those on a per-function basis.
Related
Say there is a single warning such as path_statements, unused_variables. Is there a way to ignore a single instant of this, without isolating them into a code block or function?
To be clear, when there is a single warning in the code. I would like the ability to quiet only that warning, without having to do special changes addressing the particular warning.
And without this quieting warnings anywhere else, even later on in the same function.
With GCC this can be done as follows:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wformat"
/* Isolated region which doesn't raise warnings! */
this_would_raise_Wformat(args);
#pragma GCC diagnostic pop
Does Rust have the equivalent capability?
Note, am asking about the general case of how to quiet warnings.
Am aware there are ways to resolve unused var warning for eg.
To silence warnings you have to add the allow(warning_type) attribute to the affected expression or any of its parents. If you only want to silence the warning on one specific expression, you can add the attribute to that expression/statement:
fn main() {
#[allow(unused_variables)]
let not_used = 27;
#[allow(path_statements)]
std::io::stdin;
println!("hi!");
}
However, the feature of adding attributes to statements/expressions (as opposed to items, like functions) is still a bit broken. In particular, in the above code, the std::io::stdin line still triggers a warning. You can read the ongoing discussion about this feature here.
Often it is not necessary to use an attribute though. Many warnings (like unused_variables and unused_must_use) can be silenced by using let _ = as the left side of your statement. In general, any variable that starts with an underscore won't trigger unused-warnings.
If you want to silence all warnings of a kind in a module, write e.g. #![allow(dead_code)] (note the exclamation mark) at the top of the module. This will disable all warnings of this kind in the whole module. You can also call rustc with e.g. -A dead_code.
You can disable all warnings by writing #![allow(warnings)] at the top of the module.
You can insert a module (as described in the Rust book) where the specific warnings are ignored.
As Lukas said, you can also write e.g. #[allow(dead_code)] on a statement or an expression.
I have a project that includes some performance sensitive native C++ headers making heavy use of templates. For this project we also wrap the headers and add some glue code to expose the functionality to c# and other .NET languages. We'll call this header "layout.h", and we'll assume it's a third party header that I can't change.
In a mixed mode C++/CLI assembly it is relatively easy to make a mistake and #include from a place in the code where #pragma unmanaged (or #pramga managed(push,off) ) . When that happens the templates generate IL, and I get extra managed/unmanaged transitions when running the code and performance goes down the drain.
My question is whether there is a way I can do a compile-time check just before the #include so that compilation fails if I am accidently #including from the wrong context.
// File1.cpp, compiled in a mixed mode C++/CLI assembly with /clr
ASSERT_UNMANAGED()
#include <layout.h>
My naive 1st attempt checked #ifdef _MANAGED, but that is always defined whether I'm in a #pragma unmanaged block of code or not.
The pragma directives must be inserted directly in the include file. In this way, everywhere you include the file an unmanaged section is declared.
Sorry that you have to modify your include file.
You may write ASSERT_MANAGED or ASSERT_UNMANAGED code that would use construct that is available ONLY while compiling managed or unmanaged. A ref class declaration is an example which is avaiable only when using managed.
This is somewhat a dirty solution, but it would work.
Here's a possible solution, making use of the fact that intrinsics are always compiled as native (unmanaged) code:
#include <intrin.h>
#define ASSERT_UNMANAGED() \
int TestFunc(void) { \
__pragma(warning(push)) \
__pragma(warning(error:4793)) \
auto aumt = [] () { return _bextr_u64(65537, 0, 8); }; \
__pragma(warning(pop)) \
return int(aumt()); }
#pragma unmanaged // Comment out this line and the assertion fails!
ASSERT_UNMANAGED()
#pragma managed
EDIT: Of course, if you just want warnings rather than compilation failure, you can remove the 3 __pragma(warning()) lines.
To avoid multiple includes of a header file, one of my friend suggested the following way
#ifndef _INTERFACEMESSAGE_HPP
#define _INTERFACEMESSAGE_HPP
class CInterfaceMessage
{
/ /Declaration of class goes here
//i.e declaration of member variables and methods
private:
int m_nCount;
CString m_cStrMessage;
public:
CString foo(int);
}
#endif
where _INTERFACEMESSAGE_HPP is just an identifier
but when i declare a class using visual studio 2005 IDE I get a statement as
#pragma once
at the starting of the class definition
when i took the help of msdn to find the purpose of #pragma once
it gave me the following explanation
"Specifies that the file will be included (opened) only once by the compiler when compiling a source code file. "
Someone please tell which is the right approach?, if both are correct then what is the difference? is one approach is better than the other?
gcc has pragma once as deprecated. You should use the standard include guards. All pragma directives are by definition implementation defined. So, if you want portability, don't use them.
Pragmas are compiler-specific, so I'd use #ifndef.
Preprocessor directives are resolved during (actually, before) compilation, so they do not make a difference in runtime except maybe for compile time.
However, you will never notice a difference in compile time from these two alternatives unless you use them several thousand times I guess.
The first approach is the generic approach that works with all compilers and is also the older one around. The #pragma once approach is compiler specific.
I'm starting a new BREW project, and I'd like to compile with Warning Level 4 (/W4) to keep the application code nice and clean. The problem is that the BREW headers themselves don't compile cleanly with /W4.
In gcc you can differentiate between application and system headers by using -I and -isystem, and then by default gcc doesn't report any compilation warnings in system headers. Is there an equivalent mechanism in Visual C++?
Use this method around (a) header(s) that you cannot or don't want to change, but which you need to include.
You can selectively, and temporarily disable all warnings like this:
#pragma warning(push, 0)
// Some include(s) with unfixable warnings
#pragma warning(pop)
Instead of 0 you can optionally pass in the warning number to disable, so something like:
#pragma warning(push)
#pragma warning(disable : 4081)
#pragma warning(disable : 4706)
// Some code
#pragma warning(pop)
Visual C++ team has just added support for warning levels in external headers. You can find the details in their blog post: Broken Warnings Theory.
In essence it does automatically what the suggestions here were recommending to do manually: pushes new warning level right before #include directive and pops it up right after. There are additional flags to specify locations of external headers, flag to treat all <> includes as external, #pragma system_header and a feature not available in Clang or GCC (as of this writing) to see warnings in external headers across template instantiation stack when the template was instantiated in the user code.
Besides the comments under that post, you can also find some useful discussion in a reddit announcement for that post.
I don't believe Visual C++ lets you differentiate. You can fake it by using #pragma warning around the include:
#pragma warning(push, 0)
#include "mywarningheader.h"
#pragma warning(pop)
It seems like there is an answer to this.
this post talks about /external:I that can be used to include headers with a special set of warnings.
I have not tested it myself, but the blog post is from 2017.
The /external:anglebrackets /external:W0 compiler flags disable warnings on the headers imported with #include <...>.
You can change the W0 to W1, W2, W3, or W4, to set a different warning level for those.
This is part of a series of at least two closely related, but distinct questions. I hope I'm doing the right thing by asking them separately.
I'm trying to get my Visual C++ 2008 app to work without the C Runtime Library. It's a Win32 GUI app without MFC or other fancy stuff, just plain Windows API.
So I set Project Properties -> Configuration -> C/C++ -> Advanced -> Omit Default Library Names to Yes (compiler flag /Zl) and rebuilt. Let's pretend I have written a suitable entry point function, which is the subject of my other question.
I get two linker errors; they are probably related. The linker complains about unresolved external symbols __fltused and _memcpy in foobar.obj. Needless to say, I use neither explicitly in my program, but I do use memcpy somewhere in foobar.cpp. (I would have used CopyMemory but that turns out to be #defined to be identical to memcpy...)
(I thought I could get rid of the memcpy problem by using a compiler intrinsic, like #pragma intrinsic(memcpy), but this makes no difference.)
If I look at the preprocessor output (adding /P to the compiler command line), I see no references to either __fltused or _memcpy in foobar.i.
So, my question is: Where do these linker errors come from, and how do I resolve them?
__fltused implies you are using or have at least declared some floats or doubles. The compiler injects this 'useless' symbol to cause a floating support .obj to get loaded from the crt. You can get around this by simply declaring a symbol with the name
#ifdef __cplusplus
extern "C" {
#endif
int _fltused=0; // it should be a single underscore since the double one is the mangled name
#ifdef __cplusplus
}
#endif
WRT _memcpy - memcpy is a __cdecl function, and all cdecl functions get an automatic _ as part of their decoration. so, when you say "__cdecl memcpy" - the compiler & linker go looking for a symbol called '_memcpy'. Intrinsic functions - even explicitly requested - can still be imported if the build settings have debug settings that contra-indicate intrinsics. So you are going to need to implement your own memcpy and related functions at some point anyway.
I recommend setting the "generate assembly listing" (or some such) compiler option for foobar.cpp once, and then inspecting the assembler code. This should really tell you where these symbols are used.