start	end	text
28680	36800	All right. We are here with our next QA session with Jiska and Francesco for the Spectra wireless,
36800	43280	new wireless escalation targets talk. Do you guys want to give yourself a little bit of an intro?
43980	45520	Jiska, do you want to start?
48200	54520	Yeah, okay, then I'll start. I'm a postdoc at TU Darmstadt in Germany at the Secure Mobile
54520	60500	Networking Lab, and I've been, yeah, recently working a lot with Bluetooth. Before, I've been
60500	67260	working also a bit on Wi-Fi and IoT devices and all sorts of wireless communication.
70440	76780	Hi, I'm Francesco Gringoli. I'm an assistant professor at the University of Brescia and
76780	81540	have been playing with wireless technologies in the last 15 years.
81540	89480	That's great. Thank you both. So, I mean, I'm going to start off with some a little bit simpler
89480	95920	questions. So, you talked a lot about this new vulnerability that's between the two cores.
95920	101860	Is this something that can be patched? It's hard to say. So, there are parts that
101860	108620	definitely are not patchable because they are for the performance improvements. So,
108620	115200	the stuff that goes, like, between the U-code that Francesco modified and the communication
115200	120020	with the serial interface on the Bluetooth side, this is something that you need, at least if you
120020	125220	don't want to lose performance. And this is also all in hardware, I guess. So, this is something,
125220	132900	like, in a future chip, it might be changed in a way that you can infer less information,
132900	137560	but it's probably not patchable in that sense or not easily patchable.
137560	142940	The shared RAM is something that they should remove, but I didn't see them remove it yet.
142940	148100	And I don't know if they can actually unmap it in the generation of chips or if this also needs
148240	152820	a new generation of chips. I didn't see the shared RAM actually being used anywhere. So,
152820	159640	that's the weird thing, right? The shared RAM exists. Yeah. So, it exists, but it's really
159640	167600	not being used for anything or at least for nothing that I could see. So, this is the thing
167600	170580	that they should remove, because it's the most dangerous part.
171660	175620	So, we got a question from Cooper Q, and this was actually something that I was interested in
175620	180780	as well. You mentioned LTE is on some of the same frequencies, and I know that there are some
180780	186640	all-in-one chips that include LTE in addition to their Bluetooth and wireless stacks. Have you
186640	194190	tried going through the LTE baseband or use the Bluetooth interface to get at the LTE radio?
195100	201880	Not yet. So, what we tried is we tried to see if this connection exists at all. And I can tell that
201880	208080	in the Cypress Bluetooth symbols, there's definitely symbols that are called LTE or MWS
208080	216820	something. And then I also took some logs on an iPhone and like iPhone 7 and newer. And on those
216820	221880	devices, what you can see is that there are HCI commands. So, that's from the operating system
221880	229200	Bluetooth daemon to the chip that include MWS, which is the configuration for the LTE coexistence.
229200	234520	So, they are definitely using it. I just didn't try to exploit it yet.
235800	242560	Cool. Fair enough. This one, this one's one I'm going to, I'm going to have to read verbatim
242560	246240	because it's a little out of context. I don't know what it was. In the talk, you mentioned
246240	248680	Frankenstein. Can you talk a little bit about it?
250880	258700	Yeah. So, that's another paper. So, actually, the main work of this is from Jan, who is not here,
258700	266020	but that's one of my former students. And he made some snapshotting for Bluetooth chips
266020	271240	of Broadcom and then also emulation. And the interesting part about this emulation is that
271240	277300	it includes thread switches and a virtual modem so that you can attach it to your Linux host and
277300	282440	you actually can start scanning for devices and get back random devices. So, you have like a full
282440	290000	stack emulation in that sense. And this is something that we are going to present next week
290000	299420	at USENIX security. The paper is already public. And also, the software is on GitHub since a while.
299620	307380	Cool. Could you send me links for that information? You can do it after the Q&A. I just want to be
307380	311700	able to drop it in track one for anyone that's interested in following up with that information.
312440	316880	So, anyone that's paying attention, if you want the extra information, the links to the
317540	323880	paper and everything else will be in the track one room as soon as this is over.
325420	334180	Okay, on to the next question. So, regarding the CVE-2019-15063 denial of service Bluetooth
334180	340040	Wi-Fi exploit, was that the specific one that you guys were working on? I don't remember CVE numbers
340040	345300	off the top of my head. Anyways, the question is, how are you manipulating the register that
345300	349180	results in crashes? Are you physically accessing the chipset? Or can this be done remotely?
350200	355140	Ah, so yeah, that's, so it's kind of two stages, right? So, you first need some remote code
355140	359540	execution, either on Wi-Fi or on Bluetooth. And then you could write to the register.
359760	367640	And what we do for debugging is actually, so for Bluetooth, when we modify Bluetooth,
367640	373020	then we have internal blue, which is a framework that supports the vendor specific commands from
373020	379140	Broadcom to manipulate the Bluetooth part. And for Wi-Fi, there's another thing next month,
379140	385820	I think Francesco can tell a bit more about next month. Yeah, it's a project that allows people to
385820	395460	do binary patching of the wireless driver, so that you can modify and then add functionalities.
395460	399760	But of course, this is not the remote execution, it's just for modifying the binary image
399760	405280	without having access to the source code, which is a proprietary. And this allows to modify both the
405280	412720	ARM, the ARM core, and also the U-code part that is the lowest part accessible in the hardware.
413080	417340	That's really cool. Is that a tool that is going to get released like
418120	424420	upcoming? Is that part of the Usenix talk? No, next one is, I just pasted it also in our
424420	429840	private chat, so you can copy it later. Next one is something, since when is it public? I don't
429840	438520	know, 2016, 17? Yeah. And the interesting part about next month is so next month was just built
438520	445260	to actually modify the Wi-Fi firmware without the intention to really hack it. So like,
445260	451080	more for sending arbitrary signals, turning your smartphone into an SDR. And the interesting part
451080	457060	here is that back then in 2017, actually, Google Project Zero and Itay Eisenstein used this
457060	462800	knowledge to dig a bit further into the Broadcom chips. So like Broadcom and stuff like this was
462800	470080	also not only but also based on next month, and also later work, they always use next month.
470200	481060	So that's a very interesting thing about this. And then for the Bluetooth stuff, we said like,
481580	488900	well, how do you guys go about researching phones, since for the most part, everything
488900	493080	seems to be closed source? They're asking to talk about like the research process,
493080	496060	like if you were going to try and exploit a new phone?
497640	506060	Ah, yeah, so that's, that's the thing. So the first part is, I mean, if you don't have,
506060	510480	already have a working over the air exploit, which is hard to get, especially if you don't
510480	515440	have the ROM of a device and so on, even if you had an exploit, like getting it working on a new
515440	524580	device would be hard. So usually we start with a rooted smartphone, or a jailbreak. Or, I mean,
524580	531840	also MacBooks have Broadcom chips. So and there you are already root. So it depends a bit. And
531840	537100	then we would dump the ROM. And the ROM, I mean, for Wi Fi and for Bluetooth, it's pretty much the
537100	542520	same. And for Wi Fi, the ROM also contains the U code. And the U code is the thing that runs in
542520	548420	the D11 core. So what Francesco modifies, and for me, it's more the Bluetooth firmware.
549820	554220	And then it's very annoying, because like the stuff is still without any symbols. And
554220	558540	especially Bluetooth also doesn't have any debug strings, the U code doesn't have any
558540	564940	debug strings, the Wi Fi firmware has a few debug strings. And since this is like,
564940	569440	so even the memory layout is somewhat unknown, and you need to get it and so on. And because of
569440	578020	this really horribly loads into IDA. So it really looks ugly. Yeah, fair. And I think Francesco,
578020	583760	for you, it's even the case that you get new instructions, right? Yes, for the U code,
583760	592280	there is no actually corresponds between the U code and the any known CPU. So we had to do this
592280	598180	reverse engineering for understanding the meaning of these instruction set, and then adding
598180	604640	instructions, because Broadcom, during the years, added new instructions. And yeah, the reason this
604640	610480	was very difficult, because it's not ARM that you compile or disassemble, but you have to develop
610480	619760	your own tool chain for this. So what helped is that Broadcom didn't change much the platform,
619760	626640	since they introduced it 15 years ago. So they are additionally adding instructions. And
626640	631560	also what helps is that the U code is very short is less than 64 kilobytes.
633640	639780	Have you either of you looked into any of the newer, like mesh Bluetooth protocols?
640900	646140	Bluetooth mesh. So a colleague of mine did that Lars, and he looked into the friendship together
646140	652100	with a few other people in our team. So it's so yeah, we did it in our team. But the mesh is not
652100	656880	really interesting. I mean, it's just using Bluetooth LE advertisements. So from a, at least
656880	663460	from a lower level perspective, it's nothing special. I mean, of course, implementations on
663460	671200	top are interesting then. But I mean, I do a lot of lower layer stuff. He just showed that the
671200	678620	encryption and so on in the, in the friendship of groups is broken, and Bluetooth SICK send funny
678620	688980	responses. Of course it is. Someone else is shouting out that a lot of your and related
688980	695960	work on BLE is also available as pre prints from YSEC 2020. And they also threw through a link in
695960	700500	there. I just wanted to shout that out. Francesco also has done stuff with Bluetooth sniffing,
700500	706140	right? You've built a Bluetooth sniffer. Yeah, this real time sniffer using a software defined
706140	711920	radio for capturing all the channels at the same time and GPU for decoding and brute forcing
712700	717040	lowest address part address and low energy session ID.
717040	722320	Yeah, I know that there's a lot of like kind of a wide range of like capabilities of SDR stuff. Is
722320	727540	there like a minimum requirements for the SDR hardware to do that level of sniffing and
729240	731120	for Bluetooth?
733060	741500	Well, if you have SDR that can sniff 80 megahertz is better. But for sniffing Bluetooth classic,
741500	748580	we demonstrated that it's enough to capture only 16 channels out of 80. Then you can also use one
748580	757260	of these cheap SDR like, like Hacker F or Blader F. So you do not need to buy a very expensive
758080	762840	1000 euro 80 megahertz, but you can buy one of these for 100 bucks.
763840	764800	That's awesome.
764800	765700	It should work.
765700	768340	Yeah, accessible hacking. It's nice.
769380	774600	Got one person asking, do you think Broadcom is relying a little bit too much on security
774600	776560	through obscurity with some of these chips?
778500	782480	I mean, so what you can actually see, and that's an interesting development. So
782480	789440	on the first bug that Jan discovered with Frankenstein is one in the enhancing viral
789440	795900	response. And when he submitted that one, they said, we already know the bug, and we just didn't
795900	801800	find it anywhere. And then I got like the newest Samsung Galaxy S10e and extracted the ROM. And
801800	808460	this one actually had a patch and it had a compile date of April 2018. And that also means like they
808460	813600	cannot change the ROM, so they cannot tell us lies about the ROM. And we reported it afterwards.
813600	820480	So that actually means they knew it before. But, and now that's the interesting part of the story.
821140	825420	They didn't patch it backwards in the older devices because it was not publicly known as
825520	832340	a bug and you could easily unroll the patches. Now, the thing is, they definitely increased
832340	841180	the security, I would say, after the bugs in 2017 were public. So, I mean, it took them a year
841180	846540	probably to do some pen testing and so on. But you can see like 2017, the first public incidents
846540	854160	happened. 2018, the first kind of secret patches make it into the firmware. And also they started
854160	860420	using like, I don't know, stuff like secondaries. They didn't have it before. So this is things that
860420	865180	now are going into the firmware. It's still not like super perfect and everything. It's still,
865180	871340	of course, closed source. But I mean, most firmware in wireless chips is closed source.
871340	877740	Yeah. So at least they are trying to work on it. And I think they are there on that,
877740	880700	like security by obscurity doesn't really work.
881240	890280	Fair enough. So someone is asking where people could find the source code for that Bluetooth
890280	898590	sniffer. Francesco, I think that's it. Yeah, I can send you. Yeah, I can send you a link.
898590	901690	If you send me a link, I will post that with everything else.
902530	910910	Yeah. And another one. Do you think a Bluetooth or Wi-Fi based worm is feasible in the wild or
910910	914690	interoperability between implementations too difficult to bridge?
915030	920410	So I think for Wi-Fi, it's hard because for most stuff, you need to actually join an access point
920410	925590	or something like this. But for Bluetooth, you have this master slave mode. So you can actually
925590	930090	have a device like a smartphone is usually capable of being master and slave. Some like
930090	934750	cheap devices, cheap IoT devices sometimes are only in slave mode and cannot do master.
934750	939710	But if you can be slave and master, then you can be part of this, let's say,
939710	948710	network and distribute the malware. And I think there is, let's say, a sufficient fraction of
948710	954950	popular devices. So it depends if it's in the operating system, then it would have to be like
954950	960470	compatible iPhones or something. And I mean, if you just there's not much diversity in iPhones.
960470	965650	So if you just take like the top selling iPhones or something that also would work on the chip
965650	971490	base. On Android, you have more diversity. But still, if you would say you just pick the top
971490	980010	Samsung and Galaxy, and maybe the pixels or something. Yeah, that could work. So Jan actually
980010	987670	uncovered vulnerability in the Android Bluetooth daemon. And that one would have been vulnerable.
987670	995630	And it was fixed in February. I mean, still, yeah. So you couldn't infect like 100% of devices.
996020	1001710	Considering that you have your Bluetooth on and walk around and so on, that would be a threat.
1001930	1007570	So the reason why I think people wouldn't build it is how do you control it? Because then you need
1007570	1012610	to have some communication over the internet or something like how do you do like a command and
1012610	1020270	control server for Bluetooth form in a way that is like stealthy and really, I don't know. So I
1020270	1027030	think it's really more the bigger threat is definitely taking over nearby devices or like
1027030	1032410	hacking someone or like going next to an office train station somewhere where you know, like
1032410	1037310	interesting people are and taking over their devices. But I think even if it's vulnerable,
1037310	1043910	I think this is nothing that people would build. But I mean, maybe someone builds it someday.
1043910	1049770	So I won't build it because, well, I wouldn't. But I mean, maybe someone is crazy enough to do
1049770	1054590	this, right? It's just true. I mean, you could potentially just do it without a financial
1054590	1061970	motivation, just to see if it works or something. Yeah. So switching gears just a little bit.
1062570	1066530	Did you guys report this to vendors? Like how was how did that communication like turn out?
1066530	1075670	Was it positive? Was it negative? Was it? Tell me. Yeah, so the very first report about this
1075670	1081290	denial-of-service was in August last year. So that's like a year ago. And I think they didn't
1081290	1085410	really take it serious because it was just denial-of-service, right? And even if you have
1085410	1089970	denial-of-service with an operating system reboot, it's like nothing that you could really control,
1089970	1094490	right? So like writing FF to one register, it reboots. Okay. But who cares? Because you need
1094490	1102250	RCE first. It's just it's hard to control. And interestingly, in September that year,
1102250	1109310	the iOS 13 update came out, and it actually mentioned Jan, Francesco, and me. So and so
1109310	1113030	Jan was working mainly on Frankenstein. I also worked a bit on Frankenstein. And
1113870	1118170	the coexistence was what I did with Francesco. So I was like, okay, if they also mentioned
1118170	1122990	Francesco and me, they should have fixed it. But they didn't. So I was a bit confused that
1122990	1127490	all the names were mentioned there in the iOS 13 update. And also a month is a bit too short.
1127490	1132330	And everything that they patched but silently already before was the enhanced inquiry response
1132330	1138170	issue. And then like I poked them from time to time, did you already patch it? Why didn't you
1138170	1148190	patch it? And so on. And at 3063 on stage, I also showed that this is still unpatched and so on.
1150030	1155170	And they still didn't patch it. And back then I already had in mind. So that was when I already
1155170	1160210	called Francesco and said, like, in January, we are going to build speculative transmission.
1160250	1164490	So that was, I was like, please get things in that direction of a text
1165130	1169750	fixed. But yeah, and then end of January, I actually knew that this is probably unpatchable.
1169750	1174990	And that was when I sent Apple that email, you know, why Broadcom didn't send you a fix because
1174990	1184610	it's unpatchable. What are you telling us? And yeah, so at least so that that means like Broadcom
1184610	1190130	and also like some of their customers got like some, some notice already in January, about those
1190130	1195570	things like that they are broken. And I mean, also like the ones before just about denial of service.
1195690	1200650	And then I was building a few more pox beginning of March, because I was very busy in between.
1200650	1205190	But that were like the final proof of concepts like that there's even this ram sharing and it
1205190	1210030	is exploitable and stuff like this, which I mean, Broadcom should have known it already.
1210030	1215190	And they already introduced this, this one patch that you no longer can write
1215710	1220030	to the Bluetooth ram after drive initialization that one was already pushed to devices
1220030	1226110	somewhere around March. So this is like the thing that they did against it and that they could
1226110	1232810	easily do because they were like informed quite a long time before. And then in March, when all
1232810	1238790	the proof of concepts were also like, easy to run running and so on. Then I also started informing
1238790	1244710	the other vendors who I found to have coexistence in their data sheets mentioned. So
1245190	1250450	it's probably not everyone who uses it, but at least people I know that they use it.
1251850	1256610	So this is something that like if other people were going to go look at other chipsets,
1256610	1261290	the coexistence is what they'd be looking for, for a similar style of vulnerability.
1262450	1266650	I'd be something else. So I'm not sure how it is with all the other devices,
1266650	1272270	but it's definitely existing in a couple of devices and all proprietary.
1272650	1278290	And that coexistence is controlled by that one. Was it CC10 chip?
1278290	1283250	I forget the name of the chip. It was the microcode portion that...
1286090	1288330	Ah, the D11, you mean?
1288330	1289770	Yes, that's the D11.
1289770	1295090	Yes, it's controlled by this low level stuff, because it must be real time. So it's an
1295090	1299630	arbitration between the Bluetooth and the wireless, and the wireless needs to run this
1299630	1304810	into the lowest part of the stack that is directly on this microcontroller.
1305570	1309410	Could you... is there anything else about that microcontroller that you
1309410	1312470	want to talk about or share with people that are watching right now?
1313550	1318850	Well, I think that it's very interesting if you can have the ability to hack this,
1318850	1326410	because it's the part that can decide what to transmit and whether the received frame should
1326410	1331850	be pushed to the host. So it's very interesting because you can also develop a very small stack
1331850	1339150	over there, and the behavior of this stack would be completely not detectable by the host. So there
1339150	1345210	is no way for the host to understand what the U-code might do. So if you find a way for changing
1345210	1349310	the U-code over the air, then wow, that's amazing what you can do.
1349310	1354310	But so is this something that could like proactively drop packets with like a magic value
1354310	1355990	or something like that?
1355990	1360650	Yeah, yeah, yeah. For this test that we were doing with the coexistence, we were
1361450	1367850	sending command to the wireless interface over the air, and the U-code is the D11 core is receiving
1367850	1373390	them, then dropping them, and changing the configuration of the wireless interface.
1373390	1376050	This is totally unnoticed by the host.
1378970	1385850	That's awesome. What are the next areas that you guys are looking into for like future research?
1385850	1389030	Do you have anything already lined up? Anything you can talk about?
1389610	1396170	Probably the can talk about is the part, right? I mean, obviously like wireless security, but
1396170	1402810	yeah. So there will be stuff coming up. So I will definitely do further research
1403730	1408010	and I mean, Francesco has been doing this for so many years, probably nobody else is like
1408010	1414610	questioning what he's going to do in the future when he has been doing it for the last 15 years.
1417970	1423670	Fair enough. Yeah, I'm running out of questions. We do have a couple more people that are
1423670	1430690	are typing now. Yeah. So I mean, we've got a few moments. Is there anything that you guys
1430690	1433970	want to talk about proactively that we haven't already covered?
1435610	1441450	I mean, so something that is kind of interesting is that like people currently like also if you
1441450	1446910	look into the first YouTube comments of the talk, it's like they are like, you are just publishing
1446910	1452310	this because I don't know there is this exposure notifications for Corona and stuff like this.
1452310	1458270	But actually, we have been working on this, I mean, since much longer time than this. So it's
1458270	1465690	nothing that's like connected to Corona or something in that sense. And also, I think like,
1465690	1472390	for average people who just keep their system up to date and just use it. I don't think that it's
1472390	1477570	like a big threat in that sense. I mean, of course, like if you go on DEF CON, where a lot
1477570	1481810	of hackers are around you, you might want to disable Bluetooth and Wi Fi, but like disabling
1481810	1491390	Wi Fi also has been a well known practice in the past. So yeah, it's in your experience,
1491910	1496570	in your experience, does disabling like Bluetooth and Wi Fi in the device actually turn off the
1496570	1504250	full radio? It doesn't turn off the chip, but it disables the host deck usually in a way
1504250	1511610	that you cannot establish active connections anymore. It depends. But so yeah, I mean,
1511610	1517710	of course, like switching off your device if you don't want it to be hacked is a good practice,
1517710	1523130	probably even taking out the battery. It really depends. It really depends on your on your level
1523130	1529990	of paranoia, of course. But so yeah, so those those people who who are afraid because they
1529990	1534010	have like, I don't know if you if you have something on your smartphone that's like worth
1534630	1540590	100,000 bucks or something, then maybe consider being hacked because this is like the range where
1540590	1547550	exploits for those devices start, right? So yeah, so that's probably the threat model here.
1547550	1553330	And I don't think that like, I mean, until someone writes that Bluetooth form, who knows?
1553330	1560110	But I don't think that until then, like, Bluetooth would be the preferred way to hack people.
1560310	1567870	What I still don't like about like, or how all this stuff like goes is that still Wi Fi and
1567870	1573670	Bluetooth are like, I mean, they have been exploited back in 2017, very publicly, and they
1573670	1579130	are still very insecure. And that's, that's the part here, like they have been insecure for years.
1579130	1585310	And there's, I mean, some things are happening, but really vendors and so on, they really need
1585310	1592050	like some motivation to fix stuff even further. And so I wouldn't really say like, we are making
1592050	1597670	it more insecure. It's really like kicking them somewhere and saying like, please, please fix it,
1597670	1603970	make it better. Like we have seen like at least some improvements within the Broadcom firmware,
1603970	1608410	it's still not super secure, but it's secure after the things that happened in 2017. And
1608950	1612230	yeah, so I hope to move it a bit more in this direction.
1612310	1616130	Do you have a general feeling for like, if there's any particular chips that
1616130	1620390	are seen more secure than others, like a better coding practices or
1620870	1624010	anything like that? Or are they all kind of roughly the same?
1625050	1629970	There are at least some that are more obscure than others. I mean, Qualcomm has their own
1629970	1637030	hexagon DSP, which you can emulate, but there are, I think there's a disassembler plugin for
1637030	1642930	Ghidra, which partially works. And then there is two for IDA, but they also don't support like
1642930	1648070	all commands. Then you just have disassembler and not the compiler, Ghidra you would also have
1648070	1654250	the compiler. So it's really bad quality of those tools for Qualcomm. And then still
1654250	1659650	last year at DEF CON, there has been a talk about Qualcomm Wi-Fi having a bug. And they,
1659650	1662690	so after the talk, I just went to them, I was like, how did you find it? I said,
1662690	1670290	just like static reverse engineering. I was like the hexagon, right? But yeah, so
1671530	1677150	not sure if Qualcomm is more obscure or really more secure, at least they have more people on
1677150	1685030	security conferences and, but yeah, it's, it's hard to tell. So I think in general,
1685030	1690010	if you have newer hardware, then you have more security measures in it and like newer chips.
1690010	1697610	So if you buy like the most expensive Google or iPhone or whatever, it's probably more secure
1697610	1703490	than if you buy some very cheap smartphone with cheap chips that didn't have so much money for
1703490	1709190	development, but it's still no guarantee. So it just, it could have the budget to make it secure
1709190	1716570	if they wanted to make it secure. It's no guarantee, right? Right. Fair. And the last
1716570	1722150	question that I think that we can take, and this one's not directly about your presentation. Someone
1722150	1726970	wants to know how you displayed your hand behind your presentation in the actual recorded video.
1728210	1735430	So that's actually a method that I stole from Daniel Crusoe, the guy who did the spectra.
1735490	1741310	So for his lectures, he's using OBS and he has a white wall. I mean, I also have the white wall
1741310	1745570	behind me, right? And then I point with my hand and this is the part that I'm filming. And so
1745570	1751410	this, this part would be like behind the slide and in the slide, I said white as an opaque color,
1751410	1756670	and then I put my hand off. So behind it, so then I have the layers and I can do the
1756670	1759390	the pointing. So this would be the pointing.
1760010	1763710	Nice. I'm sure some other presenters will appreciate that touch.
1764970	1769650	Okay. Well, that's all the time that we have for you. Thank you both for joining us for the Q&A
1769650	1779210	session. Thank you both for getting content into the virtual DEF CON and yeah, have a nice day.
1780270	1781170	Thank you, too.
1782090	1782670	Take care.
1782670	1783390	Thank you, too.