BG - Hivemind: Distributed File Storage Using Javascript Botnets - Sean Malone

good afternoon everyone welcome to H mind where we are looking at distributed file storage using JavaScript vets my name is shant T Malone I am a principal security consultant with Fusion X um most of you have probably not yet heard of fusion X for a very small security consultancy we focus on high-end penetration test red team assessments uh a lot of sophisticated adversary simulation if somebody with a lot of time money and talent were actually going to attack you how would you hold up what would that look like how would your detection and response capabilities hold up and so forth I we definitely hiring so if that sounds like something you're interested in please talk to me after the

talk the problem that we're addressing here is sometimes there's data that we have on our systems that we don't want other people to see and as we saw in this news article and this is just one sample there have been many similar items in the news lately sometimes encryption is not enough I even when you have something encrypted there's always a key to decrypt it whether that's a password um a hardware token any sort of artifact there that can be extracted from you through extortion or some other means will provide the access access to get to your data so the idea here is to provide a means of storing data such that if somebody attempts to cease that data

it's gone completely so the solution store the files on someone else's system so if your server is sees the data is simply not there isn't that illegal the answer is in most cases yes it is so that's why I started looking at JavaScript the nice thing about JavaScript is that it's run in a browser it's supposed to run there but websites are able to execute arbitrary code so we'll dig into that a little bit in this talk so we're going to look at doing this with standard functionality there are no exploits here we're just looking at some tips and tricks and a a framework a methodology for how we can store significant amounts of data in a distributed

fashion so what we're looking at here are all features not bugs all of these techniques are used for real web applications out there and there's nothing to patch if we were to remove these features from web browsers it would break a lot of the more modern web applications because web applications are getting uh richer and richer more and more complex they can do more things they can do it better and faster this is great uh it's it's what enables a lot of the rich experiences that we see in web applications these days but it also provides a lot lot of very useful utilities that an attacker may be able to manipulate for their own purposes so starting off with the

disclaimer this is a research project the code is still very much in a pre beta phase and while I will be releasing the code I don't recommend using it for critical data and something that you can't bear losing obviously that's the idea to get it to that point eventually where you would use it use it for data where you would rather lose it forever than have it pinned down on you and and and have somebody retrieve that data if they seize your system the second component is that I'm not a lawyer and I'm not giving legal advice and as with many things presented at the conferences this week this can be used for evil don't do

that we've seen web browsers change a lot over the years they start off with the most basic form of data storage on the client's side and that's the browser cookie then we have JavaScript for data processing and that then leads to the the Ajax the uh asynchronous JavaScript and XML where it's that background data communication between the browser and the server this then leads to more advanced HTML 5 Technologies such as web storage which is sort of like cookies on steroids where you can store significantly more data in more complex Fashions web workers let you spin off data processing threads that are separate from the application so they don't hang up the gooey there and web sockets let you

establish the by directional Communications so again it's sort of like um new and improved version of Ajax so the end result here is that a web browser has become a computer program that will communicate with my server execute any code that I pass down to it and store any data that I sent the end result is that you basically have a bot net node that's running on every system out there every desktop system at least you might look at this and say that browser sandboxing and all of the new security features built into these browsers uh cross origin policy and all of these other items might make it difficult to access data and execute code but the end result is that I really

don't care about that all I need to do is run code in the sandbox environment store data in the sandbox environment and retrieve it from there so I'm not trying to data from other sites I'm not trying to read files off of your computer this all exists within the normal browser security model so again there are no bugs here this is all features so let's look at what it takes to actually build a JavaScript JavaScript botn net as with any botn net the first step is to actually infest the noes and there are a number of different ways that this can be done starting off with sites that you own I own Shan te alone.com if somebody goes to shant team

alone.com it downloads the HTML the images all of the other assets from that server and it executes any JavaScript files that are provided so that right there is a potential injection point where I provide a particular piece of JavaScript that adds their browser to the node next is compromise sites which is basically the same thing without permission if you can find a cross-site scripting vulnerability particularly a persistent cross-site scripting vulnerability you can inject JavaScript or inject an iframe and add the nodes of whoever or add the browsers of whoever visits that compromise site to your botnet as new nodes URL shorteners are a fun one if you go out and create a URL shortener that sure it displays the site that it

