Ac mae'n gwybod am gwirio i mi wneud hwnth gweithio a'i wneud f rakwch ei ddechrau sefyddech chi'n dweud yn y tarloedd i ffurbidio'r seden. Rydyn yn ysgriff eich hollu'r un i gyd. O'r inchon wrth i fan ddechrau arweithio yr hyn y gwbl yna, ac mae'n gweithio'n ddweud a'i â chyflwyd i'r rydyn ni, rydyn ar fawr. Ac rydyn ni'n gweithio'r hyn o'n gweithio i chi'r hyn o'r gweithio'r hawn.  We've not had breakfast yet and we hope that we can all wake up together with this presentation. So let's talk about mobile point of sales terminals. Mobile point of sales terminals has seen a huge growth over the last few years. We've moved from a single vendor which has dominated the marketplace, so we've seen Square dominating this space for the last eight years and now we have a number of different vendors in this space. You can open an account in less than five minutes and typically these readers cost less than $50. So for these reasons they have grown really in their popularity over the last two years. You can find them pretty much everywhere, so these are some of the pictures that we've taken. So I've seen them in taxis, in cafes, that's my gym as well, completely unattended. And like traditional ATMs and like traditional point of sales terminals, they sit at the end point of payment infrastructure. So for these reasons they're very attractive to criminals, both for the testing of cars and for the movement of money. But of course we weren't the first to investigate mobile point of sales terminals. In 2014 MWR Labs gave their presentation at Blackhats in which they discussed findings around the mirror shuttle reader. So at this time this was being white labelled and used by a number of different vendors. And of course this kind of practice is still very common today. So in their presentation they documented a number of vulnerabilities of which many had overlap with traditional point of sales terminals. Then in 2015 three undergraduate students from the Boston University presented their findings on the Square Magstripe Reader at Blackhats. We felt that both of these research projects were really significant contributions in this area, but they focus on single products and the market has matured considerably. So for this reason we didn't feel that they dealt with the more contemporary broader issues associated with this marketplace. At the beginning of this project we started with just two card readers and two vendors and very quickly this has grown into a project which encompasses seven card readers, four vendors and two geographic regions. We chose to assess the most popular devices both in Europe and in the US. We've chosen to focus on PayPal, Square, Isettle and SumUp. Now some of these vendors operate in both geographic locations and where possible we chose to obtain the accounts and the readers for both locations. And this is because there are quite considerable differences between the processes and the applications and even the readers depending on the region. Now at the beginning of this project we had a pretty good idea of the kind of attack factors that these devices would be vulnerable to but we wanted to see how probable these were in practice. Still we had a very simple question which is how much security can really be embedded in a device that's potentially free. So we chose to assess five different areas of the payment ecosystem of these devices. We chose to look at the communication between the phone and the payment server, communication between the device and the phone, physical security mechanisms within the hardware of these devices, the mobile application and the associated mobile ecosystem and finally secondary factors. So secondary factors are things that affect the overall risk and security of the ecosystem such as the kind of checks that are being carried out during the enrolment process. So before we progress a bit further into the presentation I'm just going to give you a bit of background on how payments traditionally work for those of you that are not so familiar with that. And then we'll talk about how mobile point of sales terminals fit into this process. So normally when you go into a shop and you go to pay for services or goods you'll either interact directly with the terminal or you'll hand your card over to the merchants. Once your information has been read by the terminal this will be passed to the acquiring bank for the merchant. Now at this point in the process they don't actually know who your issuing bank is so they'll ask the car brand such as Visa and Mastercard to determine this information. Once it's been passed to your issuing bank they'll check that you have the necessary funds to complete the process and then they'll carry out some fraud checks. If they're happy for you to go ahead and make the purchase they'll send the response along the chain and you can go ahead and make the transaction. Now if we compare this process to the mobile point of sales terminal you can see that the key difference is that the merchant no longer has a direct relationship with the acquiring bank. Instead the mobile point of sales terminal provider acts as a payment aggregator. So this means that they will or won't assess risk at the same level as a traditional acquiring bank. They also may choose to mitigate some of the risk in other ways for example contractually. But essentially what you end up with is two merchants in this model. From there things are pretty similar to how I've described in the previous slide. So we're going to be focusing on card payments. This is because the core functionality of a mobile point of sales terminal is around taking card payments. But it's just worth noting that within the mobile application of all of these devices they do have features to account for things like cash transactions. So when you go to make a payment what happens is there's a list which broadly describes in terms of priorities the types of payments that your card can make. And this is confirmed with the configuration on a terminal. This list will vary depending on the issuer, the card brand and also the geographic location. But generally speaking we can understand that certain types of payments are more secure than others. So for example chip is commonly considered most secure. And this is actually because there's a high level of assurance that the card holder was present during the transaction. If you compare this to a swipe transaction this is considered low in its level of security. And that's because most of us in this room know that if you take a MagStripe you can clone the data off the MagStripe. You can also forge a signature relatively easily as well. And there's no signing of the transactions so there's no cryptogram. Next we need to understand that whilst EMV has been incredibly successful in its adoption globally it's actually been much lower in the US than compared to many other parts of the world. And this is just primarily due to the number of parties that are involved in the rollout process. But what's helpful in this scenario is that we can look to places like Europe and we can look at the kind of attack vectors that are happening in Europe and use them as a good indicator of what might take place in the US. You can see that for credit cards adoption of EMV is actually quite high so 96% but less than 50% of all transactions are made using a chip. So this is a really important fact that we need to keep in mind as we go through the process of presenting these findings. If we look at the picture for debit cards that's even worse so less than a quarter of all transactions are made using a chip. And if we look at the overall growth of mobile point of sales terminals you can see that only within a couple of years almost 50% of all transactions will be made by a mobile point of sales terminal. So how do these devices work? So this schematic overview represents quite simply how each of the components in the system work. So we have the terminal which communicates via Bluetooth to the mobile application and the phone. This in turn communicates to the payment server of the mobile point of sales terminal provider via a network connection or over wifi. So now that we have a broad understanding of how payments traditionally work and how mobile point of sales terminals fit into this process we can begin to discuss our findings. So we're going to be talking about the sending of arbitrary commands so with this attack vector what you can do is you can socially engineer a cardholder to carry out additional payments or to carry out a less secure payment such as SWITE. Then we'll talk about how for some of the terminals we looked at we were able to modify the amount so the cardholder thinks that they're actually authorising a much lower value. We're also going to talk about how we obtained remote code execution in one of the readers so this provides us with full access to the file system. This means that we can capture track to information before it's encrypted and we can even collect pins. Then we'll discuss our hardware observations so looking at the physical security mechanisms within the terminals themselves and finally we will discuss the secondary factors which affect the overall risk and security of these systems. So Bluetooth is the main form of communication between the terminal and the phone and the mobile application so therefore it's important for us to have a good understanding of how this protocol works. I'm sure many people do have an understanding of this but I'm going to assume that not everyone in the room does so let's continue. So Bluetooth can be roughly divided into two parts the host and controller layers. So the Bluetooth profiles and GAT and AT they deal with the actual transfer of information. L2CAP deals with segmentation and reassembly of packets. The host controller interface now this is the lowest level that we can directly interact with. It's commonly used for debugging the communication of Bluetooth but if you're a security researcher it's also super helpful to try and work out how the device works. So this is something that we're going to look at during this process. Then the link manager protocol this deals with pairing negotiation and encryption and then baseband is the last layer of framing before we have Bluetooth radio itself. When we talk about Bluetooth we're actually talking about two different protocols Bluetooth Classic and Bluetooth Low Energy. Now how these communicate is quite different. So Bluetooth Classic uses something called Bluetooth profiles to communicate and all of the terminals that we looked at that use Bluetooth Classic use RFCOM. So what this does is when you communicate from the terminal to the phone and vice versa what happens is it simulates a serial port which allows you to send large chunks of data. If you look at the way that Bluetooth Low Energy on the other hand communicates it's quite different. So with this you have a much smaller packet size and it produces a hierarchical structure under which certain characteristics are defined. So each characteristic has a value and it also has a number of properties such as read, write and notify. In order to attack a Bluetooth device or even just to communicate with it we need to understand what its address is. So its address consists of three main parts. We have the upper address part sorry the non-significant address part which isn't significant for any functions. Then we have the upper address part and the lower address part which is unique to each device and that's present in every frame of communication. Now the non-significant address part and upper address part is known as the organizationally unique identifier. So if you know a range of organizationally unique identifiers it's possible to sit in a public place and identify a potentially vulnerable device. For example you could go to a cafe you can use one of these Bluetooth scanners and you can identify both how close you are to the device based on the frequency and also the type of device it is. There are many different attack vectors for Bluetooth but we're going to be focusing on two. So the first is man in the middle or eavesdropping and the second is malicious device manipulation. So in the first instance what you're trying to do is you're trying to intercept the communication between the master and the slave in the network. In the second instance we're going to try and connect directly to the device and get it to carry out some functions for us. Some of those functions might be intended by design but many times that isn't the case so we're going to try and get it to do some things that we want it to do but that the developers never intended to do. So in order to carry out a man in the middle attack what you need to do is to follow the connection process between the master and the slave. You're trying to collect enough information to actually decrypt the connection. In order to carry out this attack it really depends on the type of Bluetooth that the device is using. So if the device is using Bluetooth classic using an enhanced data rate you'll need something like this front line BPA 600 which for all of us in the room is not really an affordable option. But if you're looking at a device that communicates using Bluetooth Low Energy you can use the Texas Instruments CC 2540 kit or an Ubertooth 1 and both of those cost less than $150. But this kind of attack vector is actually not the easiest to carry out and we're looking at payment terminals. So when you think about payment terminals most of the pertinent information is going to be encrypted from the payment terminal to the payment server. So for this reason sniffing or man in the middle isn't really a viable attack method for us. So just a quick note on enhanced data rates. So when we were carrying out this research there isn't a lot of information online talking about how you can determine what a device is using to communicate. So the first thing you can do is you can carry out a reconnaissance scan using something like HTI tool which is natively available in Linux and this is going to list EDR as a feature for the device. The second thing that you can do is you can capture some of the packets using a tool such as Ubertooth and this is going to display headers only so you're not going to see any data payloads in this. So in that way you can confirm that a device is using enhanced data rates and you know that it's not really viable for you to try and attack it using a man in the middle attack. So this brings us on to our first finding which is the sending of arbitrary commands. So what happens if you connect directly to a device? Well you can get it to initiate a function such as a payment, you could get it to display some text or you might be able to turn it off or on. But we also need to keep in mind that the pairing process might actually introduce some obstacles. We might need to physically interact with the device. And it's worth noting for developers that Bluetooth as a protocol doesn't actually feature any user authentication or any input sanitisation so you have to implement this at the application level. So in order to carry out attack where we connect directly to the device and we use this device to carry out some sort of malicious operation, the first thing that we need to do is we're going to have to carry out some prerequisite work to understand what features and functions are available on the device and how we can use them. So what you need to do this is you're going to need access to a mobile phone or a cell phone which has the ability to enable developers options. So within that you want to enable HCI logging. You'll need access to the mobile application for the device and you'll need access to the physical device itself. The next thing that you want to do is you want to carry out a sample of transactions for the terminal. Now the reason for doing this is it's the best way to just get a broad spectrum of how the device works. So once we've done that, we can take the HCI log from the phone and we can import it into something like Wireshark to analyse the output. So here you can see the sending of the message Inserts or Swipe card to the display. So we can use the information within the HCI log and the mobile application to work out how all of the features and functions work. So in this next example you can see that I've inserted my card incorrectly into this device and so it says please remove card. So we're looking at two packets of information. That's because this terminal communicates using Bluetooth Low Energy. So here we can see the UUID value. So this is really important. We'll need to know what this value is in order to send information to the terminal. So if we look at this in greater detail, you can see that the value is actually made up of five parts. The first is a leading part and this contains a command ID, a counter and an intended payload size for the message. Then we have the message itself, so please remove card. Then we have a trailing part and we have a checksum which is an X modem and then an end value. So now that we know this information for this specific terminal we can basically calculate anything we want to send to the display of this terminal. So we found that three of the terminals we looked at, so IZETL, SUMUP and the Mura M010 reader which was available via square and also PayPal are vulnerable to this kind of attack method. So this means that we can send a message such as please swipe now and get the card holder to sort of downgrade the method that they're using to authorise a payment for. Or we can send a message where it says payment declined or payment cancelled and get them to carry out an additional transaction. So let's have a look at this in action. So I'm just using a simple script here and we're going to force the card holder to carry out a transaction using the magstripe instead of the chip. So if we have a look at this next example this terminal is using Bluetooth Classic so the data looks a little bit different from the previous example. So we can see the sending of insert or swipe card to the display. Similar to the previous example it's made up of three parts so in the leading part we again we have an ID, a command ID value a counter and the intended payload size. And then we have the message which is insert or swipe card and then we have the checksum which is just a simple x or value. So again now that we know this information we can calculate anything we want to send to the display. It doesn't have to be insert card it can be any kind of message we want to send. So what we're going to do in the next example is I'm going to show you how we can actually interrupt the payment process a message which says payment cancelled but you're going to see in fact that the payment has been authorised. So we can see payment cancelled but in just a moment we're going to see on the phone that we receive an SMS which shows that it's actually been authorised for that value. There we go. So this brings us on to our next finding which is how we can modify the amount for certain types of transactions. We're going to use the information that we've learnt in the first process and apply this to the next process. So let's try to affect payment comments. So there are actually many ways to intercept payment comments reverse engineer them understand the structure and of course tamper them. So first of all all comments surprisingly are readers getting from the server side which means you can intercept them via HTTPS main and middle which purpose you need to bypass SSL pin-in somehow and obviously there are a lot of ways to do this. Next was already mentioned is just to enable HCI login and then get access via Wireshark to the log and to see comments. Next you also can rebuild an application, enable login messages and then get an access to them via Android Debug Bridge. This method is also very useful just to understand the structure of comments finding code examples of other comments and for other purposes. And finally if you also don't have any other options you can also use some external device such as number 2s to get access to traffic. So here are two examples from two different readers and for both readers we used two channels just to see the correlation and there are payment comments and in first case we made a payment for we initialized payment for 750 and buys which are responsible for this value are sent in hex so 0 to EE and in second case we also so in first case we used Android Debug Bridge and also get access via HCI tool. And for second case we enabled Android Debug Bridge messages and also get access to traffic via HTTPS main in the middle and in that case amount was sent in plain text so 0100 and as you can imagine in both cases just to send any amount on a reader you want you just need to change those bytes and then recalcul check sum. So what actually will happen if fraudulent merchant will change amount between reader and the phone so he can force customer to make higher value amount by sending lower value on a reader but in fact sending a higher value to a server side, to the merchant to the service provider side. So that's exactly what we did so we sent to the service provider 1 pound 23 pence but we actually show only 1 pound to the customer he make a payment and then he's signing so we don't even need to forge signature which is pretty good so this fraudulent payment will pass at least for max stripe why? Well simply because during the max stripe transactions reader will send only track to data when for example for envy transactions reader will send inside of a payment cryptogram amount, currency and all additional information for example for contactless transactions there are also certain modes legacy modes which allow to send less information and it will be no amount inside of a cryptogram and all these operations also can be affected and the last problem is that surprisingly for all service providers limits for transactions such as max stripe are completely insane for like up to $50,000 which means they rely only on an issue or acquiring bank in terms of stopping off suspicious transactions so let's imagine ourselves we can open account merchant account in less than 5 minutes then we can force customer to use less secure form of payment like max stripe instead of chip and pin then we are going to show him completely arbitrary amount like $1 on a screen, over reader and on a phone but actually it will be possible to carry out transaction for up to $50,000 a time and the last problem is that this fraudulent transactions can be made for example 10 minutes after customer has already swiped card and has already left the building it is pretty good for fraudulent merchant what we will recommend to vendors obviously even if you as a service provider can't affect firmware you can't affect the specification of communication between reader and the phone you still can mitigate these risks first of all you should control your mobile ecosystem and should not allow to use router devices because router devices is a way to get access to traffic make reverse engineer reverse engineer in work and basically we did for customers recommendations are much easier just do not use max stripe what we also found is that sometimes it's much easier to compromise mobile point of sale terminal than traditional terminals so all you need for this is just to get a good reverse engineer guy and obtain him unencrypted firmware so let's talk about obtaining firmware and how firmware process works so normally firmware is stored on the server side which means will be sent to the phone via HTTPS and then to reader via bluetooth which means you can basically get access to firmware exactly the same way as to every other comments like HTTPS main in the middle so sometimes firmware and configuration files are stored and sent to reader as a set of encrypted comments sometimes they are stored as links to encrypted firmware such here and in this case you can try to enumerate versions of firmware and sometimes it will be possible to obtain some out of date versions and then you can try to downgrade them on the reader but sometimes you don't even need to do this and you don't even need to open a merchant account use a mobile phone so all you need for this is just to use google and find some github repositories which will contain out of dated firmware what unencrypted firmware will contain yeah first of all it is a whole set of configuration files which will send what messages should be shown on the reader and some other type of operations can be used which means that you can for example disable chip and pin on the reader and finally it is a whole set of binary files on the reader side where you can find some remote code execution by a buffer or stack overflow and that's exactly what our average engineer did in the end so he found out of date version, downgraded it on the reader and got a full access so we got root access in the end which is pretty good because initially we didn't expect anything like that why it is so important why it is a holy grail of getting a fully compromised mobile point of sale terminal one of my favorite cases when in 2014 it was very unusual type of fraud in Brazil when hackers which stole track 2 data from cars used this information to make some payments on a compromised mobile point of sale terminal so basically probably they compromised it pretty much the same way as we did and what they did is they used track 2 data but sent information to a bank by saying that operations were chip and pin and the most curious part was that those cars didn't even have chip on board that's how basically bank understood that that was a fraud next of course you can just start to collect track 2 data before it will be encrypted so if you'll get access over binary file which is responsible for encryption you can get access to unencrypted track 2 as well as unencrypted pin codes because mobile point of sale terminals work pretty much the same way as traditional point of sale terminals or ATMs so k-pad has 2 modes encrypted mode and plain text mode and if you'll get access over a binary file which is responsible for switching between those 2 modes you can basically force a customer to enter pin code unencrypted and finally just to understand how payment ecosystem works, how payment research works this small piece of device is very useful that's basically what we did and why we did it and the last problem is that how to keep persistence on an infected device because for example in our case after rebooting, after each rebooting mobile point of sale checked the integrity of their own file system via digital signatures we bypassed this check but the last problem was that mobile application also has to check out of date firmware on a reader and should not be allowed to use out of date firmware on a reader but surprisingly in our case all you had to do is just to drop a packet to a server with request or response about version of firmware mobile application took like couple seconds and came up to you by saying ah I don't care what firmware version is I'm ready to work which means you can use disinfected devices in merchant's hands for a long long time to collect two data for example so let's imagine, yeah you as a fraudulent customer get a physical access to reader for couple seconds during a payment switching on the pairing mode connect your own malicious device downgrade the firmware on a reader and then send an exploit to get a full access to a reader then you bypass updating process and keep persistence on a device and just basically collect track to data on merchant's hands so this in this case our recommendations obviously it is very important to check that your customers don't use out of date firmware as well as this is completely unnecessary to allow customers to downgrade firmware on their own devices we also found very interesting practice for one particular vendor which were checking potentially infected devices potentially infected entities and when one entity was connected with another entity such as for example reader with mobile phone mobile phone with account all these sets of entities appeared to be potentially infected and blocked in the end so it's very unusual practice that we found on the market and just obviously as soon as we get a full access to mobile phone of cell terminal well it's really hard to launch Doom there you know we just decided to put more cats on the internet and last about the hardware observations yes surprisingly in these devices which cost less than $50 the hardware security was pretty good for example very good protection normally very good protection against antitampering such as antitampering foil which protects against opening really sometimes even pressure sensors and the last problem is that even if you'll get access to internals without alerting antitampering mechanisms all you'll see is just a set of proprietary protocols sometimes no GTAC which means that without developer certificates without developers manuals you hardly will get anything so this brings us on to our secondary factors so a lot of the vendors that we looked at tend to take very different approaches so some of the vendors we looked at tended to focus on the onboarding checks during the enrolment process whereas others focused on the transaction monitoring so as Tim mentioned one of the vendors we looked at carried out quite complicated correlation between different devices different accounts we had quite a lot of difficulty during this assessment process trying to keep access maintaining access to an account but this is a really sophisticated and effective way of identifying a fraudulent merchant as I mentioned at the start there are significant differences depending on the geographic location so generally speaking we noted that readers and accounts in Europe were far more restrictive than those in the US so for example Square who operates in both locations they permit MSD transactions and offline processing in the US but this isn't possible in Europe and finally with regard to the mobile ecosystem we were pretty disappointed to notice that almost all of the vendors didn't protect the mobile ecosystem at all and the biggest approach of course is that it's the very thing that allows us to gain access to much of the knowledge that we needed in order to understand how these readers work so this table represents a broad overview of all the different readers, vendors, manufacturers and areas of assessment that we carried out obviously this marketplace places emphasis on user enrolment and onboarding so they want it to be easy for customers they want it to be simple but it doesn't take into account the fact that security should in fact be incredibly high in all areas to counteract the incredibly low barriers for entry so as I mentioned at the start if you want to see the uncensored version of our presentation go ahead and access that on the media server today you're welcome to do that we spoke to all of the vendors that were affected by this process and most of them were very cooperative with us so during this process we noticed that devices actually provide a really unique opportunity especially for security researchers so traditionally in order to carry out payment testing or payment research we have to engage with a customer or we have to work in a financial institution the interesting thing about these products is that anyone can enrol with an account within five minutes so you don't have to be a business for example in Europe you can be a soul trader which is very simple to do and you can just open an account so you can use these devices to actually carry out payment research you can just use them to carry out confirmation of someone else's research you can use them to understand how a payment works so for this reason we wanted to talk about this because we think that everyone in this room can benefit from understanding how they can use mobile point of sales terminals so what does this actually mean for businesses in a setting risk it means that if you take card payments you shouldn't take swipe transactions we've mentioned that there is a vulnerability associated with some of these readers that we looked at but more specifically magstripe is actually a deprecated protocol so as I mentioned a magstripe can be cloned a signature can be forged and of course there's no signing of the transaction so every time a merchant accepts a card that's swiped they're actually accepting liability for the full value of that transaction more broadly I think all of us in this room know that embedded systems have become incredibly popular over the last few years especially with consumers but also we're seeing they're being incorporated much more into business infrastructure but that means that all of us need to understand that there's not going to be a high level of security testing in products like this typically the vendors have only been around for a few years and many of these products cost less than $100 so it's just something that we all need to keep in mind so at the beginning of this project we started with just two card readers and two vendors and this quickly grew into a really ambitious project encompassing seven card readers and two geographic locations so we found that over 50% of the readers that we looked at were affected by our vulnerabilities and our findings and all of the vendors that we looked at were affected by our findings we found that you can send arbitrary commands to the Mura M010 reader the Izettle reader the SumUp reader and for this reason it allows us to socially engineer the card holder so we can get them to carry out a swiped payment or we can send a message which says payment cancelled or payment declined and force them to carry out additional payments we also found that for three of the readers, so the same readers it's also possible to modify the amount for magnetic stripe transactions so this means that we can display a much lower value on the card terminal itself and force the card holder to carry out a much higher value transaction we found that on the Mura M010 reader we could gain access to the full file system using the remote code execution vulnerability so this means that we can do almost anything we can enable command mode on the pin pad so we can start to collect pins in plain text surprisingly the security mechanisms in most of these products is quite sophisticated but overall security wasn't good it tends to be considered in isolation so it's high in the level of the physical security mechanisms but more broadly speaking the entire ecosystem is relatively weak so this brings us on to our conclusions for manufacturers we recommend that security is implemented during the development process we could see really strong evidence of this in the physical security mechanisms but we can't see it in other areas of the ecosystem you should use a bluetooth pairing mode that visually allows the confirmation that the correct device and the correct terminal has been paired and of course you should control firmware versions so encrypt and control firmware so you can prevent it from interception by sniffing and obviously modification for vendors we recommend that you do not allow the use of magstripe or you need to implement a solution which allows for the signing of the transaction or the checking of the transaction on the server side use preventative monitoring is best practice so this means looking for transaction anomalies but it also means using things like correlation because this is a really effective way of incentivising fraudulent merchants we also recommend that vendors implement really strong enrolment checks because this is the first point of entry into the ecosystem for merchants we recommend that you control physical access to the devices this is because many of the attacks that we have mentioned in some way or other involves some level of physical proximity to carry out the attack we recommend that merchants also if at all possible assess the ecosystem this isn't obviously viable for a small business like a café that just has one reader but there are larger businesses which have many more units for cardholders we recommend that you don't actually carry out swipe transactions but instead use chip and signature or chip and pin where possible and of course it's always good practice to just check your transactions on a monthly basis and report anything that you think is anomalous to your issuing bank so this concludes our presentation and I just want to thank you all for listening to our findings at this early moment in the morning we also want to thank a few of our colleagues and friends who assisted us with this project so we want to thank Artem because he carried out a huge amount of work to identify the remote code execution vulnerability and thanks to Alexi and Mark who helped us look at the physical devices to assess their physical security mechanisms so thank you very much


