All posts in Uncategorized

Procedure: Install and Configure the Intel Manufacturing Flash Tool on a Windows Host PC
1. A PC running Windows 7 or higher with an available USB port
2 A customized installer of Intel Mfg Flash Tool bundled with the required drivers, 2 preconfigured .INIs and 3 .BAT files to perform the installation.


Step by Step instructions:
1. Extract archive to a folder on your target Windows PC.
2. Browse to the folder and launch:


3. The batch file will install the 2 needed driver packages in the appropriate order, first
the iSoC drivers ver 1.2, then the Intel Android drivers, ver 1.9
If any installer reports you already have a version of the driver installed, just let it uninstall the
old driver and install the new one.
4. Launch:


5. The installer will proceed to install the Flash Tool.
6. Right click on


and select Run as Administrator.
This script copies the CUSTOM_CONFIG.INI to the MFT install folder and also copies Manufacturing Flash Tool.INI to thePROGRAMDATA folder. It needs admin rights to copy to the install folder.
7. Congratulations, your Flash Tool is now installed and configured.

Shellcode is named as it does since it is usually starts with a specific shell command. The shellcode gives the initiator control of the target machine by using vulnerability on the aimed system and which was identified in advance. Shellcode is in fact a certain piece of code (not too large) which is used as a payload (the part of a computer virus which performs a malicious action) for the purpose of an exploitation of software’s vulnerabilities.

Shellcode is commonly written in machine code yet any relevant piece of code which performs the relevant actions may be identified as a shellcode. Shellcode’s purpose would mainly be to take control over a local or remote machine (via network) – the form the shellcode will run depends mainly on the initiator of the shellcode and his/hers goals by executing it.

The Various Shellcodes’ Techniques

When the initiator of the shellcode has no limits in means of accessing towards the destination machine for vulnerability’s exploitation it is best to perform a local shellcode.Local shellcode is when a higher-privileged process can be accessed locally and once executed successfully, will open the access to the target with high privileges. The second option refers to a remote run, when the initiator of the shellcode is limited as far as the target where the vulnerable process is running (in case a machine is located on a local network or intranet) – in this case the shellcode is remote shellcode as it may provide penetration to the target machine across the network and in most cases there is the use of standard TCP/IP socket connections to allow the access.

Remote shellcodes can be versatile and are distinguished based on the manner in which the connection is established: “Reverse shell” or a “connect-back shellcode” is the remote shellcode which enables the initiator to open a connection towards the target machine as well as a connection back to the source machine initiating the shellcode. Another type of remote shellcode is when the initiator wishes to bind to a certain port and based on this unique access, may connect to control the target machine, this is known as a “bindshell shellcode”.

Another, less common, shellcode’s type is when a connection which was established (yet not closed prior to the run of the shellcode ) will be utilized towards the vulnerable process and thus the initiator can re-use this connection to communicate back to the source – this is known as a “socket-reuse shellcode” as the socket is re-used by the shellcode.

Due to the fact that “socket-reuse shellcode” requires active connection detection and determination as to which connection can be re-used out of (most likely) many open connections is it considered a bit more difficult to activate such a shellcode, but nonetheless there is a need for such a shellcode as firewalls can detect the outgoing connections made by “connect-back shellcodes” and /or incoming connections made by “bindshell shellcodes”.

For these reasons a “socket-reuse shellcode” should be used in highly secure systems as it does not create any new connections and therefore is harder to detect and block.

A different type of shellcode is the “downloadand execute shellcode”. This type of shellcode directs the target to download a certain executable file outside the target machine itself and to locate it locally as well as executing it. A variation of this type of shellcode downloads and loads a library.

This type of shellcode allows the code to be smaller than usual as it does not require to spawn a new process on the target system nor to clean post execution (as it can be done via the library loaded into the process).

An additional type of shellcode comes from the need to run the exploitation in stages, due to the limited amount of data that one can inject into the target process in order to execute it usefully and directly – such a shellcode is called a “staged shellcode”.

The form in which a staged shellcode may work would be (for example) to first run a small piece of shellcode which will trigger a download of another piece of shellcode (most likely larger) and then loading it to the process’s memory and executing it.