was supposed to display but it perhaps puts that in a full screen iframe and there's another I on the page that's actually running the botnet code add distribution networks this is something that was discussed at black hat this morning there are uh app distribution networks out there that will allow you to provide an iframe URL or a Javascript file that will be included with your particular app the usual purpose is to drive traffic to your site from many different IP addresses and boost your search engine rankings and such um but there's nothing to prevent you from putting whatever sort of JavaScript botnet codes in that iframe as well this is one of my favorite here the

anonymous proxy server this is something that that I've been working on where you stand up an anonymous proxy server that's out there listening on the internet for 880 and it will be picked up some we'll find it someone we'll put it on the list of anonymous proxies and people will start sending traffic through that server and they're usually not paying attention to things like are you modifying the server or the the traffic as it goes through that server are you injecting an if frame into every page that they visit and this is a very effective technique to build a large spotnet in a relatively uh relatively short period of time as an example Benchmark on this I have a proxy server

that I've been doing some work with Where I Stood it up did not advertise it anywhere it was just out there on the internet as an open proxy and after a few weeks it had been picked up published on these lists and I was getting hits from roughly 20,000 unique IP addresses is in the space of 10 minutes so it's a huge amount of traffic actually I need to worry about having too much traffic going through there as opposed to not enough for command and control this is where the HTML 5 web sockets come in this quote is from the official working group publication on websockets where it says the purpose is to enable web

applications to maintain birir bidirectional Communications with server side processes I mean that could have been written WR to apply to botet command to control type Technologies that's exactly what we want to do to be able to push data back from the nodes and push commands down to the nodes when that doesn't work we can always call back to aex and that's something else that I've run into where these browsers may be trying to connect as nodes but for one reason or another they don't support websockets it won't get through whatever proxies they're going through on their end it won't get through the particular technique that you're using to infest no such as if you're using uh the that Anonymous proxy

technique sometimes websockets don't play nicely with that so it's good to always be able to fall back to the more old school Ajax Technologies for data storage we're looking at HTML 5 web storage again this is uh something where it says it's designed for storage that spans multiple windows less beyond the current session web applications may wish to store megabytes of user data why hav't user data how about my data on the back end it's a Ruby on Rails application though you can use any technology for this uh the data storage on the back end is my SQL for the active record component simply because it's easy to use it's extremely easy to prototype web applications using that

framework but as I got into that I realized no that's not really going to cut it for some of the types of Data Tracking that I need to do so I brought in redus as well which which is basically an inmemory key value storage that's very useful for storing uh data that changes very quickly it's in memory so it's very fast and you can set an expiration on keys so if you have block data that you only want available for 20 seconds while you're reassembling a file it's great to be able to set an expiration on it and have it expire and disappear uh as soon as you're done assembling that file so that's an overview of how we can

build this botn net and use it for uh just have a bot net that we can use for any purpose and I'm going to be looking at using it for data storage but there's definitely more that you can do with this uh other botnet uses would be Network scanning uh dos taxs or data processing through web workers that last one is particularly interesting because anything that you can break up into individual tasks of data such as um password hashing Bitcoin money anything like that you can push out and have run in separate threads with web workers so on a qu core system you can have four cores working to do your dirty work for you in JavaScript and again there's

nothing out there to to stop this this is this is a feature of modern browsers so we have a botnet let's look at what it takes to actually take that botn net and build a file system from it starting off with some definitions a file block is what I used to Simply refer to a piece of an uploaded file with a set maximum size a node is going to be any browser that's a a member of the botnet and the server is simply the Central Command and control system that's used both to manage the botnet nodes themselves as well as track the the phone books so to speak for the the files the blocks and

