| 00:00.07 | DocScrutinizer05 | donors* |
| 00:01.05 | DocScrutinizer05 | the window for preorders closing eventually. not though before new year |
| 00:01.40 | DocScrutinizer05 | this is just a heads-up yet |
| 00:03.10 | DocScrutinizer05 | to make those aware of the situation and plans who thought they will wait until true ordering for the finalized product will open |
| 00:04.07 | DocScrutinizer05 | they might find themselves in a second production run that may or may not happen, and for sure will take a few more months after first batch got finished |
| 00:04.59 | DocScrutinizer05 | we build to order, not for the shelf (we couldn't afford that) |
| 00:05.50 | DocScrutinizer05 | and to order means we need to order the components for our customers, which will take several weeks or months, and won't get repeated once done |
| 00:06.02 | DocScrutinizer05 | at least not before we finished first batch |
| 00:06.21 | DocScrutinizer05 | or rather, got enough orders to do a second batch |
| 00:12.57 | FIQ | wasn't there 3 donations today? |
| 00:13.31 | FIQ | just saying that you'll probably end up with around 240 rather than 229 if you close down donations soon after new year |
| 00:13.57 | FIQ | if the speed goes like the last few days |
| 00:20.54 | DocScrutinizer05 | two |
| 00:22.04 | FIQ | ah |
| 00:22.09 | FIQ | my point stands though |
| 00:22.16 | DocScrutinizer05 | and yes, we will of course adapt the true order volume of components to the number of prorders we received until that point in time |
| 00:22.43 | FIQ | referring to "as it looks right now we will source 229 components and that's it" |
| 00:22.48 | FIQ | yeah |
| 01:52.06 | winocm | IRQ! |
| 03:13.36 | *** join/#neo900 thrakcattack (~pi@193-83-233-231.adsl.highway.telekom.at) |
| 03:47.49 | *** join/#neo900 b1101 (~b@66.55.150.181) |
| 04:48.46 | *** join/#neo900 ishijoe (c414a5a3@gateway/web/freenode/ip.196.20.165.163) |
| 05:06.24 | *** join/#neo900 Herbstbert (~Herbstber@drms-4d0008c5.pool.mediaWays.net) |
| 06:52.22 | *** join/#neo900 freemangordon (~freemango@46.249.74.23) |
| 08:34.15 | *** join/#neo900 kolp (~quassel@212.255.241.73) |
| 10:09.48 | *** join/#neo900 archtimmy (~archtimmy@araneo.org) |
| 10:14.47 | obesd | DocScrutinizer05: what about an electric motor controlled by the host cpu, that when told it retracts the electricity plug from the baseband and any other black box components, so they cannot have electricity |
| 10:15.35 | obesd | then a hardware analysis on chosen baseband components to make sure they do not contain anything that could store and use electricity |
| 10:16.22 | obesd | and cutting off radio frequency rfid type energy supply as well etc |
| 10:17.10 | DocScrutinizer05 | nope, our approach is surveillance, not forcing |
| 10:17.40 | DocScrutinizer05 | I rather want to know that modem tried something fishy |
| 10:18.17 | DocScrutinizer05 | hi dos1 |
| 10:18.21 | DocScrutinizer05 | oops |
| 10:20.24 | DocScrutinizer05 | obesd: for you we will place a micro-explosive under the modem, to definitely shut it down for good. As soon as our surveillance/monitoring shows it tries to communicate to somebody when it shouldn't |
| 10:20.56 | DocScrutinizer05 | saves us all hardware analysis for hidden plutonium batteries and the like |
| 10:39.30 | *** join/#neo900 sequantz (~sequantz@194.11.24.44) |
| 10:45.56 | *** join/#neo900 freemangordon_ (~freemango@46.249.74.23) |
| 11:03.27 | obesd | DocScrutinizer05: loll :) |
| 11:03.50 | obesd | yeah you have a good point there, surveillance of when the black box does something suspicious |
| 11:03.53 | obesd | thats important |
| 11:04.47 | obesd | i wonder if an OS like replicant will make use of the technology and alert me (or log) when the modem decides it will try to secretly stay on or do other things |
| 11:07.20 | FIQ | tbh I doubt the modem is evil |
| 11:26.08 | *** join/#neo900 Neros (~quassel@24-55-190-109.dsl.ovh.fr) |
| 11:26.58 | DocScrutinizer05 | tbh I am quite sure it's genuinely not |
| 11:27.12 | DocScrutinizer05 | but I also know there are exploits OTA |
| 11:27.28 | DocScrutinizer05 | and even: |
| 11:27.36 | DocScrutinizer05 | ~gsm-agps |
| 11:27.36 | infobot | rrlp is, like, the Radio Resource LCS (Location Service) Protocol as specified first in GSM TS 04.31, or http://security.osmocom.org/trac/wiki/RRLP |
| 11:28.18 | DocScrutinizer05 | and stuff like silent SMS, to triangulate the MT |
| 11:28.22 | DocScrutinizer05 | ME |
| 11:28.26 | obesd | FIQ: if you doubt the baseband is evil, you havent been researching basebands enuff ;-D |
| 11:28.57 | DocScrutinizer05 | I'm absolutely sure baseband is crappy like hell |
| 11:29.29 | DocScrutinizer05 | I've seen 2 firmwares so far |
| 11:29.45 | obesd | DocScrutinizer05: i am curious about the rumours i keep hearing about fake basestations or gsm operators being able to send commands to your baseband, to either execute code on the baseband or on the sim card (eg "operator update") |
| 11:30.17 | obesd | yeah it is clear there are remote exploits to execute code on the baseband |
| 11:30.44 | DocScrutinizer05 | yes, SIM is yet another "second OS" (see that silly article) that can execute stuff and even get commands OTA |
| 11:30.54 | obesd | im interested to know if there are actual "features" perhaps intended for operators to apply important updates inside the sim for example |
| 11:31.14 | DocScrutinizer05 | yes, there are |
| 11:31.39 | DocScrutinizer05 | you can send SMS that go directly to the SIM and trigger in SIM whatever operator placed in there |
| 11:31.40 | obesd | interesting, so the operator can execute arbitary commands in the sym ? i heard something about them being able to send a java applet, which is run by the sim |
| 11:32.03 | FIQ | [12:30:44] <DocScrutinizer05> yes, SIM is yet another "second OS" (see that silly article) that can execute stuff and even get commands OTA |
| 11:32.15 | FIQ | pretty sure there's a good reason to this |
| 11:32.23 | FIQ | for convenient service |
| 11:32.25 | obesd | so say they execute commands on the sim, what can the sim do ? |
| 11:32.32 | FIQ | not surprised if it's abused for other stuff though... |
| 11:32.55 | DocScrutinizer05 | the SIM can do almost anything, with the modem |
| 11:33.01 | FIQ | i.e. for stuff like reset PIN, force deactivate it (nonpaying customer) and such |
| 11:33.22 | obesd | interesting |
| 11:33.50 | obesd | so without even using any exploits, an operator could send a sim command to active silent answer mode, and hear things through the microphone ? |
| 11:33.59 | DocScrutinizer05 | SAT is defining that SIM has full control over display and over HID |
| 11:34.26 | DocScrutinizer05 | when the MT has any such display and HID aka kbd/touchscreen |
| 11:34.39 | DocScrutinizer05 | SIM can initiate SMS and phonecalls |
| 11:34.46 | FIQ | well, sim has good reasons to have ota control commands |
| 11:34.51 | FIQ | unless it's too powerful |
| 11:34.54 | DocScrutinizer05 | and of course chage own program |
| 11:34.55 | FIQ | and/or abused |
| 11:35.26 | obesd | it would be good to see a full numeration on some wiki of exactly what can be done |
| 11:35.33 | FIQ | i.e. "send SMS on demand" is something I hardly see a reason for |
| 11:35.41 | DocScrutinizer05 | also I think the SIM has control over the phonebook stored in modem |
| 11:35.56 | DocScrutinizer05 | when the modem has such phonebook |
| 11:35.57 | obesd | yeah the sim seems to have its on sim-stored address book |
| 11:36.07 | obesd | yeah the sim seems to have its own* sim-stored address book |
| 11:36.18 | DocScrutinizer05 | sure |
| 11:36.30 | FIQ | oh yeah I remember that from the old phone days |
| 11:36.37 | DocScrutinizer05 | there's a SIM based AB and a modem based AB |
| 11:36.43 | FIQ | there was 2 storage options for contacts etc |
| 11:36.52 | FIQ | and SMS |
| 11:36.54 | DocScrutinizer05 | same for SMS |
| 11:37.22 | FIQ | hm |
| 11:37.55 | obesd | hmm so on most phones can the modem listen to the microphone? i would assume yes, but havent seen any evidence |
| 11:37.58 | FIQ | I wonder if the SIM was more powerful than the phone itself back in the 3310 days |
| 11:38.05 | DocScrutinizer05 | obesd: yes |
| 11:38.31 | DocScrutinizer05 | FIQ: not really |
| 11:38.41 | anYc | I guess they also evolved |
| 11:39.01 | obesd | DocScrutinizer05: so i guess it would logically follow then, that the operator can simply send a command, without any exploits, to the sim and/or modem and tell it to answer phone calls without ringing, then listen in on the microphone? |
| 11:39.15 | anYc | e.g., I had to replace my SIM in order to use UMTS |
| 11:39.30 | DocScrutinizer05 | obesd: I guess yes that's possible |
| 11:39.41 | FIQ | I wonder if the same applies for LTE? @ anYc |
| 11:40.02 | obesd | DocScrutinizer05: yeah i have heard rumours of that ability, but not hard facts/data on how, or if it was exploit based or simply just built in |
| 11:40.46 | anYc | I don't know. I don't own any LTE device yet. |
| 11:41.08 | FIQ | wouldn't be surprised if the SIM contained some odd exploits that none knows about that allows command execution by end user - or worse, via stuff like SMS |
| 11:41.13 | obesd | i have seen some presentations on exploiting basebands over IP connections too |
| 11:41.20 | FIQ | kinda like the weird iPhone sms exploits a few years ago :D |
| 11:41.23 | obesd | so a fake tower wouldnt be needed |
| 11:41.47 | DocScrutinizer05 | FIQ: that's no exploit, that's a pretty standard feature I think |
| 11:42.12 | obesd | FIQ: what was this iphone sms exploit i havent heard about? |
| 11:42.34 | FIQ | obesd: let me google a bit, it was a while ago I heard about it |
| 11:43.51 | FIQ | http://www.forbes.com/2009/07/28/hackers-iphone-apple-technology-security-hackers.html as I said, old :D |
| 11:43.58 | obesd | cheers. i also see this http://www.forbes.com/2009/07/28/hackers-iphone-apple-technology-security-hackers.html and sms spoofing |
| 11:44.11 | obesd | lol same link |
| 11:44.35 | DocScrutinizer05 | O2-germany offers so called "homezone", where the SIM calculates if you are in a radius of 500m around some address you defined as your "home", calls are cheaper in this homezone |
| 11:45.01 | DocScrutinizer05 | the SIM does some trigonometric math to decide whether or not you are in homezone |
| 11:45.09 | obesd | the research presenting on basebands said the various GSM standards group had a 80s approach to security, and thought all the "operator features" they where building in couldnt be abused, but now any cracker could use them with a fake base station |
| 11:45.20 | DocScrutinizer05 | and obviously it does some other stuff via the radio too |
| 11:45.31 | DocScrutinizer05 | since it works without GPS |
| 11:46.58 | DocScrutinizer05 | obesd: that's basically the situation, yes |
| 11:47.57 | DocScrutinizer05 | while the phone needs to pass tough authentication to get accepted by the network, the network aka BTS doesn't need to authenticate at all to the mobile |
| 11:48.19 | FIQ | no authorization requirement? genius! |
| 11:48.34 | DocScrutinizer05 | since the whole security concern back when been about not allowing any fraud |
| 11:48.52 | FIQ | how come there hasn't been *any* reports on this actually happening? |
| 11:48.54 | *** join/#neo900 lufu (~user@5.254.129.118) |
| 11:49.16 | DocScrutinizer05 | err, we seen that on CCC two years ago iirc |
| 11:49.29 | FIQ | i.e. people trolling others' sim |
| 11:50.05 | DocScrutinizer05 | Harald ran a local 'test' BTS and watched people's phones roaming to that BTS and people sending SMS via that BTS |
| 11:50.35 | DocScrutinizer05 | and I think they even demonstarted a SMS to Nokia phones that killed them |
| 11:52.00 | DocScrutinizer05 | http://berlin.ccc.de/~tobias/cursesms.txt |
| 11:52.25 | obesd | FIQ: maybe because the crackers can be very undetectable with this ;) |
| 11:54.37 | obesd | i have seen spoofed sms' before |
| 11:55.36 | DocScrutinizer05 | http://de.wikipedia.org/wiki/OpenBSC |
| 11:55.54 | DocScrutinizer05 | http://chaosradio.ccc.de/25c3_m4v_3007.html |
| 11:59.18 | DocScrutinizer05 | 2:20 |
| 12:03.22 | obesd | thanks |
| 12:03.32 | obesd | so there is a 2009 blackhat presentation on this sms exploit somewhere as wel |
| 12:11.13 | DocScrutinizer05 | yeah, my friend Harald. always a joy to listen to his talks |
| 12:21.14 | obesd | nice |
| 12:40.44 | obesd | so you are friends with Harald? |
| 12:40.44 | obesd | thats cool |
| 12:40.48 | obesd | know any links of his talks :) ? |
| 12:41.16 | obesd | i found these links on sms hacks https://www.youtube.com/watch?v=qBWc67iy4zI https://www.youtube.com/results?search_query=Attacking+SMS&sm=3 dunno if they are any good yet (havent seen them yet) |
| 12:42.07 | DocScrutinizer05 | check gnumonks.org |
| 12:42.41 | DocScrutinizer05 | Harald and I shared Openmoko visitor appartment when we were both at Taipei |
| 12:42.51 | obesd | nice sounds like fun |
| 12:43.29 | obesd | oh man i think i could add this to my pentesting services |
| 12:43.57 | obesd | i know a number of high security entities, who actually have many staff's mobile phones VPNed into the corporate network |
| 12:46.10 | DocScrutinizer05 | currently I'm in a slow chat with Harald about which RFID/NFC chip to use for Neo900 |
| 12:47.14 | DocScrutinizer05 | alas [2013-12-13 13:12:13] [Whois] LaF0rge has been idle for 5 days, 14 hours, 24 minutes, and 17 seconds. |
| 12:47.29 | obesd | interesting, hopefully a secure one hehe :) |
| 12:47.39 | obesd | lol that is slow |
| 12:47.47 | DocScrutinizer05 | how could it be insecure? |
| 12:48.07 | DocScrutinizer05 | I mean, it's connected via I2C or UART |
| 12:48.30 | obesd | perhaps a wireless exploit |
| 12:48.40 | DocScrutinizer05 | to exploit what? |
| 12:49.21 | obesd | perhaps the NFC driver in the host OS could have a buffer overflow in some part of the code that is run, before any user prompts. perhaps the nfc chip itself has firmware exploits over the air |
| 12:50.12 | DocScrutinizer05 | well, perhaps the USB driver has exploits, or the kbd driver has exploits |
| 12:50.20 | obesd | perhaps they do, yes |
| 12:50.32 | DocScrutinizer05 | how is that relevant for my selection of NFC chip? |
| 12:50.46 | obesd | well perhaps some vendors have more crappy implementations of the NFC stack than others |
| 12:50.59 | DocScrutinizer05 | so what? |
| 12:51.33 | obesd | perhaps a more robust implementation is a better choice, perhaps, depending on the big picture |
| 12:51.36 | DocScrutinizer05 | what do you hope to "exploit" in that chip? the MAC? |
| 12:51.42 | ShadowJK | suspects we don't get a nfc stack with the chip |
| 12:52.18 | obesd | well yes an exploit such as this http://www.zdnet.com/exploit-beamed-via-nfc-to-hack-samsung-galaxy-s3-android-4-0-4-7000004510/ |
| 12:52.36 | DocScrutinizer05 | LOL, how's that related to the chip? |
| 12:52.38 | obesd | i havent read to much about it, it may be independant of the NFC chip, and reply upon exploiting android software |
| 12:53.02 | obesd | maybe some NFC chips have remote firmware level exploits as well |
| 12:53.16 | DocScrutinizer05 | have WUT? |
| 12:53.39 | obesd | how about i do some research on NFC chips, then get back to you ;-) |
| 12:55.27 | DocScrutinizer05 | yeah, sounds like a plan: you learn a bit about NFC chips and how they work, Then come back and tell me what's your concerns if you still have any then |
| 12:55.51 | obesd | that sounds good |
| 12:56.05 | DocScrutinizer05 | please keep in mind that Neo900 group doesn't do any OS related stuff |
| 12:56.11 | obesd | Everything is hackable, its just a question of how :) |
| 12:56.18 | obesd | yeah just the hardware ok |
| 12:56.27 | DocScrutinizer05 | sure you can hack my wrist watch |
| 12:56.57 | DocScrutinizer05 | I'm just wondering what's the possible *exploit* of such endeavor |
| 12:57.14 | obesd | So am I too actually, busy trying to find any information on that |
| 12:57.36 | obesd | (for nfc chips, not wristwatches;) |
| 12:58.38 | DocScrutinizer05 | well, you could make my watch going faster, and you could detune the carrier frequency of the NFC |
| 12:58.52 | DocScrutinizer05 | I still don't see what that gets you |
| 13:00.18 | obesd | well im not sure whats in nfc chips exactly, if there is a cpulike core and firmware running, gaining remote wireless code execution on that could get you something, like further access into the phone |
| 13:00.28 | DocScrutinizer05 | sounds like "hacking the IrDA dongle" |
| 13:01.22 | DocScrutinizer05 | no, you can't get further access to the phone via NFC, just like you can't via the modem or via the UART or the USB |
| 13:02.04 | obesd | im inclined to at least think to myself "orly" ;) |
| 13:02.27 | DocScrutinizer05 | hacking WLAN or BT chips you at least theoretically could tamper my encryption |
| 13:02.54 | obesd | cant many of those wlan chips also do dma ? |
| 13:03.04 | obesd | and thus subvert the OS kernel |
| 13:03.09 | DocScrutinizer05 | you could hack my printer and try to gain access to my PC |
| 13:03.19 | obesd | yeah you can actually |
| 13:03.27 | obesd | there was a good presentation on that |
| 13:03.32 | DocScrutinizer05 | haha |
| 13:04.22 | DocScrutinizer05 | I dunno about your PC but mine doesn't accept code from the printer |
| 13:05.06 | DocScrutinizer05 | and Neo900 CPU won't accept code to execute, from NFC |
| 13:05.23 | DocScrutinizer05 | nor from modem, nor from WLAN or BT |
| 13:05.50 | obesd | yeah but if we where talking about many NICs and WLAN chips they have DMA access to host ram, and can patch the OS kernel, without permission from the host cpu |
| 13:06.35 | DocScrutinizer05 | Neo900 doesn't |
| 13:06.49 | DocScrutinizer05 | this is not a PCI card |
| 13:07.00 | obesd | im more familar with PCs than mobile phones, but in many PC based NICs if you can exploit their firmware and execute arbritary code on their inbuilt cpu you can then |
| 13:07.01 | obesd | ahh right |
| 13:07.13 | obesd | ahh well thats good then :) |
| 13:08.36 | obesd | not talking about neo900 here, as the neo900 has been designed more securely than all the other mobile phones i've seen, but the other mobile phones ive seen seem to have been designed even less securely than a pc |
| 13:14.57 | DocScrutinizer05 | probably the worst exploit you could do to NFC: make it transmit RF constantly |
| 13:15.18 | DocScrutinizer05 | so you could localize the device by a receiver |
| 13:15.34 | DocScrutinizer05 | over a distance of at least 50m |
| 13:15.44 | DocScrutinizer05 | when you got a really good one |
| 13:17.00 | DocScrutinizer05 | however for that you'd need to enable the whole NFC on APE CPU side first |
| 13:17.52 | DocScrutinizer05 | and when it is enabled then you *per definitionem* cam make a RFID send when you ping it with a RF signal challenge so it sends a response |
| 13:18.40 | DocScrutinizer05 | since that's what RFID/NFC is designed to do. I don't see the exploit |
| 13:19.45 | DocScrutinizer05 | the exploit is like "hahaha take THIS! I didn't switch off the light on your closet when I left" |
| 13:24.32 | obesd | what about this stuff: https://github.com/arduino/Arduino/issues/1354 http://xorl.wordpress.com/2011/07/24/cve-2011-2700-linux-kernel-si4713-i2c-buffer-overflow/ so its the OS not the chip, but if the chip itself where vulnerable to a remote code execution by exploiting a vulnerability in the chips firmware, and running the exploit on the NFC chip the attacker could then exploit the OSes i2c drivers if vulnerable |
| 13:25.39 | obesd | please excuse my 15 minutes of research on this, i havent been able to become a hardware/firmware/nfc/i2c exploitation expert in this amount of time ;-) |
| 13:26.49 | obesd | seems OS drivers usually are written to help things if the various hardware chips in a device is misbehaving/has a known hardware weird behaviour, but rarely are the drivers written to assume a hostile chip and protect against it |
| 13:28.34 | DocScrutinizer05 | sorry, I2C sends commands to chip and then actively reads a limited set of 8bit register values which are handles strictly as data payload, no index or whatever in it, no end marker, nothing. I can't see how to exploit that |
| 13:29.36 | DocScrutinizer05 | it's like trying to create a buffer oerflow by pressing the left mousebutton ;-P |
| 13:29.52 | FIQ | proceeds to hammer the left mousebutton really hard |
| 13:30.58 | obesd | isnt the xor link an example of exploiting an i2c driver |
| 13:31.00 | DocScrutinizer05 | I mean I2C is a TWO-wire "bus" |
| 13:32.52 | DocScrutinizer05 | sure you can write arbitrary crappy drivers for about everything and have biffer overflows in it, and I bet you wind a scenario for each such buffer overflow where it kicks in |
| 13:33.03 | obesd | yeah |
| 13:33.47 | obesd | so i guess if they could exploit a firmware bug on a nfc chip to run arbritary code on the nfc chip, then leverage that position to exploit a host i2c driver they could then own the OS |
| 13:34.20 | DocScrutinizer05 | but when I monitor my door bell by polling a GPIO on my PC, then I have a hard time thinking about you coming with whatever contraption you attach to my door bell knob to make my PC get a buffer overflow |
| 13:34.36 | obesd | yeah i have a hard time thinking about it too |
| 13:35.46 | DocScrutinizer05 | you must be really thck to write a driver for a two-wire master that would have a buffer overflow exploit |
| 13:36.09 | obesd | it seems V4L did it hehe |
| 13:36.17 | DocScrutinizer05 | wut? |
| 13:36.27 | obesd | video4linux, in http://xorl.wordpress.com/2011/07/24/cve-2011-2700-linux-kernel-si4713-i2c-buffer-overflow/ |
| 13:36.32 | DocScrutinizer05 | how's V4L a 2-wire bus? |
| 13:37.09 | DocScrutinizer05 | meh, this is a pretty useless and futile discussion |
| 13:37.12 | obesd | * Video4Linux Subdev Interface, drivers/media/radio/si4713-i2c.c |
| 13:37.14 | DocScrutinizer05 | err "discussion" |
| 13:37.20 | obesd | i presume thats an i2c driver there |
| 13:37.49 | obesd | on the n900 |
| 13:38.32 | obesd | dont know why there is video 4 linux stuff in a n900 radio transmitter i2c driver actually, i though v4l was for inbuilt usb webcams or something |
| 13:39.04 | DocScrutinizer05 | I don't know how that's related to hardware |
| 13:39.33 | obesd | well someone asked "Well they cant do anything anyway even if they exploited an nfc chip" and i chimed in about perhaps using it to get further into a phone |
| 13:39.49 | obesd | needing to post more concrete information i posted an example of exploiting an nfc chip, then using that position to exploit an i2c driver |
| 13:39.57 | DocScrutinizer05 | cya |
| 13:39.59 | obesd | to backup my point with more information |
| 13:43.29 | obesd | Its related to hardware because if you chose a NFC hardware chip that has lots of over the air exploits allowing an attacker to run abritary code on the NFC chip, then the attacker has now gained a more privileged position in which to attack other parts of the phone, like i2c drivers which are usually designed to think that the hardware chip itself would never be intentionally malicious |
| 13:43.40 | DocScrutinizer05 | I'm not interested in discussion of the level "when somebody writes a flawed app that monitors the PSU fan rotations and it might have a buffer overflow when the fam speed has 4000, 4444,4000 in 1s intervals, then you could exploit the vacuum cleaner's control chip so you gain access to the PC via buffer overflow in said app, when you hold the vacuum cleaner to the PC's fan exhaust" |
| 13:43.43 | obesd | or maybe you could say thats just simply related to security |
| 13:43.50 | *** join/#neo900 Herbstbert (~Herbstber@drms-4d0008c5.pool.mediaWays.net) |
| 13:44.19 | obesd | well its nice to compare to vacuum cleaners, except the reason the security community has been all over nfc is because any security vulnerabilities can be exploited by walking past someone |
| 13:45.02 | DocScrutinizer05 | haha |
| 13:45.04 | *** join/#neo900 edgar2 (~edgar2@85-156-104-112.elisa-mobile.fi) |
| 13:45.16 | obesd | or going to a financial conference with an exploit device hidden in your pocket and hanging around chatting with people, pwning their phones |
| 13:45.50 | DocScrutinizer05 | yeah great. I'm sure you could do this with a Neo900 ;-P |
| 13:46.10 | DocScrutinizer05 | after all that's what NFC is made for |
| 13:47.01 | DocScrutinizer05 | your fault when you install above mentioned app on your device |
| 13:47.25 | DocScrutinizer05 | and nothing the hw designer can do to protect you from such stupidity |
| 13:48.41 | DocScrutinizer05 | all we can do is to restrict the number of connections to CPU to 3 wires, and all 3 under full control of the CPU |
| 13:49.29 | DocScrutinizer05 | when you decide to monitor one of the three and when it goes low you detonate the nuke inside the device... your problem, not mine |
| 13:50.16 | DocScrutinizer05 | I tell you there is NO WAY I2C can hurt the CPU when the CPU doesn't ask for getting hurt |
| 13:50.38 | obesd | yes i agree |
| 13:50.55 | DocScrutinizer05 | ok, next topic then |
| 13:51.29 | obesd | though i dont know if there is much difference between different nfc chips and if people will be finding remotely exploitable bugs in their firmware, so having a more secure nfc chip could be beneficial for the user who is concerned about security ;) |
| 13:51.33 | obesd | ok next topic |
| 13:52.01 | DocScrutinizer05 | headdesks |
| 13:52.21 | DocScrutinizer05 | more secure dor bell knob |
| 13:52.30 | DocScrutinizer05 | suuuure |
| 13:52.50 | obesd | i2c driver above was already shown to be exploitable ;) |
| 13:52.53 | obesd | thats a way in |
| 13:53.00 | DocScrutinizer05 | SO WHAT?? |
| 13:53.09 | DocScrutinizer05 | I'm starting to ponder getting +o |
| 13:53.31 | obesd | um, so the attacker can run kernel mode in the users phone, stealing their credentials,passwords whatever |
| 13:53.43 | *** mode/#neo900 [+o DocScrutinizer05] by ChanServ |
| 13:54.03 | DocScrutinizer05 | you're noticing you start trolling, do you? |
| 13:54.57 | obesd | nah i honestly dont get it, ive been working in security for 15 years, what im saying seems on the ball to me |
| 13:55.38 | DocScrutinizer05 | oh great, dunno how often you suggested to your customers to get safer door bell button |
| 13:56.17 | DocScrutinizer05 | when there's a vulnerability in kernel, FIX IT!!! |
| 13:56.28 | DocScrutinizer05 | it's not my job to fix it in hardware |
| 13:56.44 | DocScrutinizer05 | and don't dare to answer! |
| 13:56.52 | obesd | but we've just demonstrated how choice (1) nfc chip with no remotely exploitable firmware bugs vs (2) nfc chip with remotely exploitable firwmare bugs, could provide a more privileged position to an attacker, to launch attacks on things like i2c drivers, to me that makes it relevant to choose a nfc chip in the first place with less bugs, thats pretty much my only point, unless im totally missing the point |
| 13:56.52 | DocScrutinizer05 | >:-( |
| 13:57.01 | obesd | nah its not your job to worry about software implementations |
| 13:57.10 | *** mode/#neo900 [+q obesd!*@*] by DocScrutinizer05 |
| 13:57.49 | DocScrutinizer05 | we don't like this sort of negative propaganda and PR here, based on false basics |
| 13:58.50 | DocScrutinizer05 | you simply miss the point that your brilliant I2C exploit didn't need any rooting of the chip |
| 13:59.05 | DocScrutinizer05 | and now excuse me please |
| 13:59.22 | DocScrutinizer05 | I have to find a rope to shoot myself |
| 14:00.37 | *** part/#neo900 obesd (~obsed@ppp121-45-210-202.lns20.cbr1.internode.on.net) |
| 14:00.55 | *** mode/#neo900 [-q obesd!*@*] by DocScrutinizer05 |
| 14:00.58 | *** mode/#neo900 [-o DocScrutinizer05] by ChanServ |
| 14:04.27 | DocScrutinizer05 | New bug in PulseAudio found: the upsampler/rate-converter creates a buffer overflow in kernel space when audio signal is composed of exactly 2 sine waves of the frequencies 333Hz and 5678Hz |
| 14:04.57 | DocScrutinizer05 | Oh PLEASE could we use microphones in Neo900 that filter out those two frequencies? |
| 14:06.26 | DocScrutinizer05 | there must be safer microphones and less safe ones |
| 14:07.10 | DocScrutinizer05 | heck when it's a digital mic we must make sure that it can't get rooted to bypass the filters |
| 14:08.08 | DocScrutinizer05 | *sigh* |
| 14:08.11 | DocScrutinizer05 | o/ |
| 14:09.01 | FIQ | exploits are silly, but it's hardly your fault if the reason is that someone was stupid when creating the firmware |
| 14:16.49 | DocScrutinizer05 | FIQ: I just get angry when somebody tells my I don't do the optimum possible to create the safest and best hardware, and then demands I should design to filter out certain data sequences from an input stream that's supposed to be immune against any arbitrary data sequence, and the definition of what I should filter out is a possible bug in the driver (prolly linux driver) for that interface |
| 14:18.58 | DocScrutinizer05 | heck, show me the bug so I can get to know about the particular data sequence I shall filter out! but probably I will answer "why don't you fix it in software right away?" |
| 14:21.12 | DocScrutinizer05 | FIQ: particularly the problem is: when you leave any such statement unanswered, people think you don't know to answer/fix the issue. No matter if you answered the same statement 50 times in the previous 50 posts |
| 14:24.08 | DocScrutinizer05 | kinda like this one: http://xkcd.com/641/ |
| 14:24.47 | DocScrutinizer05 | >>duh, Neo900 doesn't block against vulnerabilities in I2C NFC<< |
| 14:25.08 | DocScrutinizer05 | >:-( |
| 14:25.52 | *** join/#neo900 MMN-o (~mmn@213-21-90-183.customer.t3.se) |
| 14:26.30 | DocScrutinizer05 | reddit makes "Neo900 RFID vulnerability" out of that |
| 14:27.18 | DocScrutinizer05 | and don't ask me what it becomes on /. then |
| 15:04.59 | *** join/#neo900 hbib (~wurmel@pD9E3C4F2.dip0.t-ipconnect.de) |
| 15:10.28 | *** join/#neo900 lexik_ (~alex@ip-89-176-75-35.net.upcbroadband.cz) |
| 15:16.44 | *** join/#neo900 lexik_ (~alex@ip-89-176-75-35.net.upcbroadband.cz) |
| 15:21.46 | *** join/#neo900 lexik (~alex@ip-89-176-75-35.net.upcbroadband.cz) |
| 15:34.09 | *** join/#neo900 lexik_ (~alex@ip-89-176-75-35.net.upcbroadband.cz) |
| 15:43.47 | *** join/#neo900 Neros (~quassel@24-55-190-109.dsl.ovh.fr) |
| 16:06.52 | *** join/#neo900 freemangordon (~freemango@46.249.74.23) |
| 16:29.50 | *** join/#neo900 NIN101 (~NIN@p5DD290E1.dip0.t-ipconnect.de) |
| 16:38.29 | *** join/#neo900 freemangordon (~freemango@46.249.74.23) |
| 16:38.29 | *** join/#neo900 MMN-o (~mmn@213-21-90-183.customer.t3.se) |
| 16:42.13 | *** join/#neo900 struppi_ (~struppi@struppi.name) |
| 16:43.09 | *** join/#neo900 Hakki_ (~hakki@ip212-226-155-81.adsl.kpnqwest.fi) |
| 16:45.51 | *** join/#neo900 MMN-o_ (~mmn@213-21-90-183.customer.t3.se) |
| 16:46.34 | *** join/#neo900 dos1 (~dos@unaffiliated/dos1) |
| 16:54.02 | *** join/#neo900 freemangordon (~freemango@46.249.74.23) |
| 18:13.51 | *** join/#neo900 b1101 (~b@66.55.150.181) |
| 19:15.30 | *** join/#neo900 ishijoe (c414a5a3@gateway/web/freenode/ip.196.20.165.163) |
| 19:21.38 | ishijoe | hello everyone |
| 19:22.33 | ishijoe | I don't know if I can ask it here but I'm from mauritius and wanted to know if I can order the neo900 |
| 19:22.34 | ishijoe | if yes how? |
| 20:18.18 | *** join/#neo900 NIN101 (~NIN@p5DD290E1.dip0.t-ipconnect.de) |
| 20:19.42 | *** join/#neo900 NIN101 (~NIN@p5DD290E1.dip0.t-ipconnect.de) |
| 20:46.10 | *** join/#neo900 hbib1 (~wurmel@pD9E0EFBB.dip0.t-ipconnect.de) |