IS Security - PowerPoint PPT Presentation

Loading...

PPT – IS Security PowerPoint presentation | free to download - id: 5fe23a-MWRiY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

IS Security

Description:

IS Security An Overview of Computer Security Benjamin Khoo, PhD New York Institute of Technology School of Management kkhoo_at_nyit.edu Code Obfuscation We need a way to ... – PowerPoint PPT presentation

Number of Views:229
Avg rating:3.0/5.0
Slides: 86
Provided by: ben745
Learn more at: http://iris.nyit.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: IS Security


1
IS Security
  • An Overview of Computer Security
  • Benjamin Khoo, PhD New York Institute of
    Technology
  • School of Management kkhoo_at_nyit.edu

2
Acknowledgement
  • Materials for many of these slides had been
    adapted from the web and also from security-based
    companies such as Outscheme Inc., Holub
    Associates, Security Innovation, Klocwork,
    Compuware, Microsoft, Secure Software, Cigital,
    Fortify Software, SPI Dynamics, Logic Gear, etc
  • Their contributions to this set of slides is
    gratefully acknowledged.
  • Ben

3
Agenda
  • Understanding the Basics
  • Introduction
  • Security Issues
  • Application Security
  • Security Through Obfuscation
  • Summary

4
What is Computer Security?
  • Computer security is a combination of many
    protective measures taken to ensure the safety of
    the data and resources of both the owners and the
    users of the computer systems.
  • Computer security involves both keeping private
    information safe and preventing loss of
    resources.
  • Computer security concerns active attacks from
    external sources, internal abuse and inadvertent
    loss of information.

5
What is Computer Security? (2)
  • We often think of an attack as coming from a
    malicious outsider trying to wreak havoc or steal
    information. However, this is just one type of
    security vulnerability.
  • Another type of security vulnerability is failure
    to enforce restrictions on access to the data
    that are based on the authorization level of the
    user.
  • For example, not all internal employees need
    access to the same data. Providing complete
    access to all employees' health information to
    everyone in the Human Resources department is a
    security risk. In this case the application must
    provide varying access to the data, based on the
    privileges (security authorization) of the user.
    The system must also authenticate the user to
    verify their identity within the computer system.

6
What are We Protecting?
  • Protecting data
  • Integrity-Ensuring that business transaction
    data is not altered or corrupted. If something
    has been changed or modified since it was
    created, verifying that the changes are
    legitimate.
  • Confidentiality-Ensuring unauthorized access
    to information will be denied.
  • (Users Data) Privacy-For example, Web sites
    and applications should have a privacy statement
    that defines how user information will be
    handled. In addition, the producer also needs to
    put in a concerted effort to protect users data.

7
What are We Protecting? (2)
  • As intellectual property-Ensuring that asset
    such as business intelligence, source code, and
    any data related to intellectual property is
    safeguarded.
  • Availability-Ensuring that data availability
    is as expected. A denial-of-service attack or a
    natural disaster is an example of data
    availability threats.
  • Protecting network computing resources-Ensuring
    that unauthorized uses of network resources are
    denied.

8
Introduction
Area
Changes
  • Business usage of Internet and related networks
    has changed to an interconnected, transactional
    model
  • More reasons for connectivity partnerships,
    outsourcing, consumer service

Internet Usage
  • Growing in complexity
  • Outsourcing of more functions

Supply Chains
  • Have been developed, extended, or interconnected
    to support an emerging model of networked business

Applications
  • Evolving to address concerns around
  • - technology controls
  • integrity of financial data
  • privacy needs for personal information

Regulations
9
Introduction (2)
The Security Problem
83 per cent of global financial institutions
admitted their systems have been compromised in
the past year, compared to only 39 per cent in
2002. - Deloitte's 2004 Global Security Survey

Recovering from a security breach takes an
average 22 hours and causes 2 million in lost
revenues. - Aberdeen Group
Demand that providers of all software both
'shrink-wrapped' and custom demonstrate the use
of security vulnerability testing during
development. - Gartner
10
Introduction (3)
Emerging Threats
  • Todays threat is not simply hackers looking for
    computing resources, defacement opportunities, or
    simple network and host access
  • Convergence between criminal activities and
    technology leveraged attacks is here
  • Phishing attacks, data theft, identity theft
  • Todays threat is
  • Direct attacks from technologically enabled
    criminals
  • Attacks targeted at business logic and process
  • Resource target is data theft, often for
    financial gain