where all of those blocks live so storing a file we start off with the the basic file that's uploaded through the web application like any other file upload that file consists of a name the M type and the file data and this is a point where normally that would just be written to dis on the server or stored out in uh a wss3 or some other type of file storage technology but in this case what we're going to do is go ahead and encrypt the data so that when we break this up and send it out it's not possible to for a malicious node to identify data that's being stored in these files and then we break it into blocks

which basically means take that base 64 string of that encrypted file data and chop it into blocks of equal size so what I found works well is 1,24 characters it's a number that I pulled out of here you could use pretty much any block size you just need to make sure that it's small enough that you're not going to run into problems s with the local storage maximum U limits in the browsers which is usually around 5 megab for most browsers so this gives us a particular block that we can then store on the server so take block one for example we've got a server here that has block one and we want to store that out on our

distributed um file system so we've got these nodes that have come in through the various techniques that we set up beforehand and they're all checking back in just saying hey I'm out here I'm ready do you have any work for me we say yes go ahead and store this block you push it down to the nodes and you keep tracking your local phone book there on the server uh what nodes have that block and you do a hash of the block as well and store the mv5 or any other algorithm for that particular block just to provide a basic sanity check on was the data corrupted along the way did a malicious note tamper with that data and

is trying to corrupt your file there over time some of these notes are going to go back whether this is malicious intentional corruption accidental corruption or in most cases notes simply go offline uh they will be visiting a particular website going through a prophecy server and then all of a sudden they're not what happens then we we start to lose these notes and so these notes are constantly going to be doing a heartbeat check where they submit data to the server that says here's the list of the block IDs that I have and here's the list of all of the uh the check sus the m5s for all of these blocks that I'm storing and the

server is then tracking the expirations on the the various nodes for each block and this is another thing where retus comes in very handy because the heartbeat on the back end is simply updating the expirations on those uh particular keys in the data store at any given point if the number of live know good nodes Falls before a certain threshold it then pulls in new noes from the bot net sends the block up to the server temporarily and replicates it over again it has to go through the server because JavaScript can't do peer-to-peer Communications uh at least within a browser definitely uh node.js and other systems can do that just fine but within the browser security model you can't

actually listen on a port so we have to send it back up through the server but we write it we we write that block data to redus with an expiration it gets replicated the block expires and the data is no long on server retrieving a block looks very similar we have it on all of these different nodes when the the request comes in to retrieve a particular block the server sends out a request to all of the nodes in the the phone book for that particular block saying hey send send me this data and the particular note sends it back back up and again it stored in red as with a particular expiration time and all of these nodes then come back up

to the server and then we can start looking at retrieving a file so these requests go out all of the blocks are sent back up to the server for temporarily in redus and then uh there's sort of a a polling of the the reddis data store to say are all of the blocks here how close are we to having the the complete list of blocks and once that's done those blocks are simply concatenated into the encrypted data feed that backwards through the ads decrypt and you have your name mine type and the data from your original file and that provides us with a file that can then be downloaded uh I'd like to to pause here

for any questions on this since this is really the guts here this is the the part that's actually the distributed file system uh any any questions on this yes what have you found as your average time for stay alive for um repeat the question the question was what's the average time for a node to stay alive for I don't have statistics on the exact average time uh but it's basically going to be the average time that somebody is viewing a web page for have you seen it like I mean not any like scientific EV have you seen something like relatively Gooden in terms of like uh depending on the particular node and the the type of

data that it is um uh it's going to be anywhere from 10 seconds to 10 minutes usually the the interesting thing there is that especially when you're going through an anonymous proxy server or something like that uh multi-tab browsers you've got all these different system or all these different sites that are being loaded in the browser they're all going through the proxy and the JavaScript is injected into every tab so all of these different tabs serve to register this botnet and they're all shared ing the same local storage because it's all done in an iframe so it's all in the same uh the same origin for this particular node so even as your closing tabs brows into new ones it's

still continuing to do that heartbeat and update the block expiration so that node stays online until they completely close the browser or stop going through the proxy or something like that yes did you have did you do anything special

