Showing posts with label Code Monkey. Show all posts
Showing posts with label Code Monkey. Show all posts

Tuesday, October 15, 2013

Windows 8 Network Profile Manager

Starting from Windows Vista, Microsoft has implemented Network Location Awareness (NLA) into Windows. To put it in simple terms, Windows will automatically identify and name the networks it joins.

The feature however is prone to create silly network names, especially if you tend to change network adapters often, such as MyHomeNetwork 2, MyHomeNetwork 3 … MyHomeNetwork 13.

To top that off, since Windows 8, Microsoft has removed the option to manage, that includes merging and renaming, of networks – users are forced to stick with the stupid names Windows give (e.g. Network, Network 65535 etc.)

Thankfully, it is still possible to rename the network names, but only through hacking your way into the Windows Registry.

Windows 8 Network Profile Manager

Enter Windows 8 Network Profile Manager (Win8NetMan). Win8NetMan is a small application written to manage the network profiles created by Windows in a intuitive way by abstracting all the Registry complications.

Here are the features in a glance:

  • Display and changing of simple network profile properties (e.g. name, description) and advanced properties (e.g. default gateway MAC address, DNS suffix etc)
  • Deletion of individual network profiles (e.g. for old network devices that are no longer used)
  • Bulk deletion of all network profiles

Note: Changes may require reconnecting to the network to be applied.

If you like the application, please donate to support further development of useful applications!

 

 

Download (Hosted by 4Shared.com)

Tuesday, August 6, 2013

デフコン

This afternoon the Internet at my workplace went down. Since the rest of the network infrastructure was running fine, I thought it was one of those random pesky Unifi downtimes that happens once in a blue moon.

After a couple of hours I couldn’t take it anymore and decided to investigate and observed the primary gateway is slowly chugging along. Well, a quick hard reboot should fix it…

… Not.

Then I noticed my secondary gateway has high CPU usage as well – so a soft-reboot should do the trick…

… Nope.

Tried to run PING to Google (el classico!) and the response was quite odd – on-and-off responses.

I thought something was definitely wrong with the network, and boy I was pretty damn right.

A quick peek at the network monitoring tool shows 5 MBps activities on my network servers, it’s a magic number just enough to drown the Unifi link. Something is hogging the network.

So I disconnected my IP masquerade from the network – and Internet access (on the server) immediately restored.

Time to find the bad boy – DARKSTAT to the rescue. In a few seconds, the wolf among the sheep is found (more like a zombie, that fella was happily flooding the network with RDP requests). First thing that came across my mind is to immediately configure the firewall to drop all packets coming from the machine.

Yep, this time it fully restored the Internet access in our network.

ZENMAP showed our target as a Windows 2003 Server SP2 machine with a handful of opened ports. From the outside it doesn’t seem vulnerable.

… From the outside that is…

I saw RDP was opened so the most logical thing to do is to try to remote access that sonnovabeech with the most powerful account available and the most stupid password known on Earth.

Jackpot – Administrator privileges granted on the first try itself. As expected, I was greeted with loads of suspicious looking processes and a very nicely placed backdoor (LogMeIn) upon firing up the task manager.

Let’s kill this beach before it lays eggs.

Next time I’m going to audit each !@#$ server that is going to be placed on the network.

Friday, May 17, 2013

仕事の日々#3: VB.NET anonymous methods

What we lazy coders do in C# when dealing with a non-STA WinForm on another thread is usually:

Invoke((MethodInvoker) delegate
{
    txtSomeLabel.Text = "Foobar!";
});

Today I had to deal with a piece of code written in VB.NET, and here’s how it’s done:

Invoke(
   Sub()
      txtSomeLabel.Text = "Foobar!"
   End Sub
)

No casting is required as BASIC is not a strongly typed language.

It also works with anonymous methods with parameters, you just have to use Function in place of Sub.

Tuesday, May 14, 2013

仕事の日々#2: C# byte & Java byte

Although C# could be said a rip off from Java, I would understand why Microsoft made the choice to be different from Sun – because it’s downright confusing when doing low level processing if it’s done the Java way.

Aside from String/string, boolean/bool, endianness etc. beginner coders migrating from C# to Java or vice versa would most definitely make this mistake – C# byte and Java byte

In C#, a byte is an 8-bit unsigned integer (unsigned char for you C/C++ dinosaurs out there), while a byte in Java is an 8-bit signed integer (signed char).

What does that mean?

Well, it meant you’ll screw up your code if you ignore this difference.

C#

for(byte i = 10; --i >= 0; )
   Console.WriteLine("foo");

Java

for(byte i = 10; --i >= 0; )
   System.out.println("foo");

For a more hidden problem:

C#

short i = 0xFF;
byte j = (byte) 0xFF; // (byte) is optional
if(i == j) Console.WriteLine("Yay!");
else Console.WriteLine("Nay!");

Java

short i = 0xFF;
byte j = (byte) 0xFF; // (byte) is mandatory
if(i == j) System.out.println("Yay!");
else System.out.println("Nay!");

If you’re not aware of this problem, your program will most probably compile, probably pass all your tests but randomly fails after live deployment.

Captain Obvious says:
“The samples above behave differently for C# and Java.”

Oh, to make things worse, there’s no “unsigned” keyword in Java. Great. Static casting like a magus.

仕事の日々#1: OIC & ORACLE_HOME

Here’s the scenario: I’m writing a setup deployment (installer wizard) project that uses Oracle on a 64-bit system.

Naturally, the installed Oracle Client on the target system is 64-bit. Because Microsoft Installer Executive (MSIEXEC) by default runs in 32-bit mode, and building a dedicated 64-bit project is rather tedious, I’ve resorted to including the Oracle Instant Client into my setup project file.

During setup the wizard will invoke sqlplus to run various database installation scripts. When testing my freshly baked project on the test bed, sqlplus execution ended with code 1.

Well, the problem is: my scripts are configured to exit with code -1 if errors occur during execution. Out of sheer programmer instinct I inspected my setup logs and extracted the specific failed command line out to run it on the console.

The command worked fine.

For a few hours I’ve tried to find out the culprit – changing PATH, altering the script to use “connect”, changing executing user… It just wouldn’t work.

Then I tried redirecting the standard output and error streams (which are originally hidden) from the process into my log file as well.

Sqlplus said:

Error 6 initializing SQL*Plus
Message file sp1<lang>.msb not found
SP2-0750: You may need to set ORACLE_HOME to your Oracle software directory

The error message was very helpful, thank you.

I then checked my default environment variables using “echo %ORACLE_HOME%” – the values looked okay.

So what went wrong?

Apparently some bloody smart component written by a bloody smarty pants changed the ORACLE_HOME environment variable to the current execution directory, which is obviously not ORACLE_HOME.

I did not touch environment variables in my code – so that leaves Oracle Instant Client as the culprit.

Once I changed ORACLE_HOME to the values I find in registry right before launching sqlplus, everything worked like a charm. Bloody Oracle developers.

Yes, this affects imp.exe too.