11
Introduction (4)
  • Secrecy ? Security.
  • Secrecy You can't find the safe.
  • Security You can't open the safe, even if you
    know
  • how it works.
  • Secret systems are never secure!
  • The best way to assure that an encryption
  • algorithm is secure is to have thousands of
  • knowledgeable people try to break it.
  • Security ? Technology
  • Security comes from well-thought-out protocols
    (in
  • the diplomatic sense).
  • Technology only gives you a means to implement
    a portion of the protocol.

12
Security is about risk and liability
  • If the cost of fixing a security breach is higher
    than the cost of writing off the loss, businesses
    will take the loss.
  • Security is all about lowering risk to a
    reasonable level, not eliminating risk.
  • Ultimately, security comes from a web of
    contracts (in the legal sense) that impose
    liability when security is compromised.
  • E.g. Insurance is an important component of
    a secure eBusiness system. (SSL ? security).

13
e-Commerce Security Example
  • Web security is an essential element that
    provides consumers and producers confidence and
    acceptance in the use of commercial applications.
    An e-commerce site needs to address the following
    security issues
  • The interactions and transactions between a
    buyer and merchant must be strictly
    confidential and data integrity must be
    preserved.
  • A buyer and merchant must be able to verify
    each others identity.
  • The transaction records must be in a form that
    will hold up in a court of law.

14
Characteristics of a Secure System
  • Access control
  • Only authorized individuals can access it.
  • Confidentiality
  • Only authorized individuals can read the text.
  • Authentication
  • The writers are who they say they are.
  • Non-repudiation
  • The writers can't claim they didn't write it.
  • Integrity
  • The document you received is the one I sent.

15
People are Human, not Stupid
  • Any system that depends on abnormal behavior is
    insecure. The following behaviors are reasonable
  • Hi. This is Fred from IT. Can I have your
    password so I can check the system?
  • I cant remember 50 passwords, so I use the
    same password everywhere.
  • At one point 80 of the passwords at Berkeley
    were characters from the Lord of the Rings.
  • I cant remember long passwords.
  • I dont have a clue what all that junk in the
    Security-Options dialog means!
  • If I enable security, I cant browse!
  • The email came from a friend and got through the
    virus check, so why cant I click on it?

16
Hackers Exploit Bugs
  • Attacks that dont exploit human factors exploit
    bugs.
  • All software has bugs in it.
  • Firewalls dont protect against bugs.
  • The more popular (pervasive) the system, the more
    people will try to attack it.
  • Bad design (e.g. activeX) is a bug.

17
Worry about the right thing!
  • Nobody intercepts credit-card transmissions on
    the internet.
  • Lots of people hack into merchant databases and
    harvest credit-card numbers by the thousand.
  • Until recently, VISA did not require credit
    card numbers to be encrypted.
  • Even now, most merchant databases are still
    not encrypted, since theres no mandatory
    audit requirement.
  • There are solutions (e.g. CitiCard single-use
    numbers)

18
Worry about the right thing(2)
  • Firewalls dont protect against denial of service
    or bug-based attacks.
  • Firewalls have bugs too!
  • If your router is your firewall, someone can
    simultaneously hack into both!
  • Typically, layered systems with multiple
    firewalls (from different vendors) are used.
  • A bug in a subroutine in an app server is behind
    all of the above, and can be accessed through all
    of them.

19
No Program is an Island
20
How long will it take?
  • Not "is it breakable?" But "how long will it
    take to break it?
  • Will the information have value at that time?
  • Consider a 4-wheel combination lock. How long to
    try every combination?
  • 10,000 possibilities (13 bits), 1 every 2
    seconds 20,000 seconds (5.5 hours)
  • 2 people, each trying ½ the codes 2.750
    hours
  • 4 people, each trying ¼ the codes 1.375
    hours
  • 10,000 people, each trying 1 code 2
    seconds

21
Cost of a Brute-Force Attack
  • Breaking a cipher is a function of
  • number of possible keys (10,000 possibilities
    13 bits)
  • cost of the hardware (number of processors)
  • time
  • Given enough time or enough money, you can crack
    anything.
  • Will the value of the text outlive the time
    required to break the encryption?

