스토리노믹스 (로버트 맥키, 토머스 제라스) ㄴ읽다가 만 책

스토리노믹스

[한줄평]
학술서를 읽는 느낌.

일단 이 책의 주요 목표가
어떻게 하면 스토리를 이용해서 대중들에게
광고나 자신이 주장하는 것을 잘 전달하고
감흥시킬 수 있을까에 대한 책인데
최소한 나한테는 그 목적을 상실했다.

이 책의 스토리가 너무 별로다.
그런 책이 스토리에 대한 이야기를 한다는 것이 웃기다.

책은 거의 무슨 학술서를 읽는 느낌이다.
저자들이 자신의 책에 대한 스토리는 제대로 살리지 못한 것이 아닌가 싶다.

책의 1/3까지 읽고 그냥 덮었다.

진화한 마음 (전중환) ㄴ추천도서

진화한 마음

[한줄평] ★★★★★
진화로 풀어낸 우리 인간의 심리와 행동.


위 한줄평의 동일 작가의 다른 책 오래된 연장통(shadowxx.egloos.com/11389965)에 내가 쓴 한줄평이다.

나는 왜 다른 책에 썼던 한줄평을 그대로 이 책에 가져다 썼을까?
한줄평이 같다면 책의 내용도 서로 비슷한 것이 아닌가?
그럼 이 책은 읽을 필요가 없는 것이 아닌가?

한마디로 정리한다.

그의 책은 언제나 옳다.
내가 이렇게 쓸만큼 그의 책은 너무나도 좋다.

뉴스나 일반적인 진화론 책에 써져 있는 내용이 아닌
정말 새롭고 재미난 사례와 이야기가 그의 책에는 듬뿍 담겨있다.

그래서 같은 주제(진화심리학)로 다룬 책이 어려 권 있더라도
그가 쓴 책들은 모두들 새롭게 나를 즐겁게 한다.

이 책 역시 오래된 연장통에서 다뤘던 주제들을 다루고 있지만
역시나 새롭다.
그래서 읽을 가치가 충분하며, 아니, 꼭 읽어야 하는 책이다.

왜 우리 인간은 이런 상황에서 이렇게 행동하는지 추적해보고,
아무런 의문도 없이 받아들였던 행동에 큰 물음표를 던지는 이야기들은
책을 읽는 내내 "오~", "우와~ 그렇구나" 라는 감탄사를 자아낸다.

전중환 교수의 다음 책이 기대된다.

NSIS 설치파일 무결성(integrity) 검사 우회 방법 ㄴReverse Engineering

먼저 integrity 로 string 검사를 통해 호출되는 부분을 찾는다.

그리고 나서 호출하는 부분을 다시 호출하는 곳(보통 5~6곳)을 모두 nop 처리한다.
이때 조심해야 할 것은 명령어(jz, jb, jge 등)에 따라서 byte 수가 다르기 때문에
맞춰서 nop 명령(hex 90값)를 잘 넣어줘야 한다.





x64dbg를 활용한 윈도우 팝업 창(dialog) 혹은 프로그램 특정한 곳에 breakpoint 걸기 ㄴReverse Engineering

리버싱을 하다보면 팝업 윈도우가 나타나더라도 아무런 반응이 없는 프로그램들이 있다.

쉽게 말해서 잘못된 라이센스를 넣거나 하면
wrong password 라던가 뭔가 action 이 있어야 하는데
리버싱을 막기 위해서 아무런 action 을 안하는 프로그램들이 있다.

이런 상황에서 도대체 지금 팝업 창이나 특정 문구가 나오는 위치를 알아내기가 까다로울 수 있는데
이럴 때 바로 x64dbg 의 handles 를 사용해서 문제의 위치를 쉽게 찾아낼 수 있다.

다음은 x64dbg 공식 사이트에 나온 내용이다.

Messages Breakpoints in x64dbg

Introduction

Have you ever been trying to reverse a specific function in an application, but cannot really find it? For instance, let us assume you want to locate the code that is being called right after a click on a button or a keystroke. With certain applications (Delphi, CBuilder, Visual Basic, etc) it is as easy as dropping the executable inside a decompiler and locating the corresponding events/addresses in a matter of seconds. Sometimes it is not that easy, whether a packer or anti-decompiler technique is involved, or just for the simple reason that the application is not an event-driven one. What can you do in that case to obtain those addresses in a similar approach with the least effort?

