• Zum Inhalt springen
  • Zur Seitenspalte springen

Technik News

Das Blog zu IT, Mobilfunk & Internet

Vodafone, security, and revenue

Juni 1, 2006 von Harald Puhl

Do you work a lot while on the road? If you use Vodafone’s GPRS/3G data service, it could be costing a lot more than you think.
You surely heard about Vodafone blocking Skype on their mobile network in the UK, with T-Mobile following suit, all in the name of ‘fair use’ and distribution of network resources. Supposedly, using Skype instead of downloading MP3s can make their network grind to a halt…let’s just move on.

I was involved in a project about a year ago, the goal of which was to write an IP stack for an embedded device. The approach was to write the stack in an easy-to-debug higher level language on a PC, then port it to the device. So, I went ahead and started writing the PPP code, aided by a GSM modem and a Vodafone SIM card with GPRS enabled.

To my surprise, as soon as the PPP session was established, a public IP address was given by the network, and packets started arriving. Curious about what this data was, but already suspicious of what it could be, I wrote a quick-and-dirty TCP decoder, and rightly so, the misterious packets were nothing more than the usual flurry of port scans any device attached to the internet is receiving all day long. NetBIOS ports, common trojans, SSH, you name it, it was all coming in.

It was obvious that the security implications of these port scans were just as if the internet connection was coming from a DSL line – but there was a twist. GPRS fees are paid for downloaded data, but what is the definition of downloaded data? Is it just the data portion of a TCP or UDP packet? Is it the whole packet? Thus, were you actually paying for these port scans, and even for getting hacked?

“Vodafone customer support, how may I help you?”

Turns out they couldn’t help me much. Not even the technical department understood what I meant by port scans, or ‘rogue’ data coming from the internet and being charged for it. I escalated and called the UK support line, and finally got someone to admit that they don’t perform any form of filtering, “for technical reasons, as it is something very difficult to accomplish”. Besides, they were sure some customer might want their NetBIOS ports open for the whole internet to see.

Fast-forward to 2006…and they are blocking Skype. If someone can come up with a decent explanation, other than they only block data harmful to their revenue, I’d be glad to hear it. They don’t care if some kiddie hacks into your computer, and turns it into a file dump, as long as you pay for the traffic. Alas, if you touch their voice revenue with a VoIP application, they will go to any length to “protect” you.

RFID Security

Mai 30, 2006 von Franz Hieber

RFID, which stands for Radio Frequency Identification, is ubiquitous in our lives. We find RFID tags in our library books, grocery, consumer goods, printer cartridges, and are even implanted into people’s bodies.

The basic principle behind RFID is that a simple, passive device responds to a burst of RF with a unique number, which can be used to identify the object to which the device is attached. There are many types of tags, some of them can even be written to. When I have the time, I will write an in-depth article on this subject.

RenderMan, Thorn and Audit have written a book on this topic, titled RFID Security. You can get this book at Amazon.com. RenderMan is very active in the Church of WiFi, Thorn has participated in other books, such as Wardriving: Drive, Detect, Defend. Audit is a very active moderator of the Netstumbler forums, hosts personalwireless.org, and also participates in many WiFi-related projects.

iTunes – the war is over

Mai 30, 2006 von Harald Puhl

Believe me, I tried. Frustration was high, but so were spirits. The challenge: to purchase videos from Apple’s US iTunes store, while not being a United States citizen, nor living in the country.

For some obscure reason which they don’t make public, but one can guess emanates from the RIAA, Apple does not allow you to purchase music or other content in their iTunes stores, unless you are from the country that the store belongs to. So, a UK citizen cannot buy music in the US iTunes store, and so on. Fine. Whatever DRM was for…

It is very frustrating to see that in your music store, Bowling for soup only has some 70 songs available, whereas the US music store has 150 songs.

Being based in Barcelona, Spain, I was stuck in the spanish iTunes store. The Office videos (both seasons), were however stuck in the US iTunes store. I would have been quite happy to pay the $2 they asked for each show. I firmly believe in paying fair prices for good, reliable content, and so I set about trying to break down the barriers set against being a satisfied costumer.
Round 1: Direct attempt

My first attempt was to create a US-based account, using a good friend’s address, and my own credit card. This is an address where I have actually lived for some time, so I consider it in my heart as ‘home’ – it’s not just an address of someone I met on the net.

