So I'm attempting to recompile netcat from it's windows ported source to by pass antivirus signatures. The compile goes well and exits with no warnings however whenever I try to invoke the nc -L command, when I try to connect to the machine from another computer and then close the session on the other computer, I get a WIN32 Unhandled exception and it shuts down nc on the host computer and thus I can no longer connect back to it. Has anyone successfully recompiled the windows source with a working -L flag? It seems the nc.exe that ships with the source works fine with -L so I don't understand what the issue could be.

05-04-2009, 08:03 AM

xorred

that is normal. You cannot listen forever. Try that in linux, listen, connect from another pc, drop session... host nc exits.

05-04-2009, 08:07 AM

aspekt9

The -L flag is supposed to allow listening after someone connects and disconnects, and it works properly on the exe delivered in the folder already. Now when I try to compile it myself, it forcefully closes netcat on the host and gives an error when I connect and then disconnect, which it should not do, and I cannot figure out why.

So I'm attempting to recompile netcat from it's windows ported source to by pass antivirus signatures. The compile goes well and exits with no warnings however whenever I try to invoke the nc -L command, when I try to connect to the machine from another computer and then close the session on the other computer, I get a WIN32 Unhandled exception and it shuts down nc on the host computer and thus I can no longer connect back to it. Has anyone successfully recompiled the windows source with a working -L flag? It seems the nc.exe that ships with the source works fine with -L so I don't understand what the issue could be.

Funnily enough I was trying this myself last Friday. I didn't attempt the -L option, but I was getting crashes when transferring binary files between a netcat sender and listener. netcat would crash after the file transfer was finished.

Didnt get to spend too much time on this to really figure out what was going on. I compiled with Visual C++ 2008 Express on XP, trying a variety of different options in the makefile to see if that made any difference (nope). I was in the process of trying to compile with mingw when I got interrupted.

Which compiler did you use and did you modify the makefile in any way?

Edit: And yes, kazalku is right, -L allows you to listen harder (or re-listen after disconnect) , this is a Windows nc option and is not available on the standard Linux nc.

05-05-2009, 12:40 AM

aspekt9

Quote:

Originally Posted by lupin

Funnily enough I was trying this myself last Friday. I didn't attempt the -L option, but I was getting crashes when transferring binary files between a netcat sender and listener. netcat would crash after the file transfer was finished.

Didnt get to spend too much time on this to really figure out what was going on. I compiled with Visual C++ 2008 Express on XP, trying a variety of different options in the makefile to see if that made any difference (nope). I was in the process of trying to compile with mingw when I got interrupted.

Which compiler did you use and did you modify the makefile in any way?

Edit: And yes, kazalku is right, -L allows you to listen harder (or re-listen after disconnect) , this is a Windows nc option and is not available on the standard Linux nc.

Good to see someone in a similar situation, I tried using VC++ 2008 as well. I also tried, cygwin and minGW but to no avail, all would compile correctly but the -L issue still occured. I have an inkling that it might be the newer VC++ because for both those compilers, they relied on binary files in the VC++ folder (I merely added the VC++ PATHS to the compiler PATHS in order to get cl.exe and link to work, that was the only way I could get it to compile) I'm wondering if maybe an older version of VC++ would produce different results, I don't see why it should but it's worth a shot I suppose.

05-05-2009, 01:01 AM

imported_cybrsnpr

I have a modified version of crypcat HERE that compiles fine under windows and linux. The windows version requires Visual Studio 6. As for using VC 2008, I think that may be your problem since netcat is pretty old.

05-05-2009, 01:56 AM

imported_vvpalin

Quote:

Originally Posted by cybrsnpr

I have a modified version of crypcat HERE that compiles fine under windows and linux. The windows version requires Visual Studio 6. As for using VC 2008, I think that may be your problem since netcat is pretty old.

that is definitely a keeper thanks ;)

05-05-2009, 04:18 AM

lupin

Quote:

Originally Posted by aspekt9

I'm wondering if maybe an older version of VC++ would produce different results, I don't see why it should but it's worth a shot I suppose.

I think there is a reasonable chance this may work. There were a bunch of unsupported compiler options and deprecated call errors when I did my compile, and my executable ended up a fair bit bigger than the original, so something different was definitely going on there...

I think I have a version of VS 6.0 somewhere around, and I may try compiling with this if I can find it. If you do try this, can you report back on your results?

Also, how did you go about compiling in mingw? I was in the process of changing the compiler options in the make file to try and get this to work when I got interrupted by other things. Did you modify the make file or did you compile the objects separately? Any chance you could share what you did? :)

Quote:

Originally Posted by cybrsnpr

I have a modified version of crypcat HERE that compiles fine under windows and linux. The windows version requires Visual Studio 6. As for using VC 2008, I think that may be your problem since netcat is pretty old.

Any idea off the top of your head if this cryptcat mod allows you to not use the cryptography features of the product? So basically can it act like a regular nc and create a non encrypted tcp socket?

I tried sending files between another Windows version of cryptcat (without specifying a secret with -k) and nc and couldn't get them working together. In addition, when I did perform a large file send (of a memory dump) between two cryptcats, a significant amount of delay was introduced by the encryption.

If you're not sure I'll run a test later on and report back with the results...

05-05-2009, 04:28 AM

imported_cybrsnpr

encryption is required for my version. You can't turn it off. If you create a socket with it, it will require some version of cryptcat (any should work since I'm still using cryptcat's std blowfish lib). You need to specify a key no matter what version of cryptcat you use since by default, there is a key built in. With most versions of cryptcat that I used, the key was "metallica". I'm not sure what your versions key is. Just specify the -k and a key (-k should be available in all versions of cryptcat). Any encryption will introduce delay, but I never really noticed a large lag when I xfered files.

EDIT: I also want to point out that this version has a custom transport. If you are using this version for each side of the conversation, you can use the *69 custom shell to transfer files back and forth.