# Media

url: https://www.youtube.com/watch?v=6j4en3EbP3w
title: DEF CON 31 - Retro Exploitation - Vintage Computing as a Vuln Research Playground - Wesley McGrew
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=6j4en3EbP3w",
    "title": "DEF CON 31 - Retro Exploitation - Vintage Computing as a Vuln Research Playground - Wesley McGrew",
    "description": "It can be very difficult for those new to hacking to learn about vulnerability discovery and exploit development on modern operating systems and software. The complexity of a modern computing environment, developer awareness of security risks, and the iterative development of exploit mitigations over the past three decades has put up an intimidating wall in front of those who would be interested in learning about vulnerability research. Vintage computing environments can provide an interesting and fun playground environment for learning and experimenting with reverse engineering, vulnerability discovery, and exploit development.\n\nIn this talk, Wesley will discuss the setup of a complete environment for hacking software for the Commodore Amiga line of computers, a 16/32 bit computing platform of the late 80s and early 90s (not to mention a dedicated following of users and software today). He will describe the hardware environment, OS architecture, and the practically endless library of software that can be used as interesting targets of research. On-system development and debugging software will be described, as well as using the modern Ghidra disassembler. A case study of identifying and exploiting a vulnerability in a 1994 vintage FTP client will be discussed in technical detail.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 2654,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230915"
  }

  This text was transcribed using whisper model: large-v2

   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 multitasking operating system,  one of the first systems where you had a TCP IP stack that wasn't a PC.  And so the idea with 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  and that sort of tickles some of the interest that people have in retrocomputing in general,  which I have.  So there's a large interest right now in vintage and retrocomputing 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 did 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 interest with 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 off of archive.org, you can grab all the old documentation you want,  all the old documentation you read.  I love reading old computer books.  That's basically what I use my iPad for,  just downloading tons of PDFs from archive.org of old programming manuals  and computer science textbooks and technical manuals and such.  There's archives of all of 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.  I grew up using a Commodore 64, the 8-bit system that came before the Amiga.  And 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 loved 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 this stuff.  But we can also use it to teach, right?  And so in a modern computing environment and 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, it's 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.  It'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 something like the Commodore Amiga and code for it,  you know, what we were looking at is a lot of code that was written in C  using TCP IP networking,  but predates the publication of smashing the stack for front-end profit in Frac  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.  Back then, we knew 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 of it,  and we knew it would crash if we did that.  But maybe not everybody had put together the consequences of that  in a networked environment where anybody can stuff that buffer for you.  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.  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's sake, and I think it's something that you can learn from,  and it's not covered by a nondisclosure 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 with the longest 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 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 WinUAE, 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, it 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 don't have to go blue team.  You can enjoy being a red teamer.  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 and more modern environments.  There's a very high yield of zero-day findings for your efforts.  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 lack of a better term, it's like shooting fish in a barrel with 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 of the one that we're going to look at here  and I couldn't locate him, I couldn't get in touch with him.  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 if it's 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 toner 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, 90, 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.  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 a video for Amigas where more sophisticated video cards could be used with them  to output what they 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 1920 by 1200 monitor filled up with an Amiga desktop.  And it's a lot of fun to use one like that.  The custom chipsets of the Amiga are what make an Amiga an Amiga.  It's a bunch of custom ASICs, 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 of the hardware architecture of 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 chipsets.  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 chipsets can't 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 and 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 an Amiga.  So in the U.S. you saw lots of desktop tower type pizza box style Amigas being used in video production.  And in Europe you saw lots of the all-in-ones being used for gaming and general purpose computer use.  And then what interests me the most about the Commodore Amiga being 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 PowerPC 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 68Ks 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 mapper 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.  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 multitasking.  And it's preemptive multitasking.  It's the first desktop example of this.  What I mean by that is early operating systems that provided multitasking to home users,  like a Mac OS up to even the late 90s, up until Mac OS X, was cooperative multitasking.  Your process had to give up the processor at some point so other processes could execute.  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.  It's very interesting being the first system doing this.  And what's not well documented about it, that's the part that you get to have fun reverse engineering.  And if you're a vulnerability researcher, there's lots of file formats.  There's lots of parsers.  There's 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 one, classic Amiga.  There's lots of communication software.  The Amiga came out, and towards the end of its life,  it was coming out at 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 be a file or user input from the console.  It might be coming over a TCP IP stream from another computer,  which is where we're starting to have our security concerns.  And if you just want to use it, you could almost use an Amiga OS right now as a daily driver,  with all the software that's out there.  If you want 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 display, RTG graphics.  If you've got some expensive hardware, you've got accelerators.  But right now you can get what's called a PiStorm 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, right?  And so it's not trying to swap around.  It's almost real-time, right?  Something I also have been tinkering around with lately is the Apple IIe,  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 II 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 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, 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 IIs are less connected.  There's less interoperation in terms of file formats between software.  So it's not quite what we need for this talk.  But it might be something I talk about in the future.  Exploitation for those is different, right?  So I've written some Apple IIe 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 new operating system ROMs  for different versions of operating systems,  you can just have them on the Pi'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 adapt the keyboards and mice because, God bless them,  Commodore never did make a good keyboard.  And you can have the network adapters for them.  There are compact flash adapters to add storage to them.  And that's a first-class citizen on the Commodore Amiga.  The 1200s and the 600s 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 Mini-Mig is a good implementation of a base-level Commodore Amiga.  Mr. FPGA uses the Mini-Mig core in that,  and you get a bunch of other systems that you can emulate with it.  And then Apollo makes a series of stand-alone and accelerator FPGAs for Commodore Amigas.  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.  And 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 of Commodore hardware.  But it's sort of like tinkering with an old car, right?  Sometimes it's a little fussy.  Sometimes it's a little difficult.  And honestly, 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 WinUAE as an emulator  and just break into the debugger, right?  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.  It's 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, right?  WinUAE is extremely accurate.  The U in 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 in WinUAE  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  and 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 cycle-correct.  You set up which ROM you want to use.  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.  This right here, some hardware, quote-unquote hardware,  that you're adding to your system with WinUAE.  WinUAE is very clever, and it implements it as in-memory hooks.  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 placeholder stub in there that gets called,  and WinUAE sees that, executes, and grabs it,  does its native host thing for networking, and then pulls it back in there.  The Amiga emulator actually shares your IP address and 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 will 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 and 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.  If you want a development 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 one on here.  I like doing it in the system.  I like the windowing interface for an 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 in Amiga OS.  But on the host, there's servers and scripts that the VM that you 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 one UAE.  And you want a matching development kit for your kick start 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 iPad because I like to travel and read  and I don't like taking big books with me.  The Amiga DOS 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, it has its own debugger utilities.  So there's pretty nice in system debugging too but obviously you'll want to do operating system level stuff  you want to get outside of that with one UAE.  There's a lot of resources for preserving vintage computers.  And so Tosec catalogs known software and documentation from 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.  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 IO.  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 microkernel architecture.  And so EXEC does most of the work in 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, inter IO, loading libraries and such.  When a library, if you're looking at a memory image for a 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 to 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 sys base.  And from there you're supposed to use the exec library to find everything else.  And 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 performance's 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 on 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 considerably earlier than Smashing the Stack for Fun 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 megs 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 cannot 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 that 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 in WinUE.  Just 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.  This is a very simple FTP server that I've set.  Actually, in this screenshot, I've just connected to ftp.gnu.org.  And it connects to it fine.  It lists out directories.  So it still works.  So we want to start exploiting this thing.  We can look at a memory map and see where in memory the kickstart 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 WinUE debugger.  We can dump memory to a set of bin files that we can then load into Ghidra one at a time  and create a memory map of our Commodore in this situation with this software loaded  so we can navigate in Ghidra 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 Ghidra.  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 reliably.  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 a list.  It lists things, the classic old RFCs.  So we create 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 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 pointer is pointing to F.  And so we've got 197 bytes in F that we can use.  We've got 260 or 204 left in A that we can use for our code.  The stack moves around too much for us to probably 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 we went through,  and I'm going to have to kind of go through this part quickly and everything.  The cheat code for this is 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 jump to the stack pointer.  So we can 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 almost always in the same place in RAM.  We write a payload for it.  The payload is split across those code regions.  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.  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 I.O. handles is a little complicated on Amiga,  so the easiest shellcode is simply to write a file to disk.  And this calls the Amiga APIs to do so.  And this is 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  and 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.  We 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 kind of 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 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 that 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.  Thank you.


