Nytro

Introduction to Programming Using Java Introduction to Programming Using Java, Fifth Edition Version 5.0, December 2006 Version 5.1.2, with minor corrections and updates, June 2010 (Version 5 Final Release) Author: David J. Eck (eck@hws.edu) WELCOME TO the fifth edition of Introduction to Programming Using Java, a free, on-line textbook on introductory programming, which uses Java as the language of instruction. This book is directed mainly towards beginning programmers, although it might also be useful for experienced programmers who want to learn something about Java. It is certainly not meant to provide complete coverage of the Java language. The fifth edition covers Java 5.0 and can also be used with later versions of Java. You will find many Java applets on the web pages that make up this book, and many of those applets require Java 5.0 or higher to function. Earlier editions, which covered earlier versions of Java, are still available; see the preface for links. You can download Introduction to Programming Using Java for use on your own computer. PDF and print versions are also available. Links can be found at the bottom of this page hort Table of Contents: * Full Table of Contents * Preface * Chapter 1: Overview: The Mental Landscape * Chapter 2: Programming in the Small I: Names and Things * Chapter 3: Programming in the Small II: Control * Chapter 4: Programming in the Large I: Subroutines * Chapter 5: Programming in the Large II: Objects and Classes * Chapter 6: Introduction to GUI Programming * Chapter 7: Arrays * Chapter 8: Correctness and Robustness * Chapter 9: Linked Data Structures and Recursion * Chapter 10: Generic Programming and Collection Classes * Chapter 11: Files and Networking * Chapter 12: Advanced GUI Programming * Source Code for All Examples in this Book * News and Errata Download: http://math.hws.edu/eck/cs124/downloads/javanotes5-linked.pdf Sursa, carte online: Javanotes 5.1.2 -- Title Page

Dive Into HTML5 by Mark Pilgrim with illustrations from the Public Domain Dive Into HTML5 seeks to elaborate on a hand-picked Selection of features from the HTML5 specification and other fine Standards. The final manuscript has been published on paper by O’Reilly, under the Google Press imprint. Buy the printed Work — artfully titled “HTML5: Up & Running” — and be the first in your Community to receive it. Your kind and sincere Feedback is always welcome. The Work shall remain online under the CC-BY-3.0 License. Table of Contents 1. Introduction: Five Things You Should Know About HTML50 2. A Quite Biased History of HTML51 3. Detecting HTML5 Features: It’s Elementary, My Dear Watson2 4. What Does It All Mean?3 5. Let’s Call It a Draw(ing Surface)4 6. Video in a Flash (Without That Other Thing)5 7. You Are Here (And So Is Everybody Else)6 8. A Place To Put Your Stuff7 9. Let’s Take This Offline8 10. A Form of Madness9 11. “Distributed,” “Extensibility,” And Other Fancy Words10 12. Manipulating History for Fun & Profit11 13. The All-In-One Almost-Alphabetical No-Bullshit Guide to Detecting EverythingA 14. HTML5 Peeks, Pokes and PointersB Download, capitole: http://diveintohtml5.org/

Learn You a Haskell Learn You a Haskell for Great Good! 1. Introduction * About this tutorial * So what's Haskell? * What you need to dive in 2. Starting Out * Ready, set, go! * Baby's first functions * An intro to lists * Texas ranges * I'm a list comprehension * Tuples 3. Types and Typeclasses * Believe the type * Type variables * Typeclasses 101 4. Syntax in Functions * Pattern matching * Guards, guards! * Where!? * Let it be * Case expressions 5. Recursion * Hello recursion! * Maximum awesome * A few more recursive functions * Quick, sort! * Thinking recursively 6. Higher Order Functions * Curried functions * Some higher-orderism is in order * Maps and filters * Lambdas * Only folds and horses * Function application with $ * Function composition 7. Modules * Loading modules * Data.List * Data.Char * Data.Map * Data.Set * Making our own modules 8. Making Our Own Types and Typeclasses * Algebraic data types intro * Record syntax * Type parameters * Derived instances * Type synonyms * Recursive data structures * Typeclasses 102 * A yes-no typeclass * The Functor typeclass * Kinds and some type-foo 9. Input and Output * Hello, world! * Files and streams * Command line arguments * Randomness * Bytestrings * Exceptions 10. Functionally Solving Problems * Reverse Polish notation calculator * Heathrow to London 11. Functors, Applicative Functors and Monoids * Functors redux * Applicative functors * The newtype keyword * Monoids 12. A Fistful of Monads * Getting our feet wet with Maybe * The Monad type class * Walk the line * do notation * The list monad * Monad laws 13. For a Few Monads More * Writer? I hardly know her! * Reader? Ugh, not this joke again. * Tasteful stateful computations * Error error on the wall * Some useful monadic functions * Making monads 14. Zippers * Taking a walk * A trail of breadcrumbs * Focusing on lists * A very simple file system * Watch your step Download, capitole: http://learnyouahaskell.com/chapters

Introduction to Design Patterns in C++ with Qt4 Alan Ezust Paul Ezust Abstract C++ is taught "The Qt way", with an emphasis on design patterns, and re-use of open source libraries and tools. By the end of the book, the reader should have a deep understanding of both the language and libraries, as well the design patterns used in developing software with them. Table of Contents Preface Acknowledgments Rationale for the Book I. Introduction to C++ and Qt 4 1. C++ Introduction 1.1. Overview of C++ 1.2. A Brief History of C++ 1.3. C++ First Example 1.4. Input and Output 1.4.1. Exercises: Input and Output 1.5. qmake, Project Files, and Makefile 1.5.1. #include: Finding Header Files 1.6. Getting Help Online 1.7. Strings 1.8. Streams 1.9. File Streams 1.9.1. Exercises: File Streams 1.10. Qt dialogs for user input/output 1.10.1. Exercises: Qt dialogs for user input/output 1.11. Identifiers, Types, and Literals 1.11.1. Exercises: Identifiers, Types, and Literals 1.12. C++ Simple Types 1.12.1. main, and Command Line Arguments 1.12.2. Arithmetic 1.12.3. Exercises: C++ Simple Types 1.13. The Keyword const 1.14. Pointers and Memory access 1.14.1. The Unary Operators & and * 1.14.2. Operators new and delete 1.14.3. Exercises: Pointers and Memory access 1.15. Reference Variables 1.16. const* and *const 1.17. Review Questions 1.17.1. Points of Departure 2. Top of the class 2.1. First, there was struct 2.2. Class definitions 2.3. Member Access Specifiers 2.4. Encapsulation 2.5. Qt Creator - An IDE for Qt Programming 2.6. Introduction to UML 2.6.1. UML Relationships 2.7. Friends of a Class 2.8. Constructors 2.9. Destructors 2.10. The Keyword static 2.11. Class Declarations and Defintions 2.12. Copy Constructors and Assignment Operators 2.13. Conversions 2.14. const Member Functions 2.15. Subobjects 2.16. Exercise: Classes 2.17. Review Questions 3. Introduction to Qt 3.1. Style Guidelines, Naming Conventions 3.1.1. Points of Departure 3.2. The Qt Core Module 3.2.1. Streams and Dates 3.2.2. Exercises: The Qt Core Module 3.3. Review Questions 3.3.1. Points of Departure 4. Lists 4.1. Introduction to Containers 4.2. Iterators 4.2.1. QStringList and iteration 4.3. Relationships 4.4. Exercise: Relationships 4.5. Review Questions 5. Functions 5.1. Function Declarations 5.2. Overloading Functions 5.2.1. Exercises: Overloading Functions 5.3. Default (Optional) Arguments 5.4. Operator Overloading 5.4.1. Exercises: Operator Overloading 5.5. Parameter Passing by Value 5.6. Parameter Passing by Reference 5.7. References to const 5.8. Function Return Values 5.9. Returning References from Functions 5.10. Overloading on const 5.10.1. Exercises: Overloading on const 5.11. inline Functions 5.11.1. Inlining versus Macro Expansion 5.12. Functions with Variable-length Argument Lists 5.13. Exercise: Encryption 5.14. Review Questions 6. Inheritance and Polymorphism 6.1. Simple Derivation 6.1.1. Inheritance Client Code Example 6.2. Derivation with Polymorphism 6.2.1. Exercises: Derivation with Polymorphism 6.3. Derivation from an Abstract Base Class 6.4. Inheritance Design 6.5. Overloading, Hiding, and Overriding 6.6. Constructors, Destructors, and Copy Assignment Operators 6.7. Processing Command-Line Arguments 6.7.1. Derivation and ArgumentList 6.8. Exercises: Inheritance and Polymorphism 6.9. Review Questions 6.9.1. Points of Departure II. Higher Level Programming 7. Libraries 7.1. Code Containers 7.2. Building and Reusing Libraries 7.2.1. Organizing Libraries: Dependency Management 7.2.2. Installing Libraries 7.2.2.1. Points of Departure 7.3. Installing Libraries: A Lab Exercise 7.4. Frameworks and Components 7.5. Review Questions 8. Introduction to Design patterns 8.1. Anti-patterns 8.2. The Iterator Pattern 8.2.1. Directories and Files: QDir and QFileInfo 8.2.2. Customizing FileVisitor using Inheritance 8.2.3. Exercises: The Iterator Pattern 8.2.4. QDirIterator and the Iterator pattern 8.3. Review Questions 9. QObject 9.1. QObject's Child Managment 9.1.1. Exercises: QObject's Child Managment 9.2. Parents and Children 9.2.1. Finding Children 9.3. QApplication and the Event Loop 9.3.1. Layouts: A First Look 9.3.2. Connecting to slots 9.3.3. Signals and Slots 9.3.3.1. Exercises: Signals and Slots 9.4. Q_OBJECT and moc: A checklist 9.4.1. Points of Departure 9.5. Values and Objects 9.6. Exercises: QObject 9.7. tr() and Internationalization. 9.8. Review Questions 10. Generics and Containers 10.1. Generics and Templates 10.1.1. Function Templates 10.1.1.1. Exercises: Function Templates 10.1.2. Class Templates 10.1.3. Exercises: Generics and Templates 10.2. Containers 10.3. Managed Containers, Composites and Aggregates 10.3.1. Exercises: Managed Containers, Composites and Aggregates 10.4. Generics, Algorithms, and Operators 10.4.1. Exercises: Generics, Algorithms, and Operators 10.5. Serializer Pattern 10.5.1. Exercises: Serializer Pattern 10.6. Sorted Map example 10.7. Flyweight pattern: Implicitly Shared Classes 10.7.1. Points of Departure 10.7.2. Exercises: Flyweight pattern: Implicitly Shared Classes 10.8. Exercise: QSet and QMap 10.9. Review Questions 11. Qt GUI Widgets 11.1. Widget Categories 11.2. QMainWindow and QSettings 11.2.1. QSettings: Saving and Restoring Application State 11.3. Dialogs 11.3.1. Input Dialogs and Widgets 11.3.2. Exercises: Dialogs 11.4. Images and Resources 11.5. Layout of Widgets 11.5.1. Spacing, Stretching, and Struts 11.5.2. Moving Widgets across Layouts 11.5.3. Exercises: Layout of Widgets 11.6. QActions, QMenus, and QMenuBars 11.6.1. QActions, QToolbars, and QActionGroups 11.6.1.1. Points of Departure 11.6.2. Exercises: QActions, QMenus, and QMenuBars 11.6.3. Exercise: CardGame GUI 11.7. Regions and QDockWidgets 11.8. Views of a QStringList 11.8.1. Exercises: Views of a QStringList 11.9. Qt Designer 11.10. Review Questions 11.10.1. Points of Departure 12. Concurrency 12.1. QProcess and Process Control 12.1.1. Processes and Environment 12.1.2. Qonsole: Writing an Xterm in Qt 12.1.3. Qonsole with Keyboard Events 12.1.4. Exercises: QProcess and Process Control 12.2. Threads and QThread 12.2.1. QPixmap and QThread Animation Example: Movie Player 12.2.2. Movie Player with QTimer 12.2.3. Multiple Threads, Queues, and Loggers Example: Giant 12.2.4. Thread Safety and QObjects 12.2.5. Exercises: Threads and QThread 12.3. Summary: QProcess and QThread 12.4. Review Questions 13. Models and Views 13.1. M-V-C: What about the Controller? 13.2. Qt 4 Models and Views 13.2.1. QStandardItemModel and Multiple Views 13.3. Table Models 13.4. Tree Models 13.4.1. Extended Tree Widget Items 13.4.1.1. Exercises: Extended Tree Widget Items 13.5. Form Models and Views 13.5.1. Form Models 13.5.2. Designer Forms and QDataWidgetMapper 13.5.2.1. Points of Departure 13.5.2.2. Exercises: Designer Forms and QDataWidgetMapper 13.6. Review Questions 14. Validation and Regular Expressions 14.1. Validators 14.2. Regular Expressions 14.2.1. Regular Expression Syntax 14.2.2. Regular Expressions: Phone Number Recognition 14.2.3. Exercises: Regular Expressions 14.3. Regular Expression Validation 14.4. Exercises: Validation and Regular Expressions 14.5. Review Questions 15. Parsing XML 15.1. The Qt XML Module 15.2. Event-Driven parsing 15.3. XML, Tree Structures, and DOM 15.3.1. Iterator Pattern: DOM Tree Walking 15.3.2. Generation of XML with DOM 15.3.3. Exercises: XML, Tree Structures, and DOM 15.4. Review Questions 16. Meta Objects, Properties, and Reflective Programming 16.1. QMetaObject - The Meta Object pattern 16.2. Type Identification and qobject_cast 16.3. Q_PROPERTY Macro - Describing QObject Properties 16.4. QVariant Class: Accessing Properties 16.5. DataObject: An Extension of QObject 16.6. Review Questions 17. More Design Patterns 17.1. Creational Patterns 17.1.1. Abstract Factory 17.1.2. Abstract Factories and Libraries 17.1.3. qApp and Singleton pattern 17.1.4. Creation Rules and Friend Functions 17.1.5. Benefits of Using Factories 17.1.6. Exercises: Creational Patterns 17.2. Memento Pattern 17.2.1. Exporting to XML 17.2.2. Importing Objects with an Abstract Factory 17.3. The Façade Pattern 17.4. Review Questions 17.4.1. Points of Departure 18. Database Programming 18.1. Intro to MySQL 18.2. Connecting to MySQL from Qt 18.3. Queries and Result Sets 18.4. Long Running Threads and the Command Pattern 18.5. Database Models III. C++ Language Reference 19. Types and Expressions 19.1. Operators 19.1.1. Table of Operators 19.2. Evaluation of Logical Expressions 19.3. Enumerations 19.4. Signed and Unsigned Integral Types 19.4.1. Exercises: Signed and Unsigned Integral Types 19.5. Standard Expression Conversions 19.5.1. Exercises: Standard Expression Conversions 19.6. Explicit Conversions 19.7. Safer ANSI C++ Typecast operators 19.7.1. static_cast and const_cast 19.7.1.1. Exercises: static_cast and const_cast 19.7.2. reinterpret_cast 19.7.3. Why not use C-style casts? 19.8. Overloading special operators 19.8.1. Conversion Operators 19.8.2. Vectors and operator[] 19.8.3. The Function-Call operator() 19.9. Runtime Type Identification (RTTI) 19.9.1. typeid operator 19.10. Member Selection operators 19.11. Exercises: Types and Expressions 19.12. Review Questions 20. Scope and Storage Class 20.1. Declarations and Definitions 20.2. Identifier Scope 20.2.1. Default Scope of Identifiers - A Summary 20.2.2. File Scope versus Block Scope and operator:: 20.2.2.1. Exercises: File Scope versus Block Scope and operator:: 20.3. Storage Class 20.3.1. Globals, static, and QObject 20.3.1.1. Globals and const 20.3.2. Exercises: Storage Class 20.4. Namespaces 20.4.1. Anonymous Namespaces 20.4.2. Open Namespaces 20.4.3. namespace, static objects and extern 20.5. Review Questions 21. Statements and Control Structures 21.1. Statements 21.2. Selection Statements 21.2.1. Exercises: Selection Statements 21.3. Iteration 21.3.1. Exercises: Iteration 21.4. Review Questions 22. Memory Access 22.1. Pointer Pathology 22.2. Further Pointer Pathology with Heap Memory 22.3. Memory Access Summary 22.4. Introduction to Arrays 22.5. Pointer Arithmetic 22.6. Arrays, Functions, and Return Values 22.7. Different kinds of arrays 22.8. Valid Pointer Operations 22.9. What happens if new fails? 22.9.1. set_new_handler() : Another Approach To new Failures 22.9.2. Using set_new_handler and bad_alloc 22.9.3. Checking for null: new(nothrow) 22.10. Chapter Summary 22.11. Review Questions 23. Inheritance in Detail 23.1. virtual pointers, virtual tables 23.2. Polymorphism and virtual destructors 23.3. Multiple Inheritance 23.3.1. Multiple Inheritance Syntax 23.3.2. Multiple Inheritance with Abstract Interfaces 23.3.2.1. Points of Departure 23.3.3. Resolving Multiple Inheritance Conflicts 23.3.3.1. virtual Inheritance 23.3.3.2. virtual Base Classes 23.4. public, protected, and private derivation 23.5. Review Questions IV. Programming Assignments 24. MP3 jukebox Assignments 24.1. Phonon Setup 24.2. Playlist 24.3. Playlists 24.4. Source Selector 24.5. Star Delegates 24.6. Filtering Views 24.7. File Tree SideBar 24.8. AutoDJ A. C++ Reserved keywords B. Standard Headers C. The Development Environment C.1. make and Makefile C.2. The Preprocessor: For #including Files C.3. Understanding the Linker C.3.1. Common Linker Error Messages C.4. Debugging C.4.1. Building a Debuggable Target C.4.1.1. Exercises: Building a Debuggable Target C.4.2. gdb Quickstart C.4.3. Finding Memory Errors C.5. Qt Assistant and Designer C.6. Open Source development tools, Libraries, IDEs. D. Alan's quickstart guide to Debian for programmers. D.1. The apt system D.2. update-alternatives E. C++/Qt Setup E.1. C++/Qt Setup: Open Source Platforms E.2. C++/Qt Setup: Win32 E.3. C++/Qt Setup: Mac OSX F. Errata Bibliography Index Download, capitole: http://cartan.cas.suffolk.edu/oopdocbook/opensource/index.html