C the question was uh around cash control and anything special that needed to be done there uh for the anonymous proxy I simply disabled caching uh so that it was getting fresh versions of the files uh particularly any time that I wanted to inject inject data into the site 304 respons is not going to be very helpful there I really need the survey to be giving back at 200 so that I've got the data flowing through there uh but it's a very straightforward um procedure to Simply strip those cach related headers from the the upgoing request and then modify the data as it comes down

yes do you have any kind of way to

uh the question was whether there there any particularly reliable nodes or or super noes that could be used to to Source the blocks from uh I don't make a different differentiation on that it's probably possible to do that do some statistical analysis of the notes how long they're staying online how reliable the blocks are that they're sending up um but right now I simply send out data or send out a block request to all of the nodes that have it whichever one responds back first writes that key and because I'm doing that mv5 check server side it's it's no good data so faster noes are going to reply faster and make it easier to replicate that block um but

but I've not made an attempt to specifically designate uh supernes for that purpose yes two questions um first who is performing the encryption and decryption of the data and second I don't know much about reddis but is it a centralized server so the the encryption and decryption of the data is performed on the server uh is performed in the web application between when the file is uploaded and when the file is split into blocks in order to distribute it down to the notes so if so if someone gains access to the command and control server they automatically gain access to all the data um for some understandings of gain access yes and and that's something that I'll get to on

the next slide sorry um then I'm sorry what was the second question is redis um uh centralized so so redus is a a software program that runs on the same server um it's it it's a data storage technique the same as u a normal database so if you're if you're caching that file on the server what is the point of splitting the files out so I'm only caching the file on the server for a very short period of time that's the purpose of the expiration keys so when the file is uploaded it does need to live on the server for long enough to encrypt it break it into chunks and distribute it and then those blocks need

to live on the server for long enough to to be distributed uh as that replication occurs unless the user itself uploads in blocks in encrypted blocks that it itself encrypted rather than the Ser right it wouldn't be possible to modify this to do that uh the encryption and splitting into blocks on a client and then simply send those up to the server in order to do that um what I was going for here was basically the the Simplicity component that it's simply a web app where you go to this web app upload the file like any other web app there's nothing to install on your server you can retrieve it from anywhere right right um so so yes it it

would be possible to go that route uh that that's not something that I really looked into for this one though yes I was curious if you any of the functionalities of it seems like that might be help um I I looked at the pup sub features for r a little bit um didn't really find them to be necessary for this uh but yeah for future versions that that may be very useful yes seems like the amount of network traffic going back and forth Central server and the clients over time is going to be relatively constant value compared blocks that you're storing I'm curious the General throughput ratio to the block size that you're storing ends

up so so the question was on the the ratio of the network traffic to the block size the particular algorithms and and interfaces that I devised for for this particular application have not been optimized in any way so I'm sure there's definitely some blo there that could be stripped out uh in this case the the the short is that I I haven't analyzed it from that perspective um but there are definitely there's a lot that can be tuned there in terms of the heartbeat frequency and the the the pulling frequency for when you're checking for blocks that you want to send uh because that's that's where a lot of the overhead is going to be the actual uh

block the block storage and block retrieval that's going to be very little overhead overall it's simply an Ajax request so you've got your normal headers and such there uh it's going to be the pulling every quarter of a second and the heartbeat every 5 Seconds that's going to add up over time yes

uh data prioritization is not really in scope for what I'm doing here uh the the solution there is to Simply have a large enough botn net spread throughout enough different regions of the world such that people are going to be online in at least one region of the world at any given time so you've always got that sort of critical mass uh and that's the reason for having the replication and you could even uh get a little bit more specific about deliberately replicate to certain areas of the world at different times uh but the the algorithms are going to handle that themselves to some extent because as say uh Europe starts to go offline and those nodes go offline

the ones that are still online may be more in the United States and so it's automatically going to replicate to those nodes that are still online all right so moving on to what happens when everything goes WR uh this is the the whole purpose of doing this type of storage there are obviously a lot of assumptions and limitations here uh and and so the question is why why do this at all um it's really around server seizure if somebody comes in and seizes that server they unplug it from the wall and walk out of the room and they're going to do forensic analysis and they're going to get a court order for whatever encryption keys are

