Here is a story about a sneaky bug that got in the way of a hacker, who had to do some pretty important stuff in assembly.

Being a rational hacker, he didn’t start working from scratch, but turned to libraries. Say, he used a function from a dlopen()‘ed library and called it from the assembly code. In C code he wrote:

void *dostuff_ptr;

...

dostuff_ptr = dlsym ("dostuff");

In the assembly he then casually called dostuff_ptr to do the required pretty important stuff.

Being a smart hacker, he decided to re-implement the library function in assembly to show everyone his talent. And he declared a pointer to his implementation:

extern void *my_dostuff;

Being a user-friendly hacker, he allowed users to choose between the library’s implementation of dostuff() and his own by conditionally assigning somewhere in the code dostuff_ptr to the right address:

dostuff_ptr = use_mydostuff_p  ?  my_dostuff : dlsym ();

How surprised was the hacker to see that once use_mydostuff_p was true things stopped working.

To fix the problem he launched a debugger and spent some time investigating code. As you know, the amount of time it takes to debug a problem is very much dependent on how much you trust your toolchain. Well, our talented hacker was working on a new feature which affected the toolchain, and his level of trust was minimal. So he spent a lot of time debugging, debugging and debugging again.

Anyway, he eventually discovered that dostuff_ptr = my_dostuff; puts a bogus value into dostuff_ptr. After taking a close look at the value in dostuff_ptr he noticed that the value in dostuff_ptr is a binary code of the first instructions of my_dostuff(). It turned out instead of loading the address of my_dostuff() the code loaded contents of my_dostuff() into dostuff_ptr. Well, why did this happen to our good hacker? He simply did not define my_dostuff correctly! Instead of

extern void *mydostuff;

it should’ve been

void (* mydostuff) (void);

!

The end.

Today i played around a little bit with XUL. After updating my first XUL-Side multiple times i got very annoyed of the builtin caching – Whenever i changed my XUL-File i had to restart firefox. Otherwise the file was not reloaded.

After searching the web, i found a way to disable the cache (German Firefox-Wiki-Entry)

1. Open about:config in your firefox.
2. Right click and select “New -> Boolean”.
3. Add a variable “nglayout.debug.disable_xul_cache”.
4. Change its value to true via double click.
5. Restart firefox.

Now the cache for XUL-Resources is disabled. That means whenever you refresh an XUL-File (e.g. when pressing F5) the new version of the file is loaded.

IDA Pro has included symbol loading facility some time back. But different installations had yield different results; sometimes symbol loading works, sometimes it didn’t. This has led me to scratch my head for an extended period of time until now.

What happened is when IDA ask the following:

IDA Pro has determined that the input file was linked with debug information. Do you want to look for the corresponding PDB file at the local symbol store and the Microsoft Symbol Server?

it made use of its dbghelp.dll and symsrv.dll to load the symbols. We are supposed to accept Microsoft’s terms for using their symbols, but since symsrv.dll is used directly by the plugin the prompt to accept the terms is not displayed, the license cannot be accepted, and hence the symbol loading fails.

The solution is to include an empty symsrv.yes file alongside symsrv.dll in IDA’s directory to indicate that we’d gladly accept the terms that never appear.

1. Edit virtual machine setting에서 Hardware 에서 Add

2. Serial Port 선택, Output to named pipe 선택

3. Hardware 에서 Use named pipe 선택, 파이프명 \\.\pipe\com_1 (기본 설정되어 있음)

This end is the server 선택, The other end is virtual machine 선택

4. vmware OS 에 Boot.ini 에 아래와 같이 /debugport=com1 /baudrate=115200 추가

multi(0)disk(0)rdisk(0)partition(1)\WINDOWS=”Microsoft Windows XP Professional” /noexecute=optin /fastdetect /debugport=com1 /baudrate=115200

5. 본 PC 의 windbg 바로가기 대상에 아래 추가

“C:\Program Files\Debugging Tools for Windows\windbg.exe” -k com:pipe,port=\\.\pipe\com_1

6. vmware os 실행, windbg 실행

7. Symbol File Path 메뉴를 선택, SRV*c:\폴더지정*http://msdl.microsoft.com/download/symbols 추가

Start~!!

Windbg is an excellent tool for those who use it everyday and working with debugging on production code, but for us that doesn’t debug so often this new feature with VS2010 is going to change our world.

http://channel9.msdn.com/posts/Glucose/Hanselminutes-on-9-Debugging-Crash-Dumps-with-Tess-Ferrandez-and-VS2010/

Sau khi chuyển sang dùng VS2008 SP1, tôi gặp một lỗi ngớ ngẩn và rất khó chịu, nó làm giảm hiệu suất làm việc rất nhiều.

– “Step into” (khi bạn nhấn F11) hay “Step over” (khi bạn nhấn F10) không dừng lại ở các breakpoints.
– Đôi khi nhấn F10 và F11 thì VS2008 cư xử như ấn F5. —-> bạn sẽ không debug được

Đó là một lỗi của M$, mời xem tại đây: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=365666 và https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=368650

Cài Hotfix sẽ chữa được lỗi này:

http://code.msdn.microsoft.com/KB957912/Release/ProjectReleases.aspx?ReleaseId=1796 (15.5MB)

Hy vọng giúp được các bạn.

Bổ sung:

Nếu bạn chạy windows 64bit (Vista 64, Windows 7 64 …) thì khi cài đặt có thể bị lỗi. Nguyên nhân thì chưa xác định rõ ràng (tôi đoán là do trên các bản win này, VS được cài ở Program Files (x86), chứa ký tự đặc biệt nên bản cài cho hotfix bị lỗi (xong trong log thì thấy) khi detect đường dẫn)

http://codepoet5150.com/2008/09/12/visual-studio-2008-sp1-setup-failure-on-64-bit-vista-solved/

Giải pháp: bạn disable ổ CD/DVD đi thì sẽ giải quyết được vấn đề

- bỏ các ổ ảo, virtual drive nếu có
- bỏ ổ CD thật (chuột phải vào My Computer, Manage, Disk Management, disconnect ổ CD hoặc remove driver letter/path đi)

its always a nightmare to debug
its more hard when the process is more depending upon the user input
test cases cant help many times but only manual testing

## in controller
def show
@debug_mode = false
if params[:debug] and (params[:debug].downcase == ‘true’ || params[:debug] == ‘1′)
@debug_mode = true
end
post = Post.find params[:id]
end
## in application_helper

def debug_an_object(obj)
“”"
This will print the content of the object passed
Usage :
// in controller
location = Location.find :first
// in view
<%= debug_an_object(location) %>

This will returns a table which contains the attribues of the object passed

“”"

str_table_start = “<table border=’1′ cellpadding=’2′ cellspacing=’2′ style=’font-size:11px;’>”
str_table_end = “</table>”

str_tr_start = “<tr>”
str_tr_end = “</tr>”

str_td_start = “<td style=’background-color:skyblue;’>”
str_td_end = “</td>”

str_html = str_table_start + “<tr><td style=’background-color:lightgreen;’>Name</td><td style=’background-color:lightgreen;’>Value</td></tr>”
for key,val in obj.instance_values['attributes']
str_td_key = str_td_start + key.to_s + str_td_end
str_td_val = str_td_start + (val.nil? ? “nil”:val.to_s) + str_td_end
str_tr = str_tr_start + str_td_key + str_td_val + str_tr_end
str_html = str_html + str_tr
end
str_html = str_html + str_table_end
return str_html
end

## in view

<%= debug_an_object(post)  %>

this will display the object in a table

If you’re involved in a large software development effort in Java, then OSGi seems like a natural fit to keep things modular and thus maintainable. But every advantage can also be seen as a disadvantage: using OSGi you will end up with lots of small projects. Handling these and their interrelationships can be challenging.

