Podcasts about poc gtfo

Welcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: POC GTFO culture as partial antidote to alignment wordcelism, published by lc on March 15, 2023 on LessWrong. There is an important asymmetry in reception for prophets. Go read that post first if you haven't. For those who don't want to, the gist is: Given the same level of specificity, people will naturally give more credit to the public thinker that argues that society or industry will change, because it's easy to recall active examples of things changing and hard to recall the vast amount of negative examples where things stayed the same. If you take the Nassim Taleb route of vapidly predicting, in an unspecific way, that interesting things are eventually going to happen, interesting things will eventually happen and you will be revered as an oracle. If you take the Francis Fukuyama route of vapidly saying that things will mostly stay the same, you will be declared a fool every time something mildly important happens. The computer security industry happens to know this dynamic very well. No one notices the Fortune 500 company that doesn't suffer the ransomware attack. Outside the industry, this active vs. negative bias is so prevalent that security standards are constantly called "horrific" without articulating the sense in which they fail, and despite the fact that online banking system works pretty well virtually all of the time. And inside the industry, vague and unverified predictions that Companies Will Have Security Incidents, or that New Tools Will Have Security Flaws, are treated much more favorably in retrospect than vague and unverified predictions that companies will mostly do fine. Even if you're right that an attack vector is unimportant and probably won't lead to any real world consequences, in retrospect your position will be considered obvious. On the other hand, if you say that an attack vector is important, and you're wrong, people will also forget about that in three years. So better list everything that could possibly go wrong, even if certain mishaps are much more likely than others, and collect oracle points when half of your failure scenarios are proven correct. This would be bad on its own, but then it's compounded with several other problems. For one thing, predictions of doom, of course, inflate the importance and future salary expectations of information security researchers, in the same sense that inflating the competence of the Russian military is good for the U.S. defense industry. When you tell someone their Rowhammer hardware attacks are completely inexploitable in practice, that's no fun for anyone, because it means infosec researchers aren't going to all get paid buckets of money to defend against Rowhammer exploits, and journalists have no news article. For another thing, the security industry (especially the offensive side) is selected to contain people who believe computer security is a large societal problem, and that they themselves can get involved, or at least want to believe that it's possible for them to get involved if they put in a lot of time and effort, and so they're really inclined to hear you if you're about to tell them how obviously bad information security at most companies really is. But worst of all, especially for those evaluating particular critiques and trying to prevent problems in advance, is a fourth problem: unskilled hackers are bad at modeling defenders, just as unskilled defenders are bad at modeling computer hackers. It's actually very easy - too easy - to write stories and pseudocode for exploits that an average, security-aware software engineer will believe works in practice. Newbies to the field are often shocked by how many times they run into a situation where their attacks "almost" work, just like entrepreneurs are shocked by how many startup ideas "almost" work. This happens not because the ...

Link to original articleWelcome to The Nonlinear Library, where we use Text-to-Speech software to convert the best writing from the Rationalist and EA communities into audio. This is: POC GTFO culture as partial antidote to alignment wordcelism, published by lc on March 15, 2023 on LessWrong. There is an important asymmetry in reception for prophets. Go read that post first if you haven't. For those who don't want to, the gist is: Given the same level of specificity, people will naturally give more credit to the public thinker that argues that society or industry will change, because it's easy to recall active examples of things changing and hard to recall the vast amount of negative examples where things stayed the same. If you take the Nassim Taleb route of vapidly predicting, in an unspecific way, that interesting things are eventually going to happen, interesting things will eventually happen and you will be revered as an oracle. If you take the Francis Fukuyama route of vapidly saying that things will mostly stay the same, you will be declared a fool every time something mildly important happens. The computer security industry happens to know this dynamic very well. No one notices the Fortune 500 company that doesn't suffer the ransomware attack. Outside the industry, this active vs. negative bias is so prevalent that security standards are constantly called "horrific" without articulating the sense in which they fail, and despite the fact that online banking system works pretty well virtually all of the time. And inside the industry, vague and unverified predictions that Companies Will Have Security Incidents, or that New Tools Will Have Security Flaws, are treated much more favorably in retrospect than vague and unverified predictions that companies will mostly do fine. Even if you're right that an attack vector is unimportant and probably won't lead to any real world consequences, in retrospect your position will be considered obvious. On the other hand, if you say that an attack vector is important, and you're wrong, people will also forget about that in three years. So better list everything that could possibly go wrong, even if certain mishaps are much more likely than others, and collect oracle points when half of your failure scenarios are proven correct. This would be bad on its own, but then it's compounded with several other problems. For one thing, predictions of doom, of course, inflate the importance and future salary expectations of information security researchers, in the same sense that inflating the competence of the Russian military is good for the U.S. defense industry. When you tell someone their Rowhammer hardware attacks are completely inexploitable in practice, that's no fun for anyone, because it means infosec researchers aren't going to all get paid buckets of money to defend against Rowhammer exploits, and journalists have no news article. For another thing, the security industry (especially the offensive side) is selected to contain people who believe computer security is a large societal problem, and that they themselves can get involved, or at least want to believe that it's possible for them to get involved if they put in a lot of time and effort, and so they're really inclined to hear you if you're about to tell them how obviously bad information security at most companies really is. But worst of all, especially for those evaluating particular critiques and trying to prevent problems in advance, is a fourth problem: unskilled hackers are bad at modeling defenders, just as unskilled defenders are bad at modeling computer hackers. It's actually very easy - too easy - to write stories and pseudocode for exploits that an average, security-aware software engineer will believe works in practice. Newbies to the field are often shocked by how many times they run into a situation where their attacks "almost" work, just like entrepreneurs are shocked by how many startup ideas "almost" work. This happens not because the ...

Kutsuimme kartanolle vieraaksi legendaarisen hakkerin Harry Sintosen. Hän on löytänyt poikkeuksellisen monia korkean profiilin tietoturvahaavoittuvuuksia vuosien varrella. Keskustelemme Harryn kanssa siitä kuinka hän päätyi tälle alalle, kuinka valitsee kohteet, joista etsii haavoittuvuuksia ja kuinka haavoittuvuuksien etsiminen on muuttunut. Lisäksi Harry kertoo useita mielenkiintoisia tarinoita haavoittuvuuksien etsimisestä ja löytämisestä.  Äänijulkaisun lähdeluettelo: Vieras: Harry Sintonen https://sintonen.fi Mastodon https://fi.wikipedia.org/wiki/Mastodon_(ohjelmisto) Fediverse https://en.wikipedia.org/wiki/Fediverse Tietoturvayhteisön suosima Mastodon-palvelin https://infosec.exchange/ Metan VR-sijoitukset https://twitter.com/nathanbenaich/status/1586400993381687298/ MorphOS https://www.morphos-team.net Nand Game https://nandgame.com Tracers In The Dark - Andy Greenberg https://www.amazon.com/Tracers-Dark-Global-Crime-Cryptocurrency/dp/0385548095 Business insider, So expensive https://www.youtube.com/user/businessinsider/videos 4am - arkisto https://archive.org/details/apple_ii_library_4am 4am: Mr. Do! https://ia601304.us.archive.org/13/items/MrDo4amCrack/Mr.%20Do%20(4am%20crack).txt 4a: Gumball https://ia800402.us.archive.org/34/items/Gumball4amCrack/Gumball%20%284am%20%26%20san%20inc%20crack%29.txt PoC||GTFO 0x15 https://archive.org/stream/pocorgtfo15/pocorgtfo15_djvu.txt Toot! https://apps.apple.com/fi/app/toot/id1229021451?l=fi Metatext https://apps.apple.com/fi/app/metatext/id1523996615?l=fi  

