I have been a subscriber to this magazine’s electronic edition since the past year. However, they’ve only sent me one copy of the magazine till date. The cost of the yearly subscription was $79 or something which makes it an extremely expensive magazine…1 issue for $79…that’s ridiculous!
All my efforts to contact monika.drygulska@hakin9.org or marta.ogonek@hakin9.org have been futile! I would like to discourage anyone who pays for this.
Has anyone else experienced this kind of sloppy service with Hakin9?
Update 06/23/2009:
Hakin9 finally contacted me, after I emailed them (again) based on Chris John Riley’s suggestion. They provided me with the missing issues. Better late than never Hakin9! Thanks!

People tend to think that gone are the days when the “RPM Hell” used to exist. We have yum, aptitude and what not! If you install linux on a PS3, I’d like to bring you back to reality, especially like me when you have yellowdog 5.0 installed on a first gen PS3.
What is interesting is that all these package managers rely on repositories in /etc/yum.repos.d/*.
If you do not have the good repositories then you can kiss goodbye to installing the Cell Broadband Engine SDK provided by IBM. This SDK has the spu-gcc, spu-g++ which is the right set of compilers if you want to use the 1 master processor (Power Processor Element – PPE) and the other six SPE (Synergistic Processor Elements – SPEs) …think of these as slaves. You might wonder where’s the 7th of the cell processor, well, you cannot access it because it is used internally by the PS3 for virtualization.
So I got a yellow dog 5.0 iso image from here. I followed the instructions for installing it from here. I did this almost a year ago! Yes…I did actually keep it dead for a while! Then I installed gcc and compiled John the ripper! To my utter disappointment, there was no performance benefit!
Then Marc Bevand told me at Toorcon X that I needed spu-gcc to compile JTR on PS3 to get the benefits. So I got the cell sdk ISO from here. I then mounted the ISO.
mount -o loop cellsdk11.iso /mnt/disk
cd /mnt/disk
cd software
./cellsdk install
I got bunch of errors. It wanted me to install freeglut-devel and tk-8.4.*.
Thus began my journey of 10,000 steps to get the dependencies resolved and I burnt my fingers, keyboard, brains, etc….and although I realized that everyone in the US and the world had found hope…things were not looking bright for me! Until I bumped into this fantastic repository here. Trust me it took me about 8 hours of incessant installing and compiling (almost 120 odd different files) and scores of google searches to land me into this. I installed the glut, libx11, tk, tcl, libtcl, glut-devel, libstdc++, libstdc-so7, and many other packages that I cannot even recall now to get the cellsdk to work! And even though I did, I still couldnt get ./cellsdk install to work! After about 8 hours of effort and being so close to success just seemed evil. Then I realized that all the packages needed were related to the PPC64 simulator (libx11.ppc64, libtcl.ppc.64, etc.)…a quick look into the readme told me that I could neglect that using the –nosim directive to make it work.
Finally,
./cellsdk install –nosim
worked!!!!!
A small step for mankind but a giant step for me!

I think Nmap is by far the best portscanner around if you want to do some serious port-scanning. Nmap performs a DNS resolution by default. This is good for obtaining the fully qualified domain names (FQDN), however, in some cases when you are scanning huge networks spanning several class Bs, it can have a significant effect on the duration of the scan.
Although using the -n parameter can completely stop nmap from performing any resolutions, but sometimes there’s that fine granularity that you need, i.e., you want to perform name resolutions but not if it exceeds a certain amount of time. I have to say that I wouldn’t have even craved for such an idiosyncratic feature, had it not been for nmap. Fyodor has been awesome enough to provide fine-grained control over port-scanning to your heart’s content.
So I opened up the nmap code, trying to figure out if I could fine tune that feature myself and I was not at all surprised that there were several comments in the code that would give you the impression that the authors of nmap have been considering this feature.
At this time it seems that the timeouts for the DNS servers are being read out of an arrayname:
static int read_timeouts[][] in nmap_dns.cc.
The way the code works is, this array has retransmission timeouts. Each row of this array represents what retransmission timeouts that nmap will follow depending on the number of DNS servers provided.

In nmap 4.76, therefore, if you specify one DNS server (or only one entry exists in /etc/resolv.conf) nmap will wait 4000ms, then another 4000ms followed by 5000ms before giving up. But if you do specify two DNS servers, then for the first DNS server the timeouts are 2500ms followed by 4000ms and then the same is tried for the 2nd entry in the DNS servers. Therefore, it seems that nmap will wait 13 seconds at max before giving up on the DNS resolution of a host. Imagine scanning a class B and having to wait 13 seconds for each of the hosts to resolve. It would be a significant overhead.

Of course, one can find other things to do if the IP address space is not DHCP, e.g., starting a separate list scan (-sL) and a portscan (with -n) simultaneously so that the DNS resolution timeouts do not result in a major impact as far as the portscanning itself is concerned.
There could be pros and cons to this as well which I may have failed to consider. But at this time it seems that it might be the most judicious approach.

I’ll be attending the Shmoocon in Washington, DC from Feb 6th-8th. Hope to see all you h4X0rs out there!

The New Year brings in interesting things (or so we hope). My friend came up to me with an “infected” computer with a fantastic piece of malware installed. The malware was presented the user with a completely different HTML page when something was searched on Google. Browser Helper Objects (BHOs) are Dynamic Link Libraries (DLLs) that are installed in Internet Explorer (IE) and have a complete access to the DOM tree of the browser window. The name of the DLL was xyusx.dll (or something like that). This DLL was packed so that it wouldn’t permit a clean disassembly. The usual tricks seemed to work and I was able to unpack the DLL.

The procedure is simple. Open the DLL in OllyDbg. Search for the PUSHAD instruction (this instruction stores all the registers on the top of the stack) and set a breakpoint (F2 key in OllyDbg) on that instruction.

Press F9 to continue the debugging. Press F8 to execute the instruction, and then set a hardware breakpoint on the top of the stack in the Dump Window as shown in the image. You can do this easily by right clicking on the ESP register and clicking on “Follow in Dump”.
Once you reach the POPAD instruction or the hardware breakpoint is activated, this shows that the registers that were saved on the stack are now going to be restored in the respective registers. This indicates that the program has now finished extracting itself and is ready to execute the instructions.
I used OllyDump to dump out the contents of this DLL and then used LordPE to repair the import table. This process, however, needs more work due to the nature of the automated import address table repairing as some things can be missed.
Once this repairing was finished, I opened the file in IDA Pro to disassemble the unpacked DLL. This did give me a lot of information about this DLL, however, I’m still in the process of completing a good disassembly of this DLL.
As for now, I can say that this DLL installed a bunch of spyware CLSIDs into the system.
Some of the CLSIDs (out of the 45 that it uses) by this malware are listed below:

{CF46BFB3-2ACC-441b-B82B-36B9562C7FF1}
{67C55A8D-E808-4caa-9EA7-F77102DE0BB6}
{1557B435-8242-4686-9AA3-9265BF7525A4}
{55DB983C-BDBF-426f-86F0-187B02DDA39B}
{A24B57F8-505D-4fc5-9960-740E304D1ABA}
{4B646AFB-9341-4330-8FD1-C32485AEE619}
{CD3447D4-CA39-4377-8084-30E86331D74C}
{DEBEB52F-CFA6-4647-971F-3EDB75B63AFA}
{8F2183B9-F4DB-4913-8F82-6F9CC42E4CF8}
{92A444D2-F945-4dd9-89A1-896A6C2D8D22}
{1F6581D5-AA53-4b73-A6F9-41420C6B61F1}
{1126271C-A8C3-438c-B951-7C94B453B16B}
{938A8A03-A938-4019-B764-03FF8D167D79}
{44218730-94E0-4b24-BBF0-C3D8B2BCE2C3}

This DLL also seemed to communicate to :

89.188.16.10
89.188.16.16
65.243.103.56
65.243.103.60
65.243.103.62

Whatever you do to these servers is upto you. Some google searches allude that this is a “Vundo infection”. I’m also not sure what solutions people are posting to this problem but I’d not feel safe if this malware was on my computer and I’d definitely format my Windows install, patch it and change my passwords! I’m not completely dne with the disassembly and reversing of this malware yet, but I’m sure I’ll post more when I delve into this disassembled code deeper.