반응형

iPhone Debugger - Documentation

Nicolas A. Economou (*)
Core Security Technologies

Description

This tool is useful for debugging running (or newly created) native processes inside iPhone.

The development of this debugger is based on a previous Windows debugging tool (nicodbg, unreleased) and iPhone's debug API is inspired on the Patrick Walton's (with hdm's updates) weasel debugger.

It was developed on C++ and runs in native code inside iPhone. It has a console interface, similar to that of ntsd.exe, a debugger included in all Windows versions.

The design divides the tool into two parts, the interface and the C++ class for debugging, this enables the possibility of making another debugging tools with different interfaces. This design is simple and the debugger could be easily ported to another platforms.

Setup

Copy the executable iphonedbg to your preferred folder inside iPhone using OpenSSH Secure Copy (scp or WinSCP) or be any means possible.

Its usage is very simple, you've only need to be familiarized with console applications.

The working command and arguments follow:

iphonedbg [-e executable [arguments...]|-p pid executable]

The debugger can attach to a running process or start the process from scratch.

Real Life Example

  • We run Safari web browser in the iPhone and we list all the active processes from a console conected through ssh.

  • We write the command to attach the debugger to the Safari process.

  • Once we are attached to the process, the debugger loads all the process symbols and then waits for user commands.

  • We execute command g (go) and the process continues its execution waiting for some event or exception.

If after consulting a web page the Safari process crashes the debugger will inform it.

Help

Help is incorporated to the debugger accessing with the command h, the result is the following:


h -help
v -version
q -quit program
r [reg[=expression]] -print or set registers
g [expression] -run
t [value] -trace execution n times
p -trace execution not entering to calls
u [expression] -print code
db expression -read byte format memory
dd expression -read dword format memory
eb expression b1 b2 ... -write byte format memory
bp expression [condition] -set breakpoint [reg{<|<=|==|>=|>|<>}value]
bc expression -clear breakpoint
m -show memory map
s addr1 addr2 b1 b2 ... -search from addr1 to addr2
f addr1 addr2 byte -fill from addr1 to addr2 with byte value
~ -threads list
~<0..n>r -show register values from the thread number
'enter' -repeat last command

note: * to set breakpoints in thumb mode write address+1.
* to execute many cmds in a line use ';'.
* to execute many times a line: ex. 'repeat 3:r;g;'.

Command Examples

  • command "r"        = "r r3"     --> print the value of register r3 in hexadecimal
  • command "g"        = "g _main+8"  --> executes the process until function "_main" + 8 is reached
  • command "u"        = "u _main+8"  --> disassemblies function "_main" + 8
  • command "db"       = "db _main+8" --> dumps functions "_main" + 8 in 8-bit values
  • command "dd"       = "dd _main+8" --> dumps functions "_main" + 8 in 32-bit values
  • command "eb"       = "eb _main+8 cc cc cc cc" --> writes value 0xcccccccc at the beginning of function "_main" + 8
  • command "bp"       = "bp _main+8" --> sets a breakpoint at function "_main" + 8
  • command "bc"       = "bc _main+8" --> erases the breakpoint at function "_main" + 8
  • command "s"        = "s 0x1000 0x400000 CE FA ED FE" --> searches for pattern CE FA ED FE between addresses 0x1000 and 0x400000
  • command "f"        = "f 0x1000 0x2000 0" --> fills with zeros addresses between 0x1000 and 0x2000
  • command "x"        = "x libSystem.B.dylib!*" --> shows all the symbols of library libSystem.B.dylib
  • command "~"        = "~" --> shows all the threads of the process
  • command "~<0..n>r" = "~3r" --> shows the values of all register of thread number 3

Compiling From Scratch

There are two possibilites:

  • Downloading the known toolchain contained on a VMWare Linux image, iPhoneToolChainV2:
    • Copy iphonedbg-v?.?.zip to the VMWare Linux image and decompress it.
    • Run the following commands to compile the debugger:
          iPhoneToolchainV2:~/iphonedbg-v1.1# arm-apple-darwin-gcc -c disasm.c
iPhoneToolchainV2:~/iphonedbg-v1.1# arm-apple-darwin-g++ -L/usr/local/lib -o iphonedbg iphonedbg.cpp disasm.o
  • Download the iPhone SDK for Mac OS X from Apple or from iPhoneFix.de (not tested yet).

iPhone Crashes

When an application crashes inside iPhone a .plist file is generated on directory /private/var/logs/CrashReporter. This is basically an XML file with the state of the register, thread and the exception type generated. If it is a kernel crash is written at /private/var/logs/CrashReporter/Panics.


(*) Nicolas A. Economou (neconomou@) is a semi-senior exploit writer at Core Security Technologies. He's being working in computer security for 3 years and he specializes in Windows exploits, mostly, and the development of exploit writing tools. He has also developed exploits for Linux and Mac OS X.

 
posted by 김태훈-프란치스코
http://blog.paran.com/franc3sco/37107111

반응형

'작업공간 > 기본적인 삽질 & 기록' 카테고리의 다른 글

Static analysis of malicous PDFs (Part #2)  (0) 2010.05.30
The Tools  (0) 2010.05.30
강원도 춘천 닭갈비집 - 통나무집  (0) 2010.05.24
gcc 2.96이상 버전에서의 버퍼구조  (2) 2010.05.16
3.1.3 탈옥  (0) 2010.05.03
반응형
http://www.chdakgalbi.com/new
반응형

'작업공간 > 기본적인 삽질 & 기록' 카테고리의 다른 글

The Tools  (0) 2010.05.30
[퍼옴] 아이폰 디버기  (0) 2010.05.26
gcc 2.96이상 버전에서의 버퍼구조  (2) 2010.05.16
3.1.3 탈옥  (0) 2010.05.03
Backtrack4 Metasploit framework3 Update  (0) 2010.03.29
반응형


원문 주소 : http://geundi.tistory.com/120


아직 퍼와도 된다는 허락은 못맡았지만.. 댓글을 달아놨습니다..

안된다면.. 내려야죠 (+__)ㅋ

해당 메모리를 계산할 수 있을 거라고 생각을 못했었는데....

물론 오래된 버전 내용이라 지금은 그냥 공부용이지만.. 한번 정도 보시는 것도 좋을 듯 합니다.


시스템 해킹기법으로 널리 알려진 해킹기법중의 하나인 버퍼오버플로우를 이용하는데에 있어 함수의 리턴주소가 저장되어 있는 곳을 정확히 알아야 합니다.

함수의 리턴어드레스가 저장되어 있는 곳을 약간이나마 추측할 수 있는 방법을 써보고자 합니다.

다 들 아시는 부분이겠지만 gcc 2.96이상 버전으로 컴파일을 하게 되면, 버퍼오버플로우를 하는데 ret의 위치까지의 거리를 계산하는데 어려움이 있습니다. 메모리에 버퍼를 위한 공간이 할당되는데 각 버퍼 다음에 그 크기가 일정하지 않는 공간이 잡히기(이하 쓰레기) 때문입니다.

그런데 이 쓰레기의 크기가 정해지는 것에 있어서 다소 규칙성을 발견하 여 작성한 글(글 마지막에 참고문서 링크)이 있어 그 글을 기초로 하여  정리를 해보려 합니다.


1. 버퍼가 하나인 경우 

main()
{
 buffer1[ ];

}

이러한 소스를 가진 프로그램이 수행되면 스택은 다음과 같을 것입니다.


                 /-------------------------/  메모리의 높은 숫자의 주소
                 |         ret             |      
                 /-----------------/
                 |         sfb            |
                 /-----------------/
                 |                         |
                 |      쓰레기1        |
                 |                         |
                 /-----------------/
                 |                         |
                 |      쓰레기2        |
                 |                         |
                 /-----------------/
                 |                         |
                 |       buffer1        |
                 |                         |
                 /-------------------------/   메모리의  낮은 숫자의 주소


쓰레기1buffer1의 크기9바이트 이상인 경우에만 8바이트로써 일정하게 생깁니다. 9바이트 미만인 경우에는 생기지 않거나 생기는 그 크기가 뷸규칙 합니다.

쓰레기2 buffer1의 크기9바이트 이상인 경우 "buffer1의 시작주소 와 쓰레기1의 시작 주소간의 거리는 16배수로 단위로 되는 규칙성"이 있습니다.

9 <=  buffer1  <=16  :  buffer1시작주소와 쓰레기1의 시작주소의 차이는 16
16 <  buffer1  <=32   :   32
32 <  buffer1  <=48   :   48
48 <  buffer1  <=64   :   64
~
~


이러한 나름의 규칙성을 가지고 buffer1이 9바이트 이상의 크기로 선언이 되었다면 다음과 같이 ret까지의 거리를 계산할 수 있습니다.

(buffer1 시작주소와 에서 쓰레기1 시작주소의 거리) + (쓰레기1 8바이트) + (sfb 4바이트)
= buffer1의 시작주소에서 ret시작 주소까지의 거리

따라서 버퍼오버플로우를 할 때 쉘코드주소가 들어가야 할 자리를 정확히 잡아주는데 큰 도움이 될 것입니다.


2. 버퍼가 2개인 경우

버퍼가 2개인 경우에는 버퍼 2개의 크기를 모두 고려해야합니다.

main()
{
 buffer1[ ];
   buffer2[ ];
}

이러한 소스를 가진 프로그램이 수행되면 스택은 다음과 같을 것입니다.


                 /-------------------------/  메모리의 높은 숫자의 주소
                 |         ret             |      
                 /-----------------/
                 |         sfb            |
                 /-----------------/
                 |                         |
                 |      쓰레기1        | 
                 |                         |
                 /-----------------/
                 |                         |
                 |      쓰레기2        |
                 |                         |
                 /-----------------/
                 |                         |
                 |       buffer1        |
                 |                         |
                 /-----------------/
                 |                         |
                 |      쓰레기3        | 
                 |                         |
                 /-----------------/
                 |                         |
                 |       buffer2        |
                 |                         |
                 /-------------------------/   메모리의  낮은 숫자의 주소



우리는 이제 쓰레기3의 크기를 구하여야 하는데,
쓰레기3의 크기를 구하는데 있어서는 buffer2의 시작주소와 buffer1의 시작주소의 거리를 계산하는 방식으로 이루어 집니다.

buffer2와 buffer1의 거리에 대한 규칙성은 다음 그림을 참고하시면 될것 같습니다.
(그 림에서는 제가 여태 설명해오던 buffer1과 buffer2가 바뀌어져 있으니 참고하시기 바랍니다)

사용자 삽입 이미지
<그림출처 : http://hackerleon.cybersoldier.net/images/gcc296.jpg>

그림에 약간의 보충 설명을 덧붙이도록 하겠습니다.

버퍼가 2개인 경우에는 각각의 버퍼의 크기가 9이상이면 buffer2에서 buffer1까지의 거리에 일정한 규칙성을 가지게 됩니다.(그림을 보시면 아시겠지만 반드시 2개의 버퍼 각각의 크기가 모두 9이상이어야 합니다, 둘중에 하나라도 9바이트 미만이면 규칙성은 없습니다.)

(buffer1 의 크기가 9이상이고, buffer2의 크기도 9이상인 경우)
9 <=  buffer1 <= 16  : buffer1와 buffer2의 거리는 16
16 < buffer1  <= 32    :  32
32 < buffer1  <= 48   :   48
48 < buffer1  <= 64   :   64
~
~

이제 우리는 buffer2에서 buffer1까지의 거리를 알 수 있습니다. 그리고 buffer1 에서 ret까지의 거리는 앞서서 설명했던 버퍼가 하나인 경우와 같으므로, buffer2에서 ret까지의 거리를 구할 수 있게 되었습니다.

따라서 buffer2에서 ret까지의 거리는 다음과 같을 것입니다.

(buffer2에서 buffer1까지의 거리) + (buffer1에서 쓰레기1까지의 거리) + (쓰레기1 8바이트) + (sfb 4바이트)


3. 변수에 메모리를 할당하는 단위가 바뀐 것인가?

저는 여태 리눅스는 변수에 메모리를 할당할 때에 1워드 즉, 4바이트를 단위로 한다고 알고 있었습니다.

그런데 어떤 글을 보니 이러한 해석이 있더군요.

 gcc 2.96이상 버전에서는 8바이트 이하의 변수에는 1워드 단위로 할당을 하지만, 8바 이트를 초과하는 즉, 9바이트 이상의 변수에는 4워드(16바이트)단위로 할당을 한다는 것입니다.

만약 이러한 해석에 기초를 둔다면 각 버퍼가 9바이트 이상인 경우에 발견되었던 16바이트 단위의 그 규칙성에 대한 설명이 가능해집니다. 그런데 앞에서 제가 쓰레기라고 우겼던 것들은 쓰레기가 아닌게 되겠습니다. 당연히 변수에 할당된 메모리의 공간이라고 생각되기 때문입니다.

그러나 버퍼의 크기가 8바이트 이하인 경우에는 이 해석이 맞지 않는것 같습니다. 위의 그림에서 8바이트 이하인 경우에 두 버퍼간의 거리를 보시면 알 수 있는 부분입니다.

이러한 규칙성을 어떻게 받아들여야할지는 좀더 공부를 해보거나 자기가 편한대로 해야겠습니다.

또한 이러한 규칙성은 gcc버전에 따라 다를수도 있으니 이점 염두해주시기 바랍니다.

수고하셨습니다.

반응형
반응형



Geohot 의 트위터만 보고 있었는데..
제가 영어를 잘.. 못하는 편이라
영어로 뭐라뭐라 하길래 그런가보다.. 하고 넘어갔었죠.. 그 중 spirit 이란 단어가 있어서..
무슨 정신 어쩌구 저쩌구 그렇게 해석하고 넘어가버렸죠..

하지만 오늘 확인해보니.. spirit이 3.1.3 탈옥 툴 이름이더군요..

2.5세대 아이팟터치.. 3GS 아이폰..에서 실험해봤으며..
안정적으로 탈옥이 되었습니다..
사진만 삭제되고 주소록이랑 어플리케이션들은 남아있네요..

3.1.3 탈옥을 하실 분들은.. 하셔도 무방할 듯 합니다..
3.1.3 탈옥에 관한 내용을 좀 더 살펴봐야겠네요..



탈옥은 기존에 쓰던 Blackra1n과 동일하며
틀린점은.. 완전탈옥.. 즉.. 완탈이란 것입니다.. 재부팅이 무섭지 않죠..

탈옥 후 안정화 작업을 해주시면 될 듯 합니다..



반응형
반응형
일단 이야기 할게 있습니다..
시작하기 전에 중요하니 꼭 봐주세요..
MacOSX Torrent 파일은 Intel CPU만 됩니다.
AMD이신 분들은 AMD용을 따로 구하셔야 됩니다. 이점 유의하시기 바랍니다.

일단 VMware를 설치하신 이후..
첨부파일을 받아서 Torrent로 다운 받으세요..
첨부파일 iDeneb Mac OSX 10.5.8 입니다..


다운을 다 받으셨으면 압축을 푸세요..
VMware 이미지 파일이 풀릴 것 입니다.. 이젠 VMware를 실행 하셔서.. 해당 경로에 있는 이미지를 불러오세요..


Torrent를 다 받으시고 꼼꼼하신 분들은 TXT 파일도 읽어보셨겠지만..
텍스트 문서를 안읽어보신 분들은 그냥 실행하면 OS를 찾을 수 없다고 나오고 부팅이 안되죠..
꼭 readme.txt를 읽어주세요.

읽어보면.. CD-ROM에 bootloader.img 파일을 마운트하라고 나오네요..
이 파일은 VMware 이미지 있는 디렉토리에 같이 있으니 걱정 말고 찾아서 지정해주세요.


빨간색 네모를 유의 깊게 보시면서 따라하세요.

그다음에는 Ctrl + B(시작)을 누르면 부팅이 되면서 뭐라뭐라 합니다.. 엔터치고 설치해주세요.
그 다음은 그냥 시키는 데로 대충 해서 설치해줍니다..
MacOSX로 부팅이 되는데요..

이제 본격적으로 4.0으로 업그레이드를 위한 준비과정입니다..

1. 인터넷이 되는지 확인해주세요..
2. iTunes 버전을 업그레이드 해주세요.  9.1
3. 좌척 하단에 Finder를 클릭하고 우측 상단 검색창에 Terminal을 검색하셔서 Terminal이 나오면 실행해주세요.
4. 아래와 같이 입력해주시고 엔터 눌러주세요
    vi /etc/hosts
5. 갑자기 화면이 바뀌면서 뭔가가 나올꺼예요.. 그러면 키보드 방향키로 맨 끝에 있는 글자로 포인터(카렛)를 움겨주세요.
6. a -> 엔터 -> 127.0.0.1 -> 탭 -> albert.apple.com -> ESC -> : -> wq -> 엔터
   순서대로 입력해주세요.

여기까지 하셨으면 이젠 거의 끝입니다.

http://www.megaupload.com/?d=HFL8W5RF

위의 링크에서 4.0 Beta ipsw파일을 받으시고..

iTunes를 실행하고 아이폰을 연결한 다음
ART + 업그레이드 버튼을 눌러서 위에서 받은 4.0 파일을 선택해주세요

이제 냅두면 알아서 4.0으로 되야되지만..
우리의 VMware 님께서는 오류를 뿜어내시며.. 아이폰은 복구모드로 자꾸 가게 됩니다..
왜 그럴까요?

이유는 4.0으로 업그레이드 도중.. 재부팅이 되는데 이때 재부팅이 되면서 아이폰을
VMware가 인식을 하지 못하기 때문입니다..

그럼 아이폰을 VMware가 인식할 수 있게 해줘야겠죠??
하는 방법은..


VMware 우측 하단에 보면 CD-Rom, 플로피.. 하드디스크.. 등등 하드웨어 기기에 대한 상태가 표시되고 있습니다.
자세히보시면 약간 흐릿한게 있는데요.. 이것들은 VMware안에서 인식을 하지 못하고 있는 것들 입니다..

4.0으로 업그레이드 하는 도중.. 이놈들이 약간 흐릿하게 변한 이후에 선명하게 돌아오지 않는다면.. 인식하지 못한 것이죠..


위 그림처럼 흐릿한 아이콘에 마우스 오른쪽을 클릭하면 연결할 수 있는 메뉴가 뜹니다.
Connect를 눌러주면 VMware안에서 인식이 되며.. 무사히~ 4.0이 설치가 될 것입니다.
ㅇ_ㅇ;;

아직 미지의 세계.. 4.0..
같이 놀러 가시죠~ '-'/

반응형
반응형
많이들 낚여서 오시겠네요..
윈도우에서 업그레이드 되는 건줄 알고 많이들 오시겠어요..

하!지!만..

윈도우에서 itunes를 이용해서 4.0으로 업그레이드를 시도할 시.. 벽돌이 되는걸..
해결 하는 방법을 알려드리고자 글을 쓰는 거니까 그렇게 낚였다고도 볼 수 없을꺼예요 ^^;

해결 하는 방법은 간단합니다. ㅇ_ㅇ;;

아이폰을 컴퓨터에 연결한 상태로 검은비를 실행해 줍니다..
물론 3.1.3인 상태여도 상관 없습니다. 탈옥은 되지 않지만 패닉 상태에서 빠져나오게 도와줄 것 입니다. ㅇ_ㅇ;;

복구모드에서 빠져나와 애플 마크가 좀 오래 표시되는데요...
이때 냅두면 그냥 정상 부팅되기도 하고..
너무 오래 간다 싶으시면 재부팅 해주시면 됩니다. ㅇ_ㅇ;;

유익한 Tip이 되셨길..


반응형
반응형

Google Inc.'s search sites in China abruptly stopped working Tuesday, but the explanation for the outage shifted as the day wore on. The Internet giant first blamed itself, citing a technical change, but later reversed course and pointed to the heavy hand of China's "Great Firewall"—even as service appeared to be back to normal.


The evolving explanation whipsawed Google watchers and showed how fraught with confusion the relationship between China and Google remains. The episode risks escalating their battle a week after Google stopped censoring its search engine in China.

Google struggled to discern the cause of the massive disruption, in which users in China received error messages for Google searches on the company's Hong Kong-based search site, Google.com.hk, and—at least for many users—on Google.com. Google began routing Chinese Internet users to its Hong Kong site last week as it said it would no longer comply with China's censoring policies and wouldn't run a censored Chinese search engine.

Later in the day, Google reversed itself, saying it had made those changes a week earlier. "So whatever happened [Tuesday] to block Google.com.hk must have been as a result of a change in the Great Firewall," the company said.

Separately, the Foreign Correspondents Club of China said Wednesday that it had confirmed eight cases in which journalists based in China and Taiwan had their email accounts hacked in recent weeks. Several of the accounts, on Yahoo Inc., were disabled March 25 as a result of the attacks. In one case, the club said, a Beijing-based journalist's account had been modified to forward all of the journalist's emails to an unknown recipient.

Google said late Tuesday afternoon that its search traffic in China had returned to normal. "For the time being this issue seems to be resolved," it said.

The incident added to the sense of confusion over Google's relations with China. Google said Monday that its mobile services in China were being partially blocked, but it wasn't clear how extensive that blockage was, nor that the Chinese government was definitely behind it.


The disruption Tuesday was broader, if not entirely complete. Users of the Hong Kong site in at least a half-dozen Chinese cities said they could reach the search page, but that any term entered in the search window yielded a browser error message, often causing their access to Google to be severed temporarily. Users in some cities also said they couldn't access Google.cn, which since last week has automatically sent users to the Hong Kong site.

Many Chinese users reported that even searches of innocuous terms like "happy" or "tree"—on Google's Hong Kong site produced an error message saying the page couldn't be opened.

The disruption was similar to how analysts expected a crackdown by China's Internet censors would look. It also shed light on the role of the censorship regime in filtering results for China-based Web users. The system is opaque and unpredictable.

Wang Lijian, spokesman for the Ministry of Industry and Information Technology, one of China's main Internet regulators, said he was unaware of any Google disruption.

Any permanent blockage of Google's searches by China would deal a blow to Google's hopes of continuing to run part of its business there after dismantling its censored Chinese site. Google said last week it hoped to keep its music-search and map services in China, along with sales and research-and-development operations.

Beijing has expressed anger at Google for publicly flouting its censorship regime, and a decision to block access to Google entirely has always been considered possible. Many analysts have believed Beijing would stop short of that for fear of infuriating Google's tens of millions of regular Chinese users and foreign businesses that require access to information.

Because Google censored its old Chinese site, Google.cn, in accordance with government rules, that site wasn't filtered by the government's firewall. Its international sites, such as the Hong Kong one, have always been subjected to filtering, meaning that Chinese users' searches of some sensitive terms—like those related to the 1989 crackdown on pro-democracy protests, the initials RFA, for Radio Free Asia, or even the names of top leaders—might trigger an error message from the browser instead of a results page.


http://online.wsj.com/article/SB10001424052702304739104575153360362231700.html?mod=WSJ_Tech_LEADTop

반응형
반응형
아이폰에서 MSF3를 쓰려고 하는 도중..
보는데.. 얘는 도통 업데이트를 하려면 무슨 을 해야되는지 모르겠더군요..
그래서 마구마구.. 웹서핑을 해대다가!!
결국 알아냈습니다...

svn update

....
네.. 저렇게 짧습니다.. 아이폰은 subversion이 설치가 되어있지 않으니 잘.. 설치해주시기 바랍니다. ^^




반응형

'작업공간 > 기본적인 삽질 & 기록' 카테고리의 다른 글

gcc 2.96이상 버전에서의 버퍼구조  (2) 2010.05.16
3.1.3 탈옥  (0) 2010.05.03
UnPacking Malicious Executables  (2) 2010.03.09
Disassemble the MBR  (0) 2010.03.08
Shellcode to Execute a Ping!  (0) 2010.03.08
반응형
http://iphonejtag.blogspot.com/

geohot의 블로그...

3.1.3으로 업데이트 하는 바보같은 놈들에게 탈옥툴을 제공하지 않겠다!!고..
호언장담을 하고 난 후.. 진짜로 공개를 안했던 geohot..
하지만 이번엔 공개해줄 듯 한 분위기 입니다..
일단 아이패드가 발매된 직후.. 지금 가지고 있는 Exploit가지고도
탈옥이 된다면.. 바로 공개를 해주지 않을까 싶네요..
geohot 본인도 아이패드에서 동작할꺼라고 말하는 것으로 보아
상당한 자신감을 가지고 있는 듯 합니다..
언넝.. 4월달이 오길 바라는 수 밖에 없겠네요 ㅇ_ㅇ;

반응형
반응형
반응형

'작업공간 > Security' 카테고리의 다른 글

Google Runs Into China's 'Great Firewall'  (0) 2010.04.01
iPhone Unpack  (0) 2010.03.29
[iPhone] libgcc  (4) 2010.03.25
Android apk file decompiler  (0) 2010.03.24
iPhone perl Framework  (0) 2010.03.23

+ Recent posts