안드로이드2014. 6. 26. 15:29

어제 06/25일자 Google I/O를 라이브로 시청하게 됐는데, Android TV가 새롭게 단장을 하고 나왔다.
관련 이미지야 찾아보면 많으니 여긴 갔다 붙이진 않겠지만, 기존 Android TV와 다른 점은,

 

기존 Android TV가 스마트폰을 대형화 시킨 구조였다면, 이번 Android TV는 적어도 TV에 맞게 컨트롤 및 접근성에 대한 배려를 갖추고 나왔다고 하면 되겠다.

 

쉽게 말하자면, TV 패널은 터치가 되지 않는다. 그래서 스마트폰에서 어떤 앱을 실행시킬려는 시도나 특정 시나리오에 접근하려는 의도가 티비에서는 잘 되지 않는다. 아니, 개짜증난다.

리모콘으로 홈 메뉴 누르고, 스크롤해서 해서 어플에 접근한다고 해보자.  티비를 보는 사람은 그렇게 복잡한 과정을 원치 않는다.  쇼파에 누워서 몇번 클릭 클릭으로 혹은 단순한 채널 서핑 정도로 자기가 보고 싶은게 나와야 직성이 풀린다.

 

그래서 이번 Android TV는 적어도 데모영상만 봤을 때, 그러한 접근성과, 주변기기(스마트폰 + 웨어러블 디바이스(데모에서는 G와치로 구동시키는걸 보여줬다))를 통한 좀 더 익숙한(?) 컨트롤을 제공한다.   이건 확실히 올바른 방향으로 나아간다고 봐야 겠다.  아직 인터페이스가 썩 이쁘다고 하기엔 그랬다.  컨텐츠가 리스트되는 건 좋은데, 뒤의 티비 혹은 영상을 똬악 가리면서 나오는건 좀 더 처리가 필요하다고 보인다.

 

그리고, 게이밍을 강조한다고 했는데, 막상 보여준 게임은 NBA잼하고, 그 이름 뭐를 커비를 연상시키는 털 복숭이가 팡팡 뛰어다니는 게임(게임디테일은 매우 띄어나 보였다)밖에 없어서 아직 어떤 정도의 수준을 생각하는지는 모르겠다만, 벤더 리스트에 퀄컴이 있었던걸로 보아 제조사의 의지에 따라 요새 고성능 스마트폰에서 체감할 수 있는 정도의 성능을 보여줄 수도 있다고 본다.

 

아직은 갈길이 멀어보이지만, 구글이 이번 I/O를 통해서 IoT의 주도권을 가져가려는 의도는 확실히 보인다.  이는 기존 제조업체에서도 그리 반갑게 느껴지지는 않을 거라고 보인다.(정말 토스터 기에도 안드로이드를 깔아야 되는 시대는 그리 원치 않는다.) 참고로 셋톱박스 쪽에 레이져도 붙은걸 보니, 콘솔게이밍 디바이스+홈엔터테인먼트 기기로서의 포지션도 기대해볼만 하다.

'안드로이드' 카테고리의 다른 글

bionic linker  (0) 2013.09.10
Posted by code cat
안드로이드/포팅2014. 4. 13. 18:36

[    3.11328] init: skipping insecure file '/default.prop'
[    3.133259] init: skipping insecure file '/init.rc'

라는 에러 메세지가 나오면서 부팅이 안되면, 이는 다음과 같이 젤리빈(이상버전 동일?)에서 다음과 같이 파일 스탯을 참조하여, owner외에 writable 못하게 막아놓았기 때문이다.