url: https://www.youtube.com/watch?v=Gdn_jKdABo4
title: DEF CON 31 - Reproductive Justice in the Age of Digital Surveillance - McSherry, Bertash, Barnett
type: video
author: DEFCONConference
ingestion_date: 2024-08-03
transcription_model: large-v2
content:
  {
    "webpage_url": "https://www.youtube.com/watch?v=Gdn_jKdABo4",
    "title": "DEF CON 31 - Reproductive Justice in the Age of Digital Surveillance - McSherry, Bertash, Barnett",
    "description": "In the year since the Supreme Court overturned federal legal protections for reproductive rights, people seeking, providing, and supporting reproductive healthcare are grappling with the challenges of digital surveillance. Multiple services and apps track our movements and communications, and that data can be used by law enforcement and private parties to police and punish abortion access. Lawsuits and prosecutions are already underway and are likely to increase as states continue to pass or expand anti-abortion laws and undermine legal protections for online expression and privacy.\n\nBut the fight is far from over. At the state and federal level, lawmakers, activists, and technologists are taking steps to establish and shore up legal and practical protections for secure and private healthcare access.\n\nThis panel brings together legal and security experts to lead a discussion about defending reproductive justice in the digital age \u00d0 what has already been accomplished, what\u00d5s coming, and how hackers can help. It will build on and update a discussion held last year, also led by EFF and DDF.",
    "channel_url": "https://www.youtube.com/channel/UC6Om9kAkl32dWlDSNlDS9Iw",
    "duration": 3177,
    "channel": "DEFCONConference",
    "uploader": "DEFCONConference",
    "upload_date": "20230915"
  }

  This text was transcribed using whisper model: large-v2

   This is abortion access in the age of digital surveillance  With folks from the Electronic Frontier Foundation and the Digital Defense Fund. I am Corrine McSherry  I'm the legal director at EFF with me. I have India McKinney who's director of federal affairs  We have daily Barnett's staff technologist and all-around awesome smart tech person  Who's also works with hacking hustling who you may also be familiar with and then we have daily Barnett's  from the Digital Defense Fund  Kate Burtosh  Sorry Kate Burtosh, don't worry. I'll catch up  so and  We're gonna do this is that  We're gonna sort of just take turns talking a little bit about  some of what's going on in the year since the Dobbs decision that if you're here, I'm assuming you're familiar with and  Some of what we are all respectively trying to do about it and especially what you can do  and it is not just the decision as such that is what it is, but  The Dobbs decision one of the things that it's made many many people aware of is that  Their privacy and their security is not where it needs to be if they want to protect  Themselves and their communities because we know this is a this is a team sport  And so that's something that EFF and DDF has been have been working on for years the the privacy and security part of it  But we have a whole new and a particularly dangerous and fraught context  With within which to do our work  so that is  The place that we're going to be focusing here. You know, the beginning premise is that  First of all, there are lots of different ways in which  Your digital security might be able to be compromised if you don't protect yourself, but also that there's many many  Companies third parties that are collecting data about you all the time  often without your knowledge though nominally with your consent and  and that data becomes a treasure trove of information for law enforcement and  So far many companies are not doing enough to have better practices around that  so and in in a current context where that can ultimately be evidence that could be used against you or your friends or  Your family or your provider, you know  This is a becoming a very very pressing issue for many many people  And especially, you know, and we've been very involved in trying to do something about it at EFF  So I'm going to talk a little bit about what we've done from the sort of  legal team perspective and  Then we're gonna talk a little bit about what some of the technologists have been doing which is really really crucial work  And then to close this out  India is going to talk a little bit about what's happening at the federal level  And there's some really really important work that's happening right now that all of you should be paying attention to  Some of which doesn't seem obviously relevant to abortion access, but in fact completely is  So I'll be as brief as possible  At EFF, there's a few different things that we've been doing from a litigation perspective  One thing we've been doing is we're using the Freedom of Information Act to find out at least in California  Where we have some decent privacy and data sanctuary laws to find out where and how law enforcement is  despite those laws  Collecting automated license plate reader data about people and then sharing it with law enforcement  Agencies in states that actively restrict abortion in a much more serious way than California does  That's unlawful under California law and we are holding them accountable for it  And then there's sort of some things that are in process  There's a lot of work that we've been doing around what's called dragnet surveillance  And that is where law enforcement gets what are called geofence warrants or keyword warrants  And that's seeking information within a given area or related to searches with a particular  Using a particular keyword and this has been a long-standing practice. It doesn't just apply to seeking information about  abortion, but this practice is you know a natural one to apply in the abortion context and so  The we sort of view is like when you are when you protect  Privacy and security for everyone you're protecting  particularly in this moment  The use of those kinds of warrants to against women and people are providing access and also their communities  So there's challenges in multiple states to those warrants and though so far. They're reasonably  Successful because courts are understanding that these are too broad to comply with the Fourth Amendment  So that is that's some progress is being made so far  Then finally just from a litigation perspective there  We're looking at challenges to social media laws that that target teenagers, so there's at this is at the state level  There are already multiple states that have passed those kinds of laws  And they're supposed to protect the children  But they include things like well you if you're under a certain age you can't access social media without your parents consent  and we know that  Precisely the people who are going to most need to be able to access those resources without their parents consent  Right are going to be the ones who are going to get stuck in the middle  So and so we worry a lot about the effect of that for people who are seeking reproductive health care and gender affirming care  We're also doing a bunch on the legislative side most of that  I'm going to leave to India to discuss, but we have been working in multiple states to get data sanctuary laws passed to and  Laws that also just generally limit again that dragnet surveillance that I was talking about it  Can be that this is an area where we still have big fights to do at the federal level, but at the state level  Especially in blue states. There's a lot of very freaked-out upset people and rightly so  And so we are able to sort of galvanize some energy around this issue and to get some  laws in place at the state level  It's not a complete solution, but progress is being made really fast in just a year  Okay, so I can give lots of details later in the Q&A  But another thing that EFF has been doing is we've been doing a ton of activism  Around things that companies and nonprofits even should be doing around collecting and retaining data about people who reach out to them  there's a lot of practices that  Really are just creating treasure troves of data  And they do they people don't always realize that that is what they were doing until the cops come knocking  So that's a small sample of what we're doing the last thing  I would point to is we the our technologists have been just going flat out from day one and even before  Building and building on tools that you can use to protect your privacy and your security  And we've also been doing a ton of work around education, and I will hand it off to daily to talk about that  Sure, thanks so on the tech angle  I'm  most interested in disarming surveillance technologies that are endangering the movement and  otherwise empowering and educating  People involved in the abortion access work with the ability to keep good offsec while maintaining community trust  Because it's a little bit different than most infosec things  So at EFF we jumped on this only a few months before the Dobbs decision really passed like when the memo leak dropped  And we have this project called surveillance self-defense, which is at SSD dot EFF org  It's a bunch of instructional guides on tactics and technologies for thwarting surveillance and boosting privacy  So we have these sort of pre-baked personas in there  Where we curate different guides from within the SSD into an intentional list with the threat models that are likely  Associated with that that persona in mind, so it seemed like a good place to start right?  And I've worked with Kate for long before all the stuff came to pass  So I knew that she was the expert to reach out to because she's the founder of digital defense fund  I'll let her speak more about that, but they're  Fucking awesome  And so after some conversation we honed in on three personas or threat models that we wanted to tailor our advice to  Activists health care workers and patients in the health care system who are seeking abortion or other reproductive care  So for the activist the inherent tension there is this  Between privacy and publicity that needs to be reckoned with right that needs to be really kind of juggled carefully  So we lean towards advising use of compartment compartmentalization techniques  to keep strong separation between what needs to be broadcast really loudly and what needs to be kept really private and  Then for health care workers. It's tricky because there's this huge regulatory standard HIPAA, which is widely misunderstood and  It's supposed to provide a cloak of protection for the data. That's being passed around in this space  So there's a bit of compartmentalization techniques, but I think what was most useful for us is  Like yeah the compartment compartmentalization between the professional and the private right for these people and  also being able to  effectively communicate a bit of like know your rights info to the patients that are coming into their spaces and  Then of course for the third persona the people that are seeking an abortion or just the allies that are taking them to and from clinics  There's a focus on not just doing you know, like basic things like good internet privacy and  And secure communications, but also considering the street-level surveillance that they may face along the way because it's not unreasonable to expect the ALPRs  That will be planted outside of clinics will be facing them surveillance cams and the like  So honing in on these three personas helped us not just to deliver some really solid advice  But it helped us be really intentional with our language moving forward and in blog post and the one-on-one sort of consultations  We were giving individuals throughout the space  Some of the TTPs that we recommend either in the blog post or  Through the abortion access playlist again on the surveillance self-defense project  Are you know secure comms safely attending protests mobile device security compartmentalization?  Assigning team roles for trusted community members  Especially when setting up incident response plans, that's a little bit irregular from most like infosec advice you find  it's a little more activist oriented and  of course threat modeling  so although some folks organizing in the abortion access space or the movement have been operating under the assumption of  Criminal liability for a while now before Dobbs that aspect is still really quite new for a lot of people and it's really scary  so I  Think we've only seen the tip of digital evidence being used in courts right at least in the post Dobbs context  I  Should say that last year the FBI reported a tenfold increase in designating abortion activist groups as terrorist organizations  So it's been time for us to regard our threat models in that way, right?  What's making things worse is the role that tech companies are playing in this space. I think  Yeah, like data retention policies need to be re-evaluated  The data collection aggregation and brokering industries are these vampiric awful scourges that need to be banished like yesterday  But when tech companies themselves are misunderstanding their own liabilities under HIPAA  Extended through these business associate agreements  We get these like special third-party SAS apps that are kind of positioned to be these messaging services between healthcare providers and patients  these sort of necessary components and  they're running willy-nilly with behavioral tracking and selling that data and  HIPAA regulation or not  This is just illustrative of how tracking the tracking industry at large run amok endangers everyone  Especially when the lens of criminality extends or shifts to encompass new people  So I mean take my analysis there with a grain of salt because I'm not a lawyer  But I can tell when something sucks and when it's hurting people  So we can't just be forming our digital security advice for activists who are pushing for normalization of abortion as health care  There are also those who are organizing on behalf of communities  There are those that are handling vast amounts of data for many others across state lines  Unlike typical infosec paradigms that are pushing this sort of zero trust as a core ethos  I think it's really critical that we've re-humanized the privacy and security recommendations and make them for people that are living among people  We're protecting human networks, right? Not corporate ones  So in that process, we must realize that everyone's security is imbricated with one another like Corinne said it's a team sport  and  I should say that one glimmer of hope that I see  Especially in the work that I'm doing with Kate is  Cross movement organizing with similar goals of bodily autonomy  So there's sex worker rights trans rights disability justice harm reduction activists  These people are kind of recognizing the shared threat models and goals of each other and therefore sharing  Resources and upskilling each other for that sort of collective liberation  So finally, I just want to say that my call of action to you guys the the hackers and security researchers and fellow technologists  We need to be doing our part to better educate each other's about good OPSEC procedures  But we need to normalize the use of techniques normalize the use of privacy technologies  So that less tech-savvy folks can use them better use them well and not feel weird for using them  Any way that we can use our skills to protect these vulnerable networks of people rather than companies is good  and  I should say if you're working at a company if you're working at a tech company with bad privacy policies or a bad reputation of  handing over data to  Law enforcement or just like weird creepy tracking stuff do your part like change it from the inside  And I'll hand it over to Kate  I always think I do a little better holding it  I love that we kind of exited a little bit on feeling weird because I think it's like good to kind of put back  In context sort of why you're listening to a talk today about abortion access at a place like DEF CON  I just actually wanted to start with a little question for the audience. So please don't be shy  How many people here? This is your first DEF CON. Give me a little bit of a hand. I love it. Yay  So six years ago  It was my first DEF CON and I had just two weeks prior  Got a job at the digital defense fund where I had to set up this fund where our job is to basically provide digital  security and technology resources to the abortion access movement and that includes  organizations working on behalf of patients who providers and then now more recently kind of  Interfacing directly with those groups that support patients themselves. So I think one of the really  Strange things about being at DEF CON was like do I belong here?  What am I here to learn and then no sooner do I do that than the very first year I was here  I walked into a panel with EFF  wonder  Cooper Quinton and  journalist Kashmir Hill talking about the pregnancy panopticon and all of the different types of places that  Pregnancy and related data is kept and the leaks and applications and things like that  And it was just such a really wonderful eye-opening moment in the years since I think I've really enjoyed getting to  Work more with the cryptography and privacy village. I'm now one of the core organizers  So come visit us out there as well  But I think it was kind of through being in this space that I absorbed a lot of what I think makes  DEF CON a really great place to figure out like sort of what's next for this kind of very big existential crisis  Which like DEF CON is I took back from these different years with me  that's sort of like spirit of irreverence that like anyone can learn anything that  All of us don't have to accept the structures and hierarchies of technologies as they are handed to us  You have the right to rip the do not remove sticker off  And I think that's something that I think I've tried to take back with us  So we and our team can kind of better understand not just the threats in our space  But how we can be flexible and creative and brave and adapt to them  So these days our work mostly centers on ensuring that organizations that work directly with people who are seeking abortions are  Prepared that they can utilize their own creativity and tools to build the ones they do not have to reuse tools for unintended  But very amazing values forward purposes  I think in this way sort of DEF CON really embodies that same spirit of what autonomy actually means  And it's why I'm really excited to come back and bring back to you this session sort of like how we together can continue to  Take that entitlement that we all have to sort of make technology and spaces and our digital selves our own  I think if you take kind of nothing back with you today except for a couple of key points  It's that over these last few years as we've worked directly with these organizations  We've kind of figured out out of all of these threats, you know, because certainly here at DEF CON we love a good threat model  What is it like right now for somebody seeking abortion?  what are the issues that people are really kind of facing off with and we know these things actually because  Unfortunately, even before the Dobbs decision overturning Roe v. Wade  People have been getting prosecuted for being suspected of ending their own pregnancies for many decades  and so there are organizations like legal organization if when how  We've compiled reports of every single time that this has so far happened in the United States that we can tell  It can be sometimes very difficult to find and they found these sort of very key disturbing results  which is that as  we kind of look through these cases the sort of  Entry point where the case of somebody who is suspected of ending their own pregnancy comes to the attention of law enforcement  It is usually primarily through either a people who are responsible for their care be it doctors nurses social workers  someone else who's supposed to be providing them with personal health care or other support or  Someone the case that the patient knows so friends exes neighbors  And that is a vast majority of the cases. So that is extremely disturbing  I think very notable also that cases don't tend to come to the attention of law enforcement  Via these like dragnet methods  We know that like data is generated all throughout a person's experience of being pregnant and deciding whether or not they want to continue to  be pregnant, but that tip of the spear is  unfortunately an interpersonal violation somebody turning you in and then all of the data that's generated about that experience becomes relevant and  Is often requested by law enforcement or as we unfortunately see quite a lot  There is something called a consent search that is a disproportionate factor in many of these cases  That is where someone is typically pressured into disclosing a device or agreeing to the search of a device  Then we know a lot of those same forensic digital technologies that the folks on this stage are all experts in come into play  They plug your phone into a device that clones the drive and then they search for everything that's on it. They use keywords  They're looking for everything from text messages email receipts your search  Information often it's not even necessary then to go to the company in question because that search history copies right on your phone  So I think with this in mind, it's very tempting sometimes to be like, oh well if I had to get an abortion  I would do all of these things. I would like use signal use Tor use Bitcoin. I don't know  It's very tempting for us to each construct in our minds sort of like what I've come to call sort of the ghost abortion  Like the abortion that has no data  You know  I've literally had a reply guy kind of tell me that like in order to get your legally sensitive abortion  first you have to jailbreak your key of Sorrento to  To not collect that GPS data along your route to a clinic  as I think from  You seem like a sensible crowd with that laugh  So you can kind of see how like as many good intentioned things as we may want to put out there to help folks to  Learn about how to better protect themselves and the people they're supporting  There is only so far that we can ask of people like it's really not reasonable to ask someone who's probably going to have to search  across many states often great distances make a lot of travel plans now and spend way more money than they've ever had to spend on  Getting an abortion. I mean like we forget all the time, right that like we talked about all these various pieces of data  They're collected through search engines or through our experience of interacting with a mobile device  But banking institutions and telecoms companies have a long history as you have heard in this building before of  unfortunately sharing data with law enforcement  So I think one of the things that's very critical for us to do then is to look at cases that we see in the news  Like you may have seen that one  We're unfortunately Facebook messages were sort of front and center in a very sensitive case of a parent and child  Trying to work out how to obtain an abortion allegedly  I think what's very unfortunate about that is that those messages are things that were they were a source of support  There were people in the same household  Trying to give each other the sort of attention and care  That that kind of situation deserves and that that is used against you in a court of law is a huge violation  so I think what was really really great to see from communities like this one was the outrage that  Companies like meta have a standard practice of not maintaining encryption for those communications  I think we all have an idea here of why we sort of have the ability  To use other things like we do as part of our work try to encourage folks to use encrypted chat to understand the value of  it  but that  Encryption should be by default and that's why I'm so grateful for the work of the other folks on this stage is because it should  Not be on one person to not make human mistakes in the course of something so extremely  Normal and needed and part of the human experience as getting an abortion  So I think like that is something I really want you to take with me just because I love the vibe in Defcon where it's like  Technology works this way, but I think it should work this way  And I'm gonna roll up my sleeves and do it myself, and I just absolutely love that  I think I've really taken from this that you know  We all have this sort of like digital body that law enforcement has chosen to go after those messages on meta  We're really critical for the case because physical bodies especially of pregnant ones  Do not cooperate with the criminal forensic standards. It is a very non-compliant experience  There is no drug test for an abortion medication  So generally speaking in order to form a case  Based on around an experience that many people have which is that pregnancies begin and pregnancies end  they have to use this digital body and the corpus of data that it's created and  Try to construct sort of your intention of the inside of your own head all of that is a tremendous violation  And they're going to keep utilizing as other folks have described  Pregnancy is sort of the good enough reason to violate your fourth and fifth amendment rights and break down encryption privacy and other technology rights across  The board so I'm really really grateful to work in community with all these folks  And pass it back because I know that was just a whole lot to absorb  But I know that I'm really really grateful as well for this community and your collective  Continued enthusiasm to make sure that we have the right not only to support our own communities ourselves and learn those skills  But also to change the environment that they operate in and yeah with that  I wanted to pass it back to the EFF crew and Cyndia. Thank you  Yeah, so you've heard from both Kate and daily some of the things that you can do individually to protect your own individual privacy and  to shore up your own individual security and  The thing is that's a lot and that's a lot of a burden to put on you right now  And it's particularly a big burden to put on somebody who is pregnant when they don't want to be or pregnant and something is going  wrong or  Just pregnant. I am currently pregnant  there's a lot that goes on with just being pregnant when you don't have to think about is my  Search history going to turn me over to the cops  And that's not a thing that should happen and so that's when we start talking about systemic change  We need to be making systemic change so the thing is laws can change and that cuts both ways  What we saw before a lot of times you hear like when we do this privacy work  We hear a lot of people say things like well  I have nothing to hide so I'm not really concerned all that much about my privacy  Well all of a sudden the Dobbs decision happened and people who previously had nothing to hide because abortion was legal all of a sudden  They have something to hide if you are a person of who is able to bear children  you probably have something to hide now and  There's a lot of things that are in your phone and are in your computer that  Can tell on you?  Sometimes to law enforcement with a warrant or a subpoena sometimes just because law enforcement asks nicely  sometimes because companies voluntarily turn that information over because they think you are  Trafficking children or something like that and so all of a sudden we all start to have need to start caring both about a  Comprehensive consumer data privacy law which does not exist in the United States  We also need to start thinking more about attacks on encryption and other ways to have private communications  So my name is India McKinney. I'm the director of federal affairs for the electronic frontier foundation  And so that's a fancy way of saying I'm a lobbyist  And so I will tell you that even though there's been a lot of  Conversation in the last couple of years in Congress about a consumer data a comprehensive consumer data privacy law  There is not currently introduced legislation that would protect the privacy of all Americans. It currently does not exist and  So if you think that's a problem  There's a phone number  There you need to call that phone number you need to ask to speak to your senator  You knew when they pick up the phone  You tell them your name you tell them your address and you tell them you want to see a comprehensive consumer data privacy law  And you would like a response  Then you call that phone number and you talk to your other senator  Then you call that phone number and you talk to that representative  You have three you make three phone calls if you don't want to do that  There's a website up there act.eff.org  We don't currently have an action about a consumer data privacy law because again the law doesn't exist what we do have is  Several different actions that are targeted against several active  Big big bills that are not directly targeted at either abortion access or privacy  But they are targeted at encryption or giving law enforcement more access to all of your communications  carve-outs in ECPA  direct attacks on encryption  Age-gating parts of the internet all of these things are actively being discussed in Congress as a way to protect children  And if you look at the language that Congress is using to talk about child  Exploitation child endangerment child trafficking and you look at the way pro-life people talk about abortion  it's actually the same language and  So you need to be really careful when you're hearing them talk about these bills that are going to save the children from the terrible  Things that happen on the internet of course there are terrible things that happen on the internet. We've all been on the internet  There are terrible things that happen on the internet. There are terrible things that happen in real life encryption is not the problem  but law enforcement has been  Extremely clear that they want to be able to access all of your messages  And they don't want to have to go through your phone to do it  They want to be able to just get it from the companies because again right now in the status quo  They can both  Subpoena the information they can just ask nicely for the information and in some cases  They purchase the information from a data broker because that's legal  They're using your taxpayer dollars to buy information on you that has been collected by data brokers  So if you think this is utter nonsense  There's a phone number where you can call and you can tell your senators that this is utter nonsense  So it works best if you have a specific thing that you want them to do  I want you to oppose the earn it act. I want you to oppose COSA  I want you to oppose the stop CSAM Act. I want you to oppose the Cooper Davis Act  Those are all the ones on act.eff.org if you don't want to talk on the phone just push some buttons  You can do it on your phone right now  And so the thing is those are the things that really actually matter to change  The discussion about making systemic changes right now  The reason there is no comprehensive consumer data privacy law is because they tried that last Congress and it turns out  It's really really hard to get right the law that was proposed the 80 PPA, and I don't remember what that stands for anymore  It was a good starting point  But there were a lot of holes in it that were not strong enough and the biggest one is it was going to preempt any  State laws for providing additional protections for their consumers in the individual states  So it's going to be a lower threshold and states weren't allowed to build on top of that which  Again, if you think that's utter nonsense. I have a phone number for you  So but then Congress we had elections. There's a new majority in the House of Representatives  The Senate has decided has openly said in multiple meetings. They are not interested in taking up consumer privacy for everyone  They're really more focused on helping the children and the House of Representatives  They've had hearings about a consumer data privacy law for everyone, but no text has been introduced because it's really hard  They got a lot of bad press. They got a lot of bad emails, and they just  Haven't done anything about that and so until there's the political will until there's political consequences because people like you  Create it. That's actually not going to change  So it's a little bit like  Again I am a political person not a computer person, so I'm going to totally butcher this analogy, but bear with me  We basically want to DDoS this issue  One person going to make a phone call on this yes  It doesn't move the needle if everyone here at Defcon makes the phone call clicks the button  sends the email goes to a town hall meeting and  Convinces other people to do that as well  That is going to have a massive overwhelming impact on how  The Congress as a body perceives this issue right now privacy polls extremely well  Do are you in favor of privacy 97% of people say yes?  We don't know what the other 3% of people are thinking maybe they're law enforcement. I don't know  But it's an overwhelmingly popular issue, but what does that mean?  What does that look like does it mean a private right of action so that the lovely feisty lawyers at EFF can bring a class  action lawsuit and  Actually make change, what does it mean?  So we really want to take your questions and get more into the heart of what this issue is  But I do want to make sure that I leave you with the call to action there are things that you can do right now  There are also things that you can do when you get home  Paying attention to these issues becoming a member of EFF and signing up for our emails and then taking all of the action alerts like  This is our day job. We want  to share this with you  And we actually really do need your help, and I do actually believe that if we all do this together. We can make a difference  All right, so there you have it  It's the trifecta of strategies, and we're gonna have to do them all at the same time  So now we have 15 minutes, and we would love to take questions  From the audience if you have questions for the technologists the lobbyists the litigator  Please go up to there's a mic right there in the middle  And we also if you if you would rather ask a question more anonymously  We have some paper and pens that you could come and it's like ninth grade health class  You have a question or two embarrassed to ask in front of everybody  Here, I'll hand these down, and we can kind of like leave them someplace  Okay, please go ahead. Thank you. I think you're first  Hello  Hi, thank you very much  Congratulations on your pregnancy. I feel very grateful to live in  California where I feel like my rights are more or less intact  What do you all think about period trackers am I being extremely paranoid to not want my daughter  to track her period online  Okay, I think these are really great protective instincts  I always love the question about period trackers because when they kind of blew through the news it was a wonderful opportunity for us to  Talk again about threat models  basically  Like we discussed a little bit before  Some of like that again that really first way that cases come to the attention of law enforcement tends to be like an interpersonal  Piece either a health care worker or someone who is close to you violating your privacy  So period trackers are very patently useful when I need to get an abortion  Especially if it's very sensitive. I need to know how pregnant  That's gonna like let me know whether I can use medication abortion which can be done very discreetly  It means it makes it helps me to know if I'm calling to go out of state where I need to go in which clinics  Can help me with my procedure. So this is a patently normal useful thing that we all benefit from  So, how do I do it safely as of right now period tracking apps are not  Tending to be like the way that that sort of surveillance is is again coming to the attention of law enforcement  Lots of period trackers have responded to a lot of that concern rightly  So and have disclosed a little bit more about how their different applications work  So there are some that are like yuki app EU ki which are local only to the phone  So they can have that kind of ability to track your period and also has a lot of great other sexual health information in there  That is only then not connected to the internet all that wonderful stuff other  Companies like clue have like posted way more comprehensive disclosures about how they would respond  should they receive any legal info requests and I think these are all the ideal like I think the  Sort of questions from the community and from consumers were excellent  And I want us to keep doing that because what happens is that companies come out of the woodwork who are like actually I think  I feel pretty confident in the way that we handle this particular problem, and I'm excited to share with you  That same entitlement and expectation you should have to it being  Entend encrypted or working only on my phone or a combination of the above so I would say that there are safe options to use  for your personal threat model  And that it's a great opportunity to explore them with your daughter and learn together kind of like what's what's most important to each of?  You and get to practice it together, which is really cool, so thank you for your question  Hello so first of all I just want to say thank you so much for what you're doing for the community  It means a lot to me. I don't have a question  I just have a comment that I wanted to make with the end-to-end encryption applications that you guys are recommending folks to use  Especially with the point that you brought up with the the cloning of the mobile devices  And that being able to be leveraged against folks trying to get abortions or have  so  Highlighting the point that end-to-end encryption only happens in transit so once it's actually on that device if that's cloned  The whole end-to-end encryption kind of goes out the window, so I just want to highlight that for you ladies  Especially if you're advocating for our community, so thank you  Yeah, that's absolutely true  And so that's actually one of the things that we bring up like I don't want to tell law enforcement how to do their job  But you know when the January 6th  Event happened in the Capitol a lot of those  activities were  Organized over signal and whatsapp and other encrypted platforms and law enforcement still got access to those messages because they did you know old-fashioned policing where they  Turned some of the witnesses and participations and people voluntarily opened their phones and sent them screenshots and sometimes they got things from like  Family members girlfriends you know again the personal connection  So they still got access to the messages without having to break encryption, so that's definitely again  That's the thing that cuts both ways, but when law enforcement rings their hands. It says we just can't get any of it  That's actually not true absolutely  Great you, thank you  Hi, I really appreciate what you've done here the problem that I can see is that there are a lot of folks that are not  in this room  So my request is could you put together?  Not best practices because best practices generally don't stay that way or aren't in the beginning  Can you put together some really good practices for now?  And make those available in some way that the folks who need this information whether it's from a technology a  legislative or a practice basis  Can learn what's the best way that they can approach this issue that they're trying to deal with?  Make it ubiquitous and make it simple  Yeah, so we at least at EFF. We've actually tried to put together a whole bunch of resources  In different forms so we have the surveillance self-defense work that that daily was talking about and then there's also  We've written a lot for other audiences on the blog like what companies can do now and should be doing right now  If they don't want to be honey pots for law enforcement. We that wasn't the title, but that was meaning and  so we we have tried to do the to put that those resources together and  But they always have to be updated  There's an issue tag on  On EFF for reproductive justice, so you can go there to find all of the blogs associated with this topic  And then over on ssd.eff.org you can find that playlist for the specific  tech advice and general information security advice we give  Great question yeah, and I just threw out your URL for our guide in case a digital defense fund org you can just go right there  Next thank you  Yeah, my question is kind of along the same  Avenue, I'm from Washington State  And I was actually one of the people that worked really hard to get our my health my data  Bill passed which gives us  In Washington State not just women, but men all of our health data  actually needs to stay private and not trackable and  Of course when I was advocating for this  So many legislators do not understand  The internet one person from my own district actually had an amendment to exclude small businesses  from this  Law and I was like so Apple health tracker  Can now just spin off and be an LLC now it is a small business  And it can continue to track your data and trade and sell it  So I'm wondering if the EFF has a way to help simplify  What we're asking for but to also help educate the legislators who are like oh that computer stuff  I just don't understand it, and I'm like well that computer stuff. You are making laws about it  So you should understand it  So there's actually a federal bill in both the House and the Senate called my body my data  Which is a law that would provide privacy protections at?  The federal level for reproductive and sexual health data so again  You can call that phone number and you can tell your representative to support my body my data in whatever chamber  They're in and you can also that since the bill exists you can share it with your local  State people and say this is the law  Start here don't  Give us less than this right, and I do know one thing a lot of people in Washington State the legislators were saying  Oh, they can't just do this for Washington State and not the other 49 states and my husband's like well  We do it for the European Union  so  Already even though we have this bill my health my data  It is not equal to the privacy the EU has and it's not even perfect there  But that's good to know I just want you to know legislators are like explain  Yeah, what exactly does this mean?  Yeah, so we have seen that before but and there's a lot of education that always has to be done  But two things I would say is that one things  I actually think it is powerful to have protection for health data for everybody so we bring it in right. It's not like  Men don't also want that or people who can't get pregnant or awful also want data privacy protections  But the other thing I would say is you should never hesitate to start in your state  The only reason there is any discussion right now about or there was last year of actual federal a real federal bill  Is because California passed a really strong privacy  Privacy bill it wasn't perfect, but it was very strong and all of a sudden a lot of tech companies are like wait what no  No, we don't want to have to comply with 50 different state bills, and then you can say okay fine good  Let's have a federal bill, but let's have it be strong and not weaker than California's  Great, I believe Washington state bill is actually stronger than California real quick  Did we have any sheets that to come back the little?  Anybody had any anonymous questions anonymous questions. No all right. That's okay next question  Thanks  Thanks for sharing your ideas on this space. I feel like I just can you be louder  Sorry I feel like I just opened my eyes to this topic um I quite couldn't quite understand  your definition of  Autonomy yeah, can you repeat that and secondly you said Defcon?  Nurtures autonomy like the culture. Can you connect the idea again for me I?  Love to come back to that yeah  I think honestly one of the things that and this is very personal like this is not like a dictionary definition of autonomy  But I really enjoyed how when I came to Defcon there was sort of this idea that like a piece of technology is given  To you we have these like materials computers. We have systems  We have how we interact with other people  And you sort of have the right to kind of like make him or your own like a prism through which you get to act  Out what you will and your perspective on the world, and I just really felt very inspired by that  I think it's really wonderful to get to walk into any village and  Try something for yourself and to direct your own learning and to just have that sort of spirit that  All of this is for you and for you to express yourself here  So I think like you know I don't know I think my ideas of autonomy are like changing all the time  I think all of us who like work in this space you sort of have these  Aha moments where you're like wow I see parts of how the world fits together, and it's really really remarkable  So I think this is one of the many places that happens for me  I don't know if anybody else on this table wants to speak to what autonomy means to you  As a technologist now all right  Hi there, so I'm  Excuse me. I'm trans so thank you for acknowledging the intersectionality between  Trans rights and abortion rights and all of the other  things  One thing I just wanted to ask  What would you advise people who say they're in the middle of having an abortion or getting their kid?  gender-affirming health care something like that  And they may suspect that they've started to become a target of an investigation or something  Or if their state has changed their rules  How would you advise those people to handle that because of course it's not the crime. It's the cover-up and you know  How do they deal with the potential evidence that might be within their devices and their information?  I  Would start with the non-technical stuff first because it's the easiest to approach for people. It's a lot less scary  Pen and paper exercises are great. So like device mapping and to network mapping. I mean like social network mapping  is usually a really accessible point for people because they can identify the people that they have already given trust to and  Then they will begin to formulate how to speak with those people  About this new concern they have and loop them in in the process and make it again a team sport  That's huge, right?  I would also then from there begin to develop some secure communications methods with those people they've identified that already have that trust and  I mean secure communications in the non-technical way first, right?  and  You could maybe come up with some careful language or some rules some community standards about how to broach the topic and how?  To broach it in different contexts when in different contexts if that makes sense  You can get really tricky with it if you want to do like linguistic steganography or if you're like a history nerd Polari type  like code switching of language  But that's usually like really accessible for folks and it also introduces some really fundamental  Infosec or privacy concepts that translate quite nicely to the technologies  they'll eventually want to start incorporating like encryption technologies or good backup games or  etc  Thank you, thanks for the question, I think we have time for one or two more  Hello  Hello, my question is more about civic engagement. I live in a real  Speakers all face that way. Yeah  Okay, my question is more about civic engagement. I live in a really majority strong district where I have  unresponsive  Congressional representatives and so my question is is it a framing issue?  How do you how do you approach people whose viewpoints just are way different than what can I do as a  constituent in those like areas to make it more effective because I've called and I get form responses and they don't really seem to  Want to engage with a voter who's a minority in their district for with regards to like political affiliations and so on  Yeah, so the thing is abortion is obviously a super polarizing political issue  But a lot of the things that go into protecting abortion rights are not  There's a lot of reasons that you are interested in protecting individual privacy that have nothing to do with abortion  there's a lot of reasons that you want to  Protect the ability to have a private conversation digitally that have nothing to do with abortion  And so this is really a nonpartisan issue  Encryption is supported by members of both parties in Congress  Encryption is also being attacked by members of both parties in Congress. It's really nonpartisan  So there is a little bit of code-switching depending on which office you're going to talk to but  Giving the government the ability to read all of your messages  Just because they feel like it or for funsies like that rightly terrifies a whole lot of people across the political spectrum  So it doesn't really matter if you're talking to a progressive caucus member or a freedom caucus member  that's something that is  Scary and so if you protect some of the tools you end up protecting the rights of people who need it for different reasons  Thank you  Great question  So I went to both of the websites and this is a challenge I put to both  both groups and I've been involved in political action before so I talked from some area of expertise is  that's what's missing from both websites is a pamphlet a  Set of directions Q&A  About how to talk to the uncle Bob who does not understand the word  Encryption and his version of privacy is drawing the blinds on the window and that's privacy to him  so the thing is is that on both of your websites it is  Call to action to go call a Congress critter, which is fine or a state representative, which is fine  But there's nothing there on either one of your websites as far as I can tell and I looked at both URLs  That say how to persuade members of your family  and I can tell you that I've worked on local issues and gotten local issues passed is  That was the way that we got our issues passed when we were going up against big big dollars  the California Realtor Association  So the thing is is if you can't give somebody a how to talk to the uncle Bob  And they can't persuade uncle Bob. I  Found that the people who are budding activists pull back into their shell  They lose confidence to make that phone call to their Congress critter  So that's what I'm calling out both groups on is that you were worried about talking to uncle Bob  Congress critter, but not uncle Bob, please do the uncle Bob persuasion  Thank you. Thank you. Okay. Thanks so much  Yes, I will  We'll make this our last one. Thank you. Hi just a  Question and a comment related to some of what's being said  So I currently live in the political hellscape and abortion hellscape that is, Texas  And you know, so I'm worried about my daughter her friends, etc  And I think a lot of it comes down to just simple narrative simple stories the ability to hand over  Some again pamphlet was used as a term but use this technology  Don't use that technology use this method of travel. Don't use this method of travel  What is the simple guides that you can hand to somebody that is, you know?  Here's the ten things to think about I think that's critical in my opinion  I  Totally agree with you and I think this is a wonderful note to close out on because I get to connect you to some other  Amazing resources all of the groups that have operated in Texas in and other states that are now banned states  to date have  Taken on this work  I mean frankly how we learn how to do it a digital defense fund is by seeing how they connect directly with patients and  Work to like we work together to translate some of this like advice into something  That's reasonable for someone who is like going through the experience right now  So I would say that organizations like Jane's due process have amazing content directed at teens  That is like absolutely there to not only help, you know, what your rights are to help with accurate information  But also each of them is their own amazing digital security expert in the field knowing what folks deal with  so I'm so glad that like you are there supporting your daughter and all of her tears because  Now there are all these amazing organizations that can support all of you as a family and community  So thank you so much for sharing that. I really appreciate it. Thank you for what you're doing. It's critical  All  Right, thank you all so much for coming. I just want to flag that a very kind person gave us a few  boxes of plan B and informational information  Packets they're right here. There's just a few but  Perhaps you or a friend would like to have one on hand. If so, come and grab it  Yeah, come grab some plan B  These are real like I give these out at every event we're at and if there's always a huge hit pack them with some  You know sour gummy candies and people really go nuts  Thanks for being here, thanks for coming


# MediaVersion

created_at: 2024-08-03 09:12:15
prompt:
                                      <s>You are a bulleted notes specialist. [INST]```When creating comprehensive bulleted notes, you should follow these guidelines: Use multiple headings based on the referenced topics, not categories like quotes or terms. Headings should be surrounded by bold formatting and not be listed as bullet points themselves. Leave no space between headings and their corresponding list items underneath. Important terms within the content should be emphasized by setting them in bold font. Any text that ends with a colon should also be bolded. Before submitting your response, review the instructions, and make any corrections necessary to adhered to the specified format. Do not reference these instructions within the notes.``` 
  Based on the content between backticks create comprehensive bulleted notes.[/INST]
                                          **Bulleted Note Creation Guidelines**
                                          
                                          **Headings**:
                                          - Based on referenced topics, not categories like quotes or terms
                                          - Surrounded by **bold** formatting 
                                          - Not listed as bullet points
                                          - No space between headings and list items underneath
                                          
                                          **Emphasis**:
                                          - **Important terms** set in bold font
                                          - **Text ending in a colon**: also bolded
                                          
                                          **Review**:
                                          - Ensure adherence to specified format
                                          - Do not reference these instructions in your response.</s>[INST] {{ .Prompt }} [/INST]
                                      

