2010-08-30

2010-08-30 FaceBook App "disappeared" or "Publishing Feed Stories disabled" collection

Collection from
FaceBook Developer Forum
( http://forum.developers.facebook.net/ ) about
App "disappeared" or "Publishing Feed Stories disabled"


2009-03-31
ERROR 200: Feed story publishing is disabled for this application

2009-11-29
Facebook Restrictions??

2010-01-09
I restricted :S

2010-03-12
My Application disappeared P1 P2 P3 P4

2010-04-16
Publishing Feed Stories disabled

2010-05-17
My App Disappeared

2010-06-06
Publishing Feed Stories disabled

2010-06-22
please help me my app disappeared

2010-07-25
All my applications disappeared

2010-08-20
App Deleted (Need Urgent Help)

2010-08-06
Publishing Feed Stories disabled

2010-08-23
Application Love is.. Fans has been disabled! Why?

2010-08-24
abusive application

2010-08-27
Publishing Feed Stories disabled after using fb:comments

2010-08-27
Publishing Feed Stories disabled

2010-08-30
active app mysteriously disappeared

For every FaceBook Application Developers:
Be careful!!

The FaceBook automated systems for abusing identify are very ruthless,
and may not give you any warning or notice before they do that!!
Who will be next??











2010-08-20

2010-08-20 Facebook 無預警移除 APP. e04!!

在FACEBOOK火熱的今天,軟體公司開發應用程式/社交遊戲放到FaceBook上增加曝光度及流量已經成為一門顯學了,但是有人碰過辛苦開發且經營了一段時間的APP被FaceBook毫無預警給幹掉嗎?

不要懷疑,還真有這種事,很不幸的我就遇到了。

我們處裡的是一款代理自韓國的FlashGame進行FACEBOOK的APP介接整合,基本功能也很單純,就是在FaceBook上開一個進入遊戲的入口,加上一些基本的社交功能(邀請好友/經使用者同意授權後於塗鴉牆發布遊戲訊息/好友的遊戲分數排名),實在也想不出有哪裡違反了FaceBook的使用條款。

在 2010-08-19 (四) 下午兩點二十分左右,我們有位同仁發現他的FB 帳號被FaceBook停權
畫面如下

得需要透過手機驗證過後重設密碼才能再次登入,非常的怪異。

結果設完後發現我們兩週前才上架的app消失了


此時發現問題大條了,結果交叉比對後發現跟這個APP有關連的四個管理帳號全被FaceBook停權。而將此四個帳號重設密碼解封之後發現原本的APP徹底消失,一點痕跡也不留。

由我們Server上的最後LOG時間判斷,問題是發生在 14:13 分,之後就沒有request進來了。

在查找過程中發現FaceBook幹的非常徹底,所有殘渣都沒有留下,包含APP URL頁面,APP粉絲頁面,USER的應用程式書籤,USER的應用程式權限設定等等所有跟該APP有關的部份全部都消失。

在評估過後決定先進行重建設定的工作 (原本APP上線十多天有六七千個User跟粉絲全沒了)
重建過程中發現 原本的Canvas Page URL 完全不給設定。會出現
Validation failed.
The Canvas Page URL you requested is not allowed.
而且確定不是重名,若是Canvas Page URL重複則會出現
Validation failed.
Unable to update Canvas Page URL: The Canvas Page URL you requested is already taken.

這情況非常詭異,因為原先的Canvas Page URL命名並沒有違反FACEBOOK的規範才對,建置完成後也提交給FaceBook並通過了( Directory Status: Approved ),同時也上線運作了十多天了。

根據上述情況推斷該APP是被FaceBook列入黑名單之中了,
由四個管理員帳號都被FB停權的狀況來看,APP肯定不是被我們自己人給誤刪,而是被FaceBook給刪掉了。至於FaceBook為何要把APP幹掉同時將所有管理員帳號停權就不得而知了,因為並沒有收到任何通知或警告。認知中我們APP應該也沒有違反FaceBook政策的部份,要是有人惡意舉報應該也要有夠多的數量才會讓FaceBook這樣幹才對。

最後無奈之下只好更改Canvas Page URL重新設定APP
新APP設定好之後程式中的
Application ID / API Key / Application Secret / Canvas URL 這些資料全都得要隨之更新

先前累積下來的數千個粉絲全部沒了,得要重新讓USER加入
而且因為Canvas Page & APP ID 都換掉了,所以所有網站及廣宣連結全得替換。
而先前公司已經在FaceBook投放了將近USD$1000的廣宣費用也都打水飄了


嘗試要尋找申訴管道找了很久,終於在FaceBook開發論壇中找到有其他人遭遇類似的問題
Facebook Platform Developer Forum / My Application disappeared:
這一整個討論串非常的有意思,事情是從今年三月開始發生的。
然後在第三頁中 3月19日 FaceBook管理者承認是有問題造成部份好的APP因為BUG被無預警誤殺並提供申訴取回


結果到了 3月31日有開發者回應說


從別人的經驗看來就算是通過申訴一兩週之後拿回來的也是個廢物了。

我昨天也在論壇回報後,得到的回覆是
===========================
Hello,
For issues like this, please refer to our Help Center FAQs on the issue: http://www.facebook.com/help/?faq=17553
Thanks,
===========================
可是那個FAQ link得要把語系換成英文才看的到,中文語系是連不到的

這也就算了
語系換成英文就看到了


Our automated systems routinely screen and disable bad applications. If your application has been disabled and your application followed all of the Developer Principles and Policies, fill out this form to initiate the appeals process. Please note that if we determine your application does not abide by our Developer Principles and Policies, it will not be reactivated. The decision may take one to two weeks. Thanks in advance for your cooperation.


結果說要去填一個form然後等一到兩週!那是不是這一兩個禮拜我的app都關門大吉了
就算真要等一到兩週也就算了,結果那個form 連結 http://www.facebook.com/help/contact.php?show_form=dev_name_appeal 還是壞的 .....

會跳回到Help Center頁面去

在該討論串最後有其他相同情況的app開發者留言說

這就是在裝笑為嘛!!

後來從論壇中找到一個
FaceBook Developer Help Contact Form
http://www.facebook.com/developers/developer_help.php
藏的真好,我是去填了資料,但是基本上我也不報任何期望了!!
就算等了一兩個禮拜拿回來以後又能幹嘛?

在沒有收到任何通知或警告的情況下整個APP就被FaceBook莫名其妙給幹掉了!
而且我還真想不出有哪裡違反FaceBook的Policy嚴重到必須要將四個該APP管理員都給停權停掉?

這慘痛的經驗提供各位FaceBook應用程式開發者作為借鏡。
~~靠山山倒啊靠人人跑啊~~

2010-08-20 16:00 update:
剛在 Facebook Platform Developer Forum / My Application disappeared: 這討論串中看到有人比我更慘

心情頓時舒坦了些 XD

另外要在抱怨一下,
Facebook Platform Developer Forum http://forum.developers.facebook.net/
Facebook Platform bug tracking system http://bugs.developers.facebook.net/
這論壇跟bug回報系統的帳號居然沒有跟FaceBook整合
也就是你要上開發者論壇問問題得要去註冊一個帳號,發現Bug要到Bugzilla回報又得在建立一個帳號。
從這可以看出FaceBook對於第三方應用程式開發者有多麼的不重視與不用心了。

2010-08-21 06:30 update:
FaceBook的人員為了APP消失的問題特別在開發論壇中開了一個置頂的公告串
Sticky: What to do if your application disappeared or was disabled


看來這問題最近嚴重到FaceBook不得不去面對了。

而那個FAQ裡面原本壞掉的APP申訴連結 http://www.facebook.com/help/contact.php?show_form=dev_disable_appeal 也總算可用了


填完表格送出後收到一封系統自動回覆的MAIL

需要一到兩週的時間,新的都設好了到時候舊的再拿回來也沒用,我主要也就想看看FaceBook到底會怎麼回答。

2010-08-23 update:
收到FaceBook的申訴回覆了,非常的制式

========================================
We appreciate your inquiry and we apologize for any inconvenience caused. Please note that we have automated systems in place to remove applications that are abusing our product, such as publishing excessively to the Stream, or receiving negative feedback from our users. Unfortunately, we will not be able to reinstate your application, as it was removed by our automated systems. We realize that it might be a challenge to start fresh, but when an application is disabled for violating our terms and policies it is completely removed from the site permanently.

Going forward, please make sure to keep our policies in mind, as this is important for your success on Facebook Platform and to ensure that you're bringing users a great experience with your application. We strive to make our policies as clear as possible, shaping them to best serve users and the entire Platform ecosystem. We hold our developers to a high standard and trust that they will use our communication channels in ways that promote fair growth across Platform.

If you would like to re-launch your application, please feel free to do so after you are certain that it meets our terms and policies, which you can find below. Thank you in advance for your cooperation.

Developer Principles and Policies: http://developers.facebook.com/policy/
Policy Examples and Explanations: http://developers.facebook.com/docs/guides/policy/examples_and_explanations
Developer Forum: http://forum.developers.facebook.com
Statement of Rights and Responsibilities: http://www.facebook.com/terms.php

Thanks,
Platform Policy Team
Facebook
========================================
簡單來說就是:
你的APP是被我們自動偵測系統給幹掉的,不要肖想我們會還給你了,至於你的APP為何會被幹掉?這一定是你違反了我們的政策,但是違反了哪條林北不告訴你 XD !!
你自己看著辦吧!!

2010-08-30 update:
我把FaceBook Developer Forum裡面關於APP被幹掉或是塗鴉牆功能被停用的苦主PO文靠夭的整理了一下
2010-08-30 FaceBook App "disappeared" or "Publishing Feed Stories disabled" collection
至於其他自認倒楣摸摸鼻子沒上去反應的有多少就不得而知了。

2010-05-15

2010-05-15 原來GOOGLE SPIDER是個好駭客

在上週末(2010-05-09)曝光的網站漏洞
2010-05-09 取得個人資料何需Foxy. 一個爛網站就能讓你脫光光
今天看了下,居然在頁面上寫著
由於本網站受駭客入侵, 為免網友受進一步波及, 現緊急關閉本網站,並探究有效預防措施, 確認問題解決後再行開放, 做成網友不便及權益受損, 在此謹致上最大歉意!


看到這裡我又暈了,原來GOOGLE SPIDER也算駭客啊.看來還是搞不清楚問題在哪裡?

上一篇中我已經很客氣的把網站URL/名稱都蓋掉不直接SHOW出來,結果並沒有讓管理者/開發者有任何反省...

到現在(2010-05-15)事件曝光已經整整六天了,那些個資現在依然保留在GOOGLE上面.用特定關鍵字 依舊可以搜出那些會員的姓名生日電話地址..
在上一篇最前面都寫上了..
如果發現自己的個資被GOOGLE抓到了,請參閱 如何移除Google搜尋結果中「危害隱私」的 Cache暫存資料?

連怎麼移除掉已外洩被GOOGLE抓到的資料方法都說了,還不去處裡?
相比之下去年戰國策所發生的事件處裡上還稍微好一點點,起碼曝光之後沒多久就請GOOGLE把那些CACHE給處裡掉了.

該網站的系統開發商(XX數位科技 )還搞不清楚問題在哪嗎?

既然如此就直接挑明說吧,在該開發商網站上列出的相關客戶網站CASE幾乎都有一模一樣的問題
也就是進入管理後台(/mag/ )的權限都是交由JAVASCRIPT來進行判斷.這樣的如果還搞不清楚怎麼補洞的話...那只能好自為之了.

管理者/開發者不去檢討這些資料為什麼會被GOOGLE SPIDER給爬出來,難道把問題都推給駭客就沒事了嗎?
照這個邏輯下來,GOOGLE就是世界上最厲害的駭客了.

2010-05-09

2010-05-09 取得個人資料何需Foxy. 一個爛網站就能讓你脫光光

2010-05-09 22:20 補充在前面
建議大家可以設定 Google 快訊來追蹤自己的一些個人隱私資料(姓名/身分證號/電話/地址/信用卡號......等等)是否有被暴露在網路上.
雖然Google 快訊只能做到事後通知,但起碼會比什麼都不知道來的強. 早點發現可以早點處理...
如果發現自己的個資被GOOGLE抓到了,請參閱 如何移除Google搜尋結果中「危害隱私」的Cache暫存資料?

2010-05-15 補充:
被GOOGLE CACHE住的個資依舊還在... 原來GOOGLE SPIDER是個好駭客
唉......
==============================================================================
今天看到一則新聞

用foxy盜個資 網購盜刷百萬元

刷爆近百人信用卡
警方調查,嫌疑人黃廉恩(27歲,有竊盜、詐欺等前科),擔任資訊業某公司遊戲管理員,涉嫌自97年6月起,利用下載foxy資源分享軟體,網路搜尋信用卡持有人,盜走存放電腦裡個人資料,取得信用卡號及檢核碼。

一時手癢用嫌疑人名字上GOOGLE搜了一下
結果又發現一個後台管理系統被GOOGLE給爬進去了 XD


既然知道該管理後台的URL,就可以用 site: 參數來鎖定目標向GOOGLE大神查詢
啊咧,又是兩千多筆啊


隨便按一筆進去,結果跳出一個Javascript的alert 無權限,請重新登入

可是如果用NoScript這個FireFox的Plug-In來把Javascript檔掉,就可以一覽無遺了




而且不光是看個資,整個後台任何操作都通行無阻

這網站管理後台雖然在最前面有做帳號密碼登入,
但是後面所有判斷完全交由前端的JavaScript來處裡,
因為他所謂的權限系統判定,只是在ASP產出的頁面前面插上這段
< language="JAVASCRIPT">
alert("無權限,請重新登入")
history.go(-1);
< / script >
不過不管是該出來還不該出來的其他資料全都老老實實的SHOW在底下..

這樣的網站管理後台也算是個極品了.

從GOOGLE CACHE頁面的紀錄來看,這些紀錄起碼存在GOOGLE上面超過20天了.


再來看看加入這個網站的會員條款


註冊會員時,必須確實填寫基本資料,告知真實姓名、電子郵件地址與相關資料等。

所有由會員提供的個人資料,均視為機密,在未經會員同意前,XXXX網站保證絕不將個人資料,洩露給XXXX網站以外之第三者。


囧rz... 以後你還敢隨便在網上確實填寫個人資料嗎???

相關網站資料因為程式缺陷或是管理疏失而被搜尋引擎抓出來外洩的案例已經夠多了,老實說也不差這一個啦!!

所以說要取得個人資料何需Foxy. 一個爛網站就能讓你脫光光

P.S. 一些較為敏感且與新聞中嫌疑犯無關的個人資料在截圖上已先模糊處裡了,但是有概念的人隨便一搜還是搜的出來,那些都是完全被曝露在網路上的公開資料

最後再低調補一刀 XD
直接把管理者原密碼噴到前端來~超帥氣的啦!!!

2010-04-14

2010-04-14 POST Base64 encoding data to Coldfusion

這幾天遇到一個詭異的問題,程式環境是前端FLASH(AS3)後端是Coldfusion.
需求是前端AS3產生FLASH畫面ScreenShot的BitmapData透過JPGEncoder轉換之後直接將binary data POST到後端接收.
一般情況下採用 Adobe Forums: uploading bitmapData to ColdFusion 這作法是OK的.

不過在一些特殊環境之下遇到了資料傳輸被中斷問題,經過測試發現是前端POST送出的binary data在某些情況下會被Client Side某些寫的不嚴謹的防火牆誤判,
導致觸發filter產生connection reset造成數據傳輸被強制中斷.

為了解決這問題經測試後決定先用Base64編碼將binary data轉為String後再POST出去,後端接收到以後再作Base64 Decode的動作還原回JPG圖檔.這樣雖然傳輸的數據量變大了,但是原則上應該可以避免被防火牆誤判.

結果前後端改過之後測試又發現新的問題,在某些時候後端Coldfusion會噴出 500 Server Error.

ROOT CAUSE:
java.lang.IllegalArgumentException
at coldfusion.filter.FormScope.parseQueryString(FormScope.java:355)
at coldfusion.filter.FormScope.parsePostData(FormScope.java:327)
at coldfusion.filter.FormScope.fillForm(FormScope.java:277)
at coldfusion.filter.FusionContext.SymTab_initForRequest(FusionContext.java:438)
at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:33)
at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
at coldfusion.filter.RequestThrottleFilter.invoke(RequestThrottleFilter.java:126)
at coldfusion.CfmServlet.service(CfmServlet.java:175)
at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
at jrun.servlet.FilterChain.service(FilterChain.java:101)
at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)
at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286)
at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)
at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)
at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:320)
at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)
at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:266)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)