143    char *data;
144    int sz;
145    int fd;
146    struct stat sb;
147
148    data = 0;
149    fd = open(fn, O_RDONLY);
150    if(fd < 0) return 0;
151
152    // for security reasons, disallow world-writable
153    // or group-writable files
154    if (fstat(fd, &sb) < 0) {
155        ERROR("fstat failed for '%s'\n", fn);
156        goto oops;
157    }
158    if ((sb.st_mode & (S_IWGRP | S_IWOTH)) != 0) {


그럼 간단히, 644 혹은, 655 정도로 파일 퍼미션을 바꿔주면 된다.

Posted by code cat
안드로이드/포팅2014. 4. 1. 09:38

출처: Nathaniel Husted, Augst 19, 2011, "Notes regarding Android OS System Development and Security as of Android 2.3.4"


7 Android Escalation of Privledge Attacks

Two attacks against the Android platform currently exist. These attacks

allow a user-level privledge to gain root privledges on the Android platform.

They both exploit userland vulnerabilities in Android. Some of these exploits

have been fixed, but the fixes depend on the manufacturer10

.

7.1 Rage Against The Cage

The Rage Against The Cage exploit takes advantage of a bug in the adb

code. The adb code on android performs certain actions as root at start up

but then drops root privledges using setuid. The exploit is in that the adb

code does not check if the setuid call succeeds of fails. If the call fails adb will

continue to run as the root user. Rage Against The Cage works by forking

enough children processes to reach the NPROC limit on the machine and

attempts to restart adb while NPROC is maxed. When this happens, the

setuid call will fail in adb and it will continue to run with root privledges.

Details can be found at http://intrepidusgroup.com/insight/2010/

09/android-root-source-code-looking-at-the-c-skills/.


7.2 Exploid

The exploid vulnerability takes advantage of the udev system on Android.

The Google developers removed a large amount of code from udev as it would

be implemented on Linux and moved the code into the init daemon. The

dillema is that the udev code used is susceptible to a bug that existed in

udev prior to 1.4.1 that did not verif that kernel messages it received came

from the kernel. In the Android OS this means that init would receive these

requests and init runs as root. A brief overview of the exploit is as follows:

1. Exploid copies it to a system directory writable to the shell user

2. It then sends a “NETLINK_KOBJECT_UEVENT” message to the

kernel.

3. Copied executable checks to see if it srunning as root..

4. When running as root, remounts system partition as read-write

5. Finally copies /system/bin/sh to /system/bin/rootshell and chmod’s

to 04711 to always run as root.

Details can be found at http://intrepidusgroup.com/insight/2010/

09/android-root-source-code-looking-at-the-c-skills/.


7.3 KillingInTheNameOf

The KillingInTheNameOf exploit is slightly different in that it takes advantage

of google’s custom shmem interface “ashmem”. The program maps the

system properties into a processes adress space. The vulnerability is that

they are not maped as write protected. The vulnerability then finds the

ro.secure property of adb and flips it. That allows any shell started by adb

to run as root. Rough details can be found in http://jon.oberheide.org/

files/bsides11-dontrootrobots.pdf.


7.4 ZimperLich

The ZimperLich follows the same structure as the Exploid vulnerability.

There are two major differences, though. First, ZimperLich attacks the

Zygote process on android and its lack of a check against the failure of setuid.

The Zygote process is the parent process which all Dalvik jails are

forked from. the other difference is that attacking Zygote does not require

a shell with a uid so the ZimperLich attack can be run from an APK. The

source code for ZimperLich can be found at http://c-skills.blogspot.

com/2011/02/zimperlich-sources.html.


7.5 GingerBreak

The GingerBreak exploit works in a similar manner to the Exploid vulnerability.

The difference is that in this case the exploit takes advantage of the

“vold” daemon improperly trusting messages recieved. A buffer underflow attack

is commited that causes and escalation of privledge attack. The attack

was found to work on on a number of devices from Android 2.2 to Android

3.0. The vulnerability is CVE-2011-1823. The very general description can be

found at https://groups.google.com/group/android-security-discuss/

browse\_thread/thread/1ac1582b7307fc5c. Source code for the exploit

can be found at http://c-skills.blogspot.com/2011/04/yummy-yummy-gingerbreak.

html.

This has supposedly been fixed in newer versions of the Android source

11 as of May 2nd.

Posted by code cat

 

454// Evaluate the expressions in argv, returning an array of char*
455// results.  If any evaluate to NULL, free the rest and return NULL.
456// The caller is responsible for freeing the returned array and the
457// strings it contains.
458char** ReadVarArgs(State* state, int argc, Expr* argv[]) {
459    char** args = (char**)malloc(argc * sizeof(char*));
460    int i = 0;
461    for (i = 0; i < argc; ++i) {
462        args[i] = Evaluate(state, argv[i]);
463        if (args[i] == NULL) {
464            int j;
465            for (j = 0; j < i; ++j) {
466                free(args[j]);
467            }
468            free(args);
469            return NULL;
470        }
471    }
472    return args;
473}
argv의 entry들을 하나씩 Evaluate으로 패스. 

 

패스된 argv=expr을 받아서

35char* Evaluate(State* state, Expr* expr) {
36    Value* v = expr->fn(expr->name, state, expr->argc, expr->argv);
37    if (v == NULL) return NULL;
38    if (v->type != VAL_STRING) {
39        ErrorAbort(state, "expecting string, got value type %d", v->type);
40        FreeValue(v);
41        return NULL;
42    }
43    char* result = v->data;
44    free(v);
45    return result;
46}


Value *v에 expr->fn(expr->name, state, expr->argc, expr->argv) 를 assign시킴.

Value은 다음과 같은 구조체.

51typedef struct {
52    int type;
53    ssize_t size;
54    char* data;
55} Value;

 

expr은 Expr 구조체이며,

60struct Expr {
61    Function fn;
62    char* name;
63    int argc;
64    Expr** argv;
65    int start, end;

 

expr->fn은 Function 타입, Function은

57typedef Value* (*Function)(const char* name, State* state,
58                           int argc, Expr* argv[]);

형태로 정의됨.

type인 string인지 확인하고 아닐 경우, 에러 메세지를 state에 저장하고, string일 경우, 정상 진행.

마지막에 v->data를 리턴함.

이런 값들을 모아서 ReadVarArgs는 args 배열로 리턴.

 

 

expr.h

30typedef struct Expr Expr;
31
32typedef struct {
33    // Optional pointer to app-specific data; the core of edify never
34    // uses this value.
35    void* cookie;
36
37    // The source of the original script.  Must be NULL-terminated,
38    // and in writable memory (Evaluate may make temporary changes to
39    // it but will restore it when done).
40    char* script;
41
42    // The error message (if any) returned if the evaluation aborts.
43    // Should be NULL initially, will be either NULL or a malloc'd
44    // pointer after Evaluate() returns.
45    char* errmsg;
46} State;
47
48#define VAL_STRING  1  // data will be NULL-terminated; size doesn't count null
49#define VAL_BLOB    2
50
51typedef struct {
52    int type;
53    ssize_t size;
54    char* data;
55} Value;
56
57typedef Value* (*Function)(const char* name, State* state,
58                           int argc, Expr* argv[]);
59
60struct Expr {
61    Function fn;
62    char* name;
63    int argc;
64    Expr** argv;
65    int start, end;
66};

 

Posted by code cat

출처:http://kimyow.blog.me/50116380850

이 글이 가장 인기있는 글이네요.

지금와서 다시 읽어보니, 내용이 너무 두서없는 것 같아, 좀 더 이해가 쉽도록 수정을 했습니다. signing 개념 이해에 많은 도움이 되길 바라겠습니다.

=================================================================


Platform key signing 을 하는 이유는 뭘까?


왜 굳이 Platform key 로 signing 을 해야 할까?


일반적인 apk 의 경우, (일반 개발자, 3rd party 가 개발한 APK) 자신이 만든 apk 를, data 영역에 install 할 수 있으며, 또는 rooting 한 폰의 system 영역에 설치할 수 있고, 이를 실행할 수 있다.


여기서 일반적인 apk 란, 통상적을 제공되는 sdk 에서 개발 된 apk 를 말한다.

(Vendor가 아닌, 일반적인 모든 개발자가 Eclipse 등 SDK를 사용하여 개발한 Application)


Full image build 과정에서 생성되는 System image(Framework.jar)를 사용하면, 소위말하는 Internal or Hidden API 를 사용하여 build 할 수 있다.


SDK 로 제공되는 android.jar 에는 포함되지 않는 API(method) 들이 많다. 

이는 Android가 일반 개발자에게는 open 하지 않는 기능들이라고 봐도 좋다.


오직 Device 를 만들어서 파는 Vendor(삼성/LG)들만이 사용할 수 있다.


Settings.apk 의 경우,


타 모델의 apk 또는 source 를 구한다 한 들, 쉽게 자신의 phone 에 설치 & 실행이 안 될 것이다.

(Setting 만이 가지고 있는 특정 기능을 포기한 후 build 한다면, 가능하다.)


이미 당신이 가지고 있는 폰은 Vendor 가 User mode 로 build 한, 특정 key 로 signing 된 image 를 사용하기 때문이다.

( Debug or Engineer 모드로 build 된 image 가 탑재된 상태로 시장에 출시되지 않겠죠? )


User mode build 시, Vendor 는 android 에서 제공되는 known key (보통, \build\target\product\security\ 안에 있다.) 로 signing 하지 않으며, 각자의 unique 한 key 를 만들어서 signing 한다. 개발 편의를 위해서 default key 로 signing 하기도 하는데, 이는 eclipse 가 build 시 signing 하는 key 와 동일하다.


즉, Vendor 입장에서는 개발 단계와 양산 단계의 signing key 가 다른 것이다.


System 권한이 필요한 Setting 의 경우, Platform key 로 signing 후 설치된다. System과 동일한 uid 를 가져야 동일한 권한으로 data/code 사용이 가능하며 이를 위해서는 system 과 동일한 platform key 로 signing 되어야 한다.


하지만, 이미 당신이 가지고 있는 device(phone) 의 platform key 를 가지고 있지 않은 이상, 아무리 source build 를 성공해도 만들어진 Settings.apk 를 설치하기란 불가능하다.

(설치하려고 하면, INSTALL_FAILED_SHARED_USER_INCOMPATIBLE error 가 뜰 것이다.)


물론, 위에서 언급했듯이 Setting 만의 특정 기능을 뺀다면 가능하다.


Setting 만의 특정 기능이란, 타 application 을 memory 상에서 깨끗하게 kill 할 수 있는 기능이다.


이는 위에서 언급한 internal api 를 사용해야 하므로, 3rd party application 에선 사용이 불가능하며, system 권한/자격이 필요한 기능이다.


System 권한, 자격을 포기한다면, 굳이 platform key 로 signing 할 필요 없으며, 일반적인 application 으로써, 어떤 device 든지 기 설치되어 있는 settings.apk 만 확실히 제거한 후, 당신이 빌드한 새로운 settings.apk를 재설치해서 사용이 가능하다.


이 system 자격, 권한을 포기한다는 의미가, AndroidManifest.xml 에서 속성으로 명시된,

android:sharedUserId="android.uid.system" 항목을 삭제하는 것이다.


위 의미는 system process 와 같은 uid 를 사용하므로써, system process 의 code & data 를 똑 같이 공유할 수 있는 권한을 해당 application 에게 준다는 의미이다.


따라서 위 항목을 지우고 build 한 apk 를 설치하면 아주 자~~알 설치될 것이다.


하지만,~~ Settings > Applications >Manage applications 에서 "Force stop" 버튼을 클릭 하는 순간 unexpected error, 즉 setting application 이 죽을 것이다.


System 자격이 있는 넘이 호출해야 할 함수를 자격이 없는 application이 호출했기 때문에 Permission error 가 나는 것이다.


대표적인 Internal api method 인, ActivityManager 의 forceStopPackage() 를 예로 들어보자.- Internal API이므로, 일반 개발자에게는 open 되어 있지 않은 함수다.


보통 Market에서 download 받아 설치하는 일반적인 system application의 경우(TaskManager), ActivityManager.killBackgroundProcesses() 로 application 을 kill하는데, 이는 application 우선순위가 Background 이하인 application 만 kill 하는 제약을 가지고 있다.(Visible, Foreground, Service 우선순위는 완벽하게 kill 할 수 없다.)


이에 반해 ActivityManager.forceStopPackage() 함수는 아무런 제약 사항없이 대상이 되는 application 을 메모리상에서 깨끗히 지우는 기능을 한다.


이 함수를 실행하기 위해서는 permission 이 필요한데, 

<uses-permission android:name="android.permission.FORCE_STOP_PACKAGES"></uses-permission>

라고 AndroidManifest.xml 에 명시해줘야 한다.


이렇게 해서 build 된 apk 를 install 한 후, 실행 하면 하기와 같은 exception 이 발생한다.


==================================================================

 

07-21 10:38:13.480: WARN/ActivityManager(1981): Permission Denial: forceStopPackage() from pid=3565, uid=10110 requires android.permission.FORCE_STOP_PACKAGES

07-21 10:38:13.503: ERROR/AndroidRuntime(3565): FATAL EXCEPTION: main

07-21 10:38:13.503: ERROR/AndroidRuntime(3565): java.lang.SecurityException: Permission Denial: forceStopPackage() from pid=3565, uid=10110 requires android.permission.FORCE_STOP_PACKAGES

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at android.os.Parcel.readException(Parcel.java:1260)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at android.os.Parcel.readException(Parcel.java:1248)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at android.app.ActivityManagerProxy.forceStopPackage(ActivityManagerNative.java:2564)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at android.app.ActivityManager.forceStopPackage(ActivityManager.java:968)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at com.lge.lmk.activities.RunningProcessActivity$4.onClick(RunningProcessActivity.java:850)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at com.android.internal.app.AlertController$ButtonHandler.handleMessage(AlertController.java:158)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at android.os.Handler.dispatchMessage(Handler.java:99)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at android.os.Looper.loop(Looper.java:123)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at android.app.ActivityThread.main(ActivityThread.java:4668)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at java.lang.reflect.Method.invokeNative(Native Method)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at java.lang.reflect.Method.invoke(Method.java:521)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:878)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:636)