22
Risk Assessment
  • A simplistic quantitative model
  • SLE AV x EF
  • SLE Single Loss Expectancy
  • AV Asset Value
  • EF Exposure Factor (0 - 100)
  • ALE SLE x ARO
  • ALE Annualized Loss Expectancy
  • ARO Annualized Rate of Occurrence (0.0 Never
    1.0 Always this is frequency rather than
    probability).
  • E.g., a threat occurring once every 10 years has
    an ARO of 1/10 or 0.1 a threat occurring 10
    times a year has an ARO of 10.
  • Source A Guide to Building Secure Web
    Applications and Web Services, The Open Web
    Application Security Project, http//www.owasp.org

23
What Affects Security?
  • Viruses, worms, Trojan horses
  • Phishing, identity theft
  • Physical security
  • Firewalls, network security
  • Defects in platform / patches
  • Authentication / authorization
  • Application security

24
Security Attacks On the Rise
25
Security Attacks On the Rise (2)
  • Hacking tools freely available
  • Business applications exposed on internet
  • Increasing tangible and intangible costs

Network
75 percent of hacks happen at the application
Application
Database Server
Web Server
App Server
Operating System
26
Business At Risk
  • Brand and Intellectual Property losses
  • Legal / Regulatory costs
  • System abuse
  • System access denied
  • Data stolen, deleted, or modified
  • IT and end-user productivity costs

27
Security Security Security
  • Security incidents reported to CERT grew by
    2,099 between 1998 and 2002
  • Estimates put the cost of the MyDoom worm alone
    at over 4 billion
  • several new versions have surfaced on the
    Internet That could mean that bigger Doom is on
    the way

28
Poor Software quality - Root Cause of Security
Vulnerabilities
35 of all successful attacks are a result of
software defects
  • Most vulnerabilities come from software
    implementation (coding) errors (Congressional
    Testimony, Richard D. Pethia, CERT Director)
  • Traditional testing will not identify security
    problems, since it looks for predictable user
    behavior, not unpredictable hacker attacks (Watts
    Humphreys of the SEI Institute)

29
How serious are we about software quality?
  • U.S. Average Defect Rate 5.9 to 7 defects per
    thousand lines of code (Software Assessments,
    Benchmarks, and Best Practices by Capers Jones)
  • Software defects rates have increased 15 in
    1999-2000 compared to 1997-1998 (Meta
    Group,January 2002)

30
The Defenders Dilemma
  • The defender must defend all points
  • The defender can defend only against known
    attacks
  • The defender must be constantly vigilant
  • The defender must play by the rules

31
The Attackers Advantage
  • The attacker can choose the weakest point.
  • The attacker can probe for unknown
    vulnerabilities
  • The attacker can strike at will
  • The attacker can play dirty

32
The Defenders Dilemma and the Attackers
Advantage
  • The defender must defend all points the attacker
    can choose the weakest point.
  • The defender can defend only against known
    attacks the attacker can probe for unknown
    vulnerabilities
  • The defender must be constantly vigilant the
    attacker can strike at will
  • The defender must play by the rules the attacker
    can play dirty

33
Understanding the adversary
  • What would you do if you wanted to better
    understand your adversaries?
  • Talk to them?
  • Hackers tend to be one-trick ponies and focus on
    what worked yesterday
  • Hackers are not bound by ship pressure, no need
    to be efficient
  • Truth is studying hackers will just depress you
  • They have low-level C and assembly skills
  • They have access to thousands of freeware hacking
    tools
  • They read the thousands of hacker sites out there
    chock full of tips, hints and tutorials
  • We really need to understand all adversaries
  • Study todays hacks and look forward to
    tomorrows
  • Understand how to close these issues efficiently
    and effectively
  • The answer study how the hackers get in

34
Entry points are everywhere
Login screens Web forms Custom clients
OS
Resource starvation Secret content
Application Under Test
User Input
Libraries/ network
Exec. content Remote files Corrupt files Secret
content
Missing/Trojaned libraries Corrupt
packets Bandwidth attacks RPC/Web Services
files
35
From entry point to breach
  • A system can be breached in one of three ways
  • By sending it input it cant or shouldnt handle
  • Code hidden in data
  • Long strings
  • Format strings
  • Magic bullets,
  • By rigging its environment
  • Hiding code in files
  • Trojaning resources,
  • By turning its own logic against it
  • Alternate code paths
  • Time of check, time of use
  • Loop conditions,
  • Not counting social engineering and the
    insider threat