Egg-hunt shellcode” and “Omelets shellcode” are the last two types of shellcode which will be mentioned. “Egg-hunt shellcode” is a form of “staged shellcode” yet the difference is that in “Egg-hunt shellcode” one cannot determine where it will end up on the target process for the stage in which the second piece of code is downloaded and executed. When the initiator can only inject a much smaller sized block of data into the process the “Omelets shellcode” can be used as it looks for multiple small blocks of data (eggs) and recombines them into one larger block (the omelet) which will be subsequently executed.

Introduction to MSFPAYLOAD Command

In this part we’ll focus on the msfpayload command. This command is used to generate and output all of the various types of shellcode that are available within Metasploit. This tool is mostly used for the generation of shellcode for an exploit that is currently not available within the Metasploit’s framework. Another use for this command is for testing of the different types of shellcode and options before finalizing a module.

Although it is not fully visible within it’s “help banner” (as can be seen in the image below) this tool has many different options and variables available but they may not all be fully realized without a proper introduction.

# msfpayload -h

Although revealing the secret is always an appealing topic for any audience, Reverse Engineering is a critical skill for programmers. Very few information security professionals, incident response analysts and vulnerability researchers have the ability to reverse binaries efficiently. You will undoubtedly be at the top of your professional field (Infosec Institute).

It is like finding a needle in a dark night. Not everyone can be good at decompiling or reversing the code. I can show a roadmap to successfully reverse the code with tools but reverse engineering requires more skills and techniques. Software reverse engineering means different things to different people. Reversing the software actually depends on the software itself. It can be defined as unpacking the packed, disassembling the assembled or decompiling the complied piece of code termed as software. Some people have also named it as Auditing the Binary or Malware Analysis. This depends on the motive. Before we jump into more details, let’s highlight some pre-requisites of software reverse engineering.

Pre-requisite in Software Reverse Engineering

Most importantly, you should be a programmer who understands the basic concepts of how the software world works. It is like driving your car in reverse gear and reaching home without accidents! So yes, it’s not an easy job and it requires practice. Understanding following requirements is fundamental in reversing any piece of code.

001 – You should be good in at least one programming language so it could be C++.

002 – Understanding assembly language is the key to success in reversing the code and reaching the target. Understanding of stack and memory works, types of registers and pointers are the important factors.

003 – Which DLL is mapped to which statement is very important.

004 – Try identifying the algorithms used and drawing the map of them.

005 – Performing crash analysis to identify bugs, understanding the functionally of the software code by applying the hit and miss rule.

006 – Identifying files used.

007 – Identify variables used in the code, this is very important.

008 – Most importantly is Vulnerability Analysis, this is applicable when you are trying to modify the normal behaviour of the code.

Approach: Different Reversing Approaches. There are many different approaches for reversing, and choosing the right one depends on the target program, the platform on which it runs and on which it was developed, and what kind of information you’re looking to extract. Generally speaking, there are two fundamental reversing methodologies: offline analysis andlive analysis.

Offline Code Analysis (Dead-Listing)

Offline analysis of code means that you take a binary executable and use a disassembler or a decompiler to convert it into a human-readable form. Reversing is then performed by manually reading and analysing parts of that output. Offline code analysis is a powerful approach because it provides a good outline of the program and makes it easy to search for specific functions that are of interest. The downside of offline code analysis is usually that a better understanding of the code is required (compared to live analysis) because you can’t see the data that the program deals with and how it flows. You must guess what type of data the code deals with and how it flows based on the code. Offline analysis is typically a more advanced approach to reversing.

There are some cases (particularly crackingrelated) where offline code analysis is not possible. This typically happens when programs are “packed”, so that the code is encrypted or compressed and is only unpacked in runtime. In such cases only live code analysis is possible.

Live Code Analysis

Live Analysis involves the same conversion of code into a human-readable form, but here you don’t just statically read the converted code but instead run it in a debugger and observe its behaviour on a live system. This provides far more information because you can observe the program’s internal data and how it affects the flow of the code. You can see what individual variables contain and what happens when the program reads or modifies that data. Generally, it is said that live analysis is the better approach for beginners because it provides a lot more data to work with. The section on “Need for Tools” discusses tools that can be used for live code analysis.

Need for Tools: which tool to select is based on the piece of software code you’re trying to reverse. There are many tools available on internet but key tools are IDA Pro & OllyDbg. IDA Pro is a wonderfu tool with a number of functionalities; it can be used as debugger as well as disassembler. On the other side OllyDbg is an assembler level analysing debugger for Microsoft® Windows ®. Emphasis on binary code analysis makes it particularly useful in cases where source is unavailable.

