Main Problem with old DoS Method:
The original “DoS” (Denial of Service) attacks use single ping process. It lags it’s victim/server with a large packet. The problem with this is having to predict the bandwidth of the victim/server before pinging/DoSing. If the bandwidth is smaller and you ping with a packet meant for a T3 line(T3 Line = Example) you will lag the victim/server only [.75 -. 1] (milliseconds) making a 0.0025-0.0032 lag on the server and a [1.75-2.93] (milliseconds) lag on your self. This could be considered DoSing yourself. That would be the main problem. That means with the old ancient DoS method, bitches on Dial Up / 56k can not be DoSed (to an extent, because knowing the exact bandwidth of the victim/server and then having to render your packets in size would eliminate this problem). Now who the hell wants to render all their packets in size AFTER finding out their victim/server bandwidth? But with my (ssope’s) “DoS 3,000" Method, you would be able to DoS victim(s)/server(s) from 56k, to cable bandwidth, to a T1 Line, to a T3 Line, to the bandwidth size of a fucking truck tire.


Problem(2) with old DoS Method:
Lets talk about the problem (with the old DoS Method) conflicting with the victim/server. You would think that errors on the victim/server end would result in a greater lag time. Not in this case. Large packets would block the initial ping back. But you can not even rely on it blocking that ping. It depends on the size of the first ping and the time interval of the second ping. (If it is consecutive or not). Also even depending on the size of the second ping’s packet. Lets say it does block the ping. That means the lag would begin immediately. And that ping would lag there until the large packet(s) conclude. But what if you use a 3,000 ping string (DoS 3,000 Method). You could not only have to wait for the packets to conclude, but you now have created a second problem. This problem is good because it adds lag to the victim/server. The second problem that your causing to the server, would be the 3,000 packet back flow. Which now creates a whole new world of shit for your victim/server. It now has over 2,000+ packets to conclude. Depending on the size of these packets this could take a matter of minutes to hours. That my friends. Is a real DoS. Now after explaining (yet another) feature that the DoS 3,000 method has , lets go back and discuss the final problem on the victim/server dealing with the old DoS Method. If there is no second ping that is being blocked by the current packet then that means the lag doesn’t even begin. You would think that the lag would start when a new packet is sent out. Wrong. It would create a higher priority for the outgoing packet. Creating the smallest (if non at all) lag to the victim/server. Also concluding the current packet that was suppose to be blocking the current ping. This is why the old DoS method has to be rewritten. And now it has been.


DoS 3,000:
What if packets were able to be inputted as strings? Strings would consist of 3,000 packets no matter the victim/server’s bandwidth. The only thing that would change is the 3,000's universal packet size. I have created designed formulas that would be able to pre configure the packet size compared to said bandwidth of the victim/server. Lets even make it simpler then that. The large extensive program that I have already built using this method, gives proof to this theory. In the program, it sends a test ping, grabs the bandwidth, and pre configures using my “D3" formula, instantly rendering the 3,000 packet string to fit the victim/server’s bandwidth and now your victim/server’s internet connection, lies under the hands of you. What a scary thought? This is why I have only released the theory and am still deciding on if I should release this program.


DoS 3,000 Formula:






DoS 3,000 was written and invented by: ssope.
© Copyright 2005 ssope Productions All Rights Reserved.