androideval

㈠ android學習之Build環境介紹

這里略過對android在手機上的文件系統框架的闡述（google或者都能幫助你找到對應的信息），主要看google是如何把生成合適的rootfs的工作整合到它的build體系當中，同時，會順帶看一下CyanogenMod中對應各種機型的build機制。
首先，來看一下Android的build系統中，使用到的編譯選項和相關工具
具體的目錄在：mydroid/build/tools/下
|-- acp
這是一個稍微改良的cp命令，用來應付在windows/MAC/linux下的cp命令的缺陷，其中的README很值得一看！
|-- adbs
這是一個用來查看crash問題的工具，詳細請看《Android調試工具之adbs》
|-- Android.mk
|-- apicheck
用來進行發布前的API檢查（參見mydroid/build/core/tasks/apicheck.mk），是否新編譯的系統中有破壞API兼容性或是非法的API
這里的代碼是用java寫的用來檢查編譯時生成的API相關信息的xml文件（mydroid/framework/base/api/中），可以參考裡面對於xml文件解析的代碼
|-- apriori
實現prelink的工具，簡單介紹參見（mydroid/bionic/linker/README.TXT）
|-- atree
為android SDK服務的一個工具，用來按照指定xxx.atree文件中的內容進行一些文件操作
|-- bin2asm
不太明白具體的用處，應該是用來應付mac上編譯android一些與gcc相關的問題
|-- buildinfo.sh
生成target中的各種xxx.prop文件，如system.prop, build.prop等
|-- check_builds.sh
包裝了diff，用來看2個發布版本之間變化
|-- check_prereq
device上進行ota升級時的工具之一
|-- compare_fileslist.py
與check_builds.sh配合完成版本比較的腳本
|-- droiddoc
Android更具javadoc的一些移植
|-- mp-package-stats
簡單的查看一個jar/apk文件內的dex和其它文件的大小信息
|-- event_log_tags.py
處理event-log-tags的內容，關於event-log-tags文件的意義參見《Android學習之event-log-tags是神馬》
|-- fileslist.py
簡化的列出指定目錄下所有文件及大小的腳本 -- 可以放入自己的工具庫了使用：）
|-- findleaves.py
在指定目錄中（可多個）找指定文件的腳本 -- 可以放入自己的工具庫了使用：）
|-- fixlinebreaks.sh
把windows中的換行改為linux下的 -- 可以放入自己的工具庫了使用：大散蘆）
|-- fs_config
列出指定文件夾滾帶及文件的許可權
|-- fs_get_stats
得到指定文件夾下文件的簡單stats信息
|-- iself
判斷文件是否是ELF格式
|-- isprelinked
判斷文件是否是prelink過的
|-- java-event-log-tags.py
處理event-log-tags的內容，關於event-log-tags文件的意義參見《Android學習之event-log-tags是神馬》
|-- kcm
key character map的工具， 相關資料參照：
|-- lsd
!!!!!! ???
|-- merge-event-log-tags.py
處理event-log-tags的內容，關於event-log-tags文件的意掘野義參見《Android學習之event-log-tags是神馬》
|-- mktarball.sh
與fs_get_stats配合而執行的打包工具
|-- print_mole_licenses.sh
顯示當前目錄下所有mole信息
|-- releasetools
-- check_target_files_signatures
|-- common.py
|-- edify_generator.py
|-- img_from_target_files
|-- ota_from_target_files
`-- sign_target_files_apks
|-- rgb2565
rgb轉換工具
|-- signapk
命令行下對jar包簽名的工具
|-- soslim
Android定製的編譯工具之一，簡單介紹參見（mydroid/bionic/linker/README.TXT）
|-- warn.py
解析Android系統編譯log的工具
`-- zipalign
zipfile的對齊工具，參見該文件夾下的README.TXT
#p#副標題#e#
在來看看Android編譯系統中定義的一些通用XXX.mk文件
mydroid/build/core/
|-- armelflib.x
|-- armelf.x
|-- armelf.xsc
|-- base_rules.mk
|-- binary.mk
|-- build_id.mk
|-- build-system.html
|-- checktree
|-- cleanbuild.mk
|-- cleanspec.mk
|-- clear_vars.mk
|-- combo
|-- config.mk
|-- _headers.mk
|-- definitions.mk
|-- device.mk
|-- dex_preopt.mk
|-- distdir.mk
|-- droiddoc.mk
|-- mpvar.mk
|-- dynamic_binary.mk
|-- envsetup.mk
|-- executable.mk
|-- filter_symbols.sh
|-- find-jdk-tools-jar.sh
|-- help.mk
|-- host_executable.mk
|-- host_java_library.mk
|-- host_native_test.mk
|-- host_prebuilt.mk
|-- host_shared_library.mk
|-- host_static_library.mk
|-- java_library.mk
|-- java.mk
|-- legacy_prebuilts.mk
|-- main.mk
|-- Makefile
|-- multi_prebuilt.mk
|-- native_test.mk
|-- node_fns.mk
|-- notice_files.mk
|-- package.mk
|-- pathmap.mk |-- phony_package.mk
|-- prebuilt.mk
|-- process_wrapper_gdb.cmds
|-- process_wrapper_gdb.sh
|-- process_wrapper.sh
|-- proct_config.mk
|-- proct.mk
|-- proguard.flags
|-- proguard_tests.flags
|-- raw_executable.mk
|-- raw_static_library.mk
|-- root.mk
|-- shared_library.mk
|-- static_java_library.mk
|-- static_library.mk
|-- tasks
|-- user_tags.mk
`-- version_defaults.mk
#p#副標題#e#
這里，目錄在mydroid/build/core/tasks/有一些特別的task
|-- apicheck.mk, 判斷api是否符合AOSP的規范
|-- cts.mk cts測試， 可以在代碼根目錄， make cts, 編譯結束之後，進入out/host/linux-x86/bin/下，執行cts命令
|-- ide.mk IDE開發環境
|-- proct-graph.mk
`-- sdk-addon.mk
NDK的build環境沒有包含在標注難得AOSP的/build/目錄下
而是在mydroid/ndk/build下
$ cd ndk/build/tools
$ export ANDROID_NDK_ROOT=aosp-root/ndk
$ ./make-release --help
一些小技巧
如何顯示每次編譯所包含的所有xxx.mk文件
找到build/core/main.mk
把include $（subdir_makefiles）替換為
[plain] view plain $（foreach subdir_makefile, $（subdir_makefiles），
$（info Including $（subdir_makefile））
$（eval include $（subdir_makefile））)
subdir_makefile :=
如果遇見API相關的PACKAGING/checkapi-current-timestamp] Error 38
需要執行：make update-api
如何在AOSP代碼目錄之外編譯
[plain] view plain # Paths and settings
TARGET_PRODUCT = generic
ANDROID_ROOT = /home/karim/android/aosp-2.3.x
BIONIC_LIBC = $（ANDROID_ROOT）/bionic/libc
PRODUCT_OUT = $（ANDROID_ROOT）/out/target/proct/$（TARGET_PRODUCT）
CROSS_COMPILE =
$（ANDROID_ROOT）/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
# Tool names
AS = $（CROSS_COMPILE）as
AR = $（CROSS_COMPILE）ar
CC = $（CROSS_COMPILE）gcc
CPP = $（CC） -E
LD = $（CROSS_COMPILE）ld
NM = $（CROSS_COMPILE）nm
OBJCOPY = $（CROSS_COMPILE）obj
OBJDUMP = $（CROSS_COMPILE）objmp
RANLIB = $（CROSS_COMPILE）ranlib
READELF = $（CROSS_COMPILE）readelf
SIZE = $（CROSS_COMPILE）size
STRINGS = $（CROSS_COMPILE）strings
STRIP = $（CROSS_COMPILE）strip
export AS AR CC CPP LD NM OBJCOPY OBJDUMP RANLIB READELF
SIZE STRINGS STRIP
# Build settings
CFLAGS = -O2 -Wall -fno-short-enums
HEADER_OPS = -I$（BIONIC_LIBC）/arch-arm/include
-I$（BIONIC_LIBC）/kernel/common
-I$（BIONIC_LIBC）/kernel/arch-arm
LDFLAGS = -nostdlib -Wl,-dynamic-linker,/system/bin/linker
$（PRODUCT_OUT）/obj/lib/crtbegin_dynamic.o
$（PRODUCT_OUT）/obj/lib/crtend_android.o
-L$（PRODUCT_OUT）/obj/lib -lc -ldl
# Installation variables
EXEC_NAME = example-app
INSTALL = install
INSTALL_DIR = $（PRODUCT_OUT）/system/bin
# Files needed for the build
OBJS = example-app.o
# Make rules
all: example-app
.c.o:
$（CC） $（CFLAGS） $（HEADER_OPS） -c {1}lt;
example-app: ${OBJS}
$（CC） -o $（EXEC_NAME） ${OBJS} $（LDFLAGS）
install: example-app
test -d $（INSTALL_DIR） || $（INSTALL） -d -m 755 $（INSTALL_DIR）
$（INSTALL） -m 755 $（EXEC_NAME） $（INSTALL_DIR）
clean:
rm -f *.o $（EXEC_NAME） core
distclean:
rm -f *~
rm -f *.o $（EXEC_NAME） core
如何增加一個新的設備
[plain] view plain $ cd ~/android/aosp-2.3.x
$ . build/envsetup.sh
$ mkdir -p device/acme/coyotepad
$ cd device/acme/coyotepad
進入AndroidProcts.mk
PRODUCT_MAKEFILES :=
$（LOCAL_DIR）/full_coyotepad.mk
對於full_coyotepad.mk
$（call inherit-proct, $（SRC_TARGET_DIR）/proct/languages_full.mk）
$（call inherit-proct, $（SRC_TARGET_DIR）/proct/full.mk）
DEVICE_PACKAGE_OVERLAYS :=
PRODUCT_PACKAGES +=
PRODUCT_COPY_FILES +=
PRODUCT_NAME := full_coyotepad
PRODUCT_DEVICE := coyotepad
PRODUCT_MODEL := Full Android on CoyotePad, meep-meep
在BoardConfig.mk中
TARGET_NO_KERNEL := true
TARGET_NO_BOOTLOADER := true
TARGET_CPU_ABI := armeabi
BOARD_USES_GENERIC_AUDIO := true
USE_CAMERA_STUB := true
打開vendorsetup.sh
add_lunch_combo full_coyotepad-eng
#p#副標題#e#