07-21 10:38:13.503: ERROR/AndroidRuntime(3565):     at dalvik.system.NativeStart.main(Native Method)

==================================================================

 


"android.permission.FORCE_STOP_PACKAGES" Permission 을 명시해 줬는데 왜 Permission error가 날까?


이 함수를 call 하는 application쪽에 System process 의 권한이 없기 때문이다.


system process 와 동일한 권한을 갖기위해서는?


AndroidManifest.xml 파일의 manifest attribute 에 하기와 같이 지정해 주면 된다.

android:sharedUserId="android.uid.system"


이 application process 의 uid 를 system 과 공유함으로써, system 과 동일한 권한을 갖겠다는 의미다.


참 편리하게 system 권한을 가질 수 있다고 생각할 수 있지만, 이는 어디까지 platform(system)  과 signature 가 같을 때의 경우에만 해당된다.


다시한번 언급하자면,

모든 사용자가 구입한 폰은 각 Vendor 측의 고유 key로 signing 된, User mode 로 빌드 된 image 가 탑재 되었고, 각 모델별로 고유한 platform key 로 signing 되었기 때문에, 아무리 rooting 을 했건, 뭐를 했건간에, User mode 로 빌드 된 image의 key 를 바꿀 순 없다.

(Vendor 측에 아는 사람이 있어 debug 나, engineer 모드로 빌드된 image 를 구할 수 있다면??)


