

Port scanner written in x86 assembly (32-bit) - edma2
https://github.com/edma2/asmscan

======
tptacek
Hack value: moderate to high. It's nice assembly code.

Practical value: low to negative. This port scanner is slower than a
competently written scanner in C or probably even Ruby, because it has a
static timeout and no dynamic timers.

Someone else here pointed out that a port scanner is pretty much the most I/O
bound application possible. That's true. The performance wins in port scanning
probably mostly revolve around maintaining sliding windows and trying to infer
timeouts.

It is probably a really excellent technique for getting comfortable with
assembly (I'm not, at least so much that I could write this code as cleanly as
the author). I wonder what some other good short assembly versions of Unix
programs are. Maybe a plugboard proxy.

~~~
edma2
Actually, if you run asmscan as root, it pings the target host first to
estimate the timeout value. Otherwise you're out of luck, because you need
root privileges to send raw packets.

IMO, it is quite fast with this feature.

You're right, I wrote this for educational purposes. nmap is hard to beat ;)

------
to3m
Oh... indented assembly language. Is this, like, a 21st century thing?
Everybody I know (including me) who started in the 20th century just naturally
writes their assembly language out at the same indentation. I'm rigorous about
my C indentation, but it never occurred to me that it would be useful for
assembly language too. (And in fact I'm not sure that it is :)

I'm not quite sure what this might mean.

Probably just that I'm old.

~~~
mahmud
It used to be called "Structured Assembly Language"; it had huge proponents in
the 80s, even gurus who were trained in Pascal and Ada and wanted to take
structure programming to the mainframe.

On the PC, various assemblers added "high-level" macros; Turbo Assembler had
.if, .while and .struct type macros. Even processor manufacturers where on the
bandwagon; that's why the x86 has the ENTER and LEAVE instructions, to make
function calls "trivial", at the risc of performance.

In the 90s you had at least on academic (Randal Hyde) who wrote HLL, high-
level assembly language, and along with it a very successful series of text-
books on indented assembly.

Anyhoo. On the x86 side at least, the Netwide Assembler was created by a bunch
of volunteers, one of its initial goals was to remove high-level cruft and
make assembly straightforward again.

Personally, I think assembly is something best reserved for fun, one-off
hacks, and inner-loops.

~~~
aaronbrethorst
> at the risc of performance

that's some good punning.

------
mansr
Pointless other than as an exercise in asm writing. A port scanner is one of
the most I/O-bound applications imaginable.

~~~
alecco
It doesn't depend on libc. It might be useful in penetration tests or other
particular scenarios (port scanning being quite particular job in itself).

~~~
tptacek
Aren't there tens of portscanning shellcode eggs already?

------
lallysingh
Normally I wouldn't ask. I really wouldn't.

But why? Why's this better than gcc -S?

It's not exactly CPU-bound. For not needing libc, your own implementation of
syscall() isn't exactly hard, if you can't just statically link in libc as-is.

------
delinka
It makes calls into [C?] libraries that handle the actual networking. Not
quite as impressive as I was hoping. "...in assembly" tends to make me think
"implemented completely and entirely in assembly." I know, not necessarily a
common connotation, but that's how _my_ brain works.

At any rate, my point is you can "glue" functions from libraries together in
any high-level or low-level language you want and make whatever app you'd
like. I'm having trouble seeing the novelty in writing the app in asm but
letting the libs do the heavy (and perhaps less-optimized) lifting.

~~~
ajross
It's making (linux) system calls via a software interrupt. There's no
integration that I see with anything above the kernel.

But yes, I suppose it's "merely" gluing together straightforward system calls.
A port scanner doesn't by itself have a lot of complicated logic.

------
outside1234
in 1985 i would have loved reading this end to end. now, looking at assembly
makes me want to stab myself in the eye with a fork. twice.

does that make me old?

now, where is that Scala book and my glasses.

------
jevinskie
This reminds me of the tool that HBGary was planning to write.[0] They thought
that using assembly would make it a super-duper fastest-ever scanner! The
author of this tool clearly doesn't have the same delusions, even noting that
its about as fast as nmap.

[0]: <http://news.ycombinator.com/item?id=2315564>

Edit: Turns out that HBGary didn't mention writing it in assembly language but
instead wanted to use LFSR (careful, they're mathy!!) to parallelize a scan
and make it "FAST AS SHIT". I think I was getting confused with Steve
Gibson's, another "security" blowhard, NanoProbe project.[1]

[1] <https://www.grc.com/np/np.htm>

~~~
frou_dh
Hey, Steve Gibson is a good guy. His long-running show is by far the most
worthwhile on the fluff-based TWiT network.

~~~
sciurus
The last time I saw a Steve Gibson discussion here, I bookmarked a few good
links.

<http://attrition.org/errata/charlatan/steve_gibson/>
<http://radsoft.net/news/roundups/grc/>
[http://allthatiswrong.wordpress.com/2009/10/11/steve-
gibson-...](http://allthatiswrong.wordpress.com/2009/10/11/steve-gibson-is-a-
fraud/)

~~~
mkr-hn
I stopped reading what he had to say after his campaign against raw sockets in
Windows.

------
veyron
I imagine it could be used to circumvent whatever forensic tools that some
organizations use. For example, in the very recent case involving Yihao Ben Pu
and Citadel:

'... Pu had also downloaded a "port scanner" program to his Citadel computer
...'

text of complaint: <http://www.scribd.com/doc/63606232/Citadel-vs-Yihao-Ben-
Pu>

