Greetings. Welcome to track 4. This is the 3.30pm talk. This is James Kettle. He's going to talk about browser powered desync attacks. Thank you. Good afternoon and welcome to browser powered desync attacks. Have you ever had an idea and then just dismissed it because there's no way that that would ever work? Three years ago, I thought, wouldn't it be cool if you could make browsers launch desync attacks? That would enable some really interesting possibilities. But I figured that there was no way that any web server was doing something foolish enough to make that possible. This year I discovered I was completely wrong. You can achieve all manner of interesting things and in this session I'll show you how. Like many discoveries, the journey that led to it was quite windy. It started in late 2019 when there was a spate of request smuggling false positives, even including an incorrect CVE being issued for engine X. I had a look at what the cause of this issue was and declared that there was a simple solution. All you had to do was never reuse HTTP1 connections when looking for request smuggling. And after that, well, everything was wonderful until last year when I realised that connection locked request smuggling was a thing and the only way to find that is to always reuse HTTP1 connections. So at this point we had a bit of a problem and this year I set out to tackle this and after quite a lot of work I eventually found that by slowing things down and paying really close attention to the exact sequence of events, I could reuse connections and still distinguish genuine vulnerabilities from false positives. And that was nice but sometimes when you pay extra close attention to things, you find more than you bargained for. And on one website I noticed something just wasn't quite right and I pulled on that thread and the attack that I ended up with broke my mental model for request smuggling because this attack could be launched from the user's browser, which meant it didn't require an attacker and that meant it didn't even require the vulnerable site to have a front-end server and that opens a whole new frontier of attack surface. So today I'm here to share with you a methodology and toolkit that I've built to navigate this new world, demonstrated with exploits on targets including Apache, Akamai, varnishamazon.com and multiple web VPNs. First we're going to get warmed up with HP handling anomalies. After that I'll share the client-side de-sync methodology using four in-depth case studies. Then I'll introduce pause-based de-sync and attempt a live demo because it's so cool I couldn't resist. Then I'll talk about defence key takeaways for the research and wrap up with five minutes of questions.  So as part of that whenever you see this logo on a slide that means my team's built an online replica website with that vulnerability in it. So you can practice that technique on a real system online for free. I'm also releasing the code that powered every finding in this presentation and whenever there's a named target you'll find four proof of exploit code in the white paper even if I haven't managed to squeeze it onto a slide. Now we're going to start with a series of six esoteric vulnerabilities that directly led to the discovery of client-side de-sync attacks but are also really quite interesting in their own right. But first there's something I need to tell you. The request is a lie. HTTP requests are a useful abstraction but the harder you try to hold on to this concept the less sense these techniques are going to make. At the end of the day all we're doing is sending a stream of bytes and what the server does with that is up to it. For example it's all too easy to forget about HTTP connection reuse because HTTP is supposed to be stateless but sometimes stake and creep in. Take this website that I found but sadly can't name. They had a reverse proxy in front and it was set up to let me access sites intended to be public and not to access private sites on their intranet. And it was deciding where to route the request using the host header. But this front end was only validating the host header of the first request on each TCP connection so I could just send a request to the legit site and then gain access to the internal systems. Now fortunately this bug is quite rare but there's a more common variation that I'll call first request routing. Here the front end server looks at the first request to work out which backend to route it onto but then it passes all subsequent requests on that connection straight through to the same backend system. By itself this behavior is not really a vulnerability but you can use it to hit any backend with an arbitrary host header so you can use that to form part of an exploit chain that would otherwise be impossible. In this example here I want to hit the backend with a poisoned host header so I can trigger a poisoned password reset email but doing that directly isn't possible because the front end doesn't know where to route it to. But once again I just send a legit request first and then follow it up with the attack and we successfully get a poisoned password reset email and hopefully access to someone's account. So hopefully that simple technique will come in useful for you but there's also a broader takeaway here which is that it's really good to peel away these abstractions sometimes because they can hide behavior that's really quite important. On to request smuggling. Well you know the deal with this hopefully you just make the front end and back end disagree about the length of a HTTP request. You use that to apply a malicious prefix shown in orange to the victims request and that makes bad things happen to the victim. To encourage this disagreement to happen you generally obfuscate the transfer encoding header to hide it from one of the servers. So I was a bit puzzled when I found that I could trigger really suspicious behavior on a large number of websites using AWS's application load balancer using this HTTP2 request. If you look at this request you might wonder where the attack is because this is a legitimate HTTP2 request it's spec compliant there isn't any obfuscation there or anything like that and yet somehow this was causing some kind of desync on these websites. After spending quite a while investigating it as usual I eventually decided what Amazon must be doing is inexplicably adding a header that said actually this message is chunked when they forwarded it onto the back end but not actually chunking it. And well once I knew that it was easy to turn this into an exploitable desync and hack a bunch of sites so that was nice. I reported it to Amazon and they fixed it really quite quickly too. But it left the question well why was Amazon doing that? Why did that even happen? And I think it's because web browsers always send a content length header even when they're using HTTP2 even though that is not required over HTTP2. And so Amazon just ended up with logic that said well if there isn't a content length header I guess it must be chunked. So that was a handy finding but the real value of it was in the takeaway which is that for request smuggling you don't necessarily need header obfuscation or any kind of ambiguity. All you need is a server taken by surprise. We're going to come back to that shortly. Now let's take a closer look at the connection locked HP1 request smuggling issue mentioned earlier. So to confirm regular request smuggling you send two requests you confirm the first request affects the response to the second as shown here. And this works great provided you send those two requests over separate connections but to find a connection lock vulnerability you have to send them over the same connection like this. Now here we're sending and receiving exactly the same bytes as shown on the previous slide but now we have a problem because we can no longer tell where the front end thinks the first request ends. And that means we can't tell if this system is actually vulnerable or not. The solution here is to realize that these bytes that we're getting back aren't the only information that we have. We also have timing information. If the front end server thinks our message is chunked that means it's already starting to generate a response before we send the orange payload. So if we pause before sending that payload and check the socket and we see a response coming back that tells us they're not using the content length. They think this message is chunked and they're not vulnerable to a CLT desync. Meanwhile if we try to read and we don't get any data back for a few seconds and then the rest of the attack pans out as usual that proves the front end must be using the content length and therefore are actually vulnerable. So I took that technique. I automated it and I went scanning. And I found a few things. One of the mildly notable things was there was a vulnerable system that was vulnerable because they were running Barracuda's web application firewall in front of IIS. Obviously it's old news. You put a web application firewall in front of something that makes it easier to hack. But what was particularly interesting here was Barracuda had actually issued a patch for this problem but they hadn't flagged it as like a full-on security fix. They just said it was just a speculative hardening measure. So as such the client hadn't bothered to install it and it was vulnerable. As usual though the best desync I found with this technique was the one that initially made absolutely no sense. After extensive testing I was able to refine the attack sequence into this. Now there's two things to unpack here. First off as you can see the back end server is completely ignoring the content length here. So that means this is a seal.zero desync which is a rare attack class that hasn't been widely researched. Secondly is well why are they ignoring that content length? There's no reason. They're just ignoring it because they feel like it. It never occurred to me that a server might just arbitrarily ignore the content length on a completely valid HP1 request. And that has implications. It also left me wondering given that I found this by accident with a scanning technique that wasn't even designed to find this, well how many sites am I going to find if I go deliberately looking for this type of vulnerability? The answer was quite a few. My favourite one was amazon.com. So they ignore the content length on post requests sent to the path slash b. Using this I got a server side desync so I made a simple proof of concept which stored random live users HP requests including their credentials inside my amazon wishlist. So I send this request a few times, I reload my wishlist and I've got some other random people session cookies. So I reported that to Amazon. They fixed it at some point. And then I realised that I made a terrible mistake because I could have done a much cooler attack. This request exploits a random live user, right? And the request is a legitimate HP request that can be triggered by a web browser. So if I'd used the head technique to execute JavaScript in the victim's browser, I could have made every user that got hit by this spread the attack to 10 other users. Thereby making a self-spending desynchronisation worm and compromising every active user on Amazon. So that was a cool finding, missed opportunity too. And also a hint at an entire new attack class, client side desync. Every desync, every request muggling vulnerability that we've seen to date has desynchronised the connection between the front-end server and the back-end server. But if you can make a web browser send a request that causes a desync like you could on Amazon, then you can target the browser's own connection pool. And that means you can exploit sites that don't have a front-end back-end architecture. This attack starts with the victim visiting the attacker's website, which sends two requests to the target site. The first request desynchronises the browser's connection to that website so that the second request triggers a harmful response to go back to the victim and give the attacker control of the victim's account. To build these attacks, I've adapted the methodology from classic request smuggling. The main difference is that our entire exploit here needs to run in our victim's web browser, and that is an environment that's a lot more complex and uncontrolled than a dedicated hacking tool. So it's crucial to periodically take your technique as you've got it working inside your tool and try out in the browser to make sure that it works as expected in the real environment that you want the attack to work in. Tooling-wise, I did all of this with custom code, which I've just released to GitHub, but I also helped design a new Burp Suite feature called Send Request Sequence, which offers similar functionality with a bit of a gentler learning curve. For the target browser, this technique seems to work on all browsers pretty much equally. Personally, I focused on Chrome because Chrome has the best developer tools for building this kind of exploit. The first step towards a successful attack is to identify your client-side desync vector. This is a HTTP-1 request with three key properties. First and foremost, the server needs to ignore the content length of this request. This will typically happen because you've triggered some kind of server error or because you've taken the server by surprise, it just wasn't expecting a post request to that endpoint. For example here, this is one of the more effective techniques. I'm just doing a post request to a static file. They don't expect it, and as such, if the server is vulnerable, they're likely to ignore the fact that I've said I'm going to send more content than I actually have. I've sent content length 5, I've sent one byte of data. If the server replies to this request immediately, it suggests that they're ignoring the content length I've sent, and they're quite likely to be vulnerable. Secondly, this request needs to be triggable across the main inside a web browser. That means you can't use things like header obfuscation, and you can't even specify any special headers, really. Also, the target server can't advertise support for HTTP2 because this is an attack that exploits the fact that HP1 is dire, and browsers will aggressively prefer to use HP2. The only scenario where a site that uses HP2 is going to be exploitable via this is if your target victim is using a core proxy or something that only supports HP1, which is fairly unlikely. Finally, the server needs to leave the connection open after it's handled this request. Once you've found this, the next step is just take that and see if it works inside a real browser, which you can do with some JavaScript that looks something like this. Here, we're sending two requests, and the first one is going to desync the connection, and the second request is just a browser navigation, and that should hopefully suffer the consequences of the connection being desynced. Now, there's two flags worth mentioning in this attack request. First off, I'm specifying mode no-course. This is not required for a successful attack, but what it does is it means we can actually see what's happening inside the developer tools, so it's useful for debugging things when things go wrong, which they will do quite a lot. Secondly, I'm specifying credentials include. This is really important because browsers have multiple connection pools per website, and if you poison the wrong connection pool, then I can promise you an extremely frustrating time. So I specify that, and you'll probably poison the right one. Now, when you run this, if it's successful, you should see two requests in the dev tools with the same connection ID, and you should see that the second response has been affected by the malicious prefix from the first request as shown here, and at this point, it's just time to build an exploit. This is quite a powerful primitive, so you've got three main options. First off, you can try to store the user's request somewhere where you can later retrieve it, kind of like I did on Amazon, and that works just the same as regular server-side request smuggling, so I'm not going to waste any time talking about it in more detail. Secondly, there's an all-new option, which is chaining and pivoting. So a client-side desync means that you can make your victim's browser send arbitrary bytes to the target website. So what it does is it turns their browser into your personal attack platform, and it puts extra attack surface within your reach. For example, you can make them put log for shell payloads wherever you like, and you can even hit authenticated attack surface using their credentials in a way that's a bit like cross-site request forgery, but not more powerful because it doesn't have all the limitations that browsers normally put on cross-term main requests. What I'm going to focus on, though, is exploiting the end user. I've tried a lot of different techniques and had the most success with two well-known approaches from server-side request smuggling with certain tweaks applied that we're going to have a look at in the case studies. So for our first case study, we're going to exploit a straightforward vulnerability that affected a huge number of websites built on the CDN Akamai. This attack vector is nice and simple. To cause a desync, you just need to do a post request that triggers a redirect from the front-end. Confirming this in a browser is also really easy. Here, I've just crafted the prefix so that when the browser follows this redirect from the front-end, it ends up seeing the contents of the robots.txt file. For the exploit, I'm going to use the head technique. Now, if you're not familiar with this technique, it's documented in more detail in last year's presentation on HTTP2, but the short version is, with the head technique, you use the method head to queue up multiple responses that, when combined, are harmful and let us execute JavaScript from the target site in our victim's browser. And when you're doing server-side request smuggling, it's that simple. But because this is client-side, there's a couple of other things that we need to fix first. The first problem is that the initial request coming back to the web browser is a 301 redirect. And as such, the browser is just going to follow that redirect, and that's going to use the poison connection and mess up our attack. The second problem is the stacked response problem. Whenever Chrome reads in a response from the server, it deliberately does a little overread. It tries to read more data than the server said it was going to send, just to see if there's any extra data lying around. And if it sees anything, it quietly dumps the connection and breaks the attack. So, fortunately, both issues are easily resolved on Akamai. So you can fix the stacked response problem by delaying the second response, so it arrives after Chrome does its little check. So in this scenario, I was able to do this by adding a cache buster to the request so that it incurred a cache miss, and it went all the way to the back end, which was slow and old, and therefore took ages to respond and meant that it arrived late and Chrome didn't see it. The second problem of the browser redirect is easily fixed by changing mode no cause to mode cause, which means when the browser sees the redirect, it throws an exception, which we can then catch ourselves and continue with our attack, ultimately leading to a successful exploit. For our next target, we'll hit Cisco's web VPN. This technique seems to work on lots of web VPNs for some reason. I think it's because they tend to code their own web servers for security reasons, which backfires. So here, we can trigger a desync simply by doing a post request to their home page. It couldn't be much easier, to be honest. And with that, we can easily trigger a redirect to our website. And in theory, that redirect could let us redirect a JavaScript resource load and let us take full control over the page. But there's a bit of a problem, because when a web browser renders a page, it loads all the resources at the same time, and that makes it really quite hard to successfully hijack the correct file. Fortunately, there was an easy solution on this target, because this redirect response is cacheable. So if we poison the connection with our redirect, and then we tell the browser to navigate to the target JavaScript file, which is slash win.js here, then they'll get that redirect back, and they'll just get bounced back to our website by the redirect. But they'll also save the redirect in their cache. So when they land back on our website, we can send them onwards to the web VPN's login page. And when the login page starts to get rendered, it's going to try and load that JavaScript file and end up loading our poisoned version from the cache and importing our JavaScript and giving us the user's password. So I reported this to Cisco, and they didn't say anything for a while, and then they said, they're going to deprecate this product, so they're not going to fix this issue. But they are issuing a CVE for it. So that's nice. I hope you're not using it. On verisign.com, you could trigger a desync using a URL encoded forward slash. Don't ask me how I found that. But unfortunately, that wasn't the only thing a bit unusual about their setup. For reasons that I don't have time to explain in any detail, to get a working exploit, I had to use the head technique, but I had to do it with a head request that had a body, and the body had to be chunked, which meant I had to judge the chunk size so the follow-up request would perfectly slot inside that chunk and close off the request. This unbelievably did actually work, but the interesting thing here, the reason this is worth mentioning is because this approach is exclusive to client-side desync. If you're doing a server-side desync, you don't control what the next request to hit the server is going to be, so you can't accurately predict its size, and this technique is basically completely implausible. So it's worth bearing in mind that although client-side desync can be quite painful sometimes, you do have options. Speaking of painful, for our final case study, we're going to target pulse-secure VPN. Here, you can do a desync by doing a post-request to the robots.txt file, and just like Cisco's WebVPN, they've got a host header redirect gadget that we'd like to use to hijack a JavaScript import, but this time the redirect isn't cashable. So we're in this unpleasant scenario where our attack timing is crucial, and I had to take three steps to make this remotely reliable. First off, I pre-connect the victim browser with the target site to reduce the effect of network jitter on the attack timings. This might not make any difference, but I was kind of desperate. Secondly, our attack is going to fail sometimes, so it's essential that we can have multiple attempts, but a failed attempt leaves the victim on the target website out of our control. So to deal with that, I just run the attack in a separate tab, which just means we can have as many attempts as we like, except for one other potential problem, which is that if an attack fails and the browser ends up caching the genuine JavaScript file, then we can't poison that file until that cache entry has expired, which could be weeks. But I was able to avoid that issue by finding a page on pulse-secure's VPN that had a JavaScript import that never got cached because the file they were trying to import didn't actually exist. So by combining all of these, we got a successful attack, which hopefully looks something like this. Yeah, so you can see a tab pops open, and then the victim site gets reloaded a couple of times, and we get control. I reported that to pulse-secure VPN, and to be honest, I'm not sure what's happened. They didn't say anything for ages, and then they said they fixed it, but I can't find the fix. So who knows? Now, we saw earlier that slowing down and pausing can reveal useful information, and as it turns out, pausing can also create entire new desync vulnerabilities. To trigger a pause-based desync on a vulnerable server, you start by sending your headers, processing a body, but not sending it and then just waiting. Eventually, you'll get a response, generally after a server time-out is hit, and then when you finally send the body, they'll treat that as a new request. I initially found this on Varnish, and just in case you think that was really clever of me, it was actually because of multiple bugs in my code combined to trigger this condition. But once I saw it on Varnish, I was like, oh, that's cool, that's what I'm looking for, and I found it works on Apache, too, which is pretty cool. And it tends to happen when the server generates a response itself instead of forwarding the request to the backend server or handing it off to the application layer, and this single vulnerability enables two distinct attacks. So first off, we're going to use it to cause a traditional server-side desync. The front-end server must stream the request to the backend. In particular, it must forward the request headers without attempting to buffer the entire request body first.  So in practice, you need to send your headers, wait until you think a time-out has probably happened on the backend, and then send the rest and the next request and hopefully get a successful attack. So I've updated Turbo Intruder to add a couple of different ways of saying where in the request you want to pause and how long you want to pause for. So that's it. It's fairly simple. And you might be wondering, well, what front-end servers actually stream requests like this? To be honest, I couldn't be bothered looking at very many, but it worked on the first one I tried, which was Amazon's application load balancer. However, there's one extra catch, which is that they've got a defensive measure I'll call early-response detection. It's a bit like the Chrome behavior we saw earlier, but it's slightly different. So if Amazon's ALB sees the response coming in from the backend before our request is completed, then they'll follow that response on, but then they'll dump the connection. They won't reuse it on our attack or fail. Fortunately, this seems to be designed to prevent bugs rather than actual attackers, and there's a really obvious race condition in it, so it's quite easy to bypass. All you need to do is identify the backend timeout and make the orange payload, hit the front-end in the time window between the backend generating that timeout response and the front-end noticing it. In other words, basically, this attack may take a few attempts, but it's worth it. There's one final challenge that you might encounter, which is more severe. This is when the front-end and the backend have the same request timeout configured. On ALB, that creates a race condition within a race condition and makes life incredibly painful. I thought it might be possible to avoid this issue by resetting the front-end timeout without me sending in the backend timeout by sending data that the front-end normalizes and then doesn't send on to the backend. And that might work on some servers, but it didn't work on ALB, and after a while of everything I tried failing, even when it was really cool conceptually, I just gave up and I just set a vanilla attack running. And 66 hours later, it was successful. So this is one for the patient. So that was a server-side pause-based desync. And it just leaves us with one final question, which is, well, is there such a thing as a client-side pause-based desync? Now, I couldn't find a way to make a browser pause halfway through issuing a request. But SSL and TLS don't stop attackers from delaying your traffic. So there is a potential attack where the attacker triggers a request from your browser that's really big so it gets split into multiple packets. And then all they have to do is delay the right packet and they can trigger a pause-based client-side desync and exploit you. Now that might sound quite theoretical. It certainly sounded theoretical to me. And this is Defcon. So I've made a proof of concept that uses this technique on a default Apache-based website to execute arbitrary JavaScript and kind of break TLS. And now I'm going to attempt a live demo. The code on the client-side looks fairly like a regular client-side desync, but we've got tons of padding to make the request big so it gets split into multiple packets. On the attacker's middle box, I used the traffic control facility with some code like this that just says delay the packet to the target site by 61 seconds if it's in between 700 and 1,300 bytes because that seems to work. As you may guess, this is not the world's most reliable technique because you obviously can't decrypt the packets. They're encrypted. You just look at how big they are and kind of guess. But let's have a go and see what happens. Okay, cool. So I'm going to make the victim browser is just going to socks proxy to a box on Amazon that's being man in the middle just so the local network doesn't blow things up too much. It's just a socks proxy. It's not breaking or anything like that. Here we're going to connect to the attacker machine. Apologies about the size of the font. What if I do this? Yeah, okay. So here we can see this code. I've got the injects, the delay. The only change is I'm just doing a six second delay here because I reduced the server time out so that the demo doesn't take ages. And I'm running TCP dump on the attacker's box. So if the attack works, if the browser decides to send the correct packet size for me, then we're going to see a few packets go through and then one large packet being re-sent over and over. That's because the victim machine knows it hasn't been received by the server because we're delaying it. So it's just trying to re-send it. That's just TCP. But the attacker is delaying all of these re-send attempts until it finally lets them through. We get a client-side desync, and if it's successful, we'll see the attacker's box in the victim browser. So as you can see, I've just got the attack code shown earlier here. I'm going to hit execute.js, and we'll see what happens. Okay, great.  There we go. Thanks. So that was... Oh, so we don't even need the backup video. All right. So, yeah, hope you enjoyed that demo. That was the final attack of the presentation. Hopefully, most of them made sense. Let's talk about defence. These attacks almost all exploit HP1. So if you can, I would recommend using HP2 end-to-end. That said, if you can't use it end-to-end, don't do HP2 downgrading because that makes things even worse. Now, secondly, I don't know how people are going to react to this, but my view is, it's really easy to make a HP1 server but really difficult to make a HP1 server that's secure. So I would say, don't code your own HP server if at all possible. That said, software diversity is a healthy thing, so here's some advice that will help make your server slightly less prone to these kinds of vulnerabilities if you need to patch one of these vulnerabilities and using HP2 end-to-end is not an option. Now, I've got a nice bonus slide for DefCon. I think this topic has serious potential for further research. So I'm going to outline seven possible research angles roughly in order of the time commitment required and how likely I think they are to actually work. First off, more ways of making a browser, of making a server ignore the content length would be really valuable. You can use these for both a server-side desync and a client-side one, especially if it is triggered by a request that you can use from a web browser. Secondly, as we've seen, client-side desync exploitation can be quite hard, so more ways of building exploits would be really valuable. And in particular, the whole chain and pivot exploit path was researched. It basically didn't occur to me until I was writing the presentation. So I think you might even, because you can send arbitrary bytes, you might even be able to fake a protocol upgrade and change protocol to web sockets or something which might be fun. Fourth, currently, server-side pause-based desync vulnerabilities are really hard to detect. You're best off basically looking for the server banner that says they're using Apache and then trying the technique. So a reliable way to find this issue when the vulnerable server's behind a front-end would be really nice. And also, it would be amazing if you could trigger a pause-based desync without needing a man in the middle. It feels like something that should be possible. It should be possible to make a browser just still halfway through a request. Somehow. I just don't have no idea. Sixth, this is a valuable attack class right now, but it's going to get less valuable over time as HP2 adoption increases unless someone figures out a way of forcing browsers to use HP1. Again, I've got an idea, but it might be possible. And finally, I think this one's a pretty good lead. Exploration of equivalent attacks on HP2. I've seen some hints that vulnerability similar to client-side desync could happen with HP2. I don't think it's going to be as common because it kind of requires like a state machine floor on the server, but I'm fairly sure it will happen sometimes and that would be quite nice. So there's plenty of further reading available. The three things I'd suggest are, check out the white paper which also includes these slides. That's the top link on this page. Have a shot at the online interactive labs to get some real experience with this technique and then grab the tools I've released, do some scanning and find some real vulnerable systems. Feel free to chat with me in email and let me know how it goes. Also, there's a kind of related presentation tomorrow by Martin which is really good. I would suggest checking that out if you enjoyed this. And finally, the three key things to take away are the request is a lie. HP1 connectionary use is harmful and all you need is a server taken by surprise. I'll take five minutes of questions now. If you have any more after that, feel free to come and chat to me at the back or just chuck me an email. Don't forget to follow me on Twitter. Thank you for listening. Any questions? Yep. Could the attack work on HP2 servers that have a HP1 server in front? Yes, you could do a client-side desync on that potentially. Cool, thank you.


