 Welcome to DEF CON. How many first timers? Raise your hands. All right. Good amount. Good amount. So I guess everybody is here for the 10 a.m. old malware new tools on the Commodore 64. So we have Cesar here to our left. Welcome to me. He's a first time speaker. So everybody knows what that means. Yes it does. Good morning and let's have Cesar kick it off. Good morning, everyone. Thank you for being here with me. And okay, let's start immediately. Speaking about the strange things for DEF CON maybe, something like coming from the past. But I think that it makes sense, especially for this ER team. Let's speak about me for a second, but just for a few slides, for one slide. My name is Cesar Pizzi. I work, my main job is service engineer. So I spend most of my time looking at other codes. But sometimes I also try to write something for the community. And I like a lot, for example, to write software always about security regarding security tools, like for example, volatility, open canary, C2s, Spikyzi, and also have a couple of main projects running Seenwall and Resplate, which are entirely done by me. If you want to reach me out, you can obviously reach me on Twitter or on GitHub, open an issue, just get in touch with me. I will be more than happy to speak with you about everything about security. But okay, let's start with the why. It sounds pretty weird on 2022 to speak about the common 64 viruses. And what made me decide to do this? To do this was this picture coming from the DEF CON 30 team. I don't know, something went in my mind when I saw it. I decided to do something like try to bring my knowledge that I have today back with something that I was using when I was a child, for example, but be sure that this is not a talk about, it's not a nostalgic talk, it's not something about okay, the good old days, because that's not my way of approaching things. I want to report another sentence that is coming from the DEF CON 30 team. And so that's exactly what this talk is about. So trying to move what was interesting in the past into the future. So try not to lose what we learned in the past and try to keep it and make experience about it. So also doing this, I also realized that there were a lot more. Like for example, I saw this kind of viruses which was really illuminating and very, very interesting to do, this kind of exercise. And remember that we are speaking about few hundred bytes of software. Everything written back then about viruses were more or less one kilobytes of software. This is particular that we are looking at today, it's in 700 bytes. And we will see that there will be a lot of things done in 700 bytes. Okay, let's set some common background about Comer 64, because maybe nobody, not all of you know what we are speaking about. And okay, this is a picture of Comer 64 in Italy, where I come from. It was called a big biscuit because of the shape and the color of the chassis. I don't know if it's the same in other countries as well, but that was the way. And it was one of the first home computer that born in 1982, together with Apple II and a lot of others. It was mainly based for, used for gaming actually, because of several reasons. But viruses were a thing back then. And so they were existing, but it was very different from the current reality. Okay, let's start in defining a virus before going ahead, so that we are all on the same page. Okay, virus, it's a, let's say a kind of a program that without user knowledge try to persist and replicate. I'm sure that this is not a 100% fitting definition, but it's a good starting point for all of us to going ahead and understanding what we are speaking about today. Okay, today if we think about virus or Mauritius software, we are thinking about something that is built to give again to the talker. Mainly we are speaking about financial gain or gain of other type, like I don't know, information harvesting or something like that in any case is going to financial gain at the end. But if we think about the situation back then, it was a completely different thing, because there were no financial motivation behind the virus, but it was something more done for show off technical knowledge really, and not doing something malicious to the user, but pranking people maybe, or just show something that is, okay, I can do it, so I can show you that I can do it, but I don't want to harm you or whatever else. And that's the reason why I tend to define this more close to the demo scene back then. So the demo scene was the way of showing the skills of a programmer doing graphic sounds and so on. And in some way viruses were something like that done for showing the low level technical expertise, let's say. And you may think that the lack of financial gain behind this may go to some name code, a few functionalities or something written very badly, but it's not the case. We will see together that these tiny programs are really little jewels of programming and technical skillset. Okay, let's start from the state of the art. So which are the viruses known for Commer 64? This is the list, pretty much complete. It sounds pretty funny if you look at it, because we have, we count seven entries here, which is more or less what we can think it's happens in a minute of malware creation nowadays. So it's really nice to see that there were so many, so few viruses back then. And there are great analysis already done on most of them, especially for BHP, which is the first one, and considered to be the first virus is created for Commer 64 and one of the first virus ever created. But there is one which is not analyzed yet. It's the Bula virus. The only thing, it was in the list we saw before here, it was the fourth one. And the only thing that I found around before starting this kind of analysis was this little sentence coming from wiki.com saying that nothing was really known about this virus. And there were some things happening when you run it, but it was not clear how it was replicating and so on. And so I decided to get this one. In order to try to get this back to life, I obviously used some tools and some things to having it running again. And these tools, we are going to list them right now, are something to do static analysis, which is, for example, the tool I use for static analysis Ghidra, a well-known tool, I'm sure that you know it, with a specific plugin used to load the Commer 64 virus. I did some custom scripting for analyzing the virus itself with Java and the plugins of Ghidra itself. I also created a 010 editor custom template in order to be able to analyze the disk images. The 64 images are the files representing a disk in Commer 64. Then I did also some dynamic analysis, obviously, and I used the vise emulator for doing that. Vise emulator, it's an emulator which has also a very nice debugger in it, and then you'll master 3.1.5 which is an utility used to manage the 64 images again. A couple of screenshots about this, and this is, for example, the screenshot from vise, which is the emulator I used for dynamic analysis. As you can see on the bottom, you see the Commer 64 screen, and on the top, you see the debugger. The debugger is very well done. It allows you to step into the code, dumping memory, dumping op codes, and there is also this little window on top right showing your register and also these windows showing computer and drive aid. Remember this because it will be very important for our analysis. So it looks like we don't have a register just only on the main CPU, and that's important to remember for our analysis here. Then I used Ghidra, as I said, okay, this is a well-known tool, so it was for static analysis, it's assembly code, it supports the Commer 64 architecture which is based on 6502 CPU. It also decompiled the code, but in this case it's not useful to have the code decompiled, to be honest. So I just looked at the raw assembly code. Then here we have the custom template I created for 010 editor, which allows me to inspect the content of a disc of Commer 64. I'm going to release this template, I already released it this morning, and I will give you some more details at the end of the presentation about it. Okay, let's now start in giving some details about our specimen, so our virus itself. The virus from what we know exists in two variants which are identified by a version, which is 6.13 and 8.32, so we have also major release for that, and both of them are available to download if you want to, I don't know, have a look to them, to tweet or replicate the analysis or doing something by yourself, you can download it from csdbe.dk site. Okay, but before going into details, we need to set some common knowledge on Commer 64 hardware, because it's very important. You will see during the analysis that a lot of characteristics of the Commer 64 will be used in the code of the virus itself. And let's start from the main CPU. The main CPU of the Commer 64 is the well-known 6510 CPU, which is based on 6502, which was one of the first very cheap CPU that were produced in early 80s, and probably it's the CPU that gave the start to the home computer movement. It's the CPU were used and on which it's based, were based most of the home computer back then, Apple II, Atari, Commodore, and a lot of others. So it was a very cheap CPU doing a lot of things. In case of Commer 64 one, we had a clock of 1 MHz, 64K of RAM, and 48 kilobytes of for program, for a basic program. Commer 64 had a characteristic, a special one, had also some additional chipsets for managing video and sound, and that's why it became very popular for gaming mainly. But the main CPU is exactly the same as all the other home computer at the time. What it is interesting is that, and I learned it doing this research, is that it's still used. You can actually buy one if you want from this site. The form factor is a bit different right now, as you can see, but the 6502 and other variants of the CPU are still existing, are still used, according to the site, and so that's why I'm saying you are not wasting your time this morning looking at this presentation, because you are going to learn something very interesting like basics on 6502 assembly that we can use maybe on your next automotive project, I don't know if you want to use the 6502 CPU. And okay, let's spend a couple of words about mass storage. You see that picture of Commer 64 before, which was that keyboard with some ports on that. It doesn't any kind of mass storage in it, so the mass storage back then was done in two ways, mainly. The cheap one was a tape player, which is awful, slow, reliable. It was really probably one of the worst piece of hardware ever created in human history. Really, I remember it as unusable, mostly, and it was the cheap solution, so that's what I bought for the first time. And then when you start to save some money you can buy another piece of hardware, which is a bit better. It's not really a great hardware as well, but it's a lot better than the tape, which was a disk drive, reading the floppy disk, the five inches floppy disk you don't know if you ever saw it, the black one, the floppy one, exactly. And why I'm mentioning this hardware? Because it's a little less known that the 1541 disk drive had exactly another 6502 CPU in it, a running code, having some memory, having some register. This is why I told you to have a look to the register window before on the emulator, the bugger window, because actually you really have another CPU equal to the one installed on the mainboard. That means that you, in some way, you had a multiprocessor system back then in 1982, because the two CPU can actually communicate between them and they can transfer code between them and execute code at the same time. So it was pretty surprising to understand that you actually had a multiprocessor system with the main CPU and the one running on the drive. You can also upload some works on the CPU of the drive itself. It was not so easy because the connection between the two system was done through a serial bus, so it was slow and so on, but it was actually usable and it was used also by legit software, let's say, like Turbo Loader, which were programmed to load things and so on. And guess what? Yes, this can be abused by viruses as well and this is actually what the Bula virus is going to do, and we will see how in a while. But before going into the details, I promised you a crash course of assembly of 6502 assembly and so we will go very, very briefly. It's a crash course of two slides, so don't be afraid about it. Let's have a look on how it actually works. So we have a few registers in the CPU, a lot less than what we expect from current architectures like the Intel one, let's say, where we have a lot of them, and we have basically a program counter which is more or less the same as the instruction AP of the Intel architecture and is pointing to the current instruction of the of the processor. And then three general purpose registers. One is the A, which stands for accumulator, and you can store values in it. And then X and Y, which are indexing registers. So these are three general purpose registers you can use in your programs. And that's all, what you have. You have also some stack pointer pointing to a fixed memory region, going from 1.0.1.0.0.2.1. And then a flag status which holds the results of comparisons, carry and so on. So very basic structure, very simple one, but you can see that you can do a lot of things with this. I'm adding also these lights here regarding the registers 0.0.1, which are reported by device emulator because these are out of our scope today. They are registered for the sound interface device, which was one of the chip I mentioned before used for doing sounds, but we don't need our analysis today just reporting these because of for completeness. And so, very basic crash course about assembly. So we can basically do some things with the register. We can store values there and load values from the register themselves. So the instructions are pretty simple. It's a very, very simple instruction set on the 6502. And you have LDA to load a value in the accumulator, so you can put a value there. You can put an immediate value by putting a dash before it or you can reference a memory address. And the opposite way, you can also store the value that is in the accumulator into memory. So you have LDA and STA. At the same time, you have LDX, STX and LD and STY and LDY for the same operation with other registers. It's like the move operation in TURL assembly, let's say. Then we have another instruction, which is interesting for us, which is the JSR, which is the basically the same as the call in Intel architecture, with closely used by an RTS instruction, which is returning to the call in function. And then, obviously, we have also some branching instructions, so you can jump around basically on the results of several operations and so on. So you have this set of instructions here, BPL, BMI, BVC and so on. Couple of slides, then we can jump into the virus itself. So, kernel, that strange word, it's coming from Commodore 64 era. What is kernel? It sounds like it has been bespelled and actually it was. It's something like, probably it was meant to be kernel with E, not DA. And this is the Commodore 64 ROM resident operating system call. So you can call some routings doing basic operation by calling a specific memory address. Compared to the modern, I put some quotes here, PC world, it's something like the BIOS OS routing you have, we have in current PC more or less. So we have this way to call basic and low level kernel calls. And then we have another way of calling more higher level routings, which are the basic one, which are stored from A00 to BFFF. And these memory areas hold the code for the basic operation. So, let's say, if you want, I want to do a print, the code of the print is stored in this area and I call it directly by calling the memory area instead of writing print in my basic program. And that's a way of doing things in Commodore 64. But let's start now with our analysis. So the Bula virus, which we saw before that it has been, it's one of the few viruses remained which were not analyzed yet. Okay, we need to obviously start it in some way. Remember, okay, I said before the virus never dies, so it's just a matter of giving him the right environment and it starts again. And the right environment, in our case, is the emulator, obviously. And this is what happened when you start the virus. Something strange, actually. So you see this flashing screen here and some gibberish printed out on the screen, which is, and then nothing happens. So it looks like really nothing has been done to the user. But what happened behind the scene in this case? So let's start with some code snippets. Okay, this is written really tiny here, but don't worry, I will go into the details now. So we'll see with more detail. So what happens doing this common, so running the program virus, is that the serial bus was open on the device. So remember that I spoke that the two processors between CPU, the main CPU and the one on the disk drive communicate between serial bus. So this serial bus has been opened. There was an execution of a command. Then there was this flashing screen and then the bus has been closed. So let's see what really happened here. These are the set of instruction opening the serial bus. As you can see, there are a JSR and a jump instruction point to the kernel. Do you remember the addresses beginning with FF? So these jump and JSR are pointing to two kernel calls, which are the calls actually used to open the bus, the serial bus, to communicate with the CPU of this 1541. And then there is the execution of a command. The execution of a command is simply sending a couple of characters, three characters in this case, m dash w, which stands for memory write, and sending these commands, these characters, these ASCII characters, or PETASCII in this case, because command 64 had a custom ASCII code. Sending this and some codes, what happened is that some codes from the main CPU is transferred to the memory of the disk drive in this case. So what the virus is doing right now is just getting its code and transferring it on the CPU drive. Then there is the flashing screen and the closing. Why the flashing screen? Back then IO operations were really slow and you were sometimes really looking at the screen trying to understand if something was happening or not. And the flashing screen was a way, a trick, used to let the user know that something was happening during the IO operation. So that's why it has been added probably in this case. So just to let the user know that something was happening. And then, okay, the serial bus just closed. So at this point, what has been done is that the virus code has been transferred on the CPU of the floppy, but nothing else. So the code has not been executed yet. Why this has been done for two reasons, maybe, because in this way it's still here, obviously, because the virus doesn't reside anymore on the main memory. And it's more persistent right now because even if power off or reset the Commodore 64, actually until you don't power off the drive, the virus still resides there and it's not going away. So that's a neat way to gain persistent on the call itself. Yep. And so now the virus it's on this drive memory. Okay, it's time to execute it. Just to execute it, it's just a matter of sending another command like the MW we saw before. The command it's U3. It's another command coming from the ROM of the 1541, which exactly just start codes at a very specific address, which is 0500 on the disk drive. Since the set of instruction we saw before was transferring code to that address, the U3 command is just executing code residing there. So what happens here, again, snippets and we are going into the details, is that the serial bus is open again. There is a U3 command sent on the serial bus and that means that the code starts. So the virus itself is starting on the disk drive memory. There was a set of commands U3 from U9 executing code at different addresses from 0500 to FF01. It was just a matter of what you want to do and execute in this case. And what happens meanwhile on the 1541, obviously there is some code landing at 0500 where you have the code waiting for something. And there is just this tiny loop here which is just waiting for something. It's waiting for an attention signal to becoming low. That means that it's waiting for this activity. So the virus has transferred the code on the drive and it's just waiting for something to happen. If the user accesses the file or save a file or open one or whatever. Again, we need to set some other knowledge about the 1541 disk drive structure and layout before going ahead so that you will get the entire virus life cycle. OK, disks were splitting tracks as today more or less. So no difference in this. Floppy disks had 35 tracks in them with different number of sectors for each track. Obviously the smaller tracks or the internal one were smaller and so they had fewer sectors than the external one with fewer storage capacity obviously. One interesting track is track 18. Track 18 it's a special truck in special truck in the 1541 because it holds the information about the disk and which files are on the disk. So it's the truck holding the directory. It's like the MFT and bit mapping and TFS more or less. So holding all the information about the disk. And the special track 18 which is also 12 in X decimal has a special structure as well. Sectors one to 18 of the directory track contain the directory entries. So all the files stored on the disks are listed in these sectors. And there is a special sector, the sector zero, the very first one which is the BAM, the block availability map which holds the information about the free and used blocks on the disk itself. Which is very important because we will see that the virus will use this information. This is the structure of the sector zero, the BAM. Okay, you see the first two bytes which are holding some data that we are not interested in them right now. So some generic data but what is interesting for us it's the byte four which holds the number of free sectors of track one and then the subsequent three bytes holding the bitmap of free sectors on the first track. And then this structure is repeated again and again and again for all the tracks of the disk. So you have the at byte eight the number of free tracks for sector two and then the bitmap of sector two the bitmap is just a set of one or zero saying which blocks are used and which aren't. Then all the other so this is for the sector zero of track 18. Then you have sectors one to 18. Sectors one to 18 are holding the files. There is this kind of structure repeated for each file and with this specific structure here. You see that the first two bytes are pointed to the next one. So when the first two bytes are zero this means that this is the last file used by the disk itself. Then you have very important for our analysis it's the byte starting from zero to so the third byte and the fourth and fifth byte because they are holding the file type which could be PRG, Sec, Reel or USL and the track and sector number of the first block of the file. Remember this because we will see that it will be used by itself. Then there are some other information like obviously the file name, file size and so on. This structure is repeated for every single file into the comma 64 of the list of files. I told you that there are different file types in comma 64. These are the known one so PRG, Sec, Reel, USL and L. PRG is what is interesting for us. PRG is the executable files. It's like the executable in the modern PC so it holds code that can be loaded into memory and the first two bytes of the file itself are the address to where the program itself must be loaded. This is what it actually executes code. Then we have also other type of files which are less interesting for our analysis but let's just have a quick look to them. We have a sequential which are just byte streams. A way to access files without random positioning. A Reel one which is a similar way to access files but with actually the possibility to position the pointer in the file itself. Then USL which is a user defined one and okay that one which is undocumented one. Comma 64 also had a basic integrity file system and so you had to close the file before removing the disk and you had also the possibility to have a star before the type of the file if the file has not been closed in the proper way. Now okay we set this knowledge we know now that which are the information we need to understand what happens now and let's start to see what happens when we try to infect the program starts to infect the program itself. So we left the program waiting for this activity to remember. When this activity is recognized okay there is a start of a specific function which is the 600600 this function which is residing on the 1541 do a very specific thing. So it starts to find the first three blocks where on track 18 so on track 12 in hexadecimal. So that means the virus it's not trying to store itself in a file it's trying to store itself in the directory structure which is something that it should not be done because the directory structure just holds file information not the file itself. And so it starts counting from the very end of the track itself and try to find three blocks there. Okay this is just the way of doing that it's looping from in the BAM so it loads the BAM you see the block zero here and then starts looping and looking for three sectors at the end of the file. Why it starts from the end of the track 18 because it's more likely to have them free. Commodore 64 this were not known to be to hold hundreds of files probably most of them had I don't know 10, 20 files. And so usually the last three blocks of the trachetin were actually not used at all. And so it's very likely to have them free. And so the virus it's trying just to check if these three blocks are free actually. And if not just try to move it and look for the one going through the beginning of the file. And it does it through this loop here. When it detects three sectors why three because the actually the code of the virus itself it's old it has been old in three sectors. It mark them as used into the bitmap. So it does not write the code again still but it just mark it mark the sector as used. Okay now the virus itself just found a way to okay it can stores its code on the disk but it's not sure yet if it can be reexecuted because actually the virus itself want to be executed in order to infect another system another disk. And so it starts another loop looking for PRG file. We said before that PRG files were the executable one and so it starts a loop to look for this kind of file. You can see here that it loads the first sector and then tries to compare for example you see that it's comparing the at the very end of the I don't know if I can point it yeah. There it compare the file type and it looks for the PRG one. When it found it it start the real infection phase. Until then it doesn't. So what happens is that okay I found a PRG file there and so I want to start the infection process. What does the infection process? It just get the very first pointer of the of the program of the PRG file and it makes it pointing to the track 18. So usually probably the pointer of the file is just pointing to another track not the track 18 because track 18 is not meant to be to holding some codes. And so it just moved this pointer to the track itself and in this way it just basically try to get be try to be reexecuted when the user just load the file. There is an additional check so the device also check if the file is already infected. So if it find that the PRG file is pointing already to track 18 which is basically impossible in a normal situation it just keep the file and okay it says okay probably it's already infected. So you can see that there is there are also error checkings and so nothing is left to the with two random things so it's really something that is well done in this case. So it's now time to infect the file. You the device itself it's just getting the track number for the file itself. It's replacing the track and sector number obviously. It replaced the values with the track and sector. Track will be 18 for sure. Sector will be the sector where it saves the three blocks. It replaced them so that the PRG file will point to that. And then it also makes the very last block of the of the virus itself pointing back again to the PRG file so that the execution of the PRG is kept and the user maybe does not realize that there was an infection. This is not this is not really working every time but it actually worked. So let's look up what actually the infection process is. So we had as we remember the on disk activity the loop waiting for on disk activity then okay when there is a disk activity track it in has three blocks. Yes. If yes it starts the infection process if not just exit. If the PRG file then if the three blocks are free and a PRG file is found it starts the infection process. If the PRG file is not found it does something like let's say plan B. It just renamed the disk to Bula Rules and it exit because okay it just not trying to do something harmful or doing something back to the system itself but just exit just renaming the disk itself with a new name. Okay I promised you that we were going through through the two versions of the virus basically the two versions were very similar. I don't know why there were two major release between them but okay the two versions are very similar the only difference between the two are the okay the loading of the version 8 it's a bit stiltier so you don't have the the flashing screen and it also hooks the safe command so hooking in common 64 you'll speed it trivial trivial to obtain because addresses for the routing are saved on 0300203FF so it's just a matter of replacing that addresses with a new one to redirect a command. In this case the version 8 is replacing the save vector with a reset vector so that if the user is typing save to save something just got the computer itself and then so everything is screened up but you still have at this point the virus is residing on the code of the sorry on the CPU of the 1541 device. Okay I published some tools because this exercise was done through several tools but I also built my own tools for doing these analysis I hope maybe you can find them useful also to do some other analysis about virus malware or maybe just other programs. This is the 010 template editor editor template which has been built to read and analyze the disk structure. As you can see you can analyze on the bottom side here the structure for example of the BAM of the directory showing up which is the bitmap of each blocks and so on. So it helped me to analyze what the virus was doing and it pretty neat to use for analyzing the mismages of the Commodore 64 itself. Then I created a couple of GIDRA scripts in order to mapping the code. As I said you the analyzer was the GIDRA analyzer was also the compiling but I mostly use assembly in this case and these scripts are just mapping for example all the kernel and ROM calls for Commodore 64 into the source of the assembly code just adding comments on what the code is doing so it allows you to streamline your analysis of the code if you apply these kind of scripts on your analysis for example and the same has been done for the 1541 ROM calls because 1541 had its additional ROM calls the MW common we saw, the U3 common we saw and so on. I'm also published the two database of the GIDRA database I created. These are two database everything is heavily commented as you can see here these are the complete analysis of the two virus sample you can open it with your GIDRA and have a look to it if you want they will be available on the GITAB as well. So just for reference if you want to have a look and let's jump to the conclusion so why I decided to do this talk today with you. Okay we are at the end and we saw that the fully functional malicious code can be put in 700 bytes. We saw that this was a virus that was completely functional with a lot of functions with everything done in the proper way replication persistence even some really nice things like moving itself on different devices and so on. So the techniques used by the virus were not new because they were used by legit software as well so they were not discovered by these viruses for sure but it was in any case interesting to complete this analysis because it was really helpful for me as a reverse engineer and I'll tell you also why. Okay as I said the scripting together with the fully commented GIDRA database are available on my GITAB and you can download them and have a look if you want and let's have a look on what we learned or what I learned and I hope you learned as well because that's the real core of the talk from my point of view. As I said I'm a reverse engineer and from a reverse engineer point of view what I learned or let's say recalled because sometimes it's just a matter of recalling things not really learning but sometimes you tend to forget some things. With this analysis that okay for example few assembly structure does not mean that we have few functionalities. We saw 700 bytes software doing a lot of things like replicating, writing, checking for errors which is not really something that you can give for done even if higher level program so that's something that you have to consider and that's really interesting for us as a reverse engineering so it does not mean that a small program is doing few things. Then the other important things that I'm sure I tend to forget and I think it's a gray area in the malware analysis nowadays it's that we don't have to forget external devices when we are looking at malicious software. In this case we saw that we had two CPUs running on two different devices of the computer itself. Right now think about how many chips you have in a modern computer. I'm sure that you can tell me that okay but these are not executing code or you cannot access directly, yeah true but you have device drivers accessing these kind of things and think about it, think about the thing that you may misuse a device driver in order to I don't know execute code, write code, store code somewhere where we are not expected, we don't expect to see it. We have a lot of additional things in our systems right now and so far from what I think is that this is a kind of a gray area it's not really explored from what regards the malicious software and so something we need to take into consideration. And then the first thing I learned and I would like also to pass to you it's that the assembly proficiency opens a lot of doors. I tend to see that assembly it's a bit, let's say I forgot the language so it's not teach it anymore, nobody is caring about it. I'm not saying here that you have to write your next word processor in assembly which is not the case obviously and probably you don't need to write anything in assembly in most of the case. But it's very important from my point of view that everybody working in security knows assembly and knows in a proper way because this really opens a lot of doors. From my point of view, for example in this kind of analysis I didn't know the 6502 architecture I learned in doing this analysis together with you this morning and the fact that I had knowledge of Intel assembly or ARM assembly really streamlined for me the analysis of this simple architecture. So that's something that we need to keep into consideration also when we think about studies of new people coming into security fields and so on. We don't have to forget that the assembly language it's very important for our purposes. And okay, so these are all the references for what I used and what I was speaking about today. I want to leave these slides some seconds so that everybody's accredited in the proper way. And okay, so I think that at the end of my presentation so I just want to say thank you to everyone here for staying with me for the entire presentation and if any question, maybe we have some minutes I don't know, five minutes I don't know if any of you have a question or something. Okay. I'm sorry. I'm not sure if you say the removal of the hook itself. The removal process is just done by the reset itself. So when you reset the memory everything is brought back to the original state. So the save it's just replaced with the correct address. So when you type save and you replace the vector the Commodore 64 has been reset but everything then it's bringing back to the original state. Thank you. Oh, yeah. Yeah, I think so. Let's say that, okay. It's not just a matter of this CPU obviously but okay, this is obviously a CPU that is still used so you can apply the same concept that we saw today probably not all this concept because some of the concepts we saw together were really specific to Commodore 64 architecture but all the rest of the things like the assembly code and so on it's exactly the same. Yeah, yeah, yeah, yeah, that's exactly the same. Okay, thank you so much. Thank you, really.