2013.02.13 10:43
 
 

안드로이드 디컴파일러가.. 유료로 나왔다.



2013:02:13 10:43:05



http://www.android-decompiler.com/brochure/jeb-brochure-ko.pdf


사실.. 얼마나 좋은지는 잘 모르겠다. 

이미 무료로 배포중인 툴들만으로도 충분하다고 생각을 하기 때문이다.

(충분하다기보단.. 유료로 사서 쓰는거랑 비교했을때의 효율성을 비교했을때.. )


IDA 와 같은 편의기능이 몇개 들어가있고..


pdf 파일에서 나오듯.. 

조금 더 정교화된 디컴파일 기능 제공..


이게 핵심인데...

사달라고하면서까지.. 쓰고 싶은 마음은 그닥... ^^;;



개인적으로 사고 싶은 툴은..

http://www.zynamics.com


자이나믹스사에서 만든 툴들..

아.. 이전 진짜 홀릭인데 ㅠㅠ 써보고 싶은데 ㅠㅠ


3년전 세미나에서 본 이후로.. 써본적이 없다는게 함정..


저작자 표시 비영리 변경 금지
신고
Posted by Sun2Day

댓글을 달아 주세요

2011.02.28 17:23
 
 
xwodi v1.0
그러나.. TEST해보지 못함..
심바인.. 망할..  =_=;;

저작자 표시 비영리 변경 금지
신고
Posted by Sun2Day

댓글을 달아 주세요

2011.02.14 11:51
 
 
펌 : http://thomascannon.net/projects/android-reversing/

Last Update: 8th November 2010
Status: Complete (but may expand)

Introduction

This project all started when I was asked to take a look at a software product that was under evaluation. The software ran on mobile devices such as iPhone and Android and allowed end users to securely connect to their organisation from their personal phones. It provided a sandbox environment where company data could be viewed, and it encrypted all of it’s data. It is used by large blue chip companies and the literature claims it was evaluated and cleared by the US Department of Defence as suitable for use. I decided to verify the security myself and spent about 14 hours of my own time at home in which I was able to break the encryption and recover all data.

I cannot name the actual product but I have documented some of my technical notes below. They provide general tips, tricks and techniques that can be used by others to evaluate security of their mobile products. My hope is to also provide information for developers so that they understand where potential weaknesses are, and mitigate accordingly.

Scenario

For reference the main scenario I was working to evaluate was a common one: a user loses their mobile device or it is stolen. Because these devices are not under control of a central IT policy we have to assume that they won’t necessarily have a device level password in place. Therefore I haven’t (yet) looked at bypassing the device lockout screen. In addition, after its first launch the app I’m evaluating runs in the background in a locked state, with the user entering their password to unlock. So the scenario is that I find the device, it is running the security software but it is locked, what data can I retrieve?

Hardware & Software

The hardware I’m using is an HTC Desire running Android 2.2 (Froyo). It was the evaluation platform I had to work with and currently own, I have nothing against Android, in fact I really like it. I think the concepts will be similar for iPhone and most other capable smart phones (except perhaps BlackBerry in some cases). I also used a laptop running Linux.

Accessing The Device

A number of methods can be used to explore the device. For ease of analysis and documentation the device was accessed over USB from a Linux system using debug mode.

First the device needs to have debug mode enabled. Go to:

Settings > Applications > Development > USB Debugging

Then connect the device to the Linux host computer using the USB cable.

The software to use debug mode comes with the Android Software Development Kit which is a free download from Google. The SDK for Linux was simply downloaded and uncompressed.

First we list the devices detected by the Android Debug Bridge (ADB):

user@laptop:# ./adb devices 
List of devices attached
HT07NPL03993 device

Then we connect to a shell on the device:

user@laptop:# ./adb shell 
$

Find out what user level we’re running under:

$ id 
uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)

We are running as user “shell” which is quite restricted and won’t be able to see much on the system. The next task is to use an exploit to gain root privileges. There are a number of exploits that currently work and a common one was chosen. Note that this is a temporary escalation and is not quite the same as “rooting your device”.

