Everything, Everything - December 2013

2021: January
2020: J F M A M J J A S O N D
2019: J F M A M J J A S O N D
2018: J F M A M J J A S O N D
2017: J F M A M J J A S O N D
2016: J F M A M J J A S O N D
2015: J F M A M J J A S O N D
2014: J F M A M J J A S O N D
2013: J F M A M J J A S O N D
2012: J F M A M J J A S O N D
2011: J F M A M J J A S O N D
2010: J F M A M J J A S O N D
2009: J F M A M J J A S O N D
2008: J F M A M J J A S O N D
2007: J F M A M J J A S O N D
2006: J F M A M J J A S O N D
2005: J F M A M J J A S O N D
2004: J F M A M J J A S O N D
Tuesday 31st December, 2013 23:55
Happy New Year everyone!
Nmap x64 Works!
Tuesday 31st December, 2013 09:51
I gave it a try and it works. In case anyone wants to do this in the future, here's what I did to get there:

Visual Studio 2010 Express Edition

The free version doesn't natively support x64. You need to download the Windows 7.1 SDK.

After you've installed the SDK it seemed to break normal x86 compilation using the original v100 platform toolset so I had to select the Windows7.1SDK afterwards.

I also installed Visual Studio SP1 and the x64 compilation fix (KB2519277), as it seems Microsoft accidentally/intentionally crippled x64 support.

