OverflowMe.exe

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

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

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

exlefor3.7z

14.12.24 LastUpdate - RELOC 기능 추가.

만들기 전에 툴 찾아보니 나오긴한데, 제대로 추출되는게 거의 없어서 그냥 만들어버림.

일단, 라이브 엔진 추출할 때 씁니다.

(레알라이브 엔진이랑 다름.)

추출하다보면 gal 이란 파일이 종종 나오는데 이거도 내부에서 컨버팅시킬까 하다 꽤나 귀찮아져서

검색해보니 포토샵 플러그인으로 처리 가능한 듯 합니다.

(포토샵 plug-in -> file format  폴더에 dll 파일 포함해서 파일 전부 던지시면 됩니다.) 

버전 1,2 에 적용

plugin_0102.zip

버전 3 에 적용

plugin_03.zip

(포토샵 플러그인 FIle Format 폴더에 던지시면 됩니다.)

혹은 게임 만드는 툴로 직접보면 확실하게 보입니다.

p.s > 분석해보면서 느낀건데 이거만큼 비효율적인 엔진이 없는듯...

일단, 파일 크기 미사용, 쓰지도 않는 해쉬값 사용 그리고 내부에서 압축하고 압축하고 또 압축함 [...]

매번 이 엔진 만날 때마다 좀 느리네 라는 느낌을 왜 그랬나 이해했음...

설명에 앞서, 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 파일 내에서 머신 옵션이 있기에 크게 상관없을거로 판단되는 결론이다.

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

ChuableJapaneseCheck.exe

게임하다 이런 화면 가끔가다 보게 되는데

( Majiro 엔진 기능중 하난줄 알았는데, 잘 살펴보니 Chuable 사에서 구현한 기능 같네요. )

위 화면이 뜨면 위 프로그램을 실행하시면 처리됩니다.

일단, 이 상태에서도 적용됩니다.

( 완전히 일어로 보이거나 완전히 한글 상태로 깨진 상태에서만 인식합니다. )

분명, 예전에도 이 비슷한 패치를 만든 기억이 있는데 범용으로 만들진 않았던거로 기억함...