It's over, we're all doomed. I think I've heard this one before. This week, Bitcoin is up 7% and with the possible $1.9 trillion free money getting shot in our faces by J-PAL's strip club cash canon and inflation rates shooting up to brand new highs not seen in the last 12 years. I think it's safe to say that it's just a matter of time now for Bitcoin. All that and more coming up. Hey, what's up? Jay here and welcome to Bitcoin Daily bringing you guys the best tips, tutorials and ideas to help you guys become profitable and successful traders. The goal of this channel is to empower you guys with the knowledge and resources to help you get to that next level. So if you guys are new here, make sure to hit that subscribe button and turn on the notification bell. Also guys, make sure to like this video as it helps us with the YouTube algorithm to get this out there to more people. So without further ado, let's jump right in. So first things first, let's go ahead and do a recap from Monday's trade setups. So on Monday in Bitcoin, I told you guys that I was taking entries above $50,000. So on the break of 50k is where I was looking to enter. If you guys took this 50k trade and trailed it properly and took profits, let's say at 52k. So it ran up to a 52,760. Let's say you guys took profit at 52,000 from the 50,000 entry using 10x leverage, you would have done 40% profits on that move. And you guys definitely had opportunities here as well to reenter that trade and profit on it several times. In Ethereum, we told you guys that we were taking entries above 1600. So if you guys took the entries above 1600 on this breakout, it ran up to 1650. That would have been about a 15% profit if you entered at 1600 using 5x leverage. So those were the two entries that triggered this week from the trade setups that we gave you guys on Monday. If you missed those trade setups, do not worry because I'm going to give you guys some more trade setups for the weekend. So let's dive right in. Alrighty guys, so let's take a look at Bitcoin. As you guys can see here, we had the falling wedge breakout that we spoke about on Monday, which was a reverse signal, right? So we told you guys that this falling wedge pattern is a reversal signal. And then we also pointed out to you guys the RSI divergence, we had a bullish divergence on the RSI, which was also a reversal signal. So that led to this break to the upside here. And as you guys can see, we told you guys that the resistances that we were probably watching was going to be right here, which is at 52k area. And that's exactly what happened there, right? We got rejected at 52k and sent back down. So currently, we've been just kind of consolidating here in this area after a big impulse move. Remember, this was about a 10% move here for Bitcoin. And then we've just had some consolidation here afterwards. Currently, we're sitting at about 48,475 at the moment. We've gone as low as 46,300. So I told you guys that 4,600, this level right here, was going to be the support. And that 52 level was going to be the resistance. And that's exactly what we've seen here. So I'm expecting a battle here, guys. I'm expecting a battle. A lot of people are taking profits at 50k. Remember, we spoke about 50k, you know, for probably like the last month or so, we said that, you know, 50k was going to be a big level there, that where people were just going to be taking profits, right? However, we did see that squeeze, which kind of just took us all the way up to almost $60,000 in our new all-time high of $58,500. And then we got rejected. And once we got dumped below 50k, now is when we're doing all that consolidation that we skipped the first time around at that $50,000 region. So we're basically currently right now bouncing between that $46,000 to about $52,000 in Bitcoin. We currently have the 23.6% Fibonacci zone there, that level. So that's why it's that, plus there's the big $50,000 number. So that's why there's going to be so much consolidation in the area until we break to the upside. Zooming in here to the four-hour chart, you can see a lot clearer exactly what it is that's going on. You can see the top over here at that $42,000 range and the bottom here at that $46,000. So this is currently the range that we're watching and the range that we're pretty much consolidating in. We might see some continued consolidation here as Bitcoin prepares for its next move. Usually when there's a lot of consolidation, what it means that there might be a bigger move coming. So the longer that the price consolidates for, the bigger the next move might be. Remember, we saw the same thing here. Now, this was kind of a different situation, but this was all just consolidation. We consolidated here for about three weeks before taking off. And once we took off, we went from $33,000 all the way up to $58,000. That was a $15,000 move, guys. If we expect another move of that magnitude, we can be expecting to see basically $75,000 on the next impulse move. So right now is basically what we're watching in Bitcoin. We're going to be watching this 46K zone here. If we see any dips below 46, then you have to be a little bit more careful because that could lead down to that 45 to possibly 43, 44 range that you saw right here. And below that, we would basically probably be going down to around $42,000 to $40,000. Remember, 42 was the previous high here when we got dumped back down. We have not gone all the way back down to that point, but we got pretty close. We went as low here as 43,000 basically, right? Now on a move back up, obviously the first resistance that we're facing here is that 50K level. So that's the first thing that we're watching here. A break above this should lead us back up to this 52,000 level. And if we're able to finally break up and out of there, then we should be looking at this one right here, which is that 54 to 55 range. Then we should also probably look at right around here where we saw some price action. That's around that 56 to 57. And of course the previous all-time high, which is 58,500. Now, if we break that 58,500, we can be looking at a move above that 60K and possibly onwards to $70,000 to $75,000, possibly on the next impulse move. I would imagine there's going to be a lot of shorts get liquidated on such a move like that, which is why it will lead us up so high at that point. Other than that, we're bullish on Bitcoin still right now. We're still in this breakout from the falling wedge. We're just consolidating here after that move up from, we moved up from 43,000 all the way to 52, almost 53. So that's basically a $10,000 move within a few days during that span. So now we're seeing some consolidation here between the 46 to 52 range and a break up could lead us back to that previous all-time high and possibly higher. Another day, another purchase by MicroStrategy as well. They purchased an additional 205 Bitcoins for $10 million in cash at an average price of $48,888 per Bitcoin. So as of March 5th, they're currently holding 91,064 Bitcoins acquired for $2.196 billion at an average price of $24,119 per Bitcoin. So as you guys can see, the Wells are still buying Bitcoins. They've been buying Bitcoin. A lot of analytics have been showing that Wells have been buying Bitcoin at that $48,000 level. So as you guys can see here, Key Young Ju posted about Wells accumulating BTC that they're making a lot of bear traps lately, but the price seems to always recover to the institutional buying level of $48,000. Looking at recent Coinbase outflows, most of the outflows that went to Custody Wallets were at the $48,000 price. So again, guys, in Bitcoin, I am bullish. In Ethereum, more of the same basically here. It's just pretty much copying Bitcoin to the T at this point, right? The same falling wedge. Then we have the breakout out of the falling wedge. We have the bullish divergence on the RSI and we have consolidation currently here. Some people have asked about a possible bear flag here. As you guys can see, well, that's a terrible line. As you guys can see here, it looks like a possible bear flag. The thing with flags, guys, is that the probability for flags are in the direction of the overall trend. So on the daily, it is a good time frame to look at and to watch for patterns because it is more of a significant pattern, significant time frame. But because the overall trend is to the upside, the probability of a bear flag continuation are not high. So that's why we don't play those because it's against the trend. So if the overall trend was to the downside, then we'd be looking to take trades, trade setups based off of bear flags, right? But right now, the overall trend is to the upside. So a bear flag trade for us right now is not profitable enough to play. The probabilities just aren't there. So you can see here that during the week, we went up, ran up as high as 1650 and we're currently down to 1520. So we spoke about that 1500 level on Monday. We said that there's going to be a lot, a lot of chop at the 1500 level, which is why we're not playing that level. There's just way too much chop for that to be a profitable trade.  You can see here that we've been ranging basically from 1450, we've gone as high as 1650, but really the range has been to around that 1600 area, right? So that's probably the levels that you want to be watching there to see if you could get something at that support on the bottom of the range or something above on the top of that range. This is also why we're playing that 1600 level. And that's pretty much for Ethereum. As you guys know, Ethereum pretty much just follows Bitcoin. So everything that we looked at in Bitcoin, the same applies to Ethereum because Ethereum's just going to copy it. All right. So next, we're going to jump into some trade setups that we're going to be watching this weekend to hopefully get some entries if they trigger and make some profits for all of us. Before we do that, if you guys have enjoyed this video so far, make sure to give it a thumbs up. If you guys are new here, it is your first time watching one of our videos. I'm glad that you've joined us. Please go ahead and hit that subscribe button and turn on those post notifications. As you guys know, we post trades all the time. We post these reviews and we post tutorials as well. So let's go ahead and talk about some trade setups. All right. So the first thing that we're watching in Bitcoin, as you guys probably already know, it's the same trade setup that we took on Monday, the same trade setups that we've been watching this week. So we're going to be watching those same levels for this weekend. We want to see a break above 50K. A break above 50K, it should lead us back to test this $52,000 area again. Remember guys, we mentioned this on Monday and it did exactly like we said. So we're watching that same area and we're expecting a similar result there. If we dip down 46K is that first area that we're watching for a support buy. Remember at 46, we're usually, we're always looking for the entry on the bounce, not on the drop. If we were to drop lower than that, then we're looking at 44 to 42K area for an entry. This zone right here, this is basically exactly where this Fibonacci level is the 38.2%. Another possible breakout would be if we were to break out over 50K and break out and above 52 would be over 52K. So if we saw a breakout above it, we'd be willing to take that as well with a little bit less risk. So we're only risking 1% on that one on 50K. I don't mind risking closer to the 2 to 3%. In Ethereum, we're basically doing this again, the same thing as Monday. We're looking for breaks above that $1,600 area. That's kind of the same level that we watched on Monday that took off to 1650. We're waiting to see if we see something similar to that as well over the weekend. The 1500 level, there's just so much chop there. I really don't have any interest being involved in that. But a possible support entry would be back down around that $1,400 area, which is more or less right around here. That 1450 is a little bit more high risk, but it's something that you can also take if it kind of goes like that, like where it just kind of touched it and then bounced back up. You could possibly take higher risk trade right there. If we were to break above 1600 and continue up, then that next level would be 1700, which is aligned with the 23.6% Fibonacci level. So those are the trades that we're watching in Ethereum this weekend. And that pretty much wraps it up for this week, guys. I hope you guys had an amazing week. I know it's been very choppy in the markets, not only in crypto, but also in the stock market has been crazy this week and the last week really. But I hope you guys have survived. Remember, guys, don't focus too much on the day to day. You got to focus more on the big picture. So don't don't stress out too much about it. If you guys have enjoyed this video, if you guys have ever made any money from any of these trade setups that we've given you, make sure to give this video a thumbs up so that it can help us with the YouTube algorithm to continue to grow our channel and reach more people. If you guys are new here, make sure to hit that subscribe button and turn on the notification bell. We post videos five times a week. Mondays and Fridays, we do trade analysis and trade setups Tuesdays and Thursdays. We do tutorials, reviews and market news. And then on Wednesdays, we do live streams. That's pretty much it for us guys. I hope you guys have an amazing Friday. I hope you guys have an amazing, amazing weekend. And I will see you guys next week. As always, peace and love.