전체 이미지 빌드 타임에 system 과 data 영역에 들어갈 모든 APK는, 싹 다 각각 Android.mk에 명시된 key 값으로 signing 한다.


때문에, Signature 가 Platform과 맞지 않은 Settings application 을 폰에 탑재하는 순간, 아래와 같은 logcat msg 와 함께, 해당 apk 는 launcher 에서 볼 수 없을 것이다.(PackageManager 가 package loading 실패)

====================================================================

07-21 10:56:36.046: WARN/PackageManager(1981): Package com.test.application shared user changed from <nothing> to android.uid.system; replacing with new

07-21 10:56:36.054: WARN/PackageManager(1981): Signature mismatch for shared user : SharedUserSetting{462749e8 android.uid.system/1000}

07-21 10:56:36.054: ERROR/PackageManager(1981): Package com.test.application has no signatures that match those in shared user android.uid.system; ignoring!

 

====================================================================


또는,(아래는 살짝 다른 유형의 error 다.)

====================================================================

 


08-09 09:47:06.054: ERROR/PackageManager(1973): Package com.test.application signatures do not match the previously installed version; ignoring!

08-09 09:47:06.257: INFO/IQClient(2030): submitHW03 -  status- 2 level- 74

====================================================================

 


system 쪽과 signature mis-match 가 나서 이 어플을 loading 할 수 없다는 의미이다.


