Tuesday 18 April 2017

Punycode phishing alert for Google Chrome / Firefox and the fix

What's Punycode? 

Internet host names should have ASCII characters only so RFC introduced Punycode to encode Unicode characters using ASCII codes to workaround that limitation and to use Unicode characters on domain names. Even without recognition of this feature for many people, most modern web browsers already support this so that the decoded Unicode characters appear on the address bars! It's easy to imagine what can happen if this feature is used for bad purposes - phishing. 

Test
Click this link. https://www.xn--e1awd7f.com/ (Don't worry, it's a good site that helps you to test your browser) If it directs you to a site that looks like 'https://www.epic.com', your browser is invulnerable for the attack. As you already guessed, the characters appear on the address bar are not ASCII, but non-English Unicode characters that look similar to ASCII ones. The following screenshot is from my Chrome that was not ready for detecting the situation (invulnerable). 


Fix/Workaround 
Firefox has a setting to disable decoding of Punycode characters. 
  1. Type about:config in address bar and press enter.
  2. Type Punycode in the search bar.
  3. Browser settings will show parameter titled: network.IDN_show_punycode, double-click or right-click and select Toggle to change the value from false to true.
Google Chrome has no setting yet (as of 18 Apr 2017 ), but luckly there is an extension to help you - Punycode Alert (https://chrome.google.com/webstore/detail/punycode-alert/djghjigfghekidjibckjmhbhhjeomlda ). With this extension, it alerts you when you visit a Punycoded site like that. It's not perfect as it doesn't block you to visit phishers but it's million times safer than using nothing, until Google releases a new Chrome version that deals with this. This is what appears when you visit there with the extension turned on. 

References

Evernote helps you remember everything and get organized effortlessly. Download Evernote.

Monday 10 April 2017

Fixing "Error C2059: syntax error : '('" in xlocale

Introduction

When you use std::string in a relatively large project, you may see the following error message that is hard to understand. 


The source code block complained about this is like this: 


The compiler didn't like the line of 'global(const locale&);' which looked just normal. This compiles with no error if you configure a new project, which makes it look more strange. 

Troubleshooting

The problem is simply caused by the 'global' keyword. Yeah, the project actually uses this keyword for another purpose. For my case, it is defined like this to indicate the function is globally referenced: 


Now it's very easy to understand - the 'global' in xlocale has been replaced by 'nothing' so that the line must have been transformed like this:

static _MRTIMP2_PURE locale __CLRCALL_PURE_OR_CDECL
       (const locale&);

As you can see here, the function definition on xlocale is certainly corrupted now by the 'global' keyword defined already for another purpose.

Fix

You may like to remove the definition of 'global' that looks unnecessary, but unfortunately it was used in so many places in my case that I couldn't do this. But now you understand the reason (there exists '#define global' somewhere before including <string>), we have three workarounds at least. 

  1. Use #undef before #include <string>, or 
  2. Remove #include <string> from your new header file and reference it on the cpp file, or 
  3. Do '#include <string>' (or including the header file that does '#include <string>' before having #define global (or including the header file that does '#define global'). eg.
    • (TestVictim.cpp) 
      #include <Windows.h>
      #include ....                          // (other system includes)
      #include "ImIncludingString.h"         // has #include <string>
      #include "ImDefiningGlobal.h"          // has #define global

#3 is probably the best way as it has no affect on other source files. 


Evernote helps you remember everything and get organized effortlessly. Download Evernote.

Wednesday 17 August 2016

How to create "Open Developer Command Prompt for VS2015 Here" context menu on Windows 10

As a developer, sometimes I want to open up an elevated command prompt with all developer command line utilities enabled at once.

Actually there are a few registry tweaks to open up an "elevated command prompt" here, but none of them that I found supported Visual Studio command prompt. So I made another tweak on top of the tweak to enable this. Enjoy! 

** Try this at your own risk ** 

  1. Save the following contents on a reg file. eg. VSDEVCMD.REG
  2. Run the reg file.
  3. Click "Yes" on the warning dialogue. 

Windows Registry Editor Version 5.00   

[-HKEY_CLASSES_ROOT\Directory\shell\runas]   

[HKEY_CLASSES_ROOT\Directory\shell\runas] 
@="Open command window here as Administrator" 
"HasLUAShield"=""   

[HKEY_CLASSES_ROOT\Directory\shell\runas\command] 
@="cmd.exe /s /k \"pushd \"%V\" && call \"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\Tools\\VsDevCmd.bat \"\""

[-HKEY_CLASSES_ROOT\Directory\Background\shell\runas]   

[HKEY_CLASSES_ROOT\Directory\Background\shell\runas] 
@="Open command window here as Administrator" 
"HasLUAShield"=""   

[HKEY_CLASSES_ROOT\Directory\Background\shell\runas\command] 
@="cmd.exe /s /k \"pushd \"%V\" && call \"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\Tools\\VsDevCmd.bat \"\""

[-HKEY_CLASSES_ROOT\Drive\shell\runas]   

[HKEY_CLASSES_ROOT\Drive\shell\runas] 
@="Open command window here as Administrator" 
"HasLUAShield"=""   

[HKEY_CLASSES_ROOT\Drive\shell\runas\command] 

@="cmd.exe /s /k \"pushd \"%V\" && call \"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\Tools\\VsDevCmd.bat \"\""

Evernote helps you remember everything and get organized effortlessly. Download Evernote.

Monday 2 March 2015

C# TimeSpan format to always display "hh:mm:dd" safely

Introduction

TimeSpan class has a very convenient method of "ToString()" which converts the span to a fully-flavoured string of "[d.]hh:mm:ss[.ms]", but sometimes this comes too much. I needed a way to just cut off "ms" values as we didn't care about milliseconds in most cases. More than that, the "days" may be excessive as it makes it complex to calculate hours. Say, I needed a way to display, for instance, "1 day, 10 hours, 17 minutes, 36.789 seconds" of timespan value as "34:17:36". 

Microsoft did not give us a predefined format to achieve this simple goal - so I made this by myself. 

Implementation 

private static string GetFormattedTimeSpanString(TimeSpan timeSpan)
{
    const string TimeSpanFormat = "{0:D2}:{1:mm}:{1:ss}" ;                       // {0:D2} is to display at least two digits always 
    return string. Format( TimeSpanFormat, (int)timeSpan.TotalHours , timeSpan);// (int) casting is needed or it may display fraction
}

Test

public static void Main( string[] args)
{
    var timeSpans = new[]
  {
      new TimeSpan(99, 01, 01, 01, 99),
      TimeSpan. FromMilliseconds(12345),
      TimeSpan. FromSeconds(123456.789),
      TimeSpan. FromTicks(398583838521),
      TimeSpan. Zero
  };

  foreach ( var timeSpan in timeSpans)
  {
      Console. WriteLine( "Unformatted: " + timeSpan);
      Console. WriteLine( "Formatted: " + GetFormattedTimeSpanString(timeSpan));
      Console. WriteLine();
  }
}

Test Output



Evernote helps you remember everything and get organized effortlessly. Download Evernote.

Monday 7 July 2014

Strong name signing fails on C++/CLI project on Visual Studio 2010 SP1

Introduction

On C++/CLI projects, we may specify a strong name key for the output module on AssemblyInfo.cpp, like this:

[assembly: AssemblyDelaySign(false)];  
[assembly: AssemblyKeyFile("..\\strong.snk")];  

The first line explicitly sets that we are not going to use delay-signing whilst the second line specifies the key file to sign with. This syntax is legit and should produce a strong name signed .Net module. However, sometimes it doesn't, with producing this warning: 

mt.exe : general warning 810100b3: ??????.dll is a strong-name signed assembly and embedding a manifest invalidates the signature. You will need to re-sign this file to make it a valid assembly.

You might think let's just ignore it, but probably this will make your runtime crash upon loading this module with "System.IO.FileLoadException" which complains about the missing strong name signature on the module. Again - I definitely set the syntax to put a strong name key in the module but the file is not produced so. What's going on inside? 

Under the bonnet 

Let's focus on the warning back - "embedding a manifest invalidates the signature". It sounds like the module had been successfully built with the given strong name key, but then a manifest was embedded, which broke the strong name signature. Perhaps it's possible not to embed a manifest but this is not a right thing to fix the problem. 

So what's happening? Does Visual Studio support a syntax which is not fully implemented? Maybe, yes. The syntax should automatically re-sign the assembly after embedding a manifest, but by some reason it does not do that, yet. Even worse, the Visual Studio versions lower than 2010 did not generate that warning at all so that the developers wasted much time to get to know what was going on there. 

Solution 

Having said that, all we need to fix (or workaround) the issue is to re-sign the module. 

1. Define a post-build custom action using SN.EXE

On Visual Studio 2010 command prompt or Microsoft SDK command prompt, SN.EXE (Strong Name Tool) is available for strong name signature works. Open this link http://msdn.microsoft.com/en-us/library/k5b5tt23(v=vs.100).aspx for details of this utility. Please note that the options of that tool are case-sensitive

To re-sign the module, this syntax can be used on a new custom post-build event (Project property - Configuration Properties - Build Events - Post-Build Event):

  Command Line: sn.exe -Ra "$(TargetPath)" <snk file name/path>  

"-Ra" option is to re-sign an assembly which is already signed, which means AssemblyInfo.cpp should still have the strong name key syntax as shown on "Instruction". 

2. Set "Key File" and "Delay Sign (false)" on project properties

Visual Studio introduced "Key File" and "Delay Sign" fields on C++/CLI projects, which can be used to set a key file explicitly. (Project property - Configuration Properties - Linker - Advanced) Please don't forget that you should apply this on all configurations such as "debug" and "release". 
  • Set "Key File" as what you set on [assembly: AssemblyKeyFile] field on AssemblyInfo.cpp
  • Set "Delay Sign" to false
  • Mind you, the counterparts on AssemblyInfo.cpp should be removed as they conflict.
The build process automatically re-sign the module after embedding a manifest, if these fields are set correctly. Even if you have done this before, you may need to do this again because the internal field syntaxes on the project had been changed on Visual Studio 2010 SP1. If you already set that on RTM and upgraded Visual Studio 2010 to SP1, the settings won't be recognised. If your team has a mixed environment of RTM and SP1, it'll be better to upgrade all to SP1. 

If the problem persists, please refer to the links listed on "References" as many people encountered this issue and succeeded in fixing/workarounding it in various ways. 

References