summary:
  **Introduction**
  - The speakers are vocational high school students from Medford, Massachusetts, with an interest in making and breaking things.
  - They are part of an underwater robotics team called Sunk Robotics.
  - Their talk will cover how they reverse-engineered Boston's CharlieCard fare system, with the potential for free rides.

  **The Massachusetts Bay Transportation Authority (MBTA)**
  - The MBTA is Boston's public transit agency, managing buses and subways.
  - It is the oldest transit system in the country.
  - Fares for the subway are $2.40, and for buses, $1.70.

  **Previous Hacking Attempts**
  - Around 15 years ago, MIT students hacked the MBTA's trolley tickets, adding values of up to $600.
  - The MBTA obtained a restraining order to prevent the students from presenting their research at DEF CON.
  - The research was released into the public domain, inspiring the speakers.

  **Initial Attempts**
  - The speakers chose to focus on the MBTA's trolley cards, assuming they used NFC or RFID technology.
  - They purchased various NFC readers, eventually settling on the PN532 model, which worked successfully.
  - They discovered that the cards used MyFair Classic, an infamous flavor of the MyFair standard, with a proprietary 48-bit encryption algorithm.
  - They obtained the necessary encryption keys from a publicly available repository.

  **Cloning Cards**
  - The speakers were able to clone cards by copying data from one card to another, using a process called XOR.
  - Cloned cards can be detected and disabled by the MBTA.
  - Cloning requires an upfront investment, and if a card is disabled, the money is lost.

  **Forging Cards**
  - Forging cards involves reverse-engineering the data storage and manipulation process.
  - The speakers examined hex dumps of card data, looking for patterns related to money values.
  - They discovered that the money value is stored in half-penny increments and that there are two transaction registers.
  - They developed a repeatable strategy to create cards with a value of up to $327.67.

  **Reverse Engineering Process**
  - The speakers isolated variables and used XOR operations to modify card data.
  - They created a lookup table to automate the process and refined their strategy to avoid adding quarters each time.
  - They were able to create cards with custom values and card types, such as employee cards.

  **Disclosure to the MBTA**
  - The speakers contacted the MBTA to disclose their findings, inspired by a similar story involving Bobby Roush.
  - The MBTA invited them to their headquarters to discuss their research and how to prevent future incidents.
  - The speakers demonstrated their ability to edit card information, including money value and card type.

  **Conclusion**
  - The speakers emphasize that their research should not be used for illegal purposes.
  - They thank the audience for their attention and invite further questions.


created_at: 2024-08-03 09:18:12
prompt:
                                      <s>You are a bulleted notes specialist. [INST]```When creating comprehensive bulleted notes, you should follow these guidelines: Use multiple headings based on the referenced topics, not categories like quotes or terms. Headings should be surrounded by bold formatting and not be listed as bullet points themselves. Leave no space between headings and their corresponding list items underneath. Important terms within the content should be emphasized by setting them in bold font. Any text that ends with a colon should also be bolded. Before submitting your response, review the instructions, and make any corrections necessary to adhered to the specified format. Do not reference these instructions within the notes.``` 
  Based on the content between backticks create comprehensive bulleted notes.[/INST]
                                          **Bulleted Note Creation Guidelines**
                                          
                                          **Headings**:
                                          - Based on referenced topics, not categories like quotes or terms
                                          - Surrounded by **bold** formatting 
                                          - Not listed as bullet points
                                          - No space between headings and list items underneath
                                          
                                          **Emphasis**:
                                          - **Important terms** set in bold font
                                          - **Text ending in a colon**: also bolded
                                          
                                          **Review**:
                                          - Ensure adherence to specified format
                                          - Do not reference these instructions in your response.</s>[INST] {{ .Prompt }} [/INST]
                                      

summary:
  **The Problem of Platform Enshittification:**
  - Platforms mediate between **end users** and **business customers**.
  - Initially, platforms are good to their users, but eventually, they abuse both users and business customers to **claw back value** for themselves.
  - This leads to **platform decay** and an "inshittening."

  **Case Study: Facebook:**
  - Facebook started as a platform for ranking the **fuckability** of Harvard undergraduates.
  - It promised users privacy and a personalized feed but later withdrew this surplus and allocated it to advertisers and publishers.
  - Facebook exploited **high switching costs** and **network effects** to lock in users, advertisers, and publishers, creating a **hostage situation**.
  - It then withdrew surplus from all groups, leaving just enough value to keep them stuck to the platform.

  **Three Stages of Platform Inshittification:**
  - Eliminate **competition** through **predatory pricing** and **acquisitions**.
  - Use **universal computers** to **twiddle knobs** on the back end, altering deals without constraint.
  - Criminalize **adversarial interoperability** through **IP laws**, preventing users from twiddling back.

  **How to End Inshittification:**
  - **Halt consolidation** and **break up big tech companies**.
  - **Limit twiddling** by passing comprehensive **privacy laws** and ending **worker misclassification**.
  - **Open up walled gardens** with **mandatory APIs** to restore low switching costs and enable interoperability.
  - **Align tech giants' incentives** by restoring the right to mod, tinker, reverse, and hack services.
  - **Block mergers** and **unwind existing ones**, restoring antitrust enforcement.

  **The Role of Hackers:**
  - Hackers can exploit **adversarial interoperability** to drain users and revenues from inshittified companies.
  - They can also help keep interoperators honest by ensuring they are bound by **privacy**, **fair trading**, and **labor laws**.
  - Hackers should spread good ideas and prepare for the next crisis to ensure it's not wasted.

  **The Future of the Internet:**
  - We can have a new good internet that is a worthy successor to the old one.
  - It should be operated by and for the people who use it, with open, federatable, and hard-to-capture services.
  - This requires limiting the power of tech giants and restoring our ability to twiddle back.


created_at: 2024-08-03 09:24:39
prompt:
                                      <s>You are a bulleted notes specialist. [INST]```When creating comprehensive bulleted notes, you should follow these guidelines: Use multiple headings based on the referenced topics, not categories like quotes or terms. Headings should be surrounded by bold formatting and not be listed as bullet points themselves. Leave no space between headings and their corresponding list items underneath. Important terms within the content should be emphasized by setting them in bold font. Any text that ends with a colon should also be bolded. Before submitting your response, review the instructions, and make any corrections necessary to adhered to the specified format. Do not reference these instructions within the notes.``` 
  Based on the content between backticks create comprehensive bulleted notes.[/INST]
                                          **Bulleted Note Creation Guidelines**
                                          
                                          **Headings**:
                                          - Based on referenced topics, not categories like quotes or terms
                                          - Surrounded by **bold** formatting 
                                          - Not listed as bullet points
                                          - No space between headings and list items underneath
                                          
                                          **Emphasis**:
                                          - **Important terms** set in bold font
                                          - **Text ending in a colon**: also bolded
                                          
                                          **Review**:
                                          - Ensure adherence to specified format
                                          - Do not reference these instructions in your response.</s>[INST] {{ .Prompt }} [/INST]
                                      

summary:
  **Introduction**
  - Speaker: Patrick Wardle, founder of the Objective-C Foundation
  - Topics covered: Apple's macOS Background Task Management (BTM), reversing malware detection, macOS internals, etc.

  **Background Task Management**
  - **Overview**: Introduced in macOS 13, BTM governs and consolidates **persistent items** or "background tasks."
  - **Persistent items**: Processes that automatically re-execute upon system reboot or user login (e.g., auto-updaters, malware).
  - **BTM's Visual Indicators**: When an item is installed that persists, three things happen:
      - A system alert informs the user.
      - A security message is broadcast, notifying security tools.
      - The item is registered in the BTM database.

  **Why BTM Matters**
  - **For Defenders**: Provides a centralized subsystem to manage and detect persistent items, including potential malware.
  - **For Hackers**: Poses challenges due to user alerts and security messages, requiring new approaches for silent persistence.

  **Internals of BTM**
  - **Log Analysis**: Analyzing logs with full logging capability enabled provides insights into BTM's components and behavior.
  - **Key BTM Components**:
      - **SMD (System Management Daemon)**: Monitors file system events and communicates with BTM via XPC messages.
      - **BTM Daemon**: Core component that manages persistent items, updates the BTM database, and interacts with other processes via XPC.
      - **BTM Agent**: Displays user alerts and notifications regarding persistent items.
  - **BTM Database**: Contains information about all persistent items, but it's proprietary and undocumented, requiring reverse engineering to access.

  **Writing Tools to Leverage BTM**
  - **Dumping the BTM Database**: Apple's SFL tool can dump the BTM database, but it requires a private entitlement. Reverse engineering SFL tool reveals methods to deserialize database objects programmatically.
  - **Open-Source Library: dump BTM**: Allows developers to query the BTM database and integrate BTM functionality into security tools.
  - **Real-time Persistence Detection**: macOS's Endpoint Security subsystem allows security tools to register for notifications when persistent items are added or removed. However, the removal event is currently broken.

  **Bypassing BTM**
  - **Overview**: Bypassing BTM involves suppressing user alerts and preventing endpoint security messages from being delivered.
  - **Method 1: Resetting the BTM Database**: Using Apple's SFL tool to reset the database confuses the BTM daemon, preventing the user alert. Requires root access.
  - **Method 2: Suspending the BTM Agent**: Sending a stop signal to the BTM agent (running as the user) prevents the user alert from being displayed.
  - **Blocking Endpoint Security Messages**: Analyzing the BTM daemon's code reveals a kernel bug where the responsible process for persistence is not found, causing an error and preventing the endpoint security message.

  **Detecting BTM Bypasses**
  - **Resetting the BTM Database**: Write a process monitor to detect when the SFL tool is used to reset the database, or use endpoint security events to block the reset command.
  - **Suspending the BTM Agent**: Use endpoint security to register for signals and block the stop signal from being sent to the BTM agent.
  - **Endpoint Security Notifications**: While the BTM launch item add event is bypassable, file notifications (e.g., notify create, notify write) are not susceptible to the kernel bug and can be used for persistence detection.

  **Takeaways**
  - BTM, despite being a new security feature, is poorly implemented and trivial to bypass, leading to a false sense of security for users and security tools.
  - The speaker's non-profit organization focuses on Mac security and raises money for various causes, including recent wildfowl relief efforts in Maui.
  - The speaker has written free books on Mac malware, reverse engineering, and security tool development, with Volume 2 covering topics discussed in the talk.


created_at: 2024-08-03 11:20:58
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Speakers: Christian Dildog-Ryu and Caitlin Medusfor Bowden, members of the Cult of the Dead Cow
  - **Veilid** is an open-source, peer-to-peer, mobile-first networked application framework.
  - Veilid aims to provide a **privacy-focused communication platform and protocol** to defend human and civil rights.

  **Overview of Veilid**
  - Veilid is conceptually similar to **IPFS** + **Tor** but faster and designed for private, decentralized communications.
  - Written in **Rust**, Veilid runs on various platforms (Linux, Mac, Windows, Android, iOS, WASM).
  - Uses standard internet protocols: **UDP**, **TCP**, and **WebSockets**.
  - All nodes are equal, and the network gains strength from popular apps, supporting less popular ones.

  **Design Goals and Features**
  - **Security** and **privacy** are paramount, with strong cryptography and private routing.
  - **Resiliency** to handle mobile networks and context switching.
  - User-friendly and accessible to everyone, not just technically inclined individuals.
  - **Upgradable crypto system** to future-proof against technological advancements.
  - **Secure storage** with encryption and device-level secrets (keychains, key stores).
  - **Distributed hash table (DHT)** for efficient data storage and retrieval.
  - **Private routing** to protect IP addresses, similar to Tor but with enhanced privacy and speed.

  **Cryptography and Security**
  - **VLD zero** cryptography suite includes ed25519 for authentication, Curve25519 for key exchange, and XSalsa20-Poly1305 for encryption.
  - **Message digests** use Blake3, and key derivation uses the 2015 Password Hashing Competition winner.
  - **Upgradable crypto system** allows for future changes without disrupting existing data.
  - **Private routing** ensures neither node can control the entire route, protecting against adversarial nodes.

  **Development and Community**
  - Veilid is written in **Rust**, with crates available on GitLab and soon on crates.io.
  - Power users can run their own **Valid Server** with packages available for Debian, APT, and RPM.
  - Supports multiple programming languages: **Flutter**, **Dart**, **JavaScript**, and **Python**.
  - Community engagement: Twitter, Mastodon, Discord, and GitLab.

  **Conclusion**
  - Veilid aims to provide a privacy-focused communication platform accessible to everyone, protecting human and civil rights.
  - By combining strong cryptography, private routing, and decentralized storage, Veilid offers a secure and resilient framework for applications.
  - The project welcomes contributions from coders, hackers, and regular people to build a diverse and inclusive community.


created_at: 2024-08-03 11:25:53
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction:**
  - Talk presented by **Donnie Kim**, a security IT expert at the Security Office, based in Sweden and South Korea, and part of the Tracer group.
  - In May 2020, it was revealed that **eBay** and other companies were **port scanning** their visitors' computers via their websites, with the tool suite of a firm called **Threatmetrics**.

  **Browser-Based Port Scanning Implications:**
  - **Privacy**: Can be used to **fingerprint** visitors, tracking them with unique characteristics.
  - **Security**: Can uncover internet services that are a foothold for subsequent attacks like **XSS** or **CSRF**.
  - Various techniques have been used, including image and iframe tags, script tags, and exploits employing **WebRTC** and **WebSocket**.

  **Timing-Based Techniques:**
  - Focus on measuring the **timing** of network requests using the **Fetch API**.
  - Restrictions imposed by browsers and web specifications limit observable data to elapsed time and some generic error data.
  - Four components responsible for round-trip time: **browser**, **firewall**, **TCP**, and **TLS+HTTP**.

  **Hypotheses on Port States:**
  - If the port is closed and the firewall drops packets or the host is unreachable, the observed time is theoretically infinite (typically an arbitrary timeout is enforced).
  - If the port is closed and the firewall rejects packets, the browser and firewall will take up the observed time.
  - If the port is open and a process is listening, all four components will contribute to the observed time.

  **Finding Open Ports on Localhost:**
  - Localhost specifics: Firewall always rejects packets when the port is closed, and the host is always reachable.
  - Algorithm:
     - Make multiple fetches to a generally closed port (e.g., port 2) and calculate the average timing as a control.
     - If a fetch takes similar time as the control, the port is closed.
     - If a fetch takes significantly more time, the port is open.
  - Repeat the algorithm against various ports of interest to get a list of open ports.

  **Finding the Router on the LAN:**
  - Only need to determine if the host is responsive or not, regardless of the port state.
  - Algorithm:
     - If a fetch times out, the host is unresponsive.
     - If a fetch ends before the timeout, the host is responsive.
  - Repeat the algorithm against a list of potential router IPs and ports to find live routers.

  **Finding Open Ports on LAN Clients:**
  - New web standard: **Private Network Access** in Chrome restricts requests to private network resources from HTTPS web pages.
  - HTTP requests to LAN clients from an HTTP web page will return a **CORS** error with a generic "failed to fetch" string.
  - CORS check happens after the TCP connection is successful, indicating an open port.
  - Algorithm:
     - From an HTTP web page, take measurements using HTTP and HTTPS.
     - If there is no difference between the observed times, the port is closed, and the firewall rejects packets.
     - If HTTPS fetch is significantly slower than HTTP, the port is open, and a process is listening.
  - Repeat the algorithm against various LAN clients and ports of interest.

  **Proof of Concept: Your LAN.js:**
  - Demonstrates all three techniques: finding open ports on localhost, finding the router, and finding open ports on LAN clients.
  - Scanning process can take several minutes to complete.
  - Able to find various open ports and devices on the LAN, including Airplay, Google Cast, LG Smart Device, Dyson, SMB, Homebridge, router interfaces, and a Philips Hue light bulb.

  **Limitations and Takeaways:**
  - Research limitations include the possibility of **false positives** and **false negatives**, as well as the existence of more complex scenarios.
  - **Tor Browser** declines any requests to localhost and local IPs, providing privacy and security.
  - Use **ad blockers** to prevent malicious tracking scripts.
  - **VPNs** can be a mitigation as long as they allow access to the user's local network.


created_at: 2024-08-03 11:36:49
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Speaker: Fredrik Alexander, aka Stöck
  - Topic: Weaponizing plain text ANSI escape sequences as a forensic nightmare
  - **Table of Contents**: Not provided, 281 slides to be covered

  **ANSI Escape Sequences**
  - A **vulnerability class** (CB150) that allows **arbitrary code injection**
  - Can be used to **inject, vandalize, and weaponize log files** of modern applications
  - **Commonly used** by developers, security teams, and incident responders for **maintaining application reliability, performance, and security**
  - **CVE** (Common Vulnerabilities and Exposures) reference: arbitrary code injection in Rack, Lint, and Common Logger components

  **Log Files**
  - **Important** for creating a **good timeline** during incident response
  - Can be **compromised** by injecting **malicious content**
  - **Trustworthiness** of log files is crucial for effective incident response

  **Example Scenario**
  - Incident response lead of a global logistics corporation receives a call about a breach
  - Needs to collect and analyze log files to create a timeline of the incident
  - Uses a **big data application** to export and save log data locally
  - Upon reviewing the log file, encounters an **advertisement** for a data recovery service
  - **ANSI escape sequences** are the cause of this unexpected content

  **Terminals**
  - Variety of terminals used today, including built-in, third-party, and older versions
  - e.g., VS Code, Docker, iTerm, Kitty, Windows Terminal, Terminal.app, GNOME, VTE, Xterm
  - Each terminal has its own set of features and functionalities

  **Control Sequences Standard**
  - Standard for Xterm, covers **cursor movement, key remapping, printing, UI building, etc.**
  - **CSI** (Control Sequence Introducer) tells the terminal to execute a command
  - **Parameters** specify the action to be taken, e.g., changing text color
  - **ST** (String Terminator) or **bell character** ends the sequence to reset the terminal

  **Demonstration**
  - Using **Vim** or **Nano** to view log files will display **escape sequences** without rendering them
  - **Browsers** interpret escape sequences and display them as **Unicode**
  - Tools like **cat**, **grep**, **tail**, and **curl** will **render** the escape sequences

  **Log Injection**
  - Injecting **ANSI escape sequences** into log files can have various impacts
  - **Docker** is a good test bench due to its extensive use of logging and terminal rendering
  - URL-encoded escape sequences can be injected into Docker logs to change text color
  - **Newline** characters are important for creating false log entries

  **Impact of Log Injection**
  - Can **change terminal titles**, potentially tricking users into executing commands
  - **OSC 2** sequence allows changing the terminal title and reading it back to the command line
  - **OSC 8** sequence can create clickable links in the terminal, potentially leading to command execution
  - **OSC 52** sequence enables clipboard functionality, allowing command injection via paste

  **Polyglot Injection**
  - Combining multiple injection techniques to target different terminals and shells
  - Using **base64 encoding** to inject commands that run in different environments
  - Exfiltrating data by including JavaScript code in the injected content

  **Hiding Tracks**
  - Techniques to hide or obscure injected content:
    - **Cursor movement**
    - **Clearing the screen** or **scroll buffer**
    - **Resetting the screen** to empty the log file
    - **Printer prompt** to continuously send output to a non-existent printer buffer

  **DoS and Bricking**
  - Techniques to cause Denial of Service (DoS) or brick terminals:
    - **Mouse tracking** functionality to execute commands when the user clicks
    - **Repeating graphic characters** to fill the terminal screen with output
    - **Device Control Request String** to escape out of running processes and execute commands

  **Responsibility and Prevention**
  - Ongoing debate about responsibility: developers, terminal creators, or users
  - **Sanitizing input** and **escaping output** are crucial to prevent issues
  - Black box testing for log injection vulnerabilities: look for **400** and **500 errors**
  - **Nuclei template** can be used to scan for potential vulnerabilities

  **Conclusion**
  - The old is the new new: exploring old vulnerabilities with new techniques
  - Encouraging the creation of a community to further explore and secure ANSI escape sequences
  - **Log files**: Do you still trust them?


created_at: 2024-08-03 11:45:54
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Speaker: Joseph Gabay
  - Topic: Reverse engineering and bypassing the security features of a new type of smart shopping cart wheel, the Rocateq system.

  **Background**
  - Previous work: Gabay previously presented on a similar topic at DEF CON 2 years ago, focusing on ultra-low-frequency communication and how to sniff and replay signals.
  - New brand of wheel: Rocateq, with a focus on anti-shoplifting features.
  - Disclaimer: This project was conducted on personal time with personal equipment, and does not reflect the speaker's employer or professional work.

  **Overview of Smart Shopping Cart Wheels**
  - **Function**: Prevent cart removal or shoplifting, and provide tracking functions.
  - **Common features**: Ultra-low-frequency communication (around 10kHz), mechanical braking mechanism, and the ability to receive lock and unlock commands.
  - **Manufacturers**: Gatekeeper Systems and Rocateq.
  - **Locking mechanisms**: Internal wheel expansion, or a plastic piece covering the wheel to prevent forward movement.
  - **Perimeter wire**: Buried wire in parking lots or integrated into supermarket tiles, broadcasting a radio signal at ultra-low frequencies.

  **Previous Methods for Capturing Signals**
  - **Loop stick antenna**: Ferrite core and enamel wire wound together, soldered to a headphone jack to trick devices into thinking it's a microphone.
  - **Drill**: Used to wind the antenna, with a little balancing for impedance matching.
  - **Phone**: Older model with a headphone jack, used to record signals as audio files.
  - **Playback**: Signals can be played back through a speaker to control the shopping cart.

  **Rocateq System**
  - **Discovery**: The speaker's father acquired a locked Rocateq wheel, prompting further investigation.
  - **Marketing materials**: Emphasize RF receiver for data upload and download, and long battery life.
  - **FCC filings**: Provide detailed information on frequencies, bands, and test procedures for Rocateq's systems.
  - **Perimeter lock signal**: Prevents carts from leaving the parking lot.
  - **Arming lock signal**: Activates when carts are brought into the market, triggering a lock if they're taken out again.
  - **Unlock signal**: Unlocks a locked cart.
  - **Megahertz-level alarm mute**: Mutes the alarm.
  - **Per-check signal**: Sent from the checkout counter to the wheel, indicating payment and allowing exit without triggering the alarm.

  **War Shopping**
  - **Equipment**: Laptop, SDR, loop stick antenna connected to a phone, audio recorder app, and GQRX for signal recording.
  - **Procedure**: Engineer a situation where the cart locks, capture the unlock signal sent by the store clerk, and analyze the signals.
  - **Signals captured**: Perimeter lock, arming lock, unlock, megahertz-level alarm mute, and per-check signals.
  - **Per-check signal analysis**: Played back as a sound, this signal can be used to unlock the shopping cart.

  **Freaking the Wheels**
  - **Definition**: Using unconventional signal methods to gain control, inspired by John Draper's use of a toy whistle to access phone admin mode.
  - **Parasitic EMF**: When current passes through a wire, it creates a magnetic and radio field, which can be used to transmit signals at audio frequencies.
  - **Speaker playback**: By playing the right audio file through a speaker at a loud volume, it's possible to control the wheels and send lock and unlock signals.
  - **Inconsistent results**: The Rocateq wheels didn't always respond, leading to further investigation.

  **Reverse Engineering**
  - **Scope**: The depth of investigation is limited by time and resources, requiring careful selection of areas to focus on.
  - **Physical disassembly**: Purchased Rocateq wheels from eBay for destructive testing.
  - **PCB analysis**: Front and back images overlaid to trace connections, revealing a programming header and a missing chip footprint.
  - **Microcontroller**: PIC18F23K20, lacking 2.4GHz capability despite marketing claims.
  - **Mystery chip**: Labeled N100B with DE4, possibly an accelerometer sensing motion to conserve battery power.
  - **Unpopulated header**: May be intended for future 2.4GHz capability or advanced communications, but currently unused.

  **Debugging and Logic Analysis**
  - **PIC kit**: Used to connect to the microcontroller, revealing program memory, configuration bits, and EEPROM data.
  - **Code protection**: None of the security bits were set, allowing code to be pulled off the microcontroller and analyzed with Ghidra.
  - **Limited code**: Only about 2KB of actual code found, suggesting basic functionality and no encryption or data uploading/downloading.
  - **Logic analyzer**: Used to capture signals during boot, revealing that the wheel only listens for signals when in motion, likely for battery saving.
  - **Signal processing**: Passive components may be used for radio signal processing and basic mathematical operations to reduce processor load.

  **Bypass Methods**
  - **Per-check signal replay**: Play the per-check signal to the wheel to indicate payment and allow exit.
  - **30-second disarm**: Bring the cart out, then back to the buried line within 30 seconds to re-enter the idle state.
  - **Lock cycle**: Force the cart to lock and unlock with the appropriate signals, returning it to the idle state.

  **Speculation**
  - **2.4GHz capability**: FCC filings and marketing materials suggest 2.4GHz capability, but PCB analysis shows unpopulated components and no evidence of advanced communications.
  - **Mystery chip**: Possibly an accelerometer for motion sensing, with ultra-low-power mode to conserve battery.
  - **Unpopulated header**: May be intended for future expansion, but currently unused.

  **Conclusion**
  - **Acknowledgments**: Thanks to the DEF CON staff, friends, family, and software developers.
  - **Resources**: Website (bgaydocrime.com/carts) with audio files for signal playback, and a physical demo in the Flamingo room during the conference.


