I recently got the opportunity to understand what was going on with a Tianchi android KTV console with north korean content loaded on it. A description of the encryption and evolution of DRM protections associated with the device is published on the North Korea Tech blog.
One of the more common password managers in linux environments is the gnome-keyring, which is split into a service (gnome-keyring-daemon), and a user interface (most commonly, seahorse).
After a bit of fiddling in the last couple weeks, this system can be compiled to run on a mac, with only a little bit of pain.
On the off chance that it saves someone some pain who’s trying to do the same thing, here are the basic steps I needed to take:
brew install autoconf automake dbus gettext gnome-icon-theme gobject-introspection gtk+3 gtk-doc intltool libffi libgcrypt libtool p11-kit pkg-config vala
brew install libsecret --with-vala
git clone https://github.com/GNOME/gcr
git apply 0001-patch-for-osx-compilation.patch
PATH=/usr/local/opt/gettext/bin/:$PATH ./configure --enable-valgrind=no --enable-vala=yes --disable-nls --prefix=/usr/local/opt/seahorse
git clone https://github.com/GNOME/gnome-keyring
PATH=/usr/local/opt/gettext/bin/:$PATH PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig/:/usr/local/opt/seahorse/lib/pkgconfig/ ./configure --disable-valgrind --without-libcap-ng --disable-doc --disable-pam --disable-ssh-agent --disable-selinux --disable-p11-tests --disable-nls --prefix=/usr/local/opt/seahorse
PATH=/usr/local/opt/gettext/bin/:$PATH PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig/:/usr/local/opt/seahorse/lib/pkgconfig/ ./configure --disable-ldap --disable-hkp --disable-sharing --disable-ssh --disable-pkcs11 --prefix=/usr/local/opt/seahorse/
To run, you’ll need to run these components connected by a DBUS instance.
The following script seems to accomplish this:
dbus-daemon --session --nofork --address=unix:path=$HERE/unix_listener &
GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./gnome-keyring/gnome-keyring-daemon --start --foreground &
GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./gcr/gcr-prompter &
GSETTINGS_SCHEMA_DIR=/usr/local/opt/seahorse/share/glib-2.0/schemas/ DBUS_SESSION_BUS_ADDRESS=unix:path=$HERE/unix_listener ./seahorse/seahorse
Third party analytics services are suffering from the growing prevalence of ad blocking, tracking protection, and the trend of minimizing connections and requests. However, from a site owner perspective, receiving usage information remains important for measuring site growth.
My expectation is that we are already on the curve where ads and tracking software will be more tightly integrated into websites and make it significantly more difficult for clients to disambiguate
“good” and “bad” scripts, which are mostly done today from the URL.
Google already provides the tools needed to relay analytics communication through a third party server, and it took under an hour to put together a proof of concept that removes the final third-party requests that are required when viewing this page. In essence, my server proxies all the requests that would normally go to Google, and adds on a couple extra parameters to track who the real client is.
The modified loading script for google analytics, and the corresponding nginx configuration to make my server a relay are here.
A topic of conversation recently has focused on the practicality of Decimal time. Days would have 10 hours, each with 100 minutes. I recently completed a side project of converting an old clock to use decimal time.
(If you aren’t willing to switch to decimal time fully, there’s an web version as well.)
I’ve started to dive once again into the mess of connection establishment. Network address translation (NAT) is a reality today for most Internet users, and poses a significant hurdle in creating the user-user (or peer-peer) connections. NAT is the process used by your router to provide multiple internal (192.168.x.x) addresses that are all only visible as a single external address on the Internet. The challenge caused by this device is that if someone outside wants to connect to your computer, they have to figure out how to get the router to send their traffic back to you, and not just drop it or send it to another computer on your network.
Without configuring your router to add a ‘port forwarding’ rule, it isn’t supposed to do this, so many of the connection establishment procedures are really ways to trick your NAT into forwarding traffic without realizing what’s happening.
There are two main protocols on the Internet today: UDP and TCP. UDP is stateless, each “packet” of data is its own message, and is self contained. In contrast, TCP is a representation of a longer “stream” of data – many messages are sent with an explicit ordering . TCP is much harder to trick routers into establishing, and there has been little work there.
The current generation of p2p systems are led by high-bandwidth applications that want to offload traffic from central servers in order to save on bandwidth costs. Good examples of these are Google’s hangouts and other VOIP (video over IP) traffic.
These systems establish a channel to send UDP traffic between two computers both behind NAT routers using a system called ICE (interactive connectivity establishment). This is a complex dance with multiple sub-protocols used to try several different ways of establishing connectivity and tricking the routers.
One of the key systems used by ICE is a publicly visible server that speaks a protocol called STUN. STUN servers provide a way for a client to open a UDP connection through their router to a server that is known to be able to receive messages, and then learn what that connection looks like outside of its router. It can then provide that external view of how it’s connected to another peer which may be able to send messages to the same external address and port and have them forwarded back to the client.
One of the unfortunate aspects of this situation is that the complexity of these systems has led to very few implementations. This is unfortunate, since the existence of libraries making it easy to reuse these techniques can allow more p2p systems to continue working in the modern Internet without forcing users to manually configure their routers.
I’ve started work on a standalone go implementation of the ICE connectivity stack. Over the weekend I reached the first milestone – The library can create a STUN connection, and learn the external appearance of the connection as reported by the STUN server.
Another year, another dive into what’s changed in running a web server. This VM is now basically up-to-date, and supports most of the shiny new web transport improvements, like HTTP/2 and OCSP stapling. Hopefully nothing broke too badly in the process.
I’m scheduled to give a talk at toorcamp next month about packet spoofing and SP^3.
I started running a public sp3 server today. It’s a small side-project I’ve hacked together over the last couple weeks to make it easier for people to play with packet spoofing. The server works similarly to a public proxy, but with the trade-off that while it won’t send high-volumes of traffic, it will allow you to send arbitrary IPv4 packets from any source you want.
There are a few fun applications that need this capability that I’ve been thinking of: helping with NAT holepunching of TCP connections; characterizing firewall routing policies; and for cover traffic in circumvention protocols. I think there are others as well, so I wanted to start running a server to see what people come up with.
The code is on github.