Defense Strategies Against Automated Analysis in Cybersecurity

Remaining topics: Anti X techniques Debuggers Malware Embedded web browsers and the XCS problem Tools

anti X techniques X = disassembly

simple and obvious defense through to the technically impressive change names / case so string comparison fails T y p i c a l a lot of defensive software just looks for patterns, or at best, regular expressions over some patterns, then they regularly update the list of known patterns; much of this is passive/embedded happens automatically change structure / encoding, location so FSM s can t find it a r m s some allow more syntactical as well as lexical patterns, logic and conditionals, memory, PDA often wrapped in a tool run on demand use input which causes well known R.E tools to break Some are R.E. environments: IDA Pro, Ghidra, set in a crafted, safe environment, for project-scale analysis of issues/patterns/malware r a c e use complex obfuscation which can cause well- known people to break https://sensorstechforum.com/advanced-obfuscation-techniques-malware/

packing/unpacking dead code insertion function reordering poly/metamorphic instruction byte sharing hiding code, but hiding it from what? change the fingerprint so a table lookup fails? (table of known malware) through to trying to hide function from an educated and dedicated sleuthing effort

https://sensorstechforum.com/advanced-obfuscation-techniques-malware/https://sensorstechforum.com/advanced-obfuscation-techniques-malware/ https://youtu.be/KTfrbvxKQwo?t=133 marketing angle: https://www.youtube.com/watch?v=OErWn-0KTis

anti disassembly use specially crafted code and data to cause disassemblers to produce incorrect assembly language often used by malware to avoid (delay) analysis another arms race, raises the bar for the analyst

The call instruction generates a pointer to the string (supposedly the return address) pop delivers it to %eax Incorrect IdaPro (RD) disassembly: ASCII values h e l l o

For both linear and RD, take advantage of the defaults and choices cmpl jz jnz L1 $1, %eax L1 Commonly seen in the wild in malware This is really an unconditional jump but it is not recognized as such malware will load up the false branch since it won t be taken

The jumps go one byte past 0xe8, but the RD default is to name it a call instruction

The interactive techniques for RD disassemblers show both branches and wait for the user to make a decision whether or not to trust the chosen branch

Something harder than a rouge byte No disassembler currently on the market will represent a single byte as being part of two instructions, yet the processor has no such limitation FF is part of two instructions, both of which execute The target of the jump is the second byte of itself which is a valid first byte for the 2-byte instruction inc %eax

IdaPro RD produces:

Function pointers reduce the amount of information that can be deduced about program flow Use a lot of them and combine with other anti-X techniques to greatly increase the difficulty of reverse-engineering

Abusing return pointers call pushed the address of the following byte, then jumps to its target ret pops the stack and jumps to whatever address popped off They are normally balanced, but there is nothing to stop someone using ret for other flow control the disassembler won t show any code cross- reference to the target being jumped to. the disassembler will prematurely terminate the function.

anti X techniques X = ASCII (inter alia (but really just ASCII (mostly)))

float f; f = 1.2345; printf( %f , f); float f; f=1.0; printf( %4.2f ,f); float f; f=123456.0; printf( %6.4f ,f); outputs 8 bytes: $ ./y 1.234500 outputs 4 bytes: $ ./y 1.00 outputs 11 bytes: $ ./y 123456.0000 $ ./y | wc c 8 $ ./y | wc c 4 $ ./y | wc -c 11 ASCII encoded vs binary float f; srand(time(0)); f = (float) rand(); write(1, &f, sizeof(f)); always outputs 4 bytes (on this platform) regardless of the value in f remember that?

STRINGS(1) GNU Development Tools STRINGS(1) NAME NAME strings - print the sequences of printable characters in files SYNOPSIS SYNOPSIS strings [- -afovV [- -n n min-len] [-- [- -t t radix] [-- [- -e e encoding] [-- [- -] [-- [- -T T bfdname] [-- [- -w w] [-- [- -s s] [-- [-- --help afovV] [- -min-len] --bytes= bytes=min-len] --radix= radix=radix] --encoding= encoding=encoding] all] [-- --print print- -file file- -name --target= target=bfdname] --include include- -all all- -whitespace whitespace] --output output- -separator separatorsep_string] help] [-- --version version] file... --all name] DESCRIPTION DESCRIPTION For each file given, GNU strings sequences that are at least 4 characters long (or the number given with the options below) and are followed by an unprintable character. to either displaying all the printable sequences that it can find in (Show me any ASCII in this binary) strings prints the printable character Depending upon how the strings program was configured it will default