㈡ APP被攻擊導致數據篡改泄露如何滲透測試漏洞與修復解決

APP滲透測試目前包含了Android端+IOS端的漏洞檢測與安全測試，前段時間某金融客戶的APP被黑客惡意攻擊，導致APP里的用戶數據包括平台里的賬號，密碼，手機號，姓名都被信息泄露，通過老客戶的介紹找到我們SINE安全公司尋求安全防護上的技術支持，防止後期APP被攻擊以及數據篡改泄露等安全問題的發生。針對於客戶發生的網站被黑客攻擊以及用戶資料泄露的情況，我們立即成立了SINE安全移動端APP應急響應小組，關於APP滲透測試的內容以及如何解決的問題我們做了匯總，通過這篇文章來分享給大家。

首先要了解客戶的情況，知彼知己百戰不殆，客戶APP架構開發是Web（php語言）+VUE框架，伺服器採用的是Linuxcentos系統，資料庫與WEBAPP端分離，通過內網進行傳輸，大部分金融以及虛擬幣客戶都是採用此架構，有的是RDS資料庫，也基本都是內網傳輸，杜絕與前端的連接，防止數據被盜，但是如果前端伺服器（APP）存在漏洞導致被黑客攻擊，那麼攻擊者很有可能利用該伺服器的許可權去遠程連接資料庫端，導致數據泄露，用戶信息被盜取的可能。

