Thoughts of a Cyber-LOONATic

Like many of my other possessions, I have always tried my best to preserve my mobile phones in proper condition ... at very least until I am willing to replace them.
As such, it's not surprising to me when I look back and recall how each of my phones had lasted me a good few years of service.

(and so starts my recollection of past phones, as I explain my way to my latest purchase)

Samsung D500 @ GSMArena.com

Samsung D500
The D500 was my first phone that was bought with the intention of "doing great things".
Back in the days, the D500 was known for its extensive list of features and functionality.
I remember clearly how I was exhilarated by the thought of 96MB of shared memory.
Although it lacked wifi, the D500 still came with bluetooth (v1.1) and infrared.
Samsung, known for their quality cameras, left D500 competitors in the dust by shipping the D500 with a 1.3MP camera! drool
Finally, the D500 supported MIDP 2.0 ... which ultimately convinced me that this was my (cellular) destiny.





Like in any relationship, there were a few ups-and-downs:

• The MIDP 2.0 implementation was half-baked and seemed to miss some crucial libraries required to do cool things
• I think I managed to find almost every GUI-related bug in the D500 which caused it to reboot (I also enjoyed the way the D500 would reboot and bypass the SIM PIN screen, such that it would appear as if nothing had occured)
• I had to search for the D500E firmware (released in another country) in order to flash my phone and be able to achieve EDGE speeds. While the speed improvement was not really noticeable, the functionality should have been included in the default firmware on my phone

All in all, the D500 did seem to be virtually bullet-proof since it had survived numerous incidents where other phones would probably snap into pieces.
The durable D500 lasted 3 years before I let her free to continue her journey with someone else.

FOSS = Free and Open Source Software.

Casually reading through my usual list of news websites, I stumbled across a link which led me to a recent post about Notepad++'s new website. It turns out that Notepad++ has moved hosting of their site due to SourceForge compiling with US law to deny access for some countries.

