Download the Full Version of textbook for Fast Typing at textbookfull.

com

Engineering Secure Software and Systems 6th

International Symposium ESSoS 2014 Munich Germany
February 26 28 2014 Proceedings 1st Edition Jan
Jürjens
https://textbookfull.com/product/engineering-secure-
software-and-systems-6th-international-symposium-
essos-2014-munich-germany-
february-26-28-2014-proceedings-1st-edition-jan-jurjens/

OR CLICK BUTTON

DOWNLOAD NOW

Download More textbook Instantly Today - Get Yours Now at textbookfull.com

 Recommended digital products (PDF, EPUB, MOBI) that
you can download immediately if you are interested.

Search Based Software Engineering 6th International

Symposium SSBSE 2014 Fortaleza Brazil August 26 29 2014
Proceedings 1st Edition Claire Le Goues
https://textbookfull.com/product/search-based-software-
engineering-6th-international-symposium-ssbse-2014-fortaleza-brazil-
august-26-29-2014-proceedings-1st-edition-claire-le-goues/
textboxfull.com

Architecture of Computing Systems ARCS 2014 27th

International Conference Lübeck Germany February 25 28
2014 Proceedings 1st Edition Erik Maehle
https://textbookfull.com/product/architecture-of-computing-systems-
arcs-2014-27th-international-conference-lubeck-germany-
february-25-28-2014-proceedings-1st-edition-erik-maehle/
textboxfull.com

Smart Grid Security Second International Workshop

SmartGridSec 2014 Munich Germany February 26 2014 Revised
Selected Papers 1st Edition Jorge Cuellar (Eds.)
https://textbookfull.com/product/smart-grid-security-second-
international-workshop-smartgridsec-2014-munich-germany-
february-26-2014-revised-selected-papers-1st-edition-jorge-cuellar-
eds/
textboxfull.com

Engineering Secure Software and Systems 7th International

Symposium ESSoS 2015 Milan Italy March 4 6 2015
Proceedings 1st Edition Frank Piessens
https://textbookfull.com/product/engineering-secure-software-and-
systems-7th-international-symposium-essos-2015-milan-italy-
march-4-6-2015-proceedings-1st-edition-frank-piessens/
textboxfull.com
Engineering Secure Software and Systems 8th International
Symposium ESSoS 2016 London UK April 6 8 2016 Proceedings
1st Edition Juan Caballero
https://textbookfull.com/product/engineering-secure-software-and-
systems-8th-international-symposium-essos-2016-london-uk-
april-6-8-2016-proceedings-1st-edition-juan-caballero/
textboxfull.com

Software Engineering for Resilient Systems 6th

International Workshop SERENE 2014 Budapest Hungary
October 15 16 2014 Proceedings 1st Edition István Majzik
https://textbookfull.com/product/software-engineering-for-resilient-
systems-6th-international-workshop-serene-2014-budapest-hungary-
october-15-16-2014-proceedings-1st-edition-istvan-majzik/
textboxfull.com

Supercomputing 29th International Conference ISC 2014

Leipzig Germany June 22 26 2014 Proceedings 1st Edition
Julian Martin Kunkel
https://textbookfull.com/product/supercomputing-29th-international-
conference-isc-2014-leipzig-germany-june-22-26-2014-proceedings-1st-
edition-julian-martin-kunkel/
textboxfull.com

Information Technology in Bio and Medical Informatics 5th

International Conference ITBAM 2014 Munich Germany
September 2 2014 Proceedings 1st Edition Miroslav Bursa
https://textbookfull.com/product/information-technology-in-bio-and-
medical-informatics-5th-international-conference-itbam-2014-munich-
germany-september-2-2014-proceedings-1st-edition-miroslav-bursa/
textboxfull.com

Bioinformatics Research and Applications 10th

International Symposium ISBRA 2014 Zhangjiajie China June
28 30 2014 Proceedings 1st Edition Mitra Basu
https://textbookfull.com/product/bioinformatics-research-and-
applications-10th-international-symposium-isbra-2014-zhangjiajie-
china-june-28-30-2014-proceedings-1st-edition-mitra-basu/
textboxfull.com
 Jan Jürjens
Frank Piessens
Nataliia Bielova (Eds.)

Engineering
LNCS 8364

Secure Software
and Systems
6th International Symposium, ESSoS 2014
Munich, Germany, February 26-28, 2014
Proceedings

123
Lecture Notes in Computer Science 8364
Commenced Publication in 1973
Founding and Former Series Editors:
Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board
David Hutchison
Lancaster University, UK
Takeo Kanade
Carnegie Mellon University, Pittsburgh, PA, USA
Josef Kittler
University of Surrey, Guildford, UK
Jon M. Kleinberg
Cornell University, Ithaca, NY, USA
Alfred Kobsa
University of California, Irvine, CA, USA
Friedemann Mattern
ETH Zurich, Switzerland
John C. Mitchell
Stanford University, CA, USA
Moni Naor
Weizmann Institute of Science, Rehovot, Israel
Oscar Nierstrasz
University of Bern, Switzerland
C. Pandu Rangan
Indian Institute of Technology, Madras, India
Bernhard Steffen
TU Dortmund University, Germany
Madhu Sudan
Microsoft Research, Cambridge, MA, USA
Demetri Terzopoulos
University of California, Los Angeles, CA, USA
Doug Tygar
University of California, Berkeley, CA, USA
Gerhard Weikum
Max Planck Institute for Informatics, Saarbruecken, Germany
Jan Jürjens Frank Piessens
Nataliia Bielova (Eds.)

Engineering
Secure Software
and Systems
6th International Symposium, ESSoS 2014
Munich, Germany, February 26-28, 2014
Proceedings

13
Volume Editors
Jan Jürjens
Technical University Dortmund
Department of Computer Science
Dortmund, Germany
E-mail: [email protected]
Frank Piessens
KU Leuven
Department of Computer Science
Heverlee, Belgium
E-mail: [email protected]
Nataliia Bielova
Inria Sophia Antipolis – Mediterranee
Sophia Antipolis Cedex, France
E-mail: [email protected]

ISSN 0302-9743 e-ISSN 1611-3349

ISBN 978-3-319-04896-3 e-ISBN 978-3-319-04897-0
DOI 10.1007/978-3-319-04897-0
Springer Cham Heidelberg New York Dordrecht London

Library of Congress Control Number: 2014930756

CR Subject Classification (1998): E.3, D.4.6, D.2.1, D.2.4, F.3.1, K.6.5

LNCS Sublibrary: SL 4 – Security and Cryptology

© Springer International Publishing Switzerland 2014
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of
the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation,
broadcasting, reproduction on microfilms or in any other physical way, and transmission or information
storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology
now known or hereafter developed. Exempted from this legal reservation are brief excerpts in connection
with reviews or scholarly analysis or material supplied specifically for the purpose of being entered and
executed on a computer system, for exclusive use by the purchaser of the work. Duplication of this publication
or parts thereof is permitted only under the provisions of the Copyright Law of the Publisher’s location,
in its current version, and permission for use must always be obtained from Springer. Permissions for use
may be obtained through RightsLink at the Copyright Clearance Center. Violations are liable to prosecution
under the respective Copyright Law.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
While the advice and information in this book are believed to be true and accurate at the date of publication,
neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or
omissions that may be made. The publisher makes no warranty, express or implied, with respect to the
material contained herein.
Typesetting: Camera-ready by author, data conversion by Scientific Publishing Services, Chennai, India
Printed on acid-free paper
Springer is part of Springer Science+Business Media (www.springer.com)
 Preface

It is our pleasure to welcome you to the 6th International Symposium on Engi-

neering Secure Software and Systems (ESSoS 2014). This event in a maturing
series of symposia attempts to bridge the gap between the scientific communities
from software engineering and security with the goal of supporting secure soft-
ware development. The parallel technical sponsorship from ACM SIGSAC (the
ACM interest group in security) and ACM SIGSOFT (the ACM interest group
in software engineering) demonstrates the support from both communities and
the need for providing such a bridge.
Security mechanisms and the act of software development usually go hand
in hand. It is generally not enough to ensure correct functioning of the security
mechanisms used. They cannot be “blindly” inserted into a security-critical sys-
tem, but the overall system development must take security aspects into account
in a coherent way. Building trustworthy components does not suffice, since the
interconnections and interactions of components play a significant role in trust-
worthiness. Lastly, while functional requirements are generally analyzed care-
fully in systems development, security considerations often arise after the fact.
Adding security as an afterthought, however, often leads to problems. Ad hoc de-
velopment can lead to the deployment of systems that do not satisfy important
security requirements. Thus, a sound methodology supporting secure systems
development is needed. The presentations and associated publications at ESSoS
2014 contribute to this goal in several directions: On the one hand, with se-
cure software engineering results for specific application domains (such as Web
and mobile security). On the other hand, improving specific methods in secure
software engineering (such as model-based security or formal methods). A third
set of presentations presents real-life applications of secure software engineering
approaches.
The conference program featured three major keynotes from Ross Anderson
(University of Cambridge) on the psychology of security, Adrian Perrig (ETH
Zurich) on scalability, control, and isolation for next-generation networks, and
Stephan Micklitz (Google Munich) on human factors and strong authentication,
as well as a set of research and idea papers. In response to the call for papers,
55 papers were submitted. The Program Committee selected 11 full-paper con-
tributions (20%), presenting new research results on engineering secure software
and systems. In addition, there are four idea papers, giving a concise account of
new ideas in the early stages of research.
Many individuals and organizations have contributed to the success of this
event. First of all, we would like to express our appreciation to the authors of the
submitted papers and to the Program Committee members and external refer-
ees, who provided timely and relevant reviews. Many thanks go to the Steering
Committee for supporting this series of symposia, and to all the members of
VI Preface