Data Structures and Algorithms Annotated Reference with Examples This book written by Granville Barnett and Luca Del Tongo is part of an effort to provide all developers with a core understanding of algorithms that operate on various common, and uncommon data structures. Download: http://dotnetslackers.com/Community/files/folders/30283/download.aspx Sursa: Data Structures and Algorithms: Annotated Reference with Examples CHRISTMAS - DotNetSlackers Community

Linux Device Drivers, Third Edition By Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman February 2005 Pages: 636 Open Book Content Title Pages License/Copyright Table of Contents About the Author/Colophon Preface Chapter 1: An Introduction to Device Drivers Chapter 2: Building and Running Modules Chapter 3: Char Drivers Chapter 4: Debugging Techniques Chapter 5: Concurrency and Race Conditions Chapter 6: Advanced Char Driver Operations Chapter 7: Time, Delays, and Deferred Work Chapter 8: Allocating Memory Chapter 9: Communicating with Hardware Chapter 10: Interrupt Handling Chapter 11: Data Types in the Kernel Chapter 12: PCI Drivers Chapter 13: USB Drivers Chapter 14: The Linux Device Model Chapter 15: Memory Mapping and DMA Chapter 16: Block Drivers Chapter 17: Network Drivers Chapter 18: TTY Drivers Bibliography Index Download, capitole: http://oreilly.com/catalog/linuxdrive3/book/index.csp

Let's Build a Compiler by Jack Crenshaw * Part 1: INTRODUCTION * Part 2: EXPRESSION PARSING * Part 3: MORE EXPRESSIONS * Part 4 INTERPRETERS * Part 5: CONTROL CONSTRUCTS * Part 6: BOOLEAN EXPRESSIONS * Part 7: LEXICAL SCANNING * Part 8: A LITTLE PHILOSOPHY * Part 9: A TOP VIEW * Part 10: INTRODUCING "TINY" * Part 11: LEXICAL SCAN REVISITED * Part 12: MISCELLANY * Part 13: PROCEDURES * Part 14: TYPES * Part 15: BACK TO THE FUTURE * Part 16: UNIT CONSTRUCTION Download the tutorial: http://compilers.iecc.com/crenshaw/tutorfinal.pdf Sursa: Let's Build a Compiler

Windows 7 Kernel Architecture Changes - api-ms-win-core files Windows 7 introduces a new set of dll files containing exported functions of many well-known WIN32 APIs. All these filenames begins with 'api-ms-win-core' prefix, followed by the functions category name. For example, api-ms-win-core-localregistry-l1-1-0.dll contains the exported names for all Registry functions, api-ms-win-core-file-l1-1-0.dll contains the exported names for all file-related functions, api-ms-win-core-localization-l1-1-0.dll contains the exported names for all localization functions, and so on. If you look deeply into these files, you'll see that all these files are very small, and the functions in them doen't do anything, and simply returns a 'TRUE' value. Just for example, here's the assembly language content of RegDeleteValueW function in api-ms-win-core-localregistry-l1-1-0.dll: 084010CE 33C0 xor eax, eax 084010D0 40 inc eax 084010D1 C20800 ret 0008 By looking in dependency walker utility, we can see that advapi32.dll, kernel32.dll, and other system dll files, are now statically linked to these empty api-ms-win-core files. Moreover, if we look in the assembly language output of many API functions, we can see that they simply call their corresponding function in one of these api-ms-win-core Dlls. Just for example, RegDeleteValueW in advapi32.dll, simply contains a jump to the RegDeleteValueW in API-MS-Win-Core-LocalRegistry-L1-1-0.dll: ADVAPI32!RegDeleteValueW: 77C6F301 8BFF mov edi, edi 77C6F303 55 push ebp 77C6F304 8BEC mov ebp, esp 77C6F306 5D pop ebp 77C6F307 EB05 jmp 77C6F30E . . . 77C6F30E FF25B414C677 Jmp dword ptr [77C614B4] <-- [77C614B4] Points the import entry of API-MS-Win-Core-LocalRegistry-L1-1-0.RegDeleteValueW So if RegDeleteValueW in ADVAPI32 and other functions simply jumps to empty functions, how is it possible that these functions still works properly ? The answer is pretty simple: When Windows loads the dll files, all the import entries of these api-ms-win-core Dlls are replaced with a call to a real function in Windows kernel. So here's our RegDeleteValueW example again: when loading a program into WinDbg, we can see that the jmp call now points to kernel32!RegDeleteValueW function. That's because during the loading of advapi32.dll, Windows automatically replace the import entry of API-MS-Win-Core-LocalRegistry-L1-1-0.RegDeleteValueW to the function address of RegDeleteValueW in kernel32. 75e5f301 8bff mov edi,edi 75e5f303 55 push ebp 75e5f304 8bec mov ebp,esp 75e5f306 5d pop ebp 75e5f307 eb05 jmp ADVAPI32!RegDeleteValueW+0xd (75e5f30e) . . . 75e5f30e ff25b414e575 jmp dword ptr [ADVAPI32+0x14b4 (75e514b4)] ds:0023:75e514b4= {kernel32!RegDeleteValueW (758bd5af)} Another new dll: kernelbase.dll In addition to the new API-MS-Win-Core dll files, there is also another new dll: kernelbase.dll In previous versions of Windows, most of the kernel32 functions called to their corresponding functions in ntdll.dll. In Windows 7, most of the kernel functions call to their corresponding functions in kernelbase.dll, and the kernelbase dll is the one that makes the calls to ntdll.dll Effects on existing applications - compatibility issues. Most of the existing applications should not be affected by this kernel change, because all standard API calls still works the same as in previous versions of Windows. However, there are some diagnostic/debugging applications that rely on the calls chain inside the Windows kernel. These kind of applications may not work properly in Windows 7. My own utilities, RegFromApp and ProcessActivityView failed to work under Windows 7 because of these changes, and that what led me to discover the kernel changes of Windows 7. These utilities problems already fixed and now they works properly in Windows 7. API-MS-Win-Core List Finally, here's the list of all core dll files added to Windows 7 and the functions list that each one of them contain. I used my own DLL Export Viewer utility to generate the list. Sursa si tabelul: http://nirsoft.net/articles/windows_7_kernel_architecture_changes.html