花了時間測試查找才確定原因是因為Base64的可用字元與傳輸所用的 Content-Type: application/x-www-form-urlencoded 定義的保留字有所衝突.



Base64中有用到的 / = + 在 x-www-form-urlencoded 定義中是保留字元,
像下圖的情況,當POST DATA中出現兩個連續的 // 時,Coldfusion就噴500了.





解決方式有兩種.
1.前端AS3在Base64轉換完以後再作一次URLEncode的動作,把Base64Encode之後String內的 / + = 轉成 %2F %2B %3D ,後端收到之後再做URLDecode來還原後再Base64Decode,不過這樣傳輸的DATA又變更肥了.
2.前端AS3在傳Base64Encode的STRING時,把Http Header的Content-Type改為 application/octet-stream 來避開Coldfusion對於x-www-form-urlencoded的內容格式判斷

最後決定採行第二種方式,由前端AS3修改上傳時HTTP Header的Content-Type為application/octet-stream去避免後端Coldfusion自動進行格式判斷


目前測試觀察下來Coldfusion就不會再吐500了 .

2009-12-21

2009-12-21 Plurk 訊息量統計

這是延續之前所做的統計
2009-05-12 Plurk訊息成長量週統計
2009-11-06 Plurk 訊息量統計

首先是每日plurks數統計
由2009-5-10 ~2009-12-20的曲線圖