Using Windows Messages

Let us take a look at a sample crackme for demonstration purposes. In this case we have a simple executable coded in Visual C++:

sample crackme

If we try to enter a text and click on the Check! button nothing is happening, not a text message, no nothing. At this point we could get creative and start looking for other alternatives to locate the exact location where our serial is processed and yes, we would probably succeed, but what if I tell you that there is an easier way for us to land just after the press of that button? Just like we would with any Delphi, Visual Basic or any other event-driven language? Let us find out how it works.

After loading and executing the file in x64dbg, we go and enter some text and just before pressing the Check! button we go to the Handles tab and refresh the view to obtain a window list of the debuggee. We can then see the button there so we right click over it and select the option to set a message breakpoint on it:

windows widget

Now we are given a window with some options to choose from in order to set a specific message breakpoint in our button control. In this case the configuration I am going to use is something like this:

message bp dialog

We are specifying that the execution is stopping as soon as a WM_LBUTTONUP (left mouse click is up) message is sent to our button control. Right after our breakpoint is set we click the button in the crackme and soon after that we step in our breakpoint.

At this point we achieved what we wanted. We just stopped the execution right after the button click, on the other hand we are in user32.dll and our purpose is to be in the main module code. Getting there is as simple as just using a breakpoint in the code section of our executable. You can also use the Run to user code option (Ctrl+F9).

code section breakpoint

When trying to resume the execution, the debugger is going to stop the execution once again, but this time right in the middle of the code we were looking for. In this case in the DLGPROC function (the callback in charge of processing the messages being sent to every window control in the main window dialog).

dialog function

Event-driven programming

If you are a programmer, or have been in contact with programming languages in general and coding tasks, you should know the concept of the so called event-driven programming. Event-driven programming is a programming paradigm in which the stream of a program execution is dictated by events; a user action, a mouse click, a key press, etc. An event-driven application is intended to identify events as they happen, and afterwards manage them, utilizing a suitable event-handling procedure. Some programming languages are particularly intended to encourage event-driven programming, and give an IDE that halfway computerizes the generation of code, and gives an extensive choice of inherent built-in objects and controls, Visual Basic, Borland Delphi/CBuilder, C#, Java, etc are some of these types of languages. (1)

Window Messages

Even if a programmer is not using one of the above languages or even if they are using them in a non event-driven manner, Microsoft Windows applications are event-driven by nature, which means that you are going to be dealing with window messages anyway. According to the MSDN:

The system passes all input for an application to the various windows in the application. Each window has a function, called a window procedure, that the system calls whenever it has input for the window. The window procedure processes the input and returns control to the system.

The system sends a message to a window procedure with a set of four parameters: a window handle, a message identifier, and two values called message parameters. The window handle identifies the window for which the message is intended. The system uses it to determine which window procedure should receive the message.

A message identifier is a named constant that identifies the purpose of a message. When a window procedure receives a message, it uses a message identifier to determine how to process the message. (2)

Window Procedures

According to the previous information, in order to intercept window messages for a certain window, we need to first locate the window procedure of the desired “control”. To so do from the application that contains the window procedure is quite easy, it can be located by using the following functions:

LONG WINAPI GetWindowLong(  _In_ HWND hWnd,  _In_ int  nIndex);DWORD WINAPI GetClassLong(  _In_ HWND hWnd,  _In_ int  nIndex);

nIndex = GWL_WNDPROC: Retrieves the address of the window procedure, or a handle representing the address of the window procedure. You must use the CallWindowProc function to call the window procedure.

BOOL WINAPI GetClassInfo(  _In_opt_ HINSTANCE  hInstance,  _In_     LPCTSTR    lpClassName,  _Out_    LPWNDCLASS lpWndClass);BOOL WINAPI GetClassInfoEx(  _In_opt_ HINSTANCE    hinst,  _In_     LPCTSTR      lpszClass,  _Out_    LPWNDCLASSEX lpwcx);typedef struct tagWNDCLASS {  UINT      style;  WNDPROC   lpfnWndProc;  ...} WNDCLASS, *PWNDCLASS;

lpfnWndProc: A pointer to the window procedure.