Free Feature-rich PHP Mailer Swift Mailer integrates into any web app written in PHP 5, offering a flexible and elegant object-oriented approach to sending emails with a multitude of features. Send emails using SMTP, sendmail, postfix or a custom Transport implementation of your own Support servers that require username & password and/or encryption Protect from header injection attacks without stripping request data content Send MIME compliant HTML/multipart emails Use event-driven plugins to customize the library Handle large attachments and inline/embedded images with low memory use Download: http://swiftmailer.org/downloads/get/Swift-4.0.6.tar.gz Sursa: Powerful component based mailing library for PHP – Swift Mailer

CSS 3.0 Maker Interesant zic eu http://www.css3maker.com/

Mozilla JavaScript Guide Quick Table of Contents About this Guide JavaScript Overview Values, Variables, and Literals Expressions and Operators Regular Expressions Statements Functions Working with Objects Predefined Core Objects Details of the object model Inheritance revisited Iterators and generators Closures LiveConnect Overview Processing XML with E4X Expanded Table of Contents About this Guide 1. New features in JavaScript versions 2. What you should already know 3. JavaScript versions 4. Where to find JavaScript information 5. Tips for learning JavaScript 5.1. An interactive interpreter 5.2. Firebug 6. Document conventions JavaScript Overview 1. What is JavaScript? 2. JavaScript and Java 3. JavaScript and the ECMAScript Specification 3.1. Relationship between JavaScript Versions and ECMAScript Editions 3.2. JavaScript Documentation versus the ECMAScript Specification 3.3. JavaScript and ECMAScript Terminology Values, Variables, and Literals 1. Values 1.1. Data Type Conversion 2. Variables 2.1. Declaring Variables 2.2. Evaluating Variables 2.3. Variable Scope 2.4. Global Variables 2.5. See Also 3. Constants 4. Literals 4.1. Array Literals 4.1.1. Extra Commas in Array Literals 4.2. Boolean Literals 4.3. Integers 4.4. Floating-Point Literals 4.5. Object Literals 4.6. String Literals 4.6.1. Using Special Characters in Strings 4.6.2. Escaping Characters 5. Unicode 5.1. Unicode compatibility with ASCII and ISO 5.2. Unicode Escape Sequences 5.3. Unicode characters in JavaScript files 5.4. Displaying characters with Unicode Expressions and Operators 1. Expressions 2. Operators 2.1. Assignment Operators 2.2. Comparison Operators 2.3. Arithmetic Operators 2.4. Bitwise Operators 2.4.1. Bitwise Logical Operators 2.4.2. Bitwise Shift Operators 2.5. Logical Operators 2.5.1. Short-Circuit Evaluation 2.6. String Operators 2.7. Special Operators 2.7.1. conditional operator 2.7.2. comma operator 2.7.3. delete 2.7.4. in 2.7.5. instanceof 2.7.6. new 2.7.7. this 2.7.8. typeof 2.7.9. void 2.8. Operator Precedence Regular Expressions 1. Creating a Regular Expression 2. Writing a Regular Expression Pattern 2.1. Using Simple Patterns 2.2. Using Special Characters 2.3. Using Parentheses 3. Working with Regular Expressions 3.1. Using Parenthesized Substring Matches 3.2. Advanced Searching With Flags 4. Examples 4.1. Changing the Order in an Input String 4.2. Using Special Characters to Verify Input Statements 1. Block Statement 2. Conditional Statements 2.1. if...else Statement 2.2. switch Statement 3. Loop Statements 3.1. for Statement 3.2. do...while Statement 3.3. while Statement 3.4. label Statement 3.5. break Statement 3.6. continue Statement 4. Object Manipulation Statements 4.1. for...in Statement 4.2. for each...in Statement 4.3. with Statement 5. Comments 6. Exception Handling Statements 6.1. Exception Types 6.2. throw Statement 6.3. try...catch Statement 6.3.1. The catch Block 6.3.2. The finally Block 6.3.3. Nesting try...catch Statements 6.4. Utilizing Error objects Functions 1. Defining Functions 2. Calling Functions 3. Using the arguments object 3.1. JavaScript 1.3 and earlier 4. Predefined Functions 4.1. eval Function 4.2. isFinite Function 4.3. isNaN Function 4.4. parseInt and parseFloat Functions 4.5. Number and String Functions 4.6. escape and unescape Functions Working with Objects 1. Objects and Properties 2. Enumerating all properties of an object 3. Creating New Objects 3.1. Using Object Initializers 3.2. Using a Constructor Function 3.3. Indexing Object Properties 3.4. Defining Properties for an Object Type 3.5. Defining Methods 3.6. Using this for Object References 3.7. Defining Getters and Setters 3.7.1. Obsolete syntaxes 3.7.2. Summary 3.7.3. See also 3.8. Deleting Properties 4. See also Predefined Core Objects 1. Array Object 1.1. Creating an Array 1.2. Populating an Array 1.3. Referring to Array Elements 1.4. Understanding length 1.5. Iterating over arrays 1.6. Array Methods 1.7. Two-Dimensional Arrays 1.8. Arrays and Regular Expressions 1.9. Working with Array-like objects 1.10. Array comprehensions 2. Boolean Object 3. Date Object 3.1. Methods of the Date Object 3.2. Using the Date Object: an Example 4. Function Object 5. Math Object 6. Number Object 7. RegExp Object 8. String Object Details of the object model 1. Class-based vs. prototype-based languages 1.1. Defining a class 1.2. Subclasses and inheritance 1.3. Adding and removing properties 1.4. Summary of differences 2. The employee example 3. Creating the hierarchy 4. Object properties 4.1. Inheriting properties 4.2. Adding properties 5. More flexible constructors 6. Property inheritance revisited 6.1. Local versus inherited values 6.2. Determining instance relationships 6.3. Global information in constructors 6.4. No multiple inheritance Inheritance revisited 1. Example 2. prototype and Object.getPrototypeOf Iterators and generators 1. Iterators 2. Defining custom iterators 3. Generators: a better way to build Iterators 4. Advanced generators 5. Generator expressions Closures 1. Practical closures 2. Emulating private methods with closures 3. Creating closures in loops: A common mistake 4. Performance considerations LiveConnect Overview 1. Working with Wrappers 2. JavaScript to Java Communication 2.1. The Packages Object 2.2. Working with Java Arrays 2.3. Package and Class References 2.4. Arguments of Type char 2.5. Handling Java Exceptions in JavaScript 3. Java to JavaScript Communication 3.1. Locating the LiveConnect classes 3.2. Using the LiveConnect classes with the JDK 3.3. Using the LiveConnect Classes 3.3.1. Accessing JavaScript with JSObject 3.3.2. Handling JavaScript Exceptions in Java 3.3.3. Backward Compatibility 4. Data Type Conversions 4.1. JavaScript to Java Conversions 4.1.1. Number Values 4.1.2. Boolean Values 4.1.3. String Values 4.1.4. Undefined Values 4.1.5. Null Values 4.1.6. JavaArray and JavaObject objects 4.1.7. JavaClass objects 4.1.8. Other JavaScript objects 4.2. Java to JavaScript Conversions Processing XML with E4X 1. Compatibility issues 2. Creating an XML object 3. Working with attributes 4. Working with XML objects 5. Working with XMLLists 6. Searching and filtering 7. Handling namespaces 7.1. Default 7.2. Non-default 8. Using Generators/Iterators with E4X 9. See also Tutorial: https://developer.mozilla.org/en/JavaScript/Guide

JavaScript Garden JavaScript Garden is a growing collection of documentation about the most quirky parts of the JavaScript programming language. It gives advice to avoid common mistakes, subtle bugs, as well as performance issues and bad practices that non-expert JavaScript programmers may encounter on their endeavours into the depths of the language. JavaScript Garden does not aim to teach you JavaScript. Former knowledge of the language is strongly recommended in order to understand the topics covered in this guide. In order to learn the basics of the language, please head over to the excellent guide on the Mozilla Developer Network. The Authors This guide is the work of two lovely Stack Overflow users, Ivo Wetzel (Writing) and Zhang Yi Jiang (Design). Contributors Caio Romão (Spelling corrections) Andreas Blixt (Language corrections) Hosting JavaScript Garden is hosted on GitHub, but Cramer Development supports us with a mirror at JavaScriptGarden.info. License JavaScript Garden is published under the MIT license and hosted on GitHub. If you find errors or typos please file an issue or a pull request on the repository. You can also find us in the JavaScript room on Stack Overflow chat. Objects Object Usage and Properties Everything in JavaScript acts like an object, with the only two exceptions being null and undefined. false.toString() // 'false' [1, 2, 3].toString(); // '1,2,3' function Foo(){} Foo.bar = 1; Foo.bar; // 1 A common misconception is that number literals cannot be used as objects. That is because a flaw in JavaScript's parser tries to parse the dot notation on a number as a floating point literal. 2.toString(); // raises SyntaxError There are a couple of workarounds which can be used in order make number literals act as objects too. 2..toString(); // the second point is correctly recognized 2 .toString(); // note the space left to the dot (2).toString(); // 2 is evaluated first Objects as a Data Type Objects in JavaScript can also be used as a Hashmap, they mainly consist of named properties mapping to values. Using a object literal - {} notation - it is possible to create a plain object. This new object inherits from Object.prototype and has no own properties defined on it. var foo = {}; // a new empty object // a new object with a property called 'test' with value 12 var bar = {test: 12}; Accessing Properties The properties of an object can be accessed in two ways, via either the dot notation, or the square bracket notation. var foo = {name: 'Kitten'} foo.name; // kitten foo['name']; // kitten var get = 'name'; foo[get]; // kitten foo.1234; // SyntaxError foo['1234']; // works Both notations are identical in their workings, with the only difference being that the square bracket notation allows for dynamic setting of properties, as well as the use of property names that would otherwise lead to a syntax error. Deleting Properties The only way to actually remove a property from an object is to use the delete operator; setting the property to undefined or null only remove the value associated with the property, but not the key. var obj = { bar: 1, foo: 2, baz: 3 }; obj.bar = undefined; obj.foo = null; delete obj.baz; for(var i in obj) { if (obj.hasOwnProperty(i)) { console.log(i, '' + obj[i]); } } The above outputs both bar undefined and foo null - only baz was removed and is therefore missing from the output. Notation of Keys var test = { 'case': 'I am a keyword so I must be notated as a string', delete: 'I am a keyword too so me' // raises SyntaxError }; Object properties can be both notated as plain characters and as strings. Due to another mis-design in JavaScript's parser, the above will throw a SyntaxError prior to ECMAScript 5. This error arises from the fact that delete is a keyword; therefore, it must be notated as a string literal to ensure that it will be correctly interpreted by older JavaScript engines. Articol frumos aranjat aici: http://bonsaiden.github.com/JavaScript-Garden/

Learning Advanced JavaScript 1) Our Goal 2) Defining Functions 3) Named Functions 4) Functions as Objects 5) Context 6) Instantiation 7) Flexible Arguments 8) Closures 9) Temporary Scope 10) Function Prototypes 11) Instance Type 12) Inheritance 13) Built-in Prototypes 14) Enforcing Function Context 15) Bonus: Function Length Tutorial: http://ejohn.org/apps/learn/

MenuetOS MenuetOS is an Operating System in development for the PC written entirely in 32/64 bit assembly language. Menuet64 is released under License and Menuet32 under GPL. Menuet supports 32/64 bit x86 assembly programming for smaller, faster and less resource hungry applications. Menuet isn't based on other operating system nor has it roots within UNIX or the POSIX standards. The design goal, since the first release in year 2000, has been to remove the extra layers between different parts of an OS, which normally complicate programming and create bugs. Menuet's application structure isn't specifically reserved for asm programming since the header can be produced with practically any other language. However, the overall application programming design is intended for 32/64 bit asm programming. Menuet programming is fast and easy to learn. Menuet's responsive GUI is easy to handle with assembly language. And Menuet64 is capable of running Menuet32 applications. Features - Pre-emptive multitasking with 1000hz scheduler, multithreading, multiprocessor, ring-3 protection - Responsive GUI with resolutions up to 1280x1024, 16 million colours - Free-form, transparent and skinnable application windows, drag'n drop - SMP multiprocessor support with currently up to 8 cpus - IDE: Editor/Assembler for applications - USB 2.0 Hi-speed storage, webcam, printer class and TV/Radio support - USB 1.1 Keyboard and mouse support - TCP/IP stack with Loopback & Ethernet drivers - Email/ftp/http/chess clients and ftp/mp3/http servers - Hard real-time data fetch - Fits on a single floppy, boots also from CD and USB drives Site oficial: http://www.menuetos.net/

