Monthly Archives: January 2014

Development note

Tint transparent images on iOS

Leave a comment

Recently, I encountered a problem that I need to change the color of non-transparent pixels in an image with a transparent background without affecting much the original quality (at least not draw with hard edges). Therefore I did some searches on Google and found the following solution (credit at the end). The following solution does not care about the luminosity of the image.

CGImageRef image;

CGContextSetBlendMode(context, kCGBlendModeNormal);
[tintColor setFill];
CGContextFillRect(context, rect);

CGContextSetBlendMode(context, kCGBlendModeDestinationIn);
CGContextDrawImage(context, rect, image);

or exchange the steps,

CGImageRef image;

CGContextSetBlendMode(context, kCGBlendModeNormal);
CGContextDrawImage(context, rect, image);

CGContextSetBlendMode(context, kCGBlendModeSourceIn);
[tintColor setFill];
CGContextFillRect(context, rect);

For more details or other solutions, please refer to the link in credit below.
Credit: http://stackoverflow.com/questions/3514066/how-to-tint-a-transparent-png-image-in-iphone

Security research

[Facebook] Reveal information from any post, photo, page or group

Leave a comment

This vulnerability enables anyone to get some basic information (mainly just name, and uploader/author’s ID for photos and posts with a specific condition) from any post, photo, page or group regardless of its privacy setting, or type (published state for pages / visibility for groups).

All these information results from the dialog title and full URL for a given Facebook object (e.g. a post or photo) in an AJAX script at https://www.facebook.com/ajax/pages/show_tab_permalink.php?page_id=...&app_id=...&__a. Originally, the script is for page admin to get the full URL for an app installed in a page. The script takes two essential parameters, page_id and app_id, which apparently indicate the IDs for a page and an app. The HTML content in the response is a dialog with a title (“Link to the A for B”, with A for the app name and B for the page name) and a full absolute URL for the app in the page.

Perhaps, if you are a hacker like me, you would immediately try an ID of an unpublished page and app in sandbox mode. Luckily, it works. It reveals nothing more than the name and the page address of the page and app regardless of their type and visibility. In the first place, I reported this to Facebook and waited for their reply.

At that time, I had underestimated the vulnerability; afterward I kept trying plugging in different ID to the URL. Surprisingly, the page_id parameter name is totally misleading because it accepts other Facebook objects as well. Here comes to the conclusion of the possibilities of page_id value and the result.

1. Page ID
Reveal the name of a page regardless of its published state and whether you are an admin of the page or not.

2. Group ID
Reveal the name of a group regardless of its visibility state (secret group) and whether you are in the group or not.

3. Photo ID (fbid in photo URL)
Reveal the uploader’s ID of a photo regardless of its privacy setting as long as it is not deleted.

Practical usage: When you get a Facebook static image URL (the one starting with “fbcdn-sphotos” and ending with “.jpg“), you could extract the fbid from it. The full URL of a photo reveals the album ID containing its uploader’s ID.

Uploader’s ID no longer presents in static photo URL since mid 2012.

4. Post ID (the post must share something, whatever URL or other’s post)
Reveal the author’s ID of a post that shares something regardless of its privacy setting.
For unknown reasons, the dialog title and content both contain the author’s ID.

The vulnerability is now fixed by only allowing IDs of published pages and apps not in sandbox.

21 Dec 2013 – Reported to Facebook
23 Dec 2013 – Acknowledgement of report
6 Jan 2014 – Sent POC video to Facebook
11 Jan 2014 – Vulnerability fixed