created_at: 2024-08-03 11:55:54
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - **Paul** and **Thomas**, researchers from the **SONAR R&D team**, present on **Visual Studio Code (VS Code)** security.
  - They explore the **attack surface**, **vulnerabilities**, and **security measures** of VS Code, a popular **Integrated Development Environment (IDE)**.

  **VS Code Overview**
  - **Electron-based**: Built on **Node.js** and **Chromium**, enabling web-based versions like **github.dev** and **vscode.dev**.
  - **Highly extensible**: Supports a wide range of **extensions** published on the **VS Code marketplace**.
  - **Language Server Protocol**: Facilitates language support across different editors, reducing development effort.
  - **Open-source**: Approximately **800,000 lines of code** on **GitHub**, with some **proprietary parts** in the Microsoft version.

  **VS Code Architecture**
  - **Component-based**: Splits functionality into **privileged** and **less privileged processes**.
  - **Privileged processes**: Include the **main process**, **shared process** (hosting terminals and utilities), and **extension host process**.
  - **Renderer process**: Chromium-based, responsible for UI rendering, with limited access to the file system and command execution.
  - **Isolation and communication**: Different components communicate via **IPC interfaces**, with **origin restrictions** enforced by the **same-origin policy**.
  - **Debugging**: Supported via **Chromium developer tools** and **VS Code's built-in debugging features**.

  **Attack Surfaces and Vulnerabilities**
  - **Exposed network services**: VS Code extensions often expose network services, creating potential security risks due to lack of proper security measures.
  - **Argument injection**: Demonstrated through vulnerabilities in the **Rainbow Fart** extension and VS Code's built-in **Git extension**.
  - **Workspace settings**: Sensitive settings, such as `git.path`, can be overridden, leading to potential command injection.
  - **Workspace Trust**: A security feature introduced in 2021 to reduce the impact of malicious folders, but with limitations and potential bypasses.
  - **Browser-based vulnerabilities**: XSS attacks are possible due to the built-in browser in VS Code, leveraging extensions and Markdown injection.
  - **Built-in browser exploitation**: Examples include the **Markdown Preview** extension, **Jupyter Notebook** extension, and **command links** in Markdown strings.
  - **Third-party extensions**: Popular extensions like **GitLens** and **GitHub Pull Requests and Issues** extension were found to have vulnerabilities, allowing attackers to execute arbitrary code.

  **Bug Bounty and Reporting Process**
  - **Microsoft Security Response Center (MSRC)**: Used for reporting vulnerabilities, with centralized communication and transparency.
  - **Bounty discrepancies**: Disagreement over the inclusion of built-in extensions in the bug bounty scope, leading to a $30k bounty awarded and then retracted.
  - **CVEs and patches**: Highlight the importance of thorough patching, as some vulnerabilities were bypassed due to incomplete fixes.

  **Conclusion and Takeaways**
  - **CVEs as indicators**: Buggy components are often targeted, and thorough patching is essential to prevent bypasses.
  - **Workspace Trust considerations**: Clicking "Trust" can have security implications, and users should exercise caution when trusting folders.
  - **Unclear security threat model**: Developer tools often lack clear security guidelines, leaving users uncertain about potential risks.
  - **Principle of least surprise**: Emphasizing the importance of transparency and user awareness in security measures.
  - **Need for improved security**: Encouraging developer tools to prioritize security and provide clear guidance to users.


created_at: 2024-08-03 12:01:24
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - **Ben Nassi** and **Ofek Vayner** present a new method of **video-based cryptanalysis** to extract cryptographic keys.
  - This technique uses video footage of a device's power LED, demonstrating the risk to information confidentiality.

  **Background**
  - Previous research in 2014 introduced the **visual microphone**, recovering speech by analyzing video footage of objects.
  - The **LEM phone attack** uses a **photodiode** to recover speech by measuring light intensity from a desktop light bulb.
  - **Glow-O-Matac** extends this concept, recovering speech from the power LED of speakers.

  **Optical Cryptanalysis**
  - Power consumption of a device affects the intensity of its power LED, creating a correlation between power consumption and optical measurements.
  - This correlation allows for cryptanalysis by analyzing optical measurements from the power LED using a photodiode.
  - **Raspberry Pi** experiments revealed a correlation between power consumption and LED intensity up to 500 kHz.
  - RSA, ECDSA, and SIKE keys can be recovered using this technique.

  **Video-Based Cryptanalysis**
  - The primary disadvantage of optical cryptanalysis is the need for specialized equipment like photodiodes.
  - Video cameras are more accessible and can be used to obtain optical measurements from power LEDs.
  - **Rolling shutter** effect in video cameras can increase the effective sampling rate by three orders of magnitude.

  **Threat Models**
  - **Closed Video Acquisition**: Uses a smartphone's video camera, targeting any power LED with physical access.
  - **Over-the-Internet Video Acquisition**: Exploits an internet-connected video camera to target Type 2 power LEDs that indicate operation execution.
  - **Rolling Shutter**: Exploits the rolling shutter effect to increase the sampling rate and detect rapid changes in LED intensity.

  **ECDSA Key Recovery**
  - The **Minerva attack** exploits runtime optimizations in cryptographic libraries to recover ECDSA keys.
  - By analyzing video footage of a smart card reader's power LED, the signing time of ECDSA signatures can be estimated, enabling key recovery.
  - The experimental setup involved an internet-connected video camera 16 meters away from the smart card reader.
  - The signing time was calculated by analyzing the color changes in the video frames, indicating the start and end of signing operations.
  - The Minerva attack script was then used to recover the complete ECDSA key.

  **SIKE Key Recovery**
  - The **Herzblied attack** is a timing attack that recovers SIKE keys by analyzing the execution time of cryptographic operations.
  - The experimental setup involved an iPhone capturing video footage of the power LED of speakers connected to a Samsung Galaxy S8.
  - By averaging the frames and analyzing the green channel, the start and end of cryptographic operations could be detected.
  - The execution time distribution was used to set a threshold and determine the key bit values with 99% accuracy.
  - An error detection and correction mechanism was applied to recover the complete SIKE key.

  **Limitations and Takeaways**
  - The attack primarily targets weak IoT devices, up to the level of smartphones.
  - The semi-uniform distribution of sampling due to the transition time between frames is a limitation.
  - Power LEDs are more informative than expected, posing a risk to information confidentiality.
  - The potential of the attack is greater than demonstrated, as improved video camera specifications and the increasing number of weak IoT devices will make more devices vulnerable.
  - Video-based cryptanalysis is intended for non-compromised devices and uses commonly available equipment.

  **Conclusion**
  - This research highlights the vulnerability of power LEDs to video-based cryptanalysis, even with ubiquitous cameras and weak IoT devices.
  - The presented attacks demonstrate the recovery of cryptographic keys from smart card readers and smartphones.
  - The potential impact of this research was recognized with the Pony Award for the best cryptographic attack of 2023.


created_at: 2024-08-03 12:09:51
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - The talk focuses on the security and privacy of vacuum robots, specifically those with cameras.
  - The speaker is a PhD student researching security and privacy in wireless and embedded devices.
  - They also collect and reverse engineer vacuum robots, smart speakers, and flash memory.
  - Previous work includes a paper on Amazon Echo device forensics and the website robotinfo.dev, which systematically lists robots sorted by operation system, sensors, and vulnerabilities.

  **Vacuum Robot Hacking Overview**
  - The goal is to gain root access to the robot without disassembling it.
  - This talk covers research and experiments conducted over 15 months in collaboration with Zoran Bayer, the developer of Valetudo (a cloud replacement for robots).
  - The community plays a crucial role in this research, with thousands of people tinkering with these devices.

  **Motivation for Rooting Devices**
  - These devices have cool hardware and can be used for experiments.
  - Stopping constant phone-home behavior and protecting privacy are important.
  - Custom smart home solutions and diagnosing broken devices are also motivations.

  **Why Not Trust IoT?**
  - These devices have access to the home network and their own internet connection.
  - Most communication is encrypted, and there is no visibility into what data is being sent.
  - Cameras, microphones, maps of the home, and the ability to drive around independently raise privacy and security concerns.
  - Developing secure hardware and software is challenging, and even well-intentioned vendors can make mistakes.

  **Vendor Claims and Contradictions**
  - Roborock claims that data from cameras is not sent to the cloud, but then mentions remote access to view pets.
  - iRobot was caught uploading pictures from cameras to the cloud for labeling by gig workers.
  - Other vendors started making changes to privacy policies and firmware after this incident.

  **Risks of Devices with Cameras**
  - Pictures may be stored indefinitely, both in the cloud and locally.
  - Used devices may have rootkits installed, even after a factory reset, posing a security risk to the new owner.
  - Rooting is the only way to verify that a device is clean.

  **Vendor Awareness and Certifications**
  - Vendors try to avoid using the word "camera," referring to it as an "optical sensor" instead.
  - All the devices discussed have some form of certification, but these certifications may not mean much in terms of actual security.

  **Past Developments in Vacuum Robot Hacking**
  - Every time a routing method is presented or released, vendors react and make changes.
  - In some cases, these changes have broken devices or introduced countermeasures to detect and prevent rooting.
  - Previous work includes finding weaknesses in firmware updates, local updates, and region locks.
  - Disassembly was required for some devices, and new routing methods were developed.

  **Roborock's Countermeasures**
  - Introduced CQ-boot, SA-Linux, DM-Verity, and encrypted file systems.
  - Added custom code to detect and bypass traffic redirection to custom software.
  - Used obfuscation techniques to hide strings and functions in binaries.
  - Added ELF binary signature checks in the kernel to prevent running unsigned binaries.

  **Dreame's Countermeasures**
  - Enabled secure boot and started signing the system partition.
  - Introduced "Judge" countermeasure to detect firmware manipulation and randomly crash the robot while cleaning.

  **Current State of Robot Security**
  - The Roborock S8 Pro Ultra is one of the most protected robots on the market, with various security measures in place.
  - The booting process involves multiple stages of verification and encryption.
  - However, there may be a vulnerability in the U-boot boot loader that allows modification of itself and bypassing of subsequent verification checks.

  **Rooting Methods**
  - For Dreame vacuum robots, a USB stick can be used to access a shell and patch the environment.
  - For newer Dreame models, a bootloader mode and sketchy firmware package can be used to access the flash and system functions.
  - For Roborock models, a "scary" FAL root method involves grounding a data pin to bring the device into bootloader mode and flash it from USB.

  **Custom Firmware and Redirecting Traffic**
  - With root access, custom firmware can be installed and traffic redirected to a cloud emulation.
  - Valetudo is a complete replacement for the cloud application, API, and smartphone app, providing offline functionality and a responsive web interface.
  - DustBuilder is a website that allows users to build custom firmware easily.

  **Findings on Robots**
  - All cameras use the Video for Linux subsystem and can be accessed through device files.
  - Some vendors include debugging tools that allow access to the camera.
  - Dreame introduced a lot of telemetry and calling home functions, as well as geo-blocking by IP address.
  - A legal requirement for a warning prompt when accessing the camera remotely can be bypassed by overwriting the audio file, but this is illegal.

  **Summary and Final Notes**
  - Routing methods and security bypasses are available for current Dreamy and Roborock robots.
  - Secure boot and other security mechanisms can be bypassed.
  - Persistence and custom firmware are achievable.
  - Vendor claims can be validated, but some are tricky.
  - The bootloader attack is applicable to many other devices beyond vacuum robots.
  - Do not use this knowledge for illegal or malicious purposes.
  - Share routing methods and help others.
  - Tools and further details will be released in the coming days.


created_at: 2024-08-03 12:14:01
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - **Wi-Fi Chips**: Powerful, general-purpose CPUs, but proprietary binaries limit custom code.
  - **Talk Focus**: Extending functionality and facilitating security research on modern **Xtensa-based Qualcomm Wi-Fi chips**.
  - **Nexmon Framework**: Tool for modifying **Broadcom chips**, enabling features like **monitor mode** and **packet filtering**.

  **Wi-Fi Chips Overview**
  - **Full-MAC** and **Soft-MAC** chips: Full-MAC runs MAC layer in firmware, requiring direct changes for modifications.
  - **Qualcomm Wi-Fi Chips**: ADH-10K and ADH-10K-CT (by Candela Tech) drivers and firmware available. QCAC-LD driver used for factory processes.

  **Wi-Fi System-on-Chip (SoC) Structure**
  - **Application Core**: Runs OpenWRT, manages Wi-Fi cores for 2.4 GHz and 5 GHz via PCIe.
  - **Wi-Fi Core**: Handles MAC layer functions.

  **Qualcomm Wi-Fi Chip Firmware**
  - **Xtensa-based**: Little-endian firmware with ROM and RAM parts.
  - **ROM**: Patchable, with code swap mechanism and no default security features.
  - **RAM**: Stored in OpenWRT file system, LC77 compressed, with multiple segments and metadata.

  **Firmware Loading and Interface**
  - **Loading Methods**: BMI (for compressed firmware) and copy engine.
  - **Interfaces**: PMI (bootloader management) and WMI (command communication) implemented in ROM.

  **Firmware File Structure**
  - **Two Parts**: Identified by IE header, with segment headers providing metadata and compressed data.
  - **Overwriting**: First and second parts have the same address, allowing overwriting of boot-up code with real firmware.

  **Memory Layout and Xtensa Architecture**
  - **Memory Layout**: Repetitive patterns suggest different memory access rights based on offsets.
  - **Xtensa Architecture**: Features **literal pools** and **windowed registers** for efficient function calls.

  **Literal Pools and Disassembler Challenges**
  - **Literal Pools**: Load instructions use offsets from a fixed literal base instead of being PC-dependent.
  - **Disassembler Support**: IDA77, JITRA, RADAR2, and Binary Ninja lack support for literal pools, requiring patches.

  **Patching Existing Code**
  - **Nexmon Framework**: Modified to support Qualcomm-based Wi-Fi chips, allowing C-written patches and calls to existing firmware functions.
  - **GCC Plugin**: Creates Nexmon.pre file with metadata for linker scripts and patch file creation.
  - **Decompression**: Added support for Qualcomm's uncompressed firmware.
  - **Multiple Binaries**: Extended GCC plugin to include target firmware file information.

  **Addressing Load Instruction Challenges**
  - **Problem**: Load instructions expect a **libbase** to be set, requiring either communicating existing libbase or using a custom value.
  - **Solution**: Set libbase to zero at function entry, reset to original value at exit, and handle relaxation in assembler.

  **Assembler Patching**
  - **Relaxation**: Assembler relaxes call instructions to load and call, requiring resetting libbase between them.
  - **Solution**: Add instruction to reset libbase after finding call x pattern in assembler lookup table.

  **Demonstration**
  - **Patching Process**: Overwrite literal pool values, compile C files, assemble, link, and copy relevant sections to create firmware file.
  - **SSH Access**: Copy modified firmware, restart PCIe driver, and verify memory modifications via hexdump.

  **Summary and Future Work**
  - **QCAmon Framework**: Modified Nexmon to work with Qualcomm firmware, with demo patch and tools available.
  - **Future Work**: Improve patching ease, explore QCAC-LD driver, and study code swap feature.
  - **Acknowledgments**: Martin Kort and Roku for their contributions and resources.


created_at: 2024-08-03 12:19:50
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Talk given at DEF CON 31 by Trevor Stevado and Sam Haskins of Loudmouth Security
  - Focuses on **physical access systems** and their vulnerabilities

  **Physical Access Systems**
  - Components: **card**, **reader**, **back-end access controller**, **lock**
  - Reader reads credential from card, sends to access controller for validation
  - Access controller confirms validity, sends signal to lock to open door

  **Card-to-Reader Interactions**
  - Technologies: **HID prox**, **HID iClass**, **Mifare Classic**, **CEOS** (**HID**), **Mifare Desfire** (**NXP**)
  - Purpose: validate physical presence of credential at specific time

  **Types of Attacks**
  - **Card-cloning**: capturing data from card, writing to new card
  - **Downgrade**: reading data from card with standard reader, encoding on lower frequency/security card
  - **Replay**: capturing, replaying sequence of messages between card and reader
  - **Relay**: focus of presentation; relaying RFID card signal over long distance

  **History of Access Control Technologies**
  - **HID prox**: simplistic, card broadcasts ID when energized, easily cloned
  - **HID iClass**: introduced shared key between card and reader, proprietary cipher reverse-engineered
  - **Mifare Classic**: uses keys for each sector, proprietary algorithm reverse-engineered
  - **CEOS** and **Mifare Desfire**: use industry-standard ciphers, no public cloning techniques for CEOS

  **Relay Attack Scenario**
  - Attacker sends individuals near legitimate employee with Proxmark and near target door with Proxmark
  - Communication between Proxmarks via internet, acting as fake reader and card
  - Messages relayed between real reader and real card, responses sent back
  - Reader can only detect attack through **timing variations**

  **ISO 14443 Type A (14A)**
  - Messaging layer for application-specific data, e.g., **CS protocol** or **Desfire protocol**
  - **14A handshake**: exchange of parameters before application-layer data, not encrypted or authenticated
  - **UID CLN message**: card provides UID to reader, not used by CS due to lack of authentication
  - **ATS message**: includes **frame waiting time integer (FWT)**, unauthenticated, sent by card

  **Frame Waiting Time (FWT)**
  - Tells reader how long to wait between frames before expecting response from card
  - Can be modified to make reader accept **ridiculous amounts of latency**
  - Highest value of 14 results in wait time of **4,949 milliseconds**

  **Original Design**
  - Extension of HF Replay Proxmark standalone mode by Salvador Mendoza
  - Used laptops, BlueShark Bluetooth add-on, web socket connection
  - Successful test: unlocking door in Ottawa with card in Florida
  - Reliability issues due to battery level affecting Proxmark's ability to read card
  - Latency issues: real cards designed for response within milliseconds, not orders of magnitude

  **Revised Design**
  - Swapped laptops with phones, Bluetooth with serial link, powered Proxmark from phone
  - Software: HFCardHopper, new module for Iceman's Proxmark 3 firmware, inspired by Salvador Mendoza's design
  - Supports any ISO 14443A protocol, relays initial UID and DATS
  - Custom Android app for easy interface with Proxmark, supports card/reader modes, adjusts FWT
  - Custom hardware: USB-to-UART bridge module, ribbon cable for connection to Proxmark

  **Results**
  - Tested on various HID readers: RP40, RPK40, Signo (00, 01, 02)
  - Card technologies: CEOS, EV1, interested in testing EV2 and EV3
  - Distances: successful tests from 12 feet to 2,400 miles (Vegas to Ottawa)
  - Prevalence of technologies: older technologies still in use, small market percentage for newer ones
  - Most access control industry vulnerable to some form of attack

  **HID's Response**
  - Responsible disclosure through BugCrowd, triaged and responded
  - Did not accept recommendation to limit FWT due to compliance and backward compatibility
  - Majority of end users do not see relay attacks as viable threat
  - Suggested mitigations: second factor (PIN/biometric), mobile credentials


created_at: 2024-08-03 12:24:47
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - The future of **hacking**, **cybersecurity**, and **human rights** are at risk due to a proposed UN cybercrime treaty.
  - The **treaty** could reshape **anti-hacking laws** and impact **security researchers** and **coders**.
  - With **Russia** and **China** initially involved, there are concerns about the potential impact on **security researchers' rights**.

  **Background on the Proposed UN Cybercrime Treaty**
  - The **UN** is negotiating a draft **cybercrime treaty** that could reshape anti-hacking laws worldwide.
  - There is already an existing international **cybercrime treaty**, the **Budapest Convention**, with 64 signatories, which has been criticized for various issues.
  - **Russia** proposed a new **cybercrime convention** at the UN in 2017 due to concerns about the Budapest Convention infringing on national sovereignty.
  - In 2019, the **UN General Assembly** adopted a resolution creating an **ad hoc committee** to elaborate on the proposed convention.
  - Geopolitics has played a complex role in the negotiations, with some countries pursuing their own agendas, which could compromise **human rights protections**.

  **Concerns with the Zero Draft of the Treaty**
  - The **Zero Draft** of the treaty contains five chapters on **criminalization**, **domestic and cross-border surveillance**, **technical assistance**, and **proactive measures**.
  - There are concerns about the weakness of the **human rights** articles in the draft, with some countries wanting to delete them entirely.
  - The draft includes an article on **international cooperation** that removes the application of **human rights** obligations, which is concerning.
  - Countries like **India**, **Russia**, **China**, **Iran**, **Syria**, **Egypt**, and **Tonga** have proposed concerning changes, such as deleting references to international human rights obligations.

  **Impact of Treaties and the Need for Limitations**
  - **Treaties** are binding on signatory countries, and some provisions compel states to adopt certain laws, while others allow for flexibility.
  - However, too much flexibility can be problematic, especially when it comes to **criminalization** and **surveillance powers**.
  - The speaker emphasizes the need for limitations and safeguards to protect **human rights**, especially regarding **computer access without authorization**.
  - The treaty could lead to **diplomatic issues** and complicate the situation for **security researchers** and **journalists**.

  **Specific Concerns with the Treaty's Articles**
  - The speaker highlights concerns with **Article 22**, which allows countries to claim **jurisdiction** over crimes, leading to potential issues with **extradition** and **surveillance powers**.
  - They provide a scenario to illustrate the potential issues, involving a **security researcher** from a democratic country accessing a database in an authoritarian country, containing sensitive information about dissidents from another authoritarian country.
  - The speaker calls for the deletion of **Article 22** to prevent authoritarian regimes from legitimizing illegal practices and compromising human rights.

  **Proposed Safeguards and Protections**
  - The speakers from **EFF** advocate for stringent **limitations** and **safeguards** on **human rights abuses** within the treaty.
  - They propose setting **time limits** on investigative powers, ensuring **effective remedy** for wrongly targeted individuals, and requiring **prior judicial review** of surveillance powers.
  - They also want to see **transparency** in reporting the use of these powers and a clear definition of **"competent authorities"** to prevent overreach by prosecutorial authorities.
  - They highlight concerns with **Article 28**, which could force security researchers to disclose **vulnerabilities** to government authorities.

  **Next Steps and Call to Action**
  - The next intensive round of negotiations will take place in **August-September** 2023, with a potential final draft and signatories expected by **January-February 2024**.
  - The speakers urge the audience to follow the process closely and stand up for **users' rights** and the rights of security researchers to prevent criminalization in the international forum.