[side note: SourceForge's filtering started sometime in January. Clearly, I was enjoying my vacation a bit too much to notice anything.]

As many of you would agree, all this reminds a person of the Cryptography Export Regulations which the US introduced some time ago.

Many feel that affected users should simply use TOR to conceal their location, while concerned project maintainers should use an alternative service provider for hosting. I believe that if we are a community determined to support FOSS, then such work-arounds are simply not sufficient nor is such a mind-set. It is not possible for a project to "OPEN" to all, if it is hosted on a provider like SourceForge and unavailable to certain countries.

[another side note: Although I understand that SourceForge are not entirely to blame as they were adhering to laws imposed upon them, I still believe there must have been some loophole in the legislation which could have been exploited.]

When confronted with cryptography export laws, Phil Zimmermann utilised a legislation-loophole which allowed printed copies of the PGP source to be distributed globally. (See under PGP 5.0)

Whether some creative thinking will overcome such laws and regulations is not yet apparent. However, a solution needs to be found as an increasing number of countries wish to impose restrictions against their rivals and opponents.

At this rate, it seems like we may require the creation of a darknet specifically for the hosting of FOSS products.

With rare exceptions, source code is never released for proprietry software applications. This is primarily in an attempt to prevent other developers from cloning the application (and its functionality), as well as to protect the security of the application (security through obscurity).

The legitimacy of these (and other) reasons is besides the point. The fact remains that in order to implement additional functionality (e.g. add a new shortcut button), extensive research must be performed to understand the application's inner workings. Additionally, the new functionality needs to be implemented such that it does not affect existing functionality.

What all applications have in common however, is that they all rely on existing APIs to display themselves to the user. Using this commonality, two geeks have created and demonstrated what they refer to as a pixel-based reverse engineering package, Prefab.

After interpreting the display, Prefab can identify the various window components as well as interact with them. Logically, this enables a developer to create a layer, between the propriety application and the final pixel display, which can be used for all interface alterations and additions.

Although the demonstrations do seem to work fine, I'd be interested to see how badly Prefab logic is affected when a creative / unique themes are applied to the user interface. It goes without saying that this technique can only be used for additions / alterations to an application, and not to retrieve the source code for the targeted application.

All geeks know that new (and sometimes not so new) hardware doesn't always work with our chosen operating systems. Often it's not a lack of drivers or driver developers holding back progress, but rather hardware manufacturers who prolong the release of chipset information and documentation.

Many companies would rather:

1. Bastardize an older chipset to create a newer version instead of investing time into better R&D.
2. Release new hardware instead of updating firmwares for older hardware. (Belkin are notorious for this)
3. Reduce resources on newer device models in order to limit the capabilities of third-party firmwares ... instead of ... embracing the functionality-enabling hacks. (*cough* Linksys)
4. Horder chipset documentation ... instead of ... releasing it so that more people can develop, and make use of their product.
5. Release bug-infested BLOBs ... instead of ... usable source code which could be forked for improvements.

[side note: Before I continue, Linksys should be commended for their continued release of open-source devices. Additionally, I do understand that in some cases points 4 & 5 can be argued, especially regarding wireless hardware and its respective regulations.]

Having recently updated / replaced my home network with new hardware, I felt it would be best to donate the 'extra' power to something useful. The led to a renewed interest in my old Packet-Brokers folding@home team, which I created after getting tired of continously changing folding teams (and thus losing my folding history). I installed the FAH client onto most of my boxen - all being pretty much average systems.

After a few weeks of 24/7 processing, I have finally reached the 100k points milestone on a previously unused profile (which only had about 23 work units).



Boxen used for folding are as follows:

• 3x Intel Celeron E3200 (with 4GB RAM)
• 1x AMD Sempron 140 (with 2GB RAM)
• 1x Intel Centrino 1.6GHz (with 2GB RAM)
• (Occasionally) 1x Intel Core2Duo T9600 (with 4GB RAM)

At present, I don't do any GPU folding. Although I am considering making the investment into some good GPU hardware, my purchase would only be for GPU programming and not folding.

Almost a few months into my new position as a senior analyst for SensePost, and things are great. Moving from a corporate back to a smaller company gave me sensations of dejavu. This is almost certainly due to my previous experience of not only moving from a small company to a corporate, but relocating to another (busier) region of the country.

It's surprizing how different pentesting on a per-project basis is, when compared to pentesting as a dedicated resource to a global security team within a corporate. Although you are dedicated to a single project at any time, projects run for only a few days. This change is refreshing nonetheless.

It's not surprizing however that no matter what policies and procedures govern your position / role, job satisfaction depends almost entirely on the people surrounding you. Having said this, I feel extremely fortunate in that each time I left a great bunch of guys at my old job, I was met by another great bunch of guys at the new one. The SensePost gang accepted me with open arms even though I rebeled against the iFans, and stood proudly by my Gentoo ways. Additionally, the guys do their best to help me unleash my foosball and pool skillz.

In all, my only regret is that I did not join SensePose earlier as upon my entrance, I discovered that one of the IT security greats, Haroon Meer, would soon be departing in order to persue his own goals. After almost a decade at SensePost, it is understandable that Haroon would need change in order to explore other opportunities. Like the rest of the SensePost team, I wish him all the best with his new venture Thinkst. Haroon's farewell (to SensePost) post can be found here.

In my new position, I will continue to deliver ownage in order to lead the vulnerable to a MORE than adequate level of security.

Signing off for the 1st new blog post,
-- The ZA Packet-Broker

A while back I found the need for a Win32 shim DLL, so I took the opportunity to create a quick hack-up.
Shim DLLs are normally used to extend or alter the functionality offered by a regular DLL.
In my case, I just wanted to observe the data being transmitted from an application to its crypto / hashing library.
So we start with an application we'll call SecProggie and its respective hashing library, SecLibbie.

Now SecLibbie is exporting a few methods but none of them are decorated.
As such, we don't know what argument combination the methods are expecting, unless I take a look at the library's ASM.
I'm avoiding that because I wasnt something I can reuse again later.