Enter Maven. This build tool makes it a lot easier to build all these little (or not so little) projects. Which is a necessity, since a command line driven build tool is essential for doing Continuous Integration. And we all practice that, right?

However, as a developer it’s a pain to keep switching between your favorite IDE and the command line. Not to worry, Eclipse has plug-ins that handle just about any situation. Using M2Eclipse, you can maintain your POM from within the IDE.

But an Eclipse Maven project is not an Eclipse OSGi project. For handling OSGi bundles, one would want to use the Eclipse Plug-in Development Environment (PDE) with all the goodies that brings to OSGi development. There is, however, a way to get the best of both worlds, although it still isn’t perfect, as we will see shortly.

The trick is to start with a PDE project:

Make sure to follow the Maven convention for sources and classes and to use plain OSGi (so you’re not tied to Eclipse/Equinox):

Once you’ve created the project, you can add Maven support:

Make sure to use the same identification for Maven as for PDE:

Now you have an Eclipse project that plays nice with both PDE (and thus OSGi) and Maven. The only downside to this solution is that some information, like the bundle ID, is duplicated.

After installing Aptana and Eclipse, loading any thing in IE on my PCs at work and home threw the Visual script errors to debug. That prompt for me to click on Yes or No to debug is getting so annoying. The Debugger Plugin within Eclipse is not functioning properly, or was just not installed with auto updates for some reason. Any websites that have JavaScript throw this type of error. Having been reluctant to install Firefox as IT department will give me a hard time, I waited and waited until now I realize I need it to run Aptana/Eclipse for projects. But what I need is a browser with debugger, and with NetSuite projects, Firefox is what the developer needs. Many script writers and Mozilla gurus call it the “fix to stupid Internet Explorer bugs”. So I decided to download and install Firefox on the PC at work, not meaning to replace IE though. I don’t want to remove IE, as it is there just in case I want to revert from Firefox to IE. Besides not all websites are designed with both Mozilla and IE in mind. Some web sites may just throw a “you don’t have javascript enabled” message; while others recommend “use IE”. But it is all just the compatibility issue. You Tube seems to have problem running in Firefox. So it’s better to keep two choices then.
So far I love it. The download and installation took only a few minutes. Importing favorites and home page, settings from IE, and voila. Mozilla Firefox is ready for me. It’s slick. It’s a powerful web crawler, with built-in search engine besides Google. It’s smooth and fast running. It even speeds up the loading of Facebook. The interface of the latest version is clean and light. I have to say it (version 3.5.5) is much mature compared to the earlier versions (that I saw people using before). Why did not I think about migrating my browser earlier? What did I wait for? Actually I did give it a thought, but was not ready. Some buddies and IT geeks recommended. I guess I did not have a purpose for using it. These are the resources that will help me with my work projects, as long as I know what I am doing. I’ve got to do what I need to do.

My god I have been reading a lot in different forum threads, so I think there are more people then me that needs a little help with this.
Tried to gather the most relevant and working methods, and just make a little forum post on how to use the adb (android debug bridge), part of the Google system developement kit (sdk).

Download the SDK .tgz package from google and unpack the android-sdk-linux_x86-1.1_r1 folder.

Move/copy the adb file from ~/’downloadfolder’/android-sdk-linux_x86-1.1_r1/tools/ to e.g /usr/bin/adb
and make it executable (it not already) by

$ sudo cp ~/'downloadfolder'/android-sdk-linux_x86-1.1_r1/tools/adb /usr/bin/
$ sudo chmod +x /usr/bin/adb

or export $PATH as wanted.

Now that you have “installed” adb, all you gotta do us run adb to see the help file

$ sudo adb


Now you can see the help file, and all the commands you can insert. Start off with plugin in your Android device, and run
$ su
$ adb device
$ adb logcat

and you can see your mobile listed, (the number that is shown is your serial number) and then a full log of whats happening on your phone. Try doing different stuff while running logcat, you’ll understand.
To find out a little more about what you can do, visit Googles ADB site.

The very basis of Object Programming relies on the concepts of Objects.

So what are objects? and how do they the working of OOP’s.

Before we start understanding object’s under OOP’s lets us first try and understand objects from real world. Let us consider a table lamp, which is lying on our desk. The lamp has certain utility and functions that it performs. The functions of the object and its characteristics define the a lamp. For example the lamp can be either put on or off and the lamp gives light or it can be off so it does not give light. These behaviour of the object can be classified into behaviour and state. The state of a lamp can either be on or off and the behaviour can be turning on or turning off.

Similarly all the other objects that we see in real world have these to parameters to define and distinguish them from each other.

In programming concepts objects exhibit the same parameters and are used by other objects to achieve some task. So that means each programming object has a behaviour and state.

State of objects in programming are called fields or variables and behaviour are called methods or functions. So we use variables to store characteristics of a object and the functions to perform so action on those characteristics.

Let’s understand this with the help of an example.

Say for example we are supposed to build an application to capture employee information and process his wages based on the number of days that he has worked.

So we will create an employee class which will have state or variables like

• name
• age
• no of days worked
• daily wage rate
• payable wages,  etc.

Now using this information that we have provided we will write a behaviour or a function which will calculate his wage rate.

This function will basically multiply no of days worked with daily wage rate and return the computed figure as payable wages.

So using the state of the object we perform certain actions on the same to achieve our task.

But why do we need to use objects in our programs?

• Modularity: An object can be written independent of other objects and can be used by other objects.  So we can have one object called as employee and another object called as job. Job object can reference the employee object to perform certain tasks. . Once created, an object can be easily passed around inside the system.
• Information – Hiding: Using methods we can hide the structure and details of the object. That means an calling object just needs to know the function name and the values to be passed. What happens inside the object has got no business with calling object. On successful completion the object can return some value to the calling object.
• Code Re-use: Once an object has been created it can be reused in the same project or other projects needing the same functionality. Saves time and resources.
• Debugging and Pluggability: If there is an object that is creating problem in your program, just remove it and replace with another object. It is easier to debug modular structures as we will be testing and checking unit by unit instead of checking the whole code. It helps to narrow to the problem source and faster ramifications.

I will try and cover more on the uses of objects in my coming few articles, where you will learn the real power and use of objects in real life programming.

Some of this knowledge that I have presented comes from sun.com

Will follow up with more relevant articles.

Excepción en la línea… ¿10.452? Por supuesto, para poder ver la pila de llamadas completa, hay que hacer bastante scroll. Como diría un sueco que yo me sé, “Null pointer in shame? It’s a shame!“.

CubeSat Team SJSU member and computer engineering major Thomas Kopriva presents the initial debug demo of our PCB board. Let’s hear it for blinking lights!