created_at: 2024-08-03 12:34:30
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - **Ileana Barrionuevo**: Security engineer and researcher at UTN, Cordoba, Argentina
  - **Dan Borgogno**: Security engineer and researcher at Latus Seguros, Argentina

  **Digital Wallets**
  - **Definition**: Allow users to store, transfer, and receive money on their phones
  - **Problem**: When a business wants to receive payments, they need to protect client data, especially when using credit cards
  - **Attack Surface**: 
      - Critical information sent over **Bluetooth**, which is vulnerable to attacks
      - Ability to control data flow and payment process, leading to potential reply attacks and payment manipulation
      - Wide range of attack points, including data entry, hardware, firmware, Bluetooth, application manipulation, and network traffic

  **Device Features**
  - Read **EMV** (chip), **MAGstripe** (black stripe on credit cards), and **NFC** payments
  - Support **firmware updates** and **key updates** over the air
  - Use **Bluetooth Low Energy** and **EDR** (3.0)
  - Implement a **key management system** using **UKPT** (a protocol for secure key exchange)
  - Encrypt critical information (e.g., MAGstripe, EMV, and NFC data) before sending it to the backend

  **Network Traffic Analysis**
  - Intercepted traffic between application vendors and devices
  - Used tools like **Frida**, **Objection**, **Meet and Proxy**, and **Burp Suite** to analyze and manipulate data
  - **Data Reconstruction**: 
      - Backend returned encrypted credit card information (e.g., card number, CVV, expiration)
      - By guessing the first few digits and brute-forcing the remaining ones, they could reconstruct the entire credit card number
  - **Data Reuse**: 
      - UKPT states that transaction keys should be used once and discarded
      - By resending a request with encrypted information and a valid payment, they could make a successful transaction, exploiting a grey area in responsibilities between device and digital wallet providers

  **Application Analysis**
  - Focused on manipulating objects and instances related to encrypted card information
  - Abused **TUKPT** (a key management protocol) implementation
  - Captured and manipulated encrypted card information during transactions
  - Developed a script to hook methods, serialize requests, and manipulate instances at runtime
  - Demonstrated a successful attack by tampering with the serializer method and sending previous card information

  **Bluetooth Analysis**
  - Devices shared the same Bluetooth chip (**iChip YC1021**) supporting Bluetooth 3.0 and 5.0
  - Used a test application and tools like **BiddleJack** and **micro:bits** to analyze Bluetooth traffic
  - Able to sniff critical payment information over Bluetooth Low Energy
  - For Bluetooth EDR (3.0), the data was encrypted, but the pairing mechanism had vulnerabilities
      - Numeric comparison showed the same six-digit number on the device and phone, but the device had no screen to verify the pairing
      - Performed a **Man-in-the-Middle** attack using a script to emulate the device and intercept data
  - Demonstrated successful attacks, including **data manipulation**, **over-the-air updates**, and **dual copy bypass**

  **Hardware Analysis**
  - Analyzed four devices available in Argentina, focusing on valuable data and hardware vulnerabilities
  - Valuable data included:
      - **DMC** or **EMV tokens** (for payments)
      - **Firmware** (for bug exploitation)
      - **IP Key** (for data decryption)
      - **UART logs** (for potential information leakage)
  - Devices lacked anti-tampering measures, allowing cleartext data transmission between components
  - Performed a **schemer** attack to capture and transmit credit card information over Bluetooth
  - Demonstrated the attack using a hardware implant and a simple RF transmitter

  **Final Thoughts**
  - Companies should use **end-to-end encryption** and implement **anti-tampering measures**
  - **Data reuse** should be denied, and an **expiration** or **TTL** should be added to sensitive data
  - **Digital signatures** could ensure data integrity and prevent manipulation
  - **Auto-bounce pairing** or **NFC pairing** could enhance security and prevent Man-in-the-Middle attacks
  - Acknowledgments: **Adrien Perroneo**, **Marino CodeHackerspace**, and **Joaquin Marella** for their contributions


created_at: 2024-08-03 12:40:57
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Speaker: Nick Skeak
  - Topic: User enumeration in **Azure** and its implications.

  **User Enumeration**
  - Definition: Determining if a user is valid on a system.
  - Importance: Enables attacks like **password sprays**, phishing, and targeted **RCE**.
  - Facilitates identification of targets, especially when email addresses contain real names.
  - Common in **pen testing** to reduce the list of potential targets.
  - **Microsoft Azure**:
     - Widespread adoption, including Fortune 500, state and federal government agencies.
     - Contains user information disclosures that can be weaponized.

  **OneDrive Enumeration**
  - Silent and leaves no logs, making it ideal for large-scale enumeration.
  - Requires knowledge of domain and tenant names, which can be identified using tools like **AAD Internals** and **Clue**.
  - **OneDrive Enum**: Tool developed by the speaker for enumeration, with a total operating budget of $5,000.

  **Results of User Enumeration**
  - Over 24 million user names found, with about 10 million unique names.
  - Common user name formats include "John Smith" and "J. Smith".
  - User enumeration possible even with high turnover or long retention policies.

  **Presence Enumeration**
  - **Teams** presence enumeration: Monitoring users' online presence and out-of-office messages.
  - Enabled by default, allowing anyone to message people in an organization.
  - **Graph Explorer**: Contains a feature for presence lookups, even without authentication.
  - **Team Filtration**: Tool for presence enumeration, taking advantage of an anonymous presence lookup in the source code.
  - Allows tracking of a company's daily activity and identifying schedules and habits of specific individuals.

  **Guest Enumeration**
  - Possible to enumerate guest users in Azure, revealing potential business relationships.
  - Default settings allow guests to invite other guests, creating ambiguity about the nature of connections.
  - **Dr. Azure AD**: First to discover guest enumeration, with a method published four years ago.
  - Guest enumeration is not considered a vulnerability and is out of scope for pen testing, but it provides a roadmap for attackers.

  **Conclusion**
  - User enumeration is a serious issue that should be addressed by Microsoft.
  - Large-scale user enumeration, presence monitoring, and guest relationship identification are possible with minimal investment.
  - Emphasizes the need for Microsoft to take user enumeration seriously and make necessary changes.


created_at: 2024-08-03 12:44:41
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**:
  - Mieke Eoyang's presentation at DEF CON 31 discusses the **history of cyberwarfare** and its misconceptions.
  - The association between **nuclear deterrence** and **cyber conflict** has influenced popular culture and policymakers.

  **The Impact of Media and Popular Culture**:
  - The movie *WarGames* shaped **President Ronald Reagan's** concerns about potential hacking into U.S. weapons systems.
  - This led to the establishment of the **Department of Defense's** (**DoD**) first **cyber command** under the **U.S. Strategic Command**.
  - Concepts like **mutually assured destruction** and **mutual hold at risk** guided the DoD's initial approach to cyber strategy.

  **The Evolution of Cyber Threats**:
  - The DoD initially focused on potential **"cyber 9/11"** or **"cyber Pearl Harbor"** scenarios, anticipating a major cyber attack with catastrophic effects.
  - However, the reality of cyber operations is often **ephemeral**, with effects that are **hard to attribute** and **rarely decisive**.
  - The turning point in U.S. cyber strategy occurred before the **2018 midterm elections**, adopting a "defend forward" approach to actively disrupt malicious cyber activity.

  **The Role of the Private Sector and Volunteers**:
  - The recognition that **cyberwarfare is pervasive** highlights the critical role of the **private industry** and **individual volunteers** in protecting Americans and strengthening global allies.

  **Cyber in War vs. Cyber War**:
  - There is a significant difference between **cyber in war** and **cyber war**.
  - Cyber attacks during Russia's invasion of Ukraine in 2022 demonstrated that cyber operations are not as devastating as initially theorized.
  - Cyber attacks did not cause the Ukrainians to surrender, and the expected **"Cyber Pearl Harbor"** scenario did not materialize.

  **Integrated Deterrence**:
  - The focus has shifted to **integrated deterrence**, utilizing cyber as one of the tools of national power alongside other options like sanctions, law enforcement actions, or kinetic attacks.

  **The Cyber Trilemma**:
  - The **cyber trilemma** involves the factors of **speed**, **intensity**, and **control**.
  - The DoD optimizes for **control**, ensuring precision and adhering to the rules of armed conflict.

  **Cyber Offense and Defense**:
  - The DoD has prioritized sharing insights and **TTPs** (tactics, techniques, and procedures) with partners and the private sector to defend against cyber threats.
  - The "Shields Up" activities and technical assistance provided by the **NSA's Cyber Security Collaboration Center** are examples of this new approach.

  **The Need for Skilled Cyber Professionals**:
  - The DoD recognizes the need for skilled cyber professionals to help identify and disrupt malicious cyber activity targeting Americans.
  - The presentation concludes with a call for collaboration between the DoD and the cyber community to address the evolving cyber threat landscape.


created_at: 2024-08-03 12:54:12
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - **DEF CON 31** talk by **Benny Zeltser** and **Jonathan Lusky**
  - **RingHopper**: a method to hop from user-land to **SMM** (System Management Mode)
  - Disclosure of a family of industry-wide **vulnerabilities** in various **UEFI** implementations
  - Affected more than **eight major vendors**, making **billions of devices vulnerable**

  **Timeline**
  - June 1, 2021: Initial reporting of the findings
  - January 19, 2022: CERT-CC started working on coordinated disclosure
  - August 2022: Talks withdrawn from Black Hat and DEF CON due to issues not being fixed in time
  - November 8, 2022: Last embargo expired, and a note was published

  **Privilege Rings and SMM**
  - Four privilege rings: **user mode** (ring 3), **kernel** (ring 0), **VMM** (ring -1), and **SMM** (ring -2)
  - SMM started as a small operating mode for low-level system functionalities but has grown bigger over the years
  - SMM resides in a well-guarded portion of RAM called **SM RAM**, which is inaccessible to other entities
  - To switch to SMM, the kernel triggers a **system management interrupt** (SMI)
  - Once SMI is triggered, the processor switches to running SMM, and an **SMI handler** takes over
  - After the SMI handler is done, the processor switches back to running the kernel, and SMM becomes inactive

  **Time-of-Check Time-of-Use Vulnerability**
  - An SMI handler may validate input and then use it, creating a potential vulnerability
  - An attacker could modify the output buffer between the time-of-check and time-of-use to gain a write primitive
  - This can be exploited using **DMA** (Direct Memory Access) and peripheral devices like an Ethernet adapter or graphics card

  **Exploiting the Vulnerability**
  - Used a tool called **PCILH** by Ulf Rysk to initiate arbitrary read and write DMA transactions to RAM
  - Added a malicious file with a payload to a storage device to generate DMA transactions remotely
  - Hooked the DMA request and triggered an SMI to exploit the time-of-check time-of-use issue

  **Recap and S3 Suspend-Resume Cycle**
  - Discussed SMM, time-of-check time-of-use vulnerabilities, DMA transaction manipulation, and write primitives to SMRAM
  - S3 is a **sleep state** where the CPU is idle, but memory remains active
  - During a normal boot, the configuration of the platform is encoded into the **S3 boot script**
  - When the machine wakes up, the **boot engine** executes the S3 boot script to restore the configuration
  - The S3 boot script is stored in a container called **Logbox**, located in SMRAM

  **Attempting to Execute Code in SMM**
  - Analyzed the **SMBIOS DMA Edit Dixie driver** and found potential write primitives
  - In SMM, all pages containing code are **read-only**, and all pages containing data are **non-executable**
  - The paging mechanism in SMM hinders exploitation by restricting memory access and making page table attributes permanent
  - Needed to think outside the box and leverage unique mechanisms internal to SMM

  **Leveraging S3 Suspend-Resume Cycle**
  - Referenced a paper by Raphael Washtuk and Corey Kallenberg from 2015 on running arbitrary code in SMM
  - The paper abused the fact that the S3 boot script was stored in a location accessible to the OS
  - However, this has been mitigated, and now the S3 boot script resides in the Logbox in SMRAM
  - The update procedure for the Logbox prevents the kernel from updating it unless a specific global variable is not set
  - Using their write primitive, they were able to zero out this global variable and modify the S3 boot script
  - However, when the machine wakes up, the SMRAM is locked, and most of the RAM is not mapped to the page table

  **SMBase Relocation Attack**
  - Each core has its own region of SMRAM, pointed to by the **SMBase MSR** (Model-Specific Register)
  - The SMBase MSR can be modified by changing its value in the **save state**
  - This triggers an **SMBase Relocation**, relocating the entire region to a new address
  - Crafted their own SMI handler entry point in user-controlled memory and used their write primitive to modify SMBase in the save state
  - However, this didn't work due to the **SMM Code Check Enable** bit in a specific MSR
  - This bit, when set, triggers an exception if code outside of SMRAM is executed in SMM
  - There is also a **lock bit** that, when set, prevents the MSR from being modified until the next reboot
  - Putting the machine to sleep (S3 state) clears the SMM Code Check Enable bit, providing a way to bypass the restriction
  - Used their write primitive to annul a specific global variable responsible for MSR restoration
  - Put the machine to sleep, and when it woke up, the MSR was annulled, and they were able to execute code outside of SMRAM
  - Created their own SMI handler entry point and used a write primitive to modify the SMBase MSR, triggering an SMBase Relocation
  - Successfully executed code in SMM with full and unrestricted memory access

  **Dealing with Newer Mitigations**
  - Newer mitigations, such as the **S3** and **SMBase log bits**, restrict modifying the **CR3** register and SMBase MSR until the next reboot
  - Referenced a cache poisoning attack by Rafael and Joanna from 2009 to read and write to SMRAM
  - In practice, when writing to SMRAM, data first goes through the cache before being written back to SMRAM
  - This can be exploited by triggering an SMI to remove the barrier and modify the content of SMRAM
  - However, this is mitigated by the **SMRR** (System Management Range Register), which disables caching of SMRAM
  - By annulling a specific global variable using their write primitive and putting the machine to sleep, they were able to disable SMRR
  - When the machine woke up, they were able to write to SMRAM directly, resurrecting the cache poisoning attack

  **Demo**
  - Modified the Intel NUC logo stored on the SPI Flash, which is only accessible to SMM
  - Crafted a new write primitive of the value zero by chaining existing write primitives and modifying globals in SMRAM
  - Annulled the MSMM Feature Control Supported global, which is responsible for MSR restoration
  - Read the MSR before and after putting the machine to sleep, demonstrating the ability to execute code outside of SMRAM
  - Executed the SMBase relocation attack and replaced one of the SMI handlers
  - Rebooted the machine, and the new logo was displayed

  **UEFI Ecosystem and Impact**
  - The UEFI ecosystem involves the TianoCore project, IBVs (Independent BIOS Vendors), OEMs (Original Equipment Manufacturers), and end customers
  - In 2020 alone, more than **200 million devices** were manufactured that were vulnerable to the attack, resulting in billions of vulnerable devices

  **Extending the Attack to User Space**
  - Required three things: the ability to generate DMA transactions, trigger SMIs, and write to specific physical memory
  - Generating DMA transactions from user space is as simple as reading a file
  - Triggering SMIs is more complicated as it requires executing a special opcode that can only be executed from the kernel
  - Found a tweet by Alex Matrosoff mentioning that BIOS update tools often have low-level functionality that can be reused offensively
  - AMI provides drivers for Linux and Windows that expose an API for triggering arbitrary SMIs
  - For writing to specific physical memory, the communication with SMM involves a **mailbox** struct with a physical address of a row buffer
  - On Windows, used a buffer mapping yoke tool to map the physical address of the row buffer to a user-accessible virtual address
  - Exploited a race condition by modifying the physical address in the mailbox before it was mapped to a virtual address
  - On Linux, used a kernel module to map any physical address, including the address of the Linux kernel or a kernel module
  - By patching ring zero code, they gained code execution in the kernel, completing the exploitation chain from user land to SMM


created_at: 2024-08-03 13:00:47
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction:**
  - Presentation by **Omer Attias**, a security researcher at SafeBridge.
  - Focuses on **security vulnerabilities** in **global transportation payment systems**, specifically the **Moovit** app.

  **Mobile Payment Solutions for Public Transportation:**
  - **Convenience** and **security** are driving the adoption of mobile payment solutions.
  - **Moovit**, a widely-used transportation app, is used as a **case study** to examine security risks.

  **Understanding Mobile Solutions in Public Transport:**
  - **Mike** wants to take a train ride using a mobile solution, ordering an entrance and exit ticket in the form of a **QR code**.
  - The **fare** is calculated at the destination, and billing is done on a **monthly basis**.
  - **Ticket format** investigation reveals a **pattern** related to the **mass operator ID**.

  **Analyzing Ticket Formats and Gate Validation:**
  - Experimenting with modifying the operator ID in the ticket format was unsuccessful.
  - Focusing on the **physical gates**, a **logical vulnerability** was found: using a **canceled ticket** to enter and exit the station without being charged.
  - By ordering a second entrance ticket after reaching the destination, Mike can **avoid paying** for the ride.

  **Security Issues with Moovit:**
  - **Moovit**, a **worldwide mass operator**, has been acquired by Intel and has over **1.4 billion users**.
  - The goal is to find vulnerabilities in Moovit to gain a free ride and access sensitive information.

  **Account Registration and Switching in Moovit:**
  - Moovit users provide their **phone number** during registration, which is validated using a **random OTP**.
  - The **account switching feature** allows users to switch their account between devices by validating the OTP.
  - **SSL encryption** is used for API requests between the server and the mobile application.

  **Analyzing API Requests and User Keys:**
  - By bypassing SSL encryption, the speaker was able to **intercept API requests** and understand the communication between the device and server.
  - The **user key** is assigned to the device, not the user, and is used to identify accounts.
  - Understanding the **user key format** is crucial for enumerating existing accounts.

  **Brute-Force Attack on OTP:**
  - The speaker performed a **brute-force attack** on the OTP, successfully guessing the correct code and taking control of the account.
  - This allowed them to impersonate the account, use its credit card, and access personal information.
  - However, this attack has limitations, including the need for the phone number and the time required for brute-forcing.

  **Understanding and Exploiting the User Key Format:**
  - Analyzing multiple user keys revealed a **pattern** with repeated values, suggesting a relationship between certain bytes.
  - By identifying **gaps** in the user keys, the speaker was able to fill them with user keys of other devices.
  - Using the **user profile API**, they could retrieve the phone numbers associated with these user keys and perform a brute-force attack.

  **Improving the Brute-Force Attack:**
  - The speaker wanted to impersonate the user without disconnecting them from their device.
  - They discovered that the **access token**, generated after receiving the user key, is essential for API communication.
  - By requesting multiple access tokens for a user key, they could fully impersonate accounts without disconnecting them.

  **Demonstration and Takeaways:**
  - The speaker developed a **user interface** to access personal information and demonstrated purchasing a train ticket using someone else's account.
  - **Simple attacks** can succeed against large companies, highlighting the need for **increased security awareness**.
  - All vulnerabilities were responsibly disclosed to Moovit, and fixes have been implemented.


created_at: 2024-08-03 13:05:44
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Perri Adams from DARPA is joined by collaborators from Anthropic, Google, Google DeepMind, Microsoft, OpenAI, and the Open Source Security Foundation.
  - The panel discusses the **AI Cyber Challenge**, a **White House-backed initiative** with a prize pool of up to $20 million.
  - The challenge aims to develop **AI-driven systems** that can **secure software** by finding and fixing vulnerabilities.

  **Open-Source Community Challenges**
  - Omkar from the Open Source Security Foundation highlights the ubiquity of open-source software in critical systems.
  - Ensuring the security of the open-source supply chain is a challenging task that requires innovative solutions.
  - Traditional approaches, such as opening PRs, may not align with the culture and coding styles of open-source projects.

  **Managing Large Code Bases**
  - Heather, Vijay, and Dave represent organizations with some of the largest code bases in the world.
  - They emphasize the importance of scale in vulnerability detection, particularly in large code bases.
  - Techniques like fuzzing, dynamic analysis, and static analysis are essential but have limitations.
  - AI can augment these traditional program analysis tools by reducing complexity and search spaces.

  **The Role of Large Language Models (LLMs)**
  - Matt from OpenAI and Michael from Anthropic discuss the potential of LLMs in cyber defense and security tooling.
  - LLMs can automate tasks, increase productivity, and provide assistance to cybersecurity experts.
  - The rapid improvement of LLMs means that participants should not rely solely on current capabilities but expect and utilize future advancements.

  **Advice for AI Cyber Challenge Participants**
  - Prompting LLMs effectively is crucial, and persistence in finding the right prompt is key.
  - Consider the "user journey" of software development and target areas where LLMs can provide the most value.
  - Creativity and precision are essential, especially when thinking about how solutions will be deployed at scale.
  - Focus on solving constraints and bandwidth limitations, both for tools and your own capabilities.
  - Remember that future LLM versions will likely surpass current capabilities, so don't bet on today's foundation models.


created_at: 2024-08-03 13:16:27
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **The Panel: An Introduction**
  - The panel discusses the **legal challenges** faced by **hackers** and the resources available to them.
  - **Harley Geiger**, the moderator, introduces the topic and emphasizes the importance of pushing the boundaries of **permissible behavior** in security research.

  **The Impact of Legal Threats on Hackers**
  - **Miles McCain**, a security researcher, shares his experience of receiving a legal threat after identifying vulnerabilities in an anonymous social media app, Fizz.
  - The panel emphasizes the **stress** and **uncertainty** caused by legal threats, especially when they come from unexpected sources like classmates.

  **Key Takeaways from Miles' Experience**
  - Keep your research **above board** and **well-documented**. Play by the rules, don't cause damage, and maintain detailed records.
  - **Stay calm** and don't react emotionally. Focus on resolving the situation amicably and avoiding legal repercussions.
  - **Get a lawyer**. Don't try to navigate legal threats alone, seek legal representation, and utilize resources like the **Electronic Frontier Foundation (EFF)**.

  **The Perspective of a "Bug Collector"**
  - **Charlie Schneider** from Google represents the other side of the equation, working with bug bounty programs and vulnerability disclosure.
  - Large organizations can have a significant **impact** on hackers, both positively and negatively. It's important to create an **equal footing** for hackers to contribute without fear of legal repercussions.
  - The existence of the **Legal Defense Fund** is beneficial for both hackers and companies, as it encourages collaboration and the reporting of vulnerabilities.

  **Legal Issues Faced by Security Researchers**
  - **Kurt Opsahl**, Associate General Counsel at Filecoin Foundation and a volunteer with EFF, discusses the two main categories of legal issues for security researchers: issues arising from the research itself and issues related to disclosure.
  - It's important to **minimize risk** during the research phase, such as owning the hardware being tested or conducting wireless research with consent.
  - When disclosing vulnerabilities, establish communication with an **engineer** or someone who understands security, rather than going through marketing or legal channels.
  - **Document** all interactions and save any positive or appreciative responses, as they can be useful if the situation escalates.

  **The Role of the EFF's Coders' Rights Project**
  - **Hannah Zhou**, a staff attorney at EFF, introduces the Coders' Rights Project, which provides legal counseling and representation to security researchers.
  - EFF offers various ways to reach out for help, including email intake, informal referral networks, and in-person conversations at conferences like DEF CON.
  - It's important to reach out early, even if you only have an **inkling** of potential legal problems, to get informed advice and make decisions based on your risk tolerance.
  - EFF's impact litigation focuses on creating good law and preventing bad law, so they don't represent all counseling clients in litigation but consider the impact on the security research community as a whole.

  **Introduction to the Security Research Legal Defense Fund**
  - **Harley Geiger**, a coordinator of the Security Research Legal Defense Fund, explains that the fund is an independent, non-profit organization providing financial support for legal representation in cases of good-faith security research and vulnerability disclosure.
  - The fund has an **independent board** and aims to act in the public interest by supporting individuals facing legal threats due to their security research.
  - The fund is community-driven and relies on **donations**, with Google announcing that they will quadruple donations made by researchers in their Bug Hunters program.

  **Q&A Session**
  - The panel takes questions from the audience, including one about accepting donations in Bitcoin, which they are open to discussing further.
  - The panel emphasizes the importance of seeking legal advice and utilizing resources like the Legal Defense Fund and EFF to support good-faith security research and protect the rights of hackers.