Hello everybody, welcome back to another Adobe Premiere Pro tutorial. In this one, I'm going to show you how to change the number of steps that you can either undo or redo. So redo or undo steps in Premiere Pro. Let's get going. The first step here, I've got some footage loaded up and in a sequence. And it's just some nice cool little nice footage of a lake in a river kind of stuff. Real simple stuff. All good. The next step to change the number of steps is you want to go up to your history panel. So right now, I've got a check mark beside history. So if you're not, if you're not seeing it window, make sure the check mark beside history. When that's the case, now I know that it's open somewhere. And for me, history is down here. So I've got it open here. But if you're in the effects workspace, for example, it may be over here. So either way, find the history panel, then go to the hamburger menu. Left click on it. When you left click on it, you'll see settings. Now you can left click on settings. And this allows you to change the number of history states. It defaults to 32. But as a lot of you probably are guessing, you might want more states than especially if you do some very, very complicated edits. I set it to 100 and especially if you're a Photoshop user, you know how important it is to have the ability to go forward and backward in history states or states, so to speak. So now looking under history, here are all the things that I've done to this. And if I wanted to go back to say something like the lift and overwrite, the left click on that and then it will go backwards in time and it will then gray out all the other effects that came after it. So that's how you do it. Commander controls that, of course, as well to move forward or move backwards one state at a time. But that's how you change the states, guys. Thanks for watching. Ton more stuff coming up. Stay tuned.


