[00:00.060 --> 00:08.040] Our next talk comes from Turkey. It is with great pleasure to welcome and introduce you to Oskan [00:08.040 --> 00:15.550] Mustafa Akkus and his talk, The Vulnerability that Gmail Overlooked and Enabled Threat Hunting. [00:20.300 --> 00:22.140] Take it away, Oskan. [00:25.970 --> 00:33.270] Hello, I wish happy days to everyone. I am Oskan Mustafa Akkus. Today I'm going to talk about [00:33.270 --> 00:37.970] the threats that the SMTP protocol can pose and show you how large mail [00:38.710 --> 00:45.570] providers such as Gmail overlooked and enabled threat hunting. It makes me sad not to be in [00:45.570 --> 00:51.350] Vegas right now, but health is more important than anything, so please be careful and don't [00:51.350 --> 00:59.770] go out without a mask. First of all, I want to talk about myself. I'm a vulnerable researcher [00:59.770 --> 01:05.030] and penetration tester in Turkey. While studying sports science and technologies, [01:05.030 --> 01:12.390] I decided to leave the university and step into the world of cybersecurity. My purpose is to [01:12.390 --> 01:18.530] provide added value to the world of cybersecurity through the training I had given and the research [01:18.530 --> 01:24.830] I had conducted. I published security vulnerabilities on international platforms [01:24.830 --> 01:33.010] that I had discovered. I entries my exploit to CVE and EDP databases. You can also access my [01:33.010 --> 01:41.560] previous works on my personal blog pentes.com.tr. I would like to mention presentation schedule. [01:42.050 --> 01:49.310] First, we will focus on SMTP protocol structure and threats. We're going to analyze by sending [01:49.310 --> 01:57.670] training emails inspired by SMTP, and then we're going to review and result and scheme [01:57.670 --> 02:04.190] of the research. Finally, I'm going to share an explosive tool as a bonus with you. [02:04.910 --> 02:15.350] I don't have the DEF CON 28 badge today. Because of that, I am using DEF CON 26 and 27 badges. [02:16.110 --> 02:22.590] I miss it using them very much. So, let's start. [02:24.090 --> 02:29.990] Let's look at what SMTP is. Also, let's take a look at the structure of this protocol and [02:29.990 --> 02:36.390] examine the logic of operation. As everyone knows, SMTP is simple mail transfer protocol. [02:36.390 --> 02:40.750] As mentioned in the name, it's very simple protocol. We know that the simple structure [02:40.750 --> 02:47.730] can always pose a danger. So, new solutions and models contribute to the straightening of [02:47.730 --> 02:54.070] the simple structure. Different solutions were used for many security problems in SMTP. [02:54.070 --> 03:02.550] We're going to touch this issue again later. SMTP was published as IFC 788 by Postel in November [03:02.550 --> 03:14.610] 1981. This protocol structure was finalized as IFC 821, IFC 2821, and IFC 5321. [03:14.610 --> 03:23.470] IFC 5321 is the last standard published in 2008. Today, there are famous structures that [03:23.470 --> 03:30.250] high mail transfer agent is the use of the SMTP protocol such as Gmail, Postfix, [03:30.250 --> 03:38.730] Microsoft Exchange Server, Yandex, Mail.ru, Yahoo, and so on. You can examine the history and [03:38.730 --> 03:44.030] final version of the SMTP protocol in detail through the link below. [03:45.510 --> 03:51.430] According to Internet Engineering Task Force, the simple structure of the SMTP protocol can [03:51.430 --> 03:59.150] be shown as follows. Let's follow a path from the simple structure to complex structure. [03:59.150 --> 04:06.010] Below, we can see the structure that is not separated into its components. So, SMTP clients [04:06.010 --> 04:13.970] communicate via the internet. Let's continue the review by adding protocol components. If we move [04:13.970 --> 04:22.490] to from general to detail, it will be more memorable. In the diagram below, you can see that we have [04:22.490 --> 04:28.750] divided the SMTP client and SMTP server into two components such as mail transfer agent and [04:28.750 --> 04:34.330] user agent. The user agent creates the envelope then puts the message in the envelope. So, it [04:34.330 --> 04:40.610] prepares the message. The mail transfer agent transfers his prepared mail across the internet. [04:40.610 --> 04:47.050] This is done in the same way on the parties receiving the mail and delivering the mail. [04:47.050 --> 04:53.770] Up this time, the SMTP protocol was in a very simple state. Spring made trails with the simple [04:53.770 --> 05:00.330] structure. Therefore, different structures are included to strengthen the SMTP protocol. For [05:00.330 --> 05:09.110] example, extended SMTP has been released. Extended SMTP defines a framework for extending SMTP [05:09.110 --> 05:16.010] service by defining a means whereby a server SMTP can inform a client SMTP as to the server [05:16.010 --> 05:24.430] extension it supports. So, control has been added to DNS site which is used especially for email [05:24.430 --> 05:32.610] transfer. Authentication to SMTP server, domain case identification mail, domain-based message [05:32.610 --> 05:38.910] authentication, reporting and conformance, and standard policy framework are the controls provided [05:38.910 --> 05:44.870] on the DNS site. While many standards have been published to strengthen the SMTP protocol, [05:44.870 --> 05:51.750] the most important of this is the standard policy framework. This will be the point we will focus on [05:51.750 --> 05:57.890] today. At this point, we will review the Internet Engineering Task Force's documents again. According [05:57.890 --> 06:04.950] to Internet Engineering Task Force, IFC 7108 is version 1 for standard policy framework for [06:04.950 --> 06:12.570] authorizing use of domains in email. You can get detailed information from the link below. [06:12.570 --> 06:19.130] There's a sentence like this in the abstract description. This sentence is exactly like this. [06:19.130 --> 06:25.890] Email on the internet can be forgotten in a number of ways. In particular, existing protocols place [06:25.890 --> 06:31.650] no restriction on what a sending host can use as the mail from of a message or the domain given on [06:31.650 --> 06:38.430] the SMTP hello, hello comments. This part is very important. Existing protocols place no restriction [06:38.430 --> 06:44.730] on what a sending host can use as the mail from of a message or the domain. This means that the [06:44.730 --> 06:50.850] SMTP protocol is a very primitive structure. It's ironic that the millions of the servers are not [06:50.850 --> 06:58.310] using mail from control while using this protocol. Our main subject today is how famous mail transfer [06:58.310 --> 07:05.810] agent services can pause a trade event thought they use SPF. In fact, today I was gonna just [07:05.810 --> 07:12.670] share a situation related to Gmail, but it was March 3 when I applied for Package Hacking Village, [07:12.670 --> 07:19.210] so I continued my research and perform a test on other famous email providers. [07:19.290 --> 07:27.370] So today we will examine also other famous mail providers, not only the Gmail. These will be [07:27.370 --> 07:35.790] Gmail, Yandex Mail, Mail.ru, Outlook, Hotmail, Yahoo, Zoho Mail, Hi.com, and HubSpot. [07:35.810 --> 07:41.070] Because of that, it will be more correct to change the presentation title as [07:41.790 --> 07:47.240] the vulnerability that famous email providers overlooked at enabling trade hunting. [07:47.750 --> 07:54.610] Let's send emails that can pause trades and analyze the situation later. I worked on Exploit [07:54.610 --> 08:00.890] to send these training emails. I'm so sorry to say that, but I'm not gonna share the details [08:00.890 --> 08:07.290] of Exploit because it's so dangerous. However, I'm gonna show you with live examples. I'm gonna [08:07.290 --> 08:14.190] use an SMTP server as a gateway by authentication with user information. This server will be an SMTP [08:14.890 --> 08:21.190] server without open relay. In addition, this server must be a trusted server that has been [08:21.190 --> 08:27.770] previously approved by famous email providers and has no problem with mail delivery. The server I [08:27.770 --> 08:33.710] use in Exploit for this process will be my university's mail server. The servers of large [08:33.710 --> 08:42.790] companies and universities are in constant communication with famous email providers, [08:42.790 --> 08:51.510] so we can bypass most of the DNS-based controls. If you try to do this by creating a new server, [08:51.510 --> 08:58.110] you're gonna definitely fail. There's also another detail in the Exploit I wrote about that, [08:58.110 --> 09:06.530] but I'm not gonna share these details as I said before. We're gonna conduct internal and external [09:07.350 --> 09:13.830] tests on famous mail providers. In internal tests, we will try to send arbitrary mail via [09:13.830 --> 09:20.430] mail providers' own domain name, for example, gmail2gmail. In external tests, we will try to [09:20.430 --> 09:29.070] send arbitrary mail using the domain name walloffship.com. Let's analyze these training [09:29.070 --> 09:34.610] emails by sending them. I created a special account on all of the famous email providers. [09:34.610 --> 09:39.570] We're gonna perform internal and external tests throughout these accounts. We're gonna do tests [09:39.570 --> 09:49.170] on Gmail, Yamnix Mail, Mail.ru, Outlook, Yahoo Mail, Zoho Mail, Hai.com, and HubSpot. [09:49.170 --> 10:00.250] My Gmail account was forwarded to HubSpot. It's also forwarded to Hai.com too. [10:00.790 --> 10:08.810] Therefore, we're gonna also test Hai.com and HubSpot with email we sent to Gmail. [10:10.150 --> 10:16.250] In internal tests, we will try to send arbitrary mail via mail provider's own [10:16.250 --> 10:21.290] domain name. And then we're gonna analyze the results. [10:22.770 --> 10:32.610] We're gonna send the mail from defconn.gmail.com to defconn.pishui.gmail.com first. [10:32.930 --> 10:42.660] Let's start with Gmail. I'm gonna send it. [10:43.300 --> 10:52.220] It will be passed. We need to wait a little. [10:56.250 --> 11:03.390] And mail has been sent successfully. As you can see, the mail dropped on the inbox. [11:03.390 --> 11:08.050] However, there's a big warning that this mail could not be verified that it came from [11:08.050 --> 11:17.170] defconn.gmail.com. But when we look at Hai.com, there is no warning here. [11:17.850 --> 11:25.070] This is a very dangerous situation. Similarly, when we check the HubSpot, [11:25.070 --> 11:30.750] we see that the mail is successfully forwarded and does not contain any warning too. [11:31.870 --> 11:35.430] I'm gonna explain the source of this vulnerability to you later. [11:36.050 --> 11:39.230] Let's continue our test with Yandex Mail. [11:39.310 --> 11:45.890] Now I'm gonna send email from defconn.yandex.com to defconn.pishui.yandex.com. [11:45.890 --> 11:51.950] I'm passing information here. [11:52.270 --> 12:04.650] Yeah, mail has been sent successfully. I will check the inbox. [12:04.650 --> 12:08.710] And I reflect the page and check the inbox and spam box again. [12:10.710 --> 12:16.470] But no email came. Yandex didn't allow us to construct its own domain name. [12:17.050 --> 12:25.270] So let's continue the test with mail.ru. I'm gonna send email from defconn.mail.ru [12:25.270 --> 12:32.550] to defconn.pishui.mail.ru. I'm passing information. [12:40.750 --> 12:46.150] Mail has been sent successfully. I will check the inbox. [12:52.100 --> 12:55.000] I'm gonna check back again to make sure. [13:00.010 --> 13:07.090] No email came. Mail.ru didn't allow us to control its own domain name such as Yandex. [13:07.690 --> 13:16.810] So let's continue the test with Hotmail. I'm gonna send email from defconn.hotmail.com [13:16.810 --> 13:31.720] to defconn.pishui.hotmail.com. Mail has been sent successfully. [13:32.580 --> 13:39.680] I'm checking the inbox. No email inbox, but as you can see it dropped into the spam box. [13:40.580 --> 13:46.020] The mail is here. And let's continue the test with Yahoo Mail. [13:46.320 --> 13:53.020] I'm gonna send email from defconn.yahoo.com to defconn.pishui.yahoo.com. [14:02.680 --> 14:07.740] Mail has been sent successfully. I'm checking the boxes. [14:20.160 --> 14:22.540] Oh, Trump came to his own mail. [14:25.020 --> 14:30.560] And no mail came. Yandex didn't allow us to control its own domain name too. [14:30.560 --> 14:36.980] Let's continue the test with Zoho Mail. I'm gonna send email from defconn.zohomail.com [14:36.980 --> 14:54.750] to defconn.pishui.zohomail.com. Mail has been sent successfully. [14:56.810 --> 15:04.000] Let's check the page by reflashing. I'm checking the boxes. [15:08.270 --> 15:12.310] No mail came. Zoho didn't allow us to control its own domain name too. [15:12.310 --> 15:15.910] So internal tests are over. We can pass to external tests. [15:16.210 --> 15:20.130] Time to external tests. I'm gonna use the email address mink [15:20.130 --> 15:25.090] at walloffship.com for external testing. We're gonna send email from mink at [15:25.090 --> 15:29.730] walloffship.com to other email addresses. Let's start with Gmail. [15:29.890 --> 15:44.700] I'm passing. Mail has been sent successfully. [15:44.760 --> 15:48.180] At the same time, the mail dropped into the inbox already. [15:48.300 --> 15:52.720] As you can see, we cannot see the warning here as internal tests. [15:52.720 --> 15:56.060] When you browse the first mail, you can see the difference, [15:56.060 --> 16:00.580] but there is a small detail. There is a question mark in the profile photo. [16:00.620 --> 16:06.500] When we move the cursor to this point, we notice that there is a warning again here. [16:06.500 --> 16:13.440] It says your mail could not verify that walloffship.com actually sent this message. [16:13.440 --> 16:21.320] But I don't know which user cares about this. I'm gonna show an example later on this situation. [16:22.060 --> 16:29.820] Let's check out hey.com and HubSpot now. As you can see, mail has been forwarded [16:29.820 --> 16:36.480] without any warning such as an internal test. The situation looks the same for HubSpot too. [16:37.100 --> 16:41.480] There is no warning and mail is cleanly forwarded. [16:41.480 --> 16:46.100] I also want to show you what's happening in the Gmail application. [16:47.640 --> 16:53.740] I'm gonna show you an older version. There is no warning even in the profile [16:53.740 --> 16:59.440] photo in the mobile application. However, until two months ago, [16:59.440 --> 17:03.840] it was affected by this weakness in the last version. [17:03.840 --> 17:10.680] I didn't report them, but they fixed the vulnerability. I don't know how they learned. [17:12.500 --> 17:16.760] Maybe my mails may be under review. I don't know. [17:17.140 --> 17:23.620] But still, I want you to know that the old versions are still vulnerable. [17:24.740 --> 17:29.960] Let's continue tasks with Yandex Mail. I'm gonna send email from [17:29.960 --> 17:34.740] mink at walloffship.com to defcomph3 at yandex.com. [17:36.580 --> 17:52.560] I will pass the information. Mail has been sent successfully. [17:54.160 --> 18:03.680] I will check inbox. As you can see, mail dropped directly into the inbox. [18:03.680 --> 18:09.220] Also, there is no warning in the mail content. It's a very dangerous situation. [18:09.280 --> 18:12.440] I'm not Mink, but it doesn't matter for Yandex. [18:13.000 --> 18:17.720] Therefore, we can say that Yandex is affected by this situation. [18:18.240 --> 18:24.660] I'm taking note of this and let's continue tasks with mail.ru. [18:25.220 --> 18:32.180] I'm gonna send email from mink at walloffship.com to defcomph3 at mail.ru. [18:44.110 --> 18:51.360] Mail has been sent successfully. As you can see, the mail has arrived quickly. [18:51.920 --> 18:57.300] Just like Yandex, mail.ru didn't check if I was Mink or not. [18:57.300 --> 19:02.860] Therefore, we can say that Yandex is affected by this situation too. [19:03.160 --> 19:08.740] Let's continue tasks with Hotmail. Now is I'm gonna send email from [19:08.740 --> 19:14.060] mink at walloffship.com to defcomph3 at hotmail.com. [19:28.090 --> 19:34.650] Mail has been sent successfully. Now I will check. [19:35.590 --> 19:40.510] And no mail inbox, but as you can see, it dropped into the spam box. [19:40.610 --> 19:45.500] Hotmail sent this message to the spam box because it couldn't verify its owner. [19:45.910 --> 19:51.260] So I am taking note of this. Let's continue tasks with Yahoo mail. [19:51.690 --> 19:57.510] I'm gonna send email from mink at walloffship.com to defcomph3 at yahoo. [19:57.530 --> 20:15.890] com. Mail has been sent successfully. [20:17.270 --> 20:31.470] I'm checking the boxes. I'll tramp again, I think tramp is after me. [20:31.870 --> 20:34.730] I will check boxes a few times to be sure. [20:39.810 --> 20:45.050] No mail has been received. Yahoo is very strict about this. [20:45.050 --> 20:50.210] I take note of this and pass the final external test of Zaha mail. [20:50.210 --> 21:09.970] I'm gonna send email from mink at walloffship.com to defcomph3 at zahomail.com. [21:10.010 --> 21:14.310] Mail has been sent successfully. I'm checking the boxes. [21:18.850 --> 21:24.250] And no mail has been received, so Zaha mail is very strict about this, such as Yahoo. [21:24.770 --> 21:30.030] This was our last test. It's time to analyze the information we collect. [21:31.090 --> 21:35.210] As an example of my research, I caught a very interesting example. [21:35.230 --> 21:41.210] I want to present this to you. My friend was accepted by defcom Red Team Village. [21:41.210 --> 21:48.670] This news came to him from omar at redteamvillage.io. [21:48.750 --> 21:55.090] When I review this email, there's a warning in the Gmail proper photo area, just like our external [21:55.090 --> 22:01.290] test. My friend did not pay attention to this situation and answered this email. [22:01.930 --> 22:08.770] Fortunately, the mail really came from Omar, but this could be a fake mail. [22:08.910 --> 22:16.570] Now I'm gonna send an email from omar at redteamvillage.io to my friend gmail artist. [22:17.230 --> 22:20.550] We're gonna also carry out internal and external testing and [22:20.550 --> 22:27.630] look at the response of the email application on the Apple Mac device to this vulnerability. [22:28.570 --> 22:35.430] Let's send the mails. I'm gonna send these test mails from my second screen. [22:41.450 --> 22:50.390] As you can see, the mail from defcom at gmail.com also cancels a warning in the Gmail web application. [22:51.070 --> 22:58.610] However, in the email application of the Mac operating system, this mail does not [22:58.610 --> 23:03.290] cancels any warnings. This is a very interesting finding, too. [23:03.730 --> 23:09.750] In addition, the mail I sent from Omar successfully reached the application [23:09.750 --> 23:19.290] allowed me to pass whether I was Omar or not. Now, time to examine where this vulnerability is [23:19.290 --> 23:26.130] caused. Now I'm gonna show where the vulnerability originated. As I have shown before, [23:26.130 --> 23:32.010] we're gonna examine why third-party applications cannot detect this little warning in the profile [23:32.010 --> 23:37.930] photo area and why are they receiving this training mail cleanly from Gmail. [23:38.030 --> 23:42.590] Let's look at what's happening again. Hair.com does not have any warning. [23:43.430 --> 23:50.330] Also, HubSpot does not have any warning, too, as you can see. [23:51.050 --> 23:58.290] Mail that is perceived as dangerous in Gmail looks completely clean on these platforms. [23:58.290 --> 24:02.230] To show that, I'm gonna use Python library writing for the Gmail API. [24:02.230 --> 24:08.380] With this library, we're gonna check the email contents by making a request to the Gmail API. [24:09.130 --> 24:14.750] First, we need to learn the ID value of the message we want to link. [24:16.890 --> 24:24.010] And I think that should be it. I need to put this ID value into the library properly. [24:24.010 --> 24:31.450] We also need to use GET instead of LIST. It is now ready to make request again. [24:32.700 --> 24:38.930] As you can see, all the details of the mail are here. After a little examination, [24:39.290 --> 24:45.450] we realized that the warning in the Gmail web application is not among the information [24:45.450 --> 24:53.490] received with the Gmail API. Therefore, we have proved that third-party applications such as [24:53.490 --> 24:59.410] Hair.com, HubSpot, and Apple email applications cannot detect this warning because [24:59.410 --> 25:07.070] they use the Gmail API. There are dozens of applications using the Gmail API, [25:07.070 --> 25:14.710] so this vulnerability caused by Gmail affects them all. In this case, it leaves millions of [25:14.710 --> 25:22.390] people directly in danger. These applications which can connect with Gmail need to make a [25:22.390 --> 25:31.810] new update considering this situation. Once and for all, let's examine the result of our internal [25:31.810 --> 25:37.330] and external test again. Let's take a brief look at the result of our test. [25:37.330 --> 25:45.590] I'm going to summarize this part quickly. The meaning of the signs are here. In internal tests, [25:45.590 --> 25:54.190] training mails drops into the inbox with warning in Gmail and doesn't drop into any box in Yandex [25:54.190 --> 26:02.950] and doesn't drop into any box in Mail.ru and drops into the spam box in Outlook and doesn't drop [26:02.950 --> 26:10.990] into any box in Yahoo and doesn't drop into any box in Zahoomail too. In external tests, [26:10.990 --> 26:18.950] the training mails drops into the inbox without warning in Gmail and drops into inbox without [26:18.950 --> 26:28.670] warning in Yandex and drops into the inbox without warning in Mail.ru and drops into the spam box in [26:28.670 --> 26:36.730] Outlook and doesn't drop into any box in Yahoo and doesn't drop into any box in Zahoomail too. [26:36.770 --> 26:43.470] Unfortunately, third-party applications using APIs of famous mail providers cannot reflect [26:43.470 --> 26:49.450] warnings. Initially, the incoming email is forwarded directly without an error message. [26:49.750 --> 26:56.650] So, Hide.com forwarded training mails and mails dropped into the inbox without warning. Also, [26:56.650 --> 27:03.610] HubSpot forwarded training mails and mails dropped into the inbox without any warning too. [27:03.610 --> 27:10.130] This was the test result with it. I'm sharing an exclusive tool with you at the last stage of my [27:10.130 --> 27:17.170] presentation. Its name is DraftChat. DraftChat allows persons to chat throughout mail providers. [27:17.170 --> 27:23.570] You can access the GOD chat module, which is the first module and uses the Gmail API. [27:24.130 --> 27:30.810] DraftChat allows persons to chat throughout a single Gmail account in the Gmail that does not [27:30.810 --> 27:41.550] record drafts. It encrypts the sent message first with DES and then with the AES algorithm and writes [27:41.550 --> 27:49.490] them to the created draft. The message of person I've written in encrypted form on the same draft. [27:49.490 --> 27:56.450] Message can only be read with the correct case to be determined. In this way, a completely hidden [27:56.450 --> 28:02.850] chatroom is created with a single Gmail account. Therefore, DraftChat makes person-hundred private [28:02.850 --> 28:10.230] communication opportunity by turning a non-URL mail server into a chat server. You need to set [28:10.230 --> 28:16.530] up a common Gmail account to chat with your partner. Remember, you will only perform this [28:16.530 --> 28:23.650] operation once. You will not have to do this configuration every time you chat. Let's do the [28:23.650 --> 28:30.730] installation pace in a practical way. First step is turn on the Gmail API. First of all, we need to [28:30.730 --> 28:35.950] allow for quick start from our Gmail account, because we are using fighting quick start. Click on [28:35.950 --> 28:44.410] enable the Gmail API button. In this section, you should choose the desktop. In zone link dialog, [28:44.410 --> 28:51.310] click download client configuration and save the file credentials.json to your DraftChat directory. [28:51.310 --> 28:59.130] After running DraftChat, it will first ask you for your nickname. Once you have determined [28:59.130 --> 29:05.870] your nickname, you must determine whether you want to be a server or a client. Client-server [29:05.870 --> 29:13.930] relationship is very simple. If you want to be a server, the DES and AES keys that you determine [29:13.930 --> 29:20.670] will be used. If you choose to be a client, you have to get keys for these algorithms from your [29:20.670 --> 29:29.870] server partner. Let's say you choose the server option. After the retirement and 8-digit DES key, [29:29.870 --> 29:38.010] DraftChat generates a 16-digit random AES key for you and a new draft is created for the chat rooms [29:38.010 --> 29:44.330] that your client partner is expected. So you need to pass this case over to your partner. [29:45.070 --> 29:50.650] Let's take a look at the client option. In this case, I have taken an entrant from the server [29:50.650 --> 29:57.350] partner. If the keys are wrong, there is no server rating for the client, the program will give an [29:57.350 --> 30:04.450] error. The taken keys were entered and the information was verified. So you can communicate [30:04.450 --> 30:10.530] with your partner in peace of mind. When the draft box of our Gmail account is checked, [30:10.530 --> 30:18.550] you can see that a new draft has been created here. All messages are written here and the draft [30:18.550 --> 30:26.290] is continuously encrypted with algorithms. We can test this by writing a new message. [30:28.450 --> 30:34.870] It's for grids. The fact that you are offered a private chat room does not mean that the [30:34.870 --> 30:42.390] communication you provide while using this tool may be illegal. Remember that all the responsibility [30:42.390 --> 30:49.430] belongs to you. You can download DraftChat from GitHub. It also opened the development. You can [30:50.070 --> 30:56.670] contribute to this tool if you wish. Yes guys, now it's over. Thank you so much for listening to me. [30:56.670 --> 31:02.230] You can contact me from my social media accounts and you can ask your question whenever you want. [31:02.230 --> 31:08.330] I was honored to be here at DEF CON 28 Package Hacking Village. I hope to present my research [31:08.330 --> 31:14.270] at that best hacking conference in the world next year again. I wish healthy days to everyone. [31:14.270 --> 31:15.950] Best regards. Goodbye.