created_at: 2024-08-03 13:25:02
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Speaker: Asi Greenholts
  - Topic: Exploiting GitHub Actions to create a worm

  **GitHub Actions**
  - **CI/CD Platform**: Allows automation of build, test, and deployment pipelines
  - **Events**: Triggers for pipelines include push, pull request, etc.
  - **Workflows**: Pipelines in GitHub Actions, can contain multiple jobs
  - **Jobs**: Run on different runners, can contain multiple steps
  - **Steps**: Can contain bash commands or **actions**
  - **Actions**: Code packages that allow the use of third-party libraries in a pipeline

  **Worm Components**
  - **Initial Attack Vectors**: Methods to compromise a single repository, e.g., re-projecting, NPM email hijacking, command injection
  - **Action Dependencies**: Understanding the relationships between actions, e.g., Docker, JavaScript, and composite actions
  - **Action to Infect Actions**: Exploiting secrets and tokens to push malicious code or override existing tags
  - **Finding Attack Graphs at Scale**: Using Neo4j to visualize and analyze action dependencies, identifying vulnerable repositories

  **Automation and Impact**
  - **Target Repositories**: Top 10K repositories by stars and 32K repositories with bug bounty programs
  - **Metadata Collection**: Parsing action and workflow YAML files to gather information on dependencies, secrets, and permissions
  - **Vulnerable Repositories**: Demonstrating the impact of the attack by compromising a single repository and spreading to 18 intermediate actions, ultimately affecting 72 target repositories
  - **Real-World Examples**: Discussing specific vulnerable repositories and the potential for wider propagation, including private repositories and exfiltrating source code

  **Demo: Dendro Worm**
  - **Environment**: Target repository using a GitHub Actions CICD workflow, random action, composite action, and rev action
  - **Attack Process**: Infecting the rev action, triggering the composite action, and then the random action, ultimately exfiltrating secrets from the target repository

  **Additional Findings**
  - **Vulnerable Repositories**: 175 repositories vulnerable to initial attack vectors, including popular projects like Angular and Astro
  - **Email Hijacking**: Hijacking a single email domain to potentially compromise 90 repositories

  **Protection Measures**
  - **Token and PAT Permissions**: Setting minimal permissions, especially for the content permission, to prevent pushing code
  - **Branch Protection Rules**: Preventing pushes to protected branches
  - **Protected Tags**: A separate feature from branch protection, used to secure tags
  - **Outbound Connections**: Limiting connections from runners to restrict malware downloads
  - **Action Pinning**: Using hash to pin actions, making it harder for attackers to modify references
  - **GitHub's Permission-Limiter**: A project to help reduce workflow permissions


created_at: 2024-08-03 13:35:57
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - **Jules Wetzels**, **Carla Meyer**, and **Wouter Bokslag** of **Midnight Blue** present their research on **TETRA** (**Terrestrial Trunked Radio**), a widely-used radio technology for voice and data communications.
  - TETRA is used by police, military, critical infrastructure, and more in over 100 countries.
  - The cryptography within TETRA has been kept secret, prompting the team to undertake Project ReTetra to reverse-engineer the algorithms.

  **TETRA Overview**
  - TETRA is a radio technology that competes with standards like P25, DMR, and Tetrapole.
  - It was standardized in 1995 by **ETSI** (**European Telecommunication Standards Institute**), known for their work on GSM, 3G, and 4G.
  - TETRA is used for voice, data, and machine-to-machine communications, relying on secret proprietary cryptography.
  - It is used by global police forces, military and intelligence services, and critical infrastructure such as airports, harbors, train stations, and SCADA systems.
  - TETRA security is based on two main pillars: the TAA1 suite (authentication, key management, and distribution) and the TEA suite (voice and data encryption).

  **Reverse Engineering TETRA Algorithms**
  - The team selected the **Motorola MTM5400** radio as their target due to its use of a **Trusted Execution Environment** (TEE) in software.
  - They analyzed the internal architecture, firmwares, and security features to identify potential vulnerabilities.
  - They gained code execution on the application processor by exploiting a **format string vulnerability** in the AT modem command interface.
  - They moved to the DSP (Digital Signal Processor) by exploiting the lack of memory protection and shared memory between the cores.
  - To extract the secret algorithms, they performed a **cache timing side-channel attack** on the TEE, targeting the AES decryption process.
  - They optimized the attack to extract the encryption key in less than a minute.

  **Analyzing TETRA Security**
  - With the secret algorithms in hand, the team analyzed the cryptographic primitives underpinning TETRA's security.
  - They found that the authentication primitives are based on a proprietary cipher named **Hurdle**, a 16-round FISO cipher with a 64-bit block and a 128-bit key.
  - They discovered a vulnerability in the authentication scheme that allows an attacker to establish an authenticated channel with a known session key of all zeros.
  - They identified a potential attack on the identity encryption primitive, TA61, which could lead to de-anonymization of Tetra addresses.
  - The team also analyzed the TEA key stream generators and found a **backdoor** in TEA1, reducing its key strength from 80 bits to 32 bits, making it trivial to crack.
  - They demonstrated the feasibility of cracking TEA1 on 90s consumer hardware, refuting claims by ETSI that it would require high-end equipment.

  **Protocol Level Vulnerabilities**
  - TETRA messages lack authenticity or integrity guarantees, making them vulnerable to forgery.
  - The team discovered a protocol-level vulnerability where an attacker can overpower the infrastructure and alter a mobile station's perception of network time, leading to keystream recovery and decryption of messages.
  - They demonstrated this attack on a real network, highlighting the seriousness of the issue.
  - ETSI downplayed the severity of the vulnerabilities, claiming that packet injection and TEA1-encrypted networks were impossible.

  **Base Station Hacking**
  - The team acquired a **Motorola MBTS** base station and modified its firmwares to implement a proof-of-concept attack.
  - They added functionalities like raw memory access, malloc/free primitives, and TEA support to transform it into an attack platform.
  - They also discovered multiple vulnerabilities in the base station software stacks, including unauthenticated firmwares and hard-coded backdoor passwords.
  - They demonstrated the keystream recovery attack on their lab setup, showing the decryption of an encrypted message.

  **Coordinated Vulnerability Disclosure**
  - The team spent four months reverse-engineering the secret cryptography and the rest of the year analyzing the ciphers, protocol, and building proofs-of-concept.
  - They contacted the Dutch NCSC, who helped coordinate the disclosure process with various stakeholders, including police, ETSI, and the intelligence community.
  - Mitigations include firmware updates, end-to-end encryption, and the use of alternative encryption algorithms.

  **Discussion and Conclusion**
  - The team highlights some interesting responses from ETSI, including downplaying the severity of the TEA1 backdoor and claiming that 32 bits of key entropy was sufficient in the late 90s.
  - They also discuss the use of TA1 in critical infrastructure and the potential impact of the vulnerabilities, citing references from the Snowden documents.
  - ETSI has announced an update to the standard, including replacing the TAA1 authentication suite and updating the TEA algorithms, but they plan to keep the new algorithms secret.
  - The team calls for further analysis of the TEA algorithms, especially TEA3, and Hurdle, as well as the implementation and extension of open Tetra stacks.
  - They emphasize the importance of stopping secret cryptography, as it often leads to security issues and a lack of public scrutiny.


created_at: 2024-08-03 13:43:24
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Terminal Vulnerabilities and Exploits:**
  - **Terminal History:**
    - American Standard Code for Information Interchange (**ASCII**) introduced the **Escape** character, which has been used since the first publication of the standard 60 years ago.
    - **Teletype Model 33:** One of the first devices to use ASCII, released in 1963.
    - **ADM3A Terminal:** Introduced by Leah Siegler in 1976, it was one of the first affordable terminals with cursor positioning capabilities and played a role in the development of the VI editor.
    - **VT100 Terminal:** Released in 1978, it implemented the X3.64-1979 standard (known as **ANSI**), which defined additional control sequences for ASCII.
  - **Escape Sequences and Attacks:**
    - **Escape Sequences:** Used to perform actions like cursor positioning, setting margins, and changing colors.
    - **OpenBSD VT100 Emulator Bug:** Sending specific escape sequences could cause a kernel panic or reboot due to bounds checking errors.
    - **ANSI.SYS Driver:** Introduced in DOS 2.0, it allowed for redefining keys and creating art using escape sequences and custom characters.
    - **ANSI Bombs:** Prank attacks that redefined keys to perform unexpected actions when certain keys were pressed.
    - **Flash.C Terminal DOS Attack:** Sent malicious escape sequences to mess up a user's terminal, causing issues like screen inversion and character substitution.
  - **CVE and Exploitation Techniques:**
    - **H.D. Moore's Research (2003):** Published vulnerabilities in terminal emulators, including the ability to set window titles and exploit them for potential attacks.
    - **Title Reporting Vulnerability:** Exploiting the ability of some terminals to reply with a user-controllable string, allowing for potential command execution.
    - **Curl and DNS Delivery Methods:** Demonstrating how malicious escape sequences can be delivered to terminals using tools like curl and DNS lookups.
    - **Apple Terminal Vulnerability:** Information leakage issue where a malicious server could write escape sequences to the terminal via DNS, potentially exfiltrating data.
    - **Python Free HTTP Command Line:** Demonstrating how a terminal vulnerability can be combined with a Python logging issue to execute arbitrary code.
    - **Git for Windows (Git Bash) and LESS Bug:** Exploiting a vulnerability in LESS's OSC 8 hyperlink handling to write escape sequences to the terminal via Git commit logs.
    - **Top and Docker Escape:** Exploiting a bug in top's optional graphics support to set environment variables and potentially escape Docker containers.
    - **Windows Terminal and Kubernetes:** Demonstrating how a vulnerability in Windows Terminal could be used to attack a Kubernetes administrator by writing escape sequences to the termination log file.
  - **Protection and Mitigation:**
    - Treat terminals like browsers, dealing with untrusted inputs.
    - Ensure correct output escaping and secure settings.
    - Consider using basic terminals like ST to limit exposure to potential vulnerabilities.


created_at: 2024-08-03 13:50:44
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Ryan Johnson, in collaboration with Angelos Stavro and Mohamed El-Sabag, presents research on the security of prepaid Android carrier devices.

  **Android Overview**
  - Prepaid smartphones are purchased outright with a fixed-term service contract, often at a lower cost.
  - Major American carriers offer prepaid plans, with Verizon having a significant presence.
  - Android is an open-source operating system developed by Google, allowing vendors to modify and differentiate their products.
  - Various entities contribute software to Android devices, including Google (AOSP), chipset/hardware manufacturers, carriers, vendors, and vendor partners.
  - Pre-installed software is more trusted and privileged than third-party apps, with special access to permissions and system services.

  **Application Components and IPC**
  - Android applications have unique user and group IDs, providing a sandbox for files and resources.
  - Applications are identified by package names and request data/capabilities through permissions (normal or dangerous).
  - Apps are not monolithic; they are composed of components: activities, services, broadcast receivers, and content providers.
  - External apps can interact with application components if they are exported, enabled, and have the required permissions.
  - IPC mechanisms include intents, bound services, and network sockets.

  **Threat Model**
  - The threat model assumes a local application with 0 or 1 normal-level permission, appearing constrained.
  - The application interacts with insecure interfaces of co-located software, particularly through intents, bound services, and sockets.

  **Vulnerabilities in Prepaid Android Carrier Devices**
  - 21 Android carrier devices from different vendors and carriers were analyzed.
  - Common vulnerabilities include leaking non-resettable device identifiers (86%) and GPS coordinates (81%) to a loopback port.
  - Arbitrary file read/write as a system UID (9%), factory reset (24%), arbitrary AT command execution (24%), and arbitrary command execution as a system UID (9%) were also found.
  - A summary of vulnerable devices and their specific issues is provided.

  **Non-Resettable Device Identifiers**
  - Google changed the "Read Phone State" permission in Android 10, preventing third-party apps from accessing device identifiers directly.
  - However, pre-installed apps can still access and leak these identifiers to locations accessible by zero-permission third-party apps, such as system properties.
  - A code snippet demonstrates retrieving device identifiers on a TrackPhone TCL A3X.

  **GPS Coordinates Leakage**
  - Certain Android devices with MediaTek chipsets have a system binary, MNLD, which opens a debug port (TCP port 7000) when the GPS module is active, emitting GPS coordinates without authentication.
  - A local app with the internet permission can passively or actively access this port to track device location.
  - A source code snippet demonstrates connecting to the debug port and retrieving GPS coordinates.
  - Shodan search reveals 913 internet-facing devices emitting GPS data on port 7000.

  **MMI Group App Vulnerabilities**
  - The pre-installed MMI Group app (com.factory.mmigroup) exposes various capabilities, including factory reset, IMEI/serial number leakage, and arbitrary AT command execution.
  - A local malicious app can send intents to the MMI Group app, which dynamically registers for action strings, allowing data retrieval or command execution via system properties.
  - A source code snippet demonstrates initiating a factory reset.
  - Arbitrary AT command injection is possible by controlling the AT command parameter through intent extras, enabling various actions like calling 911.
  - A demo showcases a malicious app executing AT commands without permissions.

  **HiddenMenu.apk Vulnerabilities**
  - The com.trackphone.tfstatus package, named hiddenmenu.apk, exposes arbitrary AT command execution to co-located apps.
  - Similar to the MMI Group app, it allows control of the AT command parameter, enabling actions like calling 911 or resetting settings.
  - A source code snippet demonstrates injecting backspace characters to execute custom AT commands.

  **Factory Reset via Hidden Menu App**
  - The com.tctGCSHiddenMenuProxy package, a hidden menu app, exposes a programmatic factory reset to local apps without permissions.
  - A broadcast intent can initiate a factory reset, potentially causing catastrophic data loss.

  **Arbitrary File Read/Write via Permission Declaration**
  - A vulnerability in the TCL screen recorder app (com.tclscreenrecorder) allows arbitrary file read/write as a system user app.
  - A local app can declare and request a missing permission, bind to the vulnerable service, and interact with it via a messenger to access files.
  - A detailed workflow and source code snippets illustrate the attack.

  **Factory Apps and Arbitrary Command Execution**
  - Factory apps, such as engineering/hidden menu apps, provide centralized testing of hardware/software functionality and typically run with system privileges.
  - The Evenwell FQC app (com.evenwell.fqc) and Transion Factory app (com.transion.autotestfactory) expose local arbitrary command execution as a system user.
  - By crashing the FQC app while a specific activity is in the foreground, an attacker can set a system property required for command execution.
  - A malicious app can then execute commands with system privileges, granting permissions, performing a factory reset, recording the screen, etc.
  - A demo showcases a malicious app installing and granting permissions to another app.
  - Evenwell Digitech, the creator of the FQC app, is a Taiwanese company owned by Foxconn.
  - The Transion Factory app has a similar vulnerability, allowing command execution through a shell script.

  **ZTE-Specific Vulnerabilities**
  - Three vulnerabilities were discovered in ZTE devices: arbitrary file write as Android system (system server), arbitrary activity component start as a system UI app, and arbitrary file deletion as a system UI app.
  - The arbitrary file write vulnerability is achieved through a zip file employing relative paths and path traversal attacks, allowing overwriting of critical files/databases.
  - A video demo showcases removing the screen lock, deleting photos, and repackaging WhatsApp to access user data.

  **Vulnerability Root Causes and Recommendations**
  - Root causes include lack of access control at application component boundaries, insecure handling of zip files, and reliance on package names for security.
  - Vendors should consider proactive scanning and certification to ensure device security.
  - Enterprises should regularly scan assets to enforce security policies, and users should disable/uninstall vulnerable pre-installed apps.

  **Vulnerability Discovery and Q-Scout App**
  - Quokka has developed a firmware pipeline to discover vulnerabilities through static analysis, vulnerability patterns, and PoCs.
  - The Q-Scout app can be downloaded to check if a device is vulnerable to any of the presented issues.

  **Conclusion**
  - Third-party apps can exploit insecure interfaces in privileged pre-loaded software, emphasizing the need for increased security vetting.
  - The full paper provides additional details, PoCs, and contact information for further discussion.


created_at: 2024-08-03 13:55:55
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - **David Melendez** and **Gabriela Garcia** are presenting on the use of **SDR** in military drones. 
  - **Gabriela**, also known as **Gaps**, is a security developer, hacker, and hacking community organizer. She is also a coding and cybersecurity instructor and mentor. 
  - **David** is the author of *Hacking with Drones* and a fan of Capo's Party. 

  **Drone Warfare**
  - Drones have become **essential instruments of warfare**, offering **precision strikes**, **eliminating the need for onboard personnel**, and being **perfectly suited for symmetrical warfare**. 
  - They offer numerous **advantages** in terms of **accuracy**, **reduced collateral damage**, **minimized human risk**, and **extended operational duration**. 
  - Drones are also **cost-effective** compared to traditional manned aircraft, with **production methods** such as cardboard, wooden, and 3D-printed drones, as well as the use of **affordable chipsets**. 
  - They are **strategic tools** for **real-time covert operations**, **surveillance**, and **data collection**. 
  - Drones are also valuable for **SIGINT**, capable of **gathering information**, **intercepting**, and **analyzing enemy communications and electronic signals**. 
  - They can access **challenging regions**, operate continuously, and transmit data in real-time. 

  **Anti-Drone Measures**
  - Anti-drone measures include the use of **thermal and standard cameras** for **shape recognition**, **detecting heat emissions**, **analyzing drone noise**, **RF and waveform detection**, and **identifying unique radio signatures**. 
  - **Operators employ counterstrategies** such as **frequency hopping**, **unconventional jammers**, and **robust communication protocols**. 
  - However, no drone can withstand a **direct physical attack**, such as a gunshot or stun. 

  **Drones as War Elements**
  - Drones are used for **SIGINT**, **extending reach to hard-to-access areas**, providing **real-time transmissions**, and **covert operations at high altitudes or discrete flight patterns**. 
  - Typical anti-drone measures include **thermal and standard cameras** for **shape detection**, **detecting heat from electronics and motors**, and **artificial intelligence** for identification. 
  - Another technique is **characterization of drone noise** and **RF and waveform detection**, as most drones use Wi-Fi communications. 

  **Atropos and Interceptor Drones**
  - **Atropos** is a **homemade quadcopter with a Wi-Fi router**, created over a decade ago. 
  - It uses a **microcontroller** from **Microchip** and a **stabilization unit** from a **Nintendo** product. 
  - The web page of the router is used for **telemetry control**. 
  - To avoid **authentication attacks**, **beacon frames** are used, along with generating **fake drone frames** to hide the actual one. 
  - **Interceptor** is a **smaller drone** with the same beacon system. 
  - It uses **FM radio** to send commands and has **two-way communication**, allowing for **command transmission** and **telemetry reception**. 

  **Arbitrary Frequency Generation**
  - The latest approach is controlling the drone through **arbitrary frequency generation**. 
  - A **custom frequency** is generated, and the drone receives it through an **SDR**. 
  - The frequency can be changed **dynamically**, making it difficult for police guns to intercept. 

  **Spread Spectrum**
  - **Spread spectrum** is a **modulation technique** that **broadens the signal** across a wider frequency band. 
  - It enhances **resistance to noise and interference** by spreading the signal and managing noise concentrated at a particular frequency. 
  - **FHSS** (Frequency Hopping Spread Spectrum) and **DSSS** (Direct Sequence Spread Spectrum) are key terms. 
  - The innovation of spread spectrum is credited to **Hedy Lamarr** and **George Antheil**, who pioneered the system. 
  - Their work laid the groundwork for **Wi-Fi**, **CDMA**, and **Bluetooth technology**. 

  **Frequency Hopping Spread Spectrum (FHSS)**
  - FHSS is the technique used in this presentation. 
  - The signal is generated by **toggling a GPIO pin** on the **B-Core**, creating a **radio signal**. 
  - Changing the frequency of the toggling allows for **transmission at an arbitrary frequency**. 
  - This technique uses **frequency hopping**, transmitting each message at a different frequency, pre-established between the transmitter and receiver. 

  **I2S Bus and MediaTek MT7628**
  - The **I2S bus** is used to transmit and receive digital audio. 
  - It has a **clock pin** for data transmission and a **data receiving pin**. 
  - The **clock pin** is constantly toggling. 
  - By writing directly to the registers, the clock pin can be turned on and off to generate a **high-level and low-level modulation**. 
  - The **clock dividers** can be configured to change the frequency, allowing for a wide range of frequency choices. 

  **Amplitude-Shift Keying (ASK) Modulation**
  - The most simple modulation is **ASK**, similar to garage door remotes. 
  - By turning the clock on and off, a modulation is created. 
  - The receiver, an **SDR USB**, tunes to the frequency and receives the packets. 
  - The receiver decodes the **binary transmission** by analyzing the **high and low levels**. 

  **Transmitter and Receiver Setup**
  - The transmitter has a **custom controller** with **joysticks**. 
  - A **VCO** is attached to a **linear amplifier** to increase noise. 
  - The receiver is another **B-Core** attached to an **SDR dongle**, which receives data at the specified frequency. 
  - The receiver synchronizes with the transmitter by finding the first packet in a given frequency and following the list of frequencies. 

  **Demonstration**
  - The presenter demonstrates the transmitter's ability to **jump between frequencies**. 
  - The spread spectrum technique transmits at one frequency and then changes to a neighboring one. 
  - The presenter also mentions the possibility of transmitting at a **fixed but unexpected frequency**, which most jammers would not target. 
  - The drone is shown flying outdoors, with the presenter assuring the audience that it has killed very few people (only three). 

  **Conclusion**
  - The presenters thank the audience for their attendance and invite questions.