necessary that doesn't work in this case and that's the beauty of this system because nodes are going to go offline uh they're no longer talking to this server because the server is not there and as they go offline block replication has failed the server is not there so it's not replicating to new nodes and the blocks are lost because as soon as all of the nodes go offline for any given block the server has no way to retrieve that block it's simply gone and the files are are unrecoverable so when this server is seized even if again based on based on that node lifetime of roughly 10 minutes maximum in most cases uh the block is is going to be lost after all

of those nodes go offline so say half an hour an hour and I don't know of any pre letter agency that's going to pull a server analyze it in an hour and realize they better plug it back in if they want to see that data so obviously there are some things that could be done if you're going to analyze logs if you're going to get logs from the ISP anything like this go out and find all of the nodes associated with those IP addresses and seize every single node in order to reconstruct this that can be done technically but it's definitely not feasible and it's definitely not easy as easy as walking into uh a Data Center

and seizing a single server yes uh well it's totally unrealistic um to recover from that do you randomize your block IDs so that you don't store parts of the same file continuously across so that like if they were to recover like individual pieces from like compromised hosts they could uh it could just Str together the IDS in order so so so I I'll show you that in the demo um but the block IDs are uh u based cool okay so yeah it's extremely difficult from simply looking at a block to know anything about the type of data there I'm the only thing that you could really do is I'm not padding the last block so

you might be able to this block goes at the end of the file but but that's about it yes I would even AR that those points right

there exactly that that's that's definitely a benefit of Redd since it's an inmemory uh key value score instead of something that's written to dis right right red does does persist by default so it is going to write to dis um every so often to to do the persistence it's got better performance since the initial read write is memory um but the persistence is something like you mentioned that can be turned off and that's something that you likely want to do in this case um so so right it's all in Ram you you pull the plug it's not there um and even if even if you do in memory forensics while the server is still turned on uh it definitely gets

complicated there s you've already expired the blocks uh that's been over that that memory has been overwritten and so on I haven't I haven't looked at this from an actual practical forensic perspective where I've given a server running this to a forensic expert uh but but the theories the theory is pretty sound there I think what they'll do they'll fre right right you you can you can do a cold tapping and get the Ram um but again what you're getting uh has likely been overwritten multiple times as all of this replication occurs and if you're missing off I'm sorry I mean once the server is turned off right right yeah and once it's turned off the

replication fails and so forth yes prevent you from up thousand different browser instances getting all the data these different instances agency SE your server turning it back on nothing right and and you You' hit on one of the weak points here is that it is definitely possible to poison the botet it's possible if you figure out how the nodes are being added where that communication occurs if you have enough uh enough nodes that are controlled by this three-letter agency such that you then have enough of the nodes and you're logging all of that data you have the uh you have the the phone book so to speak the directory of files and blocks from the server that you sees uh and you got

the you you got and again because all of that is scored only in redus you would need to do the the memory forensics there uh and you would also have to find a way to extort that uh encryption key that was used to encrypt the file initially um but the feasibility of that I think is pretty low and it's something that requires knowing exactly how that data storage is being done at the beginning so that's something that you have to plan well in advance of seizing the server as opposed to Simply knowing this person is of Interest we're going to go seize all of their it assets yes do you have like a kill switch anywhere that like immediately as

soon as the note goes offline it wipes the Lo storage or it uh you want to send a message to all of your Conn no everything I have I haven't implemented that yet but it' be trivially easy to do um I currently wipe the the data whenever you trigger a file deletion uh but it would be very easy to write something on the browser side as well that says if you can't reach the server within 1 minute 2 minutes simply wipe all your local storage so there's some interesting unanswered legal questions here first is can a website store significant amounts of data can can they do this is this legal is this ethical and this is very