the Organizing Committee for their tremendous work and for excelling in their
respective tasks. The DistriNet research group of the KU Leuven did an excel-
lent job with the website and the advertising for the conference. Finally, we owe
gratitude to ACM SIGSAC/SIGSOFT, IEEE TCSP, and LNCS for continuing
to support us in this series of symposia.

December 2013 Jan Jürjens

Frank Piessens
Nataliia Bielova
 Conference Organization

General Chair
Alexander Pretschner Technische Universität München, Germany

Program Co-chairs
Jan Jürjens TU Dortmund and Fraunhofer ISST, Germany
Frank Piessens Katholieke Universiteit Leuven, Belgium

Publication Chair
Nataliia Bielova Inria Sophia Antipolis, France

Publicity Chair
Pieter Philippaerts Katholieke Universiteit Leuven, Belgium

Web Chair
Ghita Saevels Katholieke Universiteit Leuven, Belgium

Local Arrangements Chair

Regina Jourdan Technische Universität München, Germany

Steering Committee
Jorge Cuellar Siemens AG, Germany
Wouter Joosen Katholieke Universiteit Leuven, Belgium
Fabio Massacci Universitá di Trento, Italy
Gary McGraw Cigital, USA
Bashar Nuseibeh The Open University, UK
Daniel Wallach Rice University, USA
VIII Conference Organization

Program Committee
Ruth Breu University of Innsbruck, Austria
Lorenzo Cavallaro Royal Holloway, University of London, UK
Anupam Datta Carnegie Mellon University, USA
Werner Dietl University of Washington, USA
François Dupressoir IMDEA, Spain
Eduardo Fernandez Florida Atlantic University, USA
Eduardo Fernandez-Medina
Paton Universidad de Castilla-La Mancha, Spain
Cormac Flanagan U.C. Santa Cruz, USA
Dieter Gollmann TU Hamburg-Harburg, Germany
Arjun Guha Cornell University, USA
Christian Hammer Saarland University, Germany
Hannes Hartenstein Karlsruher Institut für Technologie, Germany
Maritta Heisel University of Duisburg Essen, Germany
Peter Herrmann NTNU, Trondheim, Norway
Valerie Issarny Inria, France
Limin Jia Carnegie Mellon University, USA
Martin Johns SAP Research, Germany
Jay Ligatti University of South Florida, USA
Heiko Mantel TU Darmstadt, Germany
Haris Mouratidis University of East London, UK
Martı́n Ochoa Siemens AG, Germany
Jae Park University of Texas at San Antonio, USA
Erik Poll RU Nijmegen, The Netherlands
Wolfgang Reif University of Augsburg, Germany
Riccardo Scandariato Katholieke Universiteit Leuven, Belgium
Ketil Stølen SINTEF, Norway
Steve Zdancewic University of Pennsylvania, USA
Mohammad Zulkernine Queens University, Canada

Additional Reviewers
Azadeh Alebrahim Kuzman Katkalov David Pfaff
Kristian Beckers Basel Katt Fredrik Seehusen
Abhishek Bichhawat Johannes Leupolz Christian Sillaber
Marian Borek Yan Li Bjørnar Solhaug
Michael Brunner Steffen Lortz Barbara Sprick
Gencer Erdogan Rene Meis Kurt Stenzel
Stephan Faßbender Jan Tobias Muehlberg Lianshan Sun
Matthias Gander Sebastian Pape Marie Walter
Jinwei Hu Davide Papini Philipp Zech
 Conference Organization IX

Sponsoring Institutions

Technische Universität München, Germany

NESSoS FP7 Project, Network of Excellence on

Engineering Secure Future Internet Software Ser-
vices and Systems, www.nessos-project.eu
Keynote Abstracts
 The Psychology of Security

Ross Anderson

University of Cambridge, UK

Abstract. A fascinating dialogue is developing between psychologists

and security engineers. At the macro scale, societal overreactions to ter-
rorism are founded on the misperception of risk and uncertainty, which
has deep psychological roots. At the micro scale, more and more crimes
involve deception; as security engineering gets better, it’s easier to mis-
lead people than to hack computers or hack through walls. Many frauds
can be explained in terms of the heuristics and biases that we have re-
tained from our ancestral evolutionary environment.
At an even deeper level, the psychology of security touches on funda-
mental scientific and philosophical problems. The ‘Machiavellian Brain’
hypothesis states that we evolved high intelligence not to make better
tools, but to use other monkeys better as tools: primates who were better
at deception, or at detecting deception in others, left more descendants.
Yet the move online is changing the parameters of deception, and rob-
bing us of many of the signals we use to make trust judgments in the
“real” world; it’s a lot easier to copy a bank website than it is to copy
a bank. Many systems fail because the security usability has not been
thought through: the designers have different mental models of threats
and protection mechanisms from users. And misperceptions cause secu-
rity markets to fail: many users buy snake oil, while others distrust quite
serviceable mechanisms.
Security is both a feeling and a reality, and they’re different. The gap
gets ever wider, and ever more important. In this talk I will describe the
rapidly-growing field of security psychology which is bringing together
security engineers not just with psychologists but with behavioural
economists, anthropologists and even philosophers to develop new ap-
proaches to risk, fraud and deception in the complex socio-technical sys-
tems on which we are all coming to rely.
SCION: Scalability, Control, and Isolation On
Next-Generation Networks

Adrian Perrig

Swiss Federal Institute of Technology (ETH), Switherland

Abstract. We present an Internet architecture designed to provide route

control, failure isolation, and explicit trust information for end-to-end
communications. SCION separates ASes into groups of independent rout-
ing sub-planes, called isolation domains, which then interconnect to form
complete routes. Isolation domains provide natural separation of routing
failures and human misconfiguration, give endpoints strong control for
both inbound and outbound traffic, provide meaningful and enforceable
trust, and enable scalable routing updates with high path freshness. As a
result, our architecture provides strong resilience and security properties
as an intrinsic consequence of good design principles, avoiding piecemeal
add-on protocols as security patches. Meanwhile, SCION only assumes
that a few top-tier ISPs in the isolation domain are trusted for provid-
ing reliable end-to-end communications, thus achieving a small Trusted
Computing Base. Both our security analysis and evaluation results show
that SCION naturally prevents numerous attacks and provides a high
level of resilience, scalability, control, and isolation.
Human Factors and Strong Authentication

Stephan Micklitz

Google Munich, Germany

Abstract. Google’s login team began focusing on strong authentication

in the spring of 2008, and in almost six years we have come a long way in
protecting our users. In this presentation we will talk about the progress
we have made since then, such as introducing strict 2-step verification,
risk-based login challenges and OpenID-style login.
We will then identify the biggest challenges we are currently facing
in establishing stronger authentication – both from a technological as
well as a usability point of view. We will also talk important privacy
considerations for such systems, and how we are addressing them. Next
we will look into our plan to address these challenges in the next years
ahead of us, making use of technological developments, e.g. the vastly
increased adoption of smart mobile devices.
 Table of Contents

Model-Based Security
Detecting Code Reuse Attacks with a Model of Conformant Program
Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Emily R. Jacobson, Andrew R. Bernat, William R. Williams, and
Barton P. Miller

Security@Runtime: A Flexible MDE Approach to Enforce Fine-Grained

Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Yehia Elrakaiby, Moussa Amrani, and Yves Le Traon

Idea: Towards a Vision of Engineering Controlled Interaction Execution

for Information Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Joachim Biskup and Cornelia Tadros

Formal Methods
Automated Formal Verification of Application-Specific Security
Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Piergiuseppe Bettassa Copet and Riccardo Sisto

Fault-Tolerant Non-interference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Filippo Del Tedesco, Alejandro Russo, and David Sands

Quantitative Security Analysis for Programs with Low Input and Noisy
Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Tri Minh Ngo and Marieke Huisman

A Modeling and Formal Approach for the Precise Specification

of Security Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Brahim Hamid and Christian Percebois

On the Relation between Redactable and Sanitizable Signature

Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Hermann de Meer, Henrich C. Pöhls, Joachim Posegga, and
Kai Samelin

Idea: Towards a Working Fully Homomorphic Crypto-processor:

Practice and the Secret Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Peter T. Breuer and Jonathan P. Bowen
XVIII Table of Contents

Web and Mobile Security

Architectures for Inlining Security Monitors in Web Applications . . . . . . . 141
Jonas Magazinius, Daniel Hedin, and Andrei Sabelfeld

Automatic and Robust Client-Side Protection for Cookie-Based

Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Michele Bugliesi, Stefano Calzavara, Riccardo Focardi, and
Wilayat Khan