36
Proactive Security Development
  • As defenders, software developers must always be
    vigilant and work smart.
  • Security Principles to live by
  • Secure by Design, Default and Deployment
  • Learn from Mistakes
  • Minimize Your Attack Surface
  • Use Least Privilege
  • Assume External Systems are Insecure
  • Remember that Security Features ! Secure
    Features
  • Never Depend on Security by Obscurity Alone
  • Fix Security Issues Correctly
  • Plan on Failure

37
When Hackers Attack why?
  • Monetary
  • Denial of Service/Publicity
  • Spammers
  • Extortionists
  • Eavesdropping ()
  • Intellectual Property/Idea Theft
  • Script Kiddie fame
  • Black Hat

38
What Applications Need Protection?
  • Anything on the Internet
  • Any application contains IP that competitors
    would benefit from
  • If you have a reason to make something closed
    source

39
Categories of Application Security
  • Data Security
  • Encryption
  • Client-side Application Security
  • Licensing
  • IP Protection
  • Code Theft
  • Server Security
  • Limited to Interactional Interface

40
Data Security
  • Encryption works well for data
  • Sometimes, it's effectively perfect
  • All Encryption algorithms are crackable
  • It just might take millions of years
  • Small problems are usually solved
  • Keeping the key secret
  • Transporting the key

41
Vulnerability
Client Interface
Reverse-engineering
interactional
Network Interface
Application
42
  • Networked/Interactional
  • Application Security

43
Interactional Security
  • In this context, we almost always want protection
  • Insecure apps can compromise servers
  • Compromised servers can be used as spambots or
    attack launch points

44
Interactional Security
  • Must limit interface vulnerability
  • The max-security VS min-usage problem
  • No direct access to the running application
  • Indeed if we had that, we probably no longer care
    about the server itself
  • Many possible attacks here
  • Infamous buffer overrun
  • Unexpected input

45
Interactional Security
  • Input Validation
  • Language environments such as Java/.NET prevent
    memory overwriting attacks
  • Prevent SQL injection
  • Prevent injected executables
  • Verify Ranges

46
Interactional Security
  • For most attacks good (perfect?) security is
    possible
  • Diligence in input validation
  • Smart information disclosure
  • Unpredictable session keys
  • No vital info in cookies
  • No informational errors to the client
  • DOS attacks
  • More complex, often app-external solutions

47
Network Security
  • Port Scan
  • nmap -sS -v -p1-65535
  • 22/tcp open ssh
  • 25/tcp open smtp
  • 53/tcp open domain
  • 69/tcp filtered tftp
  • 80/tcp open http
  • 135/tcp filtered msrpc
  • For on-demand services there is port-knocking
  • Packet Sniffing/Spoofing

48
Network Security
  • Packet Sniffing
  • Ethereal, Sniffit, Tcpdump
  • Packet Spoofing
  • Wardriving
  • Netstumbler
  • WEP Cracking
  • Airsnort

49
  • Application Security
  • Access to the source

50
Applications are not Data
  • At least as far as security goes
  • Encryption doesn't work well for applications
  • Computers can't run encrypted programs
  • Problem Deliver code a computer can understand
    that humans cannot
  • Encrypting class loaders worked (java)
  • For a minute or two anyway

51
Application Security
  • The client is in the hands of the enemy
  • The bad guy has all the time in the world to
    examine the how/what/where of your application
  • Anything you protect can be unprotected
  • Anything you hide can be found
  • Watermarking is an attempt to solve this

52
Application Security
  • Networked/Interactional systems always care about
    security
  • What's protectable in your application?
  • Open source is obviously not necessarily
    protection worthy
  • Licensing scheme?
  • DB Connection scheme?
  • Algorithm IP?
  • General IP?

53
Security through Obscurity
  • This is bad right?
  • Actually, it depends
  • What are we protecting
  • Sometimes more protection never hurts
  • How much security are we getting?
  • Seems to work for house keys, missiles, and
    hackers
  • How much does it cost to implement?
  • A lot of security for a little might be worth it,
    a little for nothing is good too

54
Security through Obscurity
  • Security through obscurity is likely the world's
    most prevalent security model
  • Probably because in many cases it is cheap or
    even free
  • If it's all you have...
  • Add to a good solution
  • Front door locks and The Club
  • The go elsewhere solution
  • Rely on it accordingly

