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. Thank you very much. Good morning, everyone. Thank you for being here
with me. And, okay, let's start immediately. Speaking about the strange things for DEF CON
management, I want to say thank you very much to all of you for being here with me.
It's 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 reverse 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 the code. So
I like to write about security, regarding security tools, like, for example, volatility,
open canary, C2s, speakeasy, and also have a couple of main projects running, 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's a little bit of a
story. It sounds pretty weird in 2022 to speak about the C64 virus. And what made me decide 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 I had 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 assured 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 also 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. And so try to not to lose what we learned. And I think that's what I
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 virus which was
really illuminating and very, very interesting to do, this kind of exercise. And remember that
you are speaking about a few hundred bytes of software. Everything written back then about
viruses were more or less one kilobytes of software. This is particular. The reason why I'm
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 historical background about commerce 64, because maybe
nobody, not all of you knows what we are speaking about. And, okay, this is a picture of
commerce 64. In Italy, where I come from, it was called the 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, you know, it was the first home computer
born in 1982 together with Apple II and a lot of others. It was mainly 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. A virus, it's, let's say, a
program that, without user knowledge, tries 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 into going ahead and
understanding what we are speaking about today. Okay. Today, if we think about virus or malicious
software, we are thinking about something that is built to give a gain to the attacker. Mainly, we
are speaking about financial gain or gain of other type, like, I don't know, information investing
or something like that. Okay. So, let's start with that. So, let's start with that. Okay. So, let's
start with that. Okay. So, let's start with that. So, let's start with that where that, in any case, is
going to a 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 of technical knowledge, really, and not doing
something malicious to the user, but pranking people, maybe, or just show something that is, Okay, I
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 graphics, 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 skill set.
OK, let's start from the state of the art.
So which are the viruses known for Commerce 64?
This is the list, pretty much complete.
It sounds pretty funny if you look at it,
because we count seven entries here, which is more or less
what we can think it happens in a minute of malware creation
nowadays.
So it's really nice to see that there were so few viruses
back then.
And there are great analyses already done, most of them,
especially for BHP.
BHP.
BHP, which is the first one, and considered
to be the first viruses created for Commerce 64,
and one of the first viruses 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.
It's 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.
And 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,
are something to do static analysis, which is,
for example, the tool I used for static analysis,
Ghidra, a well-known tool, I'm sure that you know it,
with a specific plugin used to load this Commerce 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.
These 64 images are the files.
The files are representing a disk in Commerce 64.
Then I did also some dynamic analysis, obviously.
And I used the VICE emulator for doing that.
VICE emulator, it's an emulator which has also
a very nice debugger in it.
And then the master 315, which is an utility used
to manage these 64 images again.
Couple of screenshots about this.
And this is, for example, the screenshot from VICE,
which is the emulator I used.
I used for dynamic analysis.
As you can see on the bottom, you see the Commerce 64 screen.
And on the top, you see the debugger.
The debugger, it's very well done.
It allows you to step into the code, dumping memory,
dumping opcodes.
And there is also this little window on top right
showing you register.
And also, this window's showing computer and drive 8.
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 Ghidorah.
As I said, OK, this is a well-known tool.
So it was for static analysis, disassembly code.
It supports the Commerce 64 architecture, which is based on 6502 CPU.
It also compiled the code, but in this case, it's not useful to have the code compiled,
to be honest.
So I just looked at the raw assembly code.
Then here, we have the custom template I created for 010 editor.
And this is the custom template I created for 010 editor.
Which allows me to inspect the content of a disk of Commerce 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.
OK.
Let's now start in giving some details about our specimen, so the virus itself.
The virus, from what we know, exists in two variants, which are identified by a version,
which is a six-pot.
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
at them to do it or replicate the analysis or do something by yourself.
You can download it from csdb.dke site.
OK.
But before going into dictation, you need to set some common knowledge on Commerce 64
hardware.
Because it's very important.
You will see during the analysis that a lot of characteristics of the Commerce 64 will
be used in the code of the virus itself.
And let's start from the main CPU.
The main CPU of the Commerce 64 is the well-known 6510 CPU, which is based on 6502, which was
one of the first very cheap CPUs that were produced in the early 80s.
And probably, it's the CPU that gave the start to the home computer movement.
It's the CPU where used and on which 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 the case of Commerce 64, one had a clock of 4 megahertz, 64K of RAM, and 38 kilobytes
of program, for basic program.
Commerce 64 had a characteristic, a special one.
It had also some additional chipset.
It had a lot of things.
It was used for managing video and sound.
And that's why it became very popular for gaming, mainly.
But the main CPU, it's 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.
Okay.
They are still used according to the site.
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 Commerce 64 before, which was that keyboard with some, you know,
ports on that.
It doesn't have 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, unreliable.
It was really probably one of the worst pieces of hardware ever created in human history.
Really, I remember it as unusable, mostly.
And it was a 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, I 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, running codes, having
some memory, having some register, this is why I told you to have a look to the register
window before on the emulator debugger window.
Because actually you really have another CPU equal to the one installed on the main board.
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 offload some works on the CPU of the drive itself, it was not so easy because
the connection between the two systems...
Yeah.
The connection between the two systems 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 TurboLoader, 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 Boola 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...
And so we will go 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 it's pointing to the current instruction 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 0100 to
01FF, 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 slides here regarding the register 00 and 01, which are reported
by device simulator, 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 them in our analysis today, just reporting
these for completeness.
Okay.
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 STY, and LDY for the same operation with
other three registers.
It's like the move operation in Intel assembly, let's say.
Then we have another instruction, which is interesting for us, which is the JSR, which
is basically the same as the call in Intel architecture.
We close it usually by an RTS instruction, which is returning to the calling 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 we 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's a strange word.
It's coming from Commodore 64 era.
I don't know why.
What is Kernel?
It sounds like it has been misspelled, and actually, it was.
It's something like, probably, it was meant to be Kernel, with the E, not the A.
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 this memory area holds the code for the basic operation.
So let's say if I want to do a print, the code of the print is stored in this area,
and I call it directly.
Basically, 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, 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 happens when you start the virus.
Something strange, actually.
So you see this flashing screen here, and some gibberish printed out on the screen,
and then nothing happens.
So 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 details now.
So we will see with more details.
So what happens?
Doing this command, so running the program virus, is that a serial bus was opened 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 a serial bus?
So this serial bus has been opened.
There was an execution of a command.
Then there was this flashing screen, and then, of course, the bus has been closed.
So let's see what really happened here.
These are the set of instructions 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 codes, which are the codes actually
used to open the bus, the serial bus, to communicate with the CPU of this 154.3.
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-W, which stands for memory write, and sending this command, this character,
this ASCII character, or PET ASCII in this case, because Comma 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, I.O. 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 I.O. 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 is 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, obviously, because the virus doesn't reside anymore on the main memory.
And it's more persistent right now.
Because even if you 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 persistence on the code itself.
Yep.
Okay.
And so now the virus is 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 is U3.
It's another command coming from the ROM of the 1541.
Which except it just starts codes at the very specific address, which is 0500 on the disk
drive.
Since the set of instructions we saw before was transferring code to that address, we're
seeing that 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 this 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 executing 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 become 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 saves a file
or opens one or whatever.
Again, we need to set some other knowledge about the 1541, this drive structure and layout
before going ahead so that you will get the entire virus lifecycle.
Okay.
Disks were splitting tracks as of today, more or less.
So no difference with this.
Floppy disks.
Floppy disks had 35 tracks in them with different number of sectors for each track.
Obviously the smaller tracks, so 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 is a special track in the 1541 because it holds information about the disk and which
files are on the disk.
So it's the track 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 hexadecimal, has a special structure as
well.
Sectors 1 to 18 of the directory track contain the directory entries.
So all the files stored on the disk are listed in the directory.
And the special sector, the sector 0, the first one, 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 devices will use this information.
This is the structure of the sector 0, the BAM.
You see the first two bytes, which are holding some data that we are not interested in right
now.
Some generic data.
But what is interesting for us, it's the byte 4, which holds the number of free sectors
of track 1.
And then the subsequent three bytes holding the bit map 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 byte 8, the number of free tracks for sector 2, and then the bit map
of sector 2.
The bit map 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 0 of track 18.
Then you have sectors 1 to 18.
Sectors 1 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 pointing to the next one.
So when the first two bytes are zero, this means that this is the last file.
This is the file used by the disk itself.
Then you have, very important for our analysis, it's the bytes starting from 0-2.
So the third byte and the fourth and fifth byte.
Because they are holding the file type, which could be PRG, SEC, RIL, 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 Enviro itself.
Then there are some other information like obviously the file name, file size.
This structure is repeated for every single file into the Commodore 64 of the list of
files.
I told you that there are different file types in Commodore 64.
These are the known ones.
So PRG, SEC, RIL, USL, and DEL.
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 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 sequential, which are just byte strings.
Byte strings, yeah, so a way to access files
without random positioning.
RL1, which is a similar way to access files,
but with actually the possibility
to position the pointer in the file itself.
Then USR, which is a user-defined one.
And OK, that one, which is undocumented one.
Comma64 also had a basic integrity file system.
And so you have.
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, OK, we said 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.
The program waiting for disk activity, remember.
When disk activity is recognized, OK,
there is a start of a specific function, which is the 600.
This function, which is residing on the 1541,
do a very specific thing.
So it starts to find the first free block where on track 18.
So on track 12 in hexadecimal.
So.
That means the virus is not trying to store itself in a file.
It is trying to store itself in the directory structure, which
is something that 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 free blocks there.
OK, this is just the way of doing that, looping from.
In the BAM, so it loads the BAM.
You see the block 0 here.
And then starts looping and looking for free 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.
Comma64 disks were not known 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 track 18
were actually not used at all.
And so.
It's very likely to have them free.
And so the virus is trying just to check if these three blocks
are free, actually.
And if not, it 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 actually the code of the virus itself,
it has been holding three sectors.
It marked them as used into the bitmap.
So it does not write the code again.
And still, but it just marked the sector as used.
OK.
Now, the virus itself just found a way to, OK,
it can store its code on the disk,
but it's not sure yet if it can be re-executed.
Because actually, the virus itself
wants to be re-executed in order to infect another system,
another disk.
And so it starts another loop, looking for,
for a PRG file.
We said before, the 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 very end
of the, I don't know if I can point it.
Yeah.
There, it compared the file type.
And it looks for the PRG one.
When it found it, it start the real infection.
OK.
The infection phase.
Until then, it doesn't.
So what happens is that, OK, I found the PRG file there.
And so I want to start the infection process.
What does the infection process?
It just gets the very first pointer 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 holding some code.
And so it just moves this pointer to the track itself.
And in this way, it just basically
tries to be re-executed when the user just loads the file.
There is an additional check.
So the virus will also check if the file is already infected.
So if it finds that the PRG file is pointing already
to track 18, which is basically impossible in a normal situation,
it just keeps the file.
And OK, it says, OK, probably, it's already infected.
So you can see that there are also error checkings.
And so nothing is left to random things.
So it's really something that is well done in this case.
So it's now time to infect the file.
The virus 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 saved 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 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 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, OK, when there is a disk activity,
track 18 has three free blocks, yes.
If yes, it starts.
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 renames the disk to Boola rules
and it exit because, OK, it's just not
trying to do something harmful or doing something
bad to the system itself, but just exit, just renaming
the disk.
The disk itself with a new name.
OK, I promised you that we were going 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 OK, the two versions are very similar.
The only difference between the two
are the loading of the version 8.
It's a bit sturdier, so you don't have the flashing screen.
And it also hooks the save command.
So.
And hooking in comma 64 was pretty trivial to obtain,
because addresses for the routings
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, it's just got the computer itself reset.
And then so everything is clean.
It's all set up.
But you still have, at this point,
the virus is residing on the CPU of the 1541 device.
OK, I published some tools, because this exercise was
done through several tools.
But I also built my own tools for doing this analysis.
I hope maybe you can find them useful also
to do some other analysis about virus malware, or maybe just,
of course, 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
disk images of the comma 64.
It's self.
Then I created a couple of GIDRA scripts
in order to mapping the code.
As I said to you, the analyzer was the GIDRA analyzer,
was also the compiling, but I mostly used assembly
in this case.
And these scripts are just mapping, for example,
all the kernel and ROM calls for comma 64
into the source of the assembly code,
just adding comments on what the call 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 command we saw, the U3 command we saw, and so on.
I also published the two database of the GIDRA database
I created.
These are two databases.
Everything is heavily commented, as you can see here.
These are the complete analysis of the two virus sample.
For example, you can open it with your GIDRA
and have a look to it if you want.
They will be available on the GitHub 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.
OK, 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 this virus, for sure.
But it was, in any case, interesting, too.
And I wanted to complete this knowledge,
because it was really helpful for me as a reverse engineer.
And I'll tell you also why.
OK, as I said, the scripting together
with the fully commented GITAR database
are available on my GitHub.
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 I'm a reverse engineer.
And I'm a reverse engineer.
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, OK, for example,
few assembly instructions does not mean
that we have few functionality.
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 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,
is 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.
They were 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, OK,
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, this is 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 proficiencies
opens a lot of doors.
I tend to see that assembly is a bit, let's say,
a forgot language.
So it's not teached 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.
So from my point of view, for example,
in this kind of analysis, I didn't know the 6502
architecture.
I learned in doing these analyses 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 OK, 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 is credited in the proper way.
And OK, so I think that I'm at the end of my presentation.
So I just want to say thank you to everyone here.
And for staying with me for the entire presentation.
And if any question, maybe we still have some minutes.
I don't know.
Five minutes.
I don't know if any of you have a question or something.
OK.
Let's go back.
The hook.
The light, the light, the light.
Light, the light, the light.
Oh, sorry.
I'm not sure if you say the removal of the hook itself.
Yeah, 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 is 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 is brought back to the original state.
Thank you.
Thank you.
So would you say that because this chip is still being made into a super product,
that you're looking at a potential vector of writing malware to save the system
and build off of the old architecture in modern devices, Internet of Things devices?
Yeah, I think so.
Let's say that, okay, it's not just a matter of design.
It's CPU, obviously.
But, okay, this is obviously a CPU that is still used,
so you can apply the same concepts that we saw today.
Probably not all the same concepts, 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, the roadmap isn't that we want to use the same.
Yeah, yeah, yeah, yeah, that's exactly the same.
Yeah.
Okay, thank you so much.
Thank you, really.
Thank you.