It's easy to understand once you have basic grasp of it (which admittedly takes a lot of effort!!), and from there, even machine code becomes easy to understand (and this, you can read shellcode without assembling).\x31\xC0\xB8\x01\x00\x00\x00\x89\xC3\xCD\x800x31 0xC0xor eax, eax ; clear register eax. 2 bytes compared with 5 bytes for mov eax, 0
mov eax, 1 ; move 0x1 into eax register
mov ebx, eax ; move the value held in eax into ebx
int 0x80 ; call an 'interrupt' (80) to exit the process. the exit code will be determined by the eax and ebx values :)
Thanks, friend. I'll check Xen out. It looks good, considering it promises to be the only opens-source VM. It also seems light, which is perfect for me.Assembly is too low-level and complicated?
Hmm, I'm not familiar with it personally but isn't XEN open source?
http://wiki.xen.org/wiki/Xen_Project_Software_Overview
Going completely off topic....
A simple bit of shellcode for you:
Code:\x31\xC0\xB8\x01\x00\x00\x00\x89\xC3\xCD\x80
Each instruction is a set number of bytes.
For example the first instruction is 2 bytes:
Code:0x31 0xC0
For example:
0x31 is the machine code representation of the instruction XOR which means Exclusive OR (you know, 1 xor 1 = 0...0 x 1 = 0 etc).
0xC0 is a little more complicated. But machine code opcodes are split into bits or 'parts' if you like. To keep things simple and save this post getting way too technical, let's just say that in this case, C0 represents the register eAX. Some instructions are obviously more sizeable than others, for example in our shellcode, B8 moves a value into the eAX register, which we read as:
B8 01 00 00 00 (mov eax, 1) with 00 for padding.
So reading it all together we get a simple code to exit from our process.
Code:xor eax, eax ; clear register eax. 2 bytes compared with 5 bytes for mov eax, 0 mov eax, 1 ; move 0x1 into eax register mov ebx, eax ; move the value held in eax into ebx int 0x80 ; call an 'interrupt' (80) to exit the process. the exit code will be determined by the eax and ebx values :)
Simple
Ah, my current disk is about 20GB free only...I am not sure how 1.9TB is going to fit. Well then, then I think I need an ISO copy of Windows (Since Mac/Linux doesn't have much interesting samples, nor the many tools which Windows has to offer. Which is wrong in its own way...). Thanks for your help. What I dislike is, that Linux is pretty small and takes much less time to download, and no piracy required, yet it doesn't have any interesting malware. And I do not know if Ollydbgs or IDA (by Hex-rays) supports Linux, even after I get some samples to run.
Make sure that you're aware of the limitations of testing malware in a virtual machine though. Whilst it's becoming rarer for split personality malware to appear in the wild (that is, malware which behaves differently if detects it's being run in a VM), it can still appear, as can malware which has a payload delay which will execute innocent instructions or behaviour for an idle period for a set amount of time or until a specified number of actions are taken, such as so many mouse clicks.
I know you said you weren't into static analysis and wading through machine code, but don't forget static analysis can be done on a pretty high level. Just getting a copy of the API table to see what APIs the malware is calling can be very informative, as can looking through the binary for strings and using a fake DNS (eg: ApateDNS).
If you want to dig into malware analysis but really want to avoid learning even some basic assembly, then I'd recommend picking up a copy of OllyDBG with malware analysis plugins, for example ready made unpackers (eg RunPE unpack), anti-anti VM/sandbox etc. These will help you prepare your sample for effective malware analysis without stepping through instructions and manually dumping processes etc.
Anyway, that's just some advice for starters, there are many more options besides
Best of luck! We're here if you need more pointers (null pointers or otherwise)
), then I'll get to complicated stuff like trojans, worms and advanced malware like Ransomeware.
See here for a nice explanation: http://www.friedspace.com/assembly/cpuregs1.phpmov eax, fs:[30h]
movzx eax, byte ptr[eax+0x2]
or al,al
jz payload_
jmp killprocess_
So registers are just heaps?I hear you man, I'm a C programmer myself and being so familiar with the syntax I have repeatedly tried and failed to learn C++, it just seems completely unnatural. For me, I learned assembly at a young age so growing up with it and with low level concepts it seems natural. eAX is actually a register. You see AX is a register which can hold 16 bits (in 16 bit assembly). EAX can hold 32 bits (in 32 bit assembly) and RAX is the 64 bit version. So if you're decompiling on a 32 bit machine you'll see instructions pointing to eax.
As for what a register actually is, think of it as a form of memory slot, in which you can store values and retrieve them but much much faster than doing so from the computer's memory (with pointers and such). This is where the stack comes in
In malware, you do see more complicated instructions but of course, some instructions are the same from malware to malware. Here's a simple chunk of assembly which checks to see if we're being debugged by OllyDbg.
Code:mov eax, fs:[30h] movzx eax, byte ptr[eax+0x2] or al,al jz payload_ jmp killprocess_
So in this example, we find the segment 30h which contains something called the 'PEB' and we movzx the byte at 0x2 of segment 30h into eax (this is now a zero extended value which gives us access to the AL segment of it). The next instruction checks to see if AL is 0 (or Al,AL), and if it is (JZ - Jump if Zero), we execute our payload, otherwise we skip over and JMP to our killprocess function which either idles out or does kills our process and melts or something, whatever.
But those are the kind of code segments that you will gradually learn to identify. Of course I can't look through a program in a debugger and tell you exactly how it works just from the assembly code, but I can dive in, analyse it piece by piece and work out what it's doing and what states or values trigger that behaviour, and this is how you build a picture of the program (looking at the stack/heap/registers etc of course too).
As for breaking out of VM, yes it is possible. Malware it much more likely to break out of a sandbox than a virtual machine, and the reality is quite overhyped I'm afraid but yes malware can break out in rare cases. For example, if you mount a physical USB drive in your virtual machine (for example to transfer files), the malware gets access to that, and when you dismount and use it in your normal computer, there is a copy which has been brought out of the machine. There are other ways but they are much less common and I haven't encountered them in the wild myself (in realistic usage), I'm sure another member here will explain those before me
Hope that helps a bit
. I do agree that programming is one of the worst re-learn things, because after years of practicing habits, you just can't leave them.
So registers are just heaps?
I am sorry for a little late reply. Network administrating still gives me headache as it gave me twenty years ago.
Thank you. I think now I have better understanding of memory, and more importantly Assembly. I've just bought Programming From Groundup : Assembly (It was listed as the most recommended Assembly book over Stackoverflow). For now, i think we're going off-topic. But thank you for inspirting me to do some Assembly, and re-read C reference books.
I'll try all the VMs. Thank you guys for helping me.
Some rootkits bypass. Not to mention, my current identity (credit card, bank account, passwords etc.) will be almost certainly hacked. Also, how can I be so sure that I will not infect myself while using virtualization?
My internet makes me look like a rambling fool...