55
Security through Obscurity
  • Short version What's the return-on-investment
  • Or, security-for-investment
  • How do we measure what security we've gained?
  • Defensively, StO should increase the time it
    takes to get what is being secured

56
Security through Obscurity
  • Increasing the time it takes to hack decreases
    the ROI of the thief
  • Increases his exposure to be detected
  • Makes other targets more appealing
  • Gives him more work
  • Frustrates him (or challenges him)

57
Games
  • Almost every game on the shelf has a crack for
    the licensing scheme on the net days after it was
    released
  • Why bother?

58
Games
  • Cracks are complex
  • We can still sell to the rich and non-technical
  • Cracks are immoral
  • We can still sell to the good guys
  • Cracks are underworld
  • We can still sell to those people not willing to
    risk virusizing their machines

new word
59
Psychological Warfare
  • It's about the 2 months
  • Use layers of license protection of increasing
    complexity
  • Understand things will likely be cracked

60
Psychological Warfare
  1. Evil-Johnny (EJ) spends 2 days cracking
  2. EJ distributes crack, brags to friends
  3. 2 days later, game fails again due to invalid
    license
  4. Friends yell at EJ
  5. EJ spends 3 more days cracking next tier
  6. If (friends.stillTrustEJ()) goto 2

61
Auto-update/server dependence
  • Apps that perpetually phone home can be changed
    or disabled
  • Half Life 2 (released Nov. 2004)
  • Valve, Inc. tracked cracked copies and prevented
    those versions from hitting their servers
    (crippling the install)
  • The Ninja Beta release
  • Subtlety is more powerful than force

62
Reverse Engineering Tools
  • SoftIce
  • Any C/C/etc. Windows app
  • C - Reflector, ILDASM
  • Java JODE, JAD
  • Almost any profiler, debugger, disassembler, or
    decompiler is going to reveal plenty of
    information

63
Reverse Engineering Tools
  • C reverse engineering was hard
  • An exercise in machine language
  • Following full program logic was very hard
  • C decompilers rarely work
  • Optimizations make this problem harder
  • Cracking was easiest often because there was a
    single point of failure

64
Reverse Engineering Tools
  • Java and .NET work differently
  • Java --gt Bytecode
  • .NET --gt MSIL
  • Respective compilers tend to produce code that
    has a 1-1 relationship with original source
  • Java and .NET compilers do almost no code
    optimization at all
  • Writing a usable decompiler is not terribly
    difficult

65
Code Obfuscation
VM Execute
Classes/ assemblies
compiler
Java/.NET source
decompiler
66
Code Obfuscation
  • We need a way to transform code such that
  • The runtime still understands it
  • Humans have a much harder time understanding it
  • i.e., increase the effort and time required to do
    so
  • Encryption would require we lock the package and
    hide the key
  • Obfuscation sends the contents in plain view,
    it's just that the view isn't too good

67
What can obfuscators do to prevent code
reverse-engineering?
  • What's the goal?
  • Hide IP
  • Make cracking harder (licensing)
  • Hide valuable info (Db connection, etc)
  • Hold-off copycat competitors

68
What can obfuscators do to prevent code
reverse-engineering? (2)
  • Identifier Renaming
  • Pruning
  • Control Flow Obfuscation
  • Optimizations
  • String Encryption
  • Why would I obfuscate server code?

69
Code Obfuscation simple goal
VM Execute
Classes/ assemblies
compiler
Java/.NET source
obfuscator
decompiler
Munge, munge, munge, munge, munge, ...
70
Identifier Renaming
  • Programmers use descriptive identifier names to
    describe classes, methods, fields, etc.
  • Programmers love this for maintenance
  • Hackers love this for hacking
  • Runtimes don't really care
  • How about renaming all identifiers prior to
    distribution so long as programmers can
    un-rename them

71
Identifier Renaming
getPayroll(int) --gt a(int) getUser(String) --gt
b(String) addValue() --gt c() delValue(float)
--gt d(float) Overload Induction getPayroll(i
nt) --gt a(int) getUser(String) --gt a(String) a
ddValue() --gt a() delValue(float) --gt a(floa
t)
72
Control Flow Obfuscation
  • To a runtime, control-flow is about goto's
  • Loops exist, but not exactly for loops, while
    loops, or do loops
  • Loops are just backward jumps
  • If statements get transformed into forward
    jumps
  • Restructuring control-flow doesn't usually hurt a
    runtime