created_at: 2024-08-03 14:02:12
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Speaker Introduction:**
  - Day job: Works for a boutique pen test company called SecConsult, primarily in Europe and Asia.
  - Night job: Open-source developer under the alias ScalSec.
  - Notable projects: PyPyCats, AIOSMB, MSLDAP, Octopon.

  **Talk Overview:**
  - **Spooky Authentication at a Distance**: A novel technique allowing remote authentication as a local user on a compromised machine without elevated privileges.
  - **No Initial Point of Compromise Required**: The technique focuses on leveraging the compromised user's privileges to access servers and resources within the network.
  - **Practical Applications**: Demonstrating the potential impact, including performing a no-interaction, full domain takeover using a malicious peripheral in a restricted environment.

  **Windows Authentication Protocols:**
  - **Overview**: Modern authentication protocols involve key exchange, providing encryption and decryption capabilities for subsequent communications.
  - **Generic Network Protocol**: Version negotiation, authentication protocol negotiation, authentication, and shared secret establishment.
  - **LDAP Case Study**: Supports various authentication methods, including Sicily (raw NTLM), SASL (with Espinego and GSS API), and external (MTLS-based authentication).

  **Authentication Protocols in Detail:**
  - **NTLM**: Negotiation, authentication, and challenge messages exchanged between client and server, resulting in a shared secret for encryption and integrity protection.
  - **Espinego**: An authentication protocol selector that supports LDAP, Kerberos, and potentially other sub-protocols; provides integrity protection against downgrade attacks.
  - **Kerberos**: Simpler than NTLM, with the complexity on the server-side; involves ticket exchange and shared secret establishment.
  - **SMB Encryption/Decryption**: Microsoft's approach involves obtaining the shared secret from LSS, using SSPI for programmatic access.

  **SSPI (Security Support Provider Interface):**
  - **Purpose**: Facilitates interaction with LSS, providing a set of APIs for acquiring credentials, initializing security contexts, querying context attributes, and encrypting/decrypting messages.
  - **Key Points**: Acquire Credential Handle, Initialize Security Context, Query Context Attributes, Encrypt Message, and Decrypt Message are the critical APIs for implementing authentication.

  **Remote Authentication via RPC:**
  - **Idea**: Wrap the SSPI APIs in an RPC, allowing remote invocation and enabling authentication on the attacker's machine using the victim's credentials.
  - **Challenge**: Retrieving the IV (Initialization Vector) for Kerberos mutual authentication, which is not directly accessible via the Query Context Attributes API.
  - **Solution**: Utilizing the Encrypt Message API to obtain the IV by encrypting a random message and unwrapping the response token.

  **Use Cases and Demonstration:**
  - **Proof of Concept**: Executing the proxy binary on the victim machine, authenticating to the main controller from another machine, and performing operations like listing shares and downloading files.
  - **Raspberry Pi Attack Tool**: Creating a pawn-everything toolkit by combining the proxy with a Raspberry Pi, HID keyboard emulation, and USB Ethernet functionality.
  - **Air-gapped Networks**: The proxy, when executed, connects back to the Raspberry Pi, providing authentication context and enabling domain enumeration and Kerberos attacks.

  **Future Research and Shout-outs:**
  - **Ethical Chaos**: Created a tool that hooks into processes on the attacker's machine, intercepting SSPI calls, which could be integrated with the presented technique.
  - **Additional API Calls**: Exploring PQ and Windows Hello certificate-based services to extend the proxy's capabilities.
  - **Open-source Tools**: WS net dash dot net (the proxy), Octopon (the attack tool), and other projects mentioned are available for further exploration.


created_at: 2024-08-03 14:10:05
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Speaker: Marcello (Bytebleeder)
  - Topic: Email security vulnerabilities
  - Disclaimer: Presentation contains sensitive information, and the speaker advises against illegal activities

  **Cloudflare Workers**
  - Serverless computing platform distributed across Cloudflare's CDN for geographical latency optimization
  - Supports JavaScript, TypeScript, and WebAssembly
  - Worker code is publicly accessible by default

  **Mail Channels**
  - Email transactional service with cybersecurity features
  - Partnership with Cloudflare allows sending emails through Cloudflare Workers
  - No authentication required for their API, accessible only via Cloudflare IPs
  - Allows sending emails from any domain, including those not controlled by the sender

  **Testing and Results**
  - Sender used a publicly available Cloudflare Worker to send test emails
  - Test emails from non-existent or uncontrolled domains failed or went to spam
  - Emails from domains using Mail Channels, including boston.gov and notepad++.org, landed in the inbox with SPF and DMARC passing
  - Further investigation revealed that Mail Channels is the largest player in the email transactional space with a 42% market share

  **Sender Policy Framework (SPF)**
  - Security control for the "from" field in SMTP, allowing authorized IPs and hostnames to send emails on behalf of a domain
  - Mail Channels customers include "include" statements in their SPF records, allowing all Mail Channels customers to spoof each other's domains
  - Alternative services like SendGrid and Mailgun offer additional security measures like sender identity verification and dedicated sending IPs

  **Vulnerability Disclosure**
  - Speaker contacted Mail Channels in November 2022 about the issue, with no response
  - Rapid7, a company that aggregates internet-wide data, assisted in further investigation and contacted Mail Channels in January 2023
  - Mail Channels CEO responded, stating they didn't consider the SPF issue a vulnerability
  - Mail Channels introduced "domain lockdown mode" in June 2023, allowing customers to specify authorized Cloudflare Workers or disallow Mail Channels from sending emails on their behalf

  **Domain Keys Identified Mail (DKIM) and DMARC**
  - DKIM: Cryptographic authentication providing a way to verify that an email was sent by the purported domain
  - DMARC: Security control for the "from" field visible to the email recipient, allowing senders to specify how receivers should handle unauthenticated emails
  - Out of 2 million Mail Channels customers, only 407 had any DMARC record, and only 105 used DKIM
  - Testing revealed that even with DMARC and DKIM set up, spoofed emails still passed SPF and landed in the inbox

  **Authenticated Received Chain (ARC)**
  - Experimental protocol designed for email forwarding scenarios, guaranteeing chain of custody but not preventing spoofing
  - ARC headers record authentication results at each hop, but Mail Channels doesn't check SPF, DMARC, or DKIM results
  - Presence of ARC passing in email headers can improve spam score, increasing the likelihood of phishing emails landing in the inbox
  - Domains without SPF, DMARC, or DKIM records can be potentially spoofed with a higher success rate, expanding the blast radius to over 3 billion domains

  **Demo and Conclusion**
  - Speaker attempted to demonstrate the vulnerability but encountered technical difficulties
  - Emphasized the importance of email security and encouraged organizations to review their SPF records and implement domain lockdown mode with Mail Channels
  - Acknowledged the assistance of researchers and Rapid7 in the investigation


created_at: 2024-08-03 14:18:58
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - The talk presents new approaches for **stack spoofing** on **Windows 64-bit** architecture.
  - **Stack spoofing**: Substituting stack frames with fake ones to hide malicious code execution.

  **Speaker Introductions**
  - **Alessandro Magnosi**: Principal security consultant at BSI, red teaming, offensive tool development, white box assessments, and bug hunting.
  - **Arash Parsa**: Dual role at CyberArk, performing threat hunting, detection engineering, and red teaming.
  - **Thanos Tserpelis**: Red teamer at Netitude, also contributed to the research.

  **Background**
  - Stack spoofing techniques aim to bypass detection of malicious code by concealing its presence in a target process's memory.
  - **Thread Stack Spoofing**: Hides malicious calls in the stack by replacing stack frames with fake ones.

  **Full Moon and Half Moon Techniques**
  - **Full Moon**: Obfuscates the stack by manipulating the call stack, making it difficult to detect.
  - **Half Moon**: Focuses on hiding the caller by emulating the prologue of an API-level API and executing an indirect system call.

  **Stack Spoofing Detection**
  - **Eclipse**: A detection algorithm designed to identify stack tampering techniques.
  - Extends the functionality of **RtlVirtualUnwind** to perform strict checks on specific instructions and call sequences.
  - Evaluates the efficacy of Eclipse against Full Moon and Half Moon techniques, discussing performance and limitations.

  **Combining Techniques**
  - Possibility of combining Full Moon and Half Moon to create a more robust method for call stack tampering resistant to detection.
  - Contributes to the growing body of knowledge in call stack tampering and provides insights for researchers and security professionals.

  **Stack Spoofing Techniques**
  - **Stack Truncation**: Variation of return address spoofing, using a trampoline to cut the call stack, but leaving it unwoundable.
  - **Stack Crafting**: Asynchronous technique, recording legitimate call stacks and crafting similar stacks when calling target functions.
  - **Stack Cloning**: Exploiting sleeping threads, cloning their call stacks to appear legitimate during conditional scanning.
  - **Stack Hiding**: Transforming a thread into a fiber with a legitimate call stack, switching to it during sleep, and restoring the original stack upon wake.

  **Full Moon Walkthrough**
  - Selects specific frames (set FPRAG, push reg, sync, and concealed) to modify the address pushed in memory.
  - Uses a ROP gadget to hijack the return flow and execute a restore function, resetting the main module.
  - Creates logical inconsistencies in the stack that can be used for detection.

  **IOCs and Detection Challenges**
  - IOCs include specific call opcodes and desync gadgets used in Full Moonwalk.
  - Difficult to deploy at scale and not easily hunted in EDRs.
  - Detection algorithm looks for invalid stacks, unbacked memory regions, private RX commit memory regions, and call mismatches.
  - False positives can occur with JITs, browsers, and C# applications.

  **Half Moon Walkthrough**
  - Takes an API name and relevant syscall instruction as input and traces the execution flow to find the relevant anti-function.
  - Recreates the frames of the API-level API by emulating its prologue, ensuring the return flow is correct.
  - Strategies for ensuring correct return flow: return on epilogue, targeted setup, and sliding breakpoints.

  **Opaque Architecture**
  - Emulate system call function by swapping itself with the frame of another function to restore the stack.
  - Enforce constraints in the implant to match the sides of the NDR stub call to stack.
  - Start a thread pointing to the shellcode, force initial frames, and then execute the implant.
  - Call Half Moonwalk to spoof functions, creating a legitimate call stack that hides the caller.

  **CHAT and Indirect Branch Tracing**
  - **CHAT** (Control-flow Integrity based on Hardware-Enforced Stack Protection): Creates a shadow stack, maintaining a list of return addresses.
  - If the return addresses don't match the writable normal call stack, a CP fault occurs, crashing the program.
  - Indirect branch tracing makes it challenging to modify the instruction pointer using exception handlers.
  - Browsers and other non-CHAT-enabled processes can still be abused for executing the technique.

  **Key Takeaways**
  - Obfuscate the stack at runtime, especially when going to sleep, to avoid detection.
  - Logical inconsistencies in the stack increase the chance of detection.
  - CHAT and indirect branch tracing pose challenges, but non-CHAT-enabled processes can still be targeted.
  - Combining stack spoofing with sleep encryption adds complexity but enhances stealth.


created_at: 2024-08-03 14:24:57
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Talk presented by **Alan Meekins** (NullAgent on social media) and Rekka Dam (absent)
  - Focuses on **Bluetooth** technology and its use by law enforcement

  **Law Enforcement Technology**
  - Police officers carry various devices such as **tasers**, **body cams**, smartphones, and pistols
  - Their vehicles are equipped with **Wi-Fi hotspots**, surveillance systems, and **dash cams** capable of **license plate reading**
  - **Axon Signal** technology connects these devices, enabling data sharing and automatic recording activation

  **Bluetooth Basics**
  - Bluetooth devices send out **beacons** or **broadcasts** to pair with other devices
  - Beacons contain parameters such as **MAC address**, manufacturer data, services, and local name
  - **Gap fields** are additional optional fields
  - Bluetooth devices can be **fingerprinted** based on the order of gap fields, manufacturer data, and MAC address

  **Axon Signal in Depth**
  - Axon Signal is a Bluetooth-enabled technology used by law enforcement
  - It connects **body cams**, **tasers**, **pistol holsters**, **dash cams**, and **laptop dongles**
  - When a taser is fired or a pistol is unholstered, a Bluetooth beacon is sent to trigger recording on body cams and dash cams
  - Dash cams can also be activated by detecting police lights and sirens
  - Axon, formerly Taser International, has an **OUI** (Organizationally Unique Identifier) of **0025DF**
  - This OUI is used in the MAC addresses of their Bluetooth devices

  **Bluetooth Broadcast Protocols**
  - Some protocols rely entirely on broadcast capability without a direct connection
  - Examples include **COVID exposure tracking**, **Apple Continuity**, and the upcoming **Drone ID**
  - These protocols can impact personal privacy and trackability

  **Detecting Axon Signal Devices**
  - Wiggle.net and RF Party app can be used to detect and analyze Bluetooth devices
  - Searching for Axon's OUI (0025DF) on Wiggle reveals locations of police departments and their Bluetooth devices
  - RF Party can detect and track Bluetooth devices, simulating a "cop detector"

  **Potential Applications**
  - Proof of body cam: Using MAC addresses to compel law enforcement to release body cam footage
  - Cop alerts: Creating alerts for specific cops or bad apples on the **Brady list**
  - Surveillance monitoring: Understanding the prevalence of technologies like facial recognition and license plate readers

  **Tools and Resources**
  - **PDF viewer**, **OUI database**, **Wiggle.net**, and **NRF Connect** app
  - **RF Party** app and open-source hardware for Bluetooth detection and analysis
  - **Android** app available now, with Mac, Linux, and Windows versions coming soon


created_at: 2024-08-03 14:32:56
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - The speaker begins by asking if the audience has ever encountered a vulnerability that seemed inexplicable.
  - He then introduces the topic of web race conditions and how they can be exploited.

  **Understanding Race Conditions**
  - Race conditions occur when multiple conflicting inputs are fired at a website, causing its state machine to collapse.
  - This can lead to the forging of trusted data, misrouting of tokens, and the creation of backdoors.
  - Traditional race conditions focus on limit overruns, but there are other classes of race conditions with greater potential.

  **The True Potential of Web Race Conditions**
  - The speaker shares a personal experience where he almost missed a serious vulnerability due to failing to zoom in on the state machine.
  - He emphasizes that race conditions can exist in any HTTP request, making everything potentially multi-step.

  **Discovering Substates**
  - To discover substates, a collision of two requests is needed: one to trigger the substate and another to access the same resource simultaneously.
  - Network jitter, which randomly delays requests, is a major barrier to achieving this collision.

  **The Single Packet Attack**
  - The speaker introduces the single packet attack technique, which eliminates network jitter by fitting 20-30 HTTP requests into a single packet.
  - This technique takes advantage of HTTP/2 and Nagle's algorithm to achieve high performance and ease of implementation.
  - It has been released as an update to the open-source tool Turbo Intruder.

  **Performance Benchmarking**
  - The speaker presents benchmarking results comparing the single packet attack to the last byte synchronization technique.
  - The single packet attack significantly reduces the median spread and standard deviation of request execution times.
  - This makes remote race conditions local and improves the effectiveness of exploitation attempts.

  **A Methodology for Finding Bugs**
  - The speaker outlines a three-step methodology for finding race condition bugs: predict, probe, and prove.
  - Prediction involves identifying potential collision points with serious consequences, while ruling out endpoints with less collision potential.
  - Probing involves sending requests individually and then simultaneously to look for anomalies or clues of a substate.
  - Proving involves understanding the behavior, replicating it, and exploring the impact.

  **Case Studies**
  - The speaker shares a case study on GitLab, where he discovered a vulnerability in the email invitation system.
  - By sending multiple requests in a single packet, he was able to create multiple invitations with the same email address.
  - He then demonstrates a live exploit, where he changes his email address multiple times in the same millisecond, causing a misrouting of confirmation tokens.

  **Further Research and Exploitation**
  - The speaker encourages further research into race conditions, highlighting the importance of spotting anomalies and understanding the root causes.
  - He mentions partial construction attacks, unsafe combinations of data structures and locking strategies, and the impact of different session handlers.
  - He also suggests exploring ways to improve the single packet attack and cause server-side delays.

  **Defense and Prevention**
  - The speaker offers defense advice, emphasizing the difficulty of predicting application behavior in the presence of race conditions.
  - He suggests eliminating substates by making the effects of each request atomic and avoiding mixing data sources.
  - Understanding the locking system used by the session handler is crucial for effective defense.

  **Conclusion**
  - The speaker summarizes the key takeaways: the single packet attack, the multi-step nature of race conditions, and the predict-probe-prove methodology.
  - He encourages the audience to try out the techniques and tools mentioned and shares his contact information for further discussion.


created_at: 2024-08-03 14:42:00
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - **Nikos** and **Oren**, cryptography and security researchers at **Fireblocks**, present their research on hacking **crypto wallets**.

  **Crypto Wallets and MPC**
  - A **crypto wallet** holds a **key** that allows users to sign transactions and send **cryptocurrency**.
  - The **single point of failure** in this setup is the key being stored in one place, making it vulnerable to theft.
  - **Multi-Party Computation (MPC)** offers a solution by splitting the key into shares held by different parties, eliminating the need for a centralized trusted party.
  - MPC has become a **common cryptographic technique** for protecting billions of dollars in cryptocurrency wallets, with commercial adoption in various industries.

  **Attacking Crypto Wallets**
  - Potential attacks on MPC crypto wallets include **denial of service**, **signature forgery**, and **private key exfiltration**.
  - The focus of the presentation is on private key exfiltration, where an attacker (Alice) collaborates with other participants to sign normal-looking transactions while secretly exfiltrating their key shares.
  - The research findings include **four novel attacks**, including **three zero-days**, affecting over **16 vendors** and open-source libraries.
  - The attacks target different protocols: **Lindle 17**, **GG18/GG20 family**, and a **"Do-It-Yourself" protocol**.

  **Background**
  - **Modulo Operator**: X modulo N is the remainder of X divided by N.
  - **Homomorphic Encryption**: Allows computation on encrypted data without decrypting it.
  - **ECDSA Signature Scheme**: The most important signature scheme in the blockchain space, used by Bitcoin and Ethereum.

  **Exploit 1: Attacking Lindle 17 Protocol**
  - **Lindle 17** is a **two-party signing protocol** where parties choose random key shares and encrypt them using homomorphic encryption.
  - During signing, Alice sends an encrypted partial signature to Bob, who finalizes it and verifies its validity before signing.
  - The paper specifies that any abort (invalid signature) should result in no later execution, i.e., the wallet must be locked.
  - However, the implementation did not lock the wallet, so the researchers devised a way to leverage this into a **private key exfiltration attack**.
  - By switching the modulus in the partial signature, Alice can determine if Bob's key share is divisible by a specific number, allowing her to extract his entire key share bit by bit.
  - The attack was successfully tested on an open-source implementation, and vendors have since mitigated it by following the paper's specification.

  **Exploit 2: Attacking GG18/GG20 Family of Protocols**
  - The **GG18/GG20** protocols are **multi-party signing protocols** involving multiple rounds of communication.
  - The focus of the attack is on the first round, which implements a **multiplication to addition** transformation.
  - Alice encrypts her multiplicative share (K) and sends it to Bob, who multiplies it with his key share (X) and adds a mask to prevent leakage.
  - The mask must be sufficiently large to prevent Alice from dividing and obtaining X.
  - The researchers found a way to cheat the **zero-knowledge range proof** used to ensure K is no bigger than 256 bits, allowing them to choose a large K and obtain X in the clear.
  - By manipulating the prime factors of N (the public key of the homomorphic encryption scheme), Alice can extract X mod P, where P is a 16-bit prime.
  - Using the **Chinese Remainder Theorem**, they can reconstruct X by obtaining 16 leakages in 16 signature sessions.
  - The attack was successfully tested on an open-source implementation, and vendors have mitigated it by adding zero-knowledge proofs for N's well-formedness.

  **Exploit 3: Attacking the "Do-It-Yourself" Protocol**
  - The **"Do-It-Yourself" protocol** is an MTA-based protocol without zero-knowledge proofs accompanying the ciphertext.
  - The mask is chosen to be as large as N, making the previous attack irrelevant.
  - However, without zero-knowledge proofs, Alice can send a non-ciphertext value, and by choosing a specific N, Bob inadvertently sends back his X (with some data processing and brute force required).
  - This attack is a condensed version of the previous one, obtaining all leakages in a single signature and then using CRT to reconstruct the key.
  - The researchers successfully demonstrated this attack and emphasized the need for more eyes on MPC implementation security.


created_at: 2024-08-03 14:50:22
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction:**
  - Talk about **Prototype Pollution Vulnerabilities** in **JavaScript**
  - Based on joint work with Musar Balio and Chris Steichel
  - Paper studies **Prototype Pollution Vulnerabilities**, their **gadgets**, and implements tools for detection
  - Previous presentation at Black Hat Asia focused on exploits in real-world applications and gadget details
  - This presentation will focus on methodology and tools

  **JavaScript Inheritance:**
  - Node.js executes code in an index file
  - First line of code creates an empty JavaScript object with a built-in **proto** property pointing to the **object prototype**
  - **Object prototype** contains reusable functions like **toString**
  - JavaScript allows extending the prototype with new properties, enabling **inheritance**
  - If a property is undefined in an object, the runtime will look for it in the prototype

  **Threat Model:**
  - Index.js file creates a simple web app handling "update" and "backup" requests
  - Attacker can send any request with parameters
  - By adding the "shell" property with the value "calc" to the object prototype, the attacker can exploit a **prototype pollution vulnerability**
  - If the backup request handler executes a function with attacker-controlled arguments, remote code execution can be achieved

  **Identifying Prototype Pollution and Gadgets:**
  - Static analysis implemented for Node.js applications and NPM packages to identify prototype pollution
  - Multi-label taint analysis used to find attacker-controlled data and potential prototype pollution vulnerabilities
  - Dynamic and static analysis combined to detect property reads from object prototypes and flows to internal Node.js function calls

  **Detected Gadgets in Node.js APIs:**
  - **Spawn function**: Executes a new process, allowing remote code execution by controlling environment variables
  - **Require function**: Includes external packages, reads package configuration files, and looks for an entry point in the "main" property
  - By polluting the "main" property, an attacker can achieve remote code execution if they control the malicious file

  **Exploiting Real Applications:**
  - Analyzed 15 popular Node.js apps on GitHub, detected prototype pollution cases, and confirmed 8 as exploitable
  - Examples include NPM CLI, parser, and rocket chat messenger
  - Exploitation challenge: Code may break if unexpected properties are added to the object prototype
  - Technique: Use race conditions to trigger remote code execution before the application crashes due to prototype pollution

  **Conclusion:**
  - Tools developed to detect prototype pollution vulnerabilities and their gadgets in Node.js APIs and NPM packages
  - 11 new gadgets detected in Node.js APIs, some of which have been fixed
  - Remote code execution vulnerabilities reported in popular open-source applications
  - Future work: Explore more efficient ways to detect gadgets, analyze NPM packages, and continue research on Node.js APIs.