Security Testing of GSM Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Fabian van den Broek, Brinio Hond, and Arturo Cedillo Torres

Applications
User-Centric Security Assessment of Software Configurations: A Case
Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Hamza Ghani, Jesus Luna Garcia, Ivaylo Petkov, and Neeraj Suri

Idea: Security Engineering Principles for Day Two Car2X

Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Sibylle Fröschle and Alexander Stühring

Idea: Embedded Fault Injection Simulator on Smartcard . . . . . . . . . . . . . . 222

Maël Berthier, Julien Bringer, Hervé Chabanne, Thanh-Ha Le,
Lionel Rivière, and Victor Servant

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

 Detecting Code Reuse Attacks with a Model
of Conformant Program Execution

Emily R. Jacobson, Andrew R. Bernat,

William R. Williams, and Barton P. Miller

Computer Sciences Department, University of Wisconsin

{jacobson,bernat,bill,bart}@cs.wisc.edu

Abstract. Code reuse attacks circumvent traditional program protec-

tion mechanisms such as W ⊕ X by constructing exploits from code
already present within a process. Existing techniques to defend against
these attacks provide ad hoc solutions or lack in features necessary to
provide comprehensive and adoptable solutions. We present a system-
atic approach based on first principles for the efficient, robust detection
of these attacks; our work enforces expected program behavior instead
of defending against anticipated attacks. We define conformant program
execution (CPE) as a set of requirements on program states. We demon-
strate that code reuse attacks violate these requirements and thus can
be detected; further, new exploit variations will not circumvent CPE. To
provide an efficient and adoptable solution, we also define observed con-
formant program execution, which validates program state at system call
invocations; we demonstrate that this relaxed model is sufficient to detect
code reuse attacks. We implemented our algorithm in a tool, ROPStop,
which operates on unmodified binaries, including running programs. In
our testing, ROPStop accurately detected real exploits while imposing
low overhead on a set of modern applications: 5.3% on SPEC CPU2006
and 6.3% on an Apache HTTP Server.

Keywords: Binary analysis, static analysis, return-oriented program-

ming, jump-oriented programming.

1 Introduction

Code reuse attacks are an increasingly popular technique for circumventing tra-
ditional program protection mechanisms such as W ⊕ X (e.g., Data Execution
Prevention (DEP)), and the security community has proposed a wide range of
approaches to protect against these attacks. However, many of these approaches
provide ad hoc solutions, relying on observed attack characteristics that are not
intrinsic to the class of attacks. In the continuing arms race against code reuse
attacks, we must construct defenses using a more systematic approach: good
engineering practices must combine with the best security techniques.
Any such approach must be engineered to cover the complete spectrum of
attack surfaces. While more general defensive techniques, such as Control Flow

J. Jürjens, F. Piessens, and N. Bielova (Eds.): ESSoS 2014, LNCS 8364, pp. 1–18, 2014.
c Springer International Publishing Switzerland 2014
2 E.R. Jacobson et al.

Integrity or host-based intrusion detection, provide good technical solutions,

each is lacking in one or more features necessary to provide a comprehensive
and adoptable solution [51]. We must develop defenses that can be effectively
applied to real programs.
We present a technique based on first principles for the efficient, robust de-
tection of code reuse attacks. Our work is grounded in a model of conformant
program execution (CPE), in which we define what program states are possi-
ble during normal execution. We generate our model automatically from the
program binary; thus, no learning phase or expert knowledge is required. CPE
enforces expected program behavior instead of defending against anticipated at-
tacks; thus, new exploit variations will not circumvent CPE. CPE is based on
observable properties of the program counter and runtime callstack; a program
has CPE if, for all program states during the execution of the program, the pro-
gram counter and callstack are individually valid and consistent with each other.
Code reuse attacks execute short sequences of instructions without respect to
their location in original code; thus, these attacks deviate from our model.
Conformant program execution verifies each program state; therefore, contin-
ually validating it can result in high overhead. We address this problem with
observed conformant program execution (OCPE), which reduces overhead by
only validating program state at system call executions. We demonstrate that
this relaxed model is sufficient to detect code reuse attacks. Thus, OCPE pro-
vides an adoptable solution while still providing safety guarantees. OCPE is not
designed to handle code reuse-based mimicry attacks, which have not yet been
demonstrated in the research world or seen in the wild. We believe OCPE could
be augmented in future work to handle these attacks.
We engineer our approach using a component model based on strong binary
analysis of the code. This analysis allows us to operate on modern binaries, which
frequently are highly optimized or lack debugging information; our analysis does
not rely on information that may not be present in a modern application. We
leverage a binary analysis toolkit to identify key characteristics of the stack frame
at any instruction in the binary; this allows us to gather a full callstack via a
stackwalk at runtime. While conceptually straightforward, accurate stackwalks
are surprisingly difficult to perform on real applications. Our algorithm leverages
these stackwalks, taken at system calls, to reliably detect code reuse attacks.
We implemented our code reuse detection algorithm in a tool, ROPStop,
which operates on unmodified binaries, including running programs. We evalu-
ated ROPStop using real exploits from two classes of code reuse attacks: return-
oriented programming (ROP) and jump-oriented programming (JOP). Our
results show that our tool is able to correctly identify each exploit. We tested
ROPStop with the SPEC CPU2006 benchmarks and an Apache HTTP Server as
a control group of unexploited, conventional binaries to evaluate overhead and
measure the occurrence of false positives. Our results show an average overhead
of 5.3% on and 6.3% on Apache; ROPStop reported no false positives.
We provide an overview of the challenges in detecting code reuse attacks and
existing work in this area in Section 2 and a formal description of conformant
 Detecting Code Reuse Attacks 3

program execution and code reuse attacks in Section 3. Next, we describe the
technical details of our approach in Section 4. We evaluate our approach in
Section 5 and finish with a brief conclusion in Section 6.

2 Background and Related Work

Code reuse attacks provide interesting new challenges for security researchers.
While W ⊕ X guards against code injection attacks, it is insufficient to stop code
reuse attacks because such attacks do not write new code into the address space.
We describe how an attacker gains control of the program and produces a code
reuse attack. Further, we describe how an attacker locates gadgets within the
program. We conclude with a discussion of techniques that are not specifically
focused on code reuse attacks but are similar to techniques presented here.

2.1 Gaining Control of the Program

The first step of a code reuse attack is to gain control of the program counter to
divert program control flow to the first gadget. This is done by making use of an
existing vulnerability (e.g., a buffer overflow) to alter program data. Although
these vulnerabilities and possible defenses are well studied, attackers remain
able to exploit these vulnerabilities and launch attacks [51]. We assume that
an attacker will be able to find a viable entry point for launching a code reuse
attack, and do not discuss these vulnerabilities further. To ensure that program
control flow will be diverted, an attacker overwrites either the return address for
the calling function or a function pointer with the address of the first gadget.
Note that W ⊕ X restricts attackers to cases where control flow targets depend
on writeable locations rather than executable locations.
If the return address is overwritten, control flow will be diverted to the gadget
when the current function returns and the new return address is loaded into
the program counter. Stack-smashing attacks such as this one have been well-
studied and techniques such as StackGuard [16] will prevent these attacks. To
be effective, this protection must be present in all program code, including the
program binary and any libraries on which it depends. These protections are
provided as options by most modern compilers, but they are frequently not
turned on by default, and can be turned off. Therefore, it is not safe to assume
these protections will be present, and frequently it is not possible for a user
to modify shared libraries (e.g., libc.so) to include them. If a function pointer
is overwritten, control flow will be diverted to the gadget when the program
invokes an indirect call or jump using the address of the function pointer.
Once control flow has been diverted to the first gadget, the code reuse attack
begins. We note that an attack might also use an existing vulnerability to modify
program data: for instance, to cause a system call to be executed with unintended
arguments. These data driven attacks [2, 14, 20] are complementary to control
flow-based attacks and are beyond the scope of our work.
4 E.R. Jacobson et al.

2.2 Gadget Execution

Return- and Jump-Oriented Programming. In ROP, each gadget is ter-
minated with a return instruction [44]. Thus, if an attacker has gained control
of the stack pointer, they can use these return instructions to cause program ex-
ecution to flow from one gadget to the next. JOP attacks use the same general
technique, but gadgets are chained together with indirect jump instructions [7,9].
Thus, unlike ROP, JOP does not rely on manipulating the stack pointer; instead,
indirect jump instructions have a specified target location, often stored in a reg-
ister. This provides an extra challenge in constructing a jump-oriented attack:
gadgets must manipulate relevant register values to ensure each indirect jump
transfers control to the next gadget.

Defenses against Code Reuse Attacks. There are a variety of techniques

