Menu
▾
▴
openbeacon-openamd
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
(10) |
Mar
(2) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Tomasz R. <bog...@po...> - 2009-05-25 19:13:46
|
Hello. I wrote Python script for importing network dump from 25C3 into PostgreSQL database: http://www.bogomips.w.tkb.pl/Import25C3.py It assumes database as created by this script: http://www.bogomips.w.tkb.pl/create.sql It creates full database - so you may want to trim it for your needs. Python script can be also used for other purposes - just replace INSERT statements with your own code. There were 704 strange packets - probably 2.4GHz traffic generated few packets with matching CRC after decryption. Some statistics: 674 unique tags. There are four 1-hour periods without any data. I think I know what caused strange IDs of tags visible in Leica. Old firmware (before 25C3) had different format of packets and when new agregator read old packets treating them as new ones it could result in strange IDs. At least that's what it looked like in my script before I fixed it. From tags with 23C3 firmware 84419 packets. Camp firmware - 2007: 67097. 24C3: 1780753. Tags from The Last HOPE: 276923 Beta tags were responsible for 39035832 packets Final firmware from 25C3: 49246728 packets. BTW - there was tag with ID 349. What was that? Packet types and their counts: 23 (from old firmware): 2209162. 24 (final 25C3 version) 26157340. 25 (beta): 38798260. 42 (tag looking for other tags): 2589213. 69 (social contacts report): 20737073. Currently I am trying to generate some graphs. BTW - is there any info about positions of readers? I know that they were in almost exactly the same places like during 24C3, but their IDs changed, so new map is needed. Regards. -- Tomasz Rybak <bog...@po...> GPG key ID: F22C D870 Fingerprint 93BC FEEC A426 3765 799F 10EE FAC1 9A2C F22C D870 http://member.acm.org/~tomaszrybak |
|
From: Stephan J. <xt...@cc...> - 2009-03-14 19:09:39
|
Hi, I still need information of mapping the readers by MAC or ip-address to the locations on the map. I found the xml file for the 24c3, but the ip addresses changed so I can't use this file for the 25c3 readers. Is there an updated version somewhere ? Thanks, Stephan |
|
From: Stephan J. <xt...@cc...> - 2009-03-14 18:18:31
|
Hi, I still need information of mapping the readers by MAC or ip-address to the locations on the map. I found the xml file for the 24c3, but the ip addresses changed so I can't use this file for the 25c3 readers. Is there an updated version somewhere ? Thanks, Stephan |
|
From: Manuel P. <ha...@cc...> - 2009-02-26 16:19:25
|
Hi everyone, just a heads-up... I finally sorted the issue yesterday, it appeared to be a problem with the crypto and CRC code (partly depending on byte-order). I will go and polish the code a little so it becomes a little more readable and will publish it under a free license. I'll let you know where to get it. Also, I have to have a look at the packets. Some appear to be correct by CRC though they do not contain reasonable information. There are some packets that seem to decrypt with correct CRC and the 24C3 key but as I understand, they should have a larger payload since the struct from 24C3 was 20 bytes, right? Best regards Manuel |
|
From: Tomasz R. <bog...@po...> - 2009-02-26 10:33:12
|
Dnia 2009-02-25, śro o godzinie 12:56 +0100, Manuel Prinz pisze: > Hi Tomasz! > > Thanks for your answer! > > You wrote: > > I tried to write some Python script to do it, but so far > > had problems with extracting packet data from dump - I am > > not exactly networking expert, so tcpdump and pcap are > > rather mysterious beasts to me. > > Well, I would not consider myself an expert in this area as well. I just > started with pcap and am surprised how neat and easy it actually is. > > > Can you publish this program somewhere or put it on the list - so > > we could look at it? > > Sure. I can't access the files right now but will send them here. It's > quite hackish, though. > > > At the beginning you should see many tags with beta key - and > > later you should see more and more tags with final 25C3 key. > > Occasionally you should also see tags with key from 24C3. > > Is there any sane way of determining which key to use? As I currently see > it, the protocol version information is /inside/ the encrypted data, so > the only way I see to retrieve the packet data is to try every key and > check for the packet that has the correct CRC, right? > Yea, I would also do so. As a side note, during 24C3, because there was so much transmissions in 2.4 range, few (23, to be exact) packets that are present in data set, were not from tags, but were captured, decrypted, and had matching CRC - so they were included into data set. You can recognise them because they have IDs larger than 10000. As a thumb-rule I would say that packets from 26th and beginning or 27th Dec should be decrypted using 24C3 key; after beginning or Congress (so starting at 12:00) there should be tags with beta key (about 50 of them IIRC), and on 28th there should be more and more packets with real 25C3 key. Beta key should disappear during 28th - as beta testers would come to our booth and had their tags reflashed with final firmware. -- Tomasz Rybak <bog...@po...> GPG key ID: F22C D870 Fingerprint 93BC FEEC A426 3765 799F 10EE FAC1 9A2C F22C D870 http://member.acm.org/~tomaszrybak |
|
From: Manuel P. <ha...@cc...> - 2009-02-25 13:13:38
|
Hi Tomasz! Thanks for your answer! You wrote: > I tried to write some Python script to do it, but so far > had problems with extracting packet data from dump - I am > not exactly networking expert, so tcpdump and pcap are > rather mysterious beasts to me. Well, I would not consider myself an expert in this area as well. I just started with pcap and am surprised how neat and easy it actually is. > Can you publish this program somewhere or put it on the list - so > we could look at it? Sure. I can't access the files right now but will send them here. It's quite hackish, though. > At the beginning you should see many tags with beta key - and > later you should see more and more tags with final 25C3 key. > Occasionally you should also see tags with key from 24C3. Is there any sane way of determining which key to use? As I currently see it, the protocol version information is /inside/ the encrypted data, so the only way I see to retrieve the packet data is to try every key and check for the packet that has the correct CRC, right? > Show the source! ;-) Will do, stay tuned! ;) Best regards Manuel |
|
From: Tomasz R. <bog...@po...> - 2009-02-24 23:06:39
|
Dnia 2009-02-24, wto o godzinie 16:19 +0100, Manuel Prinz pisze: > Hi folks, > > I wrote a small C program using libpcap to extract the beacon data of the > 25C3 raw packet dataset. This works pretty well so far, meaning I can > fetch the payload (16 bytes of beacon data) but unfortunately I am not > able to decrypt it using the XX-TEA algorithm and the key published on the > wiki. I do not know where the problem is exactly, so I'd to check with you > if my algoritm is right (pseudo-code): > I tried to write some Python script to do it, but so far had problems with extracting packet data from dump - I am not exactly networking expert, so tcpdump and pcap are rather mysterious beasts to me. Can you publish this program somewhere or put it on the list - so we could look at it? > 1. Extract payload from packet (16 bytes) > 2. Convert payload from network to host byte-order in 4-byte blocks > 3. Decrypt payload with XX-TEA and published key > > I tried several ways of changing the byte-order (or not changing it at > all) and different keys but I was not able to get correct results. I > verify the result by the flags field in byte 6 (should be 0 or 2) and byte > 1 (protocol version?) which should be constant. Unfortunately, I just get > random numbers. At the beginning you should see many tags with beta key - and later you should see more and more tags with final 25C3 key. Occasionally you should also see tags with key from 24C3. > > It would be really cool if you could point to me what I did wrong or if > you could verify the key is correct. I spent quite some time with > debugging already and am totally out of ideas. TIA! Show the source! ;-) -- Tomasz Rybak <bog...@po...> GPG key ID: F22C D870 Fingerprint 93BC FEEC A426 3765 799F 10EE FAC1 9A2C F22C D870 http://member.acm.org/~tomaszrybak |
|
From: Manuel P. <ha...@cc...> - 2009-02-24 15:19:21
|
Hi folks, I wrote a small C program using libpcap to extract the beacon data of the 25C3 raw packet dataset. This works pretty well so far, meaning I can fetch the payload (16 bytes of beacon data) but unfortunately I am not able to decrypt it using the XX-TEA algorithm and the key published on the wiki. I do not know where the problem is exactly, so I'd to check with you if my algoritm is right (pseudo-code): 1. Extract payload from packet (16 bytes) 2. Convert payload from network to host byte-order in 4-byte blocks 3. Decrypt payload with XX-TEA and published key I tried several ways of changing the byte-order (or not changing it at all) and different keys but I was not able to get correct results. I verify the result by the flags field in byte 6 (should be 0 or 2) and byte 1 (protocol version?) which should be constant. Unfortunately, I just get random numbers. It would be really cool if you could point to me what I did wrong or if you could verify the key is correct. I spent quite some time with debugging already and am totally out of ideas. TIA! Best regards Manuel |
|
From: Tomasz R. <bog...@po...> - 2009-02-19 17:28:04
|
Dnia 2009-02-19, czw o godzinie 11:26 +0100, Stephan Jennewein pisze: > Hi, > > I need some information about the openbeacon protocol used on the 25c3. I have analysed dump generated by USB reader and here is my interpretation of 16 bytes of frame. byte(s) - meaning 1 - 0x18 2, 3 - ID of tag 4 - 16 (0x10) 5- flags, 2 if button pressed, 0 otherwise 6 - strength: 0, 1, 2 (3 is used for tag-tag sensing) 7 ,8 - recent contact ID 9, 10 - unused (other contact?) 11,12,13,14 - sequence number 15, 16 - CRC > > I got the 16 data bytes out of the pcap files, but what is in there and where? > The old decode code used 18bytes, what is fallen out? > Then I need to know how many packets a tag sends per second and in which > strength to the readers and other tags and how is this stored. What files do you have and where did you get them? > > Is the old map of the bcc still up to date ? If yes, how do I map the ip > addresses of the readers to the numbers on the map? It is rather up to data - except that during 25C3 there was no reader in the Heaven (F002 on the map/during 24C3) but one was placed in corridor leading to Heaven. I also attach Perl script I used to analyse data dumped by USB reader - but beware of ugly code. It also does not do anything except printing some numbers on the screen. It was used by me to come with description I place in this mail. -- Tomasz Rybak <bog...@po...> GPG key ID: F22C D870 Fingerprint 93BC FEEC A426 3765 799F 10EE FAC1 9A2C F22C D870 http://member.acm.org/~tomaszrybak |
|
From: Stephan J. <xt...@cc...> - 2009-02-19 10:43:37
|
Hi, I need some information about the openbeacon protocol used on the 25c3. I got the 16 data bytes out of the pcap files, but what is in there and where? The old decode code used 18bytes, what is fallen out? Then I need to know how many packets a tag sends per second and in which strength to the readers and other tags and how is this stored. Is the old map of the bcc still up to date ? If yes, how do I map the ip addresses of the readers to the numbers on the map? Stephan |
|
From: Tomasz R. <bog...@po...> - 2009-02-04 16:15:38
|
Dnia 2009-02-03, wto o godzinie 06:22 -0500, aestetix aestetix pisze: > Hey everyone, > > Thanks for your interest in the OpenAMD project. Every deployment > seems to bring new challenges, and now that we have integrated with > SocioPatterns.org, I think we will be taking RFID and social > networking to a whole new level. > > For those who missed out on the 25c3 deployment, we introduced peer to > peer contact between the badges. Not only could the system tell where > you were, but using the badge button, it could tell who you were near. > Although these tools are still in their infancy, we hope that people > with imagination and vision will come up with some really cool ideas. One initial question: where is the data from 25c3? On the same note, it would be nice to also have raw data from The Last HOPE. -- Tomasz Rybak <bog...@po...> GPG key ID: F22C D870 Fingerprint 93BC FEEC A426 3765 799F 10EE FAC1 9A2C F22C D870 http://member.acm.org/~tomaszrybak |
|
From: Patrick R. <pa...@pa...> - 2009-02-03 15:33:26
|
Hi folks, will there be an installation at the Easter Hegg 2009 this year? Bye, Patrick |
|
From: aestetix a. <aes...@gm...> - 2009-02-03 11:22:54
|
Hey everyone, Thanks for your interest in the OpenAMD project. Every deployment seems to bring new challenges, and now that we have integrated with SocioPatterns.org, I think we will be taking RFID and social networking to a whole new level. For those who missed out on the 25c3 deployment, we introduced peer to peer contact between the badges. Not only could the system tell where you were, but using the badge button, it could tell who you were near. Although these tools are still in their infancy, we hope that people with imagination and vision will come up with some really cool ideas. Any cutting edge technology has its challenges and difficulties; ours is no exception. Each new conference we deploy at, the code base matures substantially, and we are able to add in new features. This is where you come in. This is your data, whether it's tracking movement or interest data, and we would love any suggestions or contributions you may have in mind. If there was a feature that you loved, hated, wanted, etc, let's discuss it (as well as the privacy implications) and see what happens. Thanks again, aestetix and the OpenAMD team |
