 Okay. Hello, everyone. My name is Paramot Kid and I welcome you to Reversing with Dynamic Data Resolver. If you are not already in the Discord chat, please go to BlueTimulus.org. Click on the Discord channel link and I would like you to give a warm welcome to Mr. Holger and let's start with the talk. Hi and welcome to my presentation, Reversing with Dynamic Data Resolver best practices. My name is Holger Unterwing. I'm a security researcher at Cisco Talos and I'm mainly focused on malware research, threat hunting and tool development. If you want to follow me on Twitter, you can find me at hunterbr72. I'm the author of DDR and I will guide you through the different features of DDR today, the installation process and I will show you some of the best practices, how to use the tool and some of the special cases and caveats which you can see later on in the demos where you might can run into. What is Dynamic Data Resolver? First of all, Dynamic Data Resolver is an instrumentation tool. It is instrumenting the binary so that you can trace all the instructions the binaries executing and it is collecting all kinds of data from strings to register values, memory locations etc etc. It comes with an IDAR plugin which is controlling the backend so you can easily handle everything from this IDAR plugin and you don't need to use the command line tools. You can and I will talk about that later on. DDR comes with the client server architecture so you have the DDR server which is running on the malware PC side. So the PC where you are executing malware and you have the IDAR plugin which is running inside of IDAR on the analyst PC. It is highly recommended to separate these two machines. In theory you can run all of that on one machine but keep in mind that you are executing the malware at the end. So the malware really runs on that machine so you do not want to infect your machine where you have your IDAR installation on be infected with malware. So what can I do with DDR? DDR was mainly built to resolve dynamic values and this is why I have called it Dynamic Data Resolver but it comes with all kinds of other features like the Resolving option you have in DDR. You have the option to resolve certain register values for example. So if you want to know the absolute value of EDI or EBA, EBX or EAX you can just do that with one click. You can also get the pointer to the memory this value is pointing to or even the pointer pointer. And DDR also tries to detect the address which is stored in a certain register if that one points to a certain API call like Virtual Protect. And if that is the case it will also resolve the API call so you can see the human readable name of the function call. After you have run the trace and DDR has all the instruction traces you can highlight the instructions with the color. You can just highlight them depending on how many times they were executed. So you get a pretty quick overview about which basic blocks were executed by the program and how often these basic blocks were executed by the program. As you can see here on the slide if you see a color which is a more warmer color like red or purple you know that this basic block or these instructions were executed many times. So it is likely that it is maybe a decoding routine or something like that. So that already gives you a good clue about what the sample is doing and what parts of the sample are executed and what other parts are maybe not executed. You can also get a table of all the API calls the sample has executed. So you can search through this list. You can search for certain API calls like a virtual alloc or something like that and then you can do a double click on the line and you are jumping to the disassembly code where this API call was called. The same applies for strings. As I mentioned earlier DDR tries to collect all the strings at runtime and it is filling this table with strings and the table is again searchable. So you can look for certain interesting strings like PE for example if you are looking for a PE header and then double click on this line and check out in the disassembly what is going on where this was used. We will see all of that later on in the live demo. Another neat feature of DDR is that there is a smart way to dump buffers at runtime. All you have to hand over to DDR is the size of the buffer the address of the buffer and when or where you want to dump the buffer and we will also see that later on. For example you just have to mark the operands in the disassembly which are storing these informations the other size, the address and at the end where you want to dump the buffer. Unfortunately often malware comes with anti-analysing features and it is not executed like it would be executed on a normal PC if you are running it in a VM for example. So DDR comes with an option to patch the sample at runtime. So for example you can knock out certain instructions or you can toggle the E-flag and manipulate the execution flow. So if there is a conditional branch you can just toggle the E-flag and the conditional branch will do the exact opposite. But again we will see that later on also in the demo. And last but not least you also have the option to completely skip certain functions. You can just mark a function skip it and return a fake return value. So if you have for example a certain function in your malware sample which is checking for virtual machines or for anti-debugging stuff, you can just skip the function and return the value which is telling the sample that it is not getting debugged or that it is not running on a virtual machine. But again we will see that later on in the demo. If IDA and DDR is not enough for you to analyze the sample you can also create an x64 debug script which is automatically executing the sample. So it automatically loads the sample into x64 debug. And it is automatically breaking at that address which you have highlighted in IDA when you have picked this menu point. If you don't like x64 debug you also have the option to create a new executable of the binary with an endless loop at the marked address. So you can mark a certain location or certain address in a site of IDA, pick this menu option and then a new binary is generated which has an endless loop patched at that location. So you can start the binary it starts to loop endlessly and you can attach your favorite debugger to it, restore the bytes and proceed debugging it. Okay, that should be enough for a quick overview about what you can do with DDR. In the upcoming demo we will see all these features in details again. So let's start with the installation. Of course first of all you have to download DDR, you can get it from its repository on GitHub and once you have downloaded it it comes with an installation script and pretty much all you have to do is to execute this installation script and it will guide you through the installation process. Again we will see that later on in the next demo. If you want to stay up to date with the latest versions of DDR you can follow me on Twitter and every time I'm fixing anything or releasing new stuff for DDR I will announce that on my Twitter account. If this presentation is not enough for the information you are looking for you can also find a very detailed blog post about DDR which I have released end of May on our blog which is also describing the different steps, the different features and the best practices and the caveats which you have to be aware of when you are working with DDR. DDR has a client server architecture keep in mind that DDR is instrumenting the binary. So the binary is getting executed at the end. So it is highly recommended to split the analyzing part and the execution part so that you have an analyst PC where your IDA is running on including the plugin and a dedicated malware PC where you are executing the malware sample and analyzing the malware sample. The DDR server is controlling the backend of DDR which is implemented using the Dynamo RIO framework and that one is at the end executing the sample, instrumenting the sample and collecting all the data which is then transferred back to the IDA plugin but we will also see that later on in a demo. Okay so enough theory let's have a look how that looks in the real world. Installing DDR is pretty straightforward. All you have to do is to execute the DDR installer.py script and it is solving all the dependencies for you. After it has downloaded all the dependencies it will ask you a couple of questions about the IDA installation directory the IP address it is supposed to listen on etc etc and after you have done that you can start a local HTTP server or in other words the script is starting an HTTP server for you and then you can move over to the IDA machine and access this HTTP server and download the DDR IDA plugin site of the installation. Then you unzip the file and copy over the content to the traditional IDA plugin directory. That will change in the next release which is coming out very soon and we will move over to the IDA user plugin directory. So that has the advantage that you will not need any administrative rights anymore. Once you have done that you will need to figure out which Python version your IDA installation is using and then you need to tell it to dependencies for this Python version. The request library and the PIFI library and with this you are ready to go and you can move over to the server site again and start the DDR server. After we have seen how the installation works I can give you now a quick walkthrough of the different DDR features which I have mentioned earlier. For this we have a dedicated analyst PC where IDA is running on including the plugin and we have a dedicated machine where we are executing the malware on and where DDR server is running on. Let's move to this malware machine. Once on the malware machine site we are starting the DDR server via the DDR server Python script. When we are starting it there is a little hind that you have to be aware of that there is a caveat with Windows and or Windows command prompt and Python scripts. If you are marking any text in the output window you are freezing the Python application. That means that if the plugin tries to talk to the server now you would run into a timeout. If that happens you just need to hit escape a couple of times or just do a control Z and restart the server if you like. Okay so let's move over to IDA. The first thing you usually want to do is run a trace. A trace is filling all the internal data structures inside of DDR which are necessary for most of the other features. You have two options either to run a light trace or a full trace. A full trace is a trace which is collecting as much information as possible per instruction. For example it is saving all the register values for every single instruction. A light trace is only collecting a subset for these informations but enough information that you can have a look at the API calls for example or at the strings which were traced or to get a source operand. A light trace is usually something which I am running when I start to analyze the sample and if I just want to get an overview, if I just want to highlight the traced instructions for example or if I just want to see the API calls then the light trace is good enough. Later on when I am analyzing a crypto algorithm for example and I need more informations for example all the registers then I am running a full trace but I am only running a full trace for a small address range or for a few basic blocks for example. Because this is really time consuming it is also consuming a lot of memory. So you usually want to limit the amount of instructions which you are instrumenting within full trace. Okay enough about traces. Let's run the light trace and check how that looks like on the DDR server side. So the sample is executed and the dialog box which I have just seen just belongs to the sample code. It doesn't have anything to do with DDR. Don't be confused by that. Once the analyzer is done you can see that the trace log file is written to the same directory where the original sample is located. And you can also see that the temporary trace files were deleted based on the server command and then transferred over to the IDA plugin. So now we can switch back to IDA and we also see this method can switch back to IDA and we also see this message inside of IDA that the light trace was done successfully. So this means that DDR know has all the information it needs and we can execute other features like highlighted trace instruction which is giving us an overview about which basic blocks were executed or which instructions were executed. Okay so let's move to the next feature. You can knock out instructions at run time. So if you have certain instructions which you want to get rid of like the dialog box which we have seen earlier you can just mark these instructions and you go to the patch menu in DDR and then next time you execute the sample so for example you run a new trace then these instructions are knocked out they're not getting executed anymore and you can see here that it is responding much faster because we didn't have the pop up of the dialog box and the sample immediately proceeded with execution. Okay the next feature which I would like to show you is you can use the dynamic values which were collected by the trace. First we are doing a trace again. This time we are just doing a trace over a couple of instructions. You're picking full trace for marked address range and once this is done we have all the values from these instructions inside of the database. So we can just go to get value for source operand including the value for rax in this case or we can just get the values from memory pointers like you can see here or all kinds of other informations DDR has collected. Next nice feature is that you can collect all the strings and API calls at run time. You can show both of them via tables where the DDR menu is located. So if we are looking at the strings for example this is a list of all the strings which we have collected at run time and of course you can also search for something in there like PE for example and if you are double clicking on the line then you are jumping to the line in the assembly where it is used. You can also have a look at the API calls which were executed at run time and again the same strings you can search for something and double click on it and then you see where it is used inside of the code. You have seen earlier that you can manipulate the code flow by nipping out instructions but there are also other options inside of DDR which are manipulating the code flow. The next one which I would like to talk about is the option to toggle the flexor. So for example if we have a code like this where we have a conditional jump and a comparison before then we can toggle the E-flag at the jump. In this case you have to know that EAX can never be bigger than 5. So at least in theory this jump should always be taken in this code and the program should print out main A is not greater than 5. If we want to manipulate that we can just mark the GLA instruction, do a right click and go to the patch menu inside of DDR. Inside of the patch menu we pick toggle E-flag. In this case we have to toggle the SF-flag and once this is done we can now just run the sample if we want. So for example again over the patch menu if we pick that one then the sample is just getting executed but we could also use any other feature of DDR running a trace or doing a dump which we will see later on. All these patches which I have applied will work for all the DDR features. Once we executed it then we can move over to the DDR side and check the output of the file. Sorry of the executable. So here you can see that the patch worked and the program printed out A is greater than 5 and this should never happen. The last option you have is you can skip functions at runtime. So for example if we have my function 1 here in this case and maybe something which is doing some anti-analysing, anti-debugging stuff you can just skip it and you can fake the return value. You are just marking the first instruction in the function and you are going again to the patch menu skip function at marked address at runtime and you hand over the faked return value and that's it. Now you can execute the sample again moving over to the DDR server side we see that the sample is getting executed and in the output of the sample we should see that the my function 1 output is gone because the my function 1 is not executed anymore. Another main function of DDR is that you can dump buffers at runtime and you can do that in a smart way. Later on the string will be copied into this buffer which we are going to dump. So remember that for later. So for example if you have a function like virtualalloc all you have to do is you have to mark the operand which is storing the size of the buffer now I get buffer size and the next thing is you mark the operand which is storing the address of the buffer which you are going to dump and get buffer address and last but not least the final step is you mark the instruction or the location where you want to dump the buffer. So use marked address to dump buffer to file. That's it. Now you can go to the dump menu and execute the sample and the buffer gets automatically dumped at runtime. Once it is dumped it is transferred over to Ida and you can store it somewhere on disk. Here you can see that it is the buffer which I have mentioned earlier where the program has copied the PE string into. If you want to debug the sample inside of x64 debug you can also generate x64 debug scripts which are automatically setting a breakpoint at the location which you have. So once you have generated the script you can load it into x64 debug. All you have to do is to run the script it will automatically start the sample and break at the breakpoint which you have highlighted in Ida. So here we have reached the breakpoint the script has finished and now you can proceed debugging in x64 debug. Last feature which I would like to show you is how to create endless loops in binaries. So if you want to create an endless loop you can just mark the line where you want to create the loop and then you select create executable with loop at marked address. Now DDR is creating a patchable with loop at marked address. Now DDR is creating a patched binary and you can move over to the DDR server side and you will find a patched binary in side of the samples directory. Now you can start this binary just double click on it and at a certain point we are reaching this endless loop. So now we can attach our debugger to it and proceed debugging the sample. So after pausing the sample of course the first thing you have to do is you have to replace the patched bytes the patched bytes of the endless little help in the DDR server output to see what kind of bytes you have to patch. Now you are just copying the address into this command and then finally you have the original commands back inside of the binary. So when we are proceeding to debug you see that this changed to the original bytes and now you can just proceed debugging like usual. That's it. Okay, so this was the installation and the feature work through of DDR. Let's move on and have a look at some of the special cases and of course the best practices. The better you know DDR the more efficient you can use DDR. And as usual the easiest is to watch a quick live demo about it. When I start analyzing samples I like to run a quick light trace. Light trace is only executing 20,000 instructions by default. Now you can change this default value. If you are running a light trace you can probably set that up to 200,000 but this is in this case for this sample not necessary so we can leave the default value. Once the light trace is executed we can highlight the trace instructions to see which basic blocks were actually executed. This was pretty quick in this case so let's see what's going on. Highlight trace instructions and we see that there are only four basic blocks which were actually executed. So it seems to be that there is some really analyzing checks going on. So let's go into the last function which might be responsible for this check. So when we are scrolling down a little bit we see that it seems to be that this function is dynamically resolving the get-native system in for API call. It's using get-process address. We see that pretty often in malware samples. Then it is subtracting the address in this variable and a bit later on it is subtracting 10 from this address. And a little bit below we see that this value is pushed as an argument to the next function. So it seems to be that the first argument of this function is this get-native-system in for API call function address minus 10. So when we are looking at the first argument here we see that it is executing a couple of mathematical instructions and it seems to be that it is just adding 10 to it so it has restored the original address and it seems to be that it is just calling the get-native-system-info API call here at that point. Unfortunately in real malware this is often much more complicated. So in real malware we often see that these calculations are distributed all over the place and they are heavily obfuscated. So it is often very difficult to figure out what is actually called at this point. With DDR that is much easier. You can just do a right click and you can get the value of this function pointer. Just pick get-value for pointer and source operand. And then you see the value which was used at runtime. So it is confirming what we assumed get-native-system-info is called. With this information we can now go one level up and we can change the name of this argument to function pointer get-native-system-info minus 10. And we have also seen earlier in this function that there was one parameter pushed and this is the second argument of this function. So if we are looking at the get-native-system-info we see that this is actually a pointer to the system infrastructure which is storing all the system informations. So again we can go to the function above and we can find the second argument here and we can also rename it to something like system-info or whatever you like. As far as this is a stack variable which is pointing to a structure, we can also do some housekeeping and quickly assign the right structure to it. So that makes it a little bit easier when we are proceeding the analyzers to see what's going on. So here we can see that here is actually a comparison between the number of processors and three. With a closer look we see that if the number of processors of the machine where the sample is running on is smaller than 3, then we are just printing out a likely virtual machine detected. So if it has two or less processors the sample assumes that it is running on a virtual machine. If it is more than two processors it is returning 0. And again if we go one level up we can see here that it is comparing EAX and only if it is 0 then it is proceeding with the rest of the Melba code. If not it is just exiting. Let's rename the function quickly to something like the mCheck and let's proceed analyzing. So of course we are also interested in the rest of the code and to make sure that we can execute it on a virtual machine we can just toggle the eFlex like you have seen before. Now in this case it jumps 0 so the 0 flex are fine. So let's run the trace again and wait for the results. Okay so I've cheated now a little bit and fast forwarded the video we run into a timeout. So we are seeing this warning message here and it is telling us that the response from the DDR server took too long. By default the plugin waits for 30 seconds to get the results from the DDR server, the trace for example. And if you like you can change this behavior here in the API timeout. You can increase the timeout for example to 60 seconds or to 100 seconds or whatever you think works and then the plugin waits for a longer time. So you've seen earlier that you can also configure the number of instructions for example which are supposed to be analyzed. You can play with these two values a little bit of course if you're increasing the number of instructions much more data will be collected and the files which are going to be exchanged are also much bigger. So sometimes it helps to increase the timeout to do these kind of long traces. But nevertheless make sure that you're not increasing the number of instructions to a too high value. Keep always in mind that it is also increasing the file size of the data which is collected. So coming back here to our issue that it timed out we can for example now look over to the server side and we can check if there was some internal error for example there could be a bug inside of DDR which caused a crash for example or there could be some other reason a super endless loop or whatever and a sleeper whatever. And we see here that the analyzes run for 60 seconds so it seems to be that it was successfully executed. When we are now going back to EIDA we can proceed with the analyzes of the malware to get an idea about what happened. And usually you would know check these instructions what's happening of course I'm not doing that in detail here in the demo and I know the result and the reason for the timeout in this case is a sleep timer. So you have a sleep timer here which is actually waiting for 60 seconds and of course that is more than the 30 seconds and we haven't reached the maximum number of instructions at that point yet. So the DDR server side is still trying to analyze the sample but there are no new instructions but before this sleeper is not over so this means that the analyzes are still going on on the server side but the plug-in runs into the 30 seconds timeout. So we could now increase the timeout for example and just wait for a little bit longer or again we can just here knob out these instructions and run it again. I don't like to wait so I prefer using the knob out functionality and now we are running the trace again and now it should be a little bit quicker. So light trace done and now we can clear the old highlighted instructions clear highlighted instructions and we can highlight it again and now we can see the new path with all our patches which we have applied. Now you see that we have manipulated the VM check here even if it has detected the VM bear, nevertheless we toggled the infleck here and we are going this way and now it is checking here if its name is evilmalve.exe and if that is not the case then the sample is going this way and a quick summary of what's happening here is copying itself over to the temp folder and then finally here after the sleep it is creating the process and starting another instance of itself and just from this other directory. So this is the reason why we are seeing that we are reaching here this exit call and the sample seems to be or the execution of the sample seems to be stopped at that point. In reality it has started the new instance and the new instance is running under this name so it will now go this path and it will proceed to execute the rest of the code. This should be enough for this sample so let's move on to the next one, actually one which we found during a recent appetitum campaign. It is an executable which looks like an XML file but as you know if you run that on the command line it will execute it like any other former executable. To get an overview about what it is doing as usual we are just running a quick light trace with ddr. When we are moving over to ddr we suddenly see what that the window disappeared. So it seems to be that maybe the process was killed or something like that, interesting. So we are moving back to Ida and we suddenly see that the light trace was nevertheless successfully executed. It seems to be that the ddr process is still running in the background. So what's going on here? To get an idea it's always a good idea to check the API calls which were executed and when we are looking at those we see that there's a couple of initalization going on and stuff like rebuilding the IRT for example a lot of get process address calls and after that we suddenly see oh there is a show window API call. That looks interesting because with show window you can manipulate the window and when we are looking into the disassembly we see that it is using get console window to get the handle of its own window and then it is executing show window and show window is using ESI for the command show parameter and ESI is cleared right before. So we can be pretty sure that ESI is zero in this case but even if it would be a more complex function in a different sample for example of course we can always use ddr to get an idea about what this value is here in our case zero obviously. So it is handing over zero to show window and if we are having a closer look to the show window function we will see that the command show parameter is offering a couple of different options and if it is zero it is just hiding the window from the desktop so we have solved the issue why the command window suddenly disappeared. It was not killed into the background. So this is one of the examples how you can pretty quickly analyze what actually happened with your sample and now you could either leave it like it is in this case because it doesn't hurt or if you still want to see the window you just go ahead and you kill these instructions because you don't need them for anything else. You can just knock them out about marked instructions and then we are restoring the snapshot on the other side on the ddr server side and once it is restored we can just run the sample again just do it light trace again and now we can see that it is running normally like before but it is not hiding the window anymore because we have knocked out these instructions and we are done and we can proceed with our analysis. Back to the presentation another special case which I would like to talk about is if you want to analyze the sample in an air-gapped environment so for example if the sample is doing excessive anti-VM bed checks or if you have to disable the networking for any reason there are probably many cases why you want to analyze the sample on an air-gapped system you can do that because the engine of ddr is implemented in a way that it is a command line tool and it is heavily leveraging the Dynamo-Rio framework to do all the instrumentation so at the end the ddr server script is just executing this command line tool to inject the ddr DLL into the sample the ddr DLL is the engine which is doing all the analyzes which is saving all the traces and the registers and so on and if you are running this command line tool via dr run Cclient DLL and the sample to instrument you will get a JSON file back or actually you are getting two JSON files back for the instruction trace and one for the API trace these JSON files are looking like this so they have all the informations per instruction in it so all the registers or the values of the registers at the point of the instruction the eflags, the disassembly etc etc plus the memory location which might be interesting and so on and this is a JSON file which is getting transferred over to the IDAR site and which is the IDAR plugin reading to fill in its data structures and with this file you can then use the plugin like you have seen before you have seen earlier in the command that you have to hand over a configuration file and you will find in the docs directory of the github repository a sample configuration file which is heavily commented and gives you an idea about what kind of commands you can write into this configuration file we will see in the demo you can also use the output of the ddr server script to get an idea about what's going on and what kind of values you can use so for example you can just generate a certain command via the plugin and then you can check the generated configuration but again we will see that later on in the demo so talking about the demo let's have a look at it and see how that works on the command line so when you are running the command line tool the first time you can cheat a little bit by looking at the server output the ddr server is printing out the command which it is actually executing this is the command and the configuration which belongs to the command which was automatically generated by either plugin so you can start with using the GUI and then you can have a look at the configuration file and the command line and this gives you probably a good idea how these things are actually working and for the details again you have the documentation in the docs directory of the github repository so let's just run this again and once it is finished we see that it has written all these trace files to the samples directory let's move over to the samples directory and we see that we have all these generated traces here but there are also further files like the ddr process trace and the ddr process trace is a file which is logging all the processes which were started by the sample and pretty much the same but for threads are these threads files they include the information about which threads the certain processes have started so if we are looking at the processes file for example we see that the original sample has executed a second process the evilmalve.exe and ddr is following all the threads and processes which the original sample is creating so we have seen earlier in IDAR the trace which was imported for the main thread and for the main process we haven't seen the second process in IDAR so far but the trace was generated so we can go back to IDAR and we can import this one and then we have all the instructions which were executed by the process evilmalve.exe the second instance of the exe file and let me show you how that works okay so we are back in IDAR and you hopefully remember the sample which we have looked at earlier the buffer test dot one the one which was checking if its name was evilmalve.exe and if that is not the case it is copying itself to the temp folder and executing itself under this name again and you remember that we were only following the main process here and we were able to highlight the instructions down to the point where the initial process exited but of course we are also interested in the second part what happens with the second instance and what kind of code is the second instance executing one thing we could do of course is we could just manipulate the code again like we've done before or now we are importing these files which we have just generated so we can clearly highlight the instructions and we are using the low ddr trace button to go to the directory where we have imported these traces which we have seen earlier so now I am interested in the one of evilmalve.exe so I am loading this one for the traced commands and I am loading this one for the API calls so now we have successfully imported these traces one for the API calls and one for the instructions and now we can use ddr like we've done it before and you see that the second instance which is running under evilmalve.exe is of course going this path and now we can proceed analyzing these parts and look what it is doing like we've done before get source value or whatever helps us to understand what this sample is doing the last thing which I would like to mention is that you should really keep in mind that it is good practice not to run traces for too many instructions, keep in mind that stopping at every instruction and collecting all the registers and all the memory information of course it takes a lot of time and consumes a lot of memory so it's usually good practice to just mark the basic blocks you are interested in for example if we are just interested in the values of these two basic blocks it is usually a good idea to just select them at basic blocks to list and this one select at basic block to list and you can see that it was successful here and then run the trace just for the basic block list and it is done, that is much faster you don't have to wait for too long and you're not creating gigabytes of files just keep in mind that if you are doing that that you now only have these two basic blocks in the database so all the others are not in the database at the moment which means that if you try to get a value from here then of course you are running into an error it's not in trace it can be a little bit confusing in the beginning if you don't think about it but usually you are getting pretty quickly used to that and now you can analyze the functions which you are actually interested in get source value or whatever you are looking for that's it, so you have seen that DDR is not replacing your brain but nevertheless it speeds up a lot of reversing tasks and it is usually a pretty big help in analyzing malware samples with this I'm done for today and I'm giving back to the folks from the blue team village