Like most web developers or SEO professionals, I use a vast array of tools to get the job done. I use a combination of desktop and web applications, some purchased and some free. Everyone I know has downloaded a free copy of Mozilla Firefox, but few realize that by installing some of the 1,500 free extensions they can eliminate the need for most of the other applications they currently use. Below are my 13 favorite extensions for web professionals (in no particular order):
HTML Validator: http://users.skynet.be/mgueury/mozilla/ – validates web pages to the W3C HTML standards with a simple green check in the corner of the page if the page validates, a red check if it doesn?t, and a yellow exclamation point if there are warnings. It also includes an enhanced view of source code that allows you to see where errors are within the code.
FireFTP: https://addons.mozilla.org/firefox/684/ – free, secure, cross-platform FTP client that provides easy and intuitive access to FTP servers. This eliminates a piece of software for those of you who use a separate program for FTP.
Professor X: https://addons.mozilla.org/firefox/2823/ – lets you view header information without having to view source code. The page “slides” down and Professor X shows you the contents of the page’s head element, including Meta, Script and Style content.
NikkelWHOIS: https://addons.mozilla.org/firefox/2646/ – view the WHOIS information for any page by clicking the button on the top-right of the browser.
IE Tab: http://ietab.mozdev.org – sick of swapping between Internet Explorer and Firefox when testing out a web page you?re developing? With IE Tab you can view Internet Explorer in a Firefox Tab!
FireBug: https://addons.mozilla.org/firefox/1843/ – an advanced debugger console that lets you monitor your JavaScript, CSS, HTML and Ajax.
Codetech: https://addons.mozilla.org/firefox/1002/ – web page editor that has the feel of Dreamweaver. An amazing extension for anyone doing web design that doesn?t want to fork out a few hundred dollars for Dreamweaver.
Server Switcher: https://addons.mozilla.org/firefox/2409/ – easily switch between sites on your development and live servers by clicking the switch server icon.
SEO for Firefox: http://tools.seobook.com/firefox/seo-for-firefox.html – pulls useful market research data right into Google’s and Yahoo!’s search results, including Google PR, Age, links, Alexa rank, WHOIS, and more. It also adds a few helpful links to the top of the search pages, including Google Trends, Google Traffic Estimator, and the Overture View Bid tool.
Yet Another Window Resizer: https://addons.mozilla.org/firefox/2498/ – allows you to resize browser window to default screen resolutions.
AdSense Preview: https://addons.mozilla.org/firefox/2132/ – preview the Google AdSense ads that would appear on that page. This is incredibly useful if you are considering putting AdSense on a page and don?t want to go through the hassle of signing up for an account and putting the ads up just to see what type of ads will show.
Screen grab: https://addons.mozilla.org/firefox/1146/ – takes a screenshot of the webpage and saves it as an image file. This saves a ton of time compared to the method I used to use – take a screenshot and open Adobe Photoshop to crop the image.
Server Spy: https://addons.mozilla.org/firefox/2036/ – indicates what brand of HTTP server – Apache, IIS, etc. runs on the visited site on the lower-right side of the browser.

When I first started to work on GLIBC development, one of the challenges was to understand how to debug it.  All the usual attempts to compile GLIBC without optimizations ended up with GLIBC grumpily complaining that it cannot be compiled that way.  The development FAQ says

In the early startup of the dynamic loader (_dl_start), before relocation of the PLT, you cannot make function calls. You must inline the functions you will use during early startup, or call compiler
builtins (__builtin_*).

Without optimizations enabled GNU CC will not inline functions. The early startup of the dynamic loader will make function calls via an unrelocated PLT and crash.

OK, fair enough. Can the optimized code be perhaps then debugged, since after all GCC generates adequate debug information even when optimizations are enabled?  Well, not really.  GLIBC is a carefully written piece of software and people who wrote it (a) know quite a lot about compilers and (b) use that knowledge to squeeze every drop of optimizations out of the code.  So though the resulting debug information is usually enough for users to get a sensible backtrace and report bugs to the developers, it is almost useless for single-stepping in a debugger.

The two main problems with single-stepping optimized GLIBC are (1) line numbers and (2) optimized out variables.  The line numbers at -O2 get screwed up beyond repair.   For example, when you try to single step the runtime linker while it is loading dependencies and resolving symbols, the debugger will be thrown between source files and functions at every other line.  So to make the situation more bearable you need to add -fno-schedule-insns -fno-schedule-insns2 to the build flags.

I don’t really know how to properly fix problem (2) with variables being optimized out.  What I usually do is just recompile the only file I’m interested in without optimizations and relink GLIBC.  Normal GLIBC development rarely requires single-stepping the runtime linker before it self-relocates, so try, it might work for you too!

My recipe for debuggable GLIBC is the following:

Voilà!  Debug at will!

Windows Assembly For Exploit Writing: Part II / IV

이번 섹션에서는 익스플로잇 작성을 보다 쉽게 이해하기 위해서 필요한 기본적인 X86 어셈블리를 다루고 있다. 여기서 배우는 X86 어셈블리는 어려운 내용이 아니라, 단지 기본적인 어셈블리 명령어를 읽을 수 있을 정도의 내용이라고 할 수 있다.

Registers

일단 실제 어셈블리 예제를 보기 전에 간단하게 어셈블리어라는 용어에 대한 설명과 어셈블리어에 대한 약간의 배경에 대해서 알아보도록 하자.

어셈블리어는 기계어 코드와 1:1 매칭되는 심볼릭 표현이라고 할 수 있다. OPCODE라고도 불리는 기계어코드는 여러 비트들로 구성된 명령 코드들이다. CPU는 메모리에 로드된 명령 코드를 실행시킨다.

CPU는 정보를 저장할 임시 공간이 필요한 일종의 정형화된 프로그램과 같다. 이러한 CPU를 위해 고려된 저장 메모리가 바로 레지스터이다. CPU가 RAM(Random Access Memory)에 있는 데이터를 직접 접근하여 처리할 수 있지만, 데이터가 레지스터에 있을 경우에는 RAM에 저장된 데이터를 처리하는 속도보다 빠르다.

레지스터들은 각각의 레지스터가 하는 역할에 따라 분류된다. 일반적으로 16가지 종류의 레지스터가 있는데 이 레지스터들은 크게 4가지로 분류할 수 있다. 연산을 위한 데이터를 저장을 포함한 다양한 용도로 사용되는 범용(general purpose) 레지스터, 명령어나 데이터가 저장된 메모리 주소 저장 용도로 사용되는 세그먼트 레지스터, 현재의 프로세서의 상태를 저장하고 있는 status 레지스터, 그리고 CPU가 현재 실행하고 있는 명령어 바로 다음에 실행할 명령어의 주소를 저장하고 있는 EIP 레지스터이다.

우리는 이번 장에서 익스플로잇을 작성하기 위해 알아야할 레지스터들을 중점적으로 언급할 것이다. 우선 범용 레지스터와 EIP 레지스터에 대해서 자세히 알아보도록 하자.

범용 레지스터(EAX, EBX, ECX, EDX, EDI, ESI, ESP, EBP)는 일반적인 데이터 조작에 사용된다. 범용 레지스터에서 “E”의 의미는 32비트까지 확장을 의미한다. 8bit 레지스터들을 32비트 레지스터로의 매핑에 대한 내용은 아래 표에서 확인할 수 있다.

(보다 상세한 내용을 알고자 한다면 Intel에서 제공하는 IA-32 Intel Architecture software developer’s manual; Basic Architecture를 참고하기 바란다.http://download.intel.com/design/processor/manuals/253665.pdf
)

범용레지스터는 인덱스 레지스터, 스택 레지스터 그리고 추가적인 레지스터들로 이루어져 있다. 32비트 레지스터들은 32bit 값 전체를 억세스할 수 있다. 예를 들어 EAX 레지스터에 0×41424344라는 값이 저장되어 있을 때 연산 과정에서 EAX 전체를 다룰 때는 0×41424344 전체값을 사용하게 되지만, AX을 억세스할 경우에는 연산에서 단지 0×4344만 사용하게 된다. 또한 AL을 억세스할 경우에는 0×44, AH를 억세스할 경우에는 0×43을 사용하게 된다. 이 것은 후에 쉘코드를 작성할 때 유용하게 사용된다.

Index 레지스터

EDI와 ESI 레지스터로서 문자열 처리 관련 명령어 사용시 사용하며, 문자열의 처음을  ESI, 문자열의 끝을 EDI에 저장하여 사용한다.

Stack 레지스터