designed to detect code reuse attacks. Several approaches make use of a shadow
stack to prevent control flow manipulation that relies on overwritten stack val-
ues [12, 19, 23]. Others try to detect gadget execution by monitoring the length
of instruction sequences between returns [11, 18]. Still others proposed monitor-
ing pairs of call and return instructions [12, 31]. These approaches each target
return-oriented attacks; however, they will not detect jump-oriented attacks be-
cause these attacks do not rely on return instructions to transfer control between
gadgets. Another common approach ensures that a function should only start ex-
ecuting at its entry point [12,29–31]. However, an attack may still hijack control
flow while conforming to these requirements, thus remaining undetected.
Each of these mitigation techniques targets specific characteristics of previ-
ously observed code reuse attacks; such features may not be intrinsic to all code
reuse attacks. In contrast, our work detects any violations of our model of confor-
mant program execution by validating known properties of the program. Thus,
evolving attack variations will not hinder our ability to detect these attacks.
Still other techniques monitor system calls to detect violations. ROPGuard [24]
is a recent tool focused on ROP attacks that checks for a valid callstack at a subset
of system calls. ROPGuard relies on frame pointers to traverse the callstack. Many
modern programs do not save frame pointers; thus, callstack verification is turned
off by default, leaving such programs vulnerable. By verifying conformant program
behavior at all system calls and using a robust binary analysis toolkit to perform
accurate stackwalks, our work provides a more complete approach.

2.3 Gadget Discovery

Locating potential gadgets is performed by scanning a target binary for return
instructions (for ROP) or indirect jumps (for JOP). An attacker then chooses
the gadgets to use from this set potential gadgets [13, 21, 47]. This selection of
gadgets must allow the attacker to maintain command over the control flow of
the program and perform desired actions while avoiding unwanted side effects.
ASLR is a common system-level technique that randomizes the addresses at
which libraries are loaded into the address space of a process; this is particularly
 Detecting Code Reuse Attacks 5

relevant for code reuse attacks because these attacks rely on known locations
for each gadget. Unfortunately, this is not sufficient to prevent a code reuse
attack. Schwartz et al. point out that not all operating systems randomize all
components within the address space, and some require an application to ex-
plicitly turn on ASLR [47]. As long as there exists some segment of code that is
not randomized, code reuse attacks are possible. Checkoway et al. demonstrated
that such attacks can be constructed even with a limited set of instructions [10].
Consequently, in real systems, we must assume that if gadgets exist in the code,
an attacker will be able to find a sufficiently powerful set to perform their attack.
Several prevention techniques attempt to eliminate possible gadgets in library
code via code diversification [17,28,32,36,53]. An alternative prevention strategy
seeks to create binaries or kernels that lack necessary characteristics for ROP
attacks [34, 35]. Many software diversification techniques rely on modifying the
program, library, or kernel binaries via recompilation or binary rewriting; such
modifications may not be possible in real systems. Furthermore, these techniques
do not preclude code reuse attacks, but simply challenge attackers to identify
gadgets in more sophisticated ways [51]. In contrast, ROPStop is engineered to
provide a comprehensive solution that does not require ASLR or recompilation;
ROPStop operates on unmodified binaries, including running programs.

2.4 Other Approaches

Our work is also similar to techniques that, while not focused on code reuse
attacks, may be effective against such attacks: control flow validity enforcement
and anomalous system call detection. Control-Flow Integrity (CFI) ensures that
program execution holds to a control-flow graph (CFG) derived from static anal-
ysis [1]. However, because CFI verifies each control-flow transfer during program
execution, it imposes high runtime overhead. More practical approaches, such as
Control Flow Locking (CFL) [6], Compact Control Flow Integrity and Random-
ization (CCFIR) [54], and CFI for COTS binaries [55], have other limitations.
CFL lazily verifies transfers, which greatly improves performance; however, their
technique requires statically-linked binaries, which severely limits its application.
CCFIR and CFI for COTS use binary rewriting to add verification checks at in-
direct control flow transfers. Although these approaches can be applied to shared
libraries, protections must be applied to all binary code to ensure the implied
security guarantees; any unprotected code is a potential attack target. Thus, the
user applying protections must both be aware of and able to protect all library
dependencies; this requirement can limit the applicability of these approaches.
Further, CCFIR relies on ASLR for all program code. The limitations of these
techniques prevent them from providing comprehensive defense solutions.
Host-based intrusion detection systems (IDS) use anomalous patterns of sys-
tem calls to identify attacks. These approaches rely on a learning phase [22,25,48]
or static binary analysis [26]. Unlike learning-based IDS, our work is based on
a model of what program states are possible in normal execution. Further, our
approach enforces a valid program state at each system call, rather than a valid
pattern of system calls. We note that mimicry attacks [33, 42] allow an attacker
6 E.R. Jacobson et al.

to subvert system call monitoring by ensuring that both the call stack of each
system call and the sequence of system calls made by a compromised program
appear normal to an IDS. However, mimicry attacks rely on code injection. While
it is theoretically possible to extend a mimicry attack to employ code reuse, this
form of attack does not appear in the wild; this would require an attacker to
construct a sequence of gadgets that both executes their attack and restores the
system to a state that appears valid at the next system call. However, gadget
discovery is a difficult problem. In practice, attackers who employ code reuse
are attempting to find the shortest route to a less restrictive environment [43].
Thus, we consider mimicry attacks beyond the scope of our work.

3 Conformant Program Execution

Our work is grounded in a model of conformant program execution. We create a

definition of program state and then define requirements on that program state
that must hold true at runtime. Program executions for which these requirements
hold true are called conformant executions. Any deviation from these require-
ments during program execution indicates a non-conformant execution. We first
describe our notation, then define a model of conformant program execution,
and finally discuss how code reuse attacks will be detected as non-conformant.

3.1 Notation

A program is a set of procedures, P = {p1 , . . . , pm }. I is the set of all possible

machine instructions; IP ⊆ I are the valid instructions for P . Each procedure pj
is a tuple, pj = (Ip j , entryp j , {exitp j }), where entryp j and exitp j are instructions
in Ip j that represent the entry point and the zero or more exit points for pj . To
represent valid interprocedural control flow in P , we define a call multigraph,
CM GP = (NP , EP ), where NP = P and each e = (ps , pt , i) ∈ EP is a control
flow transfer ps → pt at i where i ∈ Ip s is the instruction that effects the call.
We parse the program binary using control and dataflow analysis; these anal-
yses produce a call graph and control flow graph, which are used to populate the
data structures in our model. More details are presented in Section 4. The result-
ing CM GP may be incomplete due to unknown indirect control flow at i ∈ pj .
We address this incompleteness by making conservative assumptions about this
control flow, such as that any procedure may be the target of an indirect call. In
such cases, additional edges (pj , ∗, i) may be added to CM GP , where i ∈ pj and
the target of the control flow transfer at i is unknown. For increased accuracy,
CM GP could be augmented at runtime using dynamic analysis [46]; however,
there is an increase in overhead associated with such analysis.
We define an execution of P as execution(P ) = m1 , . . . , mn , where each
mi represents an instance of program state. Program state includes elements
of machine state that are affected by program execution, including registers
and memory. We represent two elements of interest, the program counter and
the callstack, with pc(m) and callstack(m). The callstack, C, is a sequence of
 Detecting Code Reuse Attacks 7

currently active stack frames, C = s0 , . . . , sn , where stop = sn is the frame

at the top of the stack associated with the currently active procedure.
We refer to a stack frame as a tuple s = (p, i, height), where p refers to the
procedure associated with the stack frame. i refers to the last executed instruc-
tion in the context represented by s. For the top stack frame, this instruction is
the program counter; for all other frames, this instruction is the call immediately
before the frame’s return address (Figure 1). height is the current height of the
stack frame. Stack frame height is based on the space needed to store saved
registers, procedure parameters, local variables, and a return address. Because
different parts of a procedure may require different amounts of local storage,
this height may vary for different parts of the procedure. Therefore the control
flow path leading to the current location within a procedure, which we denote
entryproc(s)  instr(s), affects the stack frame height. Our model does not rely
on other information, such as a saved frame pointer, because such information
may be omitted by optimizing compilers. We represent elements of each frame
with proc(s), instr(s), and height(s).
assembly callstack
proc(s) foo: ... ...
foo’s
instr(s) call bar stack
height(s) return address
... frame
bar’s
stack
... frame

Fig. 1. Relationship between the tuple s = (p, i, height) that represents the current
stack frame instance for procedure foo, the assembly code for foo, and the callstack.
Elements of the stack frame are represented with proc(s), instr(s), and height(s). Note
that the choice to associate the return address with the caller frame and not the callee
frame is arbitrary; this could be restated without loss of generality.

We further define Heights(i) to represent the set of valid heights possible from
all paths through the CFG from entryp j to i ∈ pj . If code modifies stack frame
height inside a loop, the height will depend on the number of loop iterations,
so it is possible that the size of the set is not finite. In such cases, we assume
that the stack frame height at these instructions is unknown. In principle, we
could analyze the instruction sequence and build a closed form model of such
behavior. In practice, this occurrence is exceedingly rare.

3.2 Conformant Program Execution

Our model of conformant program execution should be permissive enough to
allow a program to execute valid program instructions reached via valid control
flow, while restrictive enough to allow only these valid executions and detect
code reuse attacks. We define a program to have conformant execution based
on characteristics of two program state components: the program counter pc
8 E.R. Jacobson et al.

and the runtime callstack C. A program is conformant at a given time, i.e., a