created_at: 2024-08-03 15:09:36
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Speaker: Jonathan Birch, Security Engineer at Microsoft
  - Presentation Topic: **Implicit & Mutation-Based Serialization Vulnerabilities in .NET**

  **Overview of Serialization Vulnerabilities**
  - **Insecure Serialization**: Exploits leading to remote code execution (RCE) in .NET applications.
  - **Common Assumption**: Exploitation requires direct use of a serializer and the ability to tamper with serialized data.
  - **Talk Focus**: Demonstrating attacks that violate these assumptions and methods to exploit deserialization.

  **LightDB: A Case Study**
  - **LightDB**: An open-source .NET library for a NoSQL engine.
  - **Vulnerability**: Use of **Type.GetType** to convert a string into a .NET type, allowing an attacker to specify malicious types.
  - **Impact**: Potential RCE by exploiting the underlying polymorphic serializer.

  **Understanding .NET Serialization Vulnerabilities**
  - **Polymorphic Serializer**: Serializer where data dictates the type to be created.
  - **Example**: A box labeled "cat" is deserialized into a "cat" object, but an attacker can provide a box labeled "pain" to execute malicious code.
  - **Common .NET Serialization Gadgets**: Assembly.LoadWithPartialName, ObjectDataProvider, etc.

  **Implicit Serialization Vulnerabilities**
  - **LightDB Exploit**: Demonstrated through a JSON blob specifying ObjectDataProvider to launch calc.exe.
  - **MongoDB Exploit**: Similar vulnerability, but with an additional assignability check, requiring the payload to fit expected types.
  - **RavenDB Exploit**: Uses a different serializer (JSON.NET) with unsafe settings, allowing RCE by exploiting a Windows Identity serialization gadget.
  - **ServiceStack.Redis Exploit**: Uses AssemblyInstaller to perform DLL injection by calling LoadLibrary on a malicious path.

  **Serialization Mutation Attack**
  - **MartinDB**: A NoSQL engine using JSON.NET with unsafe settings, but with restrictions on serialized data.
  - **Mutation Attack**: Exploiting the ability to control key-value pairs in serialized data to collide with the syntax of an RCE payload.
  - **Example**: Using a Dictionary with a key named "$type" to specify a malicious type, resulting in RCE when deserialized.
  - **Applicability**: This attack works with various serializers and can be used to exploit websites or services accepting key-value data.

  **Bypassing Serialization Binders**
  - **Serialization Binder**: Acts as a filter during deserialization, allowing or blocking specific types.
  - **Common Misstep**: Trusting all types from a specific assembly, allowing an attacker to exploit types within that assembly.
  - **Example**: InitializedList type derived from the generic List type, allowing an attacker to specify AssemblyInstaller in the template, resulting in RCE.
  - **Contagion**: Exploiting the ability to omit type specifications for members, properties, or constructor arguments of an object.

  **Disclosure and Fixes**
  - **Disclosure**: Vulnerabilities disclosed to vendors in January 2023 or earlier.
  - **Vendor Responses**: Most vendors, except MartinDB, made fixes, but some fixes can still be bypassed.
  - **MongoDB Fix**: Added a strict allowlist for types during deserialization, making it challenging to exploit.
  - **Unfixed Libraries**: MartinDB, JSON.NET (mutation attack), and JavaScript Serializer.

  **Best Practices and Recommendations**
  - **Avoid Polymorphic Serializers**: Don't use serializers where data dictates the type.
  - **Don't Call Type.GetType**: Indicates potential unsafe serialization or reflection usage, leading to RCE.
  - **Unsafe Serializers**: Avoid using unsafe serializers anywhere, including for deep copy operations.
  - **NoSQL Engines**: Consider the risks of reading untrusted data, especially with implicit serialization vulnerabilities.
  - **Serialization Binders**: Architect your application to avoid the need for serialization binders, as they are often implemented insecurely.

  **Bonus: .NET 6+ Serialization Exploits**
  - **Myth**: .NET 6+ is immune to serialization attacks.
  - **Reality**: Exploiting .NET 6+ is harder due to the absence of some exploitable types, but deserialization gadgets like ObjectDataProvider still exist.
  - **.NET 6+ Gadgets**: AssemblyDependencyResolver and System.IO.FileInfo can be used for pingbacks by calling CreateFile on an SMB or WebDAV URL.
  - **DLL Injection**: AssemblyInstaller can be used for DLL injection if an additional exploit allows file drops.

  **Q&A**
  - Vulnerable games: Search on GitHub or NuGet for projects dependent on vulnerable libraries like LightDB.
  - Identifying vulnerabilities: Look for calls to Type.GetType with user-provided strings, indicating unsafe serialization or reflection usage.
  - AssemblyInstaller exploit: Combine with another exploit to perform file drops and ensure the presence of malicious DLLs.
  - Automapper and FastMapper: Haven't looked into them specifically, but reflection-based mappers may have similar vulnerabilities.


created_at: 2024-08-03 15:23:09
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction:**
  - Presentation on abusing manipulation points in the Android 13 runtime for anti-reverse engineering.
  - Speaker: Laurie Kirk, reverse engineer at Microsoft specializing in cross-platform malware analysis.

  **Runtime Manipulation for Anti-Reverse Engineering:**
  - Dynamic code loading techniques are commonly used to defeat static analysis of Android applications.
  - Standard methods like DEX class loader, path class loader, and Java reflective calls are easily detectable and hookable.
  - **Proposed approach:** Directly manipulate the Android runtime by modifying methods and executables in process memory, bypassing standard API calls.

  **Manipulating the Android Runtime:**
  - Android Runtime (ART) is responsible for parsing, mapping, and executing code from Android applications (APKs).
  - ART maps methods and executables from disk into process memory, providing an opportunity for manipulation.
  - **Goal:** Swap the behavior of methods to execute custom code while the application is running.

  **Finding Entry Points and Targets:**
  - Examined the Android source code to identify potential targets for manipulation.
  - Initial target: Swapping entire DEX files by modifying the 'mCookie' field, but faced a chicken-and-egg problem with the main DEX file.
  - Focused on modifying individual members within a DEX file, specifically the 'ART method' structure.

  **Intercepting Methods via JNI:**
  - Java Native Interface (JNI) allows communication between managed Java code and native C++ code.
  - Used JNI to retrieve references to target objects and their corresponding 'ART method' fields.
  - Overwrote one method's 'ART method' field with another, but it didn't work due to access modifiers and understanding the underlying native structure.

  **Understanding the Native Structure:**
  - The 'ART method' field is a pointer to an underlying native 'ART method' structure containing method data.
  - Analyzed the Android source code to understand the native representation of the 'ART method' structure and its fields.
  - Identified the 'entryPointFromQuickCompiledCode' field, which contains the actual native instructions for the method.

  **Initial Tests and Challenges:**
  - Conducted tests by overwriting random bytes in memory, but encountered repeated crashes.
  - Tried to locate the 'entryPointFromQuickCompiledCode' pointer by overwriting memory in small increments, but was unsuccessful.
  - Decided to overwrite 64 random bytes from the malicious method to the benign method, assuming similar variable sizes.

  **Second Test and Success:**
  - Modified the code to copy 64 bytes from the malicious method to the benign method.
  - Test was successful, indicating that the correct offsets and sizes were used.
  - Further testing revealed that methods must have the same signature, be static, and can be declared in separate classes.

  **Calculating Offsets and Understanding the ART Method Structure:**
  - Created a dummy 'ART method' class to calculate the offsets of its variables in memory.
  - Performed byte math to associate the bytes of two methods with their actual variables and types.
  - Confirmed the offsets by disassembling the 'entryPointFromQuickCompiledCode' field, which revealed native instructions.

  **Pushing the Boundaries:**
  - Replaced the official 'log.e' Android API with custom code to steal data, demonstrating the potential for unexpected code execution.
  - Created a static method with the same signature as 'log.e' but with custom functionality.
  - Invoking the 'log.e' method executed the custom code, stealing data from installed applications.

  **Artful: A New Open-Source Tool:**
  - Released 'Artful', a library for dynamically swapping the behavior of methods in Android 13 and 14 (Upside Down Cake).
  - Artful simplifies the process by handling the complicated calculations and providing default methods for swapping behavior.
  - Supports user-defined methods and official Android framework APIs, allowing unexpected code execution without standard API calls.

  **Summary and Benefits:**
  - Primary challenges include understanding the Android source code and performing complex pointer math.
  - Benefits: Avoid standard class loader API calls, execute unexpected code, and thwart static analysis and reverse engineering efforts.
  - Artful provides an easy-to-use library for method swapping, with potential for further extension to support different API versions.

  **Conclusion:**
  - Successfully manipulated the Android runtime by modifying methods and executables in process memory.
  - Artful library enables developers to enhance the obfuscation of their Android applications.
  - Q&A session followed the presentation.


created_at: 2024-08-03 15:37:54
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction:**
  - This talk discusses an **overlooked aspect** of **Border Gateway Protocol (BGP)** security: vulnerabilities in how its implementations parse BGP messages.
  - Software implementing BGP is relied upon for **Internet routing** and for functions such as **internal routing in large data centers**.
  - While there has been a lot of attention given to aspects of BGP protocol security, recent incidents show that a **malformed packet** can cause a **large disruption**.
  - The speakers will present a **quantitative analysis** of previous vulnerabilities in both open and closed-source popular BGP implementations.

  **BGP and Its Uses:**
  - BGP is a routing protocol that allows routers to exchange routing information and make decisions on how packets are routed across networks.
  - BGP is used for **Internet routing** but also has other use cases, such as internal data center routing, MPLS layer 3 VPNs, and custom appliances for content providers like Netflix.
  - BGP security is not just a concern for Internet service providers anymore, as any organization using BGP should be responsible for its security.

  **BGP Basics and Security:**
  - BGP has a simple state machine and a limited set of messages for peer connections, keep-alive, notification, and updates.
  - BGP packets have a header and content, which are relatively straightforward.
  - BGP, like many early internet protocols, has **no built-in security** features such as authentication or authorization.
  - Mistakes or attacks leading to **network outages and traffic redirection** happen frequently, and while the situation has improved, thousands of incidents of route leaks and hijacks still occur annually.
  - Traditional BGP security focuses on filtering incorrect or malicious routing information, origin validation, and path validation.

  **BGP Implementation Vulnerabilities:**
  - BGP implementation vulnerabilities have happened in the past, causing network outages due to different interpretations of BGP messages by routers.
  - The latest systematized work on testing BGP implementations was 20 years ago, and since then, there have been improvements in BGP security features.
  - In the past 20 years, 129 CVEs have been found in BGP implementations, with 95% of them being due to message-parsing issues.
  - There is a mix of CVEs in both open and closed BGP implementations, and while some vendors may appear to have more vulnerabilities, it could be due to better transparency and research rather than being more vulnerable.

  **The Threat Landscape:**
  - Threat actors are increasingly focusing on network infrastructure, including routers, switches, and firewalls.
  - CISA has released directives regarding the risks of exposed management interfaces on network infrastructure devices.
  - Several BGP implementations have not been systematically analyzed, and open-source implementations are gaining popularity with the trend of network function disaggregation.
  - There are many different routing protocols, platforms, and network operating systems, both open and closed-source, and the speakers cataloged and selected the most popular ones for their research.

  **Previous Vulnerabilities and Their Impact:**
  - Out of 179 non-exploited vulnerabilities that can be mapped to specific devices, 88 (49%) target routers, making them the most popular type of device being attacked.
  - Three out of these 88 vulnerabilities are decades-old CVEs affecting Cisco BGP devices that are still being exploited in 2022, highlighting the continued risk of unpatched devices.
  - These vulnerabilities, which are mainly due to parsing issues in open messages, allow for denial-of-service attacks and are being actively exploited by threat actors.

  **New Research and Methodology:**
  - The speakers first conducted manual analysis, finding issues in the design of BGP due to its age and the complexity of parsing TLV parameters and handling optional parameters.
  - They selected both open-source and closed-source BGP implementations for analysis, initially attempting static analysis but then developing a fuzzer to generate malformed input to test the implementations.
  - The fuzzer, implemented using BooFuzz, generates malformed BGP messages and monitors the target for crashes, saving the payload and restarting the target automatically.
  - The speakers found three new denial-of-service vulnerabilities in one BGP implementation, all due to issues with optional parameters.

  **Vulnerabilities and Their Impact:**
  - The vulnerabilities lead to a denial-of-service on a vulnerable BGP peer, dropping BGP sessions and rendering the peer unresponsive for a period.
  - Two out of three vulnerabilities can be triggered before the origin of the message is validated, meaning an attacker only needs to spoof a valid IP address.
  - There are over 330,000 hosts with BGP enabled on the Internet, with a significant number running Quagga or FRRouting, and over 1,000 hosts running FRRouting directly.
  - These vulnerabilities have supply chain implications, as FRRouting is an open-source project with over 1,000 forks on GitHub, and it is used as a component in other network operating systems and networking vendor solutions.

  **Risk Mitigation and Takeaways:**
  - While routing security is important, it is also crucial to consider software vulnerabilities in BGP implementations and other protocols.
  - Identify devices on your network that use BGP, assess their vulnerabilities, and patch them, taking into account supply chain issues and downstream forks that may not apply patches promptly.
  - The fuzzer developed by the speakers is open-source and can be used to test BGP implementations, and they encourage contributions and extensions to the fuzzer.
  - BGP implementations have generally matured well, but some popular ones have vulnerabilities or are too permissive, so ongoing research and fuzzing are necessary.
  - Threat actors are actively exploiting these issues, and mitigation should not be delegated solely to ISPs but should be everyone's responsibility.


created_at: 2024-08-03 15:54:31
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Presenter: Ryan O'Neill
  - Book: *Learning Linux Binary Analysis*
  - Journals: Frack, Pocker GTFO, VX Heaven, Temp Out
  - Founder: BitLackies.org, Arcana Research
  - Website: arcanaresearch.io, arcanatechnologies.io

  **Shiva: An Overview**
  - Shiva: A state-of-the-art **binary patching solution** for **ELF**
  - Custom **dynamic linker** with advanced linking and relocation operations
  - Bridges gap between developers and reverse engineers
  - Facilitates **bug fixing** in **legacy software** without source code
  - **DARPA AMP Program**: Focused on reverse engineering and ELF binary patching

  **Evolution of Shiva**
  - Origin: O'Neill's desire to write a custom ELF interpreter
  - **Interpreter chaining**: Chaining two dynamic linkers in the same process image
  - **Modular ELF virus loader interpreter**: Evolved into the first version of Shiva (x86-64)
  - **Current Version**: Shiva Alpha v0.11, forked from original, tailored for DARPA AMP and NASA

  **History of ELF Binary Patching**
  - **Early Unix Virus Research**: Silvio Cesar's work in the 90s (e.g., "UNIX Viruses" paper)
  - **ELF Virus Technology**: Similar to ELF instrumentation, involving code insertion and relocation
  - **Userland-exec()**: A function allowing userland execution without kernel involvement, by The Gruck
  - **IRISI**: Profound ELF reverse engineering software by Mayhem, chief editor of Frack
  - **Insmod for Kernel Modules**: Silvio's work on manually handling relocations to install kernel modules

  **Influential Academic Research**
  - **Katana**: A Dwarf-aware patching framework for ELF by Sergey Bratis and James Oakley
  - **Pebble**: An ELF instrumentation framework, primarily for software profiling
  - **Weird Machines in ELF**: Research by Rebecca Shapiro and Sergey Bratis on using dynamic linker relocations as a Turing-complete machine

  **Linking Concepts and Workflow**
  - **LibShiva**: An ELF linker, loader, and transformer, built on LibElfMaster (forensic reconstruction of broken binaries)
  - **Linker Chaining**: Cooperating with LD Linux.so to transform program with patches and shared libraries
  - **ELF Relocatable Objects**: Rich symbolic metadata, compiled with a large code model for absolute addresses
  - **Shiva Module Loader**: Handles loading, linking, and transforming patch and executable
  - **Userland-exec() Functionality**: Allows dynamic testing of patches without modifying the target binary
  - **Shiva Prelinker**: Updates interpreter path and adds new dynamic segment for permanent patching

  **Symbol Interposition**
  - Allows rewriting of code and data by name, including global data and functions
  - **Example**: Redefining a constant string in a program by patching it with a new value

  **Transformations and Function Splicing**
  - **Transformations**: Extending relocations to support complex patching operations like function splicing
  - **Function Splicing**: Inserting C code into any function, with full relocation and symbolic access
  - **Spliceable Code Characteristics**: Fully relocatable, rich symbolic access, no size limit, access to live variables and registers

  **Confluent Linking Technologies**
  - **Cross Relocations**: One dynamic linker relying on another to solve its own relocation
  - **Delayed Relocations**: Handled by Shiva post-linker after LD Linux.so has finished
  - **Shiva Post-linker**: Updates AT entry in auxiliary vector to handle delayed relocations

  **Demonstration**
  - **Symbol Interposition**: Rewriting global code and data dynamically and permanently
  - **Function Splicing**: Inserting code into an existing function, updating relocations and control flow graph

  **Conclusion**
  - Shiva: A powerful tool for ELF binary patching, open-sourced by O'Neill
  - Useful for developers, reverse engineers, and security researchers
  - Websites: arcanaresearch.io, arcanatechnologies.io
  - Contact: Email for queries


created_at: 2024-08-03 16:16:26
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **Introduction**
  - Talk focuses on **historical software** from the **early '90s** and **late '80s**
  - Specifically, software for the **Commodore Amiga**, a **16-bit** system
  - Using vintage computing platforms as a **playground** for learning about **vulnerability research** and **exploiting**

  **Vintage Computing Environments**
  - Provide an interesting and fun **playground environment** for learning and experimenting with **reverse engineering**, **vulnerability discovery**, and **exploit development**
  - Serve as an introduction to **hacking** for those new to the field
  - Allow for experimentation without the complexity and security measures of modern systems

  **Commodore Amiga**
  - One of the first systems to use **C** as a first-class language, have a **multitasking OS**, and a **TCP/IP stack**
  - Has a dedicated following of users and software even today
  - Offers a unique system among retro systems

  **Retrocomputing Interest**
  - Large interest in vintage and retrocomputing systems, with many **YouTube channels** and **Twitter users** dedicated to the topic
  - People collect hardware, software, and documentation, and work on preservation and restoration
  - There is a huge body of software from the '80s and '90s that is no longer in active use but is still interesting to explore

  **Advantages of Using Vintage Systems**
  - **Emulated environments** are inexpensive and easily accessible, requiring just a few gigabytes of space
  - Provide a **wholly self-contained environment** for research with comprehensive **emulation**, **documentation**, and **preserved software archives**
  - Offer an **easy-to-use toolset** with built-in **debuggers** for emulation developers
  - Pre-date modern security awareness and exploit mitigations, providing a simpler environment for learning

  **Potential Benefits**
  - Environment for exploring software with the **longest computing history**
  - High yield of **zero-day findings** due to less competition and more vulnerable software
  - No ethical concerns as most vintage software is no longer in active use
  - Legacy systems using similar architectures may still be in operation, providing real-world applicability

  **Motorola 68K Processors**
  - Found in a variety of systems, including printers, industrial controllers, networking equipment, automotive systems, and more
  - The Amiga is one of the best desktop computer platforms for tinkering with the 68K
  - Offers a range of processors, from the 6820 to the 6860

  **Amiga Hardware**
  - Custom chipsets, such as Paula, Denise, Lisa, and Agnes, are what make an Amiga unique
  - Memory architecture involves **chip RAM** (shared between the 68K and custom chips) and **fast RAM** (exclusive to the 68K)
  - Available in all-in-one models and desktop models, with the latter being more common in the US for video production

  **Amiga OS**
  - Classic Amiga OS (for 68K Amigas) is a perfect playground for vulnerability research
  - No virtual memory, multi-user capabilities, or complex page tables to understand
  - Preemptive, multitasking OS, allowing for seamless switching between processes
  - Rich file formats, parsers, and communication software, providing ample targets for research

  **Modern Modifications**
  - **PiStorm** accelerator replaces the 68K with a Raspberry Pi, providing faster clock speeds and a smoother experience
  - **Network adapters**, **storage solutions**, and **FPGA recreations** of the entire system are also available
  - **WinUAE** is an incredibly accurate Amiga emulator, providing easy access to low-level debug features and save states

  **Setting up WinUAE**
  - Requires configuration of CPU, speed, floating-point unit, just-in-time recompilation, chipset, ROM, memory, hard drives, etc.
  - Can add hardware features like BSD Sockets library for networking and RTG graphics
  - Kickstart ROM should match the OS version on disk to avoid wasting memory

  **Resources for Amiga OS**
  - Hyperion continues to release patches and updates for Amiga OS, with the latest version being 3.2.2
  - Development environment includes SAS C compiler, DevPack assembler, and matching NDK for headers and data structures
  - Old computer books and archives like Tosec and Archive.org provide valuable documentation and software

  **Amiga OS Architecture**
  - EXEC library handles most communication with hardware and is crucial for porting Amiga OS
  - Libraries loaded into memory have a base address and a jump table for API calls
  - Sys base at hexadecimal address four is the bootstrap into the system

  **Case Study: GUI FTP**
  - Simple FTP client software from the early '90s, pre-dating awareness of buffer overflow vulnerabilities
  - Long server welcome messages, file names, and file lists cause crashes
  - By connecting to a local FTP server with a payload, it is possible to gain control over the program counter and execute code

  **Exploit Development**
  - Creating a minimal FTP server allows for easy insertion of exploit code
  - Code execution clobbers the first 56 bytes, providing a limited range for payload
  - Code reuse technique is employed, jumping to the stack pointer to find reliable code execution
  - Payload is split across two code regions, with the first acting as a trampoline to move the stack pointer and jump to the second part
  - Shellcode writes a file to disk, taking advantage of Amiga APIs
  - At the end, the system is put to sleep to avoid crashing

  **Conclusion**
  - Vintage systems provide an accessible and educational environment for learning about vulnerability research and exploitation
  - They offer a fun and nostalgic alternative to modern systems, allowing for exploration and experimentation
  - By understanding the basics of these simpler systems, one can build a foundation for tackling more complex architectures


created_at: 2024-08-03 16:37:41
prompt:
[cell repeats an earlier one in this file: 1955 characters]

summary:
  **The Fight for Reproductive Justice in the Digital Age**
  - The recent overturning of federal legal protections for reproductive rights has brought to light the issue of **digital surveillance** and its impact on people seeking, providing, or supporting **abortion access**.

  **The Role of Data and Surveillance**
  - Various services and apps track **movements** and **communications**, which can be accessed by law enforcement and private parties to **police and punish** abortion access.
  - This data can be used as **evidence** against individuals, their friends, family, or providers.

  **Legal and Technological Strategies**
  - **Litigation**: Using the Freedom of Information Act to hold law enforcement accountable for unlawfully collecting and sharing license plate reader data.
  - **Challenging dragnet surveillance**: Fighting against geofence and keyword warrants that are too broad and violate the Fourth Amendment.
  - **Legislative efforts**: Working to pass data sanctuary laws and limit dragnet surveillance at the state level, especially in blue states.
  - **Technological tools**: Building and promoting the use of tools to protect privacy and security, such as secure communications, mobile device security, and compartmentalization.

  **The Role of Companies and Nonprofits**
  - Companies and nonprofits should re-evaluate their data retention and collection practices to protect individuals' privacy.
  - Data collection, aggregation, and brokering industries are a major concern, especially when tech companies misunderstand their liabilities under HIPAA.
  - It is important to normalize the use of privacy technologies and educate less tech-savvy individuals on good OPSEC procedures.

  **Systemic Change and Consumer Data Privacy Law**
  - There is currently no comprehensive consumer data privacy law in the United States, leaving individuals' data vulnerable to law enforcement access.
  - **Encryption** and **privacy** are under attack, with law enforcement seeking backdoors and increased access to communications.
  - It is crucial to contact representatives and senators to oppose bills that threaten encryption and privacy, such as the **EARN IT Act**, **COSA**, **Stop CSAM Act**, and **Cooper Davis Act**.

  **Practical Advice and Resources**
  - It is important to use secure communication methods and backup strategies, as well as consider street-level surveillance when seeking abortion care.
  - Resources like the **Surveillance Self-Defense** project provide instructional guides and personas to help individuals protect their privacy.
  - Organizations like **Jane's Due Process** offer practical advice and digital security expertise for teens and patients seeking abortion access.

  **The Role of Civic Engagement**
  - It is important to frame the issue of privacy and encryption in a non-partisan way, highlighting how it affects individuals across the political spectrum.
  - Engaging with representatives and senators, even in majority-strong districts, is crucial to making systemic change and protecting reproductive justice.

  **Conclusion**
  - The fight for reproductive justice in the digital age requires a combination of legal, technological, and legislative strategies, as well as individual and systemic change.
  - It is important to educate and empower individuals to protect their privacy and security while also advocating for stronger consumer data privacy laws.


