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.
Thursday, August 16, 2012
Friday, July 13, 2012
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.
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.
Saturday, June 30, 2012
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.
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.
Friday, June 8, 2012
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.
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.
Thursday, April 26, 2012
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.
Friday, April 20, 2012
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
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
Thursday, March 22, 2012
libusi++ comeback
Polished some old code of mine, libusi++.
The C++ UNIX Socket Interface allows for easy capture
and release of IP, IP6, ICMP, ICMP6, UDP, UDP6, TCP, TCP6,
and ARP packets. This can be extended of corse. You can
register your own Layer2 functions (RAW sockets and IP/eth dnet
interfaces are included) to support any kind of NIC or
layer you wish. The default capture layer is libpcap.
Writing a multi protocol traceroute like program is as easy
as this.
The whole online documentation is here.
I use this lib for my own tools, and I will even change
the API if I face shortcomings. I'll try to keep that stable,
but the preference is that my own stuff is working.
You have been warned, so do not blame me for potential
changes. I know that this might be a bit un-social
on a social platform like github, but I used to have
no friends in social networks anyway. :)
I tested libusi++ on Linux and FreeBSD. When I started the
project >10 years ago, it even worked on OpenBSD.
The C++ UNIX Socket Interface allows for easy capture
and release of IP, IP6, ICMP, ICMP6, UDP, UDP6, TCP, TCP6,
and ARP packets. This can be extended of corse. You can
register your own Layer2 functions (RAW sockets and IP/eth dnet
interfaces are included) to support any kind of NIC or
layer you wish. The default capture layer is libpcap.
Writing a multi protocol traceroute like program is as easy
as this.
The whole online documentation is here.
I use this lib for my own tools, and I will even change
the API if I face shortcomings. I'll try to keep that stable,
but the preference is that my own stuff is working.
You have been warned, so do not blame me for potential
changes. I know that this might be a bit un-social
on a social platform like github, but I used to have
no friends in social networks anyway. :)
I tested libusi++ on Linux and FreeBSD. When I started the
project >10 years ago, it even worked on OpenBSD.
Tuesday, March 20, 2012
contribs
I'll put some of my smaller tools to the contrib github.
For now it contains ssh-sign, which allows to use your
existing SSH hostkeys to encrypt/decrypt (RSA)
or sign (RSA and DSA) files. You can verify the signed
files against your ~/.ssh/known_hosts after fetching.
This for instance allows to add integrity to pure HTTP
downloads if you have the SSH hostkey handy since you once
ssh'ed to that host.
For now it contains ssh-sign, which allows to use your
existing SSH hostkeys to encrypt/decrypt (RSA)
or sign (RSA and DSA) files. You can verify the signed
files against your ~/.ssh/known_hosts after fetching.
This for instance allows to add integrity to pure HTTP
downloads if you have the SSH hostkey handy since you once
ssh'ed to that host.
Friday, March 9, 2012
removing #ifdef's where possible
I am tickling developers about unreadable code, even
if its secure, the whole day at work. So its just fair
that I try to write code as clean as possible myself.
While there are different views on what resembles clean
code (in my personal view its the possibility to
add concurrency and new features without a large re-write
and still keeping an easy overview, IOW you can
refactor your code fast), conditional compilation is
usually seen as one of the evils.
Conditional compilation, aka #ifdef's, are even mentioned
in Effective C++. For small code snippets it might be acceptable,
but traditionally #ifdef's are used to make programs compile
on various UNIX flavors.That makes code unreadable and potentially
buggy, in particular if the #ifdef's guard different
call semantics for the same function, just like sendfile().
I decided to remove the #ifdef's alltogether from lophttpd,
by introducing a flavor namespace, and implementing a generic
function for each flavor. That moves the conditional
compilation logic to the Makefile or configure script.
Thats one of the commits for it.
No praying without paying: We buy the easy reading and clean
code by a little bit of code duplication for similar
flavors (for example sendfile() on Linux and Android flavor)
but thats at the time of writing/maintaining, not at runtime.
The other price is that you buy another function call
for code that could have been inlined. But as a whole,
thats cheap today, compared to the hassle one can have.
I am not banning #ifdef's, there are good reasons
for some of them and if you write code at the Linux driver-
(or rootkit-) level with a lot of API changes between
kernel versions, its sometimes the best way to go.
Yet, sometimes if you look at the code, it just feels wrong
and thats the point where you should change it.
if its secure, the whole day at work. So its just fair
that I try to write code as clean as possible myself.
While there are different views on what resembles clean
code (in my personal view its the possibility to
add concurrency and new features without a large re-write
and still keeping an easy overview, IOW you can
refactor your code fast), conditional compilation is
usually seen as one of the evils.
Conditional compilation, aka #ifdef's, are even mentioned
in Effective C++. For small code snippets it might be acceptable,
but traditionally #ifdef's are used to make programs compile
on various UNIX flavors.That makes code unreadable and potentially
buggy, in particular if the #ifdef's guard different
call semantics for the same function, just like sendfile().
I decided to remove the #ifdef's alltogether from lophttpd,
by introducing a flavor namespace, and implementing a generic
function for each flavor. That moves the conditional
compilation logic to the Makefile or configure script.
Thats one of the commits for it.
No praying without paying: We buy the easy reading and clean
code by a little bit of code duplication for similar
flavors (for example sendfile() on Linux and Android flavor)
but thats at the time of writing/maintaining, not at runtime.
The other price is that you buy another function call
for code that could have been inlined. But as a whole,
thats cheap today, compared to the hassle one can have.
I am not banning #ifdef's, there are good reasons
for some of them and if you write code at the Linux driver-
(or rootkit-) level with a lot of API changes between
kernel versions, its sometimes the best way to go.
Yet, sometimes if you look at the code, it just feels wrong
and thats the point where you should change it.
Thursday, March 8, 2012
github pwnage
After recent github pwnage, I checked the integrity of my
repositories, and its all OK. The SSH keys are also fine.
So go ahead and checkout. :)
repositories, and its all OK. The SSH keys are also fine.
So go ahead and checkout. :)
Subscribe to:
Posts (Atom)