At this point everything looks very straightforward, but nonetheless, there is one limitation imposed by our OS: Microsoft Windows will not let you get this information from an external application (such as a debugger). If you want to get the window procedure address of a given window or control that is owned by another process using one of the above functions, you will end up with an ACCESS_VIOLATION exception. In our case x64dbg will be no different and hence none of the previous functions will work properly…well…yes and no. Here comes the workaround used by x64dbg to get the correct window procedure address.

Getting External Window Procedures

At this point it is not clear why this behavior occurs and whether it is OS bug. The thing is, that it can be used in all previous Windows versions. The important function here is:

DWORD WINAPI GetClassLong(  _In_ HWND hWnd,  _In_ int  nIndex);

The hack relies on testing for the given window’s charset before calling the correct function version of GetClassLong (ANSI/UNICODE) accordingly. The code used by x64dbg is something as simple as this:

duint wndProc;if(IsWindowUnicode(hWnd))    wndProc = GetClassLongPtrW(hWnd, GCLP_WNDPROC);else    wndProc = GetClassLongPtrA(hWnd, GCLP_WNDPROC);

To write code that is compatible with both 32-bit and 64-bit versions of Windows, you have to use GetClassLongPtr. When compiling for 32-bit Windows, GetClassLongPtr is defined as a call to the usual GetClassLong function.

Intercepting Messages

Now that the window procedure is located, any message could be intercepted with a proper conditional expression, but before that, let us check the logic behind this. The structure being processed each time by the window procedure looks like this:

typedef struct tagMSG {  HWND   hwnd;  UINT   message;  WPARAM wParam;  LPARAM lParam;  DWORD  time;  POINT  pt;} MSG, *PMSG, *LPMSG;

As we can see the structure give us some useful information at this point, most importantly hwnd and message. According to these fields we could know to which specific control what message is being sent to. Before going any further let us see an example for an specific message (WM_LBUTTONUP) being sent to a given Button control.

message breakpoint dialog

After clicking the OK button we step on the breakpoint and when we inspect the stack arguments we can see something like this

breakpoint stack

The first as can be seen is the handle corresponding to our Button control and the second corresponding to the message WM_LBUTTONUP (0x202).

WinProc Conditional Breakpoints

The last thing to get this feature fully working is the possibility to pause the application only when specifics handles and messages are in play. As you can read in the help, x64dbg integrates a very nice and powerful set of expressions to allow this. As shown in the above picture there are three options involved:

  1. Break on any window: Using this option we stop on the given message regardless the window handle. For this we need the simplest expression:
bpcnd WINPROC, "arg.get(1) == MESSAGE"
  1. Break on current window only: This feature will add an additional condition to the expression in order to stop the execution only when the handle of the specific window is involved, the expression in this case would be:
bpcnd WINPROC, "arg.get(1) == MESSAGE && arg.get(0) == HANDLE"
  1. Use TranslateMessage: Sometimes the winproc technique will not give the expected results so this other feature goes out of the scope of the previous technique as it relies in the TranslateMessage API to intercept messages and not in the window procedures themselves. Althought the logic is more or less the same.
BOOL WINAPI TranslateMessage(  _In_ const MSG *lpMsg);

As seen the function uses the same MSG structure that we saw before, hence the functioning with the expressions will be more of the same with some minor changes depending on the OS platform:

ifdef _WIN64bpcnd TranslateMessage, "4:[arg.get(0)+8] == MESSAGE"bpcnd TranslateMessage, "4:[arg.get(0)+8] == MESSAGE && 4:[arg.get(0)] == HANDLE"#else //x86bpcnd TranslateMessage, "[arg.get(0)+4] == MESSAGE"bpcnd TranslateMessage, "[arg.get(0)+4] == MESSAGE && [arg.get(0)] == HANDLE"#endif //_WIN64

Use Cases

As seen in this post, this is a very convenient and strong feature in x64dbg and can be used in numerous scenarios. Having the possibility to control on which events to pause a debuggee, even if it is not and event-driven application like a Delphi or Visual Basic, open the doors and give the reverser even more resources to debug. If you want to pause the execution when entering a char in an Edit control in a MASM application just set a messages breakpoint on the control itself with the message WM_KEYUP, simple as that. Same goes for Button clicks, showing windows, etc. There are a whole bunch of messages options to choose from.

Final Words

With these lines I tried to give an in-depth view of the messages breakpoints feature and some of the multiple scenarios where and how to use it. And this is all for this post, see ya around.

ThunderCls signing out