The attempt failed completely, as the iTunes signup process checks the address of the credit card, matching it against the address you say you live at. I was quite amazed that the system also checked the zip code, state and address – it wasn’t going to take any rubbish you threw at it.

Round 2: The back door

iTunes gives you two basic payment methods: credit cards and PayPal. So, I thought about creating a PayPal account with the US address, add my credit card and verify it, then try to get iTunes to accept it. Maybe the process would somehow dilute the geocoding wrath of Apple’s DRM.

The first part seemed to work – I created the PayPal account, and it allowed me to verify my credit card. I will probably deal with PayPal’s verification methods in a sepparate post.

Next step was to create the iTunes account, choosing PayPal as your payment system. The iTunes client then opens your web browser, and points it to PayPal, where you are asked to confirm you want to accept charges coming from the music store.

The iTunes account was finally created, and it allowed me to browse content in the US music store. Searching for The Office videos, I saw both seasons were available, and clicked the purchase button for the pilot episode of season 1. Success! iTunes downloaded the episode, which I added to my iPod’s library, and watched it great satisfaction.

A while later that evening, an email from iTunes arrives – they have a problem charging my purchase of a single $2 video to my PayPal account. So, I log into the PayPal account to see what’s wrong, and I’m greeted with a flurry of disputes to be resolved. The most devastating one is that I have to “confirm my identity” by adding a US-based bank account, something you can only have if you physically open it at a US branch, thus needing to confirm your identity and address, and so on.

After this, I received another couple of emails from both PayPal and iTunes, one saying iTunes had cancelled their invoicing agreement, the other saying they had frozen my account, in all, total defeat.

Round 3: The alternatives

After the disconcerting experience with iTunes, I looked around at alternatives, and was pointed by a friend to allofmp3.com. This is a service very similar to iTunes, but with a twist. First, they are based in Russia, where a loophole exists on the trade of music in electronic rather than physical format. Secondly, they don’t use any form of DRM, and let you encode the tracks you buy in a number of formats and bitrates. And thirdly, the average album will cost you less than $2, as they charge by volume rather than quantity.

They don’t have videos, but checking sites such as TorrentSpy shows you that if iTunes won’t serve them, someone else will…

Discussion of the uuencode/uudecode standard

Mai 28, 2006 von Harald Puhl

This file is a short discussion of the uuencode/uudecode ’standard:‘ how hey work, pitfalls for them, and variants on the theme.

Here’s how UUENCODE and UUDECODE do their thing: The basic idea is to convert binary data to plain ASCII data, so it can be mailed safely over standard maile systems. You start with 3 8-bit bytes (24 bits) and convert them to 4 6-bit bytes (also 24 bits). Normal ASCII text has all values between 32 and 127 (all of the ‚control‘ characters are between 0 & 31), so you need to add 32 to every byte as an offset. 127 takes 7 bits, so with only 6 bits (maximum value = 63), you can add 32 and still be under 128.

The encoding process goes like this: you take the high order 6 bits from the first input byte (Ibyte1 for short) and they become the 6 bits of the first output byte (Obyte1)…you have to remember to mask off the top two bits, which is done by doing a logical .and. with 63, which is the lower six bits all *on* and the top two *off*. Then you add 32 to force the result to be at least 32. Now Obyte2 is made from the lower 2 bits of Ibyte1 and the top 4 bits of Ibyte2. Obyte3 is the lower 4 bits of Ibyte2 and the top 2 bits of Ibyte3. Obyte4 is the lower 6 bits of Ibyte3. Again, mask off the top two of each output byte and add 32.