FEATURED VOICES IN THIS EPISODEClint BruceClint Bruce is a former Navy Special Warfare Officer, a graduate of the US Naval Academy, decorated athlete, and seasoned entrepreneur. A 4-year letter winner at Navy playing middle linebacker, captain and MVP of the '96 Aloha Bowl Championship team, he was named to multiple all-star teams his senior year. He enjoyed opportunities with both the Baltimore Ravens and New Orleans Saints and was inducted into the Navy/Marine Corps Stadium Hall of Fame in 2009. Clint's desire to serve was deep and firmly rooted. He left the NFL to pursue becoming a Navy SEAL and successfully completed BUDS (Basic Underwater Demolition SEAL Training) in 1998 with Class 217. Joining SEAL Team FIVE, Clint completed multiple deployments pre and post-911 directly involved in counter-terrorism and national security missions globally. He is a co-founder of Carry the Load, which was founded to restore true meaning to Memorial Day and celebrate the service and sacrifice of Police, Fire, and Rescue personnel and their families during the month of May. Clint lives in Dallas with his college sweetheart and three daughters who are not impressed that he played football or was a Navy SEAL.Patrick GrayPatrick Gray is the producer and presenter of the Risky Business weekly information security podcast, a weekly podcast that launched in 2007. He formerly was a journalist for publications including Wired.com, ZDNet Australia, The Sydney Morning Herald, The Age, The Bulletin (magazine) and Men's Style Australia.Eric OlsonEric Olson is the Director of Threat Intelligence for Jet Blue Airways. A threat intelligence professional for more than 20 years, Eric has had executive roles including Senior Vice President of Product Management and Vice President, Intellugence Operations, at LookingGlass Cyber Solutions, and was VP of Product Strategy at Cyveillance.Allan FriedmanAllan Friedman is Senior Advisor and Strategist at the United States Cybersecurity and Infrastructure Security Agency, and one of the nation's leading experts on Software Bill of Materials. Allan leads CISA's efforts to coordinate SBOM initiatives inside and outside the US government, and around the world. He is known for applying technical and policy expertise to help audiences understand the pathways to change in an engaging fashion, and is frequently invited to speak or keynote to industry, academic, and public audiences. Wearing the hats of both a technologist and a policy maker, Allan has over 15 years of experience in international cybersecurity and technology policy. His experience and research focuses on economic and market analyses of information security. On the practical side, he has designed, convened, and facilitated national and international multistakeholder processes that have produced real results, helping diverse organizations finding common ground on contentious, cutting edge issues.Evan Sultanik, PhDEvan Sultanik is a Principal Computer Security Researcher at Trail of Bits. A computer scientist with extensive experience both in industry (as a software engineer) and academia, Evan is an active contributor to open source software. He is author of more than two dozen peer-reviewed academic papers, and is particularly interested in intelligent, distributed/peer-to-peer systems. Evan is editor of and frequent contributor to the International Journal of PoC||GTFO. William WoodruffWilliam Woodruff is a senior security engineer at Trail of Bits, contributing to the engineering and research practices in work for corporate and governmental clients. He has developed several of our open-source projects (e.g., twa, winchecksec, KRF, and mishegos). His work focuses on fuzzing, program analysis, and automated vulnerability reasoning. Outside of Trail of Bits, William helps to maintain the Homebrew project, the dominant macOS package manager. Before joining Trail of Bits, he was a software engineering intern at Cipher Tech Solutions, a small defense subcontractor. He has participated in the Google Summer of Code for four years (two as a student, two as a mentor) and taught a class in ethical hacking as a college senior. William holds a BA in philosophy from the University of Maryland (2018).HOST: Nick SelbyAn accomplished information and physical security professional, Nick leads the Software Assurance Practice at Trail of Bits, giving customers at some of the world's most targeted companies a comprehensive understanding of their security landscape. He is the creator of the Trail of Bits podcast, and does everything from writing scripts to conducting interviews to audio engineering to Foley (e.g. biting into pickles). Prior to Trail of Bits, Nick was Director of Cyber Intelligence and Investigations at the NYPD; the CSO of a blockchain startup; and VP of Operations at an industry analysis firm.PRODUCTION STAFFStory Editor: Chris JulinAssociate Editor: Emily HaavikExecutive Producer: Nick SelbyExecutive Producer: Dan GuidoRECORDINGRecorded at Rocky Hill Studios, Ghent, NY - Nick Selby, Engineer;22Springroad Tonstudio, Übersee, Germany - Volker Lesch, EngineerRemote recordings were conducted at Whistler, BC, Canada (Nick Selby); Clint Bruce was recorded in a Google Meet session; Patrick Gray provided recordings of himself from Australia, courtesy of the Risky Business podcast. Eric Olson recorded himself on an iPhone. Washington, DC (tape sync of Allan Friedman by George Mocharko). Trail of Bits supports and adheres to the Tape Syncers United Fair Rates Card.Edited by Emily Haavik and Chris JulinMastered by Chris JulinMUSICDispatches From Technology's Future, the Trail of Bits theme, Chris JulinEVERYBODY GET UP - No Vocals & FX - Ian PostJD SCAVENGER by Randy SharpRIPPLES by Tamuz DekelFUTURE PERFECT, Evgeny BardyuzhaTHE SWINDLER, The Original Orchestra]BLUE - ALTERNATIVE - INSTRUMENTAL VERSION by Faith RichardsOU ALLONS NOUS D'ICI - INSTRUMENTAL, Dan ZeituneLITTLE EDGY, Chris JulinSCAPES: Gray NorthReproductionWith the exception of any Copyrighted music herein, Trail of Bits Season 1 Episode 3; It Depends © 2022 by Trail of Bits is licensed under Attribution-NonCommercial-NoDerivatives 4.0 International. This license allows reuse: reusers may copy and distribute the material in any medium or format in unadapted form and for noncommercial purposes only (noncommercial means not primarily intended for or directed towards commercial advantage or monetary compensation), provided that reusers give credit to Trail of Bits as the creator. No derivatives or adaptations of this work are permitted. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/4.0/.Referenced in this Episode:The original blog post announcing the availability of It Depends describes the history you just heard with more technical specificity, and also of course links to the GitHub repository where you can download It Depends and try it for yourself. That blog post also links to the repository where you can download pip-audit, and give that a whirl.In the 2021 Executive Order on Improving the Nation's Cybersecurity, the Biden Administration announced that it would require SBOMs for all software vendors selling to the federal government.Dependabot is a tool available to GitHub users. If you're interested in the catalog of open source projects Trail of Bits participates in and contributes to, please read the blog post Celebrating our 2021 Open Source Contributions. There, you can read about our work contributing for example to LLVM - the compiler and toolchain technologies we discuss in the Podcast episode Future - to Pwndbg, a GDB plug-in that makes debugging with GDB “suck less.” The post includes links to contributions our engineer consultants have made to a huge range of open source projects from assert-rs to ZenGo-X.Meet the Team:CHRIS JULINChris Julin has spent years telling audio stories and helping other people tell theirs. These days he works as a story editor and producer for news outlets like APM Reports, West Virginia Public Broadcasting, and Marketplace. He has also taught and mentored hundreds of young journalists as a professor. For the Trail of Bits podcast, he serves as story and music editor, sound designer, and mixing and mastering engineer.EMILY HAAVIKFor the past 10 years Emily Haavik has worked as a broadcast journalist in radio, television, and digital media. She's spent time writing, reporting, covering courts, producing investigative podcasts, and serving as an editorial manager. She now works as an audio producer for several production shops including Us & Them from West Virginia Public Broadcasting and PRX, and APM Reports. For the Trail of Bits podcast, she helps with scripting, interviews, story concepts, and audio production.