References

  1. https://www.technologyuk.net/computing/software-development/event-driven-programming.shtml
  2. https://msdn.microsoft.com/en-us/library/windows/desktop/ms644927(v=vs.85).asp

윈도우 시작 메뉴에서 키보드 입력으로 search 가 안 되는 문제 컴부리 이야기

언젠가부터 윈도우 시작 버튼을 눌러서 바로 프로그램을 찾는 기능이 작동을 안한다. ㅡㅡ;;;

사실 이게 없으면 cmd 관리자 권한으로 실행시키는 것 등을 할 때 무지 귀찮다.

windows key 누르면 시작메뉴가 나오는데 이때 키보드로 cmd를 넣거나 하면 아래와 같이 나와야 한다.



그래서 문제의 원인을 찾아보니 
SearchApp.exe 가 실행되지 않고 있었다.

이놈은 보통 다음과 같은 경로에 있어야 하는데
C:\Windows\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\SearchApp.exe

기능이 실행 안 될때는 다음과 같이 폴더가 .old가 붙어서 사용하지 않게 되어 있었다는... ㅡㅡ;;
C:\Windows\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy.old\SearchApp.exe



이 문제는 이벤트 뷰어 > 시스템 에서 에러 로그를 통해서 확인하고 수정하게 되었다.

왜 모든 사람은 (나만 빼고) 위선자인가 (로버트 커즈번) ㄴ추천도서

왜 모든 사람은 (나만 빼고) 위선자인가

[한줄평] ★★★★★
인간 사고에 대한 생각의 전환을 갖게 해준다.

나는 살아가면서 생각의 기틀을 흔드는 지식을 가끔 접하게 된다.
리처드 도킨스의 이기적 유전자를 읽을 때도 그랬고,
대니얼 카너먼의 생각에 관한 생각을 읽을 때도 그랬고,
주디스 리치 해리스의 양육가설을 읽을 때도 그랬고,
리처드 니스벳의 생각의 지도를 읽을 때도 그랬고,
제러드 다이아몬드의 총, 균, 쇠를 읽을 때도 그랬다.

그런데 이번 책을 읽으면서 또 한 번의 경험을 갖게 됐다.

이 책의 가장 중심 내용은
인간은 전체적으로 생각하지 않는다는 것이다.

쉽게 설명하면 우리 인간이 생각할 때는
이것을 할까 하는 생각도 있고, 말까 하는 생각도 있고, 그 일에 관심 없는 생각도 있고 등등
다양한 생각들이 모듈화되어서 작동한다는 것이다.

예를 들어 설명하자면
인간이 자동차라고 하고, 내가 어떤 결정을 내린다는 것을 자동차가 앞으로 가는 것으로 비유한다면
자동차에 동력을 만들어 내는 엔진, 동력을 전달하는 바퀴, 방향을 조정하는 운전대 등등
수많은 기능들이 모여서 앞으로 간다는 것이다.

그런데 우리는 그런 결과만을 놓고 자동차가 그냥 앞으로 간다.
왜 그런데? 라고 물으면, 엑셀을 밟았으니 그렇지 라고 단순하게 설명한다는 것이다.

이것이 우리 사고로 오면
마트에 들어가서 물건을 살 때
냄새를 맡고 배고픔을 느끼는 모듈도 있고, 화려한 포장지에 현혹되는 모듈도 있고,
생활비를 생각하는 모듈도 있고, 배우자의 눈치를 살피는 모듈도 있고,
쇼핑의 피곤함을 느끼는 모듈도 있고, 즐거움을 느끼는 모듈도 있고 하기 때문에
이런 수많은 모듈들이 서로 이런저런 결정을 해서 우리가 행동을 하게 된다는 것이다.

그러면서 너 이 물건 왜 샀어 하면, 그냥 질문자가 듣기에 합리적이여 보이는 대답을 한다.

우리 사고의 모듈성을 알려준 이 책은 정말 획기적이다.

다만 번역이 그런지 원문이 그런지 모르겠는데
말이 엄청 이상하게 쓰여진 부분이 다소 많다.
번역의 문제가 아닐까 싶은데
아마도 이런 생각도 번역이 문제라고 생각하는 모듈, 내용을 이해 못하는 모듈,
다른 일에 빠져 있는 모듈, 책을 읽는 모듈들이 뒤엉켜서 내린 결론을
내가 저렇게 번역의 문제 라고 단순화하여 말하는 것인지도 모르겠다.

