Smashing the Stack in 2011 | My
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Memory Layout and Access Chapter Four
Memory Layout and Access Chapter Four Chapter One discussed the basic format for data in memory. Chapter Three covered how a computer system physically organizes that data. This chapter discusses how the 80x86 CPUs access data in memory. 4.0 Chapter Overview This chapter forms an important bridge between sections one and two (Machine Organization and Basic Assembly Language, respectively). From the point of view of machine organization, this chapter discusses memory addressing, memory organization, CPU addressing modes, and data representation in memory. From the assembly language programming point of view, this chapter discusses the 80x86 register sets, the 80x86 mem- ory addressing modes, and composite data types. This is a pivotal chapter. If you do not understand the material in this chapter, you will have difficulty understanding the chap- ters that follow. Therefore, you should study this chapter carefully before proceeding. This chapter begins by discussing the registers on the 80x86 processors. These proces- sors provide a set of general purpose registers, segment registers, and some special pur- pose registers. Certain members of the family provide additional registers, although typical application do not use them. After presenting the registers, this chapter describes memory organization and seg- mentation on the 80x86. Segmentation is a difficult concept to many beginning 80x86 assembly language programmers. Indeed, this text tends to avoid using segmented addressing throughout the introductory chapters. Nevertheless, segmentation is a power- ful concept that you must become comfortable with if you intend to write non-trivial 80x86 programs. 80x86 memory addressing modes are, perhaps, the most important topic in this chap- ter. -
Advanced Practical Programming for Scientists
Advanced practical Programming for Scientists Thorsten Koch Zuse Institute Berlin TU Berlin SS2017 The Zen of Python, by Tim Peters (part 1) ▶︎ Beautiful is better than ugly. ▶︎ Explicit is better than implicit. ▶︎ Simple is better than complex. ▶︎ Complex is better than complicated. ▶︎ Flat is better than nested. ▶︎ Sparse is better than dense. ▶︎ Readability counts. ▶︎ Special cases aren't special enough to break the rules. ▶︎ Although practicality beats purity. ▶︎ Errors should never pass silently. ▶︎ Unless explicitly silenced. ▶︎ In the face of ambiguity, refuse the temptation to guess. Advanced Programming 78 Ex1 again • Remember: store the data and compute the geometric mean on this stored data. • If it is not obvious how to compile your program, add a REAME file or a comment at the beginning • It should run as ex1 filenname • If you need to start something (python, python3, ...) provide an executable script named ex1 which calls your program, e.g. #/bin/bash python3 ex1.py $1 • Compare the number of valid values. If you have a lower number, you are missing something. If you have a higher number, send me the wrong line I am missing. File: ex1-100.dat with 100001235 lines Valid values Loc0: 50004466 with GeoMean: 36.781736 Valid values Loc1: 49994581 with GeoMean: 36.782583 Advanced Programming 79 Exercise 1: File Format (more detail) Each line should consists of • a sequence-number, • a location (1 or 2), and • a floating point value > 0. Empty lines are allowed. Comments can start a ”#”. Anything including and after “#” on a line should be ignored. -
Virtual Memory Basics
Operating Systems Virtual Memory Basics Peter Lipp, Daniel Gruss 2021-03-04 Table of contents 1. Address Translation First Idea: Base and Bound Segmentation Simple Paging Multi-level Paging 2. Address Translation on x86 processors Address Translation pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data enables number of advanced features programmers perspective: Address Translation OS in control of address translation pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data programmers perspective: Address Translation OS in control of address translation enables number of advanced features pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data Address Translation OS in control of address translation enables number of advanced features programmers perspective: transparent: it is not necessary to know how memory reference is converted to data Address Translation OS in control of address translation enables number of advanced features programmers perspective: pointers point to objects etc. Address Translation OS in control of address translation enables number of advanced features programmers perspective: pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data Address Translation - Idea / Overview Shared libraries, interprocess communication Multiple regions for dynamic allocation -
Damn Vulnerable Linux CCERT-PUBDOC-2007-04-190
Damn Vulnerable Linux CCERT-PUBDOC-2007-04-190 Sigurnosni problemi u računalnim programima i operativnim sustavima područje je na kojem CARNet CERT kontinuirano radi. Rezultat toga rada ovaj je dokument, koji je nastao suradnjom CARNet CERT-a i LS&S-a, a za koji se nadamo se da će Vam koristiti u poboljšanju sigurnosti Vašeg sustava. CARNet CERT, www.cert.hr - nacionalno središte za sigurnost računalnih mreža i sustava. LS&S, www.lss.hr - laboratorij za sustave i signale pri Zavodu za elektroničke sustave i obradbu informacija Fakulteta elektrotehnike i računarstva Sveučilišta u Zagrebu. Ovaj dokument predstavlja vlasništvo CARNet-a (CARNet CERT-a). Namijenjen je za javnu objavu, njime se može svatko koristiti, na njega se pozivati, ali samo u originalnom obliku, bez ikakvih izmjena, uz obavezno navođenje izvora podataka. Korištenje ovog dokumenta protivno gornjim navodima, povreda je autorskih prava CARNet-a, sukladno Zakonu o autorskim pravima. Počinitelj takve aktivnosti podliježe kaznenoj odgovornosti koja je regulirana Kaznenim zakonom RH. Revizija v1.0 CCERT-PUBDOC-2007-04-190 Stranica 2 / 15 Sadržaj 1 UVOD .............................................................................................................................................. 4 2 OPĆENITO O DAMN VULNERABLE LINUX SUSTAVU .................................................................................. 5 2.1 SVRHA SUSTAVA..................................................................................................................................... 5 2.2 -
Debian \ Amber \ Arco-Debian \ Arc-Live \ Aslinux \ Beatrix
Debian \ Amber \ Arco-Debian \ Arc-Live \ ASLinux \ BeatriX \ BlackRhino \ BlankON \ Bluewall \ BOSS \ Canaima \ Clonezilla Live \ Conducit \ Corel \ Xandros \ DeadCD \ Olive \ DeMuDi \ \ 64Studio (64 Studio) \ DoudouLinux \ DRBL \ Elive \ Epidemic \ Estrella Roja \ Euronode \ GALPon MiniNo \ Gibraltar \ GNUGuitarINUX \ gnuLiNex \ \ Lihuen \ grml \ Guadalinex \ Impi \ Inquisitor \ Linux Mint Debian \ LliureX \ K-DEMar \ kademar \ Knoppix \ \ B2D \ \ Bioknoppix \ \ Damn Small Linux \ \ \ Hikarunix \ \ \ DSL-N \ \ \ Damn Vulnerable Linux \ \ Danix \ \ Feather \ \ INSERT \ \ Joatha \ \ Kaella \ \ Kanotix \ \ \ Auditor Security Linux \ \ \ Backtrack \ \ \ Parsix \ \ Kurumin \ \ \ Dizinha \ \ \ \ NeoDizinha \ \ \ \ Patinho Faminto \ \ \ Kalango \ \ \ Poseidon \ \ MAX \ \ Medialinux \ \ Mediainlinux \ \ ArtistX \ \ Morphix \ \ \ Aquamorph \ \ \ Dreamlinux \ \ \ Hiwix \ \ \ Hiweed \ \ \ \ Deepin \ \ \ ZoneCD \ \ Musix \ \ ParallelKnoppix \ \ Quantian \ \ Shabdix \ \ Symphony OS \ \ Whoppix \ \ WHAX \ LEAF \ Libranet \ Librassoc \ Lindows \ Linspire \ \ Freespire \ Liquid Lemur \ Matriux \ MEPIS \ SimplyMEPIS \ \ antiX \ \ \ Swift \ Metamorphose \ miniwoody \ Bonzai \ MoLinux \ \ Tirwal \ NepaLinux \ Nova \ Omoikane (Arma) \ OpenMediaVault \ OS2005 \ Maemo \ Meego Harmattan \ PelicanHPC \ Progeny \ Progress \ Proxmox \ PureOS \ Red Ribbon \ Resulinux \ Rxart \ SalineOS \ Semplice \ sidux \ aptosid \ \ siduction \ Skolelinux \ Snowlinux \ srvRX live \ Storm \ Tails \ ThinClientOS \ Trisquel \ Tuquito \ Ubuntu \ \ A/V \ \ AV \ \ Airinux \ \ Arabian -
Memory Management
Memory management Virtual address space ● Each process in a multi-tasking OS runs in its own memory sandbox called the virtual address space. ● In 32-bit mode this is a 4GB block of memory addresses. ● These virtual addresses are mapped to physical memory by page tables, which are maintained by the operating system kernel and consulted by the processor. ● Each process has its own set of page tables. ● Once virtual addresses are enabled, they apply to all software running in the machine, including the kernel itself. ● Thus a portion of the virtual address space must be reserved to the kernel Kernel and user space ● Kernel might not use 1 GB much physical memory. ● It has that portion of address space available to map whatever physical memory it wishes. ● Kernel space is flagged in the page tables as exclusive to privileged code (ring 2 or lower), hence a page fault is triggered if user-mode programs try to touch it. ● In Linux, kernel space is constantly present and maps the same physical memory in all processes. ● Kernel code and data are always addressable, ready to handle interrupts or system calls at any time. ● By contrast, the mapping for the user-mode portion of the address space changes whenever a process switch happens Kernel virtual address space ● Kernel address space is the area above CONFIG_PAGE_OFFSET. ● For 32-bit, this is configurable at kernel build time. The kernel can be given a different amount of address space as desired. ● Two kinds of addresses in kernel virtual address space – Kernel logical address – Kernel virtual address Kernel logical address ● Allocated with kmalloc() ● Holds all the kernel data structures ● Can never be swapped out ● Virtual addresses are a fixed offset from their physical addresses. -
UNIVERSITY of CAMBRIDGE Computer Laboratory
UNIVERSITY OF CAMBRIDGE Computer Laboratory Computer Science Tripos Part Ib Compiler Construction http://www.cl.cam.ac.uk/Teaching/1112/CompConstr/ David J Greaves [email protected] 2011–2012 (Lent Term) Notes and slides: thanks due to Prof Alan Mycroft and his predecessors. Summary The first part of this course covers the design of the various parts of a fairly basic compiler for a pretty minimal language. The second part of the course considers various language features and concepts common to many programming languages, together with an outline of the kind of run-time data structures and operations they require. The course is intended to study compilation of a range of languages and accordingly syntax for example constructs will be taken from various languages (with the intention that the particular choice of syntax is reasonably clear). The target language of a compiler is generally machine code for some processor; this course will only use instructions common (modulo spelling) to x86, ARM and MIPS—with MIPS being favoured because of its use in the Part Ib course “Computer Design”. In terms of programming languages in which parts of compilers themselves are to be written, the preference varies between pseudo-code (as per the ‘Data Structures and Algorithms’ course) and language features (essentially) common to C/C++/Java/ML. The following books contain material relevant to the course. Compilers—Principles, Techniques, and Tools A.V.Aho, R.Sethi and J.D.Ullman Addison-Wesley (1986) Ellis Horwood (1982) Compiler Design in Java/C/ML (3 -
GNU/Linux Distro Timeline LEAF Version 10.9 Skolelinux Lindows Linspire Authors: A
1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 Libranet Omoikane (Arma) Gibraltar GNU/Linux distro timeline LEAF Version 10.9 Skolelinux Lindows Linspire Authors: A. Lundqvist, D. Rodic - futurist.se/gldt Freespire Published under the GNU Free Documentation License MEPIS SimplyMEPIS Impi Guadalinex Clonezilla Live Edubuntu Xubuntu gNewSense Geubuntu OpenGEU Fluxbuntu Eeebuntu Aurora OS Zebuntu ZevenOS Maryan Qimo wattOS Element Jolicloud Ubuntu Netrunner Ylmf Lubuntu eBox Zentyal Ubuntu eee Easy Peasy CrunchBang gOS Kiwi Ubuntulite U-lite Linux Mint nUbuntu Kubuntu Ulteo MoLinux BlankOn Elive OS2005 Maemo Epidemic sidux PelicanHPC Inquisitor Canaima Debian Metamorphose Estrella Roja BOSS PureOS NepaLinux Tuquito Trisquel Resulinux BeatriX grml DeadCD Olive Bluewall ASLinux gnuLiNex DeMuDi Progeny Quantian DSL-N Damn Small Linux Hikarunix Damn Vulnerable Linux Danix Parsix Kanotix Auditor Security Linux Backtrack Bioknoppix Whoppix WHAX Symphony OS Knoppix Musix ParallelKnoppix Kaella Shabdix Feather KnoppMyth Aquamorph Dreamlinux Morphix ZoneCD Hiwix Hiweed Deepin Kalango Kurumin Poseidon Dizinha NeoDizinha Patinho Faminto Finnix Storm Corel Xandros Moblin MeeGo Bogus Trans-Ameritech Android Mini Monkey Tinfoil Hat Tiny Core Yggdrasil Linux Universe Midori Quirky TAMU DILINUX DOSLINUX Mamona Craftworks BluePoint Yoper MCC Interim Pardus Xdenu EnGarde Puppy Macpup SmoothWall GPL SmoothWall Express IPCop IPFire Beehive Paldo Source Mage Sorcerer Lunar eIT easyLinux GoboLinux GeeXboX Dragora -
Code Optimization & Linking
Code optimization & linking Jinyang Li Slides adapted from Bryant and O’Hallaron What we’ve learnt so far • C program x86 instructions – Memory layout – control flows: sequential, jumps, call/ret • Buffer overflow – Hijack control flow by overwriting a return address – Execute code intended by the attacker Today’s lesson plan • Code optimization (done by the compiler) – common optimization techniques – what prevents optimization • C linker Optimizing Compilers • Goal: generate efficient, correct machine code – allocate registers, choose instructions, ... Generated code must have the same behavior as the original C program under all scenarios gcc’s optimization levels: -O1, -O2, -O3 Common optimization: code motion • Move computation outside loop if possible. void set_arr(long *arr, long n) { for (long i = 0; i < n; i++) arr[i] = n*n; done inside loop } testq %rsi, %rsi # Test n jle .L1 # If 0, goto done movq %rsi, %rdx leaq (%rdi, %rsi, 8), %rax # rax = &arr[n] void set_arr(long *arr, long n) # rdx = n*n imulq %rsi, %rdx { .L3: long t = n*n; movq %rdx, (%rdi) # (*p) =rdx for (long i = 0; i < n; i++) addq $8, %rdi # p++; arr[i] = t; cmpq %rax, %rdi # cmp &arr[n]) vs. p } jne .L3 # if !=, goto Loop .L3 Equivalent C code .L1: ret Common Optimization: use simpler instructions • Replace costly operation with simpler one – Shift, add instead of multiply or divide 16*x --> x << 4 – Recognize sequence of products long ni = 0; for (long i=0; i<n; i++ { for (long i = 0; i < n; i++) arr[i] = n*i; { } arr[i] = ni; ni += n; } assembly not shown this -
Ucb Cs61c : Great Ideas in Computer Architecture
inst.eecs.berkeley.edu/~cs61c Running a Program (Compiling, Assembling, Linking, Loading) UCB CS61C : GREAT IDEAS IN COMPUTER ARCHITECTURE Language Execution Continuum § An Interpreter is a program that executes other programs. Java bytecode Scheme Java C++ C Assembly Machine code Easy to program Difficult to program Inefficient to interpret Efficient to interpret § Language translation gives us another option. § In general, we interpret a high-level language when efficiency is not critical and translate to a lower-level language to up performance Interpretation vs Translation § How do we run a program written in a source language? ú Interpreter: Directly executes a program in the source language ú Translator: Converts a program from the source language to an equivalent program in another language § For example, consider a Python program foo.py! Interpretation § Python interpreter is just a program that reads a python program and performs the functions of that python program. Interpretation § Any good reason to interpret machine language in software? § MARS– useful for learning / debugging § Apple Macintosh conversion ú Switched from Motorola 680x0 instruction architecture to PowerPC. Similar issue with switch to x86. ú Could require all programs to be re-translated from high level language ú Instead, let executables contain old and/or new machine code, interpret old code in software if necessary (emulation) Interpretation vs. Translation? (1/2) § Generally easier to write interpreter § Interpreter closer to high-level, so can give better error messages (e.g., MARS, stk) ú Translator reaction: add extra information to help debugging (line numbers, names) § Interpreter slower (10x?), code smaller (2x?) § Interpreter provides instruction set independence: run on any machine Interpretation vs. -
Cybersecurity and Forensic Challenges - a Bibliographic Review
https://doi.org/10.2352/ISSN.2470-1173.2018.06.MOBMU-100 © 2018, Society for Imaging Science and Technology Cybersecurity and Forensic Challenges - A Bibliographic Review Reiner Creutzburg Technische Hochschule Brandenburg, Department of Informatics and Media, IT- and Media Forensics Lab,, P.O.Box 2132, D-14737 Brandenburg, Germany Email: [email protected] Abstract professional obligations on their learning processes. One can in- The aim of this paper is to give a bibliographic review of creasingly observe that colleges and universities more and more the growing number of different Cybersecurity and Forensic Chal- have to adjust to this present generation of students and respond lenges for educational and vocational training purposes. by increasing the flexibility of the courses. For this reason, on- Special attention is given to the hacking lab, which enables effec- line degree programs, or suitable combinations of classroom and tive training in cybersecurity and computer forensics in the uni- online studies (blended learning) are increasingly offered. It is versity environment and in vocational education and training. well-known that man learns about 80% of its knowledge and skills by informal learning compared to learning from formal learning. Introduction Unfortunately, often this fact is not taken into account by plan- Nowadays, small- and medium-sized enterprises (SME) ners and decision-makers from school, university and companies. have to deal more and more with the issue of IT security. Due A well-known example is the now already for 10 years success- to the ever-growing popularity of mobile devices, but also by the fully operating ”Virtuelle Fachhochschule (Virtual University)”, general acceptance of IT technology in everyday life, new secu- an association of 10 established Universities of Applied Sciences rity threats to corporate data occur every day [1-13]. -
Practical Linux Topics
Binnie BOOKS FOR PROFESSIONALS BY PROFESSIONALS® THE EXPERT’S VOICE® IN LINUX Practical Linux Topics Practical Practical Linux Topics This book teaches you how to improve your hands-on knowledge of Linux using challenging, real-world scenarios. Each chapter explores a topic that has been chosen specifically to demonstrate how to enhance your base Linux system, and resolve important issues. This book enables sysadmins, DevOps engineers, developers, and other technical professionals to make full use of Linux’s rocksteady foundation. Practical Linux Explore specific topics in networking, e-mail, filesystems, encryption, system monitoring, security, servers, and more—including systemd and GPG. Understand salient security concerns and how to mitigate them. Applicable to almost all Linux flavors—Debian, Red Hat, Ubuntu, Linux Mint, CentOS—Power Linux Topics can be used to reference other Unix-type systems Topics with little modification. Improve your practical know-how and background knowledge on servers and workstations alike, increase your ability to troubleshoot and ultimately solve the daily challenges encountered — by all professional Linux users. Empower your Linux skills by adding Power Linux Topics to your library today. Chris Binnie US . ISBN 978-1-4842-1771-9 Shelve in: 54999 Linux/General User level: Intermediate–Advanced 9781484 217719 SOURCE CODE ONLINE www.apress.com Practical Linux Topics Chris Binnie Practical Linux Topics Copyright © 2016 by Chris Binnie 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.