First upload the exploit to an area of the device that allows us write access:

user@laptop:# ./adb push rageagainstthecage-arm5.bin /data/local/tmp/rageagainstthecage-arm5.bin 
117 KB/s (5392 bytes in 0.044s)

Then log back into the shell, change to the exploit directory, make it executable and run it:

user@laptop:# ./adb shell 
$ cd /data/local/tmp
$ chmod 0755 rageagainstthecage-arm5.bin
$ ./rageagainstthecage-arm5.bin
[*] CVE-2010-EASY Android local root exploit (C) 2010 by 743C

[*] checking NPROC limit ...
[+] RLIMIT_NPROC={3319, 3319}
[*] Searching for adb ...
[+] Found adb as PID 7325
[*] Spawning children. Dont type anything and wait for reset!
...
[*] adb connection will be reset. restart adb server on desktop and re-login.

Re-login to device:

user@laptop:# ./adb kill-server 
user@laptop:# ./adb shell
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
#

Find out what user level we’re running under:

#id 
uid=0(root) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)

And we are now root, which makes things a little easier.

Memory Dump

In Android the memory is exposed via procfs in /proc/pid/mem and having root privileges means we can directly read and write the application’s memory and even control flow of execution. The way to do this would be to attach to the app process using ptrace and use /proc/pid/map to get the memory addresses to access.

There is also another way to dump the memory of a process and it is already built into Android. First we change the permissions on a directory so the dump file can be written on the device:

# chmod 777 /data/misc 

Then we find the Process ID of our app (from a fictional company I’ve named Acme):

# ps 
USER PID PPID VSIZE RSS WCHAN PC NAME
root 1 0 344 252 c00ce65c 0000d2dc S /init
root 2 0 0 0 c0076e3c 00000000 S kthreadd
root 3 2 0 0 c0067fa8 00000000 S ksoftirqd/0
...
app_74 465 66 133776 42428 ffffffff afd0ebd8 S com.acme.android.afe
...
root 10679 1 3412 200 ffffffff 0000f474 S /sbin/adbd
root 10685 10679 744 328 c0065ce4 afd0e88c S /system/bin/sh
root 10689 10685 892 336 00000000 afd0d97c R ps

Then send a SIGUSR1 signal to the process which will cause it to dump its memory:

# kill -10 465 

In the /data/misc directory we now have the dump file:

heap-dump-tm1289007218-pid465.hprof 

Now download it onto the laptop for analysis:

user@laptop:# ./adb pull /data/misc/heap-dump-tm1289007218-pid465.hprof . 
1109 KB/s (3656449 bytes in 3.217s)

This dump file can now be opened in a memory analysis tool such as MAT but I just opened it in a HEX editor to see what it contained. I found that the memory dump contained sensitive data from inside the locked app such as email addresses, file names, server names and more.

A total of seven memory dumps were taken while analysing the app and in all cases potentially sensitive data listed above was present. In two cases the memory dumps also contained the clear text password used to unlock the app. In one dump the password was present once and in the other it was present twice. Although not consistent, when the password is present it could allow for complete compromise of the data stored in app and access into the organisation.

Reverse Engineering the Code

Android applications are mostly Java based which makes it slightly easier than normal to reverse the application code and can speed up analysis greatly. I found some useful links about Android decompiling in a blog post by Jack Mannino, so this part was pretty easy.

The following (free) tools were used:

First we get a copy of the app that is running on the device and copy to the laptop using the Android Debug Bridge from the SDK:

user@laptop:# ./adb pull /data/app/com.acme.android.afe-1.apk ./ 
1325 KB/s (5601716 bytes in 4.125s)

The apk file just downloaded is actually a zip file. After unzipping it we convert the manifest file into a readable format:

user@laptop:# java -jar ./AXMLPrinter2.jar AndroidManifest.xml >AndroidManifest.txt 

The manifest contains interesting information like permissions, intent filters, providers and lots more. There is one provider for the app I’m looking at called FileProvider which I’ll come to later:

<provider 
android:name="com.acme.android.FileProvider"
android:authorities="com.acme.android.afe.FileProvider"
>
</provider>

Back in the unzipped application package there is a classes.dex file which contains all of the main code. First this needs to be converted into a jar:

user@laptop:# ./dex2jar.sh classes.dex

This creates classes.dex.dex2jar.jar which again can be unzipped to reveal the compiled class files. These can now be opened up in JD, the Java Decompiler, to reveal a fairly close representation of the original source code. This analysis does not cover a detailed review of the code but on first glance I could see some interesting things such as static salt values (for encryption) and the method for decrypting files stored in the “sandbox” which can be invoked from an external program.

Copying the Application and Data

The app and data were extracted from the running device and migrated to a virtual Android environment. No specific attack was kept in mind for this experiment but one might conclude that it aids analysis by having the app running in a virtual environment completely under the control of the hacker. Although untested it may be possible to run and maintain the app from a PC instead of a handheld, opening it up to new risks. With some further work it may also enable an attacker to retain access to the system even when not in possession of the device. Finally, the state can be continually reverted meaning the app’s ability to lock/wipe itself after a number of failed password attempts is rendered useless.

First I pushed the busybox application to the device which will make copying easier. Then I set the path to busybox:

user@laptop:# ./adb shell 
# export PATH=/data/local/tmp:$PATH

Change to the data directory and then copy the application data to the SD Card

# cd /data/data
# busybox cp -R com.acme.android.afe /sdcard

Copy the data from the SD Card to the laptop and then push it to the Android emulator (part of the free Android SDK) which is running on the laptop:

user@laptop:# ./adb push com.acme.android.afe /data/data/com.acme.android.afe

Install the application package on the emulator:

user@laptop:# ./adb install com.acme.android.afe-1.apk

Launching the emulator I found the application ran fine.

Manually Invoking User Interface Elements

Android applications contain “activities”. An activity in Android parlance is a single focussed thing that a user can do and almost all activities interact with the user. Generally speaking, an Activity usually has its own window so that the user can interact with it.

The app I’m testing exposes a number of activities which can be enumerated from a number of places. Firstly the manifest XML decoded earlier, then the code that was decompiled and yet another great way is to query the Android system itself. Android maintains package information like Activity/Intent/Service/Provider in the PackageManagerService. You can query the service information from an ADB shell like so:

# dumpsys package > packages.txt

The packages.txt file was copied onto the laptop and searched for com.acme.android. The results showed activities such as:

com.acme.android.SecurityPreferenceActivity: 
com.acme.android.afe/com.acme.android.ui.activities.settings.SecurityPreferenceActivity

It is possible to manually launch such an activity from the ADB shell with the following command:

# am start -n com.acme.android.afe/com.acme.android.ui.activities.settings.SecurityPreferenceActivity 
Starting: Intent { cmp=com.acme.android.afe/com.acme.android.ui.activities.settings.SecurityPreferenceActivity }

The app will then try to switch to the Security Preferences screen. The hope was that even though the app was locked it would allow us to navigate directly to other screens. It seems the app was well implemented in this regard and would only show the unlock screen and the password reset screen. All listed activities were tried with the same result. The app included code in each activity to check if it was in an “unlocked” state and if it wasn’t, it would jump back to the lock screen. This technique could be used to find hidden screens and jump around an application in a way the developer hasn’t anticipated so it is good design that they checked for this. That said, it is of course possible to modify the application in memory to get the unlocked test to always return true, but I did not need to go that far in the end…

Content Providers

There is no common storage area that all Android packages can access but it does allow data sharing using content providers. This is how the app I’m testing shares data with, for example, a PDF reader in order to allow the user to view a PDF stored in the encrypted “sandbox”.

In the reverse engineering section we saw that the manifest file contained one content provider called FileProvider. In the decompiled code I could see this is used to decrypt files on the fly and serve them to external applications when the user wants to view them. The next experiment will look to utilise this function by manually invoking it to decrypt stored files.

The following test was conducted on the Android device with the security app in a locked state:

Change directory to where the app stores encrypted files:

# cd /data/data/com.acme.android.afe/files

First we inspect the contents of one of the files to see if it is really encrypted:

# cat somefile
(binary data displayed)

The file appears to be encrypted. We run the command below with the intention of launching the Android HTMLViewer and requesting the file through the app’s content provider, which should decrypt it on the fly.

# am start -a android.intent.action.VIEW -d content://com.acme.android.afe.FileProvider/files/somefile -t text -n com.android.htmlviewer/.HTMLViewerActivity 

Starting: Intent { act=android.intent.action.VIEW dat=content://com.acme.android.afe.FileProvider/files/somefile typ=text cmp=com.android.htmlviewer/.HTMLViewerActivity }

On the Android device the HTMLViewer pops up and we see that the attachment has been decrypted while the app is locked without entering the password, and then rendered successfully. It was found that the same process could be used to decrypt any file stored by the app.

Stealing the Key

When first started the app does not have access to the data. Entering the password or performing the Reset Password activity decrypts the keys required to access the databases and files. The software stores lots of juicy information in encrypted SQLite databases such as contacts, configuration settings, keys and potentially sensitive data from the organisation.

SQLite is the standard way for Android applications to store data and is built-in, just like the iPhone. The standard SQLite on Android does not yet offer encryption but there are a few implementations out there including one from the makers of SQLite themselves, for a fee.

The app uses Java Native Interface to hook into a natively compiled SQLite library sitting in:

/data/data/com.acme.android.afe/lib/libdb.so

When the user enters the correct password the app initialises the database session using this modified version of SQLite 3.

Analysis of the library shows that as well as SQLite it includes functions for implementing AES encryption in CBC mode for transparently encrypting/decrypting the database files. It was similar to the open source encrypted SQLite offerings I found but not exactly the same. One similar thing I found is that when calling the library to execute SQL statements the application needs to set a PRAGMA value as:

PRAGMA hexkey='<databasekey>'

This database key is derived from decrypting (using the user’s password or reset password) the key held in the file:

/data/data/com.acme.android.afe/shared_prefs/prefs.xml

The device under evaluation had the app running and in a locked state. As shown in the Memory Dump section it was trivial to dump the memory of the running process. In every single case the memory dump contained the database key in clear text! The key didn’t change between memory dumps even after changing the password and rebooting the device. This really is the weak link. With all the fancy encryption functionality it all came down to exposing the database encryption key when calling the SQLite library and leaving it in memory.

The database key was a hex encoded string of a 24 byte key (i.e. 48 bytes), meaning that it was likely a 192bit AES key.

The app database files are held on the device in:

/data/data/com.acme.android.afe/databases/

The databases were copied to the Linux laptop and OpenSSL was then run to decrypt the databases with the key from the memory dump. An “IV” should also be supplied here but it appears one was not used so I set it to zero:

user@laptop:# openssl aes-192-cbc -in someDB.db -out someDB.db.dec -K 0123456789ABCFEF0123456789ABCFEF0123456789ABCFEF -iv 0 -d 
bad decrypt
26402:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:330:

There were some errors in the decryption, however when viewing the resulting file the contents of previously encrypted content (even content I thought I had deleted), keys, configuration and more were there in clear text.

At this point I stopped my evaluation as it was game over. Hope these tips and tricks help you out.


저작자 표시 비영리 변경 금지
신고
Posted by Sun2Day

댓글을 달아 주세요

2010.05.03 15:25
 
 



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

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

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

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



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

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



저작자 표시 비영리 변경 금지
신고

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

xwodi  (0) 2011.02.28
Android Reverse Engineering  (0) 2011.02.14
3.1.3 탈옥  (0) 2010.05.03
VMware를 이용하여 아이폰 OS 4.0 Beta 설치하기  (5) 2010.04.11
iPhone OS 4.0 윈도우 업그레이드로 인한 문제 해결 방법  (0) 2010.04.11
iPhone Unpack  (0) 2010.03.29
Posted by Sun2Day

댓글을 달아 주세요

2010.04.11 16:50
 
 
일단 이야기 할게 있습니다..
시작하기 전에 중요하니 꼭 봐주세요..
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..
같이 놀러 가시죠~ '-'/

저작자 표시 비영리 변경 금지
신고
Posted by Sun2Day

댓글을 달아 주세요

  1. 엔신 2010.04.13 10:54 신고  댓글주소  수정/삭제  댓글쓰기

    설치 방법을 올려주셨으니
    이번에는 설치 후 새로운 점(저에게 말해줬던 것)들을
    정리해서 올려주시면 됩니다.
    전 순정을 쓰고 있지만,
    어떻게 바뀌는지 알고 싶거든요.(개발버전따위 깔고싶지 않아서가 아님...)

  2. ㅠㅠ 2012.07.11 01:38 신고  댓글주소  수정/삭제  댓글쓰기

    저기요.. 토랜토로 받으려니 1일이 넘게걸린데서.... 다른방법으로 파일 올려주심 안될까요?ㅠ

  3. ㅜㅜㅜ 2012.10.24 20:28 신고  댓글주소  수정/삭제  댓글쓰기

    fbl이주소못가게한다흑메일주소알려들릴테니 본내주세요ㅠㅠㅠ

2010.04.11 00:27
 
 
많이들 낚여서 오시겠네요..
윈도우에서 업그레이드 되는 건줄 알고 많이들 오시겠어요..

하!지!만..

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

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

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

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

유익한 Tip이 되셨길..


저작자 표시 비영리 변경 금지
신고

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

3.1.3 탈옥  (0) 2010.05.03
VMware를 이용하여 아이폰 OS 4.0 Beta 설치하기  (5) 2010.04.11
iPhone OS 4.0 윈도우 업그레이드로 인한 문제 해결 방법  (0) 2010.04.11
iPhone Unpack  (0) 2010.03.29
How to Get Started with iPhone Dev  (0) 2010.03.28
[iPhone] libgcc  (4) 2010.03.25
Posted by Sun2Day

댓글을 달아 주세요

2010.03.29 15:30
 
 
http://iphonejtag.blogspot.com/

geohot의 블로그...

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

저작자 표시 비영리 변경 금지
신고
Posted by Sun2Day

댓글을 달아 주세요

2010.03.28 22:25
 
 
http://www.webdesignerdepot.com/2009/05/how-to-get-started-with-iphone-dev/

저작자 표시 비영리 변경 금지
신고

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

iPhone OS 4.0 윈도우 업그레이드로 인한 문제 해결 방법  (0) 2010.04.11
iPhone Unpack  (0) 2010.03.29
How to Get Started with iPhone Dev  (0) 2010.03.28
[iPhone] libgcc  (4) 2010.03.25
Android apk file decompiler  (0) 2010.03.24
iPhone perl Framework  (0) 2010.03.23
Posted by Sun2Day

댓글을 달아 주세요

2010.03.25 16:27
 
 
c complier 및 c++ 라이브러리를 설치하려면..

의존성 때문에 이 libgcc이 먼저 설치되어있어야되는데

cydia에는 없다.. 이는 어떻게 구하느냐!! 고민을 하던 차에.. 구글신께 기도를 드려

얻었도다!!! 우워!!!!!!!!!

dpkg -i 패키지명

Call~


저작자 표시 비영리 변경 금지
신고

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

iPhone Unpack  (0) 2010.03.29
How to Get Started with iPhone Dev  (0) 2010.03.28
[iPhone] libgcc  (4) 2010.03.25
Android apk file decompiler  (0) 2010.03.24
iPhone perl Framework  (0) 2010.03.23
Sad iPhone  (2) 2010.02.28
Posted by Sun2Day

댓글을 달아 주세요

  1. 가베스 2010.05.14 11:56 신고  댓글주소  수정/삭제  댓글쓰기

    우와 님 완전 짱이에요 졸 멋짐 속이 다 후련해졌어요 님 짱!!!

  2. 엔신 2011.01.04 16:14 신고  댓글주소  수정/삭제  댓글쓰기

    검색하니 나오네
    왠일로 도움이... thx

2010.03.24 18:01
 
 
아이폰뿐만 아니라 전체적인 스마트폰에 대한 언급을 이 카테고리에서 해야 될 듯 싶습니다..

오늘은 A3 팀블로그에 Android 실행파일 분석 (Decompile)라는 글이 올라왔더군요.
(정말.. 감탄하고 있습니다.. 회사내에서 이러한 연구를 하시는 분이 몇분이나 되시는지는 모르겠지만.. 이정도로 다양한 연구를 진행할 수 있다니.. 부럽고 부끄럽네요.. ㅠㅠ)

안드로이드에 대해서는 세미나에서 들은 것 뿐.. 실제로 제가 안드로이드 환경에서 작업을 해본적이 없어서 뭐라 할 말이 없습니다..

제가 안드로이드폰을 사지 않는 이상.. 하지 않을 것 같고요.. 물론.. 엄청난 사건이 발생한다면.. 에뮬레이터를 설치하고 있겠죠 =_=;;

블로그상에 보면 보안상 디테일한 정보는 생략한다고 나와있지만..
구글링을 좀만 하면 그와 관련된 다양한 정보를 얻을 수 있습니다.. 그래서.. 정보를 바로 Search 하기 시작했죠.. +_ +;;
(표정들이 왜 그래요?? 마치 검색 안해본 사람 처럼..
 보안상 안알려준다고 모르고 있으면 정보보안쪽 공부하는 사람 아니자나요~
 그건 그냥 일반인이지)
그리고 찾아냈습니다.

내용은 아래와 같습니다. 일본어 입니다..
저도 일본어는 못하기 때문에 일본어를 제외한 부분만 일단 봤는데.. 맞는 내용인 듯 합니다..
그래서 자료 보관차.. 이렇게 글을 남깁니다.

http://android.jpn.org/2009/11/decompile-classesdex-in-apk.html



============================================================================================================
============================================================================================================
============================================================================================================
 Androidアプリケーション(apk)の中には Dalvik VMの実行形式である
classes.dexファイルが含まれています。今回、このdexファイルのヘッダ情報を取 得したり、
コードセクションを逆コンパイルできるdexdumpを使って、dexファイルを逆アセンブルしてみます。

1.apkファイル の展開
  $ mkdir HelloAndroid
  $ cd HelloAndroid
  $ unzip ../HelloAndroid.apk

2.dexdumpの実行
  $ ~/android-sdk-linux_x86-1.5_r3/platforms/android-1.5/tools/dexdump \
   -d ./classes.dex
Processing './classes.dex'...
Opened './classes.dex', DEX version '035'
Class #0            -
  Class descriptor  : 'Lcom/example/helloandroid/HelloAndroid;'
  Access flags      : 0x0001 (PUBLIC)
  Superclass        : 'Landroid/app/Activity;'
  Interfaces        -
  Static fields     -
  Instance fields   -
  Direct methods    -
    #0              : (in Lcom/example/helloandroid/HelloAndroid;)
      name          : '<init>'
      type          : '()V'
      access        : 0x10001 (PUBLIC CONSTRUCTOR)
      code          -
      registers     : 1
      ins           : 1
      outs          : 1
      insns size    : 4 16-bit code units
0002c4:                                        |[0002c4] com.example.helloandroid.HelloAndroid.<init>:()V
0002d4: 7010 0000 0000                         |0000: invoke-direct {v0}, Landroid/app/Activity;.<init>:()V // method@0000
0002da: 0e00                                   |0003: return-void
      catches       : (none)
      positions     : 
        0x0000 line=6
      locals        : 
        0x0000 - 0x0004 reg=0 this Lcom/example/helloandroid/HelloAndroid; 

  Virtual methods   -
    #0              : (in Lcom/example/helloandroid/HelloAndroid;)
      name          : 'onCreate'
      type          : '(Landroid/os/Bundle;)V'
      access        : 0x0001 (PUBLIC)
      code          -
      registers     : 3
      ins           : 2
      outs          : 2
      insns size    : 9 16-bit code units
0002dc:                                        |[0002dc] com.example.helloandroid.HelloAndroid.onCreate:(Landroid/os/Bundle;)V
0002ec: 6f20 0100 2100                         |0000: invoke-super {v1, v2}, Landroid/app/Activity;.onCreate:(Landroid/os/Bundle;)V // method@0001
0002f2: 1500 037f                              |0003: const/high16 v0, #int 2130903040 // #7f03
0002f6: 6e20 0400 0100                         |0005: invoke-virtual {v1, v0}, Lcom/example/helloandroid/HelloAndroid;.setContentView:(I)V // method@0004
0002fc: 0e00                                   |0008: return-void
      catches       : (none)
      positions     : 
        0x0000 line=10
        0x0003 line=11
        0x0008 line=12
      locals        : 
        0x0000 - 0x0009 reg=1 this Lcom/example/helloandroid/HelloAndroid; 
        0x0000 - 0x0009 reg=2 savedInstanceState Landroid/os/Bundle; 

  source_file_idx   : 1 (HelloAndroid.java)

Class #1            -
  Class descriptor  : 'Lcom/example/helloandroid/R$attr;'
  Access flags      : 0x0011 (PUBLIC FINAL)
  Superclass        : 'Ljava/lang/Object;'
  Interfaces        -
  Static fields     -
  Instance fields   -
  Direct methods    -
    #0              : (in Lcom/example/helloandroid/R$attr;)
      name          : '<init>'
      type          : '()V'
      access        : 0x10001 (PUBLIC CONSTRUCTOR)
      code          -
      registers     : 1
      ins           : 1
      outs          : 1
      insns size    : 4 16-bit code units
000300:                                        |[000300] com.example.helloandroid.R$attr.<init>:()V
000310: 7010 0a00 0000                         |0000: invoke-direct {v0}, Ljava/lang/Object;.<init>:()V // method@000a
000316: 0e00                                   |0003: return-void
      catches       : (none)
      positions     : 
        0x0000 line=11
      locals        : 
        0x0000 - 0x0004 reg=0 this Lcom/example/helloandroid/R$attr; 

  Virtual methods   -
  source_file_idx   : 15 (R.java)

Class #2            -
  Class descriptor  : 'Lcom/example/helloandroid/R$drawable;'
  Access flags      : 0x0011 (PUBLIC FINAL)
  Superclass        : 'Ljava/lang/Object;'
  Interfaces        -
  Static fields     -
    #0              : (in Lcom/example/helloandroid/R$drawable;)
      name          : 'icon'
      type          : 'I'
      access        : 0x0019 (PUBLIC STATIC FINAL)
  Instance fields   -
  Direct methods    -
    #0              : (in Lcom/example/helloandroid/R$drawable;)
      name          : '<init>'
      type          : '()V'
      access        : 0x10001 (PUBLIC CONSTRUCTOR)
      code          -
      registers     : 1
      ins           : 1
      outs          : 1
      insns size    : 4 16-bit code units
000318:                                        |[000318] com.example.helloandroid.R$drawable.<init>:()V
000328: 7010 0a00 0000                         |0000: invoke-direct {v0}, Ljava/lang/Object;.<init>:()V // method@000a
00032e: 0e00                                   |0003: return-void
      catches       : (none)
      positions     : 
        0x0000 line=13
      locals        : 
        0x0000 - 0x0004 reg=0 this Lcom/example/helloandroid/R$drawable; 

  Virtual methods   -
  source_file_idx   : 15 (R.java)

Class #3            -
  Class descriptor  : 'Lcom/example/helloandroid/R$layout;'
  Access flags      : 0x0011 (PUBLIC FINAL)
  Superclass        : 'Ljava/lang/Object;'
  Interfaces        -
  Static fields     -
    #0              : (in Lcom/example/helloandroid/R$layout;)
      name          : 'main'
      type          : 'I'
      access        : 0x0019 (PUBLIC STATIC FINAL)
  Instance fields   -
  Direct methods    -
    #0              : (in Lcom/example/helloandroid/R$layout;)
      name          : '<init>'
      type          : '()V'
      access        : 0x10001 (PUBLIC CONSTRUCTOR)
      code          -
      registers     : 1
      ins           : 1
      outs          : 1
      insns size    : 4 16-bit code units
000330:                                        |[000330] com.example.helloandroid.R$layout.<init>:()V
000340: 7010 0a00 0000                         |0000: invoke-direct {v0}, Ljava/lang/Object;.<init>:()V // method@000a
000346: 0e00                                   |0003: return-void
      catches       : (none)
      positions     : 
        0x0000 line=16
      locals        : 
        0x0000 - 0x0004 reg=0 this Lcom/example/helloandroid/R$layout; 

  Virtual methods   -
  source_file_idx   : 15 (R.java)

Class #4            -
  Class descriptor  : 'Lcom/example/helloandroid/R$string;'
  Access flags      : 0x0011 (PUBLIC FINAL)
  Superclass        : 'Ljava/lang/Object;'
  Interfaces        -
  Static fields     -
    #0              : (in Lcom/example/helloandroid/R$string;)
      name          : 'app_name'
      type          : 'I'
      access        : 0x0019 (PUBLIC STATIC FINAL)
    #1              : (in Lcom/example/helloandroid/R$string;)
      name          : 'hello'
      type          : 'I'
      access        : 0x0019 (PUBLIC STATIC FINAL)
  Instance fields   -
  Direct methods    -
    #0              : (in Lcom/example/helloandroid/R$string;)
      name          : '<init>'
      type          : '()V'
      access        : 0x10001 (PUBLIC CONSTRUCTOR)
      code          -
      registers     : 1
      ins           : 1
      outs          : 1
      insns size    : 4 16-bit code units
000348:                                        |[000348] com.example.helloandroid.R$string.<init>:()V
000358: 7010 0a00 0000                         |0000: invoke-direct {v0}, Ljava/lang/Object;.<init>:()V // method@000a
00035e: 0e00                                   |0003: return-void
      catches       : (none)
      positions     : 
        0x0000 line=19
      locals        : 
        0x0000 - 0x0004 reg=0 this Lcom/example/helloandroid/R$string; 

  Virtual methods   -
  source_file_idx   : 15 (R.java)

Class #5            -
  Class descriptor  : 'Lcom/example/helloandroid/R;'
  Access flags      : 0x0011 (PUBLIC FINAL)
  Superclass        : 'Ljava/lang/Object;'
  Interfaces        -
  Static fields     -
  Instance fields   -
  Direct methods    -
    #0              : (in Lcom/example/helloandroid/R;)
      name          : '<init>'
      type          : '()V'
      access        : 0x10001 (PUBLIC CONSTRUCTOR)
      code          -
      registers     : 1
      ins           : 1
      outs          : 1
      insns size    : 4 16-bit code units
000360:                                        |[000360] com.example.helloandroid.R.<init>:()V
000370: 7010 0a00 0000                         |0000: invoke-direct {v0}, Ljava/lang/Object;.<init>:()V // method@000a
000376: 0e00                                   |0003: return-void
      catches       : (none)
      positions     : 
        0x0000 line=10
      locals        : 
        0x0000 - 0x0004 reg=0 this Lcom/example/helloandroid/R; 

  Virtual methods   -
  source_file_idx   : 15 (R.java)

結果、HelloAndroid.apkで使用さ れているクラスは#0~#5の6つ。
Class #0のVirtual methodsは1つで、名前はonCreate。
メ ソッド内で、super.onCreate()とsetContentView()をコールしていることがわかります。
これだけ逆 アセンブルできれば十分ですね。


저작자 표시 비영리 변경 금지
신고

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

iPhone Unpack  (0) 2010.03.29
How to Get Started with iPhone Dev  (0) 2010.03.28
[iPhone] libgcc  (4) 2010.03.25
Android apk file decompiler  (0) 2010.03.24
iPhone perl Framework  (0) 2010.03.23
Sad iPhone  (2) 2010.02.28
Posted by Sun2Day

댓글을 달아 주세요


티스토리 툴바