해결방법은 해당 어플도 똑같이 platform signing 을 해주는 방법밖에 없다.


그래야 system 권한을 얻을 수 있다는 의미이다.


하기와 같이 platform key 를 어디선가 구해와서 signing 해주면 된다.

(당연히 아래 platform key 가 당신의 device 에 flashing 되어 있는 image 의 signed platform key 와 동일해야 한다.)


Platform key 는 어디서 구할까...??? 해당 모델의 Vendor 만이 알 수 있다.


java -jar signapk.jar platform.x509.pem platform.pk8 Unsigned.apk Signed.apk


위 명령어로 생성된 Signed.apk 를 설치해주면 System 권한으로 internal api 사용이 가능하며 원하는 모든 기능이 정상 동작 될 것이다.

Posted by code cat
안드로이드/포팅2013. 12. 29. 18:24

 통신사를 끼고 해보진 않아서 생략되는 부분도 있지만, 달리 추가되는 부분도 있다.

그래도 나름 잘 정리해 놓은거 같다.

 

 

'안드로이드 > 포팅' 카테고리의 다른 글

skipping insecure file  (0) 2014.04.13
Android Exploit  (0) 2014.04.01
안드로이드 adb 명령어 리스트  (0) 2013.12.01
안드로이드 settings 데이터 알아보기  (0) 2013.12.01
안드로이드 system 파티션 remount  (0) 2013.11.28
Posted by code cat
안드로이드/포팅2013. 12. 1. 11:03