ESP와 EBP 레지스터로서 스택을 조작하기 위해서 사용되는 레지스터이다. EBP(이전 섹션에서 언급했었다)는 스택 프레임의 시작점이며, ESP는 스택의 현재 위치를 가리키고 있다. EBP는 일반적으로 스택 프레임에 데이터를 저장할 때 참조점으로 사용된다.(example 1, hello.cpp 참조)

기타 범용 레지스터

EAX 레지스터는 누산기 레지스터로서 가장 많이 사용되는 레지스터이며 많은 연산의 결과를 저장하는 용도로 사용될 때가 많다. EBX는 데이터 세그먼트의 포인터로서 사용되며, ECX는 일반적으로 반복 구문에서 카운터로서 사용된다. 그리고 EDX는 I/O 포인터로 사용된다. 이상의 4가지 레지스터들은 byte단위로 처리할 수 있는 유일한 4개의 레지스터이다.

EIP 레지스터

EIP 레지스터는 프로세서가 다음에 실행할 명령어의 주소값을 저장하고 있다. 이 레지스터는 하나의 명령어가 실행될 때마다 다음 명령어의 주소값으로 매번 갱신된다. 앞서 언급한 대부분의 레지스터들과는 달리 EIP 레지스터는 직접적으로 레지스터 내 값 변경을 할 수 없다(명령어 내에서 EIP는 오퍼랜드로 사용될 수 없다). 이는 익스플로잇 작성시 중요한 부분이다.

데이터 타입

기본적인 데이터 타입은 8비트로 이루어진 바이트(byte), 2바이트(16bits)로 이루어진 워드(word), 그리고 4바이트(32bits)로 이루어진 더블 워드(double word)가 있다. 성능상의 목적으로 워드 혹은 더블워드들의 배열형태의 구조체 타입도 있다.(예로 스택이 있다.) 추가적으로 8바이트 경계에 걸쳐진 워드 혹은 더블워드는 두 번의 버스 사이클이 필요하다.

작성한 익스플로잇을 원격 시스템에 전송할 때는 이러한 경계에 걸쳐진 형태의 코드가 없어야 한다.

명령어

앞에서 기본적인 레지스터와 데이터 타입에 대해서 알아보았으니 자주 사용되는 명령어 몇 가지에 대해서 간단히 분석해보자. 아래 표에서는 일반적인 명령어들과 각 명령어가 하는 일에 대해서 간략한 설명이 있다. 이러한 명령어들은 디컴파일(decomplie)된 코드에서 쉽게 볼 수 있다. 보다 많은 어셈블리 명령어에 대해서 알고 싶다면 앞에서 언급한 Intel 매뉴얼을 참고하기 바란다.

Hello World

스택의 구조와 어셈블리 명령을 보다 쉽게 이해하기 위해서 간단한 hello world 예제를 자세히 살펴보자.

아래 코드는 간단한 hello world 프로그램이다.

1://helloworld.cpp : Defines the entry point for the console

2://application. This example has been compiled on Visual Studio

3 ://.NET so the “”/GS”” flag results can be seen on line 37.

4 : #include “stdafx.h”

5 :

6: int main(int argc, char* argv[])

7: {

8 //Prologue Begins

9 00401010 push ebp //Save EBP on the stack

10 00401011 mov ebp,esp //Save Current Value of ESP in EBP

11 00401013 sub esp,40h //Make space for 64 bytes (40h) var

12 00401016 push ebx //store the value of registers

13 00401017 push esi //on to the

14 00401018 push edi //stack

15 00401019 lea edi,[ebp-40h] //load ebp-64 bytes into edi

16 //the location where esp was before it started storing the values of

//ebx etc on the stack.

17

18 0040101C mov ecx,10h //store 10h into ecx register

19 00401021 mov eax,0CCCCCCCCh

20 00401026 rep stos dword ptr [edi]

21 //Prologue Ends

22 //Body Begins

23 8: printf(“Hello World!\n”);

24 00401028 push offset string “Hello World!\n” (0042001c)

25 0040102D call printf (00401060)

26 00401032 add esp,4

27 9: return 0;

28 00401035

29 10: }

30 //End Body

31 //Epilogue Begins

32 00401037 pop edi // restore the value of

33 00401038 pop esi //all the registers

34 00401039 pop ebx

35 0040103A add esp,40h //Add up the 64 bytes to esp

36 0040103D cmp ebp,esp

37 0040103F call __chkesp (004010e0) // “”/GS FLAG””

38 00401044 mov esp,ebp

39 00401046 pop ebp //restore the old EBP

40 00401047 ret 3 //restore and run to saved EIP

위의 코드 중 9번에서 21번째줄까지가 프롤로그이며, 31부터 40까지가 에필로그과정이다. 프롤로그와 에필로그는 함수 호출 과정에서 레지스터들의 값과 스택 프레임을 보존하기 위해 컴파일러가 자동으로 생성하는 코드이다. 프롤로그와 에필로그를 제외한 body부분에는 실제 코드들과 함수 호출부분이 포함되어 있다. 프롤로그와 에필로그 과정은 아키텍쳐와 컴파일러에 따라 다르다는 것을 유념하기 바란다.

위 예제의 프롤로그부분(9~21)은 visual studio 6.0 버전에서의 볼 수 있는 프롤로그 과정이다. 위 예제의 프롤로그에서 첫 번째 명령(push ebp)은 이전 EBP(부모 함수의 베이스포인터/프레임 포인터)에 저장된 주소값을 스택에 푸쉬한다(여기서부터 호출된 함수의 새로운 스택 프레임이 생성된다). 다음 명령(mov ebp, esp)는  esp 레지스터의 값을 ebp레지스터에 저장한다. 이 작업을 통해 새로운 베이스 포인터가 설정된다. 세 번째 명령(sub esp, 40h) 을 수행함으로써 지역 변수를 위한 메모리 공간을 스택상에 확보하게 된다. 위의 예제에서는 지역 변수를 위해 64 byte가 할당된다. 여기서 함수 호출 과정에서의 아규먼트(argument)값들은 오른쪽에서 좌측으로 스택에 푸쉬된다는 점과 스택을 정리하는 것은 호출한 함수측(caller)에서 담당하는 것임을 반드시 기억하기 바란다. (함수 호출 규약에 따라 스택을 정리하는 주체가 다르다. 참고로 여기선 cdecl 함수 호출 규약을 사용한다.)

위 코드의 에필로그 부분은 스택 프레임을 정리하기 전에 함수 호출 이전의 상태로 레지스터값들을 변경한다. 함수 호출 처음에서 프롤로그 과정을 통해 푸쉬했던 모든 레지스터값들은 함수 호출 이전의 값들로 복구된다.(31~33), 다음 3줄은 오직 디버그버전을 통해서만 알 수 있다. 내용은 스택 포인터(ESP)를 64바이트만큼 증가시키고 증가시킨 ESP에 저장된 값과 EBP에 저장된 값이 동일한지 확인한다.

