Amp Blasts: Nintendo

Notice: The following is a humor piece (partially based on my real opinions, but tuned up to AVGN levels of what the hell) and as always, the SX usage policy applies.

I know that the title of this alone is going to cause some rage with some people and I can see how. I myself have great memories of the NES and SNES. Both of these are great consoles. However, the reality is that the Nintendo that I knew and loved is dead. Today, I will explain why I feel this way.

The first major misstep happened in the fifth generation of game consoles with the N64. The reality is that partnering with SGI was a bad idea as they never did real-time graphics and the console's hardware limitations along with the complexity of developing games made it problematic. Add to it that a large portion of the games were pure and utter shit (Superman 64 being the most well known, but there are plenty of other games that outright sucked) and many of them featured some of the worst soundtracks I have ever heard in gaming history. The biggest beef I have is that people try to hail Goldeneye as ground breaking when the reality is that it was a slow, choppy, piece of shit with crap controls that was saved only by it's auto-aiming. (Also, people like iJustine's stupid ass in a shitty mentalfloss video, need to stop saying that it was the first game with multiplayer deathmatch as Doom had it years earlier!) The amount of good games for the N64 were few and far in between, something that would be true for all non-handheld consoles for them from that point forward.

Amp Blasts: eSports!

Disclaimer: The following is written for humor and falls under the SX usage policy.

Ok, I retired 'Amp Blasts' back in May as at that point I couldn't really think of much of blast. Since then though, quite a bit of shit has went down. In addition, personal life events happened which inspired a special level of bile and fury that I haven't had in a long time. The end result is that I have decided to revive the blasts and go after eSports, one of the biggest loads of bullshit I have seen and I'd like to start with a comparison.

First off let's take a look at the majority of people who are developers at work. We see them working on design, or programming outright without showing very much emotion aside from when they communicate inter-personally. (Yes, I'm going to destroy the anti-social stereotype cause most developer jobs are on a team, thus necessitating social communication.) They are working productively on projects that will help the bottom line of their employer and at the same time hopefully furthering their own skill-set. Some of these jobs may be thankless for a variety of real world factors that can cause somebody to be unhappy with such a job, but that is normal. At the very least, they have a good living and are trying to be a productive member of society.

Now, I'm going to take a look at many eSports "professionals." They spend most of their time playing a videogame for hours on end, communicating only with people on their team and often in crass, unprofessional ways. Their social skills with most outsiders often reaches jack and shit. They are spending their time not being legitimately productive on anything, but just playing a game in the hope of somehow making money from playing a games that probably stopped being enjoyable due to the overkill of playing it. To me, this is fucking pitiful and the fact that people honestly think that eSports will pay the bills in the long run shows me they have no common sense whatsoever.

Threading in C++

In my threading tutorial at I covered how threading was handled by different languages. In particular, I stated that I was not particularly a fan of the threading implementation used by Java due to the fact that it forced the user to either use polymorphism (courtesy of the runnable interface) or to made a subclass of the Thread class. The biggest reason for this dislike is that this is more work than is necessary. Well, in some respects Qt works similarly on threading which bothers me a bit.

There are two ways to handle threading in Qt, and honestly it feels like a brilliant solution to a problem that shouldn't exist in the first place. The first one is similar to Java as it requires the QThread class to be inherited. The second one is to use a "worker" class with a series of signals and slots to handle the threading. Based on my experiences with other languages, both feel like a considerable amount of work that results in code that doesn't look as elegant as it could be so I feel the C++11 threading included within the STL to be the better solution at this point in time.

Overall, this shows that there are instances where using the basic STL can often yield a better solution than other libraries. I know that Qt has its own list class, but the STL rendition of lists is one that to me, did not necessitate a reinventing of the wheel. At the same time, there are some specialty list classes used in Qt such as QStringList, that have some capabilities that are more beneficial for the GUIs. With all of this taken into consideration, it is always important to investigate the best combination of clean code and efficiency.

Handling Multiple Forms in Qt Creator

Before I go on with this post, allow me to say Happy Holidays to everybody around SX. Make sure to spend time with significant others if at all possible.

Now that I have that out of the way, I spoke about my initial impressions of Qt Creator as I have done some side practice with it along with working on the GUI and some aspects of the OFACE backend. (One of the major parts will most likely be worked on this Friday and if there is enough demand, I may do a timelapse video of my codework.) For those who may have read my basic programming concepts tutorials, I talked about basic memory allocation in C++ and how this is good to know for C++ and in many cases other languages regardless of if they use a garbage collector. Well, in Qt Creator I have been working with how to handle multiple forms. Now, in the case of something like C# within the .NET framework, this is a pretty cut and dry task. However, this is a different ballgame when it comes to Qt Creator.