The first byte of each encoded output line tells you how many bytes will be output when decoded. This count byte is also encoded; the ‚M‘ you see on the beginning of almost all lines is ASCII character 77…subtracting 32 gets you 45. This 45 refers to the count of DECODED bytes, which come in 3-byte cells, so this means that there are 15 cells on a line that begins with ‚M‘, or 4 * 15 = 60 encoded bytes on that line. Remember that you can’t have less than a whole cell, even though you may need only 1 or 2 bytes of the 3-byte decoded cell. Now to discuss a few common variations on the uuencode ’standard.‘ One of the earliest things that people noticed was that some mailers like to strip off any trailing spaces on lines of mail text. Seems like a good ideam, no? You’re saving storage space by trimming off useless data, right? Well…unfortunately, trailing spaces are perfectly valid in uunecoded data. I have seen several interesting ways around this problem. The first is to replace the space character (ASCII value = 0x20, or 32 decimal) with the ` character (it’s called a grave, pronounced „grahhhve“), which has an ASCII value of 0x60 (96 decimal). Under the standard decoding procedure, described above, the grave decodes the same way as a space:

for a space: (0x20 – 0x20) & 0x3F = (0x00) & 0x3F = 0x00
for a grave: (0x60 – 0x20) & 0x3F = (0x40) & 0x3F = 0x00

or in binary format:
space = 00100000
grave = 01100000

space – 32 = 0
grave – 32 = 01000000
(grave – 32) & 63 = 01000000 & 00111111 = 0

So you see that both decode to zero. The difference between them, of course, is that the grave is not seen by the mailer as a space, so it does not get truncated!
The other way around this truncation problem is to place some non-space character at the end of every line…then the trailing spaces don’t trail any more, so they’re not trimmed! It really doesn’t matter which character gets put there, so long as it is *not* a space. A normal decoder will never see this character, because it stops when the correct number of bytes is encountered, as described in the earlier discussion. Some decoders do choke on this, but they’re pretty rare.

Something I said earlier is not strictly true; the space and the grave do not *always* decode to zero; if you have a decoder that forms a look-up table for decoding, and neglects to include both the space and the grave in the table, then you’re hosed.

Speaking of look-up tables, there’s another variant of uuencode/uudecode called xxencode/xxdecode. Xxencode was invented to avoid problems in a conversion routine between the ASCII world and the EBCDIC world (used primarily by IBM mainframes). It seems that a bug in the conversion routine incorrectly maps some ASCII characters onto other characters in EBCDIC. In a fit of right-thinking, Phil Howard realized that uuencode/uudecode were just a fancy form of a look-up table, and set about finding a character set that does *not* get munged by the conversion routine. He then modified some uuencode source to handle the new character set, and *presto* the problem was solved. The rest of the code remains basically unchanged, but all encoding/decoding is done via the look-up table instead of via the „get a value between 0 and 64 and then add 32“ method that uuencode uses. You can always recognize xxencoded files because the lines start with ‚h‘ instead of the uuencode ‚M‘.

There’s yet another variant of uudecode that I’ve seen. Once people realized that this was all just a look-up table problem, it wasn’t long before encoders started appearing that included the entire table before the data, like thus:

table
`!“#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]~_
begin 666 ROGER.GIF
M1TE&.#=A@`)>`9,„„„*JJ`*H`J@“JJO]5557_5:JJJ@„JE55_U5550″Ja
M`*H„%7___]5____5?___RP„„`@`)>`0,$_A#(2:N]..O-N_]@*(YD:9YHa
MJJYLZ[YP+,]T;=]XKN]\[__`H‘!(+!J/R*1RR6RV#-„H=$JM6J_8K‘;+[7J_a
MX+!X3″Z;S~BT>LUN%][PN’Q.K]OO~+Q~S~_7H00&#H$$#@8$#X6’@(N!AX.`a

Then your decoder has an absolute reference for which characters are where in the table! Again, if the standard character set is used, this shouldn’t present any problems, because most uudecoders skip over everything before the ‚begin‘ line before they start decoding.

Note that in the example above, the encoder used *both* methods of avoiding the trailing-space-truncation problem, by using grave instead of space, and by placing the ‚a‘ at then end of every line. Kind of redundant, but I suppose it’s better than nothing. Note also that this example would *not* decode under a standard decoder that knew nothing about ‚table‘ statements; the tilde (~) specified as the second-to-last character in the table is *not* the same as the carat (^) that should be there! This example is actual data that someone posted to the net, which drove everybody nuts.

Now I’ve probably got you wondering about that ‚begin‘ line in the example. This line tells the decoder where to start decoding. It also tells the decoder which mode to use for opening the output file (for UNIX systems), and what to call the output file. Most encoders will write 644 as the mode, which gives read/write/execute privileges to the ‚owner‘, but only read/execute to the ‚group‘ and to ‚others.‘ Note that in the example, read/write/execute privileges are given to *everybody.* Dangerous!

There is also a corresponding ‚end‘ line at the end of the data. Without one, decoders would not know where data stops and other trailer info begins.

We now come to the last topic: multi-part files. Many mailers cannot handle files larger than some maximum value (some are as low as 32 kbytes!), so a common practice is to cut the uuencoded output into smaller chunks which can be mailed. At the other end, the chunks are re-combined and then decoded. The problem here is that many people use newsreaders/posters that automatically append a signature to every post, which means that the resulting concatenated file will have bad data in it! This is why you must trim off the headers & trailers by hand. Unfortunately, there is no standard yet for a uuencoder/decoder which recognizes multi-part files. Recently I’ve seen some people put „cut here“ lines in their files like this:

BEGIN—————-CUT HERE—————–
…
END——————CUT HERE—————–

so that simple programs can be written which recognize these markers. Again, normal decoders will have no problem with this, because the watch for the ‚begin‘ marker is case-sensitive; ‚BEGIN‘ is different from ‚begin.‘

That’s about it for uuencode and uudecode.

Free File Hosting – Bandwidth

Mai 2, 2006 von Franz Hieber

Bandwidth is a term that many people can get confused about. Essentially, the bandwidth shows how much information how been downloaded from the server (a computer where the files are stored). Bandwidth is shown in terms of MB’s and sometimes even in GB’s (for large websites and files that are being downloaded often). For full websites, bandwidth can go pretty quickly since every single file and image must be downloaded for every single page that is visited by every individual user. Each image and file on a page are generally small, but having those being downloaded by many people all throughout the day can build up very quickly.

Bandwidth is purchased with a web hosting package. Bandwidth isn’t free, it costs money to be allotted a certain amount of bandwidth each month. Once the bandwidth limit is reached the files and images hosted on the server for the websites will not be able to be downloaded any longer. Essentially, they are inaccessible either until more bandwidth is purchased or until the next billing cycle (since bandwidth is purchased for a specified time period, generally a month).

File hosting websites tend to use up massive amounts of bandwidth. Bandwidth is not only used when people visit the website but also is used every single time a person downloads a file or image that has been uploaded to the file hosting website. For instance, when a person uploads a picture and then goes to show other people, bandwidth is used up every single time another person views that image. That means if you put the link to that image on another page or forum, the file hosting web site is having its bandwidth used up every single time that page is loaded since the image is being downloaded along with the rest of the page.

Since bandwidth isn’t free, file hosting websites have to place limits on the amount of times a file or image uploaded can be downloaded and also on the size of the file or image uploaded. Items that are very large require more bandwidth usage each and every time they are downloaded. Also, if the files were allowed to be downloaded unlimited amounts of time, people would abuse this and post them all over the place in forums and this could lead to serious bandwidth issues. File hosting websites allot as much as much and try to be very flexible with the issue but bandwidth isn’t free.

  • « Vorherige Seite aufrufen
  • Seite 1
  • Weggelassene Zwischenseiten …
  • Seite 70
  • Seite 71
  • Seite 72

Seitenspalte

Tags

3D-Drucker Amazon AOL Apple asus memo pad Blackberry Dell DSL E-Book E-Book-Reader Ebay Elster Facebook Google Google Android Handy Hardware Hotmail IBM Internet Makerbot Microsoft mobiles Internet Netbook Prism Quantencomputer Rundfunkbeitrag Samsung samsung galaxy fame Samsung Galaxy Mega Samsung Galaxy Tab SchülerVZ Skype Smartphone Software sony xperia tablet z Suchmaschine Tablet Tintenpatronen Twitter Typo3 WebOS WhatsApp Xing Yahoo

Technik News Kategorien

Ausgewählte Artikel

LTE tilgt weiße Flecken und drückt aufs Tempo

LTE steht für Long Term Evolution und zugleich für den Vorstoß des mobilen Internets in die erste Liga der Breitband-Internetverbindungen. [...]. Heutige Angebote für mobiles Internet bringen 3,6 oder gar 7,2 MB/sec. Der Zugang erfolgt dabei meistens über einen Internet Stick der dank USB-Schnittstelle sowohl an einem Laptop wie auch am Desktop-Computer verwendet werden kann.


Externe Festplatte mit 3,5 Zoll, 2,5 Zoll oder 1,8 Zoll

Angeschlossen wird die externe Festplatte über USB, Firewire, eSATA oder einen Netzwerk-Anschluss. Vorsicht: Bei manch einer externen Festplatte stört ein lärmender Lüfter. Die kleineren Notebook-Festplatten sind 2,5-Zoll groß. Eine externe Festplatte mit 2,5-Zoll nimmt in den meisten Fällen über den USB-Anschluss Kontakt zum Computer auf und wird über dasselbe Kabel auch gleich mit Strom versorgt.

Inhaltsverzeichnis | Impressum und Datenschutzerklärung