37번째 줄에 있는 명령어(call __chkesp (004010e0)) 는 스택에서 꺼낸 리턴 어드레스의 값이 유효한지 확인하는 부분이다[상세한 설명은 MSDN의 “/GS Flag implementaion"부분을 찾아보기 바란다]. 리턴 어드레스가 유효하면, EBP에 저장된 값을 ESP에 넣고 스택에 저장된 값을 pop을 통해 EBP에 저장한다. 그리고 마지막으로 ret 명령을 통해 스택에 저장된 값을 EIP에 넣음으로써 최종적으로 함수 호출 복귀하고 이후 단계로 진행하게 된다.

참고 : 함수 호출 규약(Calling Convention)

visual studio에서는 기본적으로 함수 호출 규약 중 CDECL을 표준으로 사용한다. 만약 CDECL 함수 호출 규약을 사용하지 않는다면 스택의 레이아웃은 약간 변하게 될 것이다. CDECL말고 다른 함수 호출 규약이 몇 가지 있지만 이 문서에서는 언급하지 않겠다(참고로 fastcall, stdcall 방식이 있다).

용어 :

• 레지스터 : 레지스터란 CPU에 내부에 장착된 매우 빠른 저장공간이다. 데이터를 임시로 저장하기 위한 용도로 사용된다. 속도가 매우 빠르지만 저장공간이 매우 적다.

• OP Code : OP Code란 어셈블리어에 해당하는 기계어 표현이다.

툴 :

• Visual Studio C++

Writing Stack Based Over flows on Windows

Part I – Basic Concepts

Nish Bhalla, 31^st May, 2005

(Nish [a-t] SecurityCompass.com)

www.SecurityCompass.com

Introduction

이 문서는 윈도우에서의 Stack Based Overflow에 서술한다. 이 문서를 작성하기 전에 이것은 이미 매우 중요한 개념이다.

이 문서의 Part.1 에서는 메모리에 적재된 프로그램이 실행되는 간단한 원리를 설명한다. Part.2 에서는 기본 어셈블리어 명령어들에 대해서 알아볼 것이고, Part.3 에서는 Stack Overflow가 무엇인지, 왜 그것이 존재하는지, 로컬에서 취약한 어플리케이션을 위한 익스플로잇을 어떻게 작성하는지에 대해 중점적으로 서술할 것이다.

마지막으로 Part.4 에서는 당신만의 쉘 코드를 어떻게 작성하는지와 원격의 buffer overflow 익스플로잇에 대하여 말할 것이다.

이 문서에는 자세한 예제들이 제공될 것이고, 그것은 각 개념들을 이해하는 데 많은 도움이 될 것이다. 예제들은 Windows XP(No SP)를 기반으로 작성되었고 Visual Studio 6.0과 7.0 버전에서 테스트되었다. 또한 몇몇의 예제들은 Visual Studio .NET (or VS 7.0) 환경에서 설명하였다. 이 예제들은 Microsoft사의 프로그램에서 실행되는 새로운 보안 기법에 대해서 설명한다. Visual Studio .NET 개발 환경에서는 어플리케이션을 기록하거나 여기에서 기술한 공격들을 방어하는 보안 기법이 기본적으로 내장되어있다.

앞으로 나오는 모든 익스플로잇과 취약한 어플리케이션 예제를 컴파일 할 때에는 “/GS” flag 옵션을 disable 시키기 바란다.

그리고 이 문서에서 다루는 여러 가지 툴과 유틸리티에 대한 소개, 다운로드 링크는 제공된다. 예제들 또한 사이트에서 다운로드 가능하다. (참고 사이트 참조)

이 문서를 읽기 전에, 익스플로잇을 작성하는 방법에 대한 다른 문서들이 있을까에 대하여 생각해 본 적이 있는가?

내가 익스플로잇을 작성하는 방법을 배우기 전에, 나는 여러 훌륭한 문서들을 읽었지만 항상 선수과목에 관한 지식을 요구할 뿐이었다. 그리고 대부분의 문서는 그들의 예제를 증명하기 위해 샘플 어플리케이션을 사용하는데 그 자료는 너무 오래 되었고 적절한 예제를 찾기 위해 나는 많은 시간을 투자하여야 했다.

그것이 바로 내가 이 문서를 작성하게 된 이유다.

많은 개발자들은  “GS” flag를 설정해 주면 버퍼 오버플로우 익스플로잇 공격을 막을 수 있다고 생각한다. 하지만 마이크로소프트에서는 개발자들에게 “GS” flag 만으로는 모든 종류의 버퍼 오버플로우를 막을 수 없다고 얘기한다. (여기에 대한 상세한 내용은 msdn을 참조하기 바란다)

마이크로소프트를 제외한 다른 IDE에서는 이런 “GS” flag와 같은 기능을 제공하지 않는다. 이러한 IDE에서 개발한 어플리케이션들은 여전히 이런 익스플로잇에 대하여 여전히 취약할 수밖에 없는 것이다.

만약 이 문서를 읽다가 궁금한 점이 있다면 securitycompass.com으로 연락하기 바란다.

마지막으로, 문서 작성에 도움을 준 Jamie, Nitesh, Dhillon에 감사의 말을 전한다.

Basic Concepts: Part I/ IV

모든 어플리케이션에는 4GB의 가상 메모리 공간이 할당 된다(실제 물리적 메모리가 4GB보다 작다 할지라도). 이 4GB 공간은 32bit 주소 체계에 기반 한다(2³²byte = 4294967296 bytes). 모든 어플리케이션들은 실행될 때 메모리 관리자에 의해 가상 메모리에서 자동으로 물리적인 메모리로 바꾸어지기 때문에 데이터가 저장되는 메모리가 실제 어느 위치에 존재하는지 까지는 알 필요가 없다. 이러한 메모리 관리는 OS의 담당이며, OS는 단지 어플리케이션에게 필요한 메모리를 할당 혹은 해제해주는 역할을 한다.

4GB의 가상공간은 유저 모드와 커널 모드로 균등하게 나누어져 있다. 어플리케이션은 보통은 유저 모드 메모리에서 로드/실행되고, 커널모드 메모리는 커널모드로 작동되는 프로그램(ex. device driver 등)이 로드/실행될 때 사용된다.

 어플리케이션은 어떤 커널모드 메모리에서도 직접적으로 접근할 수 없다. 강제 혹은 우연적으로라도 접근 시 access violation을 일으킨다.

만약 어플리케이션이 kernel mode로 접근해야 할 때는 user mode에서 kernel mode로의 스위칭이 필요하다.

0×00000000 – 0×7fffffff 는 user mode를 위해, 0×80000000 – 0xBfffffff 는 kernel mode를 위해 사용된다.

Figure1. 메모리 할당

DLL and EXE Files

동적 링크 라이브러리(DLL)는 링크된 서브루틴들을 포함하는 바이너리 파일이다. 동적 링크 라이브러리는 실행 파일(.EXE)이 DLL 내부에 존재하는 서브루틴을 필요로 할 때 로드된다.  DLL과 Exe 파일은 특정 1비트를 제외하고는 모두 동일한 PE 포맷을 사용한다.

 OCX(ActiveX)와 CPL(Control Panel) 파일 확장자들 역시 DLL 파일 형식과 거의 동일하다.

라이브러리들은 정적과 동적으로 나눌 수 있다. Windows는 한 번 적재된 DLL 파일을 여러 어플리케이션을 공유할 수 있는 장점 때문에 주로 동적 라이브러리를 사용한다.

DLL의 예로는 kernel32.dll, user32.dll 등이 있다.

메모리 할당(Memory Allocation)

각각의 실행파일은 중첩되지 않는 고유의 주소 공간에 적재된다. 운영체제 버전과 어플리케이션이 동일하다면 메모리상의 DLL 위치는 다른 시스템에서도 항상 동일한 지점에서 로드된다.

Note: 익스플로잇을 작성할 때 DLL의 위치에 대한 정보와 그와 연관된 함수들이 사용된다.

실행파일이 메모리에 로드된 베이스 주소를 볼 수 있는 수많은 툴들이 있다. 하지만 우리는 Microsoft Visual Studio에서 기본적으로 제공하는 dumpbin이란 툴을 사용할 것이다.

위와 같은 정보를 확인하기 위해서는 Ollydbg나 quickview plus와 같은 여러 가지 툴 들을 사용할 수 있다.

Memory Overview

어플리케이션/프로세스는 stack segment, data segment, code/text segment 의 세 가지 메모리 구역으로 나누어진다.

stack segment는 지역 변수와 프로시저 호출을, data segment는 정적 변수와 동적 변수를, text segment는 프로그램 명령어들을 저장한다.

data segment와 stack segment는 각 프로그램마다 유일하고, 다른 어플리케이션의 접근이 불가능하다. text segment는 프로세스 내부에서 읽기만 가능한 세그먼트 영역이다. 다른 프로세스에서 접근 시도 시에도 읽기만 가능하며, 이 영역에 쓰기를 시도한다면 segment violation을 일으킬 것이다.

Memory Layout – Stack

스택은 어플리케이션이 사용할 가상 메모리 내의 예약공간이며 OS의 메모리 할당을 위해 사용한다. 개발자에게 메모리를 확장시키기 위한 추가적인 명령어를 요구하지 않는다. 운영체제는 guard page를 이용하여 자동적으로 이 작업을 수행한다.

         Figure: Memory layout

다음의 코드는 문자열 배열 “var”를 스택에 저장한다.

Example: char var[] = “www.SecurityCompass.com” ;

정보는 항상 스택의 꼭대기(top)에서 push(추가) 혹은 pop(제거)되는 특징이 있다.

그래서 스택은 “Last In First Out(LIFO)” 라고 불리어진다.

데이터를 push하면 현재 스택의 최상위를 가리키는 ESP 레지스터에 저장된 값이 4byte 아래를 가리키게 된다.(ESP 레지스터에 대한 상세한 내용은 이후에 나오는 문서를 참조하기 바란다.)

다량의 데이터들은 push 혹은 pop 을 통해 스택에 저장될 수 있다. push를 통해 데이터가 스택에 저장되면 ESP 값은 감소되고, pop을 통해 빠져나오면 ESP값은 증가한다.

Frame Layout

스택 프레임은 서브루틴/프로시저가 호출될 때 생성되는 데이터 구조이다. 스택 프레임의 목적은 부모 프로시저의 파라미터 값과 호출한 프로시저로 전달할 파라미터 값을 보존하는 것이다. 현재 스택 포인터의 위치는 언제든지 ESP에 저장된 값을 이용하여 접근 할 수 있다. 현재 함수의 시작점은 EBP 레지스터를 이용하여 추측할 수 있다.

Memory Layout – Heap

힙은 어플리케이션에 의해 사용되는 가상 메모리인데 스택과 유사하다고 볼 수 있다. 모든 어플리케이션은 기본 힙 공간을 가지고 있는데 스택과는 다르게 “new()”, “malloc()”을 이용하여 생성할 수 있고 “delete(), “”free()”를 이용하여 삭제 할 수 있다.

힙은 변수의 사이즈를 미리 알 수 없거나 스택에 저장하기에 너무 큰 변수일 경우 사용 가능한 특징이 있다.

Example:

                 OBJECT *var = NULL;

                 var = malloc(sizeof(OBJECT));

윈도우즈 힙 관리자는 메모리 청크를 할당하거나 해제할 수 있는 함수를 제공하는 메모리 관리자에 의해 작동한다. 모든 어플리케이션은 기본 1MB(0×100000)의 예약된 힙 공간을 가지며(dumpbin을 통해 output을 확인 가능함) 할당될 사이즈가 정해지지 않는다면 4k(0×1000)를 할당한다. 힙은 메모리 내에서 순서대로 할당되지 않는다.

즉, 이전과 현재에 할당된 메모리 영역이 연속적이지 않을 수 있다.

Heap Structure

각각의 힙 블록은 비어 있거나 사용 중인 메모리 블록의 연속적인 데이터를 구조체 형태로 유지하고 있다. 힙은 최소 8byte, 추가 오버헤드로 8byte 할당된다.(힙 제어 블록)

힙 제어 블록은 다음의 빈 블록을 가리키다가 힙이 할당 혹은 해제될 때 포인터 정보가 갱신된다.

Note: Heap in XP SP2 and Windows 2003

마이크로소프트는 부가적인 힙의 제어 블록에 저장되는 1byte long랜덤 값을 소개했다.

Note: Stack Protection with the “/GS” Flag

Microsoft Visual Studio .NET 의 새로운 컴파일러 플래그인 “/GS” 플래그가 소개되었다. 이것은 기본적으로 설정된 변수 공간과 리턴 주소 사이에 있는 canary 값이다.

다음 장에 있는 “Hello World” 코드를 컴파일 하게 되면 확인 할 수 있을 것이다.

용어 사전(Glossary):

 - Stack : 스택은 윈도우 메모리 관리자에 의해 정적으로 할당되어 관리되는 메모리이다.

 - Heap : 힙은 동적으로 할당되는 메모리이다.

 - Stack Frame : 스택 프레임은 함수로의 진입 시 만들어지는 데이터 구조이다.

 - Physical Memory : 물리적 메모리는 실제 컴퓨터 시스템에서 확인할 수 있는 용량과 동일하다.

 - Virtual memory : 가상 메모리는 운영 체제의 확장된 메모리 공간을 프로그램에게 제공하기 위해 사용되는 기능이다. 이것은 운영체제에게 실제 물리적 메모리보다 더 많은 메모리를 사용할 수 있도록 한다.  Microsoft에서는 페이징파일을 이용하여 가상 메모리를 사용한다.

 - Binaries : exe, dll 등의 다른 실행 파일들이 컴파일 되면 바이너리 파일로 나타내어진다. dll과 exe 파일은 동일한 포맷을 사용하지만 이 둘을 구분하기 위한 1bit만이 다를 뿐이다.

 - DLL : Dynamic Linked Libraries의 약자로 정적 라이브러리와 다르게 컴파일 하는 동안 실행파일 혹은 라이브러리에 복사되지 않는다. .OCX(ActiveX controls),  .CPL(Control Panel applets files) 같은 확장자를 가진 바이너리 파일들은 DLL 형식과 비슷하지만 보다 확장된 형식이다.

 - PE Format : Portable Executable Format의 약자로 전형적인 윈도우 실행 파일 형식이다.

 관련 프로그램 소개(Utilities): 

 - Ollydbg : ollydbg는 GUI usermode를 기반으로 한 디버깅 유틸리티이다.

                   이 유틸리티는 익스플로잇을 작성할 때 매우 유용할 것이다.

                   http://www.ollydbg.de/ 에서 다운로드 혹은 관련 정보를 얻을 수 있다.

 - Dumpbin: Dumpbin은 Visual C++와 함께 설치되는 유틸리티이다. 이 프로그램은

                  보통 “<visual studio home directly>\VC7\BIN\dumpbin”에 설치되어있다. 

Links For Additional Reading:

 - http://www.labri.fr/Perso/~betrema/winnt/

  이 사이트는 메모리 관리자에 대한 여러 기사가 링크되어 있다.

 - http://www.intel.com/products/processor/manuals/index.htm

  인텔의 웹사이트에는 어셈블리 언어 가이드가 있다(Intel Software Developers Guide).

  여기에는 어셈블리어 코드 예제와 기본 문법들이 소개되어 있으며, 윈도우에서의 어셈블리어 매뉴얼 정리가 매우 잘 되어 있다.

Writing Stack Based Overflows on Windows Part Ⅲ – Stack Overflows

Stack Overflows : Part Ⅲ / Ⅳ

 이번 부분에서는 Stack Overflow를 알기 위한 기본적인 지식을 논할 것 이다.

 Buffer Overflow는 프로그램이 버퍼의 끝에 써질 때 일어난다(배열의 경계). 이번 파트에서는 취약점을 이해하는 것과 Stack based exploits를 작성하는 것에 초점을 둘 것이다. 윈도우의 Stack Overflow를 쉽게 이해하기 위해 취약한 어플리케이션의 예제를 작성하고 exploit을 작성할 것이다. 이 파트에서는 당신이 앞의 두 파트를 읽었다고 가정할 것이다.

 Java / C#과 같은 언어와 달리 C / C++은 Buffer overflow를 위한 built in 체크(bounds checking)를 하지 않는다. Visual Studio .NET과 같은 최신의 Development 환경은 Stack Overflow를 예방하는 새로운 특징을 가지지만 모든 Development 환경이 이런 특징을 가지거나 모든 Developer들이 이런 특징을 사용하는 것은 아니다.

 eEye, NG software, Immunix, Entercept(지금은 Mcafee)과 같은 회사들은 수많은 공격들을 예방하는데 도움이 되기 위한 소프트웨어를 개발해오고 있다. 침입 방지 및 탐지시스템들 또한 네트워크를 통해 침입하는 악성코드를 막거나 탐지한다.

Background

 높은 수준의 메모리 관리 개념을 이해하고 어셈블리어의 기본개념을 알면 exploit 작성을 탐구할 준비가 된 것이다.

 exploit과 그것을 작성하는 것에 대한 지식은 프로그래밍 언어의 초기부터 발전해 왔다. 최초의 exploit은 “Morris Worm”이다.

 ”Morris Worm”은 Stack Overflow exploit이다. 이것은 1986년에 우연히 인터넷에서 유포된 후에 이슈로 떠올랐다. 이것은 컴퓨터들의 호스트를 해체시키고 웜에 감염된 대학들과 NASA, 군대, 연방정부기관들에게 수백만 달러의 피해를 야기 시켰으며 인터넷 트래픽의 약 10퍼센트를 마비시켰다. 이것은 또한 CMU의 컴퓨터 침해사고 대응 팀(CERT)과 같은 팀들을 탄생하게 했다. Aleph One의 “Smashing the stack for fun & profit”와 Dildog의 “The Tao of Windows Buffer Overflow”는 Buffer Overflow에 대해 이야기하는 첫 번째 공적인 기사였다.

 최근에는 exploit 취약점의 방법이 많이 발견되었다. 이 취약점은 대체로 큰 세 개의 카테고리(“Stack Overflows”, “Heap Overflows”, “Format String”)로 나뉜다. 이 exploit들은 서로 다르지만 같은 결과(Denial of service, Unauthorized access to a remote system or escalation of privileges)를 생성한다.

 Stack, Heap Overflows 또한 일반적으로 “Buffer Overflows”와 같이 프로그램의 버퍼를 공격하는 것이다. 버퍼는 어플리케이션의 일시적인 저장 공간이다. 버퍼를 Overflow하는 것은 할당된 공간의 한계를 넘은 곳에 데이터를 저장하는 것이다. Format String 공격은 printf, sprintf와 같은 함수의 “format”클래스를 실행함을 확인하지 않았거나 부적절하기 때문에 발생시킨다.

Basic Stack Overflow

 ”Windows Assembly – part Ⅱ/Ⅳ”에서 배운 스택은 가변의 프로그램을 위해 미리 할당된 가상메모리의 공간이다. 예를 들자면, “char var[10]“은 스택에 가변의 “var”을 10bytes 저장하겠다는 뜻이다. 일반적으로 데이터는 할당된 10bytes 이상을 쓰이지는 않는다. 하지만 만약 누군가가 var에 10bytes크기 이상의 데이터를 쓴다면 Stack Overflow가 일어날 것이다.

 당신이 10ml의 물을 담을 수 있는 잔이라고 상상해보자. 하지만 당신이 10ml이상의 물을 채우려 한다면 어떻게 되겠는가? 물은 넘쳐흐를 것이다. 이와 같이 data가 var변수에 10bytes이상의 데이터를 쓰게 된다면, 10bytes로 할당된 메모리 공간 너머는 오류가 날 것이며 시스템 에러가 발생될 것이다. 밑의 예를 보도록 하자.

 위의 예를 보면, 변수 “var”에 문자열을 복사하기 위해 strcpy함수가 불려졌다. 그리고 복사된 문자열을 콘솔창에 출력한다. 이 장면 뒤에 무슨 일이 일어나는지 정확하게 알기 위해서 F10키를 이용하여 단계적으로 프로그램 실행을 해보자(명령어를 단계적으로 실행시킨다).

 어셈블리 명령어 창과 레지스터 창, 디스어셈블된 코드 창을 실행시켜 보자. 코드의 8번째 줄에 브레이크 포인트를 각각 걸어주고, 프로그램이 브레이크 포인트에서 멈출 때 view menu/debug/disassembly를 열어준다. 또 f10키를 사용할 때에는(단계 실행), 메인 함수 안에서 멈추게 되면 view menu/debug/disassembly를 열어준다. view/debug menu (registers/memory/callstack)는 모두 유용한 메뉴들이다. 그러므로 아래의 예제를 이해할 때 메모리와 레지스터 창을 사용할 것을 추천한다.

 7번째 줄의 명령어가 실행된 후에 레지스터와 메모리 상태는 다음과 같은 값을 가질 것이다.

 앞의 두 절에서 배운 것과 같이, EBP는 지금 실행되고 있는 스택 프레임의 현재 base pointer의 위치이고 EIP는 현재 명령어 포인터이다.

 위의 표의 EBP와 EIP레지스터를 보면 EBP는 함수가 끝날 때까지(10번째 줄, 함수 에필로그가 시작한 후) 같은 것을 알 수 있다. 그리고 EBP(0×44444444)와 EIP(0×45454545) 모두 잘못된 주소들을 가리키고 있다.

 NOTE: 만약 “var”변수에 작은 문자열(예:AAAABBBB)이 복사된다면 프로그램은 정상적으로 종료될 것이다. 만약 strcpy(var, “AAAABBBB”);가 9번째 줄에 사용되면 EIP(0×00401309)와 EBP(0×0012000A)는 정상적인 값을 갖게 된다. 그러므로 프로그램은 정상적으로 종료될 것이다. (“AAAABBBB” = 0×41414141, 0×42424242)

Figure: EBP와 EIP레지스터에 덮어쓴 basic.cpp의 개략적인 표현

 위의 figure에 나와 있듯이, 스택에 레지스터 값을 저장하는 것 외에 스택 프레임이 생성될 때에 ESP와 EBP의 값 또한 스택에 저장된다. 덮어쓴 이 값들은 프로그램의 실행 경로를 바꿀 수 있다. 위 프로그램 내에서는 상위 함수 스택 프레임 EBP와 ESP의 값을 strcpy의 함수가 버퍼 경계 체크를 하지 않는 점을 이용하여 0×44444444와 0×45454545로 덮어 썼다. 메모리 0×44444444위치를 보면 그곳엔 아무것도 없으므로 에러가 발생한다.

 이 문제의 원인은 strcpy함수를 사용한 것이다. strcpy에서 출발지 버퍼가 도착지 버퍼보다 클 때에 Overflow가 일어나는 것이다.

 위의 예제를 밑의 예제처럼 약간 변경해보자. 이 수정된 예제에서, (위의 코드와 비슷한 부분은 건너뛰기로 하겠다) 문자열은 “strcpy”를 사용하여 다른 변수에 복사된다.

 이 프로그램에서는 어디에서도 사용되지 않는 함수가 추가된다. 스택을 Overflow시키고 프로그램이 끝나기 전에 추가된 함수 안의 명령어를 실행시키는 연습을 할 것이다. 이 예제에서는 EIP를 어떻게 컨트롤 할 것인지와 우리가 원하는 것을 실행시키는 법을 배울 것이다.

이 콘솔 프로그램은 main함수, hacked함수, copy함수인 3개의 함수를 가지고 있다.  main함수는 어플리케이션에 인수를 강제로 전달하거나 에러메시지를 생성한다(20-23번째 줄). 35번째 줄은 hacked함수의 위치를 출력하고 이 정보를 이용하여 어플리케이션을 공격 할 것이며 37번째 줄은 인자를 어플리케이션과 copy함수에 전달한다.  copy함수 input변수로 인자를 받고, “var”의 캐릭터형의 20byte크기의 배열을 선언한다(11번째 줄). 그리고 input변수로부터 받은 데이터를 변수”var”에 strcpy함수를 사용하여 복사한다(12번째 줄).  hacked함수는 프로그램 안에서는 실행되지 않는다(프로그램을 컴파일할 때 경고메시지가 뜨겠지만 무시하라). 이 함수는 콘솔 창에 하나의 문장을 출력한다. 한번 프로그램에 성공적으로 컴파일이 되었으면 명령어 줄에 인자 값을 넣어 실행해보자.

프로그램의 결과 값은 위에 표시된 것과 비슷할 것이다. 이와 같이 hacked함수가 시작되는 위치를 알려준다.  visual studio로 다시 돌아가자. copy함수에 브레이크 포인터를 걸고 visual 인터페이스를 통해(Project/Settings/Program Arguments) 프로그램에 같은 인수를 준 다음 go버튼을 클릭해보라(F5). 디버그 창에서 몇 장을 위로 스크롤해보면 밑의 명령어들이 보일 것이다.

이 명령어들은 함수코드경로가 열거된 위치로 jump하는 명령어들이다. 실질적인 함수 명령어들은 아래의 메모리 위치들 사이에 열거되어있다.

우리의 목표는 0040100F위치로 실행경로를 바꾸는 것이다(jmp hacked). EIP는 실행된 다음의 명령어를 가리키고 있는 포인터를 저장하는 레지스터라는 것을 기억하자.  우리가 이전 예제에서 보았듯이 strcpy함수에 사용하기위해 복사된 변수를 위해 할당된 공간보다 큰 문자열을 제공하는 것은 EBP와 EIP를 덮어쓰는 것 처럼 스택 오버플로우를 발생시킨다. 그러므로 우리는 EBP와 EIP를 큰 문자열을 사용함으로써 한 번더 덮어쓸 수 있다. 단지 16개의 문자를 사용하는 대신, 더 큰 문자열을 사용해보자(AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLL). 그리고 비슷한 결과가 출력되는지 살펴보자. 에러가 실행되고 에러 메시지가 보일 것이다.

 ”click here”을 클릭함으로써 충돌에 대한 기본적인 정보를 사용할 수 있다(AppName: basichacked.exe AppVer: 0.0.0.0 ModName: unknown ModVer: 0.0.0.0 Offset:

47474747). 오프셋의 값이 47474747이라는 이 정보는 꽤 유용하다. 47474747의 hex값은 GGGG이다. 그러므로 우리는 성공적으로 EIP를 GGGG로 덮어 쓴 것이다. 그러므로 이 프로그램의 실행경로는 현재 47474747로 수정된 것이다(우리는 이런 경고 내에서 EBP와 EIP에 덮여쓰여진 값을 확인 할 수 있기 때문에 이러한 에러메시지는 매우 유용하다. 이 예제에서는 EBP에는 FFFF값으로, EIP에는 GGGG값으로 덮어쓰여졌다). 레지스터 값을 더 자세히 보도록 하자.

Figure: copy함수에 들어가기 전의 레지스터 값

아래의 그림에 표시된 것은 copy함수에 들어간 후의 값이다. 스택 프레임이 생성되면 EBP의 값은 새로운 프레임의 베이스를 가리키게 된다.

strcpy함수 후의 저장된 EBP와 EIP의 값이 출력되었다. 하지만 현재의 EBP와 EIP는 수정되지 않았다. “RET”명령어에 도달했을 때 pop된 데이터가 스택의 EBP와 EIP레지스터에 저장된다.

Figure: 스택의 상태(저장된 EIP와 EBP의 수정된 값들)

함수가 완료되었을 때, “RET”명령어에 도달하면(에필로그) 스택에 저장된 EBP와 EIP값 모두 pop된다. 이 값들은 스택 프레임이 생성될 때(프롤로그) 스택에 저장된다. 그러나 버퍼가 오버플로우될 때, 이 값들은 DDDD(0×44444444)와 EEEE(0×45454545)의 16진수값으로 덮어써진다. window assembly장에서 배웠듯이 스택은 밑으로 자란다. 그러므로 긴 문자열 “AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHH”은 EBP와 EIP의 저장된 값에 덮어쓴다.

Figure: ret에 도달했을 때 EBP 덮어쓰기

이제 우리는 EBP와 EIP를 덮어쓸 수 있다. 다음 단계는 hacked함수와 EBP와 EIP를 덮어 쓰는 것이다. 콘솔에 출력된 것처럼 hacked함수의 위치는 0×0040100f이다. 16진수 포맷값을 인자로 주기위해서 다음과 같은 perl 스크립트를 사용했다.

  perl 스크립트는 다음과 같은 결과 값을 생성할 것이다.

1. Address of functiong : 0×0040100f
   
2. Can You See me now?
   

그러므로 스크립트는 hacked함수로 점프하는 명령어 위치로 EIP를 덮어썼다.

Note: 주소는 Intel 프로세서의 little endian형식 때문에 거꾸로 써진다.

 hacked의 내부 코드와 같은 유용한 함수는 쉽게 찾을 순 없을 것이다. 잠재적으로 시스템의 커맨드 프롬프트 혹은 무언가 실행을 하는 것을 실제로 실행하는 우리가 제작한 코드를 불러와야만 할 것이다. 우리의 함수를 로드하기 위해서는 우리는 코드를 프로그램으로 로딩하는 몇 가지 방법이 필요하다. 그리고 그 어플리케이션이 코드를 실행하게 해야한다.

 어플리케이션이 미리 컴파일되었다면 전형적인 C/C++코드는 아닐 것이다. 알고 있겠지만, 컴파일된 코드는 숫자(Op Code)로 표현되어 메모리에 로드되었다. 우리는 이러한 Op Code들을 목표로 하는 어플리케이션과 동일한 메모리 영역 내부에 써야 할 것이다. 이런 코드는 shellcode 또는 payload라고 불린다. 다음 섹션에서는 어떻게 이러한 Op Code를 작성하는 지 배울 것이다.

Utilities:

       ＊ Perl

     ＊ Visual Studio C++

추가적인 읽을거리/레퍼런스들의 링크:

＊http://www.metasploit.com/
Metasploit사이트는 쉘코드와 익스플로잇 정보를 얻기에 좋은 사이트이다.

＊http://www.securiteam.com 익스플로잇과 흥미있는 기사와 많은해커 사이트들을 포스팅해놓았다.

＊http://www.k-otik.com/
익스플로잇 정보가 많은 사이트

＊http://www.xfocus.org/
많은 익스플로잇과 토론이 활발한 사이트다.

＊http://www.activestate.com/
Active perl, 윈도우에서 실행되는perl정보들이 많은 사이트이다.

이 문서는 위에서 언급한 다양한 사이트에서 제공하는 문서를 바탕으로 쓰여졌다. 가능하다면 이 모든 문서를 읽어보길 추천한다.

To Do (Mini Exercise – Paper Part Ⅲ):

 아래의 코드를 VC++(또는 Visual Studio 7.0/7.1)로 컴파일 하고 디스어셈블한 코드를 보라.