banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Forum Index Thảo luận hệ điều hành Windows Programming, Survival Skills  XML
  [Programming]   Programming, Survival Skills 24/09/2006 12:43:47 (+0700) | #1 | 25402
[Avatar]
K4i
Moderator

Joined: 18/04/2006 09:32:13
Messages: 635
Location: Underground
Offline
[Profile] [PM]
Bài viết này được trích ra từ chương 7 của quyển sách "Gray Hat Hacking". Mình hy vọng bài viêt này giúp cho những ai chưa biết gì về lập trình có những khái niệm đầu tiên về cách giải một vấn đề trong lập trình máy tính.
Đây là một bài viết bằng tiếng Anh. Hy vọng bác nào có thời gian rỗi có thể dịch nó sang tiếng Việt giúp nhé (mọi người thông cảm vì mình dịch quá ẹ :mrgreensmilie.

Programming, Survival Skills

Why study programming? Ethical hackers should study programming and learn as much about the subject as possible in order to find vulnerabilities in programs and get them fixed before unethical hackers take advantage of them. It is very much a foot race: if the vulnerability exists, who will find it first? The purpose of this article is to give you the survival skills and the ability to find holes in software before the black hats do.

It should be said at the outset that programming is not something you learn in an article, a chapter or in one book, for that matter. There are professional and hobbyist programmers who spend years perfecting their skills. However, there are a few core concepts that can be picked up rather quickly. We will not try to turn you into a programmer. Instead, we hope that by the end of this article you won't be afraid to look at source code and that you've learned a few skills to "hack" up some code if you need to.
Programming

The Problem-Solving Process

Experienced programmers develop their own process of tackling problems. They will consolidate or even skip steps, but most of them will admit that when they first learned, they followed a more structured approach. Programming usually revolves around a problem-solving process as follows:

1 Define the problem:The first step in the process is to clearly define the problem. This step can be as simple as brainstorming; however, there is usually a need to develop requirements of some sort. In other words, "What is the problem we are trying to solve?" The next question to ask is "What are the high-level functions that will allow us to solve that problem?"

2 Distill the problem down to byte-sized chunks: At this point, the high-level functions may be hard to wrap your mind around. In fact, they may be very abstract, so the next step is to break the high-level functions into smaller ones through an iterative process until they are easy to digest.

3 Develop pseudo-code:The term pseudo means fake. Pseudo-code refers to the clear, concise description of logic or computer algorithms in plain English, without regard to syntax. In fact, there is no precise syntax for pseudo-code. That said, most programmers gravitate toward a format like their favorite programming language.

4 Group like components into modulesThis is an important step. Recent programming programs rely on a concept called modularity. Simply put, modular means self-contained and reusable bits of code-after all, why reinvent the wheel if the module already exists? Over time, programmers develop their own software module library or learn to quickly find others and incorporate them into their own programs. Modules are loosely related to functions or procedures in most languages.

5 Translate to a programming languageAt this point, you should have pseudocode that resembles your favorite programming language. It's a simple process to add the nuances of your favorite language, such as its syntax and format. Then run your favorite compiler to turn the source code into machine language.

6 Debug errors.The term bug (as it relates to hardware) was first coined by Thomas Edison, but it was Navy Admiral Grace Hopper who made it famous
when she found a bug (actually a moth) while cleaning the Harvard Mark II calculator in 1945. Many credit her with coining the term debugging, which means to remove any errors in either computer hardware or software. For our purposes, there are two types of programming errors or software bugs that require debugging: syntax and runtime.

- Syntax errors Syntax errors are caught by the compiler during the compiling process, and are the easiest type of error to find and fix. The compiler usually provides enough information to allow the programmer to find the syntax error and fix it.

NOTE: Many black and gray hat hackers will modify the source code for their exploits and purposefully add syntax errors to keep script kiddies from compiling and running them. The source code could be crippled by removing needed syntax (for example, missing ; or {}).

7 Runtime errors. Runtime errors are harder to find and fix. They are not caught by the compiler and may or may not be found during program execution. Runtime errors (or bugs) are problems that will cause the program to act in a manner not intended by the programmer. There are too many types of bugs to cover in this chapter; however, we will focus on input validation errors. These errors occur when the user provides input in a manner not foreseen or handled properly by the programmer. The program may crash (at the least) or may allow the attacker to gain control of the program and the underlying operating system with administrator or root level access (in the worst case). The rest of this chapter will focus on this type of programming error.

8 Test the program. The purpose of testing is to find the runtime errors while confirming the functionality of the program. In other words, does the program perform as planned without any unforeseen consequences? It's the latter part of this question that's the hardest to answer. The problem centers around the fact that a programmer is often the last person to find all of the runtime errors. The programmer is typically too close to the program to think outside the box. It is usually best to separate the testing and programming functionalities and have separate people perform them.

9 Implement production: Unfortunately, for too many software products, production begins as soon as the program compiles without syntax errors and without adequate testing. There's often a rush to market and a ready acceptance that bugs will be found and handled later.

to be continued... smilie
Sống là để không chết chứ không phải để trở thành anh hùng
[Up] [Print Copy]
[digg] [delicious] [google] [yahoo] [technorati] [reddit] [stumbleupon]
Go to: 
 Users currently in here 
1 Anonymous

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|