由整體趨勢來看很明顯的每日新增Plurks數成長出現停滯

以下是每小時plurks的週統計
2009-11-01 ~ 2009-11-08

當週平均每小時新增了 30,069則plurks & 125,627則回應
其中紅色橢圓型標出的時間區間是 2009-11-05 17:00~18:00 剛好當時台灣發生地震 (2009-11-05 17:33 震央南投6級)

2009-11-08 ~ 2009-11-15

當週平均每小時新增了 29,598則plurks & 122,581則回應

2009-11-15 ~ 2009-11-22

當週平均每小時新增了 29,363則plurks & 119,641則回應

2009-11-22 ~ 2009-11-29

當週平均每小時新增了 29,814則plurks & 125,022則回應

2009-11-29 ~2009-12-06

當週平均每小時新增了 29,924則plurks & 123,942則回應

2009-12-06 ~ 2009-12-13

當週平均每小時新增了 29,794則plurks & 118,111則回應

2009-12-13 ~ 2009-12-20

當週平均每小時新增了 30,628則plurks & 130,525則回應
其中在2009-12-17 15:00~17:00之間plurk有卡住的情況所以新增資料數少很多
而在 2009-12-19 21:00~22:00 (右側紅圓框標註)因為台灣發生地震(2009-12-19 21:02 震央花蓮) ,所以新增資料數突然倍增,
原本週六日plurks / responds 數與週一到週五比起來就明顯偏少,不過12-19這場地震把大家都震出來了 XD
當時的詳細數字
(其實Twitter上當時也是一樣有不少地震相關訊息,只是Twitter台灣用戶以全球來說屬於少數,也比較沒有這麼明顯的數據可抓取計算)