Adding the form in question only requires a Qt Designer Form Class to be added to the project, but doing this doesn't just mean that it can be called and all is good. When this is done, the ui, header, and cpp files are created for the class and if the class is dynamically allocated without deleting the memory after the object is no longer in use, the end result will be a textbook entry level memory leak. At the same time, calling a new form up from a method that is used for a signal event does not allow for such deletion to happen immediately as it would immediately close the form. Fortunately, there is a good way to handle this.

Initial Qt Impressions

With OFACE development having begun on my end officially when I have time available, I figure I would share some of the good and bad about what I have seen with the Qt Libraries so far. Now, despite my knowledge and experience, I refuse to call myself and expert in many programming concepts and merely just a journeyman who is working to become as diverse as possible. In addition, these are impressions that I have based on the work that I have done up to this point with the library which has been less than a week. Overall though, my initial impressions have been positive.

The IDE that I have opted to use is Qt Creator straight out of the gate. This provides me a WYSIWYG setup for many of the GUI elements. I will state that for the form-based work Qt Widgets is recommended, but for more dynamic content (such as having animations) Qt Quick serves as a good solution. The bigger advantage of this IDE is that for C++ work it is far better than the horrific experiences I have had with getting Eclipse to even work. This is a good advantage to me.

Another advantage is that the Qt libraries are much more powerful than I have anticipated. Some of the tasks that I thought I would have to create manually with C++ (which while annoying, was something I was wanting to do for some aspects as for OFACE I want to avoid some of the libraries provided by Windows for C++ due to their antiquated nature.) I actually found preexisting libraries to simplify matters and speed up development. I will state that some of the libraries are not perfect and I don't like some of the example usages, but that is me nitpicking a bit. Overall though, the libraries do go a long way in helping make platform neutral products.

Online Dictionary Attack w/ Hydra


When an attacker wants to learn credentials for an online system, he can use brute force or a dictionary attack. This article introduces these two types of attack and explains how to launch an online dictionary attack using Hydra.

Brute Force vs. Dictionary Attack

An attacker can try every possible password combination (brute force approach). The advantage is guaranteed success in finding the right password. The drawback is that it is a very time-consuming process.

It’s probable that a typical user is frustrated about password best practices and uses a pattern for the password (for example a common word and a digit appended at the end). Then the attacker can build a set of common words concatenated with a digit (an exemplary pattern in the dictionary) and try every combination from this set. This approach (dictionary attack) can save the attacker’s time, because he doesn't have to brute-force the whole key space. The disadvantage is that there is no guarantee that the right password will be found. However, the probability of hitting the right password is quite good, taking into account the passwords people often choose.


Hydra is described as a network logon cracker that supports many services. This article explains how to use Hydra to launch an online dictionary attack against FTP and a web form.

Metasploitableis a Linux-based virtual machine that is intentionally vulnerable. It can be used, for example, to practice penetration testing skills. Please remember that this machine is vulnerable and should not operate in bridge mode.

Back around for now

Hey, just dropping a line to mention that I just finished up my bachelor's degree in college. (Also received Summa Cum Laude and Departmental Honors.) Now that I have finished up this particular work I will have quite a bit more time to work on some projects that have been of interest to both myself and to SX as well. At the same time though, I will be looking into employment (I won't go into any further detail as I feel it isn't necessary to go into detail with many aspects of my life as to be quite honest, it's rather boring) so I won't be doing the whole 24/7 availability deal.

With this in mind, I have come up with a bit of a very rough basic idea for one of the main parts of how OFACE would run. In addition to this though, as I have decided to use C++ there is a matter of developing a GUI for it as well. The honest to god's reality is that should I develop this using modern Visual Studio releases, this forces me to use the .NET framework and I do not wish to have such a requirement on that project. I looked into GTK but many accounts have stated that it is not a fun experience to work with. After much consideration, I made the decision to look into Qt for the GUI and GCC 4.8.0 so that I can take advantage of the newer C++ capabilities as some of the boost libraries they have included are pretty good. I will start messing with Qt a bit shortly and looking at if it would be the best solution for this.

Brief Notes

I figure I would make a quick blog post for those who do read this and mention that I have not been able to get much forward momentum on OFACE (I have started writing code for one of the main modules for it, but have yet to look at GUI aspects as I wish to have a strong back-end first.) due in part to real life events. In particular, I am finishing my undergraduate studies which are taking up quite a bit of my time. After this is finished, OFACE will be a priority project that I will most likely be working on during Christmas.

Syndicate content