Hey everybody, Dr. O here. Welcome to part three in the real talk about loose skin series. I'm super happy that you're here. I've actually been really excited about the feedback that I've received from this series so far, but I'm most excited about the number of people who have seen results by using the strategies that I'm outlining in this series. I've heard from no fewer than 20 people who have lost large amounts of weight with zero loose skin. It is super exciting to hear. It is possible. Back in part one we looked at the causes of loose skin and the risk factors that will make it worse. We also covered the major lifestyle factors that will make dealing with loose skin hard if not impossible. Then in part two we covered fasting and other ways to improve skin health by boosting autophagy. So here in part three though we're going to cover the importance of feeding your skin the nutrients that it needs to tighten up and heal. So in this video we will cover my four favorite skin nutrients. As you can see them here collagen peptides, vitamin C, hyaluronin or hyaluronic acid which is what I'll call it, and the omega-3 fatty acids EPA and DHA. I'll do another video in the future about other nutrients that can improve skin health just later on in the series. These are the ones though that I personally had success with and where I see the most support in the research. Reach out if you have questions about other nutrients. I will definitely add them to the list and add them to the series. But first why do we need to nourish our loose skin and why do these specific nutrients matter? The best way to improve your skin health is from the inside out. Each of these nutrients tackle one or more of the key issues that lead to loose skin in the first place. I covered the issues in detail in part one but let's take a quick look at a bit of the research here as well. So what does the science have to say? Skin changes due to massive weight loss, histological means tissue level, histological changes and the cause of the limited results of contouring surgeries. So they compared skin fragments of 20 patients who had massive weight loss because or due to bariatric surgery and then 20 patients living with morbid obesity. Here's a quote, structural dermis alterations in the massive weight loss group demonstrated collagenous remodeling with consequent reduction of thick organized structured and directed fibers in favor of thin misaligned and loosely arranged fibers. So we know that massive weight loss leaves damaged collagen behind. This is why it is crucial that we improve the health of our collagen every way that we can. Next one, image analyzer study of the skin and patients with morbid obesity and massive weight loss. This time they biopsied 30 patients and here's a quote, collagen was significantly less dense in the reticular dermis with damage to the elastic fiber network. That's the key here. So now we also know that we need to address skin elasticity if we want to prevent minimize or eliminate loose skin. Last one, skin protein profile after major weight loss and its role in body contouring surgery. This study showed that there's a persistent increase in inflammatory markers in skin after rapid weight loss. So anything that can help control inflammation at the level of the skin will also be a part of the solution. So now we have our targets. So let's go ahead and dive in. So skin nutrient number one is collagen peptides. You need a steady supply of collagen to improve skin elasticity and overall skin health. All the collagen that's actually made in your body begins as something called pro collagen. You're going to hear that word a few times today to make pro collagen, your body uses two amino acids, glycine and proline. So a protein rich diet that's high in these amino acids will definitely help boost collagen production. But I'm going to show you soon why I think consuming hydrolyzed collagen peptides is actually ideal. So what are hydrolyzed collagen peptides? And I'll just usually call them collagen peptides. They're very similar to gelatin. It's a processed form of the collagen that's found in the connective tissue of animals. When gelatin is processed into smaller little peptide chains, it's called collagen peptides. So let's look at the study first. What does the science say? Oral collagen supplementation, a systematic review of dermatological applications. So this review looked at 11 studies with a total of 805 patients. It concluded, like I do, that oral collagen supplements increased skin elasticity, hydration and dermal collagen density, all things we need if we want to improve or eliminate loose skin. Right? So we're fighting against loose skin. We've already talked about the things we have to deal with. And collagen checks quite a few of those boxes. But two of the studies in this review really caught my eye because they found that a relatively large percent of the collagen peptides are actually absorbed intact rather than being broken down in the digestive tract first. So the first one was Yazaki. Yazaki found that taking collagen peptides led to a 13.6% increase in collagen tripeptides in the blood. And then Ohara et al. found that 30% of the amino acid hydroxyproline from collagen peptides was absorbed as part of a peptide rather than in its free form. So what does this mean? This means that collagen isn't completely broken down in your gut before it's absorbed. People often say there's no need to take collagen supplements because your body will just digest them and break them down into individual amino acids and absorb them just like every other protein. But that doesn't appear to be true. Some of these collagen peptides are making it into our body intact. So this is why I recommend taking collagen peptides rather than just eating a high protein diet and hoping your body will maximize collagen production. So don't get me wrong, right?  And you know from my sleep videos that I love the amino acid glycine and I love bone broth. But there appears to be something special about the collagen peptide specifically when it comes to skin health. Another study. A collagen supplement improves skin hydration, elasticity, roughness and density, results of a randomized placebo controlled blind study. So there were 72 healthy women aged 35 years or older in this study. They received either two and a half grams of collagen peptides or a placebo for 12 weeks. And here's what happened. You can see here in this image that the test product that they used with the two and a half grams of collagen peptides significantly improved skin hydration, skin elasticity, skin roughness and skin density. As you can see from the chart here, the improvements were sizable as well. Basically, the improvements ranged from 18 to 25% after 12 weeks of only taking two and a half grams of collagen peptides per day. I'll take that for sure. Another one, effects of hydrolyzed collagen supplementation on skin aging, a systematic review and meta analysis. So this review looked at 19 studies with a total of 1125 participants aged between 20 and 70 years. They did a grouped analysis of these studies that showed favorable results of hydrolyzed collagen supplementation compared with placebo in terms of skin hydration, elasticity and wrinkles, right? That we keep coming back to these same things and collagen peptides appear to improve them. Another one, dietary supplementation with specific collagen peptides has a body mass index dependent benefit beneficial effect on cellulite morphology. So this one's talking about cellulite, but I thought you've interested in that as well. 105 women aged 24 to 50 with moderate cellulite. They received two and a half grams of collagen peptides or a placebo per day for six months. The collagen peptide treatment led to a statistically significant decrease in the degree of cellulite and a reduced skin waviness on the thighs in normal weight women who had reached their goal weight. That's why they talk about body mass index dependent. It worked better as people approach their goal weight. It didn't work as well with people that still had a lot of weight to lose. All right. So I typically recommend aiming for 10 to 12 grams of collagen peptides per day, even though some of these studies were only using two and a half grams per day. I'd rather take a little too much than take a little too little, but you can decide for yourself. Here is my current favorite collagen peptide product. It's Anthony's collagen peptide powder. I just buy it on Amazon. It has 12 grams of collagen peptides per serving. I like the source. I'm amazed at how easy it mixes in water, right? I just stir it with a spoon and it's ready to drink. That's what that's one thing I really love about it. But I've also used Great Lakes collagen peptides in the past. It also has 12 grams of collagen peptides per serving. So maybe you'd like to try that one too. A couple more things before move before we move on though. Number one, I'm a big fan of collagen peptides for the skin. And I think the research is supportive of it. But the research on collagen for muscle and joint health isn't usually near as positive. But take it for skin health. And if you get lucky, you'll be pleasantly surprised by some joint health improvements as well. I personally feel that it has helped my knees. But my knees are so much better than they used to be. But I've made so many changes to my diet and lifestyle that it's often hard to tell what's making me feel better. So take that for what it's worth. And then number two, there's a question about this. You can take collagen with or without food, but I typically recommend taking it with food. And here's why. Collagen is not a complete protein source. That means it doesn't have all of the essential amino acids that we need to build a human body. It doesn't have the amino acid tryptophan. So add it to a meal that has other protein sources, if you want to get the most out of it. But there's nothing wrong with taking it without food, if that's what works better for you. I know some people like to put it in their morning coffee and things like that. But if you do that, I wouldn't count the collagen protein towards your total protein target for the day, since it won't stimulate muscle protein synthesis on its own. So just something to keep in your back pocket. All right, moving on. Skin nutrient number two is vitamin C. Vitamin C stimulates collagen and elastin synthesis in the skin. It also helps protect the skin from the damage caused by the sun's UV rays. We take a drink here quick. This is really cool. So what's the science say here? Effects of different vitamin C enriched collagen derivatives on collagen synthesis. This is a very interesting story in my opinion. This is one of several studies by Dr. Keith Barr that showed that collagen had no effect unless some vitamin C is present. They compared vitamin C enriched gelatin to vitamin C enriched collagen peptides to a gummy containing equal parts of both, some gelatin and some collagen peptides. But here's the key before we move on. All the treatments had collagen in them. But the process of making the gummies involved boiling the solution. Vitamin C is heat sensitive. The boiling destroyed the vitamin C in the gummies. And this is what led to the odd results. So back to the study. All three of the supplements increased amino acids in the circulation. So the amino acids that make collagen increased in the blood whether vitamin C was present or not. But here's the key. N-terminal peptide of pro collagen levels increased around 20% from baseline in both the gelatin and the collagen peptide groups but not the gummy. So why does that matter? N-terminal peptide of pro collagen is a mouthful but it's also a marker of collagen synthesis. So you need collagen peptides and vitamin C if you want to produce collagen. This was a super cool finding in my opinion. Here's a quote. These results suggest that vitamin C enriched gelatin and hydrolyzed collagen supplementation may improve collagen synthesis when taken one hour prior to exercise. So this wasn't specific to skin. So what about skin health in general? What's the science say here? The roles of vitamin C and skin health. So these were healthy males and females. Between 40 and 65 all of them had visible signs of skin aging. So they took 50 milligrams of vitamin C for 90 days and that led to improved skin elasticity and skin moisture. It also improved the the skin surface appearance and evenness. So vitamin C appears to improve skin health on its own but its real power is making your collagen peptides more effective at building new collagen. That's what the science has to say. Here's my favorite brand of the essential C complex from Paleo Valley. It has 450 milligrams of natural vitamin C from from a superfood blend from whole food sources. But you don't need this much vitamin C to make an impact. It appears that 50 milligrams near the time you consume your collagen seems to be enough. Alright skin nutrient 3 is a really cool one too. Hyaluronic acid. This is the one that you may have never heard of. Hyaluronic acid is a major component of the extracellular matrix of your skin. About 50% of your body's hyaluronic acid is actually found right in the skin. Its primary job is to attract and retain moisture like a sponge. Just one molecule of hyaluronic acid can hold up to a thousand times or even more of its own weight in water. So pretty cool. Really important for skin hydration. Hyaluronic acid though also plays a role in the health and function of the dermis of your skin. If you go back to part one the epidermis is the part of the skin you can see. The dermis is the part below that where all the collagen and elastin and all the important stuff is. Fibroblasts are the cells in the dermis of your skin that make collagen. They make elastic fibers and they also make hyaluronic acid. But what's cool is supplementing with hyaluronic acid leads to an increased number of these fibroblasts in your skin and that also promotes an increased production in these fibroblasts. So they make more collagen. They make more elastic fibers, elastin, and they make more hyaluronic acid. So this is really good news. But what's the bad news? Well that's going to be right here. As we age our bodies produce less and less of it. This chart shows the skin concentration of hyaluronic acid in females of different ages. So as you can see here it's called hyaluron and that's the other name for it. Between nineteen and forty seven years of age the skin concentration is 0.330 percent. At 60 years of age it's plummeted down to 0.015 percent and by 70 years of age we're down to 0.007 percent. So this loss of hyaluronic acid in the skin contributes to the loss of elasticity that we see in our skin as we age. But thankfully we can fight back with supplementation. So what's the science have to say? Oral intake of a new full spectrum hyaluronin improves skin profilometry and aging. A randomized double-blind placebo controlled clinical trial. There were 60 subjects. They received 200 milligrams per day of hyaluronic acid or a placebo for 28 days. After those 28 days there was a 5.1 percent increase in skin elasticity, a 10.6 percent increase in skin hydration, an 18.8 percent decrease in wrinkle depth, and a 17.6 percent decrease in wrinkle volume. All cool stuff. Another one. Ingestion of an oral hyaluronin solution improves skin hydration, wrinkle reduction, elasticity, and skin roughness results of a clinical study. This one had 20 females between the ages of 45 and 60. They supplemented with hyaluronic acid once daily for 40 days. And here's what we see. This is looking at change in skin elasticity. I don't speak German, but Vorherr means previously. This is the baseline data. And then Togger Tegg in German, I don't know how to say it, sorry, is days. So after 20 days they saw an 8.58 percent increase in skin elasticity. And after 40 days there was a 13.25 percent increase in skin elasticity. So pretty awesome numbers. The maximum gain of elasticity in any of the subjects was 26.16 percent in only 40 days. So pretty exciting. They also looked at skin hydration. So skin hydration increased by 21.63 percent after 20 days by 24.43 percent after 40 days. And the maximum increase in skin hydration in any of the subjects during the study was 37.18 percent in 40 days. They also did show a 16.9 percent reduction in skin roughness and a 26.36 percent decrease in wrinkled depth. So if you're looking for those things as well. All right, so what's here's a quote from it. Intake of the hyaluronic acid solution led to a significant increase in skin elasticity, skin hydration, and to a significant decrease in skin roughness and wrinkle depths. So here's my favorite, the hyaluronic acid powder from bulk supplements dot com. I try to get a lot of things from them. They're just no must no fuss. I love the price and the value. 200 milligrams per day seems like a good dose based on these studies that we just saw as well. All right, the last one, skin nutrient number four is the omega three fatty acids. The omega three fatty acids found in fatty fish may help increase skin elasticity and have anti aging effects. Omega three fats are anti inflammatory. Remember earlier we talked about how inflammation damages your skin. So here's just the one study we'll look at here. So what's the science have to say here? Supplementation with Eskimo skincare improves skin elasticity in women, a pilot study. So Eskimo skin care is just an official supplement full of the omega three fats EPA and DHA. Excuse me. Sorry. So there were 24 healthy subjects between the ages of 40 and 60. They were all they were all women. Skin elasticity was measured by using a cutometer like like with most of the studies. But after three months, they saw a 10% increase in skin elasticity in the group that was treated with the EPA and DHA the fish oil supplement. So pretty cool. All right, here's the product that I use. I just buy it on Amazon. So it's super omega three plus from life extension. I just trust the company and the product. I take it for lots of reasons. Skin health is just a nice bonus. So remember after I've gone to these four supplements, right, that this is not medical advice. Talk to your doctor or your pharmacist to decide whether or not these supplements are a good idea based on your medical history. This is actually especially true with the omega three fats. I'm a big fan of them, but they can impact blood clotting as well as atrial fibrillation risk. So always better safe than sorry. Okay, so there you have it. These are my four favorite nutrients to improve loose skin. Each of them seem to work on their own, but I personally feel like they work together better, right? They have a synergistic effect where they because if you're getting increased collagen production from a several of them increase elasticity from several of them decreased inflammation. And we know that especially the vitamin C and collagen work well together. So I think this combo will work the best is better than the sum of its parts basically. All right. So that's part three. Part four of this series will will be about other therapies you can try to improve loose skin as well. My main focus is going to be on red light therapy and low level laser therapy, but I'll address other topics too. I'm super excited about this one because I used to use a lot of low level laser therapy in my practice many, many years ago. So reach out if you have any questions or topics that you want me to cover, right? I can I will add them to the series as I go on. A good example is that several people like I lost track of counting have reached out and asked me to look into the science behind derma rolling. So you asked and I will deliver. I'll see you then. Have a wonderful day. Be blessed.