總結下來個人歸納出兩點無責任推論XD :
1.Plurk整體的成長已經出現平緩甚至是停滯
(而且估計現有的那些新增訊息數/回應數中有一定比例是由機器人貢獻的)
2.只要台灣發生地震網民就都忙著上網發推發噗

2009-11-06

2009-11-06 Plurk 訊息量統計

這篇是延續之前所做的統計
2009-05-12 Plurk訊息成長量週統計

在五月之後我讓每小時整點定位蒐集PLURK_ID資料的BOT持續運作,
直到八月中隨著我不玩PLURK而將它停掉.
接著在十月底因為手癢又重新啟動整點定位的BOT.
由下圖可以看出由五月到十一月的整體數據趨勢
(這張是以每日新增的獨立訊息數量統計所畫出的原始數據圖)
(點此看完整大圖)


對比五月初所做的統計:工作日一天約有35萬、週休假日一天約有29萬則新訊息
現在十一月初則是整整增加一倍 一天約有65萬~70萬 則新訊息
不過以個人感覺來說,雖然PLURK整體成長速度很快,但是現在的人味卻變淡了許多..
一堆機器人保卡馬? 機器人算命點歌配對問問題發廣告的~ 如果扣掉這些非人的資料之後還剩多少?我是挺懷疑的.