Highlights of IDA Pro Functionalities

In my opinion IDA Pro is most powerfull tool and is mostly used in reverse engineering, its functionalities are vast in number, however, I should highlight the key one:

Adding Dynamic Analysis to IDA

In addition to being a disassembler, IDA is also a powerful and versatile debugger. It supports multiple debugging targets and can handle remote applications, via a “remote debugging server”. Power Cross-platform Debugging:

  • Instant debugging, no need to wait for the analysis to be complete to start a debug session.
  • Easy connection to both local and remote processes.
  • Support for 64 bits systems and new connection possibilities.

Highlights of OllyDbg Functionalities

  • It debugs multithread applications.
  • Attaches to running programs
  • Configurable disassembler supports both MASM and IDEAL formats
  • MMX, 3DNow! And SSE data types and instructions, including Athlon extensions.
  • It recognizes complex code constructs, like call to jump to procedure.
  • Decodes calls to more than 1900 standard API and 400 C functions.

There are many assumptions around performance of different PHP frameworks. I frequently hear strong opinions about superiority X over Y in this context. There are companies writing new PHP frameworks from scratch because available solutions are too slow for them. What does it really mean? Does the framework performance matters? Before answering this questions lets check how slow is your framework!

Performing a representative benchmark across different framework is not an easy task. There are multiple ways to use each of them. Every use case will give different reading. Lets take routing as an example. Zend1 by default doesn’t need a routing file. It’s happy to use “/controller/action” pattern. On the other hand Symfony2 comes with a routing configuration. The file has to be read and parsed. That obviously takes some additional CPU cycles but does it mean Symfony2 routing is slower then Zend1? The answer is (obviously) no.

I benchmarked “quick start” projects. That gives some idea on what is the base line for every framework and makes it possible to reproduce my tests (and argue against them).
Code was hosted on Amazon EC2 medium instance. I installed PHP-APC to avoid disc access and code parsing. I also made sure there is no I/O on Apache2 or application level. I set logs and cache paths to “/dev/shm/”. I tweaked projects to make them return roughly the same amount of data (10KB). All virtual hosts had the same mod_rewrite rules. AllowOveride was set to None.

Benchmarked frameworks:

Requests per second from Apache Benchamrk with c=20 and n=500.

Framework Req/Sec
Phalcon 822.96
Slim 399.83
Kohana 217.34
Code Igniter 187.78
Silex 179.01
Laravel 135.9
YII 123.5
Fuel PHP 116.34
Hazaar MVC 103.53
Zend 1 103.02
Cake PHP 54.97
Nette 53.48
Symfony2 39.22
Zend 2 36.1

PHP Frameworks benchmark

I’m not surprised, Slim is the fastest because it’s a micro framework. The Quick Start project didn’t use any templates or layout which obviously contributed to the reading.
Zend1 is twice faster than Symfony2 and Zend2 but in my experience the number will quickly go down in a real live setup.

Frameworks should speed up development, performance is a secondary concern. Zend 2 and Symfony2 could do better but it’s not bad. There are ways to improve those numbers on production servers. Don’t reinvent the wheel, learn and use frameworks. There are various options which balance between performance and features.

Edit 1: If you have space for more I would like to recommend you great research on performance of web frameworks by techempower.

Edit 2:  Phalcon is the new winner.

I’ve found this cheatsheet to be the best way to learn all the secret shortcuts in Resharper that really help to speed up development in Visual Studio and make life easier.  For months I had it pinned to my cube wall until I used them so much they’re muscle memory.

If you are coming from a JAVA background and have been using IntelliJ IDEA, use this:

If you are like me and a hard core visual studio user, use this:

If you want to change your shortcut scheme (or you aren’t sure what it’s set to), in the Visual Studio top menu go to Resharper –> Options –> Keyboard & Menus, then select “Visual Studio” or “Resharper 2.x or IntelliJ IDEA” and Apply Scheme and Save.  Then hit a shortcut like Ctrl+Shift+N and a menu pops up saying there’s a conflict in shortcuts and asks which scheme do you want to use.  Select “Visual Studio” or “Resharper 2.x or IntelliJ IDEA” and check the Apply to All.  You can switch to the other schema at any time.


Here’s an image for the visual studio layout.