xda 포럼에서 가져왔는데 링크가...



 adb devices   

 list all connected devices

 adb push <local> <remote>

 copy file/dir to device

 adb pull <remote> [<local>]

 copy file/dir from device

 adb sync [ <directory> ]

 copy host->device only if changed

 adb shell

 run remote shell interactively

 adb shell <command>

 run remote shell command

 adb emu <command>

 run emulator console command

 adb logcat [ <filter-spec> ]

 View device log

 adb forward <local> <remote>

localabstract:<unix domain socket name>
localreserved:<unix domain socket name>
localfilesystem:<unix domain socket name>
dev:<character device name>
jdwp:<process pid> (remote only)

 forward socket connections forward specs are one of: tcp:<port>

 adb jdwp 

 list PIDs of processes hosting a JDWP transport

 adb install [-l] [-r] [-s] <file> push this package file to the device and install it
 adb uninstall [-k] <package> remove this app package from the device (‘-k’ means keep the data and cache directories)
 adb bugreport return all information from the device that should be included in a bug report.
 adb help show this help message
 adb version show version num
 adb wait-for-device block until device is online
 adb start-server ensure that there is a server running
 adb kill-server

 kill the server if it is running

 adb get-state prints: offline | bootloader | device
 adb get-serialno

 prints: <serial-number>

 adb status-window continuously print device status for a specified device
 adb remount remounts the /system partition on the device read-write
 adb reboot [bootloader|recovery] reboots the device, optionally into the bootloader or recovery program
 adb reboot-bootloader

 reboots the device into the bootloader

 adb root

 restarts the adbd daemon with root permissions

 adb usb  restarts the adbd daemon listening on USB
 adb tcpip <port> 

 restarts the adbd daemon listening on TCP on the specified port