另外由下圖我所標上的粗紅線來看,
雖然中間8月到10月的資料有一大段空窗,但是由整體走勢來看,
基本上PLURK每日新增的獨立訊息數量成長在8月之後已經開始趨緩
(點此看完整大圖)




接下來是10-31~11-06之間的分時統計,
這裡加上了回應數的資料
也就是除了每則獨立PLURK會有個PLURK_ID之外,在PLURK中每個回應也會有一個流水號ID.
當發出一個回應後SERVER回覆的JSON資料如下
{"object": {"lang": "tr_ch", "content_raw": "\u81ea\u52d5\u56de\u61c9@Sat Oct 31
06:00:01 CST 2009", "user_id": 5001267, "qualifier": "says", "plurk_id": 148308
338, "content": "\u81ea\u52d5\u56de\u61c9@Sat Oct 31 06:00:01 CST 2009", "id": 6
78336137, "posted": new Date("Fri, 30 Oct 2009 22:00:02 GMT")}, "last_ts": 0}

由裡面可以看到"id": 678336137 這就是此則回應的ID流水號.

下圖中的藍線是每小時回應數的增量統計
綠色區塊是每小時單筆PLURK數的增量統計
(點此看完整大圖)


可以看出 PLURK回應數與訊息數是呈現正相關且等比增加,
而且目前看來跟之前2009-05-12 Plurk訊息成長量週統計所得到的結果一樣,
還是符合東亞時區的作息時間
另外根據所抓到的數據,
最多每小時有 58,413 個新Plurk 269,826 個回應
平均則是每小時有 29,372 個新Plurk 122,991 個回應
換算下來就是平均 8.16 Plurk/秒 & 34.16回應/秒

而且這份統計還有個特別的地方
就是在2009-11-05 17:00~18:00 這一個小時的PLURK數/回應數突然拉高..(下圖紅框標出的部份)
對照當時剛好是台灣發生地震(17:33)
(點此看完整大圖)


下面附上這段時間(2009-10-31 14:00:00~2009-11-06 20:00:00)所得到的詳細PLURK_ID/RESPOND_ID資料

