kiri2sd.py

Using : kiri2sd.py [-e|-d] <filename>

세이브 파일 수정할게 있어서 만들어봄

하아 . . . 하아 . . . 파이썬은 아름답구나 . . .

OverflowMe.exe

어셈블 코드 수정안하고 버퍼 오버플로우를 통해 Good 이라는 메시지 띄우시면 정답이십니다.

※ 참고 : 그냥 실행하면 프로세스에 남는 경우가 있습니다.

그런 경우 작업관리자에서 프로세스 강제 종료로 부탁드립니다.

설명에 앞서, BMP 옵션 BI_RGB 을 전제로 설명합니다.

프로그램 만들던 중 기존에 있던 프로그램에 문제가 있길래

30분 동안 삽질해서 알아냈다 -_- . . .

일반적인 BMP 파일 구조는 크게

위와 같이 구성되어 있다.

자세한 구조는

BITMAP FILE HEADER 는 http://msdn.microsoft.com/en-us/library/dd183374(v=vs.85).aspx

BITMAP INFO HEADER 는 http://msdn.microsoft.com/en-us/library/dd183376(v=vs.85).aspx

를 참고바람.

아무튼, 24bit 비트맵 파일의 경우 BITMAP COLOR 에는 3바이트씩(RGB)

32bit의 경우에는 4바이트씩(ARGB)으로 들어간다라고만 막연히 지내온게 4년 . . .

여기서 문제가 발생되었다 -_- . . .

가로 850px 짜리 이미지를 만들고 BITMAP COLOR에 3바이트씩 850번 넣고 저장하니

저장되질 않는다. (...)

이럴 때 찾아보는 위키 !

( 한국 위키는 쓰레기라 가능하면 타언어로 보는걸 추천합니다.

딴건 모르겠는데 특히 프로그래밍 관련은 개쓰레기... )

http://en.wikipedia.org/wiki/BMP_file_format

여기서 'Pixel storage' 부분을 보면

이런 작고 아름다운 공식을 볼 수 있다.

기존의 지식으로 계산해보면

ImageWidth = 850

BitsPerPixel = 24 (3)

라고 봤을 때 계산하면

850 x 3 = 2550 이 들어가는데

위 공식을 대입했을 경우

((24 x 850 + 31)/32)*4 = 2552

이 경우 나눗셈 할 시 소수점에 대해선 무조건 내림처리 해야하며

32 나누고 4 곱하니까 8로 나누면 되지 않느냐 라는 부분에 대해선

내림처리로 인해 값이 달라지므로 반드시 나눈 후 곱셈을 하는 계산해야 한다.

이렇게 되면 2552 와 2550 의 사이에 2 라는 값이 차이가 나게 된다.

이 2 라는 값은 padding에 속하는데 해당 위키의 'Example 1' 항목의 구조에서

이런식으로 확인할 수 있다.

따라서, 해당 비트맵의 Width 끝나는 시점에 공식에 의한 비트수와 기존의 비트수를 빼서 값이 남으면

그 값만큼 padding을 넣어줘야만 제대로된 비트맵 파일을 볼 수 있게 된다.

결론은 여기까지고, 추가로 padding 된 바이트도 bitmap 파일 구조에 비트수가 표현되는 부분(두 부분)이 있는데

이 부분의 값 또한 padding 값에 맞춰서 재계산해 줄 필요가 있다.

[ PADDING 을 넣은 올바른 예 ]

[ PADDING 을 잘못 넣은 예 ]

최근, 모사에서 문제가 유출됐다고해서 봤었는데 ( 지금은 삭제됨. )

정확하게는 기억 안나는데 어렴풋이 기억에 남은 것중 하나가

32bit 데이터를 저장하는 메모리가 있을때 마지막 1bit는 뭐시고 15bit는 뭐시고 16bit는 뭐시고해서

16bit 만 때어내서 결과를 출력해내라 ? 라는 문제가 있었다.

문제의 요지는 간단하므로 '결과만'을 출력하자고 하면

하면 끝나버린다.

하지만, 저 문제를 출제한 이유는 뭘까 . . .

아마, '비트 구조체' 를 이용한 문제가 아닐듯 싶다.

