[Help Request] - PostData Air Data
[Help Request] - PostData Air Data
Hey, so i was working on a little something and i wanted to know if there's such thing as "air data" in a post data method. What i mean by this is, let's say i'm posting data to a server. I do all the "byteData()" fun stuff, set the thing to post and do "reques*****ntentLength = byteData.Length" can i send data that's of know meaning but slows down the Upload time?
When "ciphering" a dll hack, most people would pump it with just "air data" by saying ".WriteByte(0)", but how can i do something similar to this with my webrequest and would it potentially slow down the servers speed of processing the request? This isn't meant as a dos tool btw, but it could probably be used in one.
@Jason, i feel like you'd be the most likely person to know how to do this.
When "ciphering" a dll hack, most people would pump it with just "air data" by saying ".WriteByte(0)", but how can i do something similar to this with my webrequest and would it potentially slow down the servers speed of processing the request? This isn't meant as a dos tool btw, but it could probably be used in one.
@Jason, i feel like you'd be the most likely person to know how to do this.
As far as I know, using the provided .NET classes, this won't achieve much except lag the client as (from memory) the WebRequest classes use a buffered stream. You write all your data to the "request stream", but as far as I know this data isn't actually streamed to the server during the write, just buffered locally. The call to WebRequest::GetResponse() is what actually sends the data to the server and retrieves the response.
Because of this, doing a slow write, something like:
Won't actually lock up the server for 100,000 ms. It'll lock up the client for 100,000 ms while it buffers the request, then it'll send all the data to the server at once. This would explain why WebResponse objects implement IDisposable but WebRequests don't.
Note: I could be wrong about this, I haven't actually looked into how Microsoft implemented these classes. You may be able to achieve what you want by opening up a TCP stream directly then stalling on it, but AFAIK most servers automatically drop off requests like that.
Because of this, doing a slow write, something like:
Code:
var dummyLength = 1000;
var dummyData = new byte[1];
var request = (HttpWebRequest)WebRequest.Create("http://example.com");
request.Method = "POST";
reques*****ntentLength = dummyLength;
using (var reqstream = request.GetRequestStream())
{
for(int i = 0; i < dummyLength; ++i)
{
reqstream.Write(dummyData, 0, dummyData.Length);
Thread.Sleep(100);
}
}
using (var response = request.GetResponse())
{
// derp
}
Note: I could be wrong about this, I haven't actually looked into how Microsoft implemented these classes. You may be able to achieve what you want by opening up a TCP stream directly then stalling on it, but AFAIK most servers automatically drop off requests like that.
Originally Posted by Jason
As far as I know, using the provided .NET classes, this won't achieve much except lag the client as (from memory) the WebRequest classes use a buffered stream. You write all your data to the "request stream", but as far as I know this data isn't actually streamed to the server during the write, just buffered locally. The call to WebRequest::GetResponse() is what actually sends the data to the server and retrieves the response.
Because of this, doing a slow write, something like:
Won't actually lock up the server for 100,000 ms. It'll lock up the client for 100,000 ms while it buffers the request, then it'll send all the data to the server at once. This would explain why WebResponse objects implement IDisposable but WebRequests don't.
Note: I could be wrong about this, I haven't actually looked into how Microsoft implemented these classes. You may be able to achieve what you want by opening up a TCP stream directly then stalling on it, but AFAIK most servers automatically drop off requests like that.
Because of this, doing a slow write, something like:
Code:
var dummyLength = 1000;
var dummyData = new byte[1];
var request = (HttpWebRequest)WebRequest.Create("http://example.com");
request.Method = "POST";
reques*****ntentLength = dummyLength;
using (var reqstream = request.GetRequestStream())
{
for(int i = 0; i < dummyLength; ++i)
{
reqstream.Write(dummyData, 0, dummyData.Length);
Thread.Sleep(100);
}
}
using (var response = request.GetResponse())
{
// derp
}
Note: I could be wrong about this, I haven't actually looked into how Microsoft implemented these classes. You may be able to achieve what you want by opening up a TCP stream directly then stalling on it, but AFAIK most servers automatically drop off requests like that.
Lol as it turns out when you write to the server you can just add 100,000 to the content length and just use:
Code:
Dim postreqstream As Stream = postReq.GetRequestStream() postreqstream.Write(byteData, 0, byteData.Length) dim counter as int64 = 0 Do Until counter >= 100000 postReqStream.WriteByte(0) counter += 1 Loop postreqstream.Close()
Originally Posted by LilGho$t
I was expecting to get bitch slapped for asking such a dumb question...
Lol as it turns out when you write to the server you can just add 100,000 to the content length and just use:
Problem solved
Lol as it turns out when you write to the server you can just add 100,000 to the content length and just use:
Code:
Dim postreqstream As Stream = postReq.GetRequestStream() postreqstream.Write(byteData, 0, byteData.Length) dim counter as int64 = 0 Do Until counter >= 100000 postReqStream.WriteByte(0) counter += 1 Loop postreqstream.Close()
Why you'd want to do this (aside from DDoS attempts), is beyond me though.
Originally Posted by Jason
Yes, there's nothing stopping you from sending exorbitant amounts of data to the server. My point was that you don't actually have a live connection to the server while you're writing to the request stream, so "slowly" writing it is an exercise in futility.
Why you'd want to do this (aside from DDoS attempts), is beyond me though.
