Without a Break

문제 페이지로 들어가면 진짜 문자가 날라다닌다. 소스를 보면 각 문자 이미지가 있다. html 코드를 살펴보니 각 이미지 파일이 10 → 17 → 13 → 7 → ••• 순서로 있다. 아까 소스에서 발견한 각 이미지 파일의 문자를 코드에 있는 순서대로 배열하고 드림핵 형식을 맞춰주면 플래그를 찾을 수 있다.

보호되어 있는 글입니다.

문제 파일을 디버거로 열었을 때의 모습 먼저 corret를 출력하는 입력값을 찾기 위해 corret 문자를 찾아준다. 해당 위치로 이동하면 test eax,eax에서 입력값과 정답을 비교하는 것을 알 수 있다. 따라서 그 위의 코드에 있는 7FF6042D1186에 정답이 있을 것 같으니 살펴보자 7FF6042D1186로 이동하니 20개의 문자열과 사용자의 입력값을 비교한다는 것을 알 수 있었다. 비교한 후, 7FF6042D3000의 주소 값을 호출하는 것을 보아 해당 위치에 플래그가 있을 것 같다. 해당 위치의 HEX DUMP를 살펴보니 20개의 문자열이 있었다. 이제 이걸 플래그로 변환해보자 코드를 작성하고 실행해주면 플래그를 발견할 수 있다.

문제 파일을 디버거로 실행하면 위와 같이 뜬다. "correct"가 출력되는 입력값을 찾아야하니 문자열로 가보자 correct가 있는 위치로 이동하면 위와 같은 위치로 이동한다. 어셈블리 코드를 확인해보면 test eax,eax에서 입력값과 정답을 비교하는 것을 확인할 수 있었다. 그 위의 7FF799851000의 위치에 플래그가 있는 것 같으니 이동해보자 rcx(input값)와 7FF799853000의 값을 한 글자씩 18번 비교한다. 7FF799853000의 위치에 정답이 있는 것 같음 7FF799853000의 HEX DUMP는 위와 같다. 24개의 문자열이 있고, 이 문자들로 xor 연산을 통해 입력값과 비교한다. 따라서 HEX 값을 문자열로 변환시키기 위해서는 역연산을 해야한다. 1. (input..

실행 파일을 디버거로 열어준다 correct를 출력하는 입력값을 찾아야하니 문자열로 가보자 이동해보니 correct를 발견할 수 있었다. 해당 위치로 이동해보자 이동해보니 test eax,eax로 input 값과 정답을 비교하고 correct를 출력한다. 비교 후 correct를 출력하기 전에 출력하는 7FF6D04B1000의 위치로 이동해보자 rcx(input값)와 7FF7D04B3000의 값을 한 글자씩 12번 비교한다. 7FF7D04B3000에 플래그가 있는 것 같으니 해당 위치로 이동해보자 HEX DUMP에 플래그가 있었다

분석해야 할 것 공격에 성공한 공격자 IP 공격자 이외 서비스에 접근한 IP 공격자가 시스템에 침투하기 위해 접근한 서비스 포트 공격자가 이용한 취약점 공격자가 리버스 공격을 하기 위해 사용한 포트 공격자가 올린 웹쉘의 이름과 md5 해시 값 공격자가 웹쉘을 올린 뒤에 사용한 명령어 얘는 패킷이 좀 많음.. 패킷 통계 보면 저번 사례와 마찬가지로 TCP 안의 HTTP가 많은 것을 확인할 수 있음 특히 HTTP안의 Media Type이 큼 카운터를 확인해보자 SQL Injection 같은 공격을 하면 4xx쪽으로 쏠리는데, 이건 정상 state code가 많다 => 정상적인 페이지로 접근해서 시스템을 공격했음을 추측할 수 있다 도메인을 확인해보니 공격했던 웹서비스 포트는 8180임을 알 수 있었다. att..