然後對客戶伺服器里的APP代碼，以及網站PHP源文件進行代碼的安全審計，以及網站木馬文件的檢測與清除，包括網站漏洞測試與挖掘，我們SINE安全都是人工進行代碼的安全審計與木馬檢查，下載了客戶代碼到本地電腦里進行操作，包括了APP的網站訪問日誌，以及APP的Android端+IOS端文件也下載了一份到手機里。我們在檢測到客戶APP里的充值功能這里存在SQL注入漏洞，因為本身網站選擇的是thinkphp框架二次開發的，程序員在寫功能的時候未對充值金額的數值進行安全判斷，導致可以遠程插入惡意的SQL注入代碼到伺服器後端進行操作，SQL注入漏洞可以查詢資料庫里的任何內容，也可以寫入，更改，通過配合日誌的查詢，我們發現該黑客直接讀取了APP後台的管理員賬號密碼，客戶使用的後台地址用的是二級域名，開頭是admin.XXXXX.com，導致攻擊者直接登錄後台。我們在後台的日誌也找到黑客的登錄訪問後台的日誌，通過溯源追蹤，黑客的IP是菲律賓的，還發現後台存在文件上傳功能，該功能的代碼我們SINE安全對其做了詳細的人工代碼安全審計與漏洞檢測，發現可以上傳任意文件格式漏洞，包括可以上傳PHP腳本木馬。

攻擊者進一步的上傳了已預謀好的webshell文件，對APP里的網站資料庫配置文件進行了查看，利用APP前端伺服器的許可權去連接了另外一台資料庫伺服器，導致資料庫里的內容全部被黑客打包導出，此次安全事件的根源問題才得以明了，我們SINE安全技術繼續對該金融客戶的APP網站代碼進行審計，總共發現4處漏洞，1，SQL注入漏洞，2，後台文件上傳漏洞。3，XSS跨站漏洞,4，越權查看其它用戶的銀行卡信息漏洞。以及APP前端里共人工審計出6個網站木馬後門文件，包含了PHP大馬，PHP一句話木馬，PHP加密，PHP遠程調用下載功能的代碼，mysql資料庫連接代碼，EVAL免殺馬等等。

