Following from the tool shown in Util - Windows Handles - View Handle Screenshot v1.0, the next step was to create a tool that shows (for the selected Win32 Window) the handle's children structure (i.e. what 'child windows' exists for the selected window/control)

Monday, 26 November 2012

In case you missed this one (and are somewhere in Europe), I'm delivering an 1 day 'Advanced O2' training at BeNeLux OWASP Day 2012. So if you want to learn more about the O2 Platform, this is the place to come :)

On the theme of making things better and caring about the parts that can't be seen, here is an example of how I like to format large groups of .Net methods (so that they are easier to read and to look at)

Here is what a .Net Class usually looks like (if you allow VisualStudio to format it)

Last week I discovered the Jni4Net FOSS project which provides the foundation blocks to create a Java bridge to .Net (and vice-versa).

To try Jni4Net, and see if it was really possible to have .Net and Java code running on the same process (with the CLR and JVM being able to invoke each other's methods), I decided to see if I could connect the O2 Platform with the OWASP ZAP project (with both running on the same process)

After spending some time refactoring TeamMentor's (TM) main code-based (to only use the needed bits) here is a stand-alone TM site which will hold the TM Sales and Marketing pages.

If you have a couple cycles, please take it for a test drive (and try not to break it too much since the SI guys are also looking at it at the moment (that said if you break it, I can fix it with a simple git push :) ))

Important note: although the content changes will be shown on the site (the ones done via the 'notepad' editor) this data will be lost on every new publish.

There are two ways to make persistent changes:

get a local clone of the Site_getsecure.teammentor.net, change the content locally, commit those changes locally, and do a push to GitHub (which will trigger a publish to AppHarbor)

edit the desired file on GitHub's web edit interface (for example the Eval page or the Customer page), which when saved, GitHub will auto-create a Commit with the changes (which will trigger a publish to AppHarbor).

Dear dinis,
Thank you for donating to the Wikimedia Foundation. You are wonderful!
It's easy to ignore our fundraising banners, and I'm really glad you didn't. This is how Wikipedia pays its bills --- people like you giving us money, so we can keep the site freely available for everyone around the world.
People tell me they donate to Wikipedia because they find it useful, and they trust it because even though it's not perfect, they know it's written for them. Wikipedia isn’t meant to advance somebody's PR agenda or push a particular ideology, or to persuade you to believe something that's not true. We aim to tell the truth, and we can do that because of you. The fact that you fund the site keeps us independent and able to deliver what you need and want from Wikipedia. Exactly as it should be.
You should know: your donation isn’t just covering your own costs. The average donor is paying for his or her own use of Wikipedia, plus the costs of hundreds of other people. Your donation keeps Wikipedia available for an ambitious kid in Bangalore who’s teaching herself computer programming. A middle-aged homemaker in Vienna who’s just been diagnosed with Parkinson’s disease. A novelist researching 1850s Britain. A 10-year-old in San Salvador who’s just discovered Carl Sagan.
On behalf of those people, and the half-billion other readers of Wikipedia and its sister sites and projects, I thank you for joining us in our effort to make the sum of all human knowledge available for everyone. Your donation makes the world a better place. Thank you.
Most people don't know Wikipedia's run by a non-profit. Please consider sharing this e-mail with a few of your friends to encourage them to donate too. And if you're interested, you should try adding some new information to Wikipedia. If you see a typo or other small mistake, please fix it, and if you find something missing, please add it. There are resources here that can help you get started. Don't worry about making a mistake: that's normal when people first start editing and if it happens, other Wikipedians will be happy to fix it for you.
I appreciate your trust in us, and I promise you we'll use your money well.
Thanks,
Sue

The Console Out window script captured the VisualStudio process' Console Out (of which there is only one, and the reason why if you open multiple Console Out windows (as shown above) only the last one opened will capture the output

To send a message to Console Out window the sender (i.e. the code executed) must be inside the same VisualStudio Process

This means that (based on quick tests) VisualStudio scripting engines (like the Immediate Window or the F# interpreter) will not work (since they are running outside the VisualStudio process)

One easy way to trigger an Console.WriteLine is to write it in one of the C# REPL script GUIs (from the O2 VisualStudio Extension) :)

But what would be really useful would be to trigger Console.WriteLine debug messages during normal VisualStudio development, for example when programming WinForms Controls :)

To show how that is possible, lets start with an empty WinForms Application project:

Which comes with default WinForms Form:

Next add a UserControl with a Label:

And add that UserControl to the Form:

The interesting part of what just happened, is that VisualStudio invokes the constructor of the UserControl1.cs (in order to create a live instance of that Control) before adding it to the Form1.cs object.

And that (the UserControl1.cs constructor) is where we can trigger the Console.WriteLine calls.

Open the Code Behind file for the UserControl1.cs file:

Write a Console.Write message and build the project (note the message shown in the Console Out window)

The reason that happened, is because (after a successful build) VisualStudio needs to refresh the controls currently shown in the Form's Designer (for example to take into account any visual changes in those controls)

Here is another way to trigger the Console.WriteLine call (i.e. to trigger the UserControl.cs constructor).

Close Form1.cs from the Form Designer:

And the open it again:

Yet another option is to delete the UserControl1.cs from the Form1.cs:

And add it back again:

Basically, the UserControl1.cs constructor will be invoked every time that control is added (or shown), like in the image below, where another instance of UserControl1.cs was dragged into the Form1.cs:

Interestingly enough, this as a number of security implications, since a security payload/exploit can be triggered just by adding/viewing a UserControl inside the Form Designer. The problem is that the payload will run with the same privileges given to VisualStudio (not the privileges used to run the application)