Handbook of Applied Cryptography Chapter 1 - Overview of Cryptography Chapter 2 - Mathematics Background Chapter 3 - Number-Theoretic Reference Problems Chapter 4 - Public-Key Parameters Chapter 5 - Pseudorandom Bits and Sequences Chapter 6 - Stream Ciphers Chapter 7 - Block Ciphers Chapter 8 - Public-Key Encryption Chapter 9 - Hash Functions and Data Integrity Chapter 10 - Identification and Entity Authentication Chapter 11 - Digital Signatures Chapter 12 - Key Establishment Protocols Chapter 13 - Key Management Techniques Chapter 14 - Efficient Implementation Chapter 15 - Patents and Standards Appendix - Bibliography of Papers from Selected Cryptographic Forums References Index Sursa: Handbook of Applied Cryptography

Trebuie folosit winsock2.h. La inceput trebuie apelata functia WSAStartUp, la sfarsit trebuie apelata WSACleanup... Problema poate fi aici: sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_TCP) Din cate stiu eu nu se pot crea RAW sockets pe Windows din motive de "securitate". In rest, pe langa cateva functii specifice Linux, se poate porta. Functiile pentru retea, desi Windows are versiuni specifice ale acestor functii, exista si in Windows Sockets API si nu ar trebui sa fie probleme. Edit: Pe Windows 7 cred ca merge: #include <stdio.h> #include <winsock2.h> int main() { WSADATA wsaData; SOCKET hSock; WSAStartup(MAKEWORD(2, 2), &wsaData); // Cream socketul hSock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP); printf("Handlerul socketului: %d\r\n", hSock); closesocket(hSock); WSACleanup(); return 0; } Mai pe seara daca nu am ce face, incerc sa il portez.

Nu e cine stie ce, nu prea are optiuni si e detectabil. Nu cred ca are rost sa il uploadez din nou.

NTFS On-Disk Structure Visual Basic NTFS Programmer’s Guide © 2004 Alex Ionescu 1. BASIC CONCEPTS........................................................................................................................... 5 1.1 INTRODUCTION............................................................................................................................... 5 1.2 NTFS TERMINOLOGY .................................................................................................................... 5 1.3 GENERAL TERMINOLOGY.............................................................................................................. 6 1.4 NTFS VERSIONS............................................................................................................................ 7 2. THE BOOT RECORD........................................................................................................................ 7 2.1 DEFINITION..................................................................................................................................... 7 2.2 STRUCTURE..................................................................................................................................... 7 3. METAFILES ...................................................................................................................................... 10 3.1 INTRODUCTION............................................................................................................................. 10 3.1.1 Description .......................................................................................................................... 10 3.1.2 Listing (NTFS 3.0+) .......................................................................................................... 10 3.2 $MFT.............................................................................................................................................. 11 3.2.1 Description .......................................................................................................................... 11 3.2.2 Structure .............................................................................................................................. 11 3.3 $MFTMIRR ................................................................................................................................... 12 3.3.1 Description .......................................................................................................................... 12 3.3.2 Structure .............................................................................................................................. 13 3.4 $LOGFILE...................................................................................................................................... 13 3.4.1 Description .......................................................................................................................... 13 3.4.2 Structure .............................................................................................................................. 14 3.5 $VOLUME....................................................................................................................................... 14 3.5.1 Description .......................................................................................................................... 14 3.5.2 Structure .............................................................................................................................. 14 3.6 $ATTRDEF..................................................................................................................................... 15 3.6.1 Description .......................................................................................................................... 15 3.6.2 Structure .............................................................................................................................. 15 3.7 . (DOT) ............................................................................................................................................ 16 3.7.1 Description .......................................................................................................................... 16 3.7.2 Structure .............................................................................................................................. 17 3.8 $BITMAP ........................................................................................................................................ 17 3.8.1 Description .......................................................................................................................... 17 3.8.2 Structure .............................................................................................................................. 17 3.9 $BOOT............................................................................................................................................. 18 3.9.1 Description .......................................................................................................................... 18 3.9.2 Structure............................................................................................................................... 18 3.10 $BADCLUS.................................................................................................................................... 18 3.10.1 Description....................................................................................................................... 18 3.10.2 Structure........................................................................................................................... 18 3.11 $SECURE...................................................................................................................................... 19 3.11.1 Description....................................................................................................................... 19 3.11.2 Structure........................................................................................................................... 20 3.12 $UPCASE ..................................................................................................................................... 21 3.12.1 Description....................................................................................................................... 21 3.12.2 Structure........................................................................................................................... 22 3.13 $EXTEND...................................................................................................................................... 22 3.13.1 Description....................................................................................................................... 22 3.15 $OBJID........................................................................................................................................ 22 3.15.1 Description....................................................................................................................... 22 3.15.2 Structure........................................................................................................................... 23 3.16 $QUOTA........................................................................................................................................ 23 3.16.1 Description....................................................................................................................... 23 3.16.2 Structure........................................................................................................................... 24 3.17.1 Description....................................................................................................................... 26 3.17.2 Structure........................................................................................................................... 26 3. 18 $USNJRNL.................................................................................................................................. 27 3.18.1 Description....................................................................................................................... 27 3.18.2 Structure........................................................................................................................... 27 4. ATTRIBUTES.................................................................................................................................... 29 4.1 INTRODUCTION............................................................................................................................. 29 4.1.1 Definition ............................................................................................................................. 29 4.1.2 Listing (NTFS 3.0+) .......................................................................................................... 29 4.2 TYPES OF ATTRIBUTES ................................................................................................................ 31 4.2.1 Attribute Definition ......................................................................................................... 31 4.2.2 Attribute Structure........................................................................................................... 31 4.2.3 Nonresident Attribute Definition ............................................................................... 32 4.2.4 Nonresident Attribute Structure ................................................................................ 32 4.2.5 Resident Attribute Definition.................................................................................................... 33 4.2.6 Resident Attribute Structure........................................................................................ 33 4.2.7 Named and Unnamed Attributes................................................................................ 34 4.3 $STANDARD_INFORMATION............................................................................................. 34 4.3.1 Description .......................................................................................................................... 34 4.3.2 Structure .............................................................................................................................. 35 4.4 $ATTRIBUTE_LIST.................................................................................................................. 36 4.4.1 Description .......................................................................................................................... 36 4.4.2 Structure .............................................................................................................................. 36 4.5 $FILE_NAME .............................................................................................................................. 37 4.5.1 Description .......................................................................................................................... 37 4.6 $OBJECT_ID.............................................................................................................................. 38 4.6.1 Description .......................................................................................................................... 38 4.6.2 Structure .............................................................................................................................. 38 4.7 $SECURITY_DESCRIPTOR.................................................................................................. 39 4.7.1 Description .......................................................................................................................... 39 4.7.2 Structure .............................................................................................................................. 39 4.8 $VOLUME_NAME...................................................................................................................... 41 4.8.1 Description .......................................................................................................................... 41 4.9 $VOLUME_INFORMATION.................................................................................................. 41 4.9.1 Description .......................................................................................................................... 41 4.9.2 Structure .............................................................................................................................. 41 4.10 $DATA......................................................................................................................................... 42 4.10.1 Description....................................................................................................................... 42 4.10.2 Structure........................................................................................................................... 43 4.11 $INDEX_ROOT......................................................................................................................... 43 4.11.1 Description....................................................................................................................... 43 4.11.2 Structure........................................................................................................................... 44 4.12 $INDEX_ALLOCATION ........................................................................................................ 45 4.12.1 Description....................................................................................................................... 45 4.12.2 Structure........................................................................................................................... 46 4.13 $BITMAP................................................................................................................................... 47 4.13.1 Description....................................................................................................................... 47 4.13.2 Structure........................................................................................................................... 47 4.14 $REPARSE_POINT................................................................................................................. 47 4.14.1 Description....................................................................................................................... 47 4.14.2 Structure........................................................................................................................... 48 4.15 $EA_INFORMATION............................................................................................................. 49 4.15.1 Description....................................................................................................................... 49 4.15.2 Structure........................................................................................................................... 50 4.16 $EA............................................................................................................................................... 50 4.16.1 Description....................................................................................................................... 50 4.16.2 Structure........................................................................................................................... 50 4.17 $LOGGED_UTILITY_STREAM.......................................................................................... 51 4.17.1 Description....................................................................................................................... 51 4.17.2 Structure........................................................................................................................... 51 5.0 ADVANCED CONCEPTS ............................................................................................................ 52 5.1 VCNS AND LCNS .......................................................................................................................... 52 5.2 DATA RUNS ................................................................................................................................... 52 5.2.1 Definition ............................................................................................................................. 52 5.2.2 Structure .............................................................................................................................. 53 5.3 SECURITY CONCEPTS................................................................................................................... 58 5.3.1 SIDs ....................................................................................................................................... 58 5.3.2 ACLs ...................................................................................................................................... 61 5.3.3 ACEs ...................................................................................................................................... 61 5.4 INDEXES ......................................................................................................................................... 61 5.5 SPARSE FILES............................................................................................................................... 61 5.6 ENCRYPTION................................................................................................................................. 61 5.7 COMPRESSION ............................................................................................................................... 61 5.8 USNS .............................................................................................................................................. 61 Download: http://www.alex-ionescu.com/NTFS.pdf Sursa: Publications « Alex Ionescu’s Blog

INTRODUCTION TO NT INTERNALS Part 1: Processes, Threads, Fibers and Jobs © 2004 Alex Ionescu Table of Contents 1. INTRODUCTION................................................................................................................ 4 2. STRUCTURES AND TERMINOLOGY........................................................................... 5 3. IMAGE FILE EXECUTION (PROCESS CREATION)................................................. 8 4. USER-MODE PROCESS STRUCTURES..................................................................... 10 4.1 PROCESS ENVIRONMENT BLOCK (PEB)................................................................... 10 4.2 PROCESS PARAMETERS BLOCK (PPB)..................................................................... 23 4.3 LOADER DATA (LDRD).............................................................................................. 28 4.4 LOADED MODULE (LDR_LM)................................................................................... 28 4.5 VARIOUS OTHER STRUCTURES (PEB_FREE_BLOCK, RTL_BITMAP).............. 30 4.6 FLAGS (GLOBAL_FLAG, KAFFINITY)................................................................. 30 4.7 GDI STRUCTURES (HANDLE_TABLE, GDI_OBJECT)....................................... 32 5. KERNEL-MODE PROCESS STRUCTURES............................................................... 34 5.1 EXECUTIVE PROCESS (EPROCESS)........................................................................ 34 5.2 KERNEL PROCESS (KPROCESS)............................................................................. 48 5.3 LPC PORT (LPC_PORT_OBJECT)........................................................................ 53 5.4 HANDLE TABLE (HANDLE_TABLE)....................................................................... 57 5.5 VIRTUAL ADDRESS DESCRIPTOR TABLE (MM_AVL_TABLE) .............................. 60 5.6 TOKEN (TOKEN) ....................................................................................................... 62 6. USER-MODE THREAD STRUCTURES....................................................................... 68 6.1 THREAD ENVIRONMENT BLOCK (PEB) .................................................................... 68 6.2 NT THREAD INFORMATION BLOCK (TIB) ................................................................ 77 6.3 MISCELLANEOUS USER-MODE STRUCTURES ........................................................... 79 7. KERNEL-MODE THREAD STRUCTURES................................................................. 81 7.1 EXECUTIVE THREAD (ETHREAD) ........................................................................... 81 7.2 KERNEL THREAD (KTHREAD) ................................................................................ 87 7.3 IMPERSONATION (PS_IMPERSIONATION_INFORMATION) ........................ 100 7.4 APC STATE (KAPC_STATE) ................................................................................. 100 8. KERNEL-MODE JOB STRUCTURE.......................................................................... 102 8.1 EXECUTIVE JOB (EJOB).......................................................................................... 102 Download: http://www.alex-ionescu.com/part1.pdf Sursa: Publications « Alex Ionescu’s Blog

Pentru a fi compilat pe Windows trebuie portat