時間Plurk_IDResond_ID
2009-10-31 03:00:00148396314678250803
2009-10-31 04:00:00148406948678287527
2009-10-31 05:00:00148415503678313572
2009-10-31 06:00:00148423613678336137
2009-10-31 07:00:00148433324678363271
2009-10-31 08:00:00148446554678399230
2009-10-31 09:00:00148465157678452574
2009-10-31 10:00:00148487722678527261
2009-10-31 11:00:00148513535678615117
2009-10-31 12:00:00148542747678716640
2009-10-31 13:00:00148571210678811843
2009-10-31 14:00:00148600426678911765
2009-10-31 15:00:00148628675679010575
2009-10-31 16:00:00148656331679104570
2009-10-31 17:00:00148683910679200017
2009-10-31 18:00:00148713443679298748
2009-10-31 19:00:00148743587679398760
2009-10-31 20:00:00148776171679514139
2009-10-31 21:00:00148813080679663499
2009-10-31 22:00:00148853546679841230
2009-10-31 23:00:00148897964680046399
2009-11-01 00:00:00148943561680263840
2009-11-01 01:00:00148984763680459970
2009-11-01 02:00:00149012976680584802
2009-11-01 03:00:00149031196680652370
2009-11-01 04:00:00149042504680687400
2009-11-01 05:00:00149050725680711409
2009-11-01 06:00:00149058692680731360
2009-11-01 07:00:00149067968680754167
2009-11-01 08:00:00149080761680789008
2009-11-01 09:00:00149099353680844513
2009-11-01 10:00:00149123169680921074
2009-11-01 11:00:00149151104681021294
2009-11-01 12:00:00149181915681130390
2009-11-01 13:00:00149212271681239014
2009-11-01 14:00:00149242832681352458
2009-11-01 15:00:00149273170681460565
2009-11-01 16:00:00149302556681565483
2009-11-01 17:00:00149331766681667442
2009-11-01 18:00:00149361967681776773
2009-11-01 19:00:00149393874681891446
2009-11-01 20:00:00149429284682030651
2009-11-01 21:00:00149470631682213456
2009-11-01 22:00:00149517722682434982
2009-11-01 23:00:00149567176682675947
2009-11-02 00:00:00149614661682917133
2009-11-02 01:00:00149655324683112712
2009-11-02 02:00:00149680196683217294
2009-11-02 03:00:00149694979683270245
2009-11-02 04:00:00149704200683299943
2009-11-02 05:00:00149712402683321613
2009-11-02 06:00:00149719886683342289
2009-11-02 07:00:00149730435683371153
2009-11-02 08:00:00149745558683416411
2009-11-02 09:00:00149769983683504180
2009-11-02 10:00:00149803445683647350
2009-11-02 11:00:00149837102683802562
2009-11-02 12:00:00149871112683962274
2009-11-02 13:00:00149905330684106018
2009-11-02 14:00:00149938778684247008
2009-11-02 15:00:00149971519684388642
2009-11-02 16:00:00150004879684531715
2009-11-02 17:00:00150040511684685701
2009-11-02 18:00:00150078457684840502
2009-11-02 19:00:00150117479684987800
2009-11-02 20:00:00150157544685145184
2009-11-02 21:00:00150203766685346553
2009-11-02 22:00:00150254567685596553
2009-11-02 23:00:00150308466685848419
2009-11-03 00:00:00150359454686118245
2009-11-03 01:00:00150401351686322102
2009-11-03 02:00:00150425743686425015
2009-11-03 03:00:00150441070686478261
2009-11-03 04:00:00150450779686509866
2009-11-03 05:00:00150458936686535407
2009-11-03 06:00:00150467432686559441
2009-11-03 07:00:00150479372686590789
2009-11-03 08:00:00150495533686639043
2009-11-03 09:00:00150521617686735034
2009-11-03 10:00:00150555228686883128
2009-11-03 11:00:00150587886687040547
2009-11-03 12:00:00150619802687196900
2009-11-03 13:00:00150651432687334262
2009-11-03 14:00:00150682560687475496
2009-11-03 15:00:00150712405687612546
2009-11-03 16:00:00150743687687746236
2009-11-03 17:00:00150777504687893185
2009-11-03 18:00:00150814468688051288
2009-11-03 19:00:00150853753688200978
2009-11-03 20:00:00150894041688355264
2009-11-03 21:00:00150939379688549292
2009-11-03 22:00:00150989862688781825
2009-11-03 23:00:00151042880689042212
2009-11-04 01:00:00151133509689501444
2009-11-04 02:00:00151158082689608282
2009-11-04 03:00:00151173263689663682
2009-11-04 04:00:00151183082689698459
2009-11-04 05:00:00151191189689725285
2009-11-04 06:00:00151200089689751125
2009-11-04 07:00:00151211793689785297
2009-11-04 08:00:00151226753689836287
2009-11-04 09:00:00151250134689930293
2009-11-04 10:00:00151283768690081323
2009-11-04 11:00:00151315396690237877
2009-11-04 12:00:00151346870690396366
2009-11-04 13:00:00151377742690538471
2009-11-04 14:00:00151408115690679352
2009-11-04 15:00:00151437898690815405
2009-11-04 16:00:00151469152690951555
2009-11-04 17:00:00151502472691097836
2009-11-04 18:00:00151539632691252428
2009-11-04 19:00:00151577402691392956
2009-11-04 20:00:00151617811691551896
2009-11-04 21:00:00151663500691752005
2009-11-04 22:00:00151713216691981181
2009-11-04 23:00:00151765555692235561
2009-11-05 00:00:00151815674692493955
2009-11-05 01:00:00151857791692703525
2009-11-05 02:00:00151882872692815777
2009-11-05 03:00:00151897841692871616
2009-11-05 04:00:00151908648692904414
2009-11-05 05:00:00151917240692930850
2009-11-05 06:00:00151926100692956702
2009-11-05 07:00:00151938124692990868
2009-11-05 08:00:00151954506693044625
2009-11-05 09:00:00151979695693141235
2009-11-05 10:00:00152012977693294253
2009-11-05 11:00:00152045558693453784
2009-11-05 12:00:00152076567693610829
2009-11-05 13:00:00152109782693751471
2009-11-05 14:00:00152141938693894919
2009-11-05 15:00:00152171255694028888
2009-11-05 16:00:00152202547694162135
2009-11-05 17:00:00152235846694311190
2009-11-05 18:00:00152294259694511593
2009-11-05 19:00:00152335828694678395
2009-11-05 20:00:00152385175694856003
2009-11-05 21:00:00152430437695057233
2009-11-05 22:00:00152479893695288775
2009-11-06 00:00:00152585644695795655
2009-11-06 01:00:00152629571696019387
2009-11-06 02:00:00152656700696141577
2009-11-06 03:00:00152672901696204546
2009-11-06 04:00:00152683516696241177
2009-11-06 05:00:00152692668696268862
2009-11-06 06:00:00152701713696294902
2009-11-06 07:00:00152714421696332181
2009-11-06 08:00:00152730962696386044
2009-11-06 09:00:00152757010696486273
2009-11-06 10:00:00152790621696645372
2009-11-06 11:00:00152822587696801681
2009-11-06 12:00:00152854919696954465
2009-11-06 13:00:00152885630697082250
2009-11-06 14:00:00152916343697205947
2009-11-06 15:00:00152947592697340811
2009-11-06 16:00:00152979234697477657
2009-11-06 17:00:00153012796697622251
2009-11-06 18:00:00153049376697771304
2009-11-06 19:00:00153086594697905852
2009-11-06 20:00:00153125213698052301