particular machine state mi , if each component is individually valid and if both
components are consistent. A program has conformant program execution (CPE)
if the program is conformant for all program states in execution(P ).
To verify conformance for a particular program state during execution, we ex-
amine the program counter pc and the callstack C. The program counter should
contain the address of a valid instruction. An instruction j is valid if it exists
in the set of valid instructions for program P ; valid(i) : i ∈ IP . The program
counter is valid if it points to a valid instruction; valid(pc) : valid(instr(pc)).
This requirement eliminates the use of unaligned instructions that could provide
a rich selection of unintended instruction sequences to be used in an attack [8].
Further, should W ⊕X not be in place, this requirement precludes code injection
attacks, which rely on code located outside of valid code sections of the binary.
A callstack C = s0 , . . . , sn  is valid if a height requirement holds for each
frame in C and if a call requirement holds for each pair of adjacent frames.
valid(C) : ∀ s ∈ C : valid(s)

valid height(sk ) k=n
valid(sk ) :
valid height(sk ) ∧ valid call(sk ) 0≤k<n
A stack frame has a valid height h if that height is a member of the set of valid
heights Heights(i) for the corresponding instruction. For each pair of adjacent
stack frames to meet the call requirement, the control transfer represented by
each pair must correspond to an edge in the call multigraph.
valid height(sk ) : height(sk ) ∈ Heights(instr(sk ))
valid call(sk ) : (proc(sk ), proc(sk+1 ), instr(sk )) ∈ EP
Validating calls between procedures associated with consecutive stack frames
ensures that C represents a valid interprocedural control flow path through P .
Thus, we incorporate the goals of CFI [1] but perform verification with runtime
checks for an efficient implementation. Fratric also proposed a requirement on
callstack validity [24]. In his work, a valid callstack requires each stack frame to
have a valid return address and a valid call target, though the tool, ROPGuard,
is only able to implement the former because it relies on information often not
present in modern binaries. We discuss these technical differences in Section 4.
Finally, we define what is required for the program counter and the callstack
to be consistent. Given a program counter that points to a valid instruction and
a valid callstack, we need to ensure they are mutually consistent; that is, that
the callstack is valid for that program counter: consistent(i, C) : i = instr(top(C)).
These validity checks determine if a program has conformant execution:
valid(m) : valid(pc(m)) ∧ valid(callstack(m)) ∧ consistent(pc(m), callstack(m))
CPE(P ) : ∀ m ∈ execution(P ) : valid(m)

3.3 Code Reuse Attacks

We introduce a notation for code reuse attacks and discuss how our model detects
these attacks. A code reuse attack is comprised of a series of gadgets,
 Detecting Code Reuse Attacks 9

A = g0 , . . . , gn . Each gadget is a tuple: gk = (Ig k , entryg k , exitg k ), where entryg k

and exitg k are the instructions in Ig k that represent the entry point and exit point
for gk . The instructions that comprise each gadget are part of the set of possible
machine instructions I , but not necessarily part of IP [49].
Although we provide a broad definition of gadgets that spans several flavors
of code reuse attacks, there are several additional known characteristics of each
gadget. Such characteristics are often used when crafting code reuse attacks [13,
47]. The last instruction in a gadget, exitg k , must cause a control flow transfer to
the next gadget gk+1 . Gadgets gk and gk+1 are chosen such that exitg k transfers
control to entryg k+1 . In ROP, each exitg k is a return instruction and the address
of entryg k+1 is located at the top of the stack [49]; in JOP, exitg k is an indirect
jump instruction, where the target of the jump is entryg k+1 [7, 9].
Executing a sequence of gadgets interrupts the original execution of the pro-
gram. However, gadget execution occurs in the context of the program and may
use the original program stack. As a result, gadgets typically violate CPE in one
or more of three ways: executing invalid instructions, altering the stack, or not
following the original control flow of the program. To detect gadget execution,
and thus a code reuse attack, we must identify these violations.
First, gadgets may execute invalid instructions, either code that was injected
or misaligned instructions from the original program. We detect these invalid
instructions by examining the program counter: ∀ gk ∈ A : Ig k ⊆ IP .
Second, gadgets may include instructions that alter the stack. Let
C = s0 , . . . , sm  represent the callstack prior to the execution of the first gadget,
where sm represents the top of the stack. While a gadget gk executes,
Ck = s0 , . . . , sn , . . . , sq  where s0 , . . . , sn−1  represents what remains of the orig-
inal callstack and sn , . . . , sq  represents the effects of executing gadget code.
When g0 begins execution, sn = sm . If subsequent gadgets remove values from
the stack, s0 , . . . , sn−1  s0 , . . . , sm , where A B means that A is a contiguous
subsequence of B that either starts at the same initial state (i.e., s0 ) or is empty.
Otherwise, s0 , . . . , sn−1  = s0 , . . . , sm−1 .
Each gadget must maintain the correct height in the context of the stack
frame in which it executes; the expected height for the first instruction in each
gadget, entryg k ∈ Ip j , must match the height of sn . Otherwise, the height of
frame at the top of the stack will be observably incorrect at all instructions in
the gadget. This invariant must be maintained as subsequent gadgets execute.
We detect these invalid stack frames by verifying the height of each stack frame:
∀ i ∈ Ig k , gk ∈ A : height(entryg k  i) + height(sn ) = height(entryp j  i),
where Ig k ∈ Ip j
Third, gadgets may induce a control flow path that does not match that of the
original program. The instructions that comprise each gadget are selected from
an existing procedure; to maintain conformant execution, there must be a valid
control flow transfer from the procedure corresponding to the stack frame below
sn to the procedure that contains the gadget’s instructions. We detect these
invalid control flow paths by validating the path represented by the callstack:
∀ gk ∈ A : (proc(sn−1 ), pj , instr(sn−1 )) ∈ EP , where Ig k ∈ pj
10 E.R. Jacobson et al.

However, there are two ways in which an attack might be able to conform to
our model. First, there may be cases in which a loop allows multiple valid stack
heights at a particular instruction, as described in the previous section; in this
case, a gadget may be able to use an invalid stack height without detection, i.e.,
|Heights(instr(sk ))| > 1 ∧ height(sk ) ∈ Heights(instr(sk )) ∧
height(sk ) = height(entryproc(sk )  instr(sk ))
In our experience, such code is rare, and can be mitigated by unrolling or oth-
erwise modifying the loop such that |Heights(instr(sk ))| = 1. Second, an attack
might take advantage of our conservative handling of indirect control flow to
construct unintended paths through the binary via indirect procedure calls, i.e.,
(proc(sk−1 ), ∗, instr(sk−1 )) ∈ EP ∧ proc(sk−1 ) → proc(sk ) at instr(sk−1 )
Such an attack would have to make use of existing program code using whole
procedures at a time, because executing a sequence of procedure fragments would
result in one or more invalid stack frames. Such attacks must still override the
targets of one or more indirect calls to force the execution of the program down
the path desired by the attack. For example, an attack could begin by overwriting
a table of function pointers. However, this is made more complex by the fact that
it must not only overwrite the function pointer but also overwrite the data used
to set up the parameters used at the callsite. While this strategy seems unlikely,
as we use more sophisticated analysis to refine indirect call edges, we further
reduce the likelihood of circumventing our technique.

3.4 Observed Conformant Program Execution

In this section, we define observed conformant program execution (OCPE ), which
improves efficiency by verifying program states only at system call entries. Mon-
itoring at system call granularity offers two advantages. First, the system call
tracing interface provided by operating systems (e.g., PTRACE SYSCALL) cannot be
interrupted; therefore, we will receive notification of system call entry even if an
attack is in progress. Second, attacks must use the system call interface (e.g.,
exec) to modify the overall machine state; therefore, we will not miss the effects
of an attack by monitoring only at system calls. We define OCPE as follows:
is syscall(m) : callstack(m) = s0 , . . . , sn ; proc(sn ) invoked system call syscall(m)
observed(P ) = m ∈ execution(P ) | is syscall(m)
OCPE(P ) : ∀ m ∈ observed(P ) : valid(m)
OCPE makes the assumption that the effects of an attack will be visible in the
program state at the point a system call is executed. As discussed in Section 2,
current code reuse attacks are not constructed to evade OCPE [13,47]. We demon-
strate in Section 5 that OCPE is effective against these attacks. Furthermore, we
believe it will be difficult for future code reuse attacks to entirely hide their
effects from our stack model, because an attack would have to both hide its own
effects as well as forge a consistent program state. Even if a future attack could
circumvent OCPE in this way, our model of CPE would detect these deviations
from normal program execution. Therefore, OCPE is an effective optimization of
CPE that greatly improves performance while preserving the power of CPE .
 Detecting Code Reuse Attacks 11

4 Implementation
We have incorporated our model into a tool, ROPStop, that monitors a process
during its execution for observed conformant program execution. We use sev-
eral components from the Dyninst binary modification and analysis toolkit to
perform this runtime monitoring and verification [37], and ROPStop has been
implemented for both 32- and 64-bit x86/Linux. In total, ROPStop is approxi-
mately 3,000 lines of C++ on top of several toolkit libraries.

4.1 Process Monitoring