Then you need to add support for an x64 target to Visual C++ (x64 is visible in the list below because I'd done it already):

Add an x64 Release

Create a new platform and copy the existing Win32 settings:

Select x64 from the list and copy from Win32

Now you need to configure each of Nmap's Visual C++ projects to use the SDK instead:

Change the platform to the SDK

There's pretty good notes (and an honest warning) available here: http://msdn.microsoft.com/en-us/library/9yb4317s(v=vs.100).aspx


The 64-bit application will need to use 64-bit OpenSSL DLLs. I grabbed the latest version (1.0.1e) from the OpenSSL website (thankfully the sources hadn't been hacked, although the website had recently been hijacked). I also grabbed the latest version (ActivePerl- of ActiveState Perl as you'll need it to configure some stuff before compilation. It turns out that Express edition, because it's crippled, isn't quite as straightforward as running three or four commands (many thanks to 3noch for doing the heavy lifting). In the end I had to add the SDK to the PATH so it could find the right binaries (ml64.exe in particular). I also ran a small batch file that, after I looked at it in more detail, called setenv appropriately (e.g. "setenv /Release /x64"), otherwise I think it defaults to x86 based on the error messages I saw.

In summary, after setting the PATH to include the right directory (e.g. "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin" and maybe "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64" although I don't appear to have added the latter), you need to run something like:

setenv /Release /x64

This should make the text green and say something like:

Setting SDK environment relative to C:\Program Files\Microsoft SDKs\Windows\v7.1\.
Targeting Windows 7 x64 Release

Then you need to run:

perl Configure VC-WIN64A
nmake -f ms\ntdll.mak

Hopefully that works. I'm a bit hazy as to how I did it as I had to Google a lot of things after a bit of trial and error to try and get it working.

So after building the DLLs (and other files), you'll need to overwrite the files in "nmap-mswin32-aux\OpenSSL\bin", "nmap-mswin32-aux\OpenSSL\include" and "nmap-mswin32-aux\OpenSSL\lib". One thing I failed to immediately spot was that the header files in the includes directory within the OpenSSL source file are all 0KB in size! It seems that none of the OpenSSL 1.x downloads contain an includes directory with any proper files. There is, however, an inc32 directory that looks pretty similar (and seems to be what Indy Pit Crew used when creating their 0.9.8g x64 binaries). I copied those files over the top of the includes directory in nmap-mswin32-aux. I'm assuming that I compiled this okay, openssl.exe seemed to work fine.


You'll need to switch the WinPcap libraries for the x64 versions you can find in their developers pack. Again, I just copied over the relevant files from the 4.1.2 pack ("WpdPack\Lib\x64\Packet.lib" and "WpdPack\Lib\x64\wpcap.lib" and copied across the latest files from "WpdPack\include" for good measure), overwriting the 32-bit versions.


Okay, so I cheated here. I know these third party files (libsvn) are only used by nmap-update so I didn't bother doing this. For now, I just want to get the main nmap.exe (and ideally ncat and nping) working.


Again, I cheated here and ignored the minefield that is Python. Zenmap is the sole reason why the "vcredist2008_x86.exe" file exists in the ZIP and setup files. I find Zenmap a bit too quirky on Windows and only really use it to help generate the script arguments that I paste into the command line version. The executable is generated using py2exe, which I have little control over. If you really want a 64-bit version you can probably just run the "zenmap" Python script using the "X86-64" version of Python 2.7.6.

Compiling Nmap

Because I'd overwritten the existing x86 files with x64 versions, I didn't really change any project settings (I just had to change the platform to the Windows 7.1 SDK for every project). Also, if you haven't done this already, you'll need to make sure that you have the latest Visual C++ 2010 SP1 x64 redistributables installed so you can run what you've built. I appear to have successfully built an x64 version of Nmap 6.41SVN r31943 (I realise this dates back to August; perhaps I'll try a newer revision, although I think the very latest code might not compile properly on Windows right now).

Further Work

Obviously, the first thing is to work out why I get the horrible error message and fix that. I've basically given up for now, but I'll take another look at some point (April 2014?).

EDIT: I fixed it! In short, I hadn't included the OpenSSL DLLs alongside the executable. Once I'd copied the two DLLs across, it ran fine! This is probably my fault, as I use a batch file to compile Nmap (to avoid installing cygwin) and I think it was grabbing a copy of the DLLs from a different directory (which was empty).

The setup file still needs to be updated to include vcredist_x64.exe for x64 (instead of the x86 version) and the default location could put files in "Program Files" instead of "Program Files (x86)". It would make sense to have separate x86 and x64 installers to save people from downloading the large vcredist files (having two is bad enough, but a third version that's not even used on x86 versions is a waste of bandwidth). Nmap's WinPcap installer already supports x64 (as I got that working properly years ago) so at least that bit's simple and we can include the same file in both Nmap setup files.

For now, because I haven't updated the installer, here's the ZIP file containing everything you need: Nmap x64 4.61SVN r31943.
Monday 30th December, 2013 22:21
Just made a movie of my #2013 on Twitter: https://t.co/X2BnukVGys What's yours look like? #Vizify
Monday 30th December, 2013 12:15
Just caught up on the Arsenal match. Lee Probert was a poor and inconsistent referee. But we won 1-0 and we're top of the league! :D
Sunday 29th December, 2013 09:09
"@BBCOne: Our #MrsBrownsBoys Christmas special was the most watched programme on Christmas Day." What is wrong with this country? #sadface
Nmap x64
Sunday 29th December, 2013 01:59
Random late night thought, how easy is it to compile Nmap as a 64 bit Windows application? It can be compiled okay on Linux, but I don't think anyone has tried it with Windows even though it probably only involves targeting x64 when building things. The third party libraries might be more of an issue, but OpenSSL must support 64 bit, which might only leave some random things that aren't essential.

Why? Because Windows x64 has been around for a decade and at some point x86 versions of Windows will disappear (Server 2008 R2 onwards are x64 only). Also, big scans are more likely to work without running out of memory. Maybe.
Saturday 28th December, 2013 08:13
NTP distributed reflection DoS attacks abusing "monlist": https://t.co/lkLfT9PigK
Friday 27th December, 2013 21:09
Watched Superman for the last three hours. Turns out I could have just watched the first ten minutes of Superman 2 instead.
Friday 27th December, 2013 00:04
Had to swap GTX 780 for old 275 as new cudaminer has killed it. I hadn't disabled any power/voltage limits, just failed under heavy use :(
Thursday 26th December, 2013 19:57
New version of cudaminer looks significantly quicker (but autotune looks broken on my GTX 780). Now casually mining FTC about 45% faster!
Thursday 26th December, 2013 16:40
Podolski deserves a goal, he's turned the game around. Giroud did well with assist. Theo has stepped up this half, hope he gets a hat trick.
Sunday 8th December, 2013 12:44
Wow, I must have been lucky. I solo mined a block of 200 Feathercoins in a couple of days (should have taken 18).
Thursday 5th December, 2013 08:39
"bot systems are within 20 metres of each other. A painfully slow speed of just 20 bps was achieved using the method" http://t.co/lTPvJU4pS4
Wednesday 4th December, 2013 08:47
China want free extension of extended support for WinXP. Not going to happen. Took a year to get our start button back in Win8. #StubbornMS
© Robert Nicholls 2002-2021
The views and opinions expressed on this site do not represent the views of my employer.