FEATURED VOICES IN THIS EPISODEDan GuidoDan Guido is the CEO of Trail of Bits, a cybersecurity firm he founded in 2012 to address software security challenges with cutting-edge research. In his tenure leading Trail of Bits, Dan has grown the team to 80 engineers, led the team to compete in the DARPA Cyber Grand Challenge, built an industry-leading blockchain security practice, and refined open-source tools for the endpoint security market. In addition to his work at Trail of Bits, he's active on the boards of four early-stage technology companies. Dan contributes to cybersecurity policy papers from RAND, CNAS, and Harvard. He runs Empire Hacking, a 1,500-member meetup group focused on NYC-area cybersecurity professionals. His latest hobby coding project -- AlgoVPN -- is the Internet's most recommended self-hosted VPN. In prior roles, Dan taught a capstone course on software exploitation at NYU as a faculty member and the Hacker in Residence, consulted at iSEC Partners (now NCC Group), and worked as an incident responder for the Federal Reserve System.Evan SultanikEvan Sultanik is a Principal Computer Security Researcher at Trail of Bits. A computer scientist with extensive experience both in industry (as a software engineer) and academia, Evan is an active contributor to open source software. He is author of more than two dozen peer-reviewed academic papers, and is particularly interested in intelligent, distributed/peer-to-peer systems. Evan is editor of and frequent contributor to the International Journal of PoC||GTFO. Trent BrunsonTrent is a Principal Security Engineer and Research Practice Manager at Trail of Bits. He has worked in computer security since 2012 as a researcher and engineer at Assured Information Security in Rome, NY, and at the Georgia Tech Research Institute, where he served as the Threat Intelligence Branch Chief and the Associate Division Chief of Threat Intelligence & Analytics.  Trent received his Ph.D. in computational physics from Emory University in Atlanta in 2014, and his dissertation work applied the renormalization group and Monte Carlo methods to study exact results on complex networks.Host: Nick SelbyAn accomplished information and physical security professional, Nick leads the Software Assurance practice at Trail of Bits, giving customers at some of the world's most targeted companies a comprehensive understanding of their security landscape. He is the creator of the Trail of Bits podcast, and does everything from writing scripts to conducting interviews to audio engineering to Foley (e.g. biting into pickles). Prior to Trail of Bits, Nick was Director of Cyber Intelligence and Investigations at the NYPD; the CSO of a blockchain startup; and VP of Operations at an industry analysis firm. Production StaffStory Editor: Chris JulinAssociate Editor: Emily HaavikExecutive Producer: Nick SelbyExecutive Producer: Dan GuidoRecordingRocky Hill Studios, Ghent, New York. Nick Selby, EngineerPreuss-Projekt Tonstudio, Salzburg, Austria. Christian Höll, EngineerRemote recordings: Whistler, BC (Nick Selby); Queens, NY (Emily Haavik)Edited and Mastered by Chris JulinTrail of Bits supports and adheres to the Tape Syncers United Fair Rates CardMusicDispatches From Technology's Future, the Trail of Bits theme, Chris JulinCANTO DELLE SCIACALLE, Cesare PastanellaSHALLOW WATER - REMIX, Omri Smadar, Yehezkel Raz, Sivan TalmorALL IN YOUR STRIDE, ABELET IT RISE, Divine Attraction ROAD LESS TRAVELED, The David Roy CollectiveKILLING ME SOFTLY, Ty SimonTECH TALK, Rex BannerLOST ON EARTH, Marek JakubowiczSCAPES, Gray NorthReproductionWith the exception of any Copyrighted music herein, Trail of Bits Season 1 Episode 0; Immutable © 2022 by Trail of Bits is licensed under Attribution-NonCommercial-NoDerivatives 4.0 International.  This license allows reuse: reusers may copy and distribute the material in any medium or format in unadapted form and for noncommercial purposes only (noncommercial means not primarily intended for or directed towards commercial advantage or monetary compensation), provided that reusers give credit to Trail of Bits as the creator. No derivatives or adaptations of this work are permitted. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc-nd/4.0/. Referenced in this EpisodeIn “Are Blockchains Decentralized? Unintended Centralities in Distributed Ledgers,” Evan Sultanik, Trent Brunson, and nine other engineers on the Trail of Bits Research and Engineering and Software Assurance teams report their findings from the year-long project to examine Blockchain centrality. Fluxture is a free and open source software crawling framework for Blockchains and peer-to-peer systems that Trail of Bits created to assist with the work described in this episode. We also link to the free and open source recursive dependency graphing tool It-Depends, which we will discuss in depth in the upcoming podcast episode that's creatively titled, It-Depends. The Are Blockchains Decentralized paper cites more than 30 academic and commercial research papers. There is literature about how malicious Tor exit nodes surveil and inject attacks into Tor-users' traffic. You may also read  comments about exit node manipulation by Tor network maintainers. One report states that On February 2, 2021, a single, malicious actor was able to fully manage 27 percent of Tor's exit capacity.The reports “How Malicious Tor Relays are Exploiting Users in 2020 (Part I)" hypothesized that the entity behind a range of malicious tor relays would not to stop its activities anytime soon; the follow-up, "Tracking One Year of Malicious Tor Exit Relay Activities" continues the discussion. Meet the Team:CHRIS JULINChris Julin has spent years telling audio stories and helping other people tell theirs. These days he works as a story editor and producer for news outlets like APM Reports, West Virginia Public Broadcasting, and Marketplace. He has also taught and mentored hundreds of young journalists as a professor. For the Trail of Bits podcast, he serves as story and music editor, sound designer, and mixing and mastering engineer.EMILY HAAVIKFor the past 10 years Emily Haavik has worked as a broadcast journalist in radio, television, and digital media. She's spent time writing, reporting, covering courts, producing investigative podcasts, and serving as an editorial manager. She now works as an audio producer for several production shops including Us & Them from West Virginia Public Broadcasting and PRX, and APM Reports. For the Trail of Bits podcast, she helps with scripting, interviews, story concepts, and audio production.