We perform runtime process monitoring using the ProcControlAPI process mon-
itoring and control component [40] of Dyninst. This library allows a tool process
(ROPStop) to manage one or more target processes using platform-independent
abstractions. ProcControlAPI includes the ability to control threads, set break-
points, request notifications (callbacks) at events, and read and write memory.
Using ProcControlAPI, we may either create a new process or attach to a
running process. We then register a callback function that is invoked before each
system call. Although ProcControlAPI already provides the capability to reg-
ister callback functions at various process events using the operating system’s
debug interface (ptrace), we extended the library to provide support for call-
backs at system call entry. ROPGuard [24] used an alternative approach that
instead operates on the library wrappers for system calls rather than directly on
the system call. However, this can be defeated by malicious code that directly
executes a trap instruction to invoke a system calls By using the debug interface,
we can guarantee that all system calls will trigger our callback.
ROPStop then parses the program binary and any library dependencies using
the ParseAPI control flow analysis library [39]. ParseAPI uses recursive traver-
sal parsing to construct a whole-program control flow graph [15, 52], including
sophisticated heuristics to recognize functions that are only reached by indirect
control flow and works in the absence of symbol table information [27, 45]. This
CFG provides both the call multigraph (CM GP ) required by our model and the
information necessary to identify each valid program instruction (IP ).
Once the process binary has been parsed, we continue its execution. If the
process creates additional threads or launches a new process, ProcControlAPI
will monitor these also. A monitored process is stopped at each system call
entry. ROPStop checks that the program has conformant execution; ROPStop
explicitly verifies the program counter and the callstack and implicitly verifies
consistency. If the process is conformant, execution is continued. If ROPStop
detects non-conformant program state, the process is terminated.

4.2 Instruction Validity

ROPStop first verifies that the program counter points to a valid instruction
in the original program, e.g., that instr(pc) ∈ IP . This inexpensive step ensures
that an attack may not make use of unaligned instructions. We identify the basic
12 E.R. Jacobson et al.

block in the CFG that contains this address and disassemble the block using the
InstructionAPI instruction disassembly library [38]. If we reach an instruction
that begins at the address in the program counter, we conclude the current
instruction is valid. Otherwise, we conclude the instruction is invalid.

4.3 Callstack Validity

Next, ROPStop gathers a full stackwalk using the StackwalkerAPI library [41].
A full stackwalk must be gathered at each system call to ensure that no malicious
stack modifications have occurred since the last validity check; this step must
be completed even if two system calls occur within the same function or a single
loop. ROPStop uses StackwalkerAPI to walk the stack one frame at a time and
validate each frame before continuing the stackwalk. StackwalkerAPI represents
stack frames as pairs (r, sp), where r is a location in the program and sp is
the value of the stack pointer in that location. Given an input frame (ri , spi ),
StackwalkerAPI calculates the expected previous frame (ri−1 , si−1 ).
Given a valid stack frame sj and an expected previous frame sj−1 from Stack-
walkerAPI, we validate it as follows. We verify the height of the stack frame
sj by validating the return address of sj−1 , rj−1 . We define a return address to
be valid if the instruction at this address is immediately preceded by a call in-
struction; this definition is also used by the ROPGuard tool [24]. ROPStop uses
InstructionAPI to locate the instruction prior to the return address and identify
its type. If sj−1 ’s return address is valid, we conclude that the height of sj is
valid, e.g., that height(sj ) ∈ Heights(instr(sj )).
This validation allows ROPStop to verify the second necessary condition for
a valid stack frame: that there exists a valid control flow transfer between the
caller (sj−1 ) and the current, callee frame (sj ). We check the CFG constructed
by ParseAPI to verify that there is a valid call edge from the caller to the callee;
this edge must originate at the call instruction found in the previous step. This
verifies that (proc(sj−1 ), proc(sj ), instr(sj−1 )) ∈ EP .
Performing a stackwalk is not always an easy task. The debugging information
that describes stack frames (e.g., DWARF call frame information) is frequently
missing; for example, commercial binaries frequently omit this information due
to concerns about reverse engineering. Even if this debug information is present
it is frequently incomplete or incorrect; for example, compilers often omit stack-
walking information for automatically generated code.
In light of these challenges, we extended StackwalkerAPI to use dataflow
analysis to identify stack heights. This analysis begins at the entry to a function
and tracks the effects of all instructions that modify the stack heights; the result
is the set of possible stack heights for each instruction in the function. This robust
analysis enables an accurate stackwalk in the absence of debugging information.
If StackwalkerAPI reaches the bottom of the stack and does not encounter an
invalid stack frame, then we conclude that the callstack is valid. Otherwise, we
have found non-conformant program state, and the process is terminated.
 Detecting Code Reuse Attacks 13

5 Evaluation
ROPStop provides protection against code reuse attacks while identifying no
false positives. We verified these characteristics with the following experiments.
First, we tested ROPStop against code reuse attacks, as well as a conventional
stack smashing attack, and show that ROPStop detects each of these attacks.
Second, we tested ROPStop against a set of conventional binaries, and show that
ROPStop results in no false positives while imposing overhead of only 5.3% on
SPEC benchmarks and 6.3% on an Apache HTTP Server.
All evaluation was conducted on a 2.27GHz quad-core Intel Xeon with 6GB
RAM, running RHEL Server 6.3 (kernel 2.6.32). All exploits were run inside
VirtualBox 4.2.0 virtual machines, running Debian 5.0.10 (2.6.32) or Ubuntu
10.04 (2.6.26); see Table 1. SPEC and Apache were run directly on the host.
Table 1. Details about each exploit and results for ROPStop’s detection of the attack.
All attacks were detected because of invalid stack frame heights; the exploit character-
istic that lead to the observed invalid program state is also provided.

Name OS Exploit Source Detected Why Invalid

17286a (ROP) Ubuntu 10.04 sickness [50] ✓ Overwritten return address
17286b (ROP) Ubuntu 10.04 sickness [50] ✓ Overwritten return address
Rsync (ROP) Debian 5.0.10 Schwartz et al. [47] ✓ Overwritten return address
Bletsch (JOP) Debian 5.0.10 Bletsch et al. [7] ✓ Gadget executing
Stack-smash Debian 5.0.10 Aleph One [3] ✓ Overwritten return address

We began by testing ROPStop against known attacks; we summarize each

attack in Table 1. The 17286 ROP exploits are from http://www.exploit-db.com.
Rsync is a ROP exploit generated by the Q tool [47]. We acquired the code
necessary for this exploit from the authors; additional exploits from this work
were unavailable. Bletsch is a JOP attack [7]. Finally, we include a canonical
buffer-overflow attack, Stack-smash, to demonstrate ROPStop’s ability to detect
these attacks also. We used information provided in the original documentation
to create the vulnerable program as well as the input necessary for each exploit.
The results of testing ROPStop against these attacks are shown in Table 1.
We were successful in detecting each attack. In each case, callstack verification
failed; the height of a stack frame was found to be invalid because the return
address in the expected caller frame did not follow a call instruction.
Next, we used the SPEC CPU2006 benchmark suite and an Apache HTTP
Server (version 2.4.6) [5] to provide a control group of conventional binaries.
We applied ROPStop to the execution of these binaries to both detect any
false positives and determine how much overhead ROPStop incurs. We selected
SPEC because the execution of each benchmark is well understood and as CPU
intensive programs, any overhead imposed by ROPStop would not be hidden by
I/O. Each benchmark was run three times with the reference inputs; we report
the mean of these runs. We measured end-to-end times, which includes the time
required to generate our model as well as the runtime of the program.
ROPStop generated no false positives when run on the SPEC CPU2006 bench-
mark suite. The overhead imposed by ROPStop is shown in Figure 2; on average,
14 E.R. Jacobson et al.

20 %

10 %

0%
perlbench

libquantum
hmmer

omnetpp
bzip2

zeusmp

leslie3d

sphinx3
mcf

cactusADM

sjeng
milc

gromacs

namd
gobmk
soplex

h264ref

lbm
gamess

povray

gemsFDTD

tonto

wrf
bwaves

astar

mean
Fig. 2. Overhead results for SPEC CPU2006 benchmarks under ROPStop; mean rep-
resents the geometric mean of all overhead values. We omit four benchmarks, gcc,
calculix, dealII, xalancbmk; we were unable to successfully run these unmonitored.

ROPStop imposes 5.3% overhead. In most cases ROPStop imposes under 3%

overhead; our highest overhead is 19.1% for tonto.

Table 2. Full results for SPEC CPU2006 benchmarks under ROPStop. The system call
rate is reported as system calls per second based on unmonitored runtimes; components
of overhead are reported as percentages of total overhead imposed (summing to 100%).