analogous to something like uh ads if you go to a site you're expecting that that site is going to try to serve up ads Those ads may be flash ads for example so there's going they're going to consume Network bandwidth they're going to consume at least temporary storage on your computer and they're going to consume processing power so I would maintain that what we're doing here is not any difference any different than that uh it's the same sort of thing it's functionality that's in in no way essential for the web application that you're intending to visit and there is nothing that is actually illegal about writing data to a particular node uh but again that's not legal advice that's

just my own personal perspective on this uh same thing with with bandwidth and processing power this really comes into play when you start looking at the uh web workers for uh JavaScript data processing if you're you're turning through CPU and if you're going to make the computer a little bit sluggish or if you're going to uh rack up their power bill or with on the bandwidth side if you're paying um by the megabyte or by the gigabyte and you're using that node to conduct a Dos attack uh you're doing that with other people's checkbooks so I think especially ethically there there's a little bit more of a clearcut problem with that um legally still a bit of a

gray area if somebody did deliberately decide to go to a website and download and execute the the JavaScript that was present on that site yes this on cell phones at all I have not tried this on cell phones uh there are cell phone browsers that support local storage and I believe there are some that support websockets so basically any browser that supports this there's no reason why it wouldn't work it's just another Computing platform it works really really well um but you're limited to five bags of local storage on Mob uh I I think I think the five mag limit is not just mobile devices I think um a lot of the browsers have five Meg limits

by default as well uh the the final interesting question here is is the individual is the end user the owner of that node responsible for the data that you push down there if you're using this to store illegal data and you push down something illegal and say for the sake of argument it's not encrypted is not even encoded and you're storing uh missile codes or other types of data in the local storage on somebody's browser and for something completely unrelated their system gets seized and all of a sudden this is in their temporary data in their their browser cache uh are they are they responsible for that because again they did deliberately go to a website that

served something down to the browser that got stored on their computer this could be seen as similar to child pornography if you did not if you went to a site that downloaded that but you did not deliberately click save file to your computer in most cases you're still responsible for having that on your computer at all so this seems to be a rather similar case yes

correct yeah there there's definitely a difference of intent there whether you are intending to go to a site where the primary purpose of that site uh may be something illegal as opposed to uh going to a site that happens to be compromised and is making a browser a member of this botet uh so so if you can prove that it was unintentional then then you you may be able to get out of it that way but I think the default assumption is going to be that it was intentional assum that

right right I I'm not cling to have answers here I'm just saying that these are these are some interesting considerations with with this type of um data storage uh well anyhow let's let's get into the demo here we don't have all that much time remaining so let's see if this comes up correctly all right here's the the web application where we basically have a list of files that we've stored already uh as well as the list of notes um let's see if this will work the Wi-Fi's been bit sluggish here

I know I

know all right let me try switching over to the speaker Wifi here

anyone have the key for this network said should I check show at least this we get

L glad I had you type that I'm not

sure speak St

there we go all right so this is a list of notes that are active in the last minute uh I am still troubleshooting the actual proxy injection technique trying to deal with the massive amounts of traffic that's being sent there and figuring out how to throttle the traffic in a way that doesn't throttle the the botnet traffic as as well so these are are mostly test nodes that I own that have been set up for for this demonstration um you can see here we basically have an ID for each node an IP address the the uid which is basically how the browser remembers what node it is and identifies all the traffic that's being sent back uh and the last updated

so every time that request comes in uh either a heartbeat or just a a q check to see if there are any commands it updates that last updated time and we use that to decide what nodes are we going to distribute to and we only want to attempt to distribute to nodes that are currently online so going over to files here um the upload is is very straightforward it's just like any other web application here I put in a password choose a file to upload and go so it takes a little bit of time here to because you've got to upload it and distribute it before it actually saves it and here this is pretty much the only

information that's being stored you've got let me go into the detail view you've got the the file name and ID a u but you don't even see the original file name or the type of the file all of that metadata is stored in it's just a Json data store that's then encrypted and split up into these blocks so here's the the data that this file consists of um here's what I mentioned earlier with it's all u based so you just have file block Dot and then U for that file so this is all of the uh file blocks and these are the nodes that they live on and when these nodes were last updated so if any of these nodes uh so the