另外在前一篇 不請自來的Plurk廣告機器人 裡面鞭過的 www.plurk-ad.com 機器人帳號 athena1021 雖然已經被PLRUK給關閉了,但是接下來那個鬼plurk-ad又有新玩法了
(這個 www.plurk-ad.com 跟被Alvin Woon直接點名的卡馬救星 plurk.hasaowall.com 其實是系出同源.
而之前那個"敗家女孩"被Plurk官方Block掉之後又借屍還魂了,從 http://plurk.hasaowall.com/plurkre/showpd.php 這支程式跳轉過去的Plurk帳號就知道了,只是還沒開始發作而已)
這是JacquesCh 在11-03 00:00這噗底下 留下的廣告訊息
水分子保濕霜 使肌膚更加水嫩明亮
廣告連結是 http://www.plurk-ad.com/plurkre/610328


這是dallas_cowboys 在11-03 17:00這噗底下 留下的廣告訊息
白雪公主魔法棒 淡化斑點,提升肌膚明亮度
廣告連結是 http://www.plurk-ad.com/plurkre/877419

而這兩個帳號PLURK數都是0,回應數都是100多


看來為避免特定ID被封鎖,PLURK-AD已經開始嘗試改用大量免洗帳號打游擊了.
看這PLRUK帳號搜尋頁 http://www.plurk.com/user_search?q=Orem%2C+UT%2C+United+States&gender=all&age=all&sort=num_of_followers#page8 還有後面幾頁裡面有好幾個帳號的情況就可以推出來了,
EX: Kevinmclaughlin RichmondHigh ReelectJon Vicki_Elsa Gordon_Browns serena_williams kathy_griffin alicia_keys 這幾個
都是10月創的帳號,PLURK數0回應數在一百上下
這樣就算有熱心網友提供黑名單封鎖工具也是防不勝防啊~~

啊這位去年曾經山寨人家原版正妹牆搞出個強力正妹牆然後四處打廣告暱稱用"海角七號"的老兄!!
你真的那麼缺錢嗎?????


後記: 有某位高人透漏,這個正妹牆強力版[有 正妹帶回家/★打槍換新貨★ 功能的](grils.hasaowall.com ServerIP:74.220.215.84) 與 卡馬救星(plurk.hasaowall.com ServerIP:74.220.215.84) & 噗浪廣告 (www.plurk-ad.com ServerIP:74.220.215.84)好像跟某位知名人士有關 ,
由GOOGLE搜尋 正妹牆強力版 似乎可看到一些線索.

至於到底是不是? 那就請諸位看官自行評斷~

2009-07-22

2009-07-22 杭州日全蝕體驗

2009-07-22 上午在中國長江流域發生日全蝕
目前剛好在杭州工作,也就順便利用這個機會來體驗一下整個日全蝕的過程。
根據Google的資料

当前观测点位于杭州,可观测日全食
食象 (ΔT=66.2s)北京时间高度角方位角PV
初亏08:21:24.9+38.8°087.4°287°12.2
食既09:34:13.0+54.5°097.3°132°05.4
食甚09:36:53.5+55.0°097.7°019°09.2
生光09:39:35.1+55.6°098.2°266°13.0
复圆10:59:20.0+72.0°119.8°111°06.5
其他日食参数
全日食延:5分22.1秒本影深度:60.1%
食分:100.00%星等(食甚):1.02299

由於缺乏專業的攝影器材及鏡頭,拿一般的相機/攝影機拍日蝕效果也很差(拍出來的太陽跟芝麻差不多大),所以就直接放棄拍太陽了(要看日蝕太陽照片的話網上隨便一搜都是一堆專業照片)。

這邊就決定拿web cam拍辦公室窗外天色由亮變暗再變亮的街景。

以下是2009-07-22 個人在杭州實際經歷的日蝕文字過程記錄:
08:10 從住處出發步行前往辦公室,一出門就看到天上都是雲,陰天..太陽只能從雲縫中看到。
08:25 走在從杭州住處到辦公室的路上,路上已經看到有人拿著遮光板看太陽,此時雲層轉薄,以肉眼觀測可見到太陽,不過光用肉眼還沒法看到陰影。
08:40 抵達辦公室,開始準備把web cam架起來利用 justin.tv 進行拍攝及記錄。
09:00 開始拍攝杭州街景。
09:15 杭州天空開始慢慢轉暗(跟黃昏時差不多),太陽大概被遮蓋了一半左右。
09:20 杭州街燈開始點亮,外面氣溫明顯感覺降低。
09:25 街上抬頭看天空的人群越來越多,路上汽車基本上都開車燈了。
09:33 天色越來越黑,變暗的速度很快,就跟有人把燈關了一樣。
09:34 天空完全變黑,跟夜晚一樣,街上傳來陣陣歡呼聲
09:39 全蝕結束,天空開始慢慢轉亮,這時候街上再度傳來歡呼聲。
09:50 基本上天色已經恢復到正常的狀態。

以下是由杭州辦公室往窗外拍攝的影片片段,時間區間為09:31~09:43

Watch live video from wiselysong's channel on Justin.tv注:影片在2:29秒的時候 [時間點是09:33:29到09:34:36]因為網路傳輸中斷而發生跳鏡的情況.所以有瞬間變黑的情況,第二個斷點是在影片的 4:40" 當時的時間點是09:36:47-09:38:26
完整拍攝記錄可到 http://zh-tw.justin.tv/wiselysong/archive 去指定時間日期(2009-07-22 09:30 AM)來觀看

2009-07-05

2009-07-05 無線WEP加密法有多虛弱?

無線WEP加密法有多虛弱? 答案是~~非常弱~~

之前就有看過資料知道無線網路的WEP加密是可以破解的,不過一直沒去驗證到底有多好破解.

這次趁著新住處的ADSL還沒牽好之前的周末因為沒網路在家很無聊,就來實際嘗試操作一下看看WEP到底有多好破解.

上GOOGLE稍微做了下功課之後很快的就選擇了一個較多網路資源的軟體(軟體名稱在這就不公開,因為實在是太簡單易用了,不過隨便搜都搜的到就是了)
而且這玩意在Ubuntu上面已有被納入到官方APT中,只要使用的無線網卡有支援無需自行編譯直接用APT裝上就能用,大大的降低了門檻.

很幸運的我有張USB的無線網卡有支援,直接拿來就能用,
首先讓無線網卡進入 promiscuous mode 來監聽蒐集封包.
以下就把過程截圖紀錄下來 (敏感資訊已經加上薄碼了)

先看下我周圍有哪些AP


聽了一陣子之後選擇要鎖定的目標AP,基本上以訊號強度夠,而且擷取到的有效封包夠多為首要考量,依據這個原則我先挑選第三個AP來做實驗,它是採用WEP加密的AP,而且在監聽的過程中持續有被使用的封包被抓到


再來就是鎖定這個AP的MAC來蒐集可供破解的封包,這是個比較花時間的過程,必須視該AP的被使用狀況來決定需要多少時間,我這邊是在花了大約四個小時蒐集到五千多個可用封包後成功的


把蒐集到的五千多個封包用程式去計算出WEP KEY


很幸運的就這麼給算出來了,用我的Celeron 1.8的NoteBook也只花了5秒


整個過程中比較花時間的是搜集可供計算比對的封包的過程,如果是在使用率高的AP上的話這個時間基本上可以縮短.
(其實還有比較機車的玩法是去主動送出連線封包,不過因為有點太暴力所以就不試了XD)

由這實例可以知道WEP果然是非常貧弱的加密法,根據該軟體的文件WPA/WPA2基本上也是可以被它破解出來的.

這次的實驗只是為了證明WEP加密有多麼的貧弱.
個人對於WEP加密法並沒有太深入的研究,具體是怎麼處裡也不甚了解,只是很單純的抓現成的程式稍微看一下說明文件後直接拿來用就成功破解了,連我這外行人都能輕易搞定,正在使用無線網路的你還敢掉以輕心嗎?

或許有些人的想法是我家裡的AP讓別人用又沒差,只要不要佔用過多的頻寬影響到我正常上網就好了,基本上這是非常沒有sense的說法,一但你的AP被閒雜人等利用了,他就可以把你的IP當作一個出口的跳板來幹壞事(EX:發恐嚇信給馬囧/小英 or anyone,盜用他人網路銀行帳號,上傳色情圖片到討論區...etc. 可以幹的壞事族繁不及備载[然後就等著被宰]),等到出事以後警察根據來源IP追查到你家時,你可是有理說不清的啊.

所以看到這裡趕緊檢查下自己的無線AP吧,如果你的AP只要WEP加密,建議馬上改成WPA/WPA2,同時在AP上設定可存取的MAC Address清單限制會稍微(注意...只是稍微)安全一些,當然直接插網路線不要用無線會更好一些.

因為無線網路的整個訊號是對外無限制散射的,所以在安全性上面是有他先天的缺陷的. 這篇主要著重在WEP有多麼容易被破解,沒有牽涉太多技術性的深入探討,只是作一個網路安全概念性的描述. 對這方面有興趣的朋友可以上網搜尋到更多相關有用的資料,在此就不多作贅述了.