Have a read http://download.savannah.gnu.org/releases-noredirect/pgubook/ProgrammingGroundUp-1-0-booksize.pdf

Comparison of assemblers. http://en.wikipedia.org/wiki/List_of_assemblers

learning ASM is a sign that you have too much free time man

That is funny. I am now taking an intro computer science class and the more I look into it the more I like it. If this keeps up for all semester, I may change majors.  :S I have no idea...

Im not looking to destroy any OS at all with the virus because that would be counter productive. My main concern is allowing it to spread without being detected for quit sometime over a variety of systems. The means to do this would be to not allow its signature to remain the same thruout every file it infects so that antivirus software would have very little to go on. As long as the virus did not corrupt the system and it did not show a repeating signature thruout the computer it would lay for possibly years undetected.

If you have a student account, grab the Microsoft Dreamspark VS2010 (Full), if you don't have a student account, I have several...

I'm looking at OD1N as a base for NMR, quite simply it is open source (open code), Object Orientated C++, which allows for basically any system and also has integrated pulse shaping libraries for Spin-Echo routines. I currently (based on the modeling) have a magnet design that will give 1.074 +/- 0.001 Tesla in a 5x5x5mm cube area in the center of the sample volume area (so it is kind of homogeneous), with that and the various pulse-shim/shim-pulse routines there is a real possibility of getting NMR working @44MHz.

I'm also looking at Microsoft Robotics studio as well as both PIC & TI (Launchpad) for the MC/DSP to generate the signal & pulses.

Is there any way we can modify OD1N so that the basic program could be used for multiple spectroscopic outputs (including light based)? A single GUI that could be used to run all the various systems and to get all the data in one place would be great.

I'm busy writing a Business Plan for additional funding, I have an agreement with a certain Associate Professor, I'll supply him with a magnet assembly, he'll supply me with the electronics to go with it (and he'll also write it up). Trouble is, he has kind of gone overboard on the electronics, I personally see no reason for an FGPA when a simple DSP (Digital Signal Processor)/MSP (Mixed Signal Processor)* will do the job as effectively, without the enormous code/cost overhead. Trying to design systems that can work by themselves is one thing, however, not making use of the incredible amount of computing power in the average study PC/Laptop is just dumb.

That said, the average potential user of these systems is not going to set out to spend 4 or 5 times the price of the complete system in order to get the feel for building an untested & unknown unit themselves. If the price were right, quite frankly they'd prefer to simply purchase something they already know works.

* Especially when you have things like the MSP430 series, with the 64QFN chips having up to 128kB Memory, with USB 2.0 port access built in, for <$10 each (MSP430F5528 looks nice @ $3.95 each, especially with CCS onboard).

metamorphic code is going to involve essentially writing your own compiler...in assembly  polymorphism is a much more attainable goal, and can even be written using C.

as for network code I'm going to assume you're writing this on windows so you'll be using ws2_32.dll.  To load it in a "discreet" fashion, find the base address of kernel32.dll via one of the many published methods, walk it's export table until you hit LoadLibraryA and GetProcAddress, store the corresponding addresses.  To avoid having suspect strings in your code you could use a simple 32 bit hash function and do the comparison that way.

I used write this sort of shit for fun back in the day.  Rootkits were more fun though IMO.  Best is when you write it in ASM and inject into another driver (beep.sys is an old fav) either in memory or on disk.

edit: I always used NASM, but that was just personal preference

Before looking into polymorphic code or any other techniques, you need to write out a business plan of sorts outlining what your goals are and who your targets are.  Are you after financial data, webcam recordings to get n00ds of your girly friends, a generic botnet to lease out to spammers and DDOSers.. etc.

Are you targeting corporate machines or personal machines?  They have vastly different security procedures.

Antivirus programs work in two ways:  they identify viruses based on various checksums and they attempt to use heuristics to identify unusual behaviors (like remote thread injection, unusual packing mechanisms, modifications to code segments, etc.)  Unless you've spread at the level of the Storm worm the first isn't usually that large of a concern, but it can be tricky to avoid the second.  Trying to purposely change the form of your program can sometimes make it look more suspicious unless you're careful about it.  You generally want to get as deep as you can as quickly as you can and stay there, via kernel and driver exploits, so you can undermine detection efforts.

If you're looking more at using polymorphism on the actual infection packets, those are usually only blocked by IDS systems on corporate networks anyway.  I think you'll find that your design goals vary greatly with your targets, infection vector, etc.

I like seeing that there is such an overlap between underground chemistry, underground IT, etc.  A powerful second world has been developing for years.  There's a large class of people growing who realize life has a lot more to do with who can outsmart whom than with arbitrary decrees of legality.

Correct that would be illegal, I just want to play around with code at the moment and see if theres a means to beat virus scanners and other security measures to make a virus stay undetectable for years as long as its not doing anything to draw attention to itself I see little reason for a heuristics model to be created in order to detect such a thing.

Modifications of a tiny virus to encrypt itself should keep general operations at a small level at first.


Its all just a complicated study in biology nothing more... Although the points brought up by Anonymity fellow are definitly worth discussing.

I would love code examples matter of fact since reverse enginering is what I do best in programing.

A pseudocode example might help show potential overall flow design as well.

For this example, say you have a simple buffer over exploit like the Slasher worm, etc. where everything is contained in one packet and when it gets to the server it starts sending out copies of itself.  You could use something like the following:


Exploit portion
===================
[control data]
[long random string to overflow buffer]
[return address - this could even be varied by pointing it to random locations with jmp esp instructions]
====================
Code portion
====================
[optional random length string of effective nops (inc eax;   dex eax;   xor ecx, ecx;  etc.]
[code to base64 decode block X]
[code to decrypt block X using key YYYY - this could be as simple as an xor loop]
[jmp block X]
[YYYY]
[Encrypted, base64 encoded block X]



where X decrypts to something like:

[allocate space for packet Z]
[copy control portion of packet into Z]
[seed random number generator]
[fill buffer length in Z with random data (other than NULL or whatever)]
[pick a random return address out of a list of useable ones (in this case addresses of jmp esp insructions) and copy it to Z]
[pick a random length and fill it with random effective nops (in Z of course)]
[copy base64 decode block into Z, altering instructions randomly as much as possible while still retaining functionality]
[copy decryption block into Z, altering instructions randomly as much as possible while still retaining functionality]
[choose a random value for YYYY (again avoiding nulls) and copy it into Z]
[make an encrypted copy of this entire X block using the new YYYY inside of Z]
[base64 the encrypted copy (to get rid of nulls.. you could use any encoding that will help with this, or a different encryption process to begin with that avoids nulls somehow)]
[your new packet is now ready to go and has everything it needs in it, so fire it off to a random IP, then loop back to the start of this X block]
============end of X==============

The decoding and decryption code are the only things that remain somewhat constant, so the more you can alter it each round the better.
the jump to block x could even be altered (eg. xor eax, eax;  je X     ||or||   xor ecx, ecx;  dec ecx;  jne X)

It's important to realize that you're making an encrypted copy of the entire currently running block (including the parts you haven't executed yet) but since the output of the encryption and encoding is in another part of memory, it's not going to affect the currently running code.


When you get into doing this kind of thing in executables, you can get even more creative.  Microsoft hid it's Patchguard initialization functions in an error handler, then purposely caused a divide by 0 error in the middle of a seemingly innocuous part of the kernel code.  Heuristics-based AVS often look for self-modifying code and data execution, so you sometimes have to find clever ways around these problems.