( 보통 쓰일 일 없는 이 녀석이지만, 가끔 압축 알고리즘 등과 같은 소스 분석하다보면 가끔가다 나온다. )

대충 요딴식으로 풀면 풀리겠다.

그런데 잘 생각해보니, 이렇게하면 바이트 순서(byte order)로 인해 값이 꼬이는 문제가 있지 않을까 떠올랐다.

여기서 잠깐 훑어보는 바이트 순서란 ?

크게 바이트 순서는 크게 빅 엔디언(Big-endian) 과 리틀 엔디언(Little-endian) 으로 나뉜다.

리틀 엔디언은 값을 거꾸로 저장하는 방식을 뜻한다.

예를 들어 00 00 00 01h 라는 값이 있을 경우, 저장하게 되면 01 00 00 00 와 같이 거꾸로 저장된다.

반대로, 빅 엔디언은 00 00 00 01h 라는 값이 있을시, 00 00 00 01 와 같은 형식으로 그대로 저장하게 된다.

최근 개인용 PC컴퓨터는 죄다 리틀 엔디언으로 나오니 크게 문제는 없어보지만,

위와 같은 이유로 컴파일러에 의해 01 00 00 00 와 같은 리틀 엔디언으로 값이 저장되면

빅 엔디언으로 읽는 컴퓨터로 갈 시 01 00 00 00 인 상태 그대로 읽어오는게 아닐까 하는

착각에 빠졌는데 . . .

잘 생각해보니, PE 파일 내에서 머신 옵션이 있기에 크게 상관없을거로 판단되는 결론이다.

( 하기사, 만든 사람들이 나같지 않았을테니 쓸데없는 걱정이였던듯 )

이 글을 읽기 전에, 어디까지나 필자가 보고 느낀 것을

그대로 적은거라 아래의 글이 틀릴 수 있습니다.

틀릴 시, 지적해주시면 감사하겠습니다.

무척이나 오랜만에 Visual Studio를 켜서 컴파일러해서 컴파일하려니까

/MD 와 /MT 의 차이를 잊어버리고 말았다.

나는 이 글에 관심이 없다. 우연히 검색하다 들어왔다. 하는 분들을 위해

결론부터 말하면 " 그냥 앵간해선 /MT 으로 컴파일 하시는 걸 추천합니다 "

그럼, 본격적으로 글을 적어보도록 하자.

:: /MD 의 경우, Import Table 와 올리디버그 ::

[ Import Table ]

 [ 올리디버그 ]

:: /MT 의 경우, Import Table 와 올리디버그 ::

 [Import Table]

 [올리디버그]

대충봐서 위 두개를 보고 차이를 느낀 사람은 그냥 창을 닫거나 했을 수 있을 법한데

CRT(C-RunTime) 함수가 들어가느냐, 안들어가느냐 차이이다.

/MD : 런타임 함수를 기본으로 컴파일러 함. ( 함수를 동적 라이브러리에서 불러옴. )

/MT : MS에서 제공하는 정적 라이브러리의 코드를 가져옴.

따라서, MD로 설정하는거보다 MT로 설정하는게 훨씬 용량이 크게 들어간다.

( inline 함수인가 inline 함수가 아닌가의 차이 )

그럼, 여기서 장단점을 감히 말해보도록 하자.

/MD 의 장단점

장점 : 용량이 적게 들어간다.

( 동적 라이브러리를 읽어옴으로 용량이 적게 들어간다. )

런타임 오류메시지로 /MT에 비해서 오류를 추적하기 쉽다.

단점 :  프로세스간의 호환이 뛰어나지 않다.

( 어떠한 경우에 의해 C-Runtime 에러가 발생할 확률이 높음. )

/MT 의 장단점

장점 : 프로세스간의 호환이 뛰어나다.

(자신이 고유 코드 영역을 가지고 있어, 충돌의 가능성은 거의 제로에 가깝다.)

단점 : 용량이 커진다.

( 정적 라이브러리가 들어가 용량이 커지게 된다. )

위 차이 정도니까, MD 보다는 개인적으로 MT 옵션을 추천한다.