Description: Sorry about the delay...Github repo will be up eventually. Rest assured, all the theory I explain has sound functional backing.
Tags: aking1012 , Andrew King , AV , AV Bypass ,
Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying.
Already had an email conversation with Ignatius. I forgot to note something in the RWX part of the video.
DWORD endaddress = GetProcAddress(baseaddress, "endmarker");
endmarker was an additional exported function I added to the end of test.c and test.h exports. This is just a simple way I can get the address of the end of the DLL.
Github still forthcoming. Getting all the code for each video worked out and functional before upping to github.
@Ignatius - Thanks for sticking with it and actually working through the code.
Big Thanks Andrew!
greeting
thanks a lot andrew for such an awesome videos !
Thank you Andrew for posting these videos. The fact that there has been a delay has meant that I could research around the topics that you have covered already (use of mingw, creation of a DLL, inline assembly etc.) as well as the other topics that you mentioned in the thread of the first video.
I have managed to get the code working and confirm RWX as well as give the various memory addresses etc., but I get several warnings when compiling. I'm using mingw on Windows XP SP3. I know that many of us expressed interest in this series and there have been a large number of views of the first two videos so I hope that there are quite a few who, like me, are following along. Has anyone else noted a lot of warnings when compiling? I'm not typing from the system that I use, otherwise I could copy/paste the warning messages.
The warnings are about converting an int to a pointer without a cast. In the code I'm using on my box they're unsigned int, so there shouldn't be issues with a negative turning in to a huge positive and it's not based on user input so...reasonably safe. FFmpeg as a great many similar warnings;) However, some of those can be reached by user supplied data.
Having managed to sort out the first part, I thought I'd turn my attention to the second part and conversion of AT&T to Intel. I know that the principal was covered by having a nasm template and I'll be interested to see how this is actually used in future videos.
I did some googling and came across two links that might be relevant:
http://www.linuxquestions.org/questions/programming-9/syntax-converter-for-inline-assembly-618734/
http://stackoverflow.com/questions/199966/how-do-you-use-gcc-to-generate-assembly-code-in-intel-syntax
I've just tried the first and the code compiles without any errors under mingw in Windows XP when using Intel syntax and ".intel_syntax noprefix\n\t" as the first line of the inline assembly. I also looked into using <gcc -S="" IntelFormat.c=""> which spewed out IntelFormat.s and that contained assembly in AT&T format (with movl, %esp etc.).
I don't know how reliable either of these methods are when compared with the template method described in the video. I plan having a play around with some Intel-style inline assembly and compile it with mingw.
You are more than welcome to try out using ".intel_syntax noprefix". I know that if you need to pass in any arguments or state that spcific registers are no longer to be trusted that it does not work. I would just rather be safe. This is more related to extended inline asm, but I am wary.
Another fantastic video! Hope the next one will be up soon :)
Look forward to meeting you in person next week :)
@Andrew: I've been playing around with your template and nasm, as well as the alternatives to which I linked earlier. I put random opcodes in and saw what AT&T syntax came out. It all *seemed* consistent, though I didn't try all possible opcodes.
I've also done some further research into objdump. It seems that it's used frequently to get shellcode, usually in association with a python script. I saw that the format of the code in the objdump output isn't particularly user-friendly and it would have needed a lot of careful copy/paste if the process hadn't been scripted.
I'm sure that I will make use of your template when your further videos have been uploaded but I just wanted to do some background reasearch. I see from Vivek's post that you are likely to see him shortly, presumably at a conference, so I anticipate there might be a delay in seeing more of this series. No worry though, your time is valuable!
I know I said no-go on fully functional code but...here's something
objdump -d whatever
g = open('/tmp/evasion/shellcode.txt', 'r')
test = g.readlines()
for struct in test:
chunks = struct.split('\t')
astruct = chunks[-1]
astruct = astruct.rstrip()
astruct = astruct + ";"
print astruct
Inline-egg from core is another possibility(open source).
Hello Andrew
Is it also possible to bypass enterprise av, or this is true for personal av? Also do u need enough privileges to bypass av?
It's not about breaking the AV. It's about the AV not recognizing the code as malicious. If you have a license to hand me for a particular AV product that isn't on virustotal, I'll demonstrate.
Thanks Andrew
@Andrew: More snippets of tantalising information for me to research!
I've been playing around with inline assembly and shellcode within some C code and they seem similar. I realise that the shellcode must avoid null and other bad characters and the inline assembly must be converted from human-readable form to machine code by gcc. Are there any other differences? Why would one be preferred over the other?
I realise that this series will go down the inline assembly route, but would shellcode be a suitable, realistic option?
@Ignatius: could be. I'm going the inline assembly route for several reasons. 1) With a download and loadDll custom payload I can have any characters I want in the DLL...no more banned characters -- 2) I would prefer assembly over shellcode so that I can compile as opposed to seek and replace within a compiled file -- 3) Shellcode would be preferred to dump straight in to an exploit, although I seem to remember noticing that metasploit now has metasm integrated into the framework...like an exploit can manually assemble instructions -- Shellcode could be a realistic option. I wouldn't try writing shellcode as opcodes to begin with. I would try compiling and stripping C or compiling assembly and then tweaking things a bit to get around banned.