replication is set to four right now for all of this is tunable uh so it distributes to four and if it ever drops below two then it will go ahead and read that blck in and replicate it to a new Noe um in production you you definitely want these values set higher since it's fairly easy to lose four noes at the same time and you can see it's a large number of blocks here simply because the the block size is set to 1,24 characters or roughly a kiloby so going back to our file list uh we can now fetch this file where you simply enter the password and we'll do an incorrect password first just to show what that looks

like uh it loads the file blocks and says password incorrect it's something not able to to CCT that so let's try to get and that is that is a a legitimate loading bar in the sense of it's actually saying what percentage of the nodes have or that what percentage of the blocks do we have the data for and the expiration time for red is right now is set to 20 seconds so if it can't get all the logs back in 20 seconds it'll lose the ones that it has so far you'll have to just start the process over again 20 seconds is just the number that I picked that may be tuned differently in production putting in

different password this

time there we

go seem the St Network may have B issues as well

let's

try yes yes um but but you can put it anywhere yeah it's it's just AWS instance that's running this right

now all right

um this will work in modern versions of chrome IE and Firefox those are the ones that I've tested um I have not tested it in other browsers though anything that supports websockets and local storage is likely to work just fine um good question I I I don't I don't know exactly I think it's I8 I I I think yeah I think I8 and up where the the HTML 5 features sounds right let me try switching this over oh wait all I have to do is threaten it apparently there we go keep this and there's our

data obviously something that's becoming more and more dangerous to be caught [Music] with um looking at this real quickly on the the node side here here's an example going through the proxy um I went to my site Shan I've got foxy proxy here that's set up to funnel traffic through my particular Anonymous proxy server and let's look at the HTML here what I've done is simply replaced the ending body tag with an if frame right before it that loads the node in here uh this node is nothing other than an empty HTML frame with the the script tag to load our main um application.js and the which is all of your your jqu resources and

such and the bot JS where all the processing occurs um if we look at this in the console here scrolling up a bit we'll see here's where um it's sending data back uh all of these different requests here th this is this particular take not is conf configured as an Ajax node in part because um Firebug and others haven't quite fully caught up to show this sort of data for websockets so it's nice to be able to see what's going on uh so we see all of the the different uh blocks being sent back there and okay yeah I guess we're not showing the entries for where it actually stored this data um the check Q is exactly what it sounds

like check the command CU see what's happening are there any blocks or are there any blocks that I should be sending back uh the now let me go and that here see if I can

this oh you know it'll be a bit hard to read on here anyways if you're interested in seeing the actual traffic going back and forth or if you're interested in digging into the code at all U i' definitely be happy to do that in the the question a session afterwards uh that's that's about everything any other questions yes so have any

issues this would likely get caught by the right cobt algorithm or cobt communication detection algorithms um I haven't made any attempt to evade that but again the the same evasion techniques the same detection evasion techniques that work for any other type of data would likely work for this as well yes Amat [Music]

so so that's something where you you could you could tune that on the Fly you could say um wait a little bit longer than 20 seconds you you could make that shorter if you've got some high performance nodes and that's something where that the nice thing about the block retrieval algorithm is it simply broadcast the message to every note so you for each block you only need a single note that is going to reply fast enough and so the easier way to account for that need to Simply increase your replication count uh so that you're replicating to more and more nodes and you've got a higher chance of having one that's going to respond very

quickly uh you you could it's you could definitely increase the time between heartbeats you could increase the time between um the these check Q commands these are arbitrary numbers essentially that are all tunable via a configuration file so it's something where depending on the particular setup that you have depending on your bandwidth the size of the files how critical these files are uh and how you're generating how you're investing nodes because that's what's going to affect the quality of your nodes in general uh but based on all of these different items that's what's really going to effect on how you want to tune those parameters all right well thank you very

much and I I believe there's a a Q&A room for additional discussions there Q&A room down the hall all right I will be there thank you