Visual Basic Image Internal Structure Format © 2004 Alex Ionescu Table of Contents STRUCTURE RELATIONSHIP DIAGRAM .............................................................................................. 3 1. THE VB HEADER. ............................................................................................................................. 4 THREAD FLAGS .......................................................................................................................... 4 MDL INTERNAL CONTROL FLAGS............................................................................................ 5 2. THE COM REGISTRATION DATA.............................................................................................. 6 2.1 THE COM REGISTRATION INFO. ........................................................................................ 6 2.2 THE DESIGNER INFO. .......................................................................................................... 7 OBJECT TYPES.......................................................................................................................... 7 3. THE PROJECT INFORMATION.................................................................................................. 8 4. THE SECONDARY PROJECT INFORMATION..................................................................... 8 5. THE OBJECT TABLE....................................................................................................................... 9 6. THE PRIVATE OBJECT DESCRIPTOR................................................................................... 9 7. THE PUBLIC OBJECT DESCRIPTOR.................................................................................... 10 8. THE OBJECT INFO......................................................................................................................... 10 9. THE OPTIONAL OBJECT INFO................................................................................................ 11 10. THE CONTROL INFO.................................................................................................................. 11 Download: http://www.alex-ionescu.com/vb.pdf Sursa: Publications « Alex Ionescu’s Blog

Native API Compression and Introduction to NT Design Autor: Alex Ionescu Chapter 1 – How NT works, in the average programmer’s words Chapter 2 – The Native API, for a programmer Chapter 3 – The Compression Application Download: http://www.alex-ionescu.com/Native.Pdf Sursa: Publications « Alex Ionescu’s Blog

Windows XP/2003 User-Mode Debugging Internals Autor: Alex Ionescu Windows XP/2003 User-Mode Debugging Internals, Part 1 http://www.alex-ionescu.com/dbgk-1.pdf Windows XP/2003 User-Mode Debugging Internals, Part 2 http://www.alex-ionescu.com/dbgk-2.pdf Windows XP/2003 User-Mode Debugging Internals, Part 3 http://www.alex-ionescu.com/dbgk-3.pdf Sursa: Publications « Alex Ionescu’s Blog