Okay. Our next talk, Andre is going to update us on SRS LTE. Thanks. So we should be running behind and that would mean that we are in 2020 in February, it's the second, it's two past two. And it's the only slot. Cool. So for those of you who don't know us, we're building open source end-to-end 3GPP protocol stacks. So with our software, you can build like fully and software run a entire LTE network. So you can have a UE, you have an E-Node B, which is the base station and a core network. You can run that entirely in software views herbs or RF front ends. You can use the E-Node B connect commercial handsets or your phone to the E-Node B or you can use the UE and connect to a commercial cell if you want so. And we do all sorts of crazy things with that. So we put the UE's in cars and in planes and like the satellites and stuff like this. Most of us know us obviously through the open source project and like we have a big or long history of researchers that use it for like security analysis. And that would be like a list of the GSMA, which is like a central entity that collects security vulnerabilities discovered in 3GP stacks. And out of this list, all of those have used SRS LTE. So it's pretty, so eight out of 11 of the recent CVDs have used that. And we have a list online on SRS-LTE.com and it lists currently over 165 research papers using our software for, but obviously there's other use cases, not just research or not just security research. So what I'll be talking about a little bit is the highlights of SRS-LTE from 2019. We're looking a little bit at 2020. Then I'll a little talk about a little bit about the platforms that we're talking because this has, we've extended this a little bit and briefly this touching, well, continuous integration, continuous delivery, test and quality assurance in general. So in 2019, we had three releases. So we've been following like a three month release cycle. And in early 2019, we added DTD support, so time division duplexing, something that is not used here, but in China. Carrier aggregation to the UE, we added a 3GPP channel simulator so you could basically emulate a channel when it is received from the UE or transmitted at the eNOTB. We added paging and user plane encryption to the eNOTB and the EPC. In 2006, we basically used those two releases, 1906 and 1909 to refactor a big portion of our protocol stack. So there hasn't been a lot of features added into this release and also the next one. So we focused on preparing it and making it scalable for all the developments that we were planning to do. So we did it in summer and in 1909, we started to open source the first 5G and R blocks, which were, yeah, I'm going to talk about this a little bit in detail, but there were kind of extensions to protocol layers, to data plane protocol layers that we had. We started to put MBIOT, which has previously been a closed source implementation. We started to put that open source through the community. We added circuit switch fallback so that you can actually use, have a network of 2G and 4G and have someone falling back to 2G for having calls.  So we get more additions from Howard there. Yeah, we also added conformance testing, like we started to add the conformance testing architecture there and in 1912, so just in December, we added for the protocol layers for 5G, we added support for RSE message packing, unpacking and also for interacting with 5G core, we started to add NGAP packing, as well as some cycling support, I will be talking about this later on. So for 2020, we are actually planning to change our release cycle a little bit. So those past two years, in which we've done a three month cycle, they've been quite stressful, not only because it takes a lot of time to prepare releases and fix. Everyone wants to get pull requests merged in and then you need to make sure that you do the quality assurance okay and that everything does not break and you don't introduce regressions. But especially the 06 and 012 release, they were quite hard because it was close to Christmas, everyone was on vacation. And then that's why we decided to go for that six month cycle from now on basically so that there won't be a 20 or three. So we will adopting kind of the Ubuntu cycle and releasing in 04 and in 010 because that better fits our development cycle. So basically after the start of the year, you have enough time to pair things and at least that's what is our intention. We'll see. And then for the autumn release after the summer, everyone comes back and you develop and test and then you have a good autumn release. So that's what we were looking at for 2020 at least. Let's see if we change that in 21, I don't know. Okay, so what are the upcoming features for 2020? So we will add more 5G and R stuff for sure and something that we are looking at is NSA, so non-send alone mode, which basically means that and all deployments that you're currently out there, they are non-send alone, which basically means that you always have a 4G, which kind of so as an anchor carrier and all the control, all the signaling is going over 4G always. And the NR is just to offload and to provide higher throughput essentially and and it only supports the data plane. So B can ask to enable a 5G bearer and then you have additional capacity and additional channel that goes over NR, but you always need 4G, so there's no way. As opposed to send alone where you really have on the right side like a 5G core, so a core network that exists and speaks the 5G language and can really run independently, well, send alone, as the name says. And as for most of our developments, we are focusing on the UE first, so this will be added in the beginning and then later on the eNOTB. What we have done so far is the user plane protocol layers, like all the extensions to MAC, RC, PDCP, they're pretty much done. The full control plane is there for non-send alone, so announcing that my phone is able to speak 5G and stuff like this that you need to do and that's all there. So what we're looking at now is to do the control plane. I mean not really control plane, but the part of the NR that is still needed for, let's say, on this side, so there's a little bit of control and signaling needed. Adding this and then we're extending the PHY, so we will be writing a x86 implementation of the NR PHY as well as an RFSOC, so an FPGA-based implementation that leverages some hardware effect on Siling's fabric and we will target in those. And the upper protocol layers, they're just run on the arms in this platform or on x86, so this is no problem. CV2x, so basically we've heard about car-to-car communication using 11p, so there's kind of two competing standards for car-to-car communication. One is based on Wi-Fi and the other one is the cellular way and that's why they put C there, so it's the cellular V2x. And so basically what it means if you're talking in cellular context is that usually like a phone is connected to a base station and there's uplink, downlink going through back and forth between a UI and a base station. And if there's, if you have two UI's that want to communicate, you always need to go through the base station, so essentially having a round-trip time or a round-trip between two UI's, it's like up to the base station, down to the UI, up to the base station and down to the UI again. And the idea is, I mean if they're close enough to each other, we could just have a site link, so SL, so let those two devices communicate directly with each other. That's essentially what site link brings, using LTE signals, more or less like modified versions of that, but more or less LTE-FI and 5G-FI in the future. And we have started to implement that and we are targeting like all four modes. We have a full file-layer implementation of Sidelink and we have joined a Etsy-sponsored interoperability testing in December in Malaga where we essentially tested interoperability with all like implementation from all vendors, like from test equipment manufacturers as well as all baseband chips and baseband, yeah, baseband chips that are then put into units, onboard units from various vendors and that's something that we will open-source as well in the next release. MBIT, I've been briefly mentioning that, so we've been developing this in private, but then later last year decided to open-source that and we will be adding a full file-layer for the UI and the EnotB into mainline SRS LTE and that's something that you can get then, in most countries, if you turn on GeoForce 4, you spot in the 800 megahertz band more or less like in some networks, you spot something like this, which is an MBIT carrier in-band in the LTE signal, sometimes also out of band here to not raise those resources and that's something that you can then sync on and decode. The reason for not putting the up-layers is only resources, so we do have them but we need to refactor them and then put them there, but the file will be there and that's something that you can then have like a critical user interface with constellation, sync and some message decoding of the broadcasting messages. Then CRMQ, that's something that we've been briefly talking about in the last FOSSTEM where we, basically the idea is to run LTE networks without needing, without requiring RF hardware, so basically to lower the entrance level a little bit, so you can run an LTE network but you always need at least two relatively expensive devices and a few computers and with this you can, you could do that basically without hardware and for us as developers that's pretty attractive, I mean we do have hardware but we want to use it for running wall grind and then address sanitizer and GDB-ing stuff that you cannot do if you're running over the air with a user, so you want to run stuff faster, slower, pause and stuff like this and maybe emulate more complex scenarios with multiple ENOBs that are very difficult to control and to orchestrate and so the idea was to basically use CRMQ and instead of sending those acute samples, I mean we're still running the full file to usurp, we are using CRMQ to send it over IPC or IP to a receiver and then we, yeah, we basically add a timestamp synchronization for that because LTE is like very much depends on time stamps and time synchronization, so we added support for that and then we've also removed all the dependencies from system timers in the UE and the ENOB this year so there's no, all the timings arrive from the samples that come from CRMQ in that case or from the user if you run it normally, that allows you to run a full end-to-end system like in the CMake like testing thing without requiring containers and other dependencies so it's very basic but it allows you to run those things with a make test basically and that's just a screenshot of how this looks like so it's three consoles, here you have the core network as there is EPC then the ENOB and then here you have a UE that attached to, you know it's a great channel, look at this, look at this constellation and yeah and you see like it just behaves as if you're running over the air, very good and it's all running on one machine and you can debug it, you can GDP it, you can single step through it, it's all good at least on the RAN side, okay. ASS and ENOB outlook so actually ASS ENOB is always a little bit like the step child of ours so we are like focusing on the UE so much but it's not, I mean we really don't mean that but the good news is that we will be focusing on ASS ENOB a lot more in the upcoming months so we not only add new features like handover for instance so this is needed if you have two cells and your UE moves so it's leaving basically the cell range of one base stage to the other one you need to do a handover so that will be added, there will also be support for carrier aggregation so a single UE cannot only have a primary carrier but you can add multiple carriers to it so and that's needed for increasing bandwidth obviously so yeah you can combine up to well five in release 10 and up to 32 in theory in I don't know release 30 I think so we see how much GSP we have to do that and we will focusing on performance and stability a lot so we're going to deploy this and this needs to be like rock solid target platforms so up until now we have really just I mean the priority has always been on x86 so the PHY is so computationally intense that it's not really viable to run a full ATE on anything else like the PHY on anything else on x86 just because all of the you know all of the like SIMD that is required and even ARM I mean it does have SIMD but it's even if you have a powerful like the snapdragon or Raspberry Pi 4 it's still hard I mean you can run like smaller bandwidth like six pure b is probably okay but a 20 megahertz or 20 megahertz LTE signal and there's no way you can run the entire PHY in ARM but it's getting better and yeah the idea is to basically widen that a little bit because of obviously it's getting better and up until now having focused on x86 only we will expand that so we do support ARM already but we will extend this to sync ultra scale so in fact we have a full PHY for downlink on an FPGA that basically offloads all the heavy stuff to an FPGA to sync ultra scale plus and only once the protocol layers L2, L3 so the up and non so not so these P critical things in ARM and that's something that we do with the same code base so we are this is not something different or different for us so so we are intending to maintain this and use the same code base that runs on all those platforms and we will see I mean maybe the ARM I haven't looked at the NVIDIA once perhaps a little bit more performant but maybe you can even run a bigger cell there with all these P in the ARM that would be would be cool so besides the wide range of RF hardware we're also tying a wide range of these P platforms here quality assurance so this is yeah like if you want to target like commercial crate I mean depending on what that means deployments and then things I mean you have to really look after of the quality and then after you know recreations that you do in your development and that you introduce and then that basically what you what you're you know putting there to a customer setting to a customer or putting on get up that actually satisfies your your needs and one of the building steps is obviously a continuous integration platform that we have and then we currently have around 600 not not exactly 600 it's a little bit less depending on what configuration you have a unit test that we are constantly running in Jenkins that is building for for x86 in ARM running atrocentrizer while grind limited in ARM and then basically executing those tests on a pull request basis and periodically in Jenkins as well so we also try to leverage from static code analysis tools that is available for open source projects like severity a tool from from synopsis as well as LGTM and that's something that we basically did in the in the last release so by looking at the initial analysis you kind of had a code quality batch of E which is like the like the worst you can get I mean it wasn't that bad actually and then and then we you know addressed a few of them some of them were yeah anyway so you you get now a and and and I hope we will get an A plus so that's that would be the best that's the second best but it also depends obviously on the ratio between code lines of code and errors that you have yes and then obviously unit test not enough so we are RF people so we have also an RF continuous integration that we call RFCI internally that we heavily use for yeah finding a regression box and and things like that that target or that are related to to RF things like like yeah these p and after related issues and we have been developing an in-house testbed where we used Jenkins that SSH into machines launch docker python scripts that you know post-process results and analyze logs and stuff like this create reports and that's also that we exit is also something that we execute on each pull request and periodically like long running handover test 24 hours 48 hours that we run you know weekly on a weekly basis something that yeah we'd like to announce here as well as that we've recently you know agreed with this become that we are more closely working together and basically adopting because this in-house testbed I mean it was a good thing for us and it worked for us but there's a tool called or yeah like a software called Osmo GZM tester which has a lot more features that that that we had and and it just made a lot of sense to kind of get SSLTE support into Osmo GZM tester so everyone else can use that it's already like open source is an Osmo Comp project so we will adding Osmo GZM SSLTE support to Osmo GZM tester and then basically we'll rebuild that entire framework with running tests and producing logs and reports and probably also trying to make those you know available for the outside world and also extend the RF infrastructure and that's a photograph that Harrod actually took so that's an installation in Osmo Comp where there's where Osmo Comp has built like a rack and a 19 inch 1U essentially housing that houses like various RF front ends and all connected cable together with variable antennae are all controlled remotely so this allows you to you know reproduce experiments to run those continuously and that's something that we are looking forward to and and extending also Osmo GZM tester for that. Another thing was conformance testing so I will briefly touch this so all the UEs that we have all the phones that we have they're they're running conformance tests so they need to obey like tests that 3GPP actually does and you usually do that you go to a testing entity you get a wrote on Schwartz one million you know a euro thing that you can test you with nobody can afford that and so what we did is to use Eclipse Titan it's a Eclipse project it's a TTCM3 compiler that is actually the language that the conformance tests are implemented in and basically wrote a system simulator that basically acts like this guy without phi fake phi and that's something that we can run on the Raspberry Pi it's all integrated in our conformance in our continuous integration and this is something that that like really helps to to make sure that you actually does what it is supposed to do and it complies with all the you know all the conformance requirements on the protocol side of things and we are running fully unmodified protocol stack there to test against the test and that's it thank you no I mean there's like we have a question yeah sorry so is the ROS here MQ transport LTE specific or not there is like timestamp synchronization and resampling and the resampling thing thing is something that you just you know put a base rate because how do you reconnect so base station depends on the bandwidth so it's first surges in the lower bandwidth and changes the bandwidth so you need to do a little bit of resampling there but I mean other than that no it's it's it's not LTE specific at all no thanks for that question yes the question was if we have been looking at the Pluto to implement LTE yes so two things the Pluto like at ease like really requires strict timing and so we need to know when we receive samples what the timestamp is and when we transmit them because the transmit is always you know aligned to the to the receive side and what we need to add there is timestamp support because the Pluto lipo doesn't have timestamp support very good are we looking forward to that so then the extension of of that would be yes you could perhaps run the mbaot on the Pluto itself definitely on the host but you still have your to a usb2 bandwidth limitation so you can definitely run the mbaot and probably is like a small LTE cell six pubes 15 pubes but definitely not the bigger ones because they're like 20 megahertz so you and then you're not getting that over the usb2 if you're going to Jenkins there are better alternatives okay thank you yeah I mean we just used Jenkins for continuous integration really so it's not you're already oh yeah yeah it's deploy yeah yeah yeah yeah yeah yeah of the serum q no I mean we don't so the question is if we if we have sms support so no no we don't do that I mean it's it's possible to send sms over nas signaling from the from the EPC and I know of like a few like users on the list who have looked into this but there is not it's not officially supported in our in the open sources okay yeah yeah it's it's yeah I mean yeah yeah yeah yeah yeah so I mean there's a few hemorrhaging users I know of and then they yeah obviously I mean it's the limitation is the rf that you're using and we are agnostic we are rf agnostic so we can yeah I mean like so there's a like we have a lookup table for all the 3 gbp like official channels and maybe you cannot directly use your channel of interest because it's not an official one but you can obviously add this if you want yeah I mean I don't see a problem here yeah