我們SINE安全對SQL注入漏洞進行了修復，對get,post,cookies方式提交的參數值進行了安全過濾與效驗，限制惡意SQL注入代碼的輸入，對文件上傳漏洞進行修復，限制文件上傳的格式，以及後綴名，並做了文件格式白名單機制。對XSS跨站代碼做了轉義，像經常用到的<>script等等的攻擊字元做了攔截與轉義功能，當遇到以上惡意字元的時候自動轉義與攔截，防止前端提交到後台中去。對越權漏洞進行銀行卡查看的漏洞做了當前賬戶許可權所屬判斷，不允許跨層級的查看任意銀行卡信息，只能查看所屬賬戶下的銀行卡內容。對檢測出來的木馬後門文件進行了隔離與強制刪除，並對網站安全進行了防篡改部署，以及文件夾安全部署，伺服器底層的安全設置，埠安全策略，等等的一系列安全防護措施。

至此客戶APP滲透測試中發現的網站漏洞都已被我們SINE安全修復，並做了安全防護加固，用戶信息泄露的問題得以解決，問題既然發生了就得找到漏洞根源，對網站日誌進行溯源追蹤，網站漏洞進行安全測試，代碼進行安全審計，全方面的入手才能找出問題所在，如果您的APP也被攻擊存在漏洞，不知道該如何解決，修復漏洞，可以找專業的網站安全滲透測試公司來解決，國內SINESAFE，鷹盾安全，綠盟，啟明星辰，深信服都是比較專業的、也由衷的希望我們此次的安全處理過的分享能夠幫到更多的人，網路安全了，我們才能放心的去運營APP。

㈢ linux下怎麼樣重命名文件

這兩天在使用Ubuntu系統上進行開發軟體的安裝，一直遇到創建的Android
Studio圖標無法使用的問題，創建的圖標提示「應用程序啟動錯誤」。在網上也找了很多文章，都是說文件夾中包含空格。但是文件路徑確實沒包含空格，但是包含-，即"android-studio"，所以准備重命名進行嘗試，但是遇到"bareword
not
allowed"的問題。
Linux下對文件重命名有兩種命令：
mv
，rename
mv很簡單，move文件移動
mv
/dir/file1
/dir2/file1
兩個參數，第一個是源文件，第二個是目的地，如果第二個參數文件名不一樣，則會重命名。
當兩個參數不帶目錄，只有文件名時，那就是重命名了。這是單個文件的重命名。
rename
arg1
arg2
arg3
rename才是真正的批量重命名命令。而且他是3個參數，不是2個。
arg1：舊的字元串
arg2：新的字元串
arg3：匹配要重命名的文件，可以使用3種通配符，*、?、[char]，*表示任意多個字元，?表示單個字元，[char]匹配char單個自定的精確字元，可以填寫任意字元，foo[a]*表示只匹配fooa開頭的文件名，如果一個文件是foobcc.txt，是不會被匹配的。
值的注意的是，此命令在不同的Linux版本也有不同，Debian一系的操作系統別有用法。舉例說明：
比如/home下有兩個文件
abbcc.txt,
addbb.txt
,
a.txt
我想把a替換為xxx，命令是這樣的
：
rename
「a」
「xxx」
*.txt
那麼它會首先去匹配有哪些文件需要修改，這里凡是.txt後綴的文件都會被匹配，如果改成?.txt則只會匹配到一個文件，那就是a.txt。然後把匹配到的文件中的a字元替換為xxx，注意測試時abab.txt這樣的，只會替換第一個a，有待再了解。
說到Debian一系的操作系統，比如Ubuntu，這個命令這樣使用是不對的，報錯，向下面這樣的：
Bareword
「a」
not
allowed
while
「strict
subs」
in
use
at
(eval
1)
line
1.
經過Google之後發現有這樣的說法：
On
Debian-based
distros
it
takes
a
perl
expression
and
a
list
of
files.
you
need
to
would
need
to
use:
rename
『s/foo/foox/』
*
這里是一個perl表達式，好理解點說就是綜合了前兩個參數為1個，這樣就只需要2個參數，而非上面所說的3個參數形式。
所以在Ubuntu下執行上面舉例的重命名時，命令是這樣的：rename
『s/a/xxx/』
*.txt