After writing a program in C language, I tried to create an executable file by gcc and analyze it binary, but for the following program, the strings command will print the string "hoge".Therefore, I would like to prevent it from being printed, but what kind of method should I use?I think you can save it to a txt file, but I would like to make it a download file as a binary analysis problem, so I asked you because I thought it would be easy to download the txt file.
#include<stdio.h>
# include <string.h>
int main (void)
{
char buf [32];
char key [ ] = "hoge";
puts("Please input password.");
fgets(buf,sizeof(buf),stdin);
strtok(buf, "\n");
if(!strcmp(buf,key)){
puts("Congratulations!");
}
else{
puts("Invalid input.");
}
return 0;
}
It's a little off the rails, but the respondents are also wrong, so I'll supplement it as an important thing.K&R 2nd 4.9 Initialization also
Character arrays are a special case of initialization; a string may be used installed of the braces and communication:
char pattern[] = "should";
is a short for the longer but equal
char pattern[]={'o', 'u', 'l', 'd', '\0'};
As described in , even if you write one character at a time in the source code, it has the same meaning in terms of language specifications.
Now, the answer is, why don't you take a step further from here and flip the ~ bits of each character?
At runtime, you can restore the value by reversing the bit again.Of course, XOR in a particular bit pattern is possible, even if it is not ~.
char key[] = {~'h',~'o',~'g',~'e','\0'};
for(inti=0;i<4;i++)key[i]=~key[i];
This is a quick fix to the "parse using the strings command" question.
For example, MSSQL Server has a vulnerability that allows all users to view raw passwords to leak memory during program operation.
In the implementation where the obfuscation of the executable is also program-started by decrypting it at the start of execution, it is easy to obtain the pre-obfuscation executable if the process is paused and the memory image is dumped upon completion of decryption.
Based on these examples, it may be better to review the extent to which countermeasures should be attempted.
What I really want to do is obfuscate executable files, not specific to strings, but I will continue to follow the question title.
Prerequisites
- Do not change source code significantly
- string does not appear
Plan 1. Put it in Japanese
strings does not display Japanese strings, so strcmp(buf, "hage") would be fine.
Proposed 2. Make it wide
If you convert the input characters to char→wchar_t to wcscmp(buf, L "hoge"), strings a.exe will no longer display hoge.However, it appears in strings-ela.exe.I don't think it will work for people I know.
Proposition 3. Use obfuscation and compression tools
In the MS-DOS era, tools that compress EXE files and deploy themselves at boot time were popular.When compressed, the contents of strings are messy.Don't you see it often now?When I looked for it, I could only find upx and other super old ones.
Obfuscator, a obfuscator, is widely used in the .NET world, but it doesn't seem to be common in the native world. For the time being, I searched a little and found PELock or https://www.pelock.com
Proposition 4. Base64 or uuencode strings that you don't want to see directly before compiling
On the source code, for example, strcmp(buf, unbase64(BASE64IZE("hoge"))).
- BASE64IZE() replaces the source with a macro or tool that converts base64 before compiling
- unbase64() creates a function that reverses base64 at runtime
If you specialize in Windows, you can base64/uuencode the string resource and restore it after LoadResource.You can zip a text file containing a password and remove the header.I can do as much as I want.The rest is just a matter of cost performance.
--- Add below ---
If you don't want to show the raw password string, try implementing the salt + cryptographic unidirectional hash (+stretching) that has already been established as a password system.One fixed salt plus a fixed hash is enough (you'll hear here and there that it's enough without salt)
if you want to take action against easy detection with the strings command.
Why don't you do the following briefly?
char key[] = {'h', 'o', 'g', 'e', 0};
When I checked with the strings command, hoge disappeared.
However, for at least gcc, it also depends on the options as follows:
cc-Stest.c:
movb$104,-53(%rbp)
movb$111, -52 (%rbp)
US>movb $103, -51 (%rbp)
movb $101, -50 (%rbp)
US>movb $0,-49 (%rbp)
↑There is no problem with this, but
For cc-O2-Stest.c:
movl $1701277544,11 (%rsp)
↑When I optimized it, I could see hoge.
luna:~%cc --version
cc(GCC) 7.2.1 20171128
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
As the comment says, -fno-store-merging can suppress this behavior, but
because it affects other parts of the same .c file.
If you use this option, you should separate this part into a separate .c file.
I think so.
© 2024 OneMinuteCode. All rights reserved.