Michael Hidalgo has posted two blog entries where he uses the O2's VisualStudio Extension to open an Console Out window inside VisualStudio, which is then used to help with a quick test on the DateTime object (and making his life easier)

"...Free/Libre Open Source Software Hacking (FLOSSHack) events are designed to bring together individuals interested in learning more about application security with open source projects and organizations in need of low cost or pro bono security auditing. FLOSSHack provides a friendly, but mildly competitive, workshop environment in which participants learn about and search for vulnerabilities in selected software. In turn, selected open source projects and qualified non-profit organizations benefit from additional quality assurance and security guidance...."
See FLOSSHack_One for the details (and vulnerabilities discovered) of the first event.

OWASP's FLOSSHack is one of those 'magical' spaces where the OWASP's community and its projects can come together and add a lot of value.

OWASP is a community that really embraces new ideas, new contributors and projects.

For somebody motivated (and with time/energy) there are very few ‘real’ barriers on entry. Even the cases where it ‘feels’ like there are barriers of entry or ‘bureaucracy’, those are mainly artificial and easy bypassed (with the right level of energy and commitment)

The problem is Empowerment

What I found (by observing lots of OWASP projects starting, blossoming and dying) is that what makes the difference is how Empowered is an individual on a particular project/tasks.

Here is a good read (if you're into kernel dev or patching) from the guy who created EasyHookI while back I did some kernel development where I used the Rasta Ring 0 Debugger to apply direct code patches to user-land dlls. One of the best PoCs was one where I was able to do MSIL patching on loaded .NET assemblies, which were completely invisible to user-land.Patching the CLR was also very interresting :)

Google Refine in their own words is: "...a power tool for working with messy data, cleaning it up, transforming it from one format into another, extending it with web services, and linking it to databases like Freebase...."

What you will see in that example is that I will dynamically compile and execute a WinForms Control, without using VisualStudio's Debug/Run capabilities to see the new changes in action. I was able to compile the modified Source Code file, and using reflection, was able to create a new instance of an WinForm's Control (without leaving the VisualStudio's IDE).

And the best part is that we can code our tests in an REPL environment (think Roslyn), which allows the support for complex (and unit-test like) scenarios.

I can't underestimate how powerful, fast and efficient it is to be able to have this type of REPL environment while coding.

Here is an example of using the VisualStudio C# REPL - O2 Platform extension to update/fix an existing WinForms control without going though the painful (and slow) process of VisualStudio GUI programming, which usually goes something like this:

Which looks like this (it's a good idea to right-click on the code editor to open the context menu, and to select the show Log Viewer option:

Here is a small text change to show the C# REPL environment in action

Now here is the powerful part, this script:

Will create a new popup window with the ascx_Simple_Script_Editor WinForms Control (that was just dynamically compiled from the original source code (note: the ascx_Simple_Script_Editor Control is the one used to create the C# REPL environment))

What is happening is that the ascx_Simple_Script_editor.cs file (whose source code is shown in the background) was dynamically compiled and executed .... without leaving the VisualStudio's IDE.

Just to double-check that we are doing this in real time, lets make a small code change in the ascx_Simple_Script_editor.cs source code (using VisualStudio's code editor).

The code shown below will create two MessageBox(es). The first was created using the normal .Net MessageBox call syntax, and the 2nd uses O2's FluentSharp API (which should be easier to read)

Here is the 1st MessageBox:

Here is the 2nd MessageBox:

The ascx_Simple_Script_Editor WinForms Control will appear after the MessageBox(es):

Now that we've proven that we are able to change, compile and execute a C# WinForm's control in a REPL environment, let's do something more interesting.

Moving a ToolStrip Control

One of the O2 Platform user's feature requests that I have received for this control (the one that we are editing), is to move the ToolStrip Control (the one with the New, Open and Save As buttons) from the bottom of the Control, to the top (which is where usually ToolStrips are located).

Going back to the VisualStudio document with the ascx_Simple_Script_editor.cs source code, here is the addToolStrip method that 'inserts below' the commandsToExecute Control an ToolStrip Control (the rest of the addToolStrip method adds the TootlStrip items (3x Buttons, 1x Label and 1x TextBox)

To change the location of the ToolStrip Control, we will use the FluentSharp insert_Above Extension Method (vs the originally used insert_Below Extension Method) :

Once the change is saved, we can immediately see these changes in action, by using the REPL environment created via the gist script shown above..

Here is the updated version of the ascx_Simple_Script_editor Control with the ToolStrip Control at the top.

Note that I didn't use VisualStudio's Debug/Run capabilities to see the new changes in action. I was able to compile the modifed Source Code file, and using reflection, was able to create a new instance of that WinForm's Control (with everything done inside VisualStudio's IDE).

Adding a new Button

As a final example, lets add a Run button to the ToolStrip Control.

Here is the updated source code (note the new add_Button line)

Once saved , complied and executed (not by VisualStudio), we can see that there is a Run button on the ToolStrip.

Here is the button being used to execute a test REPL script:

VisualStudio power is still all there
Another benefit of this technique/workflow is that we still have access to the powerful VisualStudio Intellisense and Error detection:

Compiling and executing the Solution

The final step is to compile the Solution file (with the changes made)

And run the O2 Platform executable (now using VisualStudio's F5).

Note how the O2 Platform's native C# REPL editor now has the changes made to the ToolStrip Control (it is above the code-editor and has an extra Run button)

This technique will change the way you code (once you got your head around it)
I can't underestimate how powerful, fast and efficient it is to be able to have this type of REPL environment while coding (and how painful is the VisualStudio workflow in comparison).

In fact, this REPL environment is a curse, since once you tried it, there is no way back! :)