8000 need some info regarding some #define · Issue #11 · DosX-dev/obfus.h · GitHub
[go: up one dir, main page]
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

need some info regarding some #define #11

Closed
zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a opened this issue Nov 29, 2024 · 3 comments
Closed

need some info regarding some #define #11

zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a opened this issue Nov 29, 2024 · 3 comments
Labels
good first issue Good for newcomers question Further information is requested

Comments

@zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
Copy link

it is obvious whats the usage of "ANTI_DEBUG", but what about "NOP_FLOOD"?

another thing is with "__CRASH", would you recommend it over abort, exit, or exitprocess? or it is for future use as it is currently not used at all.

what about "ANTITAMPER", how is it going to prevent tampering with code?

last thing, do you recommend:
#define NO_CFLOW 0
#define NO_ANTIDEBUG 0

or

completely remove NO_*?

cu 8000 rrently it is same whether it is defined as 0 or completely removed, but the question is really for future consistency if for example other switches in the future may accept other values.

thank you.
@DosX-dev DosX-dev added good first issue Good for newcomers question Further information is requested labels Nov 29, 2024
@DosX-dev
Copy link
Owner

Hello, @zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a! Thank you for your questions; they are quite relevant. I’ll address them in the same order.

it is obvious whats the usage of "ANTI_DEBUG", but what about "NOP_FLOOD"?

The NOP_FLOOD macro is designed exclusively for use within the obfus.h library. It acts as auxiliary obfuscation functionality, similar to the BREAK_STACK_* macros.

another thing is with "__CRASH", would you recommend it over abort, exit, or exitprocess? or it is for future use as it is currently not used at all.

__CRASH deliberately causes a program crash through intentional failure, rather than a proper exit. This is meant to protect critical sections from hooking functions like ExitProcess() or exit(). Whether to use it depends on your goals, but if it’s undocumented, consider whether it’s necessary for your case.

what about "ANTITAMPER", how is it going to prevent tampering with code?

This feature is currently in the conceptual stage and might even be removed. The original idea was to assign an N-flag within control flow obfuscation and validate it during execution. If any condition was skipped, the program would crash. The implementation, however, remains undecided.

last thing, do you recommend:
#define NO_CFLOW 0
#define NO_ANTIDEBUG 0
or
completely remove NO_*?

If you don’t plan to disable any obfuscation features, it’s cleaner to omit the NO_* macros entirely. Initially, I considered general macros like CFLOW_LVL with values from 0 to 2 (0 - disabled, 1 - default, 2 - enhanced). However, this approach could confuse users, who might think arbitrary values are allowed or that removing a declaration disables the feature.

To avoid this confusion, I opted for two clear options: disable the feature or enable a stronger mode. The default medium level doesn’t require explicit settings or declarations.

It’s worth noting that the example code provided in the documentation intentionally includes all settings to demonstrate the full range of configurations available. However, in real-world use, the code can be significantly simplified by omitting unused options or relying on defaults.

For future consistency, if additional switches are introduced, you can always expand or adapt the NO_* macros. That said, for now, whether to declare them as 0 or omit them entirely is up to you and depends on your coding preferences.

@zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a
Copy link
Author

thank you for your detailed answer, i like the feature_lvl [0..2], but i agree that it can confuse some users.

i have 1 more question:

https://github.com/DosX-dev/obfus.h/blob/main/include/obfus.h#L88
"#if defined(FAKE_SIGNS) && (FAKE_SIGNS != 0)"

why did you use this combination, why not straight to #if FAKE_SIGNS != 0?

this could also open 1 more question for future use, like:
the usage of #define without any values, i.e. #define FAKE_SIGNS without the need to provide any specific value.

so far this is the only inconsistency i found in macro switches.

thank you again, and you may close this issue after explaining the statement above.

@DosX-dev
Copy link
Owner

Really. This code can and should be simplified. Thank you!

DosX-dev added a commit that referenced this issue Dec 12, 2024
@DosX-dev
#11
475c72a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
good first issue Good for newcomers question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@zmn28hgbn59kcmlpio8unfh7fdre523esd28q9a @DosX-dev
0