Show me any ASCII in this binary? Take care to make sure that none shows up Avoiding leaving ASCII strings, even in executables Move ASCII into an executable. Instead of leaving: leave the binary from: x.c main(argc, argv, envp) int argc; char **argv, **envp; { FILE *f; f = fopen( .script , w ); fprintf(f, #!/bin/sh\n#\n\n ); fprintf( wget http:// \n ); #!/bin/sh # wget http://..... chmod 777 . //and maybe system( script ); }

Avoiding leaving ASCII strings, even in executables $ cc -S x.c $ cat x.c #include <string.h> int main() { char pwd[64]; if (strcmp(pwd, "ABCDEFG1234!") == 0) {} } $ cat x.s .file "x.c" .text .def __main; .scl 2; .type 32; .endef .section .rdata,"dr" .LC0: .ascii "ABCDEFG1234!\0" .text .globl main .def main; .scl 2; .type 32; .endef .seh_proc main main: pushq %rbp $ cc -o x x.c $ strings x | head -20 !This program cannot be run in DOS mode. v _a .text @B/70 B/81 tgr5 ABCDEFG1234! GCC: (GNU) 7.4.0 20181206 (Fedora Cygwin 7.4.0-1)

cover tracks historical interpretation - hiding files log files, maybe network based app specific ghost process Avoiding leaving ASCII strings, even in executables If it s in an executable, move onto the stack: #include <stdio.h> $ cat x2.c #include <stdio.h> int main(argc, argv, envp) int argc; char **argv, **envp; { printf("#!/bin/sh\n#\n"); printf("user: root\n"); printf("password: mypass\n"); int main(argc, argv, envp) int argc; char **argv, **envp; { char str0[1024], str1[1024], str2[1024]; str0[0]=0x23; str0[1]=21; str0[1]=0x2f; str0[3]=0x62; str0[4]=0x69; //printf("#!/bin/sh\n#\n"); printf("%s\n", str0); } $ cc -o x2 x2.c $ strings x2 /lib64/ld-linux-x86-64.so.2 Puts #!/bin/sh user: root password: mypass ;*3$" GCC: (Debian 10.2.0-5) 10.2.0 crtstuff.c deregister_tm_clones change to } $ cc -o x2 x2.c $ strings x2 /lib64/ld-linux-x86-64.so.2 puts __cxa_finalize __libc_start_main libc.so.6 GLIBC_2.2.5

cover tracks historical interpretation - hiding files log files, maybe network based app specific ghost process The depth of the game can continue: strcpy(a, ABC ); a[0]= A ; a[1]= B a[2]= C get beyond typical, or expected, levels of effort a[0]=0x41; a[1]=0x42; a[2]=0x43; char *x; x = &(a[2]); x[1]= ((f() + 1) + 1)

Anti-X X= Java decompilation Stopping (or trying to stop) Java decompilation Probably the biggest reason people use them is to solve technical issues Once it s in the wild though, reconstituted source code can cause problems Good documentation and a solid EULA can help a lot

Anti-X X= Java disassembly 1. Obfuscation Move .data section stuff to run time Use hexadecimal format extensively (avoid food for strings(1) ) Use direct heap addresses Add unnecessary conditional jumps (goto spaghetti) Add garbage code Metamorphosis replace straightforward code with complex Change static libraries to dynamic to thwart strings(1) Code packers break signatures expected by readelf and similar Add indirection 2. Encrypt your classes with a private key, and use a custom classloader to decrypt your classes with a public key before loading into memory 3. or just try to crash the decompiler tools like ProGuard, Yguard

Anti-X X= Java disassembly None are insurmountable however Deploy it as a Saas so that your code is never present on the end user machine

Destroying stack frame patterns https://reverseengineering.stackexchange.com/questions/2105 2/anti-disassembler-techniques-and-ida-pro