Pasirine. The pasirine is any bird of the order Pasiriformes, which includes more than half of all bird species. Sometimes known as perching birds or, less accurately, as songbirds, pasirines are distinguished from other orders of birds by the arrangement of their toes three pointing forward and one back which facilitates perching. With more than 110 families and some 6409 identified species, pasiriformes is the largest order of birds and among the most diverse orders of tristral vertebrates. The pasirines contain several groups of brood parasites such as the vigils, cuckoo finches, and the cowbirds. Most pasirines are omnivorous, while the shrikes are carnivorous. The terms pasirine and pasiriformes are derived from Pasirdomesticus, the scientific name of the eponymous species the house sparrow and ultimately from the Latin Pasir, which refers to sparrows and similar small birds.


Today, we mark World Day Against Trafficking Persons, and I commend states on the progress made so far in combating this phenomenon. However, the fight against human trafficking is far from over. Being 2021 the International Year for Elimination of Child Labour, I would like to focus on the specific vulnerability of children to trafficking. According to the Global Report on Trafficking in Persons by the United Nations Office on Drugs and Crime, 74,514 victims of trafficking were detected in over 110 countries between 2017 and 2018. In 2018 about one-third of the overall detecting victims were children. Data from IOM and UNICEF indicates that 8 out of 10 migrant children travelling the Central Mediterranean route towards Europe report exploitation and are regularly held against their will, forced to work or experience wage theft. The COVID-19 pandemic has increased the vulnerabilities of people in already precarious situations and has exposed even more children to risks of trafficking. Poverty, loss of employment and school closures place children at higher risk of trafficking for purposes of exploitation and abuse. These situations are more acute in humanitarian settings. Over the past 30 years IOM has learned that combating trafficking in persons requires comprehensive approaches and strong partnerships. I highlight here our work with the Office of Special Representative of the Secretary General on violence against children. The stories shared by over 100,000 victims assisted by IOM have taught us that we must listen carefully to victims and their struggles, their strengths in expressing their concerns and sharing their stories and their determination to help build improved responses is not only crucial but inspiring for all of us.