Coding a Syn Scanner * by ithilgore * * ithilgore.ryu.L@gmail.com * * version 1.2 - March 2007 * ***************************************** ***************************************** * Coding a Syn Scanner * * by ithilgore * * ithilgore.ryu.L@gmail.com * * version 1.2 - March 2007 * ***************************************** 0x0. Index 0x1. Prologue 0x2. Syn Scanning 0x3. Tcp/ip header analysis 0x4. Raw Sockets 0x5. Libpcap/Sniffing Session 0x6. The SYN port scanner(source) 0x7. Epilogue 0x8. References -------------- 0x1. Prologue -------------- In the current article we are going to analyse the process of programming a Port Scanner which uses stealthier methods to scan its victim. In fact we shall see how a SYN scanner is made. It is not the result that counts so much, since there are already some high-quality tools in the open source community that support such a function ( see Nmap ). However, we are more interested in the process of making such a tool, a process which includes many different interesting matters of the security sector. What are these things in a few words? --Raw Sockets --Libpcap/Sniffing --Tcp/ip header analysis --The Syn Scanning itself This guide's purpose, as you will realize, is not to just plainly give the source code of the SYN Scanner ( this in fact by itself doesn't have any actual meaning since, as we have already mentioned there are such tools with an open source in public ) but to give some guidelines for someone who wants to go deeper into the Network Programming (in Unix) through the programming and analysis of the creation of this particular tool.This means that with this guide, you will constantly have to refer to man pages,RFCs etc as well as to execute other tools such as tcpdump. For someone to be able to understand the flow of this guide he will have to: a) have a good understanding of the C language have already delved into the basics of network programming ( see http://beej.us/guide/bgnet/ ) c) know some basic things about networks d) have a box installed with a unix-flavored OS ( root priviledges required ) so as to be able to experiment with the code. e) have a second box ( either as a virtual machine or real ) available (this is not required though) f) have enough free time as some concepts are quite difficult to understand in the first place Note down that the code has been successfully tested on a Slackware 11 box with kernel 2.4.33.3 ------------------ 0x2. SYN Scanning ------------------ The SYN scanning is based on a simple method called half-open connection. As we already know, when two computers communicate with each other through the TCP, the below procedure is followed: a) client ----------SYN J--------------> server client <--------SYN K / ACK J+1------ server c) client --------ACK K+1 -------------> server The above is called 3-way handshake as it goes through 3 stages of handshake: a) In the beginning, the client sends a TCP packet to the servers's port with an initial sequence (usually random). During the second stage, if the server accepts connections on this particular port, he will send as an answer a TCP packet with a sequence ACK equal to SYN+1 (we suppose the client's sequence is SYN) as well as a new SYN sequence of his own. c) In the end, the client will answer with an ACK incremented by 1 in relation to the SYN the server sent during the b part. -->In case the server's port is closed, the server sends a RST packet in the b stage and terminates the handshake. The above way is the classical way of a common port scanner, that scans through the ports that interest the attacker trying to open to each of them a full connection through the simple 3-way handshake. What a nice way for the victim's firewall or IDS to log the attack... A better solution is given by the half-open connection: a) client ----------SYN J--------------> server client <--------SYN K / ACK J+1------ server c) client ----------RST ---------------> server Which is the only difference? As you have already observed the last step during which the client who already knows that the server has sent a positive answer, instead of opening the connection fully ( the usual state: Connection Established ), sends a RST packet terminating the connection prematurely. What is the benefit? A smaller chance to alarm any security mechanism of the victim as the connection is never opened fully. This is in fact the stealth capability that the SYN scanner comes to use. Details for how it is done, below. ---------------------------- 0x3. TCP/IP header analysis ---------------------------- It is time to see more closely what exactly takes place behind the curtains. At this stage it would be a good chance to scan through the RFCs 791 ( Internet Protocol ) and 793 ( Transmission Protocol ) as their knowledge will come in handy later. The TCP header's format is shown below. In fact, the important information that every TCP packet must have is untill the Urgent Pointer, which means 20 bytes in size. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Let's see more analytically each field of the header: ------ ----- ------------ FIELD SIZE DESCRIPTION ------ ----- ------------ Source Port: (16bits) The client's Port number Destination Port: (16bits) The server's (destination) Port number Sequence Number: (32bits) The sequence number that is used for enumerating TCP packets (see 3-way handshake) Acknowledgment Number: (32bits) The answer number to the previous SYN. It stands that ACK = previous_SYN + 1 Data Offset: (4 bits) The number that defines the header's size.WARNING!-> it is counted by multiples of 32bits/4bytes. This means that when the TCP packet has nï options data_offset = 5 Reserved: (6 bits) Just reserved, these bits are all 0 Flags: (6 bits) Each flag defines a special state.(1 bit each -on/off) URG: Urgent: for fast routing ACK: Ácknowledgment: for the 2nd and 3rd stage of the 3way TCP handshake PSH: Push: the system doesn't buffer the segment into the ÉP stack RST: Reset: for immediate termination of a connection SYN: Synchronization: for a new connection and TCP handshake FIN: Final: for the normal termination of a connection ( see TCP termination) Window: (16bits) The maximum quantity of data that the client will receive Checksum: (16bits) The packet's checksum, which we shall analyze later Urgent Pointer: (16bits) It is used in combination with the urgent flag These are in a few words the TCP header's fields with which we shall be occupied below when we create our own datagram. We do not analyse each of them in depth since this is not our purpose.Instead of that we shall point out some of them later as they will be of vital importance to our SYN scanner.For more information you are encouraged to see the corresponding RFCs. But now let's see in a code level how such a TCP header would be like. /* TCP header */ typedef u_int tcp_seq; struct sniff_tcp { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ u_char th_offx2; /* data offset, rsvd */ #define TH_OFF(th) (((th)->th_offx2 & 0xf0) >> 4) u_char th_flags; #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define TH_PUSH 0x08 #define TH_ACK 0x10 #define TH_URG 0x20 #define TH_ECE 0x40 #define TH_CWR 0x80 #define TH_FLAGS (TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR) u_short th_win; /* window */ u_short th_sum; /* checksum */ u_short th_urp; /* urgent pointer */ }; As we see there is a 1 to 1 correlation between the struct's fields and the TCP header's fields. We should point out that the above struct is not the classic BSD-flavored but a style proposed by Tim Carstens -> http://www.tcpdump.org/pcap.htm ( we shall refer to pcap later if this link moved your curiosity ) A little more patience to see the IP header and then we shall look into a live example with tcpdump! The IP header then: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ ----- ------------ FIELD SIZE DESCRIPTION ------ ----- ------------ Version: (4 bits) The header's version.We are discussing IPv4 so it is 4. IHL: (4 bits) Header length: in 32bit words!! Thus the min_value = 5 (just before Options) Type of Service: (8 bits) It is used for priorities in certain services of some networks Total Length: (8 bits) Total datagram length (in bytes), that includes the ÔCP header. It shows us where the payload begins. Identification: (8 bits) A unique value of the sender in case there is need to reassembly a fragmented packet. Flags: (3 bits) bit 0: reserved 0 , bit 1:DF (don't fragment) , bit 2:MF(more fragments) sequence: b0,b1,b2 Fragment Offset: (13bits) It is used to reassembly fragmented packets. Time to Live: (8 bits) How many hops(routers) the packet can pass before it is discarded. max_value = 255 Protocol: (8 bits) /etc/protocols for info , tcp = 6 , udp = 17, icmp = 1 Header Checksum: (16bits) The checksum of the whole datagram. Later about that Source Address: (32bits) The sender's IP Destination Address: (32bits) The receiver's IP Using the same logic as in the tpc header, we write the struct of the ip header: /* IP header */ struct sniff_ip { u_char ip_vhl; /* version << 4 | header length >> 2 */ u_char ip_tos; /* type of service */ u_short ip_len; /* total length */ u_short ip_id; /* identification */ u_short ip_off; /* fragment offset field */ #define IP_RF 0x8000 /* reserved fragment flag */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* more fragments flag */ #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ u_char ip_ttl; /* time to live */ u_char ip_p; /* protocol */ u_short ip_sum; /* checksum */ struct in_addr ip_src,ip_dst; /* source and dest address */ }; #define IP_HL(ip) (((ip)->ip_vhl) & 0x0f) #define IP_V(ip) (((ip)->ip_vhl) >> 4) The 2 above headers refer to the TCP/IP, however we must not forget that the on the data link layer we've got some NICs that are "in the way". NICs huh? But of course we couldn't omit to mention the ethernet and unique MAC addresses that every network interface has. For this reason, we are going to examine one more (little) header that will be enscapsulated into the packet afterwards. This specific header will not bother us later, but it is good to know about it. Thus we have: /* ethernet headers are always exactly 14 bytes */ #define SIZE_ETHERNET 14 /* Ethernet addresses are 6 bytes */ #define ETHER_ADDR_LEN 6 /* Ethernet header */ struct sniff_ethernet { u_char ether_dhost[ETHER_ADDR_LEN]; /* destination host address */ u_char ether_shost[ETHER_ADDR_LEN]; /* source host address */ u_short ether_type; /* IP? ARP? RARP? etc */ }; Things here are quite simple: ------ ----- ------------ FIELD SIZE DESCRIPTION ------ ----- ------------ ether_dhost (6bytes) Destination's MAC address ether_shost (6bytes) Sender's H ÌÁC address ether_type (2bytes) The protocol that is directly "above" ethernet (here we've got IP) The best way for someone to understand the above concepts is a real example. So we open 2 terminals and in the first we write: root@hyena:/home/# tcpdump -i eth0 -l -n -x -vv ( where eth0 is the name of your own NIC ) while in the other terminal we telnet into a host for which we know their port 80 is open ( or some other port ) Our router's web interface would be a good example. ithilgore@hyena:~$ telnet 10.0.0.2 80 Trying 10.0.0.2... Connected to 10.0.0.2. Tcpdump's output will be something like this: tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 19:46:00.774299 IP (tos 0x10, ttl 64, id 17418, offset 0, flags [DF], proto: TCP (6), length: 60) 10.0.0.4.39507 > 10.0.0.2.80: S, cksum 0x8691 (correct), 1121958480:1121958480(0) win 5840 <mss 1460, sackOK,timestamp 7536218 0,nop,wscale 0> 0x0000: 4510 003c 440a 4000 4006 e29c 0a00 0004 0x0010: 0a00 0002 9a53 0050 42df ba50 0000 0000 0x0020: a002 16d0 8691 0000 0204 05b4 0402 080a 0x0030: 0072 fe5a 0000 0000 0103 0300 19:46:00.775223 IP (tos 0x0, ttl 64, id 14712, offset 0, flags [none], proto: TCP (6), length: 60) 10.0.0.2.80 > 10.0.0.4.39507: S, cksum 0xb576 (correct), 448057277:448057277(0) ack 1121958481 win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp 188518 7536218> 0x0000: 4500 003c 3978 0000 4006 2d3f 0a00 0002 0x0010: 0a00 0004 0050 9a53 1ab4 cfbd 42df ba51 0x0020: a012 2000 b576 0000 0204 05b4 0103 0300 0x0030: 0101 080a 0002 e066 0072 fe5a 19:46:00.775264 IP (tos 0x10, ttl 64, id 17419, offset 0, flags [DF], proto: TCP (6), length: 52) 10.0.0.4.39507 > 10.0.0.2.80: ., cksum 0xea69 (correct), 1:1(0) ack 1 win 5840 <nop,nop,timestamp 7536219 188518> 0x0000: 4510 0034 440b 4000 4006 e2a3 0a00 0004 0x0010: 0a00 0002 9a53 0050 42df ba51 1ab4 cfbe 0x0020: 8010 16d0 ea69 0000 0101 080a 0072 fe5b 0x0030: 0002 e066 3 packets ... rings a bell? As you will have already guessed this is the 3way TCP handshake. Let's take one to one the values of the packets to find a correspondence with the headers that we saw above. 1st packet: ( it begins with the IP header ) 0x0000: 4510 003c 440a 4000 4006 e29c 0a00 0004 4510: 4 = version , 5 = header length , 10 = type of service , 003c: 003c = total length ( 0x3c = 60d ) thus we know where the payload begins 440a: 440a = identification 4000: 4006 = 010 | 0 0000 0000 0110 where the 3 MSB is the flag field ( so we have DF flag which we see in tcpdump ) - the rest 13 bit are the fragment offset field 4006: 40 = time to live ( 64d ) , 06 = protocol number ( we said that TCP is 6d ) e29c: the header checksum 0a00: The first part of the Source IP address ( 10.0 ) 0004: The second and last part of the Source IP address ( 0.4 ) so 10.0.0.4 0x0010: 0a00 0002 9a53 0050 42df ba50 0000 0000 0a00: First part of the Destination IP address ( 10.0 ) 0002: Second part Destination IP address ( 0.2 ) so 10.0.0.2 -----------------end of IP header/ beginning TCP header-------------------------- 9a53: Source Port ( 0x9a53 = 39507d ) 0050: Destination Port ( 0x0050 = 80d ) 42df: First part of sequence number ( we send SYN ) ba50: Second part of seq number , so: seq = 0x42df ba50 = 1121958480d 0000: First part of ACK 0000: Second part of ACK: we don't have an ACK as in the first packet we just initiate ôï connection 0x0020: a002 16d0 8691 0000 0204 05b4 0402 080a a002: a = data offset (here because of telnet we've got some options so 0xa = 10d != 5d = min_value(no options/data)), 002 = 0000 00 | 00 0010 the 6 MSB are the reserved 0, the rest are flags where we have the 2nd LSB ON (SYN flag) 16d0: window size 8691: datagram checksum ( keep that in mind ) 0000: urgent pointer , ( it doesn't exist in our case ) ---------------from here on follow options and data that we do not interest us--- 0204: <> 05b4: <> 0402: <> 080a: <> Analysing the above we see an analogy with the headers that we studied before. Let's see some more things about the 2 next packets to verify the 3way handshake: 2nd packet: 0x0000: 4500 003c 3978 0000 4006 2d3f 0a00 0002 0x0010: 0a00 0004 0050 9a53 1ab4 cfbd 42df ba51 0x0020: a012 2000 b576 0000 0204 05b4 0103 0300 0x0030: 0101 080a 0002 e066 0072 fe5a Here the values are nearly the same. Where one should focus is on the 42df ba51 Maybe it looks like something we saw before? It is the previous Syn Sequence + 1 and resides in the field of the Acknowledgment Number of the TCP header. So we verified that ACK = previousSYN + 1. Before that let's keep in our memory ( or on the clipboard for those who can't ) the number 1ab4 cfbd which corresponds to the Sequence Number of the current packet. Now let's go and see the 3rd packet and specifically the seq and ack values 3rd packet: 0x0000: 4510 0034 440b 4000 4006 e2a3 0a00 0004 0x0010: 0a00 0002 9a53 0050 42df ba51 1ab4 cfbe 0x0020: 8010 16d0 ea69 0000 0101 080a 0072 fe5b 0x0030: 0002 e066 Here we have Sequence Number = 42df ba51 = previous_ACK (not the essence) and also ACK = 1ab4 cfbe = previoysSYN + 1 Maybe we should remind the graph? a) client ----------SYN J--------------> server client <--------SYN K / ACK J+1------ server c) client --------ACK K+1 -------------> server This about the TCP/IP packet analysis. Don't hesitate to re-read the points that you didn't understand and experiment with other examples on tcpdump. ( reading in parallel it's man pages ) ----------------- 0x4. Raw Sockets ----------------- To be able to construct a SYN scanner we will need to explicitly send our own packet with a SYN flag ON and then see if the answer we get is ACK or RST. How do we construct our own datagram? Enter Raw Sockets. Raw Sockets are nothing more than the capability of constructing our own Network Datagram ( ICMP ,TCP,IP,IGMP ) We know that TCP corresponds to the Transport Layer of the OSI model while IP belongs to the Network Layer both of which are normally managed by the kernel of the operating system. When an application needs to open a new connection with a server, then the usual way to do this is the sockets interface which allows us in a limited extent to set the conditions and parameters under which this connection will take place. In a figure: OSI TCP Layer 7: Application layer -application- | Layer 6: Presentation layer -application- <-| user process Layer 5: Session layer -application- __________________________ sockets interface / raw sockets--| Layer 4: Transport layer <---------> TCP/UDP | <-------| Layer 3: Network layer <---------> IPv4/IPv6 <-| kernel Layer 2: Data Link layer <---------> BPF/DLPI/drivers | Layer 1: Physical layer hardware Raw sockets in contrast to the plain interface give us the potential to define ourselves exactly what the datagram we shall send will be like. We define a raw socket as: int sockfd; sockfd = socket(AF_INET, SOCK_RAW, protocol); where protocol is one of the constants from the <netinet/in.h> header It is also important to set the socket option of IP_HDRINCL which allows us to define the IP header however we like. const int on; if ( setsockopt ( sockfd , IPPROTO_IP , IP_HDRINCL , &on , sizeof(on)) < 0 ) error It should be noted down that for the creation of a raw socket we need root priviledges. From the moment we know the headers' formats that we saw in section 0x3, it is relevantly easy to create the datagram we want: int sockfd,i; struct sockaddr_in sin; char datagram[4096]; // buffer for datagrams struct sniff_ip *iph = (struct sniff_ip *) datagram; struct sniff_tcp *tcph = (struct sniff_tcp *) (datagram + sizeof (struct sniff_ip)); sockfd = socket (AF_INET, SOCK_RAW, IPPROTO_TCP) ; sin.sin_family = AF_INET; sin.sin_port = htons (i); memset (datagram, 0, 4096); /* zero out the buffer */ iph->ip_vhl = 0x45; /* version=4,header_length=5 (no data) */ iph->ip_tos = 0; /* type of service not needed */ iph->ip_len = sizeof (struct sniff_ip) + sizeof (struct tcphdr); /* no payload */ iph->ip_id = htonl (54321); /*simple id*/ iph->ip_off = 0; /*no fragmentation*/ iph->ip_ttl = 255; /*Time to Live -> set maximum value*/ iph->ip_p = IPPROTO_TCP; /* 6 as a value - see "/etc/protocols" */ iph->ip_src.s_addr = ipP->sin_addr.s_addr; /*local device IP */ iph->ip_dst.s_addr = sin.sin_addr.s_addr; /*destination address*/ iph->ip_sum = 0; /*no need to fill ip checksum- kernel does that*/ tcph->th_sport = htons (1234); /* arbitrary port */ tcph->th_dport = htons (i); /* scanned destination port */ tcph->th_seq = random (); /* the random SYN sequence */ tcph->th_ack = 0; /* No ACK needed */ tcph->th_offx2 = 0x50; /* 50h (5 offset) ( 8 0s reserverd )*/ tcph->th_flags = TH_SYN; /* initial connection request FLAG*/ tcph->th_win = (65535); /* maximum allowed window size*/ tcph->th_sum = 0; /* will compute later */ tcph->th_urp = 0; /* no urgent pointer */ { int one = 1; const int *val = &one; if (setsockopt (sockfd, IPPROTO_IP, IP_HDRINCL, val, sizeof (one)) < 0) printf ("Warning: Cannot set HDRINCL for port %d\n",i); } Now that our datagram is ready, the only thing that is left is to send it: if (sendto (sockfd ,datagram, iph->ip_len , 0, (struct sockaddr *) &sin, sizeof (sin)) < 0) { printf ("Error sending datagram for port %d\n",i); } We used here a simple i variable for the victim's port. Putting all the above inside a loop we can send SYN packets to any port we are interested in. There is still something missing though... because we left one important value undefined and without it our packet will be DROPed by an receiver!! For those who haven't understood yet, we are talking about the TCP checksum field. The algorithm is described in analysis in RFC 1071 but in a few words it goes as follows: We make 16bit words from the bytes that will be checksumed and we calculate their sum in a 1's complement form. That is what the function below implements: uint16_t checksum_comp ( uint16_t *addr , int len ) { /* compute TCP header checksum */ /* with the usual algorithm a bit changed */ /* for byte ordering problem resolving */ /* RFC 1071 for more info */ /* Compute Internet Checksum for "count" bytes * beginning at location "addr". */ register long sum = 0; int count = len; uint16_t temp; while( count > 1 ) { temp = htons(*addr++); // in this line:added -> htons sum += temp; count -= 2; } /* Add left-over byte, if any */ if( count > 0 ) sum += * (unsigned char *) addr; /* Fold 32-bit sum to 16 bits */ while (sum>>16) sum = (sum & 0xffff) + (sum >> 16); uint16_t checksum = ~sum; return checksum; } What is not so clearly documented is that the TCP checksum mustn't be calculated only on the tcp header but it MUST be calculated along with a pseudo-header that contains the following info: struct pseudo_hdr { u_int32_t src; /* 32bit source ip address*/ u_int32_t dst; /* 32bit destination ip address */ u_char mbz; /* 8 reserved bits (all 0) */ u_char proto; /* protocol field of ip header */ u_int16_t len; /* tcp length (both header and data */ }; Thus we will have to write: struct pseudo_hdr *phdr = (struct pseudo_hdr *) ( datagram + sizeof(struct sniff_ip) + sizeof(struct sniff_tcp) ) ; phdr->src = iph->ip_src.s_addr; phdr->dst = iph->ip_dst.s_addr; phdr->mbz = 0; phdr->proto = IPPROTO_TCP; phdr->len = ntohs (0x14); tcph->th_sum = htons ( checksum_comp ( (unsigned short *) tcph , sizeof(struct pseudo_hdr)+sizeof(struct sniff_tcp))); Attention is needed in fields that will need to be converted to network byte order (big endian) from host byte order (little endian or big endian depending on the box) calling the respective functions htonl or htons as well as their opposites ntohs or ntohl. Sometimes it may be necessary to experiment, like the writer when he calculated the checksum manually. Here is a good point to use the values that tcpdump had given us in the previous section for the tcp checksum field and to verify it manually by calculating the 1's sums of the bytes of the tcp + pseudo headers. --------------------------------- 0x5. libpcap /sniffing session --------------------------------- Given that we have sent the SYN packets, we will need to examine the victim's reply to record which ports it has open. The question is if we can use an equal logic like the one we use in plain sockets. The answer is no. The kernel does never pass TCP ( and UDP ) packets to a raw socket. This is not entirely true for every kernel since Linux implements raw sockets in another way and we could sniff a TCP reply without having to use something else. However a call for portability denotes that we are not going to use this unportable way. This means that we are not going to read the victim's answer with such a traditional way like the sockets API. We will need access to the datalink layer itself! The 3 most common methods to do something like this in a Unix environment are: a) BPF (berkley packet filter) DLPI (SVR4 Datalink Provider Interface) c) SOCK_PACKET interface óôï Linux The bad thing about these methods is that they are platform-dependent and thus reduce portability. Here libpcap gives the solution - the packet capture library. Now is the right time to visit the link that we have mentioned before as a credit to Tim Carstens: http://www.tcpdump.org/pcap.htm Tcpdump itself has been written with this library, proof of the possibilities that it provides us. For someone to be able to continue smoothly here on, he will need to take a good look at the man pages of the library (online version here -> www.tcpdump.org/pcap3_man.html) and especially at the functions: int pcap_findalldevs(pcap_if_t **alldevsp, char *errbuf) char *pcap_lookupdev(char *errbuf) int pcap_lookupnet(const char *device, bpf_u_int32 *netp, bpf_u_int32 *maskp, char *errbuf) int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, bpf_u_int32 netmask) int pcap_setfilter(pcap_t *p, struct bpf_program *fp) pcap_t *pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, char *errbuf) int pcap_dispatch(pcap_t *p, int cnt, pcap_handler callback, u_char *user) int pcap_loop(pcap_t *p, int cnt, pcap_handler callback, u_char *user) void pcap_breakloop(pcap_t *) The first thing we need to do is find which devices are available in our own box and use one of them for sniffing in the datalink layer. Maybe you have already realized which function is appropriate for this job: pcap_if_t *alldev; if ((pcap_findalldevs (&alldev, errbuf)) == -1) { printf ( "%s\n" , errbuf ); exit(-1); } After we find one device and an available IP that represents it ( the default case is usually one IP per device ), we can begin the sniffing session calling pcap_t *pcap_open_live(const char *device, int snaplen, int promisc, int to_ms, char *errbuf) which returns a pointer to a pcap session id that is defined as pcap_t. The function's parameters can even be guessed from their names: char *device: the device we found with pcap_findalldevs() and we are going to use in the session int snaplen: the maximum size of bytes for every packet that we will sniff - 65535 is more than enough int promisc: 1 or 0 , promiscuous or not , hate mail from net admin or not etc int to_ms: read timeout in ms for the platforms that support it - it doesn't interest us char *errbuf: the buffer that holds all libpcap errors After we open the session, we are going to apply filtering. The biggest convenience that the library provides us with are the filters, that are described analytically by the tcpdump manpages (online version here-> http://www.tcpdump.org/tcpdump_man.html ). We filter the network traffic to the specific information that we are interested in and analyse each packet for the fields that interest us. In our case we need to see only the victim's reply. Consequently our filter will be of the form: src host ip where ip is the address of the victim. We go on with the filter's compilation: int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, bpf_u_int32 netmask) pcap_t *p: our session struct bpf_program *fp: the struct into which the compiled filter will be saved char *str: the filter expression , thus src host ip The rest 2 options, we shall not need ( int optimize , bpf_u_int32 netmask ) - 0 both The last step for our sniff engine is the application of the filter: int pcap_setfilter(pcap_t *p, struct bpf_program *fp) as for the 2 options, you can understand yourselves what they are, if you have read the above well enough. Now that our engine is ready the only thing that needs to be done is to power it on. Essentially this is done with one of these: int pcap_dispatch(pcap_t *p, int cnt, pcap_handler callback, u_char *user) Þ int pcap_loop(pcap_t *p, int cnt, pcap_handler callback, u_char *user) You can refer to the man pages to see the subtle difference between the two but this is not so important for the scanner. The pcap_handler is the function that we have defined to process each packet that is captured by the engine. Maybe we forgot our purpose? What we need to examine is if the victim has sent a reply with the SYN and ACK flags ON: if ( ( (tcp->th_flags & 0x02) == TH_SYN) && ( tcp->th_flags & 0x10 ) == TH_ACK )) { //PORT OPEN !!! } In the opposite case the victim replies with a RST, so we can say with nearly absolute certainty that the port is closed. There is always the possibility that the packets will be DROPed for 0xE2A reasons (1002d) during the course either from the host itself or from a firewall or other gateway, so in that case we define the port's state as unknown/filtered. We have taken precautions though, with an internal timeout through a SIGALRM that is triggered by an alarm() and a signal handler to be able to escape the immobility that our central pcap_dispatch necessarily has ( it needs to work in blocking mode ) and to go on with the scanning of the rest of the ports. The 3rd step of the SYN scanning is needed though, isn't it? Shouldn't we also send a RST to the receiver if he replies us positively? It seems that the kernel itself (not so oddly) helps us in this situation by automatically sending a RST packet to the victim in that case. Attention though, since this might be different from operating system to operating system and it might be needed to send our own explicitly. In that case, what you need only do is to complete with your own code the explicit sending of the TCP datagram with RST on. If you have understood and studied all the above, it may not seem so difficult now. Another piece of our scanner has just been finished. It is time to put it all together. Combining then all the above we make our SYN scanner. ---------------------------------- 0x6. The SYN port scanner (source) ---------------------------------- -------------- 0x7. Epilogue -------------- If you have managed so far and studied the source coude, then well done. I hope that you have learned something through all this guide and that it aroused your interest for the sector of network programming and security applications/tools on which is based. Like I mention in the source 's introduction I will value any feedback and I encourage you to make your own changes and improvements on the code, as I believe that as a whole it just sets the base for a custom security scanner. Possible expansions for the tool: 1) IP spoofing capabilities 2) Real time port randomization 3) Alternate probing and IP expiry tactics For any ( serious ) contact about the project mail me here -> ithilgore.ryu.L@gmail.com ---------------- 0x8. References ---------------- -UNIX Network Programming Volume 1, Third Edition: The Sockets Networking API -http://mixter.void.ru/rawip.html (raw sockets tutorial) -http://www.netfor2.com/checksum.html (IP checksum introduction) -http://www.tcpipguide.com/free/t_TCPChecksumCalculationandtheTCPPseudoHeader.htm (TCP checksum and pseudo header) RFCs -http://www.ietf.org/rfc/rfc0791.txt (IP) -http://www.ietf.org/rfc/rfc0793.txt (TCP) -http://www.ietf.org/rfc/rfc1071.txt (Checksum) -http://www.tcpdump.org (libpcap + tcpdump) --EOF-- Sursa scanner: http://rstcenter.com/forum/34495-syn-port-scanner-source.rst Articol: http://sock-raw.org/papers/syn_scanner

SYN port scanner (source) version 1.2 by ithilgore ithilgore.ryu.L@gmail.com /****************************************************************************/ /* Creeper - a simple Syn Scanner */ /* minimalistic port scanner for educational purposes */ /* Copyright (C) 2007 ithilgore - ithilgore.ryu.L@gmail.com */ /* */ /* This program is free software: you can redistribute it and/or modify */ /* it under the terms of the GNU General Public License as published by */ /* the Free Software Foundation, either version 3 of the License, or */ /* (at your option) any later version. */ /* */ /* This program is distributed in the hope that it will be useful, */ /* but WITHOUT ANY WARRANTY; without even the implied warranty of */ /* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the */ /* GNU General Public License for more details. */ /* */ /* You should have received a copy of the GNU General Public License */ /* along with this program. If not, see <http://www.gnu.org/licenses/>. */ /* */ /****************************************************************************/ /****************************************************************************/ /* Creeper */ /* version 1.2 */ /* by ithilgore */ /* ithilgore.ryu.L@gmail.com */ /* */ /* compile with: gcc creeper.c -lpcap -o creeper */ /* some compilers may also need -fpack-struct */ /* */ /* Use of this code is for educational purposes only. I am not responsible */ /* for any illegal or criminal activities performed with this tool or */ /* any modifications of it. */ /* This tool is free and open software. This means you can do anything you */ /* like with it with your own responsibility and with no warranty from me. */ /* to the source. */ /* */ /* This tool has been tested so far and works sucessfully in: */ /* ----Slackware 11 with kernel 2.2.4.33 */ /* ----Arch Linux (Core Dump) kernel 2.6.23 */ /****************************************************************************/ #include <stdio.h> #include <stdlib.h> #include <string.h> #include <errno.h> #include <netdb.h> #include <arpa/inet.h> #include <sys/types.h> #include <sys/socket.h> #include <unistd.h> #include <pcap.h> #include <signal.h> #define BUFSIZE 65535 //maximum size of any datagram(16 bits the size of identifier) #define TRUE 1 #define FALSE 0 #define default_low 1 #define default_high 1024 /* change the timeout at will * it defines how long the scanner will wait for * an answer from the scanned host * careful though - testing shows < 4 is bad * it is just another factor between speed and accuracy */ #define DEFAULT_S_TIMEOUT 5 /* default snap length (maximum bytes per packet to capture) */ #define SNAP_LEN 1518 /* ethernet headers are always exactly 14 bytes */ #define SIZE_ETHERNET 14 /* Ethernet addresses are 6 bytes */ #define ETHER_ADDR_LEN 6 /* USING TCPDUMP-like header structs */ /* Ethernet header */ struct sniff_ethernet { u_char ether_dhost[ETHER_ADDR_LEN]; /* destination host address */ u_char ether_shost[ETHER_ADDR_LEN]; /* source host address */ u_short ether_type; /* IP? ARP? RARP? etc */ }; /* IP header */ struct sniff_ip { u_char ip_vhl; /* version << 4 | header length >> 2 */ u_char ip_tos; /* type of service */ u_short ip_len; /* total length */ u_short ip_id; /* identification */ u_short ip_off; /* fragment offset field */ #define IP_RF 0x8000 /* reserved fragment flag */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* more fragments flag */ #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ u_char ip_ttl; /* time to live */ u_char ip_p; /* protocol */ u_short ip_sum; /* checksum */ struct in_addr ip_src,ip_dst; /* source and dest address */ }; #define IP_HL(ip) (((ip)->ip_vhl) & 0x0f) #define IP_V(ip) (((ip)->ip_vhl) >> 4) /* TCP header */ typedef u_int tcp_seq; struct sniff_tcp { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ u_char th_offx2; /* data offset, rsvd */ #define TH_OFF(th) (((th)->th_offx2 & 0xf0) >> 4) u_char th_flags; #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define TH_PUSH 0x08 #define TH_ACK 0x10 #define TH_URG 0x20 #define TH_ECE 0x40 #define TH_CWR 0x80 #define TH_FLAGS (TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR) u_short th_win; /* window */ u_short th_sum; /* checksum */ u_short th_urp; /* urgent pointer */ }; /* pseudo header used for tcp checksuming * a not so well documented fact ... in public */ struct pseudo_hdr { u_int32_t src; u_int32_t dst; u_char mbz; u_char proto; u_int16_t len; }; /* Global Variables */ int verbose_mode; int stealth_mode; /* Syn Scanning */ int s_timeout; /* timeout seconds for Syn Scanning */ long int low_port = default_low; long int high_port = default_high; char *ipArg = NULL; pcap_t *session; /* Function Prototypes */ void got_packet(u_char *args, const struct pcap_pkthdr *header, const u_char *packet); void print_usage(const char *argv); int check_Port(long *lport, long *hport, char *optar); uint16_t checksum_comp(uint16_t *addr, int len); pcap_t* EnginePreparing(char *vicIP, struct sockaddr_in **ipP, pcap_t *session); struct hostent* host_resolve(void); void Syn_Scanning(void); void Connect_Scanning(void); void sigfunc(int); /* Function Prototypes end*/ /********************************MAIN PROGRAM********************************/ int main(int argc, char *argv[]) { if ( argc == 1 ) { print_usage( argv[0] ); exit(0); } int opt; while ( (opt = getopt(argc , argv , "h:vp:S") ) != -1 ) { switch (opt) { case 'h': ipArg = optarg; break; case 'v': verbose_mode = TRUE; break; case 'p': check_Port (&low_port, &high_port, optarg); break; case 'S': stealth_mode = TRUE; break; case '?': fprintf (stderr, "option inconsistency : -%c \n" "see usage(no arguments)\n", optopt); exit(EXIT_FAILURE); } } if (ipArg == NULL){ fprintf(stderr, "No host given-see usage(no arguments)\n" ); exit(EXIT_FAILURE); } if (!stealth_mode) { Connect_Scanning(); } else { if (getuid() && geteuid()) { fprintf(stderr, "Need to be root to initiate Syn Scanning\n"); exit(EXIT_FAILURE); } Syn_Scanning(); } exit(EXIT_SUCCESS); } void print_usage(const char *argv) { fprintf(stdout, "Port Scanner by ithilgore\n" "usage: %s -h Host [OPTIONS]\n" "Host -> IP or Name\n" "OPTIONS include:\n" "-v : verbose mode\n" "-p : port range (eg. -p23 , -p0-1024)\n" "-S : stealth mode on ( syn scanning )\n" "more options to be included\n\n" , argv); } int check_Port (long *lport, long *hport, char *optar) { char *s1 = optar ; //point to the char after 'p' errno = 0; *lport = strtol(s1, (char **)NULL, 10); if (errno != 0) { perror ("Port number problem \n"); exit(0); } if (!(s1 = index(s1, '-'))) { //if no port range specified (no other '-' found) *hport = *lport; return 0; } else { *hport = strtol(++s1, NULL, 10) ; if (errno != 0) { perror("Port number problem \n"); exit(0); } if (low_port > high_port) { fprintf(stdout, "low_port is higher than high_port: swapping...\n"); *lport ^= *hport; *hport ^= *lport; *lport ^= *hport; } } } struct hostent* host_resolve(void) { struct hostent *hostname; extern char * ipArg; if (!(hostname = gethostbyname(ipArg))) { fprintf (stderr, "Host name resolution failed for %s \n" "Try using the nslookup prog to find the IP address\n", ipArg); exit(EXIT_FAILURE); } if (verbose_mode) { fprintf(stdout, "Host Resolution results:\n" "Name: %s\n" "Aliases:", hostname->h_name); char **alias = hostname->h_aliases; while(*alias) { fprintf(stdout, "%s ", *alias); alias++; } char **addrs = hostname->h_addr_list; fprintf(stdout, "\nIP address/es:\n"); while(*addrs) { fprintf(stdout, " %s ", inet_ntoa(*(struct in_addr *)*addrs)); addrs++; } printf("\n"); } return hostname; } void Connect_Scanning(void) { int sockfd; char temp_addr[7]; struct sockaddr_in sockaddr; struct servent *serv; struct hostent * hostname; hostname = (struct hostent *)host_resolve(); char **addr = hostname->h_addr_list; /* transfer of dotted-decimal IP of first IP from resolving */ strcpy (temp_addr, inet_ntoa(*(struct in_addr *)*addr)); fprintf(stdout, "Initiating Connect() Scan against %s [%ld ports] \n", temp_addr, (high_port-low_port+1)); int i = 0; for (i = low_port; i <= high_port; i++) { if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) == -1) { perror("Socket error"); exit(EXIT_FAILURE); } sockaddr.sin_family = AF_INET; sockaddr.sin_port = htons(i); inet_pton(AF_INET, temp_addr, &sockaddr.sin_addr); if (!connect(sockfd, (struct sockaddr*)& sockaddr, sizeof(sockaddr))) { serv = getservbyport(htons(i), "tcp"); fprintf(stdout, "TCP port %d open , possible service: %s\n", i, serv->s_name); } close(sockfd); } fprintf(stdout, "Connect Scanning completed\n"); } void sigfunc(int signum) { /* signal handler */ pcap_breakloop(session); } void Syn_Scanning(void) { s_timeout = DEFAULT_S_TIMEOUT; /* global var for timeout */ int sockfd; int timeout = 0; /* check if timeout with return from dispatch */ char temp_addr[16]; struct sockaddr_in sin; struct servent *serv; struct hostent *hostname; struct sockaddr_in *ipP; /* local ip storage */ hostname = (struct hostent *)host_resolve(); char **addr = hostname->h_addr_list; strncpy(temp_addr, inet_ntoa(*(struct in_addr *)*addr), 16); char datagram[4096]; // buffer for datagrams struct sniff_ip *iph = (struct sniff_ip *)datagram; /* tcp header begins right after the end of the ip header */ /* can it work in reverse ? Of course not */ struct sniff_tcp *tcph = (struct sniff_tcp *)(datagram + sizeof(struct sniff_ip)); struct sigaction act; act.sa_handler = sigfunc; sigemptyset(&act.sa_mask); act.sa_flags = 0; /* read man of libpcap -> SA_RESTART MUST BE OFF */ /* Prepare the Sniffing Engine */ session = (pcap_t *)EnginePreparing(temp_addr, &ipP, session); fprintf(stdout, "Initiating Syn Scanning against %s [%ld ports] \n", temp_addr, (high_port-low_port+1)); int i = 0; for (i = low_port; i <= high_port; i++) { if ((sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) < 0) { perror("sock:"); exit(EXIT_FAILURE); } sin.sin_family = AF_INET; inet_pton(AF_INET, temp_addr, &sin.sin_addr); memset(datagram, 0, 4096); /* zero out the buffer */ iph->ip_vhl = 0x45; /* version=4,header_length=5 (no data) */ iph->ip_tos = 0; /* type of service -not needed */ iph->ip_len = sizeof (struct sniff_ip) + sizeof (struct sniff_tcp); /* no payload */ iph->ip_id = htonl(54321); /* simple id */ iph->ip_off = 0; /* no fragmentation */ iph->ip_ttl = 255; /* time to live - set max value */ iph->ip_p = IPPROTO_TCP; /* 6 as a value - see /etc/protocols/ */ iph->ip_src.s_addr = ipP->sin_addr.s_addr; /*local device IP */ iph->ip_dst.s_addr = sin.sin_addr.s_addr; /* dest addr */ iph->ip_sum = /* no need for ip sum actually */ checksum_comp( (unsigned short *)iph, sizeof(struct sniff_ip)); tcph->th_sport = htons(1234); /* arbitrary port */ tcph->th_dport = htons(i); /* scanned dest port */ tcph->th_seq = random(); /* the random SYN sequence */ tcph->th_ack = 0; /* no ACK needed */ tcph->th_offx2 = 0x50; /* 50h (5 offset) ( 8 0s reserverd )*/ tcph->th_flags = TH_SYN; /* initial connection request */ tcph->th_win = (65535); /* maximum allowed window size */ tcph->th_sum = 0; /* will compute later */ tcph->th_urp = 0; /* no urgent pointer */ /* pseudo header for tcp checksum */ struct pseudo_hdr *phdr = (struct pseudo_hdr *) (datagram + sizeof(struct sniff_ip) + sizeof(struct sniff_tcp)); phdr->src = iph->ip_src.s_addr; phdr->dst = iph->ip_dst.s_addr; phdr->mbz = 0; phdr->proto = IPPROTO_TCP; phdr->len = ntohs(0x14); /* in bytes the tcp segment length */ /*- WhyTF is it network byte saved by default ????*/ tcph->th_sum = htons(checksum_comp((unsigned short *)tcph, sizeof(struct pseudo_hdr)+ sizeof(struct sniff_tcp))); int one = 1; const int *val = &one; if (setsockopt(sockfd, IPPROTO_IP, IP_HDRINCL, val, sizeof (one)) < 0) fprintf(stderr, "Warning: Cannot set HDRINCL for port %d\n",i); if (sendto(sockfd, datagram, iph->ip_len, 0, (struct sockaddr *)&sin, sizeof(sin)) < 0) { fprintf(stderr, "Error sending datagram for port %d\n", i); break; } sigaction (SIGALRM, &act, 0); alarm(s_timeout); // give port as argument to callback function timeout = pcap_dispatch(session, -1, got_packet, (u_char *)i); alarm(0); /* trigger off alarm for this loop */ if (verbose_mode && timeout == -2) { fprintf(stdout, "timeout for port %d\n", i); } } fprintf(stdout, "SYN Scanning completed\n"); } uint16_t checksum_comp (uint16_t *addr, int len) { /* compute TCP header checksum */ /* with the usual algorithm a bit changed */ /* for byte ordering problem resolving */ /* see RFC 1071 for more info */ /* Compute Internet Checksum for "count" bytes * beginning at location "addr". */ register long sum = 0; int count = len; uint16_t temp; while (count > 1) { temp = htons(*addr++); // in this line:added -> htons sum += temp; count -= 2; } /* Add left-over byte, if any */ if(count > 0) sum += *(unsigned char *)addr; /* Fold 32-bit sum to 16 bits */ while (sum >> 16) sum = (sum & 0xffff) + (sum >> 16); uint16_t checksum = ~sum; return checksum; } pcap_t* EnginePreparing (char * vicIP, struct sockaddr_in **ipP, pcap_t *session) { char *dev; char errbuf[PCAP_ERRBUF_SIZE]; bpf_u_int32 devip, netmask; struct pcap_pkthdr header; struct bpf_program filter; /* compiled filter */ char filter_exp[30] = "src host "; /* we filter the traffic to the victim */ pcap_if_t *alldev; /* yes some numbers are HARDCODED as they should be */ /* guess why and then try exploiting it */ strncpy((char *)filter_exp+9, vicIP, 16); fprintf(stdout, "filter exp: %s \n ", filter_exp); if ((pcap_findalldevs(&alldev, errbuf)) == -1) { fprintf (stderr, "%s\n", errbuf); exit(EXIT_FAILURE); } struct pcap_addr *address = alldev->addresses; address = address->next; /*first address is U(F)O*/ struct sockaddr_in * ip; while (address) { if (address->addr) { ip = (struct sockaddr_in *) address->addr; fprintf (stdout, "Local IP: %s \n", inet_ntoa(ip->sin_addr)); } address = address->next; } *ipP = (struct sockaddr_in *)alldev->addresses->next->addr; /* local ip to be used in the raw datagram */ /* choose the first you find -there was some problem when choosing the last * ip since the last found might be 0.0.0.0 and thus chaos would occur */ dev = alldev->name; /*if ( (dev = pcap_lookupdev(errbuf)) == NULL) { printf ( "%s\n" , errbuf ) ; printf ( "Using default eth0 \n"); dev = "eth0" ; }*/ if (verbose_mode) { fprintf (stdout, "Using local IP: %s \n", inet_ntoa((*ipP)->sin_addr)); fprintf(stdout, "Using local Device: %s\n", dev); } if ((session = pcap_open_live (dev, BUFSIZE, 0, 0, errbuf)) == NULL) { fprintf (stderr, "Could not open device %s: error: %s \n ", dev, errbuf); exit (EXIT_FAILURE); } if (pcap_compile(session, &filter, filter_exp, 0, 0) == -1) { fprintf (stderr, "Couldn't parse filter %s: %s \n ", filter_exp, pcap_geterr(session)); exit (EXIT_FAILURE); } if (pcap_setfilter(session, &filter) == -1) { fprintf (stderr, "Couldn't install filter %s: %s\n", filter_exp, pcap_geterr(session)); exit (EXIT_FAILURE); } return session; } void got_packet(u_char *args, const struct pcap_pkthdr *header, const u_char *packet) { const struct sniff_tcp *tcp; const struct sniff_ip *ip; const struct sniff_ethernet *ether; struct servent *serv; int size_ip; int size_tcp; ether = (struct sniff_ethernet*) (packet); ip = (struct sniff_ip *) (packet + SIZE_ETHERNET); size_ip = IP_HL(ip)*4; if (size_ip < 20) { fprintf (stderr, "Invalid IP header length: %u bytes \n", size_ip); return; } if (ip->ip_p != IPPROTO_TCP) { fprintf (stderr, "Returned Packet is not TCP protocol \n"); return; } tcp = (struct sniff_tcp*)(packet + SIZE_ETHERNET + size_ip); size_tcp = TH_OFF(tcp)*4; if (size_tcp < 20) { fprintf (stderr, " * Invalid TCP header length: %u bytes\n", size_tcp); return; } /* the actual SYN scanning (heh) : we examine if the SYN flag is on at the receiving packet(port open) */ if (((tcp->th_flags & 0x02) == TH_SYN) && (tcp->th_flags & 0x10) == TH_ACK) { serv = getservbyport ( htons((int)args), "tcp" ); fprintf (stdout, "TCP port %d open , possible service: %s\n", args, serv->s_name); // RST is sent by kernel automatically } else if ((tcp->th_flags & 0x04 ) == TH_RST && verbose_mode) { //fprintf (stdout, "TCP port %d closed\n", args ); too much info on screen } else if (verbose_mode) { //fprintf (stdout, "Port %d state unknown/filtered \n", args); } } Sursa: http://sock-raw.org/papers/syn_scanner