grep vs. grab

I pushed my experimental grep version to github.
It features only small amount of options, but it speeds
out grep's on large directory trees, in particular if
you have a fast HDD or SSD, where you can be as
twice as fast.

What is a dzug?

I moved the dzug.c from the null directory to xSports,
where it actually belongs to.

What is a D-Zug? Besides being an exploit for CVE-2012-3524,
a D-Zug (german: Durchgangs-Zug) was a fast kind of train
in the 70's and 80's. Nowadays its obsoleted by high speed
trains like ICE (similar to TGV in France).
dzug.c, also kind of a 80's style of living, integrates a lot of
attack vectors to proof CVE-2012-3524 exploitable.
There exist a lot of flavors of dzug.c, so
if this PoC version is not working for you, it means
indeed nothing. Its also not bound to Linux. Theoretically any
UNIX running DBUS is at risk.

New Android lophttpd binaries

I just compiled lophttpd 0.98 for Android
(without SSL support). Available here.
Nice, isn't it?

lophttpd https trickery

After better separating the client state machines
inside lophttpd yesterday, by encapsulating the
send and recv functions, it was easy to add HTTPS
support into lophttpd today (TLSv1 actually).
Everything works as normal, single threaded and non-blocking.
You will of course lose some performance compared to
plain sockets (as with any crypto) and also the sendfile() needs to be
emulated, but it should still give good performance.

I've got a new smart phone

See above! :p

I get a lot of comments about old Android jailbreaks,
but I can just repeat myself: If they are not working,
there is little chance I can help you. The bugs
are just fixed over a year ago. Thats the nature of
a jailbreak.

lophttpd trickery

I made some optimizations for lophttpd to dynamically
adjust the chunksize that is passed to sendfile().
Its based on the amount of data that is already
in the TCP send queue. The problem is that the web
server can be too fast in pushing data to the client,
so the send queue starts filling until its full and
the connection times out and is dropped as poll() wont
report possible events on it. You can adjust your send
buffer sizes (up to some extent), but increasing the timeout is no good idea,
as evil clients might just not read the pending data.
This solution avoids that and still gives you enough tuning
parameters (-S, -N, -DSTATIC_SEND_SIZE_COMPUTATION) in case
you know better.:D Much of the performance parameters
depend on the actual hardware/network configuration
(fast CPU vs. slow network, fast CPU and Gigabit LAN,
slow receivers etc. etc.). For few connections like
1000 simultaneous downloads, this is no issue at all.
The fun begins with 10k connections and its not about
CPU usage, but having as few connection drops
as possible for long lasting downloads. However the
default values should fit for most scenarios.


If you have a good test environment for c10k, let me know.

optimizing dd

I was feeling like writing a new paper, but this time not
about boring security topics.
Rather about how dd could be optimized if large files
are copied. You can read it here and find an implementation
here.


If you want to see your logo in the Credits section or
like to sponsor future similar research, let me know.

web server trickery

I added new switches to lophttpd. -E keeps connections
open even after failed GET/HEAD requests, since lot of
browsers seem to ignore the HTML base tag when fetching
/favicon.ico. This saves overhead of accepting new connections
in such a case and also speeds up a yet unimplemented
feature which I have in mind when it comes to run
lophttpd on Android.
-Q keeps the rand token for file uploads secret, which allows
you to implement storage-only service in case you want to
review uploaded documents before you pass them to the public.


frontend, the lophttpd reverse proxy now cleanly separates
between header and body of server replies which is also
needed for future features such as quick URL filtering.


All in all, a good release to run a web server in hostile
environments with low overhead.

more sshttp trickery

sshttp is now able to multiplex SSH and SMTP traffic,
due to protocol leetness (see above screenshot).


As SMTP requires the end of the line to be CRLF, but
SSH (at least OpenSSH) accepts a bare LF, the above
example is actually one valid line for SMTP, and one
valid line for OpenSSH (the "220 ..." is skipped by
OpenSSH since it does not start with SSH-).


This trickery allows sshttp to display one banner in two
and decide on the next incoming packet where to actually
connect to. I tested the setup with Postfix and OpenSSH
and it obviously wont work with SMTP multi-line banners.


The README and Makefile contains the few simple steps that
are necessary to run smtpd and sshd on the same port.


Notice, that its usually not possible to mux protocols
that both start with a server banner.

lophttpd news

Besides new features like file uploads, serving
of /proc and /sys files and some speed
enhancements, lophttpd now also has got a logo:

Fear my gimp skills. Its all in the cloud.
The frontend part is still experimental though.


And always remember that the other end of the cloud
is always connected to a smartphone. :p