So I have done a ton of videos on why Hogwarts Legacy looks like it could be a game of the year contender. I do think it's only right that I do a video discussing and talking about the few negatives that also come with this game, a few negatives you may not know about this game and that's why today guys I bring you 5 reasons not to buy Hogwarts Legacy. How's it going guys, my name is DPJ and if you do enjoy the video leaving a like really helps out and if you like what you see and want to see more be sure to subscribe. So as good as Hogwarts Legacy does indeed look and it does look pretty good, there are a few drawbacks, a few disappointments and in particular a shadow over the game. Today we discuss all. Okay so getting into it, firstly guys Hogwarts Legacy is a single player game only. If you are coming here expecting to play with your friends unfortunately that is not happening. This game is strictly a PvE game without the intention of ever adding any kind of multiplayer which in my opinion is a bit disappointing as team not for even like a co-op play through would I believe be enough to pull in many many more players and be pretty cool to actually do an experience with a friend. Imagine being able to battle other wizards via a system and like like what we see in Alden Ring. I mean yeah I'm overdoing it there, Alden Ring is just incredible probably the best game I've ever played if not up there with my top 5 but I am seeing and believing that there are people out there that think this will be the next Alden Ring. Now although there's a little comparison if you just run around as a mage within Alden in my opinion the games are just too far different it's daft to compare. But either way guys this is a single player game only with no mention of multiplayer ever coming to the game I mean let's hope one day that may change but I doubt it. Next up guys and this one is for the deeper Harry Potter fans and as being a Harry Potter fan myself the movies and books made a big deal out of a feature known as Quidditch it's a massive part of Hogwarts it's a big deal house versus house this in my opinion was the ultimate competition between them so Hogwarts is quidditch is basically humble on booms a dangerous sport but one that's real entertaining and in a game like Hogwarts Legacy I feel would be the correct time to get a feature like this done properly. The older quidditch games although not terrible the worlds moved on and I feel it could indeed be an amazing part of this game. Well guys unfortunately quidditch is not a part of Hogwarts Legacy confirmed by Porky quidditch will not play a part in this game which is one of the most disappointing things about this game I mean an open world massively explorable Harry Potter RPG a core element of the franchise is missing I mean it isn't the be all and end all but it's a feature many fans would love to have seen and it will be a massive loss. Now I guess without the multiplayer addition to the game Porky probably thought that such a feature would be a waste of resources I don't know now brooms are here though and there is broom racing yeah I know it isn't exactly quidditch and well within a massive open world like Hogwarts Legacy well what it seems to be I'd at least expect some form of aerial challenge on brooms so broom racing it is but it has got big boots to fill another edition fans were excited to see were scubstones and wizards chess now guys I can confirm these also won't be a part of this game now these have been confirmed I believe to be a part of content originally going to be added but due to time restrictions and restraint on that time and getting this game done and pushed out they are now a part of cut content now during the gameplay showcase avalanche software admitted that the developers had to make some difficult choices about what to include in Hogwarts Legacy and that these would not fit into the launch of the game the good news is we could possibly see them return in a future DLC but we will see guys okay so moving on now it's confirmed that micro transactions will not play a part in Hogwarts Legacy which is a great thing I guess but there is console exclusivity now this is something we well actually I wouldn't say we're seeing more of it these days but it is one of those situations I don't think game developers are comfortable with due to the backlash it can usually cause and with Hogwarts Legacy well console exclusivity is a thing and well in a certain way players on one platform will directly benefit in game over players on another platform due to these exclusivities so if you play this game on ps4 or ps5 you'll get to play the haunted hugs mead shop quest this is an eerie mystery adventure involving hugs mead shopkeeper madame mason and it's available only on ps4 and ps5 which is a shame now the players who complete the haunted hug mead's quest and the associated dungeon will also get exclusive access to their very own shop in hugs mead where they can sell items and gear at better rates than anywhere else in the game what is this so yes guys I mean it doesn't really surprise me like this is a thing but it does kind of suck for pc and xbox players out there but hey it is what it is okay so moving on and release dates now we all know that next gen being xbox series xms and the playstation 5 and pc will get to play this game as early as the 7th of February if we pre-order the deluxe edition standard editions go live on February 10th for pc xbox series xms and pc players but if you are still playing on a ps4 or the xbox one this game doesn't release for you until April 4th almost two months later and well it gets worse if you plan to play this unswitched a nintendo switch then it doesn't release until July 25th what's that five six months later which is a long time to wait because I'm absolutely at no doubt people will have completed this game fully complete this game probably before even releases on that old gen never mind july on the nintendo switch so yeah pretty disappointing there okay so lastly guys we're going to talk about the whole jk rallying situation now I ain't going to get too deep into this there are plenty of rant videos discussing interesting points defending both parties but at the end of the day me personally I don't get the whole situation of how it's escalated to a point of people actually wanting to boycott this game because of a few dumb things jk said I mean I don't get the whole construct of your opinion difference to mine shame on you for thinking that way I don't get the whole construct of your opinion differs to mine that means mine's right yours is wrong you should be punished for the way you think at the end of the day guys people within this world differ opinions differ livelihoods differ it's just the way things are but I 100% don't agree with the way they try and force their way over life on other people if you want to live your life that way that's fine live it and shut the f up about it I live my life a certain way there are many things in this world I just don't agree with you know what I do I just ignore said things I don't try and force my ways of thinking on anyone I don't try and cancel people because they think different to me I couldn't care less I'll just shut the f up jk rally made a tweet where I actually thought she was joking but clearly she wasn't but either way you ain't allowed to joke these days because you will be cancelled for it I mean she's grown up in the 80s and 90s everybody joked about absolutely everything these days guys you make one single joke your whole platform's gonna crumble beneath your feet it's just an absolute crazy world to me I mean we live in a world now where the cancer culture of grade will try and take away from other people by pushing their will on them using literally anything to do so even the most minor of things now jk rolling will benefit from Hogwarts legacy she is Miss Harry Potter but at the end of the day yeah almost all of us disagree with what she has said there really was no need for it there's no need to make a joke about it but this game is way beyond her and it supports many many many individuals who have nothing to do with her I mean I won't lie some of the things I've read online some of the absolute idiots who try and push their agenda on others is literally causing the opposite people are now more so pushing towards the game and I really ain't surprised another thing is and I've seen this so often people will agree and support you and your force until you try and affect something they like and want to do it's always been that way and I see no difference here and while you guys want to know my thoughts on the whole situation well here it is I cannot wait to play and post this game and there we have it and I know guys the end of the video has arrived if you guys enjoyed it even a like really helps out if you like what you're seeing want to see more be sure to subscribe and hopefully guys I will see you on that next one