Ok.
Jeg har i dag oppdatert firmware - på ei mus.
Når ble de lure nok til å trenge firmware? Antagelig sammen med led/optikk-variantene.
Og hva hindrer dem fra å gro et virtuelt keyboard om natta og bedrive bruteforcing av passordet mitt? Ingenting jeg vet om.
(Ok, feedback er et problem. Men det fins usb skjermkort... :p)
Monday, 17 October 2011
Wednesday, 17 August 2011
Verbbøyingsgalskap
Japansk er fleksibelt og komplisert. La oss ta et tilfeldig verb, taberu - å spise.
For det første er ikke ordbok-formen av verbet infinitiv på japansk. Ordbokformen av verbet er "uformell ikke-fortid" - kan hende det skjer omtrent nå, kan hende en bare har vage planer om det en gang i fremtiden, men det er iallfall ikke ferdig med å skje.
"Watashi wa niku ga taberu." - Jeg spiser kjøtt. Temmelig generell og uformell vending. Om du allerede snakker om deg selv og det du liker, vil du vanligvis sløyfe de to første ordene. "Niku ga taberu." - Spiser kjøtt.
Det er uformelt, dog. I høflig samtale med folk du ikke kjenner godt, vil du vanligvis bruke en normalt høflig form. "Niku ga tabemasu." (uttales "Niku ga tabemas".)
Men hvis du vanligvis ikke spiser kjøtt, vil du kanskje uttrykke det. "Niku ga tabemasen." - Spiser ikke kjøtt. Å bøye verb i positive og negative former er en typisk japansk ting. Fremdeles en veldig generell vending.
"Niku ga tabetai desu." - Har lyst til å spise kjøtt. Her er verbet gjort om til et adjektiv "lyst til å spise", mens "desu" = har.
"Niku ga tabete mimasu." - Kan prøve å spise kjøtt og se hvordan det går. Her er du usikker på om dette er noe for deg. "Mimasu" er høflig ikkefortid av "å se", her som hjelpeverb.
"Niku ga tabete mitai desu." - Har lyst til å prøve å spise kjøtt og se hvordan det går. Kombinasjon av de to over.
"Niku ga tabete imasu." - Spiser kjøtt akkurat nå. "-te imasu" er noe ala "am -ing"-form på engelsk.
"Niku ga tabete iru hito." - Personen som spiser kjøtt akkurat nå. "Iru" er den ikke-høflige kortformen av "imasu", når du bruker en hel frase som et adjektiv så brukes korte bøyinger.
"Niku ga tabemashou." - La oss spise kjøtt! Høflig men direkte.
"Niku ga tabemasen ka." - Skal vi ikke spise kjøtt? Indirekte invitt, høfligere.
"Niku ga taberaremasen." - Kan ikke spise kjøtt. Potensiell, høflig ikkefortid, negativ form.
"Niku ga tabemashita." - Har spist kjøtt.
"Niku wa tabeta koto ga arimasen." - Har aldri spist kjøtt. Uformell fortid pga. hjelpeordene etterpå. En mer klumpete og direkte oversettelse blir "Erfaringen å ha spist kjøtt, har jeg ikke."
"Niku wa tabenai tsumori desu." - Har ikke planer om å spise kjøtt. Negativ uformell ikkefortid + hjelpeord.
"Niku wa tabenakute wa ikemasen." - Må spise kjøtt. ("Kan da ikke la være å spise...")
"Niku ga tabeta hou ga ii desu." - Bør spise kjøtt. Formaning, "Det er bedre (for deg/meg) å..."
"Niku ga tabesugite wa ikemasen." - Ikke forspis deg på kjøtt. Her er taberu blitt til det sammensatte verbet tabesugiru, der -sugiru betyr "for mye".
... og jeg har fremdeles bare såvidt begynt på Genki II. Mange flere sammensetninger og former ligger på lur og venter. Og taberu er et enkelt, regulært verb i forhold til mange andre.
Det er da litt gøy. :)
また、ね！
For det første er ikke ordbok-formen av verbet infinitiv på japansk. Ordbokformen av verbet er "uformell ikke-fortid" - kan hende det skjer omtrent nå, kan hende en bare har vage planer om det en gang i fremtiden, men det er iallfall ikke ferdig med å skje.
"Watashi wa niku ga taberu." - Jeg spiser kjøtt. Temmelig generell og uformell vending. Om du allerede snakker om deg selv og det du liker, vil du vanligvis sløyfe de to første ordene. "Niku ga taberu." - Spiser kjøtt.
Det er uformelt, dog. I høflig samtale med folk du ikke kjenner godt, vil du vanligvis bruke en normalt høflig form. "Niku ga tabemasu." (uttales "Niku ga tabemas".)
Men hvis du vanligvis ikke spiser kjøtt, vil du kanskje uttrykke det. "Niku ga tabemasen." - Spiser ikke kjøtt. Å bøye verb i positive og negative former er en typisk japansk ting. Fremdeles en veldig generell vending.
"Niku ga tabetai desu." - Har lyst til å spise kjøtt. Her er verbet gjort om til et adjektiv "lyst til å spise", mens "desu" = har.
"Niku ga tabete mimasu." - Kan prøve å spise kjøtt og se hvordan det går. Her er du usikker på om dette er noe for deg. "Mimasu" er høflig ikkefortid av "å se", her som hjelpeverb.
"Niku ga tabete mitai desu." - Har lyst til å prøve å spise kjøtt og se hvordan det går. Kombinasjon av de to over.
"Niku ga tabete imasu." - Spiser kjøtt akkurat nå. "-te imasu" er noe ala "am -ing"-form på engelsk.
"Niku ga tabete iru hito." - Personen som spiser kjøtt akkurat nå. "Iru" er den ikke-høflige kortformen av "imasu", når du bruker en hel frase som et adjektiv så brukes korte bøyinger.
"Niku ga tabemashou." - La oss spise kjøtt! Høflig men direkte.
"Niku ga tabemasen ka." - Skal vi ikke spise kjøtt? Indirekte invitt, høfligere.
"Niku ga taberaremasen." - Kan ikke spise kjøtt. Potensiell, høflig ikkefortid, negativ form.
"Niku ga tabemashita." - Har spist kjøtt.
"Niku wa tabeta koto ga arimasen." - Har aldri spist kjøtt. Uformell fortid pga. hjelpeordene etterpå. En mer klumpete og direkte oversettelse blir "Erfaringen å ha spist kjøtt, har jeg ikke."
"Niku wa tabenai tsumori desu." - Har ikke planer om å spise kjøtt. Negativ uformell ikkefortid + hjelpeord.
"Niku wa tabenakute wa ikemasen." - Må spise kjøtt. ("Kan da ikke la være å spise...")
"Niku ga tabeta hou ga ii desu." - Bør spise kjøtt. Formaning, "Det er bedre (for deg/meg) å..."
"Niku ga tabesugite wa ikemasen." - Ikke forspis deg på kjøtt. Her er taberu blitt til det sammensatte verbet tabesugiru, der -sugiru betyr "for mye".
... og jeg har fremdeles bare såvidt begynt på Genki II. Mange flere sammensetninger og former ligger på lur og venter. Og taberu er et enkelt, regulært verb i forhold til mange andre.
Det er da litt gøy. :)
また、ね！
Tuesday, 21 December 2010
Transport layer protocols for stealth and evil
Ever tested some of the more exotic transport protocols?
SCTP is interesting ... multihoming means you can have several ips involved on each side of a connection (association in sctp speak) ... so when you move from wired to wireless your ssh session still is fine. If you find a proper SCTP ssh, of course.
Testing it on Ubuntu LTS, though, using socat for glue... a listening SCTP socket is invisible in netstat -ln. Fun. tcp, udp, raw sockets are visible ... but sctp isn't.
socat SCTP-LISTEN:8080,fork TCP-CONNECT:localhost:22
Nice, stealthy backdoor. Does not show in netstat(8) or ss(8). Combine with socat TCP-LISTEN:2223 SCTP-CONNECT:localhost:8080 on a remote host and we have a completely stealthy tunnel, if the firewall is mildly clue-challenged.
lsof reports a mysterious socket. But it also does that for udev and update-manager, so that's hardly conclusive.
knan@ip:~$ lsof | grep socat | grep sock
socat 24969 knan 3u sock 0,6 0t0 645716 can't identify protocol
The only place I've dug out useful info so far is from procfs.
Hardly easy to read. But it says LADDRS 0.0.0.0, LPORT 8080. Ok.
(BTW: SCTP not being in netstat is a Debian/Ubuntu-specific bug, SuSE/Red Hat have applied patches.)
sctp_darn(1) can do more fun sctp-specific stuff, like setting up multiple local and remote addresses for the association.
Cool enough. But there are other fun transport protocols we can try.
How about DCCP? It's connection-oriented and has congestion control but otherwise is UDP-like.
netsend dccp receive
The only place in /proc/net you find DCCP mentioned is in /proc/net/protocols. Which says nothing about ongoing connections or listening sockets.
knan@ip:~$ grep -ir DCCP /proc/net/
/proc/net/protocols:DCCP 1400 1 -1 NI 1196 yes dccp_ipv4 y y y y y y y y y y y y n n y y y y n
lsof still says little.
knan@ip:~$ lsof | grep netsend | grep sock
netsend 25376 knan 3u sock 0,6 0t0 658124 can't identify protocol
ss(8) to the rescue! But only when you specifically ask it about DCCP sockets with -d.
The final protocol I want to propose today is UDP-Lite. This is basically a UDP variant with partial checksums, for the case when garbled data is better than no data.
$ netsend udplite receive
As usual, netstat tells us nothing of this uncommon activity.
This time, though, lsof identifies it!
knan@ip:~$ lsof | grep netsend
netsend 25461 knan 3u IPv4 661633 0t0 UDPLITE *:6666
Which is good, since ss doesn't.
To summarize (for Ubuntu 10.04 LTS):
Hope this leaves you entertained by the possibilities. Black hats begone!
P.S.
launchpad:netstat+sctp
launchpad:lsof+sctp
launchpad:lsof+dccp
SCTP is interesting ... multihoming means you can have several ips involved on each side of a connection (association in sctp speak) ... so when you move from wired to wireless your ssh session still is fine. If you find a proper SCTP ssh, of course.
Testing it on Ubuntu LTS, though, using socat for glue... a listening SCTP socket is invisible in netstat -ln. Fun. tcp, udp, raw sockets are visible ... but sctp isn't.
socat SCTP-LISTEN:8080,fork TCP-CONNECT:localhost:22
Nice, stealthy backdoor. Does not show in netstat(8) or ss(8). Combine with socat TCP-LISTEN:2223 SCTP-CONNECT:localhost:8080 on a remote host and we have a completely stealthy tunnel, if the firewall is mildly clue-challenged.
knan@ip:~$ netstat -ln Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:4949 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN udp 0 0 0.0.0.0:68 0.0.0.0:* udp 0 0 0.0.0.0:36558 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* udp 0 0 0.0.0.0:45561 0.0.0.0:* knan@ip:~$
lsof reports a mysterious socket. But it also does that for udev and update-manager, so that's hardly conclusive.
knan@ip:~$ lsof | grep socat | grep sock
socat 24969 knan 3u sock 0,6 0t0 645716 can't identify protocol
The only place I've dug out useful info so far is from procfs.
knan@ip:~$ cat /proc/net/sctp/eps ENDPT SOCK STY SST HBKT LPORT UID INODE LADDRS ffff8800722cb800 ffff8800342c8480 2 10 16 8080 1001 645716 0.0.0.0
Hardly easy to read. But it says LADDRS 0.0.0.0, LPORT 8080. Ok.
(BTW: SCTP not being in netstat is a Debian/Ubuntu-specific bug, SuSE/Red Hat have applied patches.)
sctp_darn(1) can do more fun sctp-specific stuff, like setting up multiple local and remote addresses for the association.
Cool enough. But there are other fun transport protocols we can try.
How about DCCP? It's connection-oriented and has congestion control but otherwise is UDP-like.
netsend dccp receive
knan@ip:~$ netstat -ln Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:4949 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp6 0 0 :::22 :::* LISTEN tcp6 0 0 ::1:631 :::* LISTEN udp 0 0 0.0.0.0:68 0.0.0.0:* udp 0 0 0.0.0.0:36558 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* udp 0 0 0.0.0.0:45561 0.0.0.0:*Netstat still says nothing.
The only place in /proc/net you find DCCP mentioned is in /proc/net/protocols. Which says nothing about ongoing connections or listening sockets.
knan@ip:~$ grep -ir DCCP /proc/net/
/proc/net/protocols:DCCP 1400 1 -1 NI 1196 yes dccp_ipv4 y y y y y y y y y y y y n n y y y y n
lsof still says little.
knan@ip:~$ lsof | grep netsend | grep sock
netsend 25376 knan 3u sock 0,6 0t0 658124 can't identify protocol
ss(8) to the rescue! But only when you specifically ask it about DCCP sockets with -d.
knan@ip:~$ ss -ldn Recv-Q Send-Q Local Address:Port Peer Address:Port 0 0 *:6666 *:*
The final protocol I want to propose today is UDP-Lite. This is basically a UDP variant with partial checksums, for the case when garbled data is better than no data.
$ netsend udplite receive
As usual, netstat tells us nothing of this uncommon activity.
knan@ip:~$ netstat -ln Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:4949 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp6 0 0 :::22 :::* LISTEN tcp6 0 0 ::1:631 :::* LISTEN udp 0 0 0.0.0.0:68 0.0.0.0:* udp 0 0 0.0.0.0:36558 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* udp 0 0 0.0.0.0:45561 0.0.0.0:*
This time, though, lsof identifies it!
knan@ip:~$ lsof | grep netsend
netsend 25461 knan 3u IPv4 661633 0t0 UDPLITE *:6666
Which is good, since ss doesn't.
To summarize (for Ubuntu 10.04 LTS):
| Protocol | netstat(8) | ss(8) | lsof(8) | /proc/net/* |
|---|---|---|---|---|
| SCTP | No | No | No | /proc/net/sctp/eps /proc/net/sctp6/eps |
| DCCP | No | Yes (-d) | No | No |
| UDP-Lite | No | No | Yes | /proc/net/udplite /proc/net/udplite6 |
Hope this leaves you entertained by the possibilities. Black hats begone!
P.S.
launchpad:netstat+sctp
launchpad:lsof+sctp
launchpad:lsof+dccp
Wednesday, 15 December 2010
sed for dns hackers
(Requires gnu sed)
Moving to a new set of nameservers is a bit like moving house. Lots of stuff thrown away for reasons of unreasonable antiquity, lots of stuff could do with a refresh and cleanup.
sed -i.bak '/\(NS\|SOA\)/ s/\bdns1\.example\.org/innerdns1.example.org/g; /\(NS\|SOA\)/ s/\bdns2\.example\.org/innerdns2.example.org/g' master/*
This simple, pretty oneliner fixes NS and SOA records to point to new addresses, and leaves other records alone - unless you have really unfortunate and awkward capital-letter names in your zones. Add some more \b safeguards if so.
Moving to a new set of nameservers is a bit like moving house. Lots of stuff thrown away for reasons of unreasonable antiquity, lots of stuff could do with a refresh and cleanup.
sed -i.bak '/\(NS\|SOA\)/ s/\bdns1\.example\.org/innerdns1.example.org/g; /\(NS\|SOA\)/ s/\bdns2\.example\.org/innerdns2.example.org/g' master/*
This simple, pretty oneliner fixes NS and SOA records to point to new addresses, and leaves other records alone - unless you have really unfortunate and awkward capital-letter names in your zones. Add some more \b safeguards if so.
Thursday, 28 October 2010
Japanese WHOIS fun
Recently, I wanted to look up info on a Japanese domain name. Being a command-line type of guy, I obviously did $ whois ac.jp and expected things to work out.
Well, things were a bit less helpful than I'd hoped.
So I looked up the current WHOIS protocol. That's probably the shortest RFC I've ever seen.
The interesting bit: "The WHOIS protocol has no mechanism for indicating the character set in use." ... rrrright. Obviously not UTF-8 on this server.
Some trial and error, then.
$ whois ac.jp > gnark.txt
$ file gnark.txt
gnark.txt: ASCII English text, with escape sequences
Oh thank you. Very helpful. (irritated hacking ensues)
End product (bash function):
P.S. This was written using FreeBSD whois. Ubuntu whois acts completely differently - specifically asks for and shows English information in English locales, and breaks interestingly in the Japanese locales I've tested.
Well, things were a bit less helpful than I'd hoped.
$ whois ac.jp Domain Information: [%I%a%$%s>pJs] a. [%I%a%$%sL>] AC.JP e. [$=$7$-$a$$] f. [AH?%L>] 3X=Q%I%a%$%s g. [Organization] Academic Domain k. [AH?%<oJL] l. [Organization Type] m. [EPO?C4Ev<T] n. [5;=QO"MmC4Ev<T] p. [%M!<%`%5!<%P] a.dns.jp p. [%M!<%`%5!<%P] b.dns.jp p. [%M!<%`%5!<%P] c.dns.jp p. [%M!<%`%5!<%P] d.dns.jp p. [%M!<%`%5!<%P] e.dns.jp p. [%M!<%`%5!<%P] f.dns.jp p. [%M!<%`%5!<%P] g.dns.jp [>uBV] Reserved [EPO?G/7nF|] [@\B3G/7nF|] [:G=*99?7] 2005/03/30 17:37:52 (JST)While I can figure out what I need here, why the garble? This is 2010 and I'm running in a UTF-8 locale with proper fonts; I should see hiragana/katakana/kanji just fine.
So I looked up the current WHOIS protocol. That's probably the shortest RFC I've ever seen.
The interesting bit: "The WHOIS protocol has no mechanism for indicating the character set in use." ... rrrright. Obviously not UTF-8 on this server.
Some trial and error, then.
$ whois ac.jp > gnark.txt
$ file gnark.txt
gnark.txt: ASCII English text, with escape sequences
Oh thank you. Very helpful. (irritated hacking ensues)
End product (bash function):
function jwhois { whois "$@" | iconv -f iso-2022-jp ; }$ jwhois ac.jp Domain Information: [ドメイン情報] a. [ドメイン名] AC.JP e. [そしきめい] f. [組織名] 学術ドメイン g. [Organization] Academic Domain k. [組織種別] l. [Organization Type] m. [登録担当者] n. [技術連絡担当者] p. [ネームサーバ] a.dns.jp p. [ネームサーバ] b.dns.jp p. [ネームサーバ] c.dns.jp p. [ネームサーバ] d.dns.jp p. [ネームサーバ] e.dns.jp p. [ネームサーバ] f.dns.jp p. [ネームサーバ] g.dns.jp [状態] Reserved [登録年月日] [接続年月日] [最終更新] 2005/03/30 17:37:52 (JST)Looks better, yes?
P.S. This was written using FreeBSD whois. Ubuntu whois acts completely differently - specifically asks for and shows English information in English locales, and breaks interestingly in the Japanese locales I've tested.
Thursday, 24 June 2010
Wine on Windows...
The Wine project is preparing the long-awaited 1.2 release for the end of the month.
Stuff like this should help morale:
Gothic I & II not working on Windows 7
Working around a longstanding d3d driver bug by instead running via crosscompiled d3d8+wined3d on OpenGL on Windows. :)
Stuff like this should help morale:
Gothic I & II not working on Windows 7
Working around a longstanding d3d driver bug by instead running via crosscompiled d3d8+wined3d on OpenGL on Windows. :)
Friday, 14 May 2010
Fun hardware - first results
Testing the Fusion-io ioXtreme 80GB (/dev/fioa) vs Intel X25-M gen 2 160G (/dev/sda). The non-directio dd went cpu-limited for some reason, needs looking into.
792 MB/s read speed at 12% cpu use in the directio case looks a bit promising :)
Stay tuned, more to come...
792 MB/s read speed at 12% cpu use in the directio case looks a bit promising :)
# dd if=/dev/fioa2 of=/dev/null bs=1M
26723+1 records in
26723+1 records out
28021615104 bytes (28 GB) copied, 201.797 s, 139 MB/s
# dd if=/dev/fioa2 of=/dev/null bs=1M iflag=direct
19792+0 records in
19791+0 records out
20752367616 bytes (21 GB) copied, 26.2142 s, 792 MB/s
# dd if=/dev/sda4 of=/dev/null bs=1M
5157+0 records in
5156+0 records out
5406457856 bytes (5.4 GB) copied, 25.136 s, 215 MB/s
# dd if=/dev/sda4 of=/dev/null bs=1M iflag=direct
6040+0 records in
6039+0 records out
6332350464 bytes (6.3 GB) copied, 26.1701 s, 242 MB/s
Stay tuned, more to come...
Subscribe to:
Posts (Atom)