Overhead Breakdown
Benchmark System Call Rate % Overhead % Instruction % Callstack % Context
(calls/second) Imposed Validity Validity Switching
perlbench 167.8 9.6 0.2 50.7 49.1
bzip2 2.0 0.8 0.0 43.8 56.2
bwaves 3.3 1.4 0.0 31.7 68.2
gamess 29.5 2.4 0.1 59.0 40.9
mcf 3.4 1.9 0.0 51.4 48.5
milc 25.5 5.7 0.1 23.5 76.4
zeusmp 0.2 0.7 0.0 54.2 45.7
gromacs 1.5 0.6 0.0 45.1 54.9
cactusADM 7.6 1.0 0.1 52.0 47.9
leslie3d 31.4 9.2 0.1 14.2 85.7
namd 3.1 0.9 0.0 61.6 38.4
gobmk 14.0 2.2 0.1 43.6 56.4
soplex 241.5 18.1 0.2 50.8 49.1
povray 156.2 18.1 0.1 53.3 46.6
hmmer 18.6 2.6 0.1 38.8 61.1
sjeng 4.8 1.3 0.0 40.5 59.5
GemsFDTD 88.7 7.3 0.2 40.9 59.0
libquantum 0.3 0.7 0.0 50.2 49.8
h264ref 5.1 1.3 0.0 28.9 71.0
tonto 119.6 19.1 0.1 41.2 58.7
lbm 1.4 3.4 0.0 15.5 84.5
omnetpp 3.7 8.8 0.0 12.7 87.3
astar 7.2 1.3 0.1 56.7 43.3
wrf 53.2 15.7 0.0 13.4 86.6
sphinx3 18.6 2.4 0.1 38.1 61.8

The overhead imposed by ROPStop is dependent on the frequency of system

calls as well as the height of the stack. ROPStop is a separate process, rather than
in the same address space as the monitored application. Validating state at each
system call requires at least two context switches; these context switches are more
expensive than the validation checks ROPStop performs. Thus, benchmarks that
make frequent use of system calls or, to a lesser extent, have deep call stacks,
Another Random Scribd Document
with Unrelated Content
'Alya, Djebel el 49, 50, 52, 60.

Amanus, Berg 324.

Amerikanische Expedition 72, 162, 266, 286;

Universität in Beirut 201, 222.

'Ammān 13, 34, 54, 157;

Torweg A. 27;
Theat. A. 25.

'Anazeh, Stamm 23, 24, 61, 112, 122, 147, 166, 190.

'Antara, Gedichte des 57, 63.

Antilibanon 104, 116, 153, 158, 162.

Antiochien 169, 309, 310, 312, 323, 324, A. 306, A. 307;

Beschreibung der Überreste 312 f.;
Sarkophag in der Serāya A. 327;
Getreidemarkt A. 311;
Haupt einer Sphinx A. 314.

Apamea 232, 234, 315.

Apostelbrunnen 7.

Araber 14, 16, 22, 35, 54, 57, 90, 99, 103, 119;
Dichtung 57-59;
Feindschaft zwischen den Stämmen 61, 62;
Gastfreundschaft 31 f., 36, 52-54;
Sitten 35, 36, 39, 46, 64;
Marduf reitend A. 61.

Arabische Bauern A. 203;

Inschriften 117.
'Areh, Dorf 77, 81.

Armenier 135, 316, 322.

Armenische Frage, die 316, 317, 322.

Asad Beg 165.

Asbā'i, Mustafa el 143.

'Asī-Sumpf 234.

Assassinen, Sekte 189.

Athen, Akropolis 158.

At Tabari, Geschichte des 75.

'Awād, Araber 116, 117, 118, 122.

'Awais, Jūsef el 154.

'Azam Zadēh, Familie zu Hamāh 215, 216.

Azrak, Kal'at el 80.

Ba'albek 153, 154, 158, 165, 209;

Tempel der Sonne 158; A. 159;
der große Hof A. 161;
Säulen des Sonnentempels A. 163;
Brunnen im großen Hof A. 173;
Fragment eines Gebälkes A. 174;
Basilika des Konstantin A. 175;
Steinlager A. 177;
Rās ul 'Ain A. 179;
Tempel des Jupiter A. 167;
 Kapitäle A. 171.

Bāb el Hawah 286; A. 289.

Bābiska, Dorf 289.

Babylon 233.

Bagdad 61, 103;

Eisenbahn 252.

Baghrās, Kastell 324.

Bailānpaß 324.

Baitokaikē 209.

Bākirha, Ruinen 268, 289;

Tempelruine A. 291.

Balad, Scheich el 55.

Baldachingrab in Barād 280; A. 279.

Barād 276;
Turm im Westen der Stadt A. 277;
Baldachingrab A. 279.

Barada, Suk Wādi A. 155.

Barada, Wādi 144, 153.

Barāzi, Familie zu Hamāh 215.

Barāzi, Mustafa Pascha el 142, 227.

Bārischa, Djebel 286, 289, 290, 294.

Baschan 84.

Bāsufān, Dorf 281, 282, 284, 286;

kurdisches Mädchen A. 285.

Bathaniyyeh 126.

Bauern, syrische 54.

Bawābet Ullah, Damaskus 128.

Bedr, Schlacht von 59.

Beduinen 10, 22, 53, 54, 198, 249.

Beha'i, Sekte der 144, 184.

Beida, Chirbet el 118.

Beida, Kal'at el 32, 119, A. 119, A. 120;

Gefängnistür A. 121;
Simse A. 123.

Beida, weißes Land 103, 116.

Beirut 95, 201, 222, 255.

Belkaaraber 23, 25, 54; A. 32, A. 47.

Belkaebene 18, 22.

Beni Atijjeh 231.

Beni Awadjeh, Araberst. 61.

Beni Hassan, Stamm 61, 64, 92.

Beni Sachr, Stamm 23, 32, 35, 37, 39, 84.

Beni Scha'alān 24.

Bergaraber 71.

Bienenkorbdorf 250, A. 251.

Biridjik, Eisenbahn in 252.

Birket Umm el 'Amūd 24.

Bizzos, Grabmal 244, 245, 267, 268, A. 244.

Bkei'a, Ebene 191.

Blunts, Reisende 80.

Bologna 245.

Bosra 20, 69, 77.

Bosra el Harīr 221.

Bosra eski Scham A. 93.

Brāk, Dorf 126.

Brünnow 32 Anm.

Buchalih 119.

Burdj el Kās 272.

Burdjkeh, Dorf 270, 271.

Burdj Heida 282.

Burenkrieg 220.

Busān, Wādi 102.

Butler, Mr. 71, 235, 266, 266 Anm., 267 Anm., 272 Anm., 275 Anm.

Calycadnus, Fluß 232.

Cassius, Berg 317, 323.

Chabbaz, Hanna 187.

Chālid Beg 'Azam, Haus das, in Hamāh 219.

Chamberlain, Mr. 100.

Charāneh, Ruinen von 52.

Chaulik 317.

Chirāb esch Schems 272, 275, A. 273;

Skulpturen im Innern eines Grabes A. 275.

Chirbeh 119.

Chirbet Hāß, Dorf 236;

Oberschwelle A. 239.

Chittāb 108, 112, 126.

Christusdorn 11.

Chudr, Gefangener 188.

Chureibet es Suk, Tempel und Mausoleum 26 bis 29;
Tempel A. 29;
Mausoleum A. 31.

Cromer, Lord 55, 100, 221.

Cufische Inschriften 76, 117.

Da'dja, Stamm 22, 25, 38, 50, 61, 65, 92.

Damaskus 73, 77, 83, 92, 95, 100, 126, 127, 128, 129, 130, 133;
Freitag in 147;
Große Moschee 136, 144, 145;
Große Moschee, Hof der A. 147;
und Dächer vom Fort aus A. 131;
Kornmarkt A. 135;
vor den Toren von A. 151;
Wasserverkäufer A. 152;
Verkäufer von Zuckerwaren A. 145.

Dāna, Dorf 286;

Grab zu A. 287;
Pyramidengrab in 245;
Grabmal A. 249.

Danādischeh, Familie 200.

Daphne, der Weg nach 314, A. 313.

Dār Kita 275.

Decimus, Centurio der Legion des Flavian 209.

Dehes 286, 293.

Deir es Sleb 212.

Deiret Azzeh 286.

Deir Sambil 241.

Dera'a, Höhlendorf 104.

Derwisch, Soldat 162, 165.

Deutschland, Bagdadbahn 252.

Dīn, Scheich ed 55.

Djad'allah 65, 80.

Djebeliyyeh 71, 92.

Djerūd, Oase von 147, 148.

Djerūdi, der Brigant, s. Mohammed Pascha, Scheich von Djerūd.

Djisr el Wād, Brücke 202.

Djof 80.

Domaszewski 32 Anm.

Drekisch, Dorf 204.

Dreschplatz in Karyatein A. 148.

Drusāra 91.

Drusen 37, 41, 49, 55, 63, 66, 72, 74, 82, 87, 98, 99, 118, 298, 300;
Sitten 124;
Streitigkeiten mit den Suchūr 83-101;
eine Gruppe A. 83.
Drusische Pflüger A. 91.

Druz, Djebel 60, 65, 66, 74, 75, 81, 90, 104, 111, 118, 157, 158.

Drusisches Gebirge 20, 41, 60, 65, 74, 90, 96.

Dussaud, Mr. 71, 80, 98, 117, 120, 169.

Edsch Dscheida 104.

Effendi, Derwisch, Afghane 219.

Effendi, Jusef 81, 82.

Effendim 212.

Eisenbahn nach Mekka 13, 165;

Rayak-Hamah 252;
Bagdad 252;
französische 214, 252.

Eisernes Tor, Antiochien 313.

El, Gott 118, 119.

El 'Ablā 116, 117.

El Adjlād 104.

El Bārah, Dorf 236, 237, 238, 264, 300;

ein Haus in A. 237;
Fries A. 239.

El Chudr, Grab von 89, 91.

