thái

(nên đọc nếu tiền làm bạn đau đầu :-D) mình thấy mình thiếu kiến thức nghiêm trọng, hay nói cách khác, cực kỳ ngu dốt, về chuyện quản lý tài chính cá nhân. đi làm 7 năm, làm *chuyên nghiệp* 5 năm, vậy mà nhìn lại tài chính thì rối tung, tài sản thì chỉ được mỗi mụn sách, còn đầu tư thì bỏ lỡ quá trời cơ hội. giá mà có ai đó nói cho mình biết việc quản lý tài chính này nó quan trọng đến cỡ nào thì có lẽ tình hình đã tốt hơn rất nhiều rồi. ít nhất là không bị mất ngủ vì cái sự ngu dốt của mình. thôi, bỏ qua. giờ biết mình ngu cũng chưa có muộn lắm. bắt đầu học lại vậy. ---- mình có lời khuyên cho các bạn đang muốn thấu chi (dành cho các bạn không làm ngân hàng: thấu chi là vay tiền ngân hàng, để có thể rút vượt quá số tiền còn lại trong tài khoản). mình nói hoài àh, giờ nhắc lại lần cuối: đừng bao giờ thấu chi! nếu mà mấy năm vừa rồi, các bạn vẫn sống được, thì không cần thấu chi, các bạn vẫn có thể sống tốt. kinh nghiệm thấu chi của mình đau đớn lắm nha. làm nguyên năm, đến cuối n...

Challenge 8 is a trivial format string bug, but one needs neat shellcode to get the flag. 1. Analysis First thing first: $ file t1g3rd t1g3rd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.15, dynamically linked (uses shared libs), not stripped t1g3rd is a regular network service that when executed would listen on port 7384. When a client comes in, the binary forks a new child process, and calls a function named handleClient . At the begining of handleClient , t1g3rd calls setrlimit(2) to disallow this child process to open new file or fork a new process. This makes the binary a perfect example to illustrate how to write neat shellcode using inlineegg :-D. handleClient then goes on to read two inputs, which are 19 bytes long and 512 bytes long respectively, from the client. The first input is sent back to the client using printf(3) , and the second is just discarded. 2. Vulnerability As one can guess, the printf(3) call at 0x08048c52 t...

Last week or so I joined CLGT to take part in HackJam 2009 by Sapheads. AFAIK this is the first CTF that Sapheads organizes, but they had done a very good job. To most people's surprise, the contest attacted quite a lot of teams from around the world, and it had quickly become an international competition. Did I tell you that we're the winner ? Ha ha ha this is our very first win since the name CLGT was born. BTW, HackJam 2009 was a success because Sapheads had kept their promise which is to "provide challenges that greatly resemble real world scenarios and environments, at the same time, adding fun and educational ingredients to them". We really had fun ^_^, not disturbing pains *_*, in solving the challenges. Thank you Sapheads! We're looking forward to HackJam 2010. I promised to some people in #sapheads that I would release some writeups about the challenges after the contest ended, and here they are. Sorry for the delay, I have been busy working with v...

Flickr's API Signature Forgery Vulnerability Thai Duong and Juliano Rizzo Date Published: Sep. 28, 2009 Advisory ID: MOCB-01 Advisory URL: http://netifera.com/research/flickr_api_signature_forgery.pdf Title: Flickr's API Signature Forgery Vulnerability Remotely Exploitable: Yes 1. Vulnerability Description Flickr is almost certainly the best online photo management and sharing application in the world. As of June 2009, it claims to host more than 3.6 billion images. In order to allow independent programmers to expand its services, Flickr offers a fairly comprehensive web-service API that allows programmers to create applications that can perform almost any function a user on the Flickr site can do. The Flickr's API consists of a set of callable methods, and some API endpoints. To perform an action using the Flickr's API, you need to select a calling convention, send a request to its endpoint specifying a method and some arguments, and will receive ...

Challenge 2 Challenge 2 is simple yet interesting. The initial target is a Python 2.2 byte-compiled file, so the first job is to decompile it to get the source code. Fortunately, decompyle just works: $ decompyle newbie.pyc Thu Aug 27 02:13:25 2009 # emacs-mode: -*- python-*- import urllib def some_cryption(arg): pass a = 'http://' dummy = 'http://korea' b = 'uxcpb.xe' b = b.encode('rot13') c = 'co.kr' cs = '.com' d = '/vfrp/uxuxux' dt = '/hackers' d = d.encode('rot13') dx = 'coolguys' ff = urllib.urlopen(((a + b) + d)) f_data = ff.read() file = open('hkhkhk', 'w') file.write(f_data) some_cryption(f_data) file.close() You can see that the purpose of this script is to download some data from a fixed URL, and save them to a file named hkhkhk . We ran the script, and it indeed downloaded this file . As the script suggests, the content of hkhkhk is encrypted by some cipher. Opening hkhkh...

This post is about challenge 8 which made gamma95 and I feel so lost when it comes to web hacking. Challenge 8 (not accessible atm) is the only web hacking challenge in WOWHacker's CTF. In hindsight it's not very difficult, but in fact it took us almost 1 day to solve it. This is a classic PHP local file inclusion attack. If you set the parameter ty and the cookie 71860c77c6745379b0d44304d66b6a13 to the same file name, the vulnerable PHP script in challenge 8 would try to include that file. Here's what the code looks like: $ty = $_GET["ty"]; $page = $_COOKIE[" 71860c77c6745379b0d44304d66b6a13 "]; if ($ty != $page) { echo "Error!"; } else { if (include($ty) != 'OK') { echo "Can't find that page!"; } } Update : gamma95 has just noticed me this challenge may not be a PHP local file inclusion attack. Maybe it's just a vulnerable readfile call like this: $ty = $_GET["ty"]; $page = $_COOKI...