00:01:10 Sunshine CTF 00:10:27 Question Discussion: Opinions regarding CTF's vs. Real World Exploits 00:24:15 ENCRYPT CTF Discussion 00:31:25 Pwn2Own 2019 (P2O) and Tesla Hacking 00:41:25 Tricking Tesla Autopilot 00:56:45 Ghidra 9.0.1 Release 00:59:30 Commando VM 01:06:50 PoC||GTFO 0x19 01:13:20 ASUS Update Tool Backdoor 01:19:05 Windows Defender APC Code Injection Sensors 01:22:55 BSEA-1 - A Stream Cipher Backdooring Technique 01:32:40 LockerGoga Randomware Vaccination 01:37:40 Hearing your touch: A new acoustic side channel on smartphones 01:43:05 Keybase is not softer than TOFU 01:48:30 Exploitation Techniques and Defenses for Data-Oriented Attacks 01:56:00 Restricting Control Flow During Speculative Execution with Venkman Additional Links: Sunshine CTF Writeups Attacking Javascript Engines Phrack Article

Alvaro was at Toorcamp and DEFCON. Chris from The Amp Hour and Jack from the Darknet Diaries podcast were also there. Jen went to the Vintage Computer Festival Alvaro and Jen will both be at the Hackaday Superconference this year. Call for papers is still open!!! Hardware Developers Didactic Galactic and the Mountain View Reverse Engineering Meetup A listener, David, wrote up his process for reverse engineering a robot cat litter box . Alvaro’s fridge reverse engineering twitter thread. Bunnie Huang’s book “Essential Guide to Electronics in Shenzhen” Jen mentioned playing with IDA and the Hex-Rays Decompiler Dmitri’s CortexProg ARM SWD debugger/programmer. KiwiCon We have a mirror of PoC||GTFO on the website. Have comments or suggestions for us? Find us on twitter @unnamed_show,  or email us at show@unnamedre.com. Music by TeknoAxe (http://www.youtube.com/user/teknoaxe)

GSoC 2018 Projects announced, tutorial FreeBSD jails with iocage, new Code of Conduct for FreeBSD, libhijack, and fancy monitoring for OpenSMTPD This episode was brought to you by Headlines Google Summer of Code 2018 (https://summerofcode.withgoogle.com/organizations/?sp-page=5) FreeBSD (https://www.freebsd.org/projects/summerofcode.html) FreeBSD Google Summer oF Code Ideas (https://wiki.freebsd.org/SummerOfCodeIdeas) You can join #freebsd-soc on the efnet IRC network to chat with FreeBSD developers interested in mentoring student proposals and projects, past FreeBSD/GSoC students, and other students applying to FreeBSD/GSoC this year. NetBSD (https://mail-index.netbsd.org/netbsd-advocacy/2018/02/12/msg000765.html) You can get a stipend (paid for by Google) and spend a few months getting to know and improving the insides of NetBSD or pkgsrc. ``` The schedule is: 12-27 March Applying 23 April Find out if you were accepted 14 May - 22 August Do the project! We have some suggestions for suitable projects: - ARM EFI bootloader - Using libFuzzer on base tools - Refactoring ALTQ (QoS implementation) and integrating with NPF - Testsuite for libcurses - Improve pkgin Other suggestions and details are at: https://wiki.netbsd.org/projects/gsoc/ ``` These projects are suggestions; you can come up with your own. Suggestions for other suitable projects are welcome. Feel free to contact, or chat around on IRC: irc.freenode.org #netbsd #netbsd-code #pkgsrc Haiku (https://summerofcode.withgoogle.com/organizations/4821756754264064/) Students: How to Apply for a Haiku Idea (https://www.haiku-os.org/community/gsoc/2018/students) Project Ideas (https://www.haiku-os.org/community/gsoc/2018/ideas) > If you have questions you can contact the devs on IRC: irc.freenode.org #haiku FreeBSD Jails with iocage (http://norrist.devio.us/iocage_freebsd.html) Introduction FreeBSD jails allow users to run multiple, isolated instances of FreeBSD on a single server. Iocage simplifies the management of FreeBSD Jails. Following this tutorial, the jails will be configured to bind to an IP address on the jail host's internal network, and the host OS will pass traffic from the external network to the jail. The jails will be managed with Iocage. Iocage uses ZFS properties to store configuration data for each jail, so a ZFS file system is required. Network setup These steps will: Set up the internal network. Enable the pf packet filter Configure pf pass internet traffic to and from the jail. PF is full featured firewall, and can do more than just pass traffic to an internal network. Refer to the PF documentation for additional configuration options. Run the following to configure the internal network and enable pf. sysrc cloned_interfaces+="lo1" sysrc ifconfig_lo1="inet 192.0.2.1/24" sysrc pf_enable="YES" Put the following in /etc/pf.conf ``` Variables ext_if should be set to the hosts external NIC extif = "vtnet0" jailif = "lo1" jailnet = $jailif:network NAT allows the jails to access the external network nat on $extif from $jailnet to any -> ($ext_if) Redirect traffic on port 80 to the web server jail Add similar rules for additional jails rdr pass on $ext_if inet proto tcp to port 80 -> 192.0.2.10 ``` Reboot to activate the network changes ZFS The best way to use ZFS on a VPS is to attach block storage as a new disk. If block storage is not available, you can optionally use a file as the ZFS device. Enable and start ZFS. sysrc zfs_enable="YES" service zfs start ZFS using Block storage List the available disks. If you are using a VPS, the block store will probably be the second disk. geom disk list Create a ZFS pool named jailstore. zpool create jailstore /dev/vtbd1 ZFS using a file Create the ZFS file. dd if=/dev/zero of=/zfsfile bs=1M count=4096 Create a ZFS pool named jailstore. zpool create jailstore /zfsfile Install iocage the easy way pkg install py36-iocage Skip to "Using iocage" Install iocage the hard way Swap file Smaller servers may not have enough RAM to build iocage. If needed, create a swap file and reboot. dd if=/dev/zero of=/swapfile bs=1M count=1024 echo 'swapfile="/swapfile"' >> /etc/rc.conf reboot Install some build dependencies pkg install subversion python36 git-lite libgit2 py36-pip Building iocage requires the FreeBSD source. svn checkout https://svn.freebsd.org/base/releng/11.1 /usr/src Get the latest FreeBSD ports tree. ``` portsnap fetch portsnap extract ``` + build iocage. cd /usr/ports/sysutils/iocage/ make install Using iocage ``` iocage activate jailstore iocage fetch iocage create -n www ip4_addr="lo1|192.0.2.10/24" -r 11.1-RELEASE iocage start www iocage console www ``` Once you have a shell inside the jail, install and start Apache. pkg install apache24 sysrc apache24_enable="yes" service apache24 start Port 80 on the jail will now be accessible on the hosts IP address. Multiple jails. Additional jails can be installed using the example above. Install the new jail with the iocage create command , but use a different IP address Expose the new jail to the network by adding additional rules to pf.conf. iXsystems SNIA Persistent Memory Summit 2018 Report (https://www.ixsystems.com/blog/snia-report-2018/) New FreeBSD Code of Conduct (https://www.freebsd.org/internal/code-of-conduct.html) The FreeBSD Project is inclusive. We want the FreeBSD Project to be a venue where people of all backgrounds can work together to make the best operating system, built by a strong community. These values extend beyond just development to all aspects of the Project. All those given recognition as members of the Project in whatever form are seen as ambassadors of the Project. Diversity is a huge strength and is critical to the long term success of the Project. To that end we have a few ground rules that we ask people to adhere to. This code applies equally to everyone representing the FreeBSD Project in any way, from new members, to committers, to the core team itself. These rules are intended to ensure a safe, harassment-free environment for all and to ensure that everyone feels welcome both working within, and interacting with, the Project. This document is not an exhaustive list of things that you should not do. Rather, consider it a guide to make it easier to enrich all of us and the technical communities in which we participate. This code of conduct applies to all spaces used by the FreeBSD Project, including our mailing lists, IRC channels, and social media, both online and off. Anyone who is found to violate this code of conduct may be sanctioned or expelled from FreeBSD Project controlled spaces at the discretion of the FreeBSD Code of Conduct Committee. Some FreeBSD Project spaces may have additional rules in place, which will be made clearly available to participants. Participants are responsible for knowing and abiding by these rules. Harassment includes but is not limited to: + Comments that reinforce systemic oppression related to gender, gender identity and expression, sexual orientation, disability, mental illness, neurodiversity, physical appearance, body size, age, race, or religion. + Unwelcome comments regarding a person's lifestyle choices and practices, including those related to food, health, parenting, drugs, and employment. + Deliberate misgendering. + Deliberate use of "dead" or rejected names. + Gratuitous or off-topic sexual images or behaviour in spaces where they're not appropriate. + Physical contact and simulated physical contact (e.g., textual descriptions like "hug" or "backrub") without consent or after a request to stop. + Threats of violence. + Incitement of violence towards any individual, including encouraging a person to commit suicide or to engage in self-harm. + Deliberate intimidation. + Stalking or following. + Harassing photography or recording, including logging online activity for harassment purposes. + Sustained disruption of discussion. + Unwelcome sexual attention. + Pattern of inappropriate social contact, such as requesting/assuming inappropriate levels of intimacy with others. + Continued one-on-one communication after requests to cease. + Deliberate "outing" of any private aspect of a person's identity without their consent except as necessary to protect vulnerable people from intentional abuse. + Publication of non-harassing private communication without consent. + Publication of non-harassing private communication with consent but in a way that intentionally misrepresents the communication (e.g., removes context that changes the meaning). + Knowingly making harmful false claims about a person. Interview - Benno Rice - benno@freebsd.org (mailto:benno@freebsd.org) / @jeamland (https://twitter.com/jeamland) News Roundup libhijack in PoC||GTFO 0x17! (https://www.soldierx.com/news/libhijack-PoCGTFO-0x17) Hijacking Your Free Beasties In the land of red devils known as Beasties exists a system devoid of meaningful exploit mitigations. As we explore this vast land of opportunity, we will meet our ELFish friends, [p]tracing their very moves in order to hijack them. Since unprivileged process debugging is enabled by default on FreeBSD, we can abuse PTrace to create anonymous memory mappings, inject code into them, and overwrite PLT/GOT entries. We will revive a tool called libhijack to make our nefarious activities of hijacking ELFs via PTrace relatively easy. Nothing presented here is technically new. However, this type of work has not been documented in this much detail, tying it all into one cohesive work. In Phrack 56, Silvio Cesare taught us ELF research enthusiasts how to hook the PLT/GOT. The Phrack 59 article on Runtime Process Infection briefly introduces the concept of injecting shared objects by injecting shellcode via PTrace that calls dlopen(). No other piece of research, however, has discovered the joys of forcing the application to create anonymous memory mappings in which to inject Code. This is only part one of a series of planned articles that will follow libhijack's development. The end goal is to be able to anonymously inject shared objects. The libhijack project is maintained by the SoldierX community. Previous Research All prior work injects code into the stack, the heap, or existing executable code. All three methods create issues on today's systems. On amd64 and arm64, the two architectures libhijack cares about, the stack is non-executable by default. jemalloc, the heap implementation on FreeBSD, creates non-executable mappings. Obviously overwriting existing executable code destroys a part of the executable image. The Role of ELF > FreeBSD provides a nifty API for inspecting the entire virtual memory space of an application. The results returned from the API tells us the protection flags (readable, writable, executable) of each mapping. If FreeBSD provides such a rich API, why would we need to parse the ELF headers? PLT/GOT hijacking requires parsing ELF headers. One would not be able to find the PLT/GOT without iterating through the Process Headers to find the Dynamic Headers, eventually ending up with the DT_PLTGOT entry. With FreeBSD's libprocstat API, we don't have a need for parsing ELF headers until we get to the PLT/GOT stage, but doing so early makes it easier for the attacker using libhijack The Future of libhijack Writing devious code in assembly is cumbersome. Assembly doesn't scale well to multiple architectures. Instead, we would like to write our devious code in C, compiling to a shared object that gets injected anonymously. This requires writing a remote RTLD within libhijack and is in progress. Writing a remote RTLD will take a while as doing so is not an easy task. Additionally, creation of a general-purpose helper library that gets injected would be helpful. It could aid in PLT/GOT redirection attacks, possibly storing the addresses of functions we've previously hijacked. This work is dependent on the remote RTLD. libhijack currently lacks documentation. Once the ABI and API stabilize, formal documentation will be written. Conclusion Using libhijack, we can easily create anonymous memory mappings, inject into them arbitrary code, and hijack the PLT/GOT on FreeBSD. On HardenedBSD, a hardened derivative of FreeBSD, libhijack is fully mitigated through PaX NOEXEC. We've demonstrated that wrapper-style Capsicum is ineffective on FreeBSD. Through the use of libhijack, we emulate a control flow hijack in which the application is forced to call sandbox_open and fdlopen on the resulting file descriptor. Further work to support anonymous injection of full shared objects, along with their dependencies, will be supported in the future. Imagine injecting libpcap into Apache to sniff traffic whenever "GET /pcap" is sent. In order to prevent abuse of PTrace, FreeBSD should set the security.bsd.unprivilegedprocdebug to 0 by default. In order to prevent process manipulation, FreeBSD should implement PaX NOEXEC. libhijack can be found at https://github.com/SoldierX/libhijack Introduction to POSIX shell (https://sircmpwn.github.io/2018/02/05/Introduction-to-POSIX-shell.html) What the heck is the POSIX shell anyway? Well, the POSIX (the Portable Operating System Interface) shell is the standard Unix shell - standard meaning it was formally defined and shipped in a published standard. This makes shell scripts written for it portable, something no other shell can lay claim to. The POSIX shell is basically a formalized version of the venerable Bourne shell, and on your system it lives at /bin/sh, unless you're one of the unlucky masses for whom this is a symlink to bash. Why use POSIX shell? The “Bourne Again shell”, aka bash, is not standardized. Its grammar, features, and behavior aren't formally written up anywhere, and only one implementation of bash exists. Without a standard, bash is defined by its implementation. POSIX shell, on the other hand, has many competing implementations on many different operating systems - all of which are compatible with each other because they conform to the standard. Any shell that utilizes features specific to Bash are not portable, which means you cannot take them with you to any other system. Many Linux-based systems do not use Bash or GNU coreutils. Outside of Linux, pretty much everyone but Hurd does not ship GNU tools, including bash1. On any of these systems, scripts using “bashisms” will not work. This is bad if your users wish to utilize your software anywhere other than GNU/Linux. If your build tooling utilizes bashisms, your software will not build on anything but GNU/Linux. If you ship runtime scripts that use bashisms, your software will not run on anything but GNU/Linux. The case for sticking to POSIX shell in shipping software is compelling, but I argue that you should stick to POSIX shell for your personal scripts, too. You might not care now, but when you feel like flirting with other Unicies you'll thank me when all of your scripts work. One place where POSIX shell does not shine is for interactive use - a place where I think bash sucks, too. Any shell you want to use for your day-to-day command line work is okay in my book. I use fish. Use whatever you like interactively, but stick to POSIX sh for your scripts. How do I use POSIX shell? At the top of your scripts, put #!/bin/sh. You don't have to worry about using env here like you might have been trained to do with bash: /bin/sh is the standardized location for the POSIX shell, and any standards-conforming system will either put it there or make your script work anyway. The next step is to avoid bashisms. There are many, but here are a few that might trip you up: [[ condition ]] does not work; use [ condition ] Arrays do not work; use IFS Local variables do not work; use a subshell The easiest way to learn about POSIX shell is to read the standard - it's not too dry and shorter than you think. Using standard coreutils The last step to writing portable scripts is to use portable tools. Your system may have GNU coreutils installed, which provides tools like grep and cut. Unfortunately, GNU has extended these tools with its own non-portable flags and tools. It's important that you avoid these. One dead giveaway of a non-portable flag is long flags, e.g. grep --file=FILE as opposed to grep -f. The POSIX standard only defines the getopt function - not the proprietary GNU getopt_long function that's used to interpret long options. As a result, no long flags are standardized. You might worry that this will make your scripts difficult to understand, but I think that on the whole it will not. Shell scripts are already pretty alien and require some knowledge to understand. Is knowledge of what the magic word grep means much different from knowledge of what grep -E means? I also like that short flags allow you to make more concise command lines. Which is better: ps --all --format=user --without-tty, or ps -aux? If you are inclined to think the former, do you also prefer function(a, b, c) { return a + b + c; } over (a, b, c) => a + b + c? Conciseness matters, and POSIX shell supports comments if necessary! Some tips for using short flags: They can be collapsed: cmd -a -b -c is equivalent to cmd -abc If they take additional arguments, either a space or no separation is acceptable: cmd -f"hello world" or cmd -f "hello world" A good reference for learning about standardized commands is, once again, the standard. From this page, search for the command you want, or navigate through “Shell & Utilities” -> “Utilities” for a list. If you have man-pages installed, you will also find POSIX man pages installed on your system with the p postfix, such as man 1p grep. Note: at the time of writing, the POSIX man pages do not use dashes if your locale is UTF-8, which makes searching for flags with / difficult. Use env LC_ALL=POSIX man 1p grep if you need to search for flags, and I'll speak to the maintainer of man-pages about this. FreeBSD Broadcom Wi-Fi Improvements (http://landonf.org/code/freebsd/Broadcom_WiFi_Improvements.20180122.html) Introduction Since 2015, I've been working on improving FreeBSD support for Broadcom Wi-Fi devices and SoCs, including authoring the bhnd(4) driver family, which provides a unified bus and driver programming interface for these devices. First committed in early 2016, bhnd(4) allowed us to quickly bring up FreeBSD/MIPS on Broadcom SoCs, but it has taken much longer to implement the full set of features required to support modern Broadcom SoftMAC Wi-Fi hardware. Thanks to the generosity of the FreeBSD Foundation, I've recently finished implementing the necessary improvements to the bhnd(4) driver family. With these changes in place, I was finally able to port the existing bwn(4) Broadcom SoftMAC Wi-Fi driver to the bhnd(4) bus, and implement initial support for the BCM43224 and BCM43225 chipsets, with additional hardware support to be forthcoming. Now that my efforts on FreeBSD/Broadcom Wi-Fi support have progressed far enough to be generally useful, I wanted to take some time to provide a brief overview of Broadcom's Wi-Fi hardware, and explain how my work provides a foundation for further FreeBSD Broadcom Wi-Fi/SoC improvements. A Brief Background on Broadcom Wi-Fi Hardware Broadcom's Wi-Fi devices are members of the Broadcom Home Networking Division (BHND) device family; other BHND devices include MIPS/ARM SoCs (including Wi-Fi SoCs commonly found in consumer access points), as well as a large variety of related networking hardware. BHND devices utilize a common set of Broadcom IP cores (or "functional blocks") connected via one of two on-chip bus architectures: Hardware designed prior to 2009 used Broadcom's “SSB” backplane architecture, based on Sonics Silicon's interconnect IP. Subsequent hardware adopted Broadcom's “BCMA” backplane, based on ARM's AMBA IP. The IP cores used in earlier SSB-based devices were adapted for compatibility with the new backplane. When BHND hardware is used in a PCI Wi-Fi card, or a SDIO Wi-Fi module, the device's dual-mode peripheral controller is configured to operate as an endpoint device on the host's peripheral bus, bridging access to the SoC hardware: Host access to SoC address space is provided via a set of register windows (e.g., a set of configurable windows into SoC address space mapped via PCI BARs) DMA is supported by the bridge core's sparse mapping of host address space into the backplane address space. These address regions may be used as a target for the on-chip DMA engines. Any backplane interrupt vectors routed to the bridge core may be mapped by the bridge to host interrupts (e.g., PCI INTx/MSI/MSI-X). The host is generally expected to provide drivers for the IP cores found on the SoC backplane; since these cores are found in both BHND SoCs and BHND Wi-Fi devices, it is advantageous to share driver and platform code between the two targets. Modernizing FreeBSD's Broadcom SoftMAC Wi-Fi Support FreeBSD support for Broadcom SoftMAC Wi-Fi adapters is provided by two partially overlapping PCI/CardBus drivers: Legacy Wi-Fi adapters are supported by bwi(4). This driver remains in-tree to support devices incompatible with v4 or later firmware (e.g. BCM4301, BCM4302, BCM4306 rev 1-2), all of which were released prior to December 2002. Modern Wi-Fi adapters are supported by bwn(4), with access to on-chip cores mediated by bhnd(4). Prior to my work porting bwn(4) to bhnd(4), access to on-chip cores was mediated by sibabwn, a PCI/WiFi-specific derivative of the legacy siba(4) SSB bus driver. There were two major limitations to sibabwn that have long blocked adding support for newer SoftMAC Wi-Fi chipsets: the newer BCMA interconnect found in post-2009 hardware was not supported by siba(4), and siba_bwn assumed a PCI/PCIe bridge, preventing its use on FreeBSD/MIPS Broadcom SoCs with interconnect-attached D11 cores. The new bhnd(4) driver family, written as a replacement for siba(4) and siba_bwn, provides: A unified bus driver interface for both SSB and BCMA on-chip interconnects A generic BHND bridge driver framework for host-connected BHND devices (e.g. Wi-Fi adapters, etc) A PCI/PCIe bridge core driver, for PCI-attached BHND devices. An abstract BHND NVRAM API, with support for the varied NVRAM formats found in BHND Wi-Fi adapters and SoCs. Drivers for common BHND platform peripherals (UARTs, SPROM/flash, PMUs, etc) By porting bwn(4) to bhnd(4), we are now able to support existing BCMA devices with MAC/PHY/Radio combinations readily supported by bwn(4), as was the case with the BCM43224 and BCM43225 chipsets. This also opens the door to porting additional PHY support from Broadcom's ISC-licensed Linux drivers, and will allow us to bring up bwn(4) on Broadcom WiSoCs supported by FreeBSD/MIPS. Monitor OpenSMTPD using Logstash and Grafana (https://www.tumfatig.net/20180129/monitor-opensmtpd-using-logstash-grafana/) Logs are usefull. Graphs are sexy. Here's a way to get a view on what happens to your OpenSMTPD traffic, using Web v2.0 tools ; namely Logstash & Grafana. For those who would not be aware of those tools, logstash is some kind of log-parser that can eat syslog formatted logs and write them into elasticsearch ; in “document” format. Grafana is a Web frontend that can dig into various databases and render graphics from requests. I won't go into the whole “how to install” process here. Installation is quite straight forward and online documentation is quite clear. What you need OpenSMTPD deals with emails and logs its activity via Syslog. Syslog is configured to send the logs to Logstash. Logstash has a set of rules configured to transform the text-oriented information into searchable document-oriented data. The transformed data is stored into Elasticsearch. Elasticsearch provides Web API to search and find stuff. Grafana connects to ELS to get data and draw the graphs. Beastie Bits CharmBUG Presentation - Writing FreeBSD Malware (https://www.meetup.com/CharmBUG/events/247995596/) March London *BSD meeting 13/03/18 (http://mailman.uk.freebsd.org/pipermail/ukfreebsd/2018-February/014180.html) FreBSD Ports Workshop (https://wiki.freebsd.org/MateuszPiotrowski/Ports/Workshop) The history of NetBSD/atari and support for ATARI compatible Milan / OSC2018Osaka (https://speakerdeck.com/tsutsui/osc2018osaka) SSH Mastery, 2nd Edition (https://www.tiltedwindmillpress.com/?product=ssh-mastery-2nd-edition) *** Feedback/Questions Stephen - Viewer Interview Question (http://dpaste.com/06WTRB9#wrap) pb - trust expanding your 280TB pool (http://dpaste.com/0TZV6CM#wrap) Tim - ZFS questions for the ZFS Man (http://dpaste.com/0759X1E#wrap) Daniel - ZFS full backup question (http://dpaste.com/1SJXSBQ#wrap) ***

Databar OSCAR   This is a story about the rise and fall of a compter peripheral and the company behind it. The company was Databar, and the product was called OSCAR, which was short for Optical SCAnning Reader.   In 1983, it wasn't easy to get inexpensive software for your home computer. Floppy disks were expensive. Modems were slow and expensive. You could get software in magazines — a variety of computer magazines offered computer program listings that you could type in. You might spend hours laboriously typing in a program, and it might work. Or more likely,  it wouldn't, because of a typo or because of errors in the published listing. It wasn't easy to get inexpensive software for your computer.   One solution that a couple of companies came up with was to distribute software in books and magazines — but instead of printed listings that you'd have to type in, the programs were distributed as bar codes — long collections of black and white dots. You could use a bar code scanner to read the programs into your computer.    The best known solution was, perhaps, Cauzin Softstrip. And although Softstrip may have been the best known, it was by no means a success. I've already published interviews with the people who created Softstrip.    Another contender in this niche — and the one that this episode is about - was the Databar OSCAR. OSCAR was released two years before Softstrip. OSCAR had two parts — the hardware, the Optical SCAnning Reader that would connect to your Atari 8-bit computer, or your Texas Instruments 99/4A, or your Commodore 64. And, the bar code software, which was to be published in a special magazine, called Databar.   First, let's talk a little about the hardware. A silver plastic device, a little smaller than a loaf of bread, was the brains of the operation. A hand-held removable wand, connected via a telephone-style coiled wire, held the optical reader. That's the part that you would roll over the bar code to read the software into your computer. Finally, there was an interface cable that connected the main device to your computer. This is the only bit of hardware that's different in the Atari, Commodore, and Texas Instruments versions of the product. The Commodore version, for instance, connects to the C64's cassette port. The Atari version also emulates a cassete tape drive, and connects to the Atari's SIO port.   The hardware alone cost $79.95, but it wouldn't do much good without the bar-code printed software, which was the Databar magazine. A 1-year subscription to the Databar magazine would cost an additional $120.   So let's talk about the software: the magazine. "Databar - The Monthly Bar Code Software Magazine" which was published in 1983, and turned out to only have one issue published, so it wasn't very monthly after all.   Databar ran some advertisements in the Atari, Commodore, and Texas Instruments computer magazines. I'm going to read a bit from one of them. [ad excerpt]   The magazine was published in three versions: one for the Atari 8-bit computer, one for the TI 99/4A, and a version for Commodore 64. The cover and front part of the magazine was the same in all editions, with general-interest articles like "Computer Gaming," "To Your Health - Your Health Is Up To You," and "Climbing the Slippery Financial Hills." The second part of the magzaine was different in each edition. This was the part with the bar codes. Each version has pretty much the same set of programs, but customized to the dialect of BASIC used on that particular computer. The selection of non-confrontational, milquetoast programs includes OSCAR's Match (a memory game), Financial Quiz, Math Challenge, Health Assessment, The Law and You, and Miles Per Gallon Calculator.   Only 9 programs were ever published in this format for the Commodore and TI, and they are all in the magazine. 13 Atari programs were ever published in this format, in the Atari version of the magazine.    The OSCAR box claims that the hardware is also compatible with the Timex Sinclair 1000, 1500, 2000, and the TRS-80 Color Computer. But I haven't seen any evidence that versions of the magazine were created for those systems, nor the hardware adapters to connect to them.   One of the benefits of the reader was that it was supposed to be faster than typing. My favorite ad for the OSCAR reader says "Programming the Home Computer — Expert Typist with Keyboard vs. Eight-year-old with OSCAR." The task: entering a two-page BASIC program. The expert typist with a 100 word-per-minute speed and a degree in computer programming can do it in 1 hour and 9 minutes. The little girl with bows in her hair and bubble gum in her mouth, with no prior computer experience, can enter the program using OSCAR in 8 minutes.   Now that we've set the stage, it's time for the interviews. There are three: first, Don Picard, the Executive Editor of Databar magazine; then Kim Garretson, the publisher of the magazine; and finally Neal Enzenauer, the principal engineer for OSCAR.   ## interview 1: Don Picard Don Picard worked for Webb Publishing, a large printing company that owned a number of magazines. Don worked in a division called  Creative Communications, that was a custom publishing house for corporate clients. The division did work such as in-flight magazines for airlines, and custom magazines for Farmer's Insurance and the American Automobile Association. He was the Executive Editor of Databar magazine.   Teaser quotes: "Concept was basically dead before it got born." "When money's invested there becomes a sort of momentum involved. Nobody wants to say, 'This was a mistake.'"   ## interview 2: Kim Garretson The next interview is Kim Garretson, the founding editor and publisher of Databar magazine.   Teaser quote: "Sometimes you had to go across a single line of code three or four or five or seven times to hear the little beep."   ## interview 3: Neal Enzenauer Our final interview is with Neal Enzenauer, the principal engineer for OSCAR.   Teaser quote: "We thought we were going to set the world on fire and make magnetic media obsolete — but I guess we didn't."   ## closing Thanks to Don Picard, Kim Garretson, and Neal Enzenauer. Thanks to Allan Bushman for scanning the Atari version of the Databar magazine and OSCAR instructions; @doegox on Twitter for writing the python script to decode the barcodes without the scanner, @paulrickards for wrangling the Commodore software, and @travisgoodspeed for the PoC||GTFO 'zine, which was instrumental in bringing the pieces together. Thanks to the Internet Archive for hosting scans of the magazines and all the software.    The interview with Don Picard took place on April 5, 2016. The interview with Kim Garretson took place on June 27, 2016. (A video version of that interview is available, including an extended version where we also discuss CD-ROM publishing and the Prodigy online service.) The interview with Neal Enzenauer took place on April 12, 2016.   ANTIC interview with creators of Cauzin Softstrip, another software bar code system   PoC||GTFO   Databar Magazine - Atari edition   Databar Magazine - Commodore edition   Databar Magazine - TI 994/A edition   Decoded Software from Databar Magazine - Atari edition   Decoded Software from Databar Magazine - Commodore edition   Decoded Software from Databar Magazine - TI 994/A edition   An Introduction To Oscar And Bar Code Scanning - Atari Version   Databar OSCAR Box scans   Databar OSCAR unboxing video   Databar OSCAR Software Binder   Kim Garretson interview, extended video version   More background on the format   Decoding software in python   Databar Bar Code Reader patent   Expert Typist with Keyboard vs. Eight-year-old with OSCAR   Databar ad in Antic magazine   Another ad in Antic   Databar mention in JACG Atari newsletter   Databar article in Enthusiast '99 magazine   PC Magazine article about OSCAR

Chris (@cmaddalena), Kyle (@chaoticflaws), and Daniel (@notdanielebbutt) join me at DEFCON to discuss various topics ranging from conferences like DEFCON, Blackhat, and BSides Las Vegas to bird feeders. We read a couple passages from the POC||GTFO bible available from no start press.

Episode #116 consacré à POC||GTFO avec Ange Albertini Pour vous inscrire au workshop Inkscape d’Ange, c’est ici : https://www.eventbrite.com/e/ange-albertini-binary-poster-workshop-tickets-29729953090         The post PoC or GTFO appeared first on NoLimitSecu.

Materials Available here: https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Ryan-O%27Neil-Advances-in-Linux-Forensics-ECFS.pdf Advances in Linux Process Forensics Using ECFS Ryan O'Neill Security Consultant, Leviathan Security Group Many hackers today are using process memory infections to maintain stealth residence inside of a compromised system. The current state of forensics tools in Linux, lack the sophistication used by the infection methods found in real world hacks. ECFS (Extended core file snapshot) technology, https://github.com/elfmaster/ecfs is an innovative extension to regular ELF core files, designed to be used as forensics-friendly snapshots of process memory. A brief showcasing of the ECFS technology was featured in POC||GTFO 0x7 (Innovations with core files). However this talk will reveal deeper insight on the many features of this technology, such as full symbol table reconstruction, builtin detection heuristics, and how common binutils such as objdump, and readelf can be used to quickly identify complex infections such as PLT/GOT hooks and shared library injection. We will also cover the libecfs API that was created specifically for malware and forensics analysts who aim to implement support for ECFS snapshots into new or existing malware detection software. While the ECFS core format was initially designed for runtime malware and forensics purposes, another very neat aspect to this technology was quickly extrapolated on; the ECFS snapshots can also be reloaded into memory and executed. Very similar to VM snapshots, which opens many more doors for research and exploration in a vast array of areas from dynamic analysis to migrating live processes across systems. ECFS is still a work in progress, but for those who understand the arduous nature of dissecting a process and identifying anomalies, will surely acquire a quick respect for the new technology that makes all of this so much easier. Ryan 'elfmaster' O'Neill is a computer security researcher at Leviathan Security and the maintainer of Bitlackeys.org, a hub for much of his independent research. He is a Reverse engineer, and a Software engineer, who also specializes in the ELF binary format, and delivers on going workshops in this area to interested parties, including the US government. Ryan has worked on many security technologies including but not limited to: Maya's Veil : anti-tamper / anti-exploitation protection for Linux ELF binaries VMA Vudu : automated forensics analysis of process runtime infections in Linux kernelDetective : Linux kernel forensics software Ryan has produced alot of research and publications in areas pertaining to Linux kernel and userland malware, such as "Linux kprobe instrumentation from phrack 66", and is author of soon to be released book "The art of Linux binary analysis" which focuses on everything from ELF internals to Linux Viruses, and Binary protection techniques. Ryan has been involved in the computer security scene since 1999.