Portable Executable File Format

Total Page:16

File Type:pdf, Size:1020Kb

Portable Executable File Format Chapter 11 Portable Executable File Format IN THIS CHAPTER + Understanding the structure of a PE file + Talking in terms of RVAs + Detailing the PE format + The importance of indices in the data directory + How the loader interprets a PE file MICROSOFT INTRODUCED A NEW executable file format with Windows NT. This for- mat is called the Portable Executable (PE) format because it is supposed to be portable across all 32-bit operating systems by Microsoft. The same PE format exe- cutable can be executed on any version of Windows NT, Windows 95, and Win32s. Also, the same format is used for executables for Windows NT running on proces- sors other than Intel x86, such as MIPS, Alpha, and Power PC. The 32-bit DLLs and Windows NT device drivers also follow the same PE format. It is helpful to understand the PE file format because PE files are almost identi- cal on disk and in RAM. Learning about the PE format is also helpful for under- standing many operating system concepts. For example, how operating system loader works to support dynamic linking of DLL functions, the data structures in- volved in dynamic linking such as import table, export table, and so on. The PE format is not really undocumented. The WINNT.H file has several struc- ture definitions representing the PE format. The Microsoft Developer's Network (MSDN) CD-ROMs contain several descriptions of the PE format. However, these descriptions are in bits and pieces, and are by no means complete. In this chapter, we try to give you a comprehensive picture of the PE format. Microsoft also provides a DLL with the SDK that has utility functions for inter- preting PE files. We also discuss these functions and correlate them with other in- formation about the PE format. 223 224 Part 11: Undocumented Windows NT Overview of a PE File In this section, we discuss the overall structure of a PE file. In the sections that fol- . sections s variou s comprise e fil E P A . format E P e th t abou l detai o int o g e w , low Because Microsoft's 32-bit operating systems follow the flat memory model, an ex- s a h suc , executable n a f o s part t differen , Still . segments s contain r longe o n e ecutabl e executabl n a f o s part t differen e Thes . characteristics t differen e hav , data d an e cod d store a dat f o n concatenatio a s i e fil E P a , Thus . sections t differen s a d store e ar in sections. A few sections are always present in a PE file generated by the Microsoft linker. d generate e fil E P A . names t differen h wit s section r simila e generat y ma s linker r Othe with the Microsoft linker has a .text section that contains the code bytes concate- nated from all the object files. As for the data, it can be classified into different cat- egories. The .data section contains all the initialized global and static data, while the - liter g strin s a h suc , data y read-onl e Th . data d uninitialize e th s contain n sectio s .bs e som s contain o als n sectio s Thi . section a .rdat e th n i d store s i , constants d an s al other read-only structures, such as the debug directory, the Thread Local Storage n sectio a .edat e Th . chapter s thi n i r late n explai e w h whic , on o s d an , directory ) (TLS contains information about the functions exported from a DLL, while the .idata sec- tion stores information about the functions imported by an executable or a DLL. The .rsrc section contains various resources, such as menus and dialog boxes. The .reloc section stores the information required for relocating the image while loading. , earlier d mentione s A . significance y an e hav t no o d s section e th f o s name e Th o als n ca s Programmer . sections e th r fo s name t differen e us y ma s linker t differen g data_se a #pragm d an g code_se a #pragm e Th . own r thei f o s section w ne e creat . compiler t Microsof h wit g workin e whil s section w ne e creat o t d use e b n ca s macro The operating system loader locates the required piece of information from the data e fil f o w overvie n a t presen l wil e w , Shortly . headers e fil e th n i t presen s directorie . detail e mor n i m the t a k loo n the d an s header e Fil E P a f o e Structur - head s variou s contain e fil E P a , data l actua e th f o g consistin s section e th m fro t Apar . sections e th n i t presen n informatio t importan e th d an s section e th e describ t tha s er . familiar k loo t migh s byte 2 t firs e th , file E P a f o p dum x he e th t a k loo u yo f I Aren't they M and Z? Yes, a PE file starts with the DOS executable header. It is fol- lowed by a small program that prints an error message saying that the program cannot be run in DOS mode. It's the same idea that was used in 16-bit Windows ex- . DOS r unde n ru s i e imag E P e th f i , executed s i e cod m progra s Thi . ecutables After the DOS header and the DOS executable stub comes the PE header. A field e 4-byt e th h wit s start r heade E P e Th . header w ne s thi o t s point r heade S DO e th n i signature "PE" followed by two nulls. The PE format is based on the Common Object Chapter 11: Portable Executable Eile Format 225 e fil t objec e th y b d followe s i e signatur E P e Th . Unix y b d use ) (COFF t Forma e Fil d produce s file t objec e th r fo o als t presen s i r heade s Thi . COFF m fro d borrowe r heade by Microsoft's 32-bit compilers. This header contains some general information about the file, such as the target machine ID, the number of sections in the file, and so forth. The COFF style header is followed by the optional header. This header is op- tional in the sense that it is not required for the object files. As far as executables and DLLs are concerned, this header is mandatory. The optional header has two e Th . files F COF l al n i d foun e b n ca d an F COF m fro d inherite s i t par t firs e Th . parts second part is an NT-specific extension of COFF. Apart from other NT-specific infor- e Th . directory a dat e th s contain o als t par s thi , type m subsyste e th s a h suc , mation data directory is an array in which each entry points to some important piece of in- formation. One of the entries in the data directory points to the import table of the . on o s d an , DLL e th f o e tabl t expor e th o t s point y entr r anothe , DLL r o e executabl n informatio f o s piece t differen e th f o s format d detaile e th t a k loo l wil e W later in this chapter. f o y arra n a s i e tabl n sectio e Th . table n sectio e th y b d followe s i y director a dat e Th e th t abou n informatio t importan e th s summarize r heade n sectio A . headers n sectio respective section. Finally, the section table is followed by the sections themselves. e Befor . file E P a f o n organizatio e th f o w overvie n a u yo s give s thi t tha e hop e W diving into the details of the PE format, let's discuss a concept that is vital in inter- preting a PE file. ... s Addres l Virtua e Relativ All the offsets within a PE file are denoted as Relative Virtual Addresses (RVAs). An . memory n i d loade s i e executabl n a h whic t a s addres e bas e th m fro t offse n a s i A RV This is not the same as the offset within the file because of the section alignment n a r fo s requirement t alignmen n sectio e th s specifie r heade E P e Th . requirements executable image. A section has to be loaded at a memory address that is a multi- ple of the section alignment. The section alignment has to be a multiple of the page ; requirements e attribut e pag t differen e hav s section t differen e becaus s i s Thi .
Recommended publications
  • The “Stabs” Debug Format
    The \stabs" debug format Julia Menapace, Jim Kingdon, David MacKenzie Cygnus Support Cygnus Support Revision TEXinfo 2017-08-23.19 Copyright c 1992{2021 Free Software Foundation, Inc. Contributed by Cygnus Support. Written by Julia Menapace, Jim Kingdon, and David MacKenzie. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". i Table of Contents 1 Overview of Stabs ::::::::::::::::::::::::::::::: 1 1.1 Overview of Debugging Information Flow ::::::::::::::::::::::: 1 1.2 Overview of Stab Format ::::::::::::::::::::::::::::::::::::::: 1 1.3 The String Field :::::::::::::::::::::::::::::::::::::::::::::::: 2 1.4 A Simple Example in C Source ::::::::::::::::::::::::::::::::: 3 1.5 The Simple Example at the Assembly Level ::::::::::::::::::::: 4 2 Encoding the Structure of the Program ::::::: 7 2.1 Main Program :::::::::::::::::::::::::::::::::::::::::::::::::: 7 2.2 Paths and Names of the Source Files :::::::::::::::::::::::::::: 7 2.3 Names of Include Files:::::::::::::::::::::::::::::::::::::::::: 8 2.4 Line Numbers :::::::::::::::::::::::::::::::::::::::::::::::::: 9 2.5 Procedures ::::::::::::::::::::::::::::::::::::::::::::::::::::: 9 2.6 Nested Procedures::::::::::::::::::::::::::::::::::::::::::::: 11 2.7 Block Structure
    [Show full text]
  • Automatic Classifying of Mac OS X Samples
    Automatic Classifying of Mac OS X Samples Spencer Hsieh, Pin Wu and Haoping Liu Trend Micro Inc., Taiwan TREND MICRO LEGAL DISCLAIMER The information provided herein is for general information Contents and educational purposes only. It is not intended and should not be construed to constitute legal advice. The information contained herein may not be applicable to all situations and may not reflect the most current situation. Nothing contained herein should be relied on or acted 4 upon without the benefit of legal advice based on the particular facts and circumstances presented and nothing Introduction herein should be construed otherwise. Trend Micro reserves the right to modify the contents of this document at any time without prior notice. Translations of any material into other languages are intended solely as a convenience. Translation accuracy 6 is not guaranteed nor implied. If any questions arise related to the accuracy of a translation, please refer to Mac OS X Samples Dataset the original language official version of the document. Any discrepancies or differences created in the translation are not binding and have no legal effect for compliance or enforcement purposes. 10 Although Trend Micro uses reasonable efforts to include accurate and up-to-date information herein, Trend Micro makes no warranties or representations of any kind as Classification of Mach-O Files to its accuracy, currency, or completeness. You agree that access to and use of and reliance on this document and the content thereof is at your own risk. Trend Micro disclaims all warranties of any kind, express or implied. 11 Neither Trend Micro nor any party involved in creating, producing, or delivering this document shall be liable for any consequence, loss, or damage, including direct, Malware Families indirect, special, consequential, loss of business profits, or special damages, whatsoever arising out of access to, use of, or inability to use, or in connection with the use of this document, or any errors or omissions in the content 15 thereof.
    [Show full text]
  • Intel Updates
    Intel Updates Jun Nakajima Intel Open Source Technology Center Xen Summit November 2007 Legal Disclaimer y INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL’S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL® PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. INTEL PRODUCTS ARE NOT INTENDED FOR USE IN MEDICAL, LIFE SAVING, OR LIFE SUSTAINING APPLICATIONS. y Intel may make changes to specifications and product descriptions at any time, without notice. y All products, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice. y Intel, processors, chipsets, and desktop boards may contain design defects or errors known as errata, which may cause the product to deviate from published specifications. Current characterized errata are available on request. y Intel and the Intel logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. y *Other names and brands may be claimed as the property of others. y Copyright © 2007 Intel Corporation. Throughout this presentation: VT-x refers to Intel®
    [Show full text]
  • EXPLOITING BLUEBORNE in LINUX- BASED IOT DEVICES Ben Seri & Alon Livne
    EXPLOITING BLUEBORNE IN LINUX- BASED IOT DEVICES Ben Seri & Alon Livne EXPLOITING BLUEBORNE IN LINUX-BASED IOT DEVICES – © 2019 ARMIS, INC. Preface 3 Brief Bluetooth Background 4 L2CAP 4 Overview 4 Mutual configuration 5 Linux kernel RCE vulnerability - CVE-2017-1000251 6 Impact 8 Exploitation 9 Case Study #1 - Samsung Gear S3 9 Extracting the smartwatch kernel 9 Leveraging stack overflow into PC control 10 From Kernel to User-Mode 13 Aarch64 Return-Oriented-Programming 13 Structural considerations 14 SMACK 19 Case Study #2 - Amazon Echo 22 Getting out of bounds 23 Analyzing the stack 23 Developing Write-What-Where 26 Putting it all together 28 Case Study #n - Defeating modern mitigations 29 A new information leak vulnerability in the kernel - CVE-2017-1000410 29 Conclusions 31 BLUEBORNE ON LINUX — ©​ 2019 ARMIS, INC. — 2 ​ ​ Preface In September 2017 the BlueBorne attack vector was disclosed by Armis Labs. BlueBorne allows attackers to leverage Bluetooth connections to penetrate and take complete control over targeted devices. Armis Labs has identified 8 vulnerabilities related to this attack vector, affecting four operating systems, including Windows, iOS, Linux, and Android. Previous white papers on BlueBorne were published as well: ● The dangers of Bluetooth implementations detailed the overall research, the attack ​ surface, and the discovered vulnerabilities. ● BlueBorne on Android detailed the exploitation process of the BlueBorne vulnerabilities ​ on Android. This white paper will elaborate upon the Linux RCE vulnerability (CVE-2017-1000251) and its ​ ​ exploitation. The exploitation of this vulnerability will be presented on two IoT devices - a Samsung Gear S3 Smartwatch, and the Amazon Echo digital assistant.
    [Show full text]
  • Dartmouth Computer Science Technical Report TR2011-680 (Draft Version) Exploiting the Hard-Working DWARF: Trojans with No Native Executable Code
    Dartmouth Computer Science Technical Report TR2011-680 (Draft version) Exploiting the Hard-Working DWARF: Trojans with no Native Executable Code James Oakley and Sergey Bratus Computer Science Dept. Dartmouth College Hanover, New Hampshire [email protected] April 11, 2011 Abstract All binaries compiled by recent versions of GCC from C++ programs include complex data and dedicated code for exception handling support. The data structures describe the call stack frame layout in the DWARF format byte- code. The dedicated code includes an interpreter of this bytecode and logic to implement the call stack unwinding. Despite being present in a large class of programs { and therefore poten- tially providing a huge attack surface { this mechanism is not widely known or studied. Of particular interest to us is that the exception handling mech- anism provides the means for fundamentally altering the flow of a program. DWARF is designed specifically for calculating call frame addresses and reg- ister values. DWARF expressions are Turing-complete and may calculate register values based on any readable data in the address space of the pro- cess. The exception handling data is in effect an embedded program residing within every C++ process. This paper explores what can be accomplished with control of the debugging information without modifying the program's text or data. We also examine the exception handling mechanism and argue that it is rife for vulnerability finding, not least because the error states of a program are often those least well tested. We demonstrate the capabilities of this DWARF virtual machine and its suitableness for building a new type of backdoor as well as other implications it has on security.
    [Show full text]
  • A Proposed System for Hiding Information in Portable Executable Files Based on Analyzing Import Section
    IOSR Journal of Engineering (IOSRJEN) www.iosrjen.org ISSN (e): 2250-3021, ISSN (p): 2278-8719 Vol. 04, Issue 01 (January. 2014), ||V7|| PP 21-30 A Proposed System for Hiding Information In Portable Executable Files Based on Analyzing Import Section Mohammad Hussein Jawwad 1- University of Babylon- College of Information Technology- Iraq Abstract: - Information-hiding techniques have newly become very important in a many application areas. Many cover mediums have been used to hide information like image, video, voice. Use of these mediums have been extensively studied. In this paper, we propose new system for hiding information in Portable Executable files (PE files). PE is a file format for executable file used in the 32-bit and 64-bit versions of the Windows operating system. This algorithm has higher security than some traditional ones because of the combination between encryption and hiding. We first encrypt the information before hiding it to ensure high security. After that we hide the information in the import table of PE file. This hiding depends on analyzing the import table characteristics of PE files that have been built under Borland turbo assembler. The testing result shows that the result file does not make any inconsistency with anti-virus programs and the PE file still function as normal after the hiding process. Keywords: - PE File, Information Hiding, Cryptography. I. INTRODUCTION The development and wide use of computer science and informatics also, the advent of global networks (i.e. Internet) that make the access for information is possible for every one online impose the need for ways to avoid hackers and muggers from getting the important information.
    [Show full text]
  • Debugging with GDB
    Debugging with GDB The gnu Source-Level Debugger HP Seventeenth Edition, for GDB January 2007 Richard Stallman, Roland Pesch, Stan Shebs, et al. (Send bugs and comments on GDB to [email protected] with copy to [email protected] ) Debugging with GDB TEXinfo 2003-02-03.16 Copyright c 2007 Free Software Foundation, Inc. Published by the Free Software Foundation 59 Temple Place - Suite 330, Boston, MA 02111-1307 USA ISBN 1-882114-77-9 Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another lan- guage, under the above conditions for modified versions. i Table of Contents Summary of GDB............................. 1 Free software ................................................ 1 Contributors to GDB......................................... 1 1 A Sample GDB Session .................... 5 1.1 Loading the Executable .................................. 5 1.2 Setting Display width.................................... 6 1.3 Setting Breakpoints ..................................... 6 1.4 Running the executable under GDB ...................... 6 1.5 Stepping to the next line in the source program............ 6 1.6 Stepping into a subroutine ............................... 6 1.7 Examining the Stack .................................... 7 1.8 Printing Variable Values ................................. 7 1.9 Listing Source Code ..................................... 7 1.10 Setting Variable Values During a Session ................. 8 2 Getting In and Out of GDB ..............
    [Show full text]
  • Process Address Spaces and Binary Formats
    Process Address Spaces and Binary Formats Don Porter – CSE 506 Housekeeping ò Lab deadline extended to Wed night (9/14) ò Enrollment finalized – if you still want in, email me ò All students should have VMs at this point ò Email Don if you don’t have one ò TA office hours posted ò Private git repositories should be setup soon Review ò We’ve seen how paging and segmentation work on x86 ò Maps logical addresses to physical pages ò These are the low-level hardware tools ò This lecture: build up to higher-level abstractions ò Namely, the process address space Definitions (can vary) ò Process is a virtual address space ò 1+ threads of execution work within this address space ò A process is composed of: ò Memory-mapped files ò Includes program binary ò Anonymous pages: no file backing ò When the process exits, their contents go away Problem 1: How to represent? ò What is the best way to represent the components of a process? ò Common question: is mapped at address x? ò Page faults, new memory mappings, etc. ò Hint: a 64-bit address space is seriously huge ò Hint: some programs (like databases) map tons of data ò Others map very little ò No one size fits all Sparse representation ò Naïve approach might would be to represent each page ò Mark empty space as unused ò But this wastes OS memory ò Better idea: only allocate nodes in a data structure for memory that is mapped to something ò Kernel data structure memory use proportional to complexity of address space! Linux: vm_area_struct ò Linux represents portions of a process with a vm_area_struct,
    [Show full text]
  • Common Object File Format (COFF)
    Application Report SPRAAO8–April 2009 Common Object File Format ..................................................................................................................................................... ABSTRACT The assembler and link step create object files in common object file format (COFF). COFF is an implementation of an object file format of the same name that was developed by AT&T for use on UNIX-based systems. This format encourages modular programming and provides powerful and flexible methods for managing code segments and target system memory. This appendix contains technical details about the Texas Instruments COFF object file structure. Much of this information pertains to the symbolic debugging information that is produced by the C compiler. The purpose of this application note is to provide supplementary information on the internal format of COFF object files. Topic .................................................................................................. Page 1 COFF File Structure .................................................................... 2 2 File Header Structure .................................................................. 4 3 Optional File Header Format ........................................................ 5 4 Section Header Structure............................................................. 5 5 Structuring Relocation Information ............................................... 7 6 Symbol Table Structure and Content........................................... 11 SPRAAO8–April 2009
    [Show full text]
  • Investigation of Malicious Portable Executable File Detection on the Network Using Supervised Learning Techniques
    Investigation of Malicious Portable Executable File Detection on the Network using Supervised Learning Techniques Rushabh Vyas, Xiao Luo, Nichole McFarland, Connie Justice Department of Information and Technology, Purdue School of Engineering and Technology IUPUI, Indianapolis, IN, USA 46202 Emails: [email protected]; [email protected]; [email protected]; [email protected] Abstract—Malware continues to be a critical concern for that random forest learning technique achieved best detection everyone from home users to enterprises. Today, most devices are performance than the other three learning techniques. The connected through networks to the Internet. Therefore, malicious achieved detection rate and false alarm rate on experimental code can easily and rapidly spread. The objective of this paper is to examine how malicious portable executable (PE) files can be data set were 98.7% and 1.8% respectively. We compared detected on the network by utilizing machine learning algorithms. the performances of the four learning techniques on four The efficiency and effectiveness of the network detection rely types of PE malware - backdoors, viruses, worms and trojans. on the number of features and the learning algorithms. In this The results showed that the same learning technique show work, we examined 28 features extracted from metadata, packing, the similar performance on different types of malwares. It imported DLLs and functions of four different types of PE files for malware detection. The returned results showed that the demonstrated the features that are extracted from the files have proposed system can achieve 98.7% detection rates, 1.8% false no bias for a specific type of malware.
    [Show full text]
  • CS429: Computer Organization and Architecture Linking I & II
    CS429: Computer Organization and Architecture Linking I & II Dr. Bill Young Department of Computer Sciences University of Texas at Austin Last updated: April 5, 2018 at 09:23 CS429 Slideset 23: 1 Linking I A Simplistic Translation Scheme m.c ASCII source file Problems: Efficiency: small change Compiler requires complete re-compilation. m.s Modularity: hard to share common functions (e.g., printf). Assembler Solution: Static linker (or Binary executable object file linker). p (memory image on disk) CS429 Slideset 23: 2 Linking I Better Scheme Using a Linker Linking is the process of m.c a.c ASCII source files combining various pieces of code and data into a Compiler Compiler single file that can be loaded (copied) into m.s a.s memory and executed. Linking could happen at: Assembler Assembler compile time; Separately compiled m.o a.o load time; relocatable object files run time. Linker (ld) Must somehow tell a Executable object file module about symbols p (code and data for all functions defined in m.c and a.c) from other modules. CS429 Slideset 23: 3 Linking I Linking A linker takes representations of separate program modules and combines them into a single executable. This involves two primary steps: 1 Symbol resolution: associate each symbol reference throughout the set of modules with a single symbol definition. 2 Relocation: associate a memory location with each symbol definition, and modify each reference to point to that location. CS429 Slideset 23: 4 Linking I Translating the Example Program A compiler driver coordinates all steps in the translation and linking process.
    [Show full text]
  • IBM AIX Version 6.1 Differences Guide
    Front cover IBM AIX Version 6.1 Differences Guide AIX - The industrial strength UNIX operating system AIX Version 6.1 enhancements explained An expert’s guide to the new release Roman Aleksic Ismael "Numi" Castillo Rosa Fernandez Armin Röll Nobuhiko Watanabe ibm.com/redbooks International Technical Support Organization IBM AIX Version 6.1 Differences Guide March 2008 SG24-7559-00 Note: Before using this information and the product it supports, read the information in “Notices” on page xvii. First Edition (March 2008) This edition applies to AIX Version 6.1, program number 5765-G62. © Copyright International Business Machines Corporation 2007, 2008. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Figures . xi Tables . xiii Notices . xvii Trademarks . xviii Preface . xix The team that wrote this book . xix Become a published author . xxi Comments welcome. xxi Chapter 1. Application development and system debug. 1 1.1 Transport independent RPC library. 2 1.2 AIX tracing facilities review . 3 1.3 POSIX threads tracing. 5 1.3.1 POSIX tracing overview . 6 1.3.2 Trace event definition . 8 1.3.3 Trace stream definition . 13 1.3.4 AIX implementation overview . 20 1.4 ProbeVue . 21 1.4.1 ProbeVue terminology. 23 1.4.2 Vue programming language . 24 1.4.3 The probevue command . 25 1.4.4 The probevctrl command . 25 1.4.5 Vue: an overview. 25 1.4.6 ProbeVue dynamic tracing example . 31 Chapter 2. File systems and storage. 35 2.1 Disabling JFS2 logging .
    [Show full text]