 Thank you so much. Thank you. That was awesome. That was amazing. So speaking of completely ridiculous things, we're going to talk about some stuff here that isn't something that you're likely going to be doing at work, but it may be something that you do to pick up some skills that you could use at work or that you could use when you're thinking about something else. And so this talk, we're going to be looking at historical software. We're going to be looking at software from decades ago, the early 90s, late 80s, looking at software for the Commodore Amiga, so the 16-bit system, not as maybe popular here in the U.S. as it was in Europe for home use, but still a very interesting system, a very unique system among retro systems. This being one of the first systems where C was a first-class language, one of the first systems where you had a multi-tasking operating system, one of the first systems where you had a TCP IP stack that wasn't a PC, right? And so the idea of this is we're going to be using vintage computing platforms as a playground, somewhere where we learn about vulnerability research, where we learn about exploiting things in an environment that's fun, that sort of tickles some of the interest that people have in retro computing in general, which I have. So there's a large interest right now in vintage and retro computing systems. There's tons of YouTube channels, there's lots of people on Twitter who collect hardware, who look at software, who are dedicated to either preserving the stuff, restoring things. We're always talking about clipping out the bad batteries and cleaning up the acid leaks that those batteries do to the motherboards, collecting versions of software that have previously thought to have been lost, looking at documentation and making sure that people can remember this because there's a large body, a huge body of software written in the 80s and 90s that's not in current active use, but somebody wrote it. Somebody spent months or years of their life putting that code together, and it's interesting to look at that. It's interesting to see where their time and their efforts went, because that stuff is what modern software is built on top of, even if it's not straight from the source code. It's the stuff that we used before we started writing our software. So there's an overlap of an interest of hackers with this. There's lots of hackers in the infosec community that are also in the retro industry. And even if you are on a shoestring budget and you can't pay the skyrocketing eBay prices for this sort of equipment, you can build a nice collection and a nice environment for doing research in this area in just a few gigabytes of space. So with off of archive.org, you can grab all the old documentation you want, all the documentation you need. I love reading old computer books. That's basically what I use my iPad for, just downloading tons of PDFs from archive.org old programming manuals and computer science textbooks and technical manuals and such. There's archives of all the preserved free and commercial software for these things, things that have been abandoned. And so a combination of documentation and disk images for all the software you can, for example, for the Commodore Amiga that we're looking for, you can have a complete set of everything there ever was for it essentially on a thumb drive. And for me, that's fascinating. So I grew up using a Commodore 64, the 8-bit system that came before the Amiga. And, you know, I had a large collection of floppy disks acquired from various sources, BBSs and copies and things like that. So I probably had a few hundred disks and everything growing up that I just love just going through and seeing what was there and exploring. And now you can go back and do that and have that sort of nostalgia hit if that's your thing, right? And just explore old disk images and see what you can find and see that work that people put into things. You can set up emulated environments and things that had hardware that you couldn't afford back then. It was very expensive to buy hard drives for these things. It was very expensive to buy memory expansions and things like that. But in an emulated environment, it's all free. You just sort of click the button and add it in. There's lots of modern hardware add-ons that we're going to talk about for this particular platform. And so the question is, is all this is nice for nostalgia? We can leverage these archives and these efforts to create these environments that make it easy and fun to just tinker around with the stuff. But we can also use it to teach, right? And so in a modern computing environment in like a 64-bit Intel system, there are so many exploit mitigations in place. We started with smashing the stack in the mid-90s. And we've solved, not solved, but we made it harder to exploit that by having non-executable stacks and stack cookies and address-based layout randomization and all sorts of various things that make it harder and harder to write exploits. But the problem with that is very difficult to just turn on a 64-bit Intel system and start learning how to write exploits or start learning how to reverse engineer programs when all that stuff's in the way. And so you'll see that most tutorials have some mechanism for turning those off on modern operating systems. There's a lot of steps and it creates an environment that's okay to tinker around with, but maybe it's not the most authentic environment, right? Whereas if we look at it, it's something like the Commodore Amiga and code for it. You know, what we're looking at is a lot of code that was written in C using TCPIP networking, but predates the publication of smashing the stack for front-end profit and frack by over a year. So tons of code written before really most people had a concept of what it meant to try to defend against these. You know, back then we knew, you know, if we have a variable in memory that we're trying to stuff data into, we knew that C wouldn't keep us from writing over the end, though, and we knew it would crash if we did that. But, you know, maybe not everybody had put together the consequences of that in a networked environment where anybody can stuff that buffer for you. And so really another thing that was interesting for me, I started giving presentations at DEF CON 19. That was the first time I gave a talk and I've given several since. You know, I've presented research that I've done at universities and things like that. A lot of the research I do now is under NDA. A lot of the stuff is stuff that I wish I could tell you about and maybe one day I hope I can, but I can't right now. But this is something that's fun. It's fun for hacking sake and I think it's something that you can learn from and it's not covered by a non-disclosure agreement. The potential benefits of this, if you're going to be getting into this sort of stuff like looking at old software with a view for vulnerability research, it's an environment for exploring the insides of software that belongs to computing history. You've got a comprehensive availability of emulation, documentation, preserved software archives. You can have a wholly self-contained environment for doing this research in a very small amount of space and with very easy to use tools. Most of the emulators that for all these old systems have pretty nice debuggers built into them because the emulation developers need those debuggers to make sure that the code of the operating system and the software running on top of it is actually something that's being executed authentically and so they need good debuggers and so there's usually a good debugger in there. And when UAE, which is what we're going to be using for Amiga stuff in this talk, is something that has a very nice debugger built into it. And so emulating software that predates modern awareness of security vulnerabilities and mitigations that gives students of offensive security research, people who want to learn how to break things, how to hack things. There's nothing wrong with that. You know, you don't have to go blue team. You can enjoy being a red teamer, right? It gives you an environment where there's no active measures to bypass so you can just sort of step through the easy mode version of it and build that confidence in your tooling, build that confidence in reading assembly and reading different architectures of assembly and examining memory and sort of understanding the environment from a basic point of view before you start looking at more modern software, more modern environments. There is a very high yield of zero-day findings for your effort so if you want to find bugs that nobody else has found before as a beginner, you're going to have a hard time with it with modern software because there's a lot of people looking at a lot of popular modern software and they find the bugs before you're going to and even if you find a bug, it's going to be very difficult to exploit whereas for a lack of a better term, it's like shooting fish in a barrel of this software, right? Because it's written before that awareness for security is there. It's not the fault of the programmers of this software because they didn't... they had no resources to do any better and it worked, right? It was amazing that it worked out at all back then. And also if we start talking about the ethics of vulnerability research, you can completely sidestep that with this, right? So nobody's going to get mad at you for breaking their FTP client that they released in 1993. I actually tried to find the author, the one that we're going to look at here and I couldn't locate him, I couldn't get in touch with him and I hope he's doing well and I hope he doesn't mind. But there's very little chance of an organization sending you a cease and desist over this, right? And also legacy systems are still in operation. How many Motorola 68Ks do you think are still running? A lot, I bet. And so the sort of things that a Motorola 68K is sitting in is the sort of thing that if it's still running, as long as it kept running, as long as it kept turning over clock cycles and doing its thing, chances are it's still there, right? So there's a lot of printers that use Motorola 68Ks and if it's a laser jet printer or something like that, then as long as you can get tonal refills for it, they're probably just going to keep it in place. A lot of industrial controllers and PLCs use the same processor and those for sure are an environment where as long as it's working, we're not going to replace it. Networking equipment, VME bus systems that are used in all sorts of industrial and military situations. There are automotive systems, there are cars that have Motorola 68Ks in them and the Motorola 68K processor went on to evolve into some more modern systems. There were cold fire processors later on that implemented more features and are maybe not binary compatible but are still at heart Motorola 68Ks and if you know a 68K, then you can do this. There's many different versions of the 68K as well that have increasingly more sophisticated features and memory mapping and things like that. TI calculators, the 89, 92, 89 plus range all had 68K processors. A bunch of audio synthesizers have it and then there's the microcontrollers that have synthesized cores of the Motorola. The Amiga is probably the best desktop computer platform for tinkering with the Motorola 68K though. For the operating system and the body of software written for it, the accessibility of it, it's quite easy to get hold of the Amiga 500 models. It's Motorola 68K based and you can expect to find anything from a 6820 to a 6860 in there if you've got a really nice one. The video output for it, PAL, NTSC and then there's a format for Amiga where more sophisticated video cards could be used with them to output with a call RTG graphics and that can be of arbitrary resolution and color depth and so for a modern Amiga setup you can literally have your 1920x1200 monitor filled up with an Amiga desktop and it's a lot of fun to use one like that. The custom chip sets of the Amiga are what make an Amiga to Amiga. It's a bunch of custom A6, a bunch of custom chips that Commodore made that went along with the 68K that handled things like the audio, the floppy, the serial, video output, interfacing custom chips and they all have their names Paula, Denise, Lisa, Agnes. These are all parts, the hardware architecture, the Amiga that make the Amiga an Amiga. These chips are expensive on eBay now because you can't just manufacture new ones. We're working off of old stock and things salvaged from other computers but there are some modern FPGA recreations of these chip sets and that's going to be something you want to look at as a possibility for an environment if you want to create a hardware environment for this. The architecture for memory for the Amiga involves having chip RAM and fast RAM so chip RAM is shared with those other chips, the Paula, Denise, Lisa, Agnes between the Motorola 68K and that and you can expect to see about up to two megs of that memory shared between them. That's slower memory because it's on a memory bus where those chips can get access to that bus and keep this processor from grabbing stuff on that memory because they can kind of deal with memory directly and do their own thing. Fast RAM is additional RAM on top of that two megabytes where the CPU has exclusive access to it, the custom chips that can access it directly and so while the custom chips can access that chip RAM while it's waiting for access to that memory, the 68K can access that fast RAM and just sort of clock it as fast as it wants to. There are all in one models where the computers in the keyboard like Americans would usually expect to see out of a Commodore 64 the 500, 500 pluses, 600s and 1200s and then there's desktop models that in the U.S. you mostly saw for use in video production video toaster or doing broadcast video. That was one of the most popular applications in the U.S. for the Amiga. So in the U.S. you saw lots of desktop tower type Amiga or pizza box style Amigas being used in video production and in Europe you saw lots of the all in ones being used for gaming in general purpose computer use. And then what interests me the most about the Commodore Amiga being the the classic Amiga OS, when I say classic Amiga we're talking about these Motorola 68K Amigas. After Commodore went out of business there were many different directions for Amiga OS and that's a rabbit hole, I'm not going to go down but for the Amiga hardware there are power PC Amigas out there and there's attempts to port the Amiga core operating system to Intel processors and recreations at the API level of them. But the classic Amiga OS that runs on the 68K is so interesting to me because it is a perfect little playground there's no virtual memory so you don't have to worry about or it's optional. You usually don't have a virtual memory system on a classic Amiga. Most of the 68Ks don't have a memory map or unit and so there's no virtual memory. The address is the physical address on the chips and all the running programs share that memory space. All the running programs can screw around with each other's memory which is not the most stable thing in the world but it sure is fun, right? It's fun when you're stepping through things in a debugger when you can sort of just go mess around with whatever you want to without having to worry about understanding page tables and things like that. It's not multi-user it is a single user operating system but it is multi-tasking and it's preemptive multi-tasking. It's the first desktop example of this and what I mean by that is early operating systems that provided multi-tasking to home users like a Mac OS up to even the late 90s up until Mac OS X was cooperative multi-tasking your process had to give up the processor at some point so other processes could execute, right? You had to have a call in there saying I'm done with what I want to do with my slice of time. Somebody else can have my time otherwise you would just hang the whole system with your little program. The Amiga OS triggers interrupts on a regular basis and will take the state of a process and all of its registers store it off and then give another processor time and then swap them back in and it's all seamless just like you would expect on a modern operating system and it's very interesting being the first system doing this. It's well documented and what's not well documented about it that's the part that you get to have fun reverse engineering. Lots and if you're vulnerability researcher there's lots of file formats, there's lots of parsers lots of interesting things the sort of beginnings of our PNG graphics file format are there like cooked into the main modules of the Amiga OS with the IFF format. PNG is an evolution of that IFF image file format. Interchangeable file format is what it stands for but it's a lot of times used for images. Another Hawaiian classic Amiga is lots of communication software. The Amiga came out and towards the end of its life was coming out in a time when the internet was starting to become something that normal users could have access to, that they could dial up into a service or have a networking connection in some way and talk TCP IP instead of just dialing up a BBS and having one point to point communication. And so we have that environment where a file handle might not dial or user input from the console, it might be coming over a TCP IP stream from another computer which has where we're starting to have our security concerns. You could almost use an Amiga OS right now as a daily driver with all the software that's out there or if you wanted to just go full hermit mode and desert island computer you could have a lot of fun for the rest of your life just playing on a Commodore Amiga. Full HD to screw play, RTG graphics, if you got some expensive hardware you got accelerators but right now you can get what's called a Pi storm that allows you to replace the Motorola 68K with a board with a little CPLD type thing and a Raspberry Pi and it will emulate that 68K at clock speeds that are very fast and it becomes a very smooth experience. There are network adapters both old and new, the newer ones are a little bit easier to set up than the old ones and it's a very responsive user interface. You're the only user and so it's not trying to swap around, it's almost real time. Something I also have been tinkering around with lately is the Apple 2E which is extremely fun to reverse engineer. It's less interesting on vulnerability analysis because it's such a different programming model to modern systems but it's extremely fun to reverse engineer. So the Apple 2 ROMs, stepping through those and reverse engineering the 6502 assembly of those, the tricks that they use to get the monitor ROM in such a small amount of space like the sort of the REPL that you use to investigate memory and assemble new code in and execute it, they'll like reuse parts of functions and jump in the middle of functions. They're not functions in the classical sense as we think of as a like compiled C code and so it's all hand assembled and so you get to see what Wozniak was thinking when he wrote this stuff and it's very interesting. Those Apple 2's are less connected, there's less inter-operation in terms of file formats between software so it's not quite what we need for this talk but it might be something I'll talk about in the future. Exploitation for those is different. I've written some Apple 2E exploits but nothing terribly impressive yet. So the modern modifications I've talked about the PyStorm accelerators, very fast CPU, it also since it's sitting as a CPU it by default has access to the bus so it can implement that hey also there's some storage here, also there's RTG graphics, also there's a ton of fast RAM, also instead of having to burn some operating system ROMs for different versions of operating systems you can just have them on the Py's file system and say I want to run Kickstart 1.4 today, I want to run Kickstart 2 today, I want to run Kickstart 3 today and all those have different modules built in. You can to do video adaptation to this you can have another Raspberry Pi inside of your Commodore Amiga that will convert the RGB output to a very clean HDMI signal. You can have the keyboards in mice because God bless them, Commodore never did make a good keyboard and you can have the network adapters for them. They're compact flash adapters to add storage to them and that's a first class citizen on the Commodore Amiga, the 1200's and the 600's had IDE buses on them to add drives and so it's very easy to get storage onto them in a modern sense and now there are FPGA recreations of the entire system and so if the eBay prices do continue to go up and I hope I don't contribute to that with this talk, the Minimig is a good implementation of a base level Commodore Amiga. Mr. FPGA uses the Minimig core in that and you get a bunch of other systems that you can emulate with it and then Apollo makes a series of standalone and accelerator FPGAs for Commodore Amiga's so if you want to set up a research environment for this you can test and play on real hardware and it's a lot of fun I've got a 500 plus that I've built up for tinkering with this sort of thing and I love it. I've got a refurbished 1200 motherboard on its way that I'm going to be putting in a plexiglass case to have the real Cadillac Commodore hardware but it started like tinkering with an old car. Sometimes it's a little fussy sometimes it's a little difficult and honestly like with the real hardware sometimes it can be hard to get that really low level debug access to it when it's very easy to launch when UAE is an emulator and just break into the debugger. It's just like having a perfect in-circuit debugger. You have save states on the emulator so you can sort of rewind state and replay back and do different things. You can copy and replace drive images very quickly so that you can change the state of the disk and swap out different configurations. Physically portable, I don't want to take any of my Commodore hardware with me anywhere. I don't trust it to travel well so I'm going to use it on my laptop. When UAE is extremely accurate, the UAE the acronym originally was Unusable Amiga Emulator but it has evolved since then. It's incredibly accurate now especially with certain configurations. It's tricky to set up at first though and I have a set of slides here that don't expect to read these slides and just be like oh yeah I know what that's saying. These slides are for when you watch this back on YouTube or you grab these slides so that you know what settings to set and when UAE, just to get started with a basic setup, you set up your CPU. You set up whether you want it to be cycle accurate speed. You set up whether you want a floating point unit. You set up whether you want to do just-in-time recompilation of assembly language instructions. You set up which version of the Commodore underlying chipset you want to use and whether you want its memory access to be the cycle correct. You set up which ROM you want to use and this is one of the later kickstart ROMs and I think in a slide here in a moment we're going to talk about what might surprise you about that. You set up how much memory it has. You set up what hard drives that you have for it. And if you, in this right here, some hardware, quote unquote, hardware that you're adding to your system with when UAE, when UAE is very clever and it implements it as in-memory hooks. Like there's the BSD sockets library for connecting to the internet. The code for that is not in the Commodore Amiga's memory. There's like a place holder stub in there that gets called and when UAE sees that executing grabs it does its native host thing for networking and then pulls it back in there. The Amiga emulator actually shares your IP address in TCP stack. Then RTG graphics and such. The kickstart ROM contains the OS, the libraries, the modules in ROM. Ideally you want your kickstart ROM to match the operating system that's on disk, otherwise there'll be multiple copies of each of those modules and you'll waste a little bit of memory having that. For a 1200, most of them shipped with version 3.0 of kickstart. The last Commodore version was 3.1 in 94. Hyperion is probably like there's a lot of debate over who has Amiga OS and who is the true Amiga OS nowadays and I'm not getting into that. But the latest Hyperion version that I think is the most authentic to the Commodore version is 3.2.2 and it was released in April of this year. So Hyperion continues to release patches and updates to the Amiga OS. Later version numbers are either PowerPC or actually older. There are 68K versions of Commodore OS with later version numbers that are actually older than 3.2.2. You can install it from floppy disk images in WinUI or make your own floppies to install it on a real Amiga. The Picasso 96 driver here from Aminet, which is the archive for Amiga software, that's what you're going to do to get RTG graphics up. Adultment environment, SAS C for your C compiler, DevPack for your assembler. And this is if you want to do your stuff on system which I don't even have an off system on here. I like doing it in the system. I like the windowing interface for Amiga. It's fun to use. I'm not playing with my Amiga stuff to play with a piece of software on Windows. I'm playing with it to play with Amiga OS. But on the host, there's servers and scripts that the VM can interact with. Ghidra, the NSA disassembler reverse engineering decompilation tool has a Motorola 68K module. Great support for it. So that also tells you that if the NSA thinks that it's a good idea to have 68K support in a disassembler, maybe there's some relevant platforms out there that you would want to take a look at with it. You want that. Ghidra is great for looking at memory images out of WinUI and you want a matching development kit for your kickstart OS. The NDK is like grabbing the Windows SDK. It has all the headers for all the operating system stuff. It tells you the names of all the functions, all the arguments, all the data structures. You can literally drag those header files into Ghidra and then start applying it to memory for modules and stuff. Books. I love old computer books. You can grab these on eBay. You can grab these on archive.org. I've got both. I've got a shelf of 68K Amiga OS stuff, but I also have all the books on my iPads because I like to travel and read and I don't like taking big books with me. The AmigaDOS manual is what you want to use to figure out how the hell do I use this thing because it's a very different paradigm from Windows. You'll want the official instruction set reference for the Motorola processor and then the Commodore Amiga references for digging into just what it is that you're looking at. How is it architected? The hardware reference manual, the kernel reference manual, the libraries, devices, the includes and autodocs, that's probably better looked at as files on your NDK. This developer CD on archive.org has a good recent NDK that matches the later Commodore ones or you can download the NDKs from Hyperion. Then the SAS C development manuals that it has its own debugger utilities, and so there's pretty nice end system debugging too, but obviously you'll want to do operating system level stuff. You want to get outside of that with WinUE. There is a lot of resources for preserving vintage computers and so TOSET catalogs, known software documentation for many different computing platforms and so you can build yourself a complete set of Commodore Amiga software from this. archive.org has lots of books and software and the English Amiga board, fantastic set of folks that are talking 24 hours a day about Amiga stuff arguing over which FPGA is better too. If we look at the architecture of the Amiga OS, this is straight from the manuals. The Amiga hardware is down here at the bottom with the chips, the actual Commodore chips that do disk control, keyboard and mouse, graphics, audio and I.O. There is one library, one module that talks to those chips and that's exec. That's essentially your very core kernel. This is almost very almost a micro kernel architecture and so exec does most of the work and talking to the hardware and then other modules handle everything else. The graphics rendering, the windowing system, DOS, audio, serial and parallel and so when you're talking about porting Amiga OS things, all you have to really port is exec and that has your tasks which are your processes, your messaging system between processes, handling interrupts, internet I.O., loading libraries and such. If you're looking at a memory image for Commodore Amiga, a library that's loaded into memory has a base address but it's actually in the middle of a data structure. The library's metadata is ahead in memory of that library base. The data for the library is past that but before the library base, minus from that base is a jump table for all the functions of that library and those are numbered essentially. You can just do a simple multiplication, figure out oh it's function three. Well I multiply three by a constant and jump to that address and that's a jump table to where that function actually exists in memory and so that's how you find API calls. Kind of like what you would expect out of load library and get function address type stuff in Windows. If we look at this is a full memory map of the Commodore Amiga and so most old systems you have a memory map and microcontroller systems and things like that. Your memory map would have all sorts of addresses for static addresses that are important for the system like how do you talk to the keyboard and things like that. On a Commodore Amiga there is one address that is supposed to be always static and that is hexadecimal four and that's a pointer to sysbase and from there you're supposed to use the exec library to find everything else. That's your bootstrap into getting there. Now in practice a lot of this stuff is in static areas of memory. A lot of games talk to the hardware directly without using exec and that's of course not supported but of course games are going to do it for performances sake. The case study this is the first time I'm revealing publicly the target software and it's GUI FTP. It's just a FTP client, very simple FTP client and I wanted to pick a target that was of the time not a modern version of GUI FTP, not a modern piece of Amiga software because there's plenty of it, right? There's people still writing software and so what I did was I grabbed the very first CD published set of software from Aminet and that's all my archive.org and it has early networking and file format software which is the sort of thing you want to look at for simple vulnerability analysis. It was published in January of 1995, again, considered really earlier than smashing the stack for front and profit which is sort of your moment in time where people started becoming more aware of exploiting C software. And so you get this great hypertext interface for it so there's like a hypertext system kind of built into Amiga that a lot of software uses for navigating directories and documents and things like that and so you can see that there's 86 whole types of communication software on this Aminet set and that's a lot of software when you're talking about software that old. And so everything on this disk predates smashing the stack by at least 14 months. This was literally the first one I picked. I was like an FTP client is probably fun because FTP is a little bit of a complicated protocol to parse. It's by Kevin Priest who did a fantastic job of it and we don't blame him at all for having buffer overflow vulnerabilities in place especially it's his first release. He's not even sure if he's going to keep the numbering scheme for version numbers. If he's out there get in touch. And it's referred to in books and so we can establish it. This is a piece of software you would legitimately use back then. This is something that if you wanted to connect to an FTP server you would have used this. We install it so we install it from the ISOs. Again very easy to do and when you mount these ISOs and go. And running it you see a very familiar two-pane interface for an FTP client. So this is what you'd expect to see and it works with modern like this is a very simple FTP server that I've set. Actually in this screenshot I've just connected ftp.ganu.org and it connects to it fine. It lists out directories so it still works. If we want to start exploiting this thing we can look at a memory map and see where in memory the kick start ROMs and things like that loaded. We want to find where this is in memory. And so just to have a situational awareness we can use and all of this is in the when you a debugger. We can dump memory to a set of bin files that we can then load into Ghedra one at a time and create a memory map of our Commodore in this situation with this software loaded that we can so we can navigate in Ghedra the internals of this thing. And what that allows us to do is it allows us to take headers for say the BSD socket library or any other library in the data structures and start creating things that we can refer to to navigate around memory in Ghedra. So what part of Glee FTP are we going to attack? A large server a lot of things crash this thing but large server welcome messages crash it's not reliable I couldn't get it to do the same thing twice in a row but long file names and file lists crash it really reliable like if you give it too long of a file name it will crash in the same way every time so we can develop a well structured payload. I decided it's been a while since I did anything with FTP so I looked at the RFC not much help it's just like it lists things classic old RFCs. So we created a minimal FTP server to just talk to it. It's easy to insert our own exploit code and if we just stuff a ton of characters into there we get a crash here and we get control over the program counter if we want to execute for code from there we have a certain range of memory here it loops back around the red part is smashed before code execution ever happens and so we can't use this B and D we have labels for this actually so execution clobbers the first 56 bytes the program counters at PC those bytes wind up in the A5 register if we want to use those the stack pointers pointing to F and so we've got 197 bytes in F that we can use we've got 200 or 260 or 204 left in A that we can use for our code the stack moves around too much for us to raw we just point an address into there because it's dynamic it can load a different every time and so we want to do code reuse we want to find somewhere in memory we can jump to where it actually will find somewhere in memory that we can jump to and actually get reliable code execution so there's lots of promising things and I'm going to have to kind of go through this part quickly and everything the cheat code for this is the there's some libraries loaded early in the booting process that are almost always in the same place and there's some code there where we can we can jump to the stack pointer so we can set the essentially set the instruction pointer to the stack pointer by doing a jump sp it's a two byte sequence and you're like oh man two bytes I can find that easy in memory well there's not a lot of memory right this is a very tight operating system and there's none of them in the ROMs but there's one that's all almost always in the same place in RAM we write a payload for it the payload is split across those code regions there's just the since code region one the bottom part there is where code execution starts I use that as sort of a trampoline I just sort of move the stack pointer and then jump over into the other part of code and I use it with a jump subroutine so that the next address is pushed to the stack and I use that as a reference for my strings that I need and what I'm doing is I'm simply just writing a file to disk reusing some of the IO handles is a little complicated on Amiga so the most easiest shell code is simply to write a file to disk and this calls the Amiga APIs to do so and these are a little more detailed look at that and at the end it will crash the entire system if you don't set up the stack back right and keep executing and so to avoid crashing I just sleep forever just call sleep and just let it sit there and grab a cycle every once in a while running it basically we connect up to a local FTP server with the payload it loads up tries to load up a directory with it creates the file simple as that so we get execution we get the ability to drop a file anywhere on Amiga which actually would be a pretty good plan if you wanted to establish persistence so with modern systems making teaching and learning memory corruption much more difficult complex architectures lots of mitigations these systems they can make it easier for you to sort of tinker around with the internals of something get a feel for it before you're going to do it on a more modern system and so it's easy you can't completely understand Windows no one person can understand everything in Windows you could sit down and over time reverse engineer every single piece of Amiga OS and have a complete understanding of this system and that's a good feeling to have and it's a nice little hobby approach type thing if you like that sort of thing you can take advantage of this to find hidden things in software we can look inside of old software for hidden features hidden functionality that's been disabled there's a site called the cutting room floor that does this for video games and there's all sorts of sprites and levels and music and things like that in games that have been lost to time embedded systems have similar architectures to these simpler architectures and so this is a good springboard into getting into embedded systems as well and ultimately the reason for doing this is just fun right if this sort of thing interests you then it's interesting to do just for its own sake and really that's why a lot of us are in retro computing is it's nostalgic and it's just fun to play around with to play around with something that's not Windows or Linux for a while so thank you for your time on this I appreciate you getting up early on a Sunday to check this out this is my contact information and I see a lot of y'all who clearly are Amiga users of a certain age and they have t-shirts and everything and so I really appreciate folks that like this kind of hardware and software coming to attend this and seeing what I had to do with it so thank you very much