El Churbeh, Türbalken A. 101.

El Hayyāt, Moschee in Hamāh 222.

El Mugharāh, Dorf 246.

El Muwaggar 50, 121;

Kapitäl A. 51, 52, 53.

Emesa, Römerstadt 181.

Englisch-japanisches Bündnis 221.

Epiphania, Festung 213.

Ethreh 80.

Euphrat 259.

Euting, Reisender 80.

Fāfertīn, Dorf 263, 271.

Fāiz, Neffe des Mohammed en Nassār 102, 104, 125, 126.

Faīz el Atrasch, Scheich von Kreyeh 73, 77.

Faiz', Talāl ul 23, 24.

Fāris, Maultiertreiber 260, 261, 262, 293, 300.

Fāris, Habīb 18, 21, 324.

Fayyād Agha von Karyatein 147.

Fedhāmeh 104.
Feiertag, ein, im Orient A. 185.

Fellahīn-Bank 55.

Fendi, Führer 73.

Fīda Abu'l 21.

Frankreich, Bagdadbahn 252.

Gablān, Araber 38, 42, 47, 48, 49, 50, 52, 53, 56, 57, 60, 61, 63, 64,
66, 69, 70, 324, A. 57.

Garīz, der, Seleucia 321, 322, A. 319;

unterer Teil des A. 325.

Gethsemane 4.

Gharz, Ghādir el 116, 118.

Gharz, Wādi el 119.

Ghassaniden Forts 32, 50, 121.

Ghawārny 40.

Ghazu 63, 76.

Ghiāth 92, 104, 107, 112, 115, 125.

Ghor, das 10, 16, 40;

Zug durch das, A. 12.

Giour Dāgh 280, 290.

Gischgāsch, Scheich von Umm Ruweik, 102, 104, 106, 107, 112,
115.

Gottesherz 111.

Grabeskirche, heilige, in Jerusalem A. 2.

Griechen 134, 135.

Griechische Inschriften 117, 233, 244, 245, 271, 276.

Habīb, Maultiertreiber 3, 14, 69, 107, 119, 162, 166, 260.

Habrān, Torweg A. 97;

kurdisches Mak'ad A. 99.

Haddjbahn 21, 33, 42.

Haddjstraße 231, A. 58.

Hadūdmadūd 283.

Haida, Dr. 165.

Haifa 18.

Haīl, Stadt 42, 46, 80.

Halakah, Djebel 286.

Hamad 103, 107, 112, 119.

Hamāh 162, 166;

Beschreibung 213-215;
Bewohner 215-223;
Römerstraße 211, 212;
 Moschee 215;
Kubbeh A. 215;
Kapitäl A. 221, A. 223, A. 233;
Na'oura A. 213;
Tekyah Killānijjeh 219, A. 217.

Hamath, Festung 213.

Hamdān, Sohn der Weisheit 115.

Hamūd, Gablāns Vater 49.

Hamūd von Sueda 77, 89, 90.

Hanelos 119.

Hārim 298, 300;

Burg 300, A. 299.

Hārith, Ibn el 59.

Harra, schwarzes Land 103.

Harūn er Raschid 205.

Haseneh 66, 166, 190;

Kamele der A. 67.

Hāß, Djebel el 250.

Hassan Beg Rā'i 178.

Hassaniyyeh, Stamm 22, 61, 66, 84.

Haurān, Gebirge 17, 55, 66, 71, 72, 78, 80, 82, 103, 120, 121, 126,
298.
Hayat, Kalybeh 126;
Haus des Scheich A. 127.

Heddjasbahn 133.

Helbān, Dorf 250.

Hermon 116, 153.

Heschbān 16.

Hind, das Land 189.

Hiran 121.

Hīt, Dorf 126.

Hittiter 166, 169, 170, 214.

Hober, Dorf 250.

Höhlen Namrūds 28-33.

Höhlendörfer 104.

Homs 104, 162, 169, 170, 173, 174;

die Einwohner 173, 174, 182-187;
Häuser 178, 181;
der Orontesanger
Mardj ul 'Asi 181;
Kastell 177;
ein Feiertag im Orient A. 185;
Straße in A. 187.

Homs, See 169.

Homsi, Nicola 257.

Howeitāt, Araberstamm 61, 231.

Hurmul, Turm von 165, 166.

Husn es Suleimān 206;

Tempel A. 207;
Tempel, Nordtor A. 209.

Husn, Kal'at el 188, 192, 195, 197, 200;

griechisches Kloster 202; A. 193;
Inneres der Festung A. 195;
innerer Festungsgürtel A. 199;
Bankettsaal 198, A. 198;
der Schwarze Turm 192.

Ibrahim, Armenier, 317, 318, 321.

Ibrahim, Maultiertreiber 3.

Ibrahim Pascha 34, 173.

Iliān, Milhēm 81, 82, 91, 92.

Imtain 65, 77.

'Isa, Fellāh ul 49, 50, 53, 54, 55, 60, 65, 72, 80, 158, A. 49.

Islam 220, 221.

Ismailiten 188, 211, 212, 225.

'Isset Pascha 144, 205.

Jadūdeh, Felsengräber 24.

Jaffa 7.

Jahya Beg el Atrasch 77, 298.

Jakit Ades 262.

Japanische Krieg 98 bis 101, 150, 178.

Jemen, Aufstand 13, 14, 78, 121, 221, 231, 255, 256.

Jericho 10.

Jerusalem 4, 95, 154, 256;

Klagemauer in A. 17;
Moschee Omar A. 1;
heilige Grabeskirche A. 2;
Straße in A. 3;
Stephanstor in A. 4.

Jezīdi, Sekte 272;

Glaube der 268, 269, 282, 283, 284.

Jordan, Tal, das 10, 22.

Jordanbrücke 12, 13, 14, A. 13.

Judäa, Wüste von 9.

Juden aus Buchara A. 18.

Jūnis, Scheich von El Bārah 238, 241, 242, 243, 246, A. 242, 327.

Jusef, Führer 22, 24, 96, 98, 101.

Kabul 219.
Kabuseh 322.

Kadesch 169, 170.

Kāf 80.

Kaffee, Gebräuche 19, 20;

am Wegrande A. 191.

Kais, Imr ul 47, 56, 58, 63.

Kalam, Muschkin 143, A. 143.

Kalb Lōzeh, Kirche von 293, 297, 299, A. 295.

Kalkutta 219.

Kalōteh, Dorf 272, 275;

Kirche 276;
Kapitäl A. 276.

Kamele, Tränken der A. 71.

Kāmu'a Hurmul 165, A. 183.

Kanawāt 104, 158;

Basilika A. 105;
Tempel A. 107;
Tor der Basilika A. 109;
Mauern von A. 103.

Kantarah 112.

Karyatein, Oase von 147;

Dreschplatz in A. 148.
Kasr el 'Alya 50.

Kasr el Banāt 246, A. 247.

Kastal 32, 121.

Kāturā, Grabmal A. 272.

Kbēs, Monsieur 214, 215, 216, 222, 223.

Kbeschīn, Dorf 263.

Kefr 'Abīd, Dorf 250, 251.

Kefr Anbīl 235, 236.

Kefr Lāb 282.

Kefr Nebu 280.

Keifār 280.

Kerak 198, 199.

Khayyām, Omar 22.

Kiāzim Pascha, Vāli von Aleppo 255-259.

Kieperts Karte 162, 250, 263.

Killani, Familie zu Hamāh 215, 219, 227.

Killiz 252.

Klagemauer in Jerusalem A. 17.

Konia 162, 260, 261.

Konstantin, Münzen 26.

Konstantinopel 46, 99, 144, 166, 205.

Koran, Erzählungen vom 225, 226.

Kreta, Muselmänner von 146.

Kreuzfahrer 199, 202.

Kreyeh 74, 77, A. 89.

Ksedjba, Dorf 286.

Kseir 166, 169.

Kubbeh in der Moschee zu Hamāh A. 215.

Kubbet el Chazneh 136, 143, A. 137.

Kuda'a, Stamm 134.

Kuleib 79.

Kulthum, Ibn, Gedicht des 134.

Kurden 99, 263, 264, 281, 285.

Kurutul, Kloster oberhalb Jerichos A. 11.

Kurunfuleh 154, 157.

Kuseir es Sahl 26.

Kutaila, Klagegesang von 59.

Kuwēk, Fluß 250.

Kweit 46, 256.

Kymet, eine kurdische Frau 322, 323.

Lager in der Nähe des Toten Meeres A. 23;

Abbrechen des A. 73.

Lahiteh 126.

Lampe in Rifa't Aghas Sammlung A. 313.

Laodicea ad Orontem 169, 170.

Larissa, Stadt 227.

Lava 116, 119, 122.

Lebīd, Gedichte des 57, 58.

Lebweh 162, 165.

Ledschastraße 126.

Libanon 157, 158, 162, 169;

Zedern des A. 182.

Littmann, Dr. 71, 73, 117 Anm.

Lütticke, deutscher Konsul in Damaskus 129.

Lysicrates, Denkmal des 286.

Ma'alūla, Kloster von 202.

Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.

Let us accompany you on the journey of exploring knowledge and

personal growth!

textbookfull.com