Posted by code cat
안드로이드/포팅2013. 12. 1. 08:36

안드로이드에서 settings에 저장되는 여러 값에 대해 궁금하다면 다음과 같이 보면 된다.

우선 settings에 관련된 value들은 db에 저장되는 이는 다음의 위치에 있다.


/data/data/com.android.providers.settings/databases/settings.db


이 db를 접속하려면 console에서 다음과 같이 하자.

#sqlite3 settings.db



그러면 sqlite 콘솔이 뜨는데, 여기서 다음과 같이 해보자.

sqlite>.table



그러면 현재 query가능한 table들이 나온다.

android_metadata system bluetooth_devices secure



여기서 secure의 값들을 보고 싶으면 아래와 같이 하면 된다.

sqlite>select * from system;



해당 sqlite3 명령어에 대해서는 인터넷에 검색하면 잘 나온다.

참고로 sqlite3 에서 나오는 명령어는 .quit이다.


Posted by code cat
안드로이드/포팅2013. 11. 28. 16:59

system 파티션을 RW으로 remount하기 위해서는 다음과 같이 콘솔에서 실행하면 된다.

(system 파티션에 대한 path는 각자 다르니 사용하는 디바이스에 맞추면 된다.)


mount -o rw,remount /dev/block/.../by-name/system


'안드로이드 > 포팅' 카테고리의 다른 글

안드로이드 adb 명령어 리스트  (0) 2013.12.01
안드로이드 settings 데이터 알아보기  (0) 2013.12.01
Android Build System 용어  (0) 2013.10.16
GGLContext 에 대하여  (0) 2013.03.24
pthread_cancel()  (0) 2013.02.04
Posted by code cat


xref: /system/core/libmincrypt/sha.c

286void SHA_init(SHA_CTX* ctx) {
287    ctx->state[0] = 0x67452301;
288    ctx->state[1] = 0xEFCDAB89;
289    ctx->state[2] = 0x98BADCFE;
290    ctx->state[3] = 0x10325476;
291    ctx->state[4] = 0xC3D2E1F0;
292    ctx->count = 0;
293}


/system/core/include/mincrypt/sha.h

37typedef struct SHA_CTX {
38    uint64_t count;
39    uint32_t state[5];
40#if defined(HAVE_ENDIAN_H) && defined(HAVE_LITTLE_ENDIAN)
41    union {
42        uint8_t b[64];
43        uint32_t w[16];
44    } buf;
45#else
46    uint8_t buf[64];
47#endif
48} SHA_CTX;


xref: /system/core/libmincrypt/sha.c

147void SHA_update(SHA_CTX* ctx, const void* data, int len) {
148    int i = ctx->count % sizeof(ctx->buf);
149    const uint8_t* p = (const uint8_t*)data;
150
151    ctx->count += len;
152
153    while (len > sizeof(ctx->buf) - i) {
154        memcpy(&ctx->buf.b[i], p, sizeof(ctx->buf) - i);
155        len -= sizeof(ctx->buf) - i;
156        p += sizeof(ctx->buf) - i;
157        SHA1_Transform(ctx);
158        i = 0;
159    }
160
161    while (len--) {
162        ctx->buf.b[i++] = *p++;
163        if (i == sizeof(ctx->buf)) {
164            SHA1_Transform(ctx);
165            i = 0;
166        }
167    }
168}


Posted by code cat