73
Control Flow Obfuscation
  • Decompilers must analyze control flow to rebuild
    source statements

x
goto
for
for
goto
if xlt0
yy-1
goto
yy1
yy-1
x
yy1
goto
if xlt0
if xlt100
if xlt100
74
Control Flow Obfuscation
  • Most decompilers crash on sufficiently nasty
    control flow
  • JODE does well
  • We must be careful not to break anything
  • Additional indirection is usually removed by many
    runtimes
  • Some techniques can introduce subtle errors
  • Example using static variables can introduce
    subtle race conditions

75
Summary
  • Interactional/Network Security
  • Many good references available
  • Input validation is often at the core of most
    protection techniques
  • This problem is theoretically solvable
  • Application complexity is where things are
    allowed to slip through

76
Summary
  • Application Security
  • The client is in the hands of the enemy
  • Persistent server interaction
  • Updates
  • Phone home
  • Provide a service!
  • Obvious confirm Don't Spy
  • Psychological Warfare
  • If you're positive you're acting against the bad
    guy, you can take off the white hat

77
Summary
  • Application Security
  • Java and .NET are reverse-engineerable with
    one-click
  • Obfuscation is cheap or FREE
  • Dotfuscator CE in every copy of Microsoft Visual
    Studio 2003 and 2005
  • Estimate how much a breach would cost you and
    plan accordingly

78
Summary
  • As defenders, software developers must always be
    vigilant and work smart.
  • Security Principles to live by
  • Secure by Design, Default and Deployment
  • Learn from Mistakes
  • Minimize Your Attack Surface
  • Use Least Privilege
  • Assume External Systems are Insecure
  • Remember that Security Features ! Secure
    Features
  • Never Depend on Security by Obscurity Alone
  • Fix Security Issues Correctly
  • Plan on Failure

79
Suggested Preventive Tools for Windows
  • Set-up auto-download of MS updates
  • MS Baseline Security Analyzer
  • MS Internet Info Server Lock-Down
  • MS Tool to Remove Malicious Software
  • MS Anti-Spyware
  • Adaware
  • Spybot Search and Destroy

80
References
  • Preemptive Solutions, Inc.
  • http//www.preemptive.com
  • Code Security whitepapers, demos, etc.
  • http//www.securityfocus.com/archive/1/272037
  • Many Javascript injection attacks
  • http//msdn.microsoft.com/msdnmag/issues/04/09/SQL
    Injection/default.aspx
  • MSFT article on SQL injection

81
References
  • Chkrootkit - www.chkrootkit.org
  • Linux based rootkit detector
  • RK Hunter - www.rootkit.org
  • Linux based rootkit detector
  • Airsnort - airsnort.shmoo.org
  • Linux WEP cracker
  • Airmagnet -
  • Windows wireless net finder

82
References
  • Dasho-Pro - www.preemptive.com
  • Java Watermark/Code Security tool
  • Used on the Java JDK's JCE library
  • JODE - jode.sf.net
  • Java Decompiler
  • JAD - kpdus.tripod.com/jad.html
  • Java Decompiler (bit out-of-date)

83
References
  • Reflector - http//www.aisto.com/roeder/dotnet/
  • .NET decompiler (any language)
  • Dotfuscator - www.preemptive.com
  • .NET Code security tool
  • Community Edition included in VS2003-5
  • Preemptive Demos
  • http//www.preemptive.com/downloads/Documentation.
    html
  • Flash demos of SQL injection, reverse-engineering,
    license check bypass

84
References
  • www.gamecopyworld.com
  • Cracks for most games
  • www.astalavista.sk
  • Cracking tutorials, cracks, tools
  • www.compuware.com
  • SoftIce debugger (aka cracking tool)
  • http//www.linuxjournal.com/article/6811
  • Port knocking article

85
References
  • Writing Secure Code, Howard/Leblanc, Microsoft
    Press, ISBN 0735615888
  • Excellent Reference
  • Decompiling Java, G.Nolan, Apress, ISBN
    1590592654
  • Details of reverse-engineering and protecting
    Java
  • COLLBERG Christian Collberg, Clark Thomborson,
    Watermarking, Tamper-Proofing, and
    Obfuscation--Tools for Software Protection, IEEE
    Transactions on Software Engineering 288,
    735-746, August 2002
  • University of Arizona
About PowerShow.com