Such a weird Processor: messing with opcodes (...and a little bit of PE) (Has...Ange Albertini
After being trapped by a malware, I went back to the basics, studied ASM and PE from scratch, and failed all tools I tried in the process.
This presentation introduces the complete details that are shared on Corkami.com, and highlights some of the most interesting cases.
A quick tutorial on what debuggers are and how to use them. We present a debugging example using GDB. At the end of this tutorial, you will be able to work your way through a crash and analyze the cause of the error responsible for the crash.
[Ruxcon Monthly Sydney 2011] Proprietary Protocols Reverse Engineering : Rese...Moabi.com
This presentation given in 2011 during the first Ruxcon Monthly (Ruxmon) Sydney focuses on proprietary protocols reverse engineering and vulnerability audits.
A User's Experience of Working with the AnalyzerAndrey Karpov
This text is a copy of a post by one PVS-Studio user, originally published in Russian here. It was kind of Alexander to permit us to publish it at our website and translate it into English.
When the PVS-Studio team announced that they had finally released a standalone version which didn't require you to have Visual Studio installed to be able to work with it, I certainly couldn't but try it :) Before that I already had experimented with the trial version on one of our old projects. And now I got a chance to check the code of our recent project built in the AVR Studio IDE (it's eclipse-based).
To be able to work with the analyzer, you need special files generated by the preprocessor. The AVR environment can do that, but there's one subtle nuance: when you turn on the flag "Preprocessor only" you really get the preprocessed files - but they still have the .o extension instead of the .i you expected. Well, it took me 5 minutes to write a Python script to solve this small problem, and here we go - the analyzer runs well!
Such a weird Processor: messing with opcodes (...and a little bit of PE) (Has...Ange Albertini
After being trapped by a malware, I went back to the basics, studied ASM and PE from scratch, and failed all tools I tried in the process.
This presentation introduces the complete details that are shared on Corkami.com, and highlights some of the most interesting cases.
A quick tutorial on what debuggers are and how to use them. We present a debugging example using GDB. At the end of this tutorial, you will be able to work your way through a crash and analyze the cause of the error responsible for the crash.
[Ruxcon Monthly Sydney 2011] Proprietary Protocols Reverse Engineering : Rese...Moabi.com
This presentation given in 2011 during the first Ruxcon Monthly (Ruxmon) Sydney focuses on proprietary protocols reverse engineering and vulnerability audits.
A User's Experience of Working with the AnalyzerAndrey Karpov
This text is a copy of a post by one PVS-Studio user, originally published in Russian here. It was kind of Alexander to permit us to publish it at our website and translate it into English.
When the PVS-Studio team announced that they had finally released a standalone version which didn't require you to have Visual Studio installed to be able to work with it, I certainly couldn't but try it :) Before that I already had experimented with the trial version on one of our old projects. And now I got a chance to check the code of our recent project built in the AVR Studio IDE (it's eclipse-based).
To be able to work with the analyzer, you need special files generated by the preprocessor. The AVR environment can do that, but there's one subtle nuance: when you turn on the flag "Preprocessor only" you really get the preprocessed files - but they still have the .o extension instead of the .i you expected. Well, it took me 5 minutes to write a Python script to solve this small problem, and here we go - the analyzer runs well!
hashdays 2011: Ange Albertini - Such a weird processor - messing with x86 opc...Area41
Whether it's for malware analysis, vulnerability research or emulation, having a correct disassembly of a binary is the essential thing you need when you analyze code. Unfortunately, many people are not aware that there are a lot of opcodes that are rarely used in normal files, but valid for execution, but also several common opcodes have rarely seen behaviours, which could lead to wrong conclusions after an improper analysis.
For this research, I decided to go back to the basics and study assembly from scratch, covering all opcodes, whether they're obsolete or brand new, common or undocumented. This helped me to find bugs in all the disassemblers I tried, including the most famous ones. This presentation introduces the funniest aspects of the x86 CPUs, that I discovered in the process, including unexpected or rarely known opcodes and undocumented behavior of common opcodes.
The talk will also cover opcodes that are used in armored code (malware/commercial protectors) that are likely to break tools (disassemblers, analyzers, emulators, tracers,...), and introduce some useful tools and documents that were created in the process of the research.
Bio: Ange Albertini is a reverse-engineering and assembly language enthusiast for around 20 years, and malware analyst for 6 years. He has a technical blog, where he shares experimental sources files, and some infographics that are useful in his daily work.
An introduction to exploit development.
I gave this talk at Hack the North 2014, and most of this information is pulled out of classics like Smashing the Stack for Fun and Profit, so there shouldn't be anything novel in here.
One of the most important benefits of automated testing is to ensure a fast and safe code refactoring to evolve our system architecture. The main problem is how to write tests that are easy to write, easy to follow and not time consuming during development nor execution time. In this session, we are going to explore some powerful Java testing libraries that will help you write better (unit) tests focusing on the main Unicorns architecture challenges such as validating microservices endpoints, remote calls to other microservices or just asynchronous/reactive code.
Thumb.co.il is the best web-based video format inspector tool ever created. This is an overview of the reasons for creating thumbcoil and a peek into some of the cool technology contained therein.
FreeBSD on Cavium ThunderX System on a ChipSemihalf
The lecture given during BSDCan 2016 by Wojtek Macek that describes the FreeBSD operating system port for the Cavium ThunderX CN88XX System on a Chip. ThunderX is a newly introduced, ARM64 (ARMv8) SoC designed for the high performance and server markets. It is currently the only one in the ARM world to incorporate up to 96 CPU cores in the system along with the whole technology to make it possible.
hashdays 2011: Ange Albertini - Such a weird processor - messing with x86 opc...Area41
Whether it's for malware analysis, vulnerability research or emulation, having a correct disassembly of a binary is the essential thing you need when you analyze code. Unfortunately, many people are not aware that there are a lot of opcodes that are rarely used in normal files, but valid for execution, but also several common opcodes have rarely seen behaviours, which could lead to wrong conclusions after an improper analysis.
For this research, I decided to go back to the basics and study assembly from scratch, covering all opcodes, whether they're obsolete or brand new, common or undocumented. This helped me to find bugs in all the disassemblers I tried, including the most famous ones. This presentation introduces the funniest aspects of the x86 CPUs, that I discovered in the process, including unexpected or rarely known opcodes and undocumented behavior of common opcodes.
The talk will also cover opcodes that are used in armored code (malware/commercial protectors) that are likely to break tools (disassemblers, analyzers, emulators, tracers,...), and introduce some useful tools and documents that were created in the process of the research.
Bio: Ange Albertini is a reverse-engineering and assembly language enthusiast for around 20 years, and malware analyst for 6 years. He has a technical blog, where he shares experimental sources files, and some infographics that are useful in his daily work.
An introduction to exploit development.
I gave this talk at Hack the North 2014, and most of this information is pulled out of classics like Smashing the Stack for Fun and Profit, so there shouldn't be anything novel in here.
One of the most important benefits of automated testing is to ensure a fast and safe code refactoring to evolve our system architecture. The main problem is how to write tests that are easy to write, easy to follow and not time consuming during development nor execution time. In this session, we are going to explore some powerful Java testing libraries that will help you write better (unit) tests focusing on the main Unicorns architecture challenges such as validating microservices endpoints, remote calls to other microservices or just asynchronous/reactive code.
Thumb.co.il is the best web-based video format inspector tool ever created. This is an overview of the reasons for creating thumbcoil and a peek into some of the cool technology contained therein.
FreeBSD on Cavium ThunderX System on a ChipSemihalf
The lecture given during BSDCan 2016 by Wojtek Macek that describes the FreeBSD operating system port for the Cavium ThunderX CN88XX System on a Chip. ThunderX is a newly introduced, ARM64 (ARMv8) SoC designed for the high performance and server markets. It is currently the only one in the ARM world to incorporate up to 96 CPU cores in the system along with the whole technology to make it possible.
Windows Kernel Exploitation : This Time Font hunt you down in 4 bytesPeter Hlavaty
In our recent work we targeted also win32k, what seems to be fruit giving target. @promised_lu made our own TTF-fuzzer which comes with bunch of results in form of gigabytes of crashes and various bugs. Fortunately windows make great work and in February most of our bugs was dead - patched, but not all of them…
Whats left were looking as seemingly unexploitable kernel bugs with ridiculous conditions. We decided to check it out, and finally combine it with our user mode bug & emet bypass. Through IE & flash we break down system and pointed out at weak points in defensive mechanism.
In this talk we will present our research dedicated for pwn2own event this year. We will describe kernel part of exploit in detail*, including bug description, resulting memory corruption conditions & caveats up to final pwn via one of our TTF bugs.
Throughout the talk we will describe how to break various exploit mitigations in windows kernel and why it is possible. We will introduce novel kernel exploitation techniques breaking all what stands { KASLR, SMEP, even imaginary SMAP or CFG } and bring you SYSTEM exec (from kernel driver to system calc).
* unfortunately bug was not fixed at the time of talk, so we do not exposed details about TTF vulnerability, and we skipped directly to some challenges during exploitation, and demonstrate how OS design can overpower introduced exploit mitigations.
A short training introducing binary reverse engineering in x86. Some application to malware is presented as well. The actual training is hands on and contains a software package for the participants.
The emulator was presented to the public at RubyConfBr 2013. Its source code can be downloaded at http://github.com/chesterbr/ruby2600
The video is on YouTube: http://www.youtube.com/watch?v=S3qAOu41CxE
An introduction to the motivation behind the ooc project.
In a nutshell: software sucks, tools sucks, languages sucks - examples of what not to do. How ooc allows you to do pretty much aything with a few building blocks. An overview of the advantages/strong points of ooc.
NDC TechTown 2023_ Return Oriented Programming an introduction.pdfPatricia Aas
Return Oriented Programming (ROP) is an exploitation technique that folks have often heard of, but don't know the mechanics of. In this talk you will learn how it works, and we will go through some examples to show how it can be used to execute code in contexts where the stack is not executable.
XCon 2014 => http://xcon.xfocus.org/
In the past was quite common to exploit heap / pool manager vulnerabilities attacking its internal linked structures. However current memory management improve a lot and at current date it is quite ineffective to attack heap in this way. But still those techniques come into hand when we start to looking at linked structures widespread throughout kernel that are unfortunately not hardened enough.
In this presentation we will examine power of these vulnerabilities by famous example “CVE – 2013 - 3660”. Showing bypass on ‘lazy’ assertions of _LIST_ENTRY, present exploitation after party and teleport to kernel.
CONFidence 2015: when something overflowing... - Peter HlavatyPROIDEA
Speaker: Peter Hlavaty
Language: English
This talk will cover how powerfull are buffer overflows, how weak are mitigations against them, why are buffer overflows still possible in those days, how generic are they, and example how useful is turn race conditions to buffer overflow. Race conditions are nice example for that, because they are one of the hardest to find and on of the easiest to make. example is on Linux kernel (droids included), but talk will be keeped for buffer overflows in general (mainly for windows & Linux kernel)
CONFidence: http://confidence.org.pl/pl/
This talk will cover how powerfull are buffer overflows, how weak are mitigations against them, why are buffer overflows still possible in those days, how generic are they, and example how useful is turn race conditions to buffer overflow. Race conditions are nice example for that, because they are one of the hardest to find and on of the easiest to make. example is on Linux kernel (droids included), but talk will be keeped for buffer overflows in general (mainly for windows & Linux kernel)
"Technical challenges"? More like horrors!
Let's explore first the technical debt of old file formats,
with the evolution of the "MP3" format.
Then we go through more recent forms of file format abuses and tools:
polyglots, polymocks, and crypto-polyglots.
Last, an overview of recent collisions and other forms of art with MD5.
They say that with file formats, "specs are enough".
Should we laugh, cry or run away screaming?
Presented at Digital Preservation Coalition's CyberSec & DigiPres event.
You are *not* an idiot ~ or maybe we're all idiots.
Keynote at NorthSec 2021.
Talking about school, failure, success, diploma, impostor syndrom, manipulators, burn out, suicide, and how to deal with them.
The talk delivery was more personal, the slides are kept generic.
The recording is available @ https://youtu.be/Iu70J49bPlE?t=20869 (starts at 5:47:49)
Demystifying hash collisions.
Pass the Salt, 1st July 2019.
video @ https://passthesalt.ubicast.tv/videos/kill-md5-demystifying-hash-collisions/
Hack.Lu, 22 October 2019.
video @ https://www.youtube.com/watch?v=JXazRQ0APpI
Beyond your studies ~ You studied X at Y. now what?
HackPra, July 2018
A student's life ago, the author somehow managed to graduate.
On the way, he made a lot of mistakes -- and he still does.
A few people since called him 'successful', but LOL, if only they knew....
And now, the author will do another (big!) mistake:
instead of hiding in shame as he probably should,
he'll share his mistakes with anyone bored enough to attend,
in the hope that he's the last person to ever look that dumb to commit such mistakes.
If you're a genius and you know what to do in life, please skip this. Seriously.
If, like the author at the time, you wonder WTF is going on with graduation, professional work and life, then hopefully you learn a few things. Maybe.
Btw the author is 42 (WTF - old!).
Maybe that will help to provide a few answers.
Presented at Troopers 2016.
When Infosec and Digipres share interests...
TL;DR
- Attack surface with file formats is too big.
- Specs are useless (just a nice ‘guide’), not representing reality.
- We can’t deprecate formats because we can’t preserve and we can’t define how they really work
- We need open good libraries to simplify landscape, and create a corpus to express the reality of file format, which gives us real “documentation”.
- Then we can preserve and deprecate older format, which reduces attack surface.
- From then on, we can focus on making the present more secure.
- We don't need new formats: reality will diverge from the specs anyway - we need 'alive' (up to date, traceable) specs.
AKA "How people can create better video games via hacks"
Presented at Hack.Lu's Cryptoparty4kids 2015
Fallback slides: this was actually presented with videos and sound
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
110. Ivanlef0u Adam Błaszczyk, BeatriX, Bruce Dang, Candid Wüest, Cathal Mullaney, Czerno, Daniel Reynaud, Elias Bachaalany, Ero Carrera, Eugeny Suslikov, Georg Wicherski, Gil Dabah, Guillaume Delugré, Gunther, Igor Skochinsky, Ilfak Guilfanov, Ivanlef0u, Jean-Baptiste Bédrune, Jim Leonard, Jon Larimer, Joshua J. Drake, Markus Hinderhofer, Mateusz Jurczyk, Matthieu Bonetti, Moritz Kroll, Oleh Yuschuk, Renaud Tabary, Rewolf, Sebastian Biallas, StalkR, Yoann Guillot,... Questions?
Welcome! I'm Ange Albertini, and I will talk about x86 and PE
this extra slide to let you decide if you really want to read further ;) I studied ASM and PE, from scratch I failed all tools I tried: IDA, OllyDbg, Hiew, pefile, WinDbg, HT, CFF Explorer... here are a few of my findings
This is an improved version of my presentation at Hashdays. I reworked it, but most of the content is still the same.
I created Corkami, a website about reverse engineering. it's technical, and free: open-source, relying on free tools, free for commercial use, no ads, no log-in. I focus on creating a LOT of small focused PoCs. they're handmade so really no extra stuff. each of them is probably meaningless, but altogether, they're a useful toolbox to test and learn. then I write a summary page. but I put more work in PoCs than in the pages. the important is: for each feature I study, there's a PoC available but it's only a hobby, so it's quite messy, and not as good as I'd like it to be.
so, whether it's a non PE exe with an inverted ZM signature, in 16bits asm. a complete 'correct' PDF with text (that's the full PDF btw), typed in notepad a working java class, with opcodes generated manually a tiny PE, with imports and code in the middle of the header you can see that all of them only have the necessary elements.
and here is the story behind this presentation
first, a small flashback
years ago, I was young and innocent, believing that CPU would be perfect, because they're made of transistor, not software. and I thought I knew assembly.
then I encountered my first undocumented opcodes. and shortly after, my first sectionless PE. I was shocked, but I thought I was still young...
So I decided to go back to the basics, studying x86 and PE from scratch.
and writing my findings on the way, on Corkami.
This talk is only a subset of what's available on the site, even on these topics.
but, if I was just a guy learning ASM and PE, I probably wouldn't be presenting here. So, here is why I'm here :) Most of these bugs were already reported and fixed.
so, first, I'll start slowly, trying to introduce assembly to beginners, and make them understand the problem of undocumented opcodes. then, it will get more technical: I'll cover a few assembly tricks, including some found in malware. then I'll introduce my opcode tester, CoST. and I'll also present my last project which deals with the PE format.
So, let's start and try to make everybody understand the problem of undocumented opcodes. so first, introduce opcodes themselves
so, we create a simple program in a language, such as C. Here, in Visual Studio, Microsoft standard development environment. this program shows a simple message box on screen, then terminates. an executable is generated, and indeed does what we expected.
what the Visual Studio compiler did from our C code is actually generate sequences of assembly code instruction that will generate the wanted actions.
so, the C code is turned into assembly. which is itself encoded in the binary as opcodes.
Here, you can see calls to MessageBox, then ExitProcess (the names are self-explaining), with the parameters above. these assembly operations are stored in opcodes directly in the binary, as visible on the left.
now you know that this is what is in the file itself. this is how it's read by 'us' (reverse engineers, malware analysts, exploit developers...). the CPU itself only reads the hex. as you can see, there is a relation: 68 - in hex - is used to push offsets calls starts with FF 15... and you can see the used addresses here (read them backward). so, you see the first byte determine the actual opcode. and depending on each opcode, the length is variable.
This is what is actually in the file on the hard disk (the 'hex'). If you'd accidentally open the file in, say notepad - it doesn't really make sense, but at least you have that on your machine - you could find it here (remember, it's hex). Note that it's actually a very tiny part of the whole file (<30bytes out of 56000).
What's important is that in the end, anything running on your machine is about the CPU executing opcode, no matter what. the compiled file is full of 'unneeded' stuff. while you can make a much smaller file with exactly the same functionality (that's the whole file), and even though they're very different, the same opcodes are present again.
so, the compiler translates our C to a series of assembly operations, which is itself encoded in opcodes. the resulting executable only contains the opcodes, which are directly understood and executed by the CPU. If no error happens, what is here directly affects the behavior of the program, there is no 'man in the middle' from the OS. so our C code will just eventually lead the CPU to read and execute 6A 40 68 F4 20 40 00 68 FC 20... if, by any chance, there is some opcodes that we are not aware of, or doesn't do what we expect, the CPU doesn't care, it just knows what to do.
so now, let's interfere with the compiling process
let's add a command that will force a specific byte in the opcodes. this result is not known to visual studio, which only shows ??
indeed, if we check Intel official documentation, there is nothing to see here...
so, we forced something that is not recognized by the most expensive Microsoft compiler to execute, which is not even in Intel's books. We should only expect a crash, right ?
but the CPU doesn't care about what YOU (or VS) know, and it just executes that mysterious D6 just fine (apparently) it doesn't look like a big problem, but if like Microsoft, you base your judgment on Intel's documentation, you just don't know what happens next. No automated analysis, proactive detection, etc... and you need to understand that undocumented opcode. You can't even skip it: you don't know if it will jump, do nothing, trigger an exception... and because of variable instruction length, you can't even tell what would be the next instruction, so you can't guess easily backward from the next instruction.
so what did we do in reality ? D6 will be decoded as SETALC, which is quite simple. It doesn't interfere with the execution of this example (it could have, of course). surprisingly, it's not documented by Intel, but it's documented by AMD. anyone knows why ? I'd be curious to know.
the funny thing is, even though Intel docs are full of holes, Intel free tools are fully aware of what to expect... Sadly, Microsoft WinDbg decided to follow the official docs, which makes it a very bad tool against malware, which commonly use undocumented tricks.
So, you now know that the CPU knows things that the Intel documentations omits. if we or our tools are not able to tell what the CPU will do, we're just blind.
the extra problem is that each of this oddities are usually scattered in various files, deep under obfuscations or in malicious behavior. no 'ready to use' toolbox. that's the hole I wanted to fill.
Now, let's start the real stuff
before focusing on particular opcodes, my first questions was: what are actually all the supported opcodes ? then, actually how many registers are there ? before anything happen, do they have any particular value ?
that's the problem. like English language, assembly uses mainly always the same 'standard' opcodes. which means, what everybody is used to hear or read: Here, 'standard language'. What all generations understand. most people would understand...
but Intel CPU are from the 70's and still backward compatible... here is an example of Shakespeare English and old x86 mnemonics unknown to most people. yet still fully working on a modern CPU.
so here is a small executable where I only use uncommon opcodes. some are not really doing anything, some are actually doing something meaningful. I expect that most of us are not even used to see these opcodes, yet they're fully supported by all CPUs.
Another funny fact is that some specific opcodes (interrupt) used to be for various functionality, which made IDA and Hiew over-interpret them. in IDA, you can disable the option which is by default.
new generation : English and opcodes. probably unknown to most people single opcodes for CRC, AES, string masking... MOVBE = rejected offspring netbook only. absent from i7 => so much for backward compatibility
I made a 'non working' PoC with all opcodes encoded, and various tricky situation. very useful to quickly test the abilities of a disassembler.
the basics of assembly are the registers... registers are overlapping. unlike many documentations, ST0 <> MM7 before any operation, registers have the value assigned to themselves by the OS. I collected these values under windows, specific values it's not CPU specific, but the initial values of the register on process start-up, under windows, gives a few hint that are used by malwares. eax can immediately tell if you're on an older OS or not. While GS can tell you if the machine is 64b or not, even in a 32b process.
I created a PoC that just gets all registers from EP and TLS, and checks the validity of result. easy check see if a malware/tool is interfering with the loading process.
smsw is an old 286-era mnemonic (before protected mode was 'complete'): it allows usermode access to cr0. the higher word of a reg32 target is 'undefined', yet always modified (and same as cr0) under XP, right after an FPU operation, the returned value is modified [bits 1 and 3, called MP (Monitor Coprocessor) and TS (Task switched)], but eventually reverted after some time. too tricky ? redirection fails. any idea why ?
demo of smsw: undocumented behavior fpu relation (xp) redirection weirdness
the GS trick is similar. on 32b of windows, GS is reset on thread switch. on 64b windows, it's already used by the OS (value non null at start) ie wait long enough, it's null, whatever the value before. if you just step manually, instantly lost. after some time, but not a too short time, it's reset
demo of all GS features
xchg eax, eax is 90, which originally did nothing. (xchg eax, ecx is 91) thus 90 became nop but 87 c0 is an xchg eax, eax that is not a nop and does something in 64b, as it resets the upper dword. hint nop gives hint of what to access next. it does nothing, but it's multi-byte. first, it's not completely documented by intel and, being a multi-byte opcode, if it overlaps an invalid page, it can trigger an exception!
Mov is documented, but has a few quirks. * to/from control and debug registers, memory operands are not allowed. but not rejected ! * in 64b, with no REX prefix, movsxd can actually work to and from a 32b register, which is against the logic of 'sign extending' * on the contrary, mov from a selector actually affects a complete 32b register. the upper word is theoretically undefined, but actually 0 (used by malware to see if upper part is actually reset or if wrongly emulated as 'mov ax, cs'.)
smsw (undocumented) gives full cr0 access. then cr0 access with 'ignored' Mod/RM then standard cr0 access... same results, in all 3 cases.
Bswap... is like an administration... rules prevent it to work correctly most of the time... it's supposed to swap the endianness of a register. but most of the time, it does something unexpected. with a 64b register, it swaps the quadword around. good. with a 32b, it resets the highest dword. 'as usual', of course... and on 16b, it's 'undefined' but it just clears the 16b register itself (the rest stays unchanged, of course)...
demo of nop / mov / bswap, in both 32b and 64b
anyone knows what will happen here ? push, ret. put an address on the stack, pop it and jump to it. no possible trick, right...
so, what happened ? olly even auto-comments the ret! the 66: before the RETN makes return to IP, not EIP. so here we returned to 1008, not 401008. the other problem is that while different, there is no official name for this ret to word, 'small ret', 'ret16'....
I won't enumerate them all. they're already on Corkami, with some other x86 stuff that might be useful to print. too much theory with no practice never gives good results...
so I created CoST.
an opcode tester, in a tricky PE. available in easy mode compile (less tricky), as CoST is quite difficult to debug :) just run, and it roughly displays what happened.
so, it contains a lot of various tests... (150 is the lower margin, depend how you count) some trivial... some less trivial.
Cost just gives some output when ran from the command line. but actually it gives much more output on debug output. even if the binary is hand-made, it's self documented, via one-line calls to VEH printing, and internal exports for different internal chapters.
here is my favorite part of CoST: anyone sees what this is doing ? executing code at push_eip... then the same code with selector 33 (64b code) so the same opcodes are executed twice, first in 32b mode, then in 64b.
and these opcodes gives exclusive mnemonics to each side... works fine under a 64b OS. same EIP, same opcodes, twice, and different code.
as you'd expect, WinDbg, following Intel docs too closely, will give you '??' Hiew does that too a little. but honestly, I found bugs in all disassemblers I looked at, no exception AFAIR. Even a crash in XED.
CoST was originally only an opcode tester. then I added a few PE tricks... have a look yourself, the top of the file, and the PE header (right at the bottom)
As you can see, IDA didn't really like it at first (fixed, now) So, if CoST helps you to find a few bugs in your program, I'm not really surprised.
but one single file, even full of tricks, is not enough to express all the possibilities of the PE file. so I created more.
I already made some useful graphs for PE files. and I started a wiki page, with more than 120 PoCs, focusing, as usual, on precise aspects of the PE. PE with no section, with 64k sections, with huge ImageBase, relocation encryption...
in low alignments, the section table is checked but not used at all. so, if it's full of zeroes, it will still work – under XP. thus, with SizeOfOptionalHeader, you can set it in virtual space... Hiew doesn't like that. check the picture, it doesn't even identify it as a PE.
what do you think ? when you can do ASCII art with the PE info, something dodgy is going on :) this is ReversingLabs' dual PE header. the PE header is partially overwritten (at exports directories) on loading. the upper part is read from disk, the lower part, read in memory, is overwritten by the section that is folded over the bottom of the header.
export names can be anything until 0, or even null. Hiew displays them inline, so, well, here is the PoC of weird export names one of the other names in this PoC is LOOOONG enough to trigger a buffer overflow >:)
this is a 64k section PE against the latest Olly. amazingly, it doesn't crash despite this funny message...
this one is not very visual, yet quite unique. TLS AoI points to an Import descriptor Name member... depending on AoI or imports happening first, this is a terminator or not... so the same PE gets loaded with more or less imports depending on the OS.
unlike what I used to believe, cpus and windows binaries are far from perfectly logical nor documented If you only follow the official doc, you're bound to fail. especially with the malware landscape out there.
so give Corkami PoCs a try – and send me a postcard if you found some bugs I seriously hope that MS will put WinDbg back to a more reactive release cycle, and will update it...
Eternal thanks to Peter Ferrie, my permanent reviewer. Ivanlef0u is also very helpful. a lot of people helped me in the process to make this presentation and the content on corkami, in one way or another. Any questions?
Thanks for your attention. I hope you liked it.
mips relocs are still working, even with x86 CPU and PE. and relocs apply on relocs data themselves... so does my PoC adding an extra relocation on the imagebase doesn't influence the loading (the PE is already mapped), but it interferes with the EP calculation. Drivers are just low alignment PEs with different import. so I made a PE with low alig and no imports, that detects how it's ran, and resolves its own imports accordingly on TLS and DLLMain return, only ESI and EIP have to be correct, so my PoC corrupts everything else... IDA didn't like a weird ESP...