엔드 오브 타임 (브라이언 그린) ㄴ추천도서

엔드 오브 타임

[한줄평] ★★★☆☆
엔트로피에서 시작해 진화론, 그리고 엠파이어 스테이트 빌딩까지 우주의 시간을 이야기한다.

먼저 이 책은 두껍다.
그래서 선뜻 책을 읽어볼 엄두를 내는게 어렵다.
그러나 책을 몇장만 읽어봐도 책 속으로 확 빨려 들어간다.

저자는 모든 물리학이나 수학 등을
일반인들이 알기 쉽도록 비유와 상세한 설명으로 풀어낸다.

우주의 시작에서의 엔트로피의 역할과 중력,
인간의 죽음, 영생, 마음, 종교, 예술을 탄생시킨 진화론,
거대한 우주 시간이 흘러가면 어떻게 되는지 엠파이어 스테이트 빌딩을 오르면서
우리에게 친절하게 우리가 살고 있는 우주가 어떤지, 인간은 무엇인지 등에 대해서 말한다.

물론 몇몇 장에서는 상세한 부분까지 들어가 조금은 신경을 써서 읽어야 하는 부분도 있지만
이 책은 꼭 한번 읽어봐야 하는 것이 아닌가 생각이 든다.

빅맨 SELECTED (마크 판 퓌흐트, 안자나 아후자) ㄴ추천도서

빅맨 SELECTED

[한줄평] ★★★☆☆
우리가 리더를 따르는 이유와 리더십의 발생에 대해서 진화적으로 풀어냈다.

진화심리학 책을 읽고 나서 더 깊은 분야를 알고 싶어서 이 책을 읽었다. 
이 책은 리더십과 팔로워십(리더를 따르는 것)이 왜 진화심리학적으로 발생했는지를 재미나게 엮어 낸다.

사실 나도 별 생각없이 리더십, 리더십 했는데
우리는 왜 리더를 따르는 것일까?
그리고 완전히 수평적인 조직은 생길 수 없는 것일까?
리더의 자질은 무엇일까? 등등

그동안 막연하게 궁금해 왔던 질문들에 대한 대답이 이 책에 자세히 제시되어 있다.
즉, 우리는 진화적인 측면에서 리더십과 팔로워십이 도움이 되었기 때문에 그렇다는 것이다.

그럼 우리는 어떤 리더에게 끌릴까?
이것도 역시 예전 사바나에 살던 우리 조상들이 살아남기 위해 도움이 되었던 리더의 특징을 선택했다는 것이다.
물론 그때는 지금보다 리더와 팔로워가 훨씬 평등했다고 한다.

그 외에도
진화적으로 받아들인 리더의 특징과
현대 사회에 필요로 하는 리더의 특징의 괴리에 대한 이야기도 담고 있다.

재개발될 빌라 리모델링할 아파트 (엘디쌤, 이관용) 책에 관한 작은 이야기

재개발될 빌라 리모델링할 아파트

[한줄평] ★☆☆☆☆
입주물량으로 지역 예측하는 내용이 반복.

이젠에 그의 책 경기도 부동산 투자지도(http://shadowxx.egloos.com/11385524)을 읽고 너무 많이 실망해서
더는 그의 책을 사지 말아야지 했는데...
혹시나 하는 맘에 샀더니...역시나다.

책의 내용은 아주 단순하다. 그냥 입주물량이 적은 곳을 사야 한다는 것이다.
책이 담고 있는 내용에 비해서 책 쪽수를 늘리기 위한 다양한 방법을 사용했다.
따라서 이 책은 그냥 서점에 서서 20~30분만 읽어도 된다.

그의 블로그에 올라오는 글은 꽤 괜찮은데 책은 왜 이런지 모르겠다.

엑셀에서 찾기 (ctrl + f) 기능을 함수로 구현하기 컴부리 이야기

FIND(B2,PHONETIC(E:G))

끝이다.

이렇게 하면 B2 칸에 들어 있는 글자가 범위로 지정한 글자의 전체 수에서
몇 번째에 있는지를 찾아준다.
즉, 저렇게 했는데 #VALUE! 가 나오면 B2칸에 있는 글자가 범위에는 없다는 소리다.

1 2 3 4 5 6 7 8 9 10 다음