Re: Few comments after reading Wiki
Heilpern, Mark wrote: If you want to roll your own, with Linux support, check out http://flash-plaice.wikispaces.com/. Wow, this is great ! And the one on sump.org is even closer to what I'm looking for (same hardware, but simpler design). Thanks a lot ! - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Simon Matthews wrote: Could you tell me the make and model of the new MPU, and maybe some links to datasheets. It's the Samsung 2442, http://www.samsung.com/Products/Semiconductor/MobileSoC/ApplicationProcessor/ARM9Series/SC32442/um_s3c2442b_rev12.pdf I am intrigued to see how they implement the protection. Yeah, me too :-) Section 6 basically says that it works, but doesn't give any details on how. I'd try the following types of attack: - confuse the state machine: disable the NAND controller block between sending command and address, and see what happens. - combine operations: start a write command, turn the NAND control lines to GPIO, send the address, take the rejection, send a harmless command, switch the GPIOs back to NAND control, and send the address. - completely bypass the NAND control block: set the slowest memory timing, control the NAND signals through GPIO, then do a memory write to put the right kind of data on the bus. A logic analyzer may be handy for this type of experiments. (There are some quite resonably priced PC-based ones, alas none of them seem to play nice with Linux :-( Alas, building my own with a small FPGA is a bit too much work for a lunch break project.) - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
On Wed, 23 May 2007, Werner Almesberger wrote: Simon Matthews wrote: Could you tell me the make and model of the new MPU, and maybe some links to datasheets. It's the Samsung 2442, http://www.samsung.com/Products/Semiconductor/MobileSoC/ApplicationProcessor/ARM9Series/SC32442/um_s3c2442b_rev12.pdf I am intrigued to see how they implement the protection. Yeah, me too :-) Section 6 basically says that it works, but doesn't give any details on how. I'd try the following types of attack: - confuse the state machine: disable the NAND controller block between sending command and address, and see what happens. - combine operations: start a write command, turn the NAND control lines to GPIO, send the address, take the rejection, send a harmless command, switch the GPIOs back to NAND control, and send the address. - completely bypass the NAND control block: set the slowest memory timing, control the NAND signals through GPIO, then do a memory write to put the right kind of data on the bus. A logic analyzer may be handy for this type of experiments. (There are some quite resonably priced PC-based ones, alas none of them seem to play nice with Linux :-( Alas, building my own with a small FPGA is a bit too much work for a lunch break project.) There are a couple of PC-based LAs that work with Linux. Look for the xoscope project, I think it has links to a couple of such LAs. Michael ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
On Wed, 23 May 2007, Werner Almesberger wrote: [EMAIL PROTECTED] wrote: There are a couple of PC-based LAs that work with Linux. Look for the xoscope project, I think it has links to a couple of such LAs. Hmm, only the BitScope, which is a nice device, but its digital capabilities are fairly limited. What I'm thinking of is something like the LogicPort: http://www.pctestinstruments.com/ I'll check with my friends. I'm sure I've seen something. M ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
[EMAIL PROTECTED] wrote: There are a couple of PC-based LAs that work with Linux. Look for the xoscope project, I think it has links to a couple of such LAs. Hmm, only the BitScope, which is a nice device, but its digital capabilities are fairly limited. What I'm thinking of is something like the LogicPort: http://www.pctestinstruments.com/ - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
I use both a LogicPort and a DigiView (www.tech-tools.com). The DigiView is a little more expensive, but it has a huge capture buffer. (I think the DV is 128kb, where the LogicPort is 4kb.) Conversely, the LogicPort has 34 input signals where the DV has only 18. The application provided with the LogicPort is much more polished; DV's is pretty rocky. I still use the DV much more often, carrying the LogicPort only as a backup. If you want to roll your own, with Linux support, check out http://flash-plaice.wikispaces.com/. (I'm not sure, but I may have first found that link on this mailing list.) I haven't played with that device, but if I had more free time -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, May 23, 2007 12:55 PM Cc: community@lists.openmoko.org Subject: Re: Few comments after reading Wiki On Wed, 23 May 2007, Werner Almesberger wrote: [EMAIL PROTECTED] wrote: There are a couple of PC-based LAs that work with Linux. Look for the xoscope project, I think it has links to a couple of such LAs. Hmm, only the BitScope, which is a nice device, but its digital capabilities are fairly limited. What I'm thinking of is something like the LogicPort: http://www.pctestinstruments.com/ I'll check with my friends. I'm sure I've seen something. M ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately. Thank you. AuthenTec, Inc. http://www.authentec.com ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
On Wed, 2007-05-16 at 19:55 -0300, Werner Almesberger wrote: You'll (almost certainly) be able to do this as well: the new MCU will allow you to specify which NAND Flash area can be written to. Once this is set, it cannot be changed without a reset. So this would be a hardware assisted solution. Unfortunately, you can probably bypass it if you're determined. Could you tell me the make and model of the new MPU, and maybe some links to datasheets. I did look in the WIKI and in previous messages but couldn't find these details. I am intrigued to see how they implement the protection. Thanks Simon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
1. I hope, that there will be made SAR tests and results will be very low Why? It may help with marketing, but the worst it could do (unless it's several orders of magnitude beyond what current phones) is make you a bit warm. Non-ionizing radiation is not a cause of cancer. Better to worry about things that there is actually evidence to back up - like radon, or using the phone while driving :-) Not exactly only marketing. When I used phone with SAR 1,2, I feel much worse sometimes. When I have phone with 0,5, I can speak hours. This is maybe suggestion only, but maybe not... And I don't care about cancer and similiar things. Please note, that nobody has given profs for and against cell phones. IMHO, people will think more and more about it. If you want to have more sells, you have to think about it. Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
5. hav developers though about creating it on kind of x86 compatible platform ? I know, it could be more difficult to create energy efficient device, but having PC in pocket (with ability to running dos, windows after changing SD card) would be more than excellent yes, i have. i don't know about any others though i'm waiting for via to release the pico-itx board they've been promising and will see what i can do with that to create a UMPC/phone/pda type combo. this board/cpu promises ultra-low power and hw accelerated video playback, looks very interesting and would be awesomely flexible/powerful as you say, the main issue is power - x86 isn't really optimized for anything as it's such a generalised architecture. my calcs at the moment on power are struggling to get more than a few hours use with a reasonable size battery As I'm not hardware guy, I don't know if it has sence, but (of course, it will be more diffiult than current): Chipset will have support for CPU, RAM, flash, one USB hub. No SATA, PATA and similiar. Additionaly cpu 9something about 200 - 400 Mhz), ram, flash and devices connected over usb... Maybe this will be more exergy efective Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
I was thinking about protecting memory with main phone software (like kernel, boot loader, main apps). You'll (almost certainly) be able to do this as well: the new MCU will allow you to specify which NAND Flash area can be written to. Once this is set, it cannot be changed without a reset. So this would be a hardware assisted solution. Unfortunately, you can probably bypass it if you're determined. So, the scenario can be: spefifying area by virus and getting device to reset to have full control... Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Marcin Wiacek wrote: So, the scenario can be: spefifying area by virus and getting device to reset to have full control... At which time your (still protected) firmware sets the protection again, and executes the regular code. But yes, if you add an easily changeable vector before that point, you lose :-) The bypass I'm thinking of is a little harder, either by messing up the NAND state machine in the MCU (so it doesn't notice we're about to write), or, if they've been really careful, by toggling the bits through GPIO and carefully timed memory accesses. Something your virus author may still do, of course. And that's when the second chip kicks in. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
On Wed, 2007-05-16 at 19:55 -0300, Werner Almesberger wrote: You'll (almost certainly) be able to do this as well: the new MCU will allow you to specify which NAND Flash area can be written to. Once this is set, it cannot be changed without a reset. So this would be a hardware assisted solution. Unfortunately, you can probably bypass it if you're determined. Could you tell me the make and model of the new MPU, and maybe some links to datasheets. I did look in the WIKI and in previous messages but couldn't find these details. I am intrigued to see how they implement the protection. Thanks Simon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Few comments after reading Wiki
Hello, First of all, I will introduce myself. I was creating such projects like Gammu and Gammu+ mainly for synchronizing informations from Nokia phones (non Symbian) with PC using Nokia prioprietary protocols, but also for some AT and Alcatel devices (including manufacturer commands and protocols). Currently I'm searching for new interesting task for me (for fun, but also as full time job, because I'm ending studies). I don't have 350 USD and I won't probably have OpenMoko connected hardware phone (now). My comments after reading Wiki: 1. I hope, that there will be made SAR tests and results will be very low 2. it could be good to have such phone with GSM/UMTS switching (even without all data standards like EDGE, ) 3. you can use quite easy Gammu/Gammu+ sources (or at least source from similiar Gnokii) for making import tool from Nokia/other phones. Additionaly in Gammu/Gammu+ you have some interesting snippets for decoding MMS files and many other. Maybe it will be usefull. 4. I quess, many people are really waiting for phone with GSM/hardware monitoring functions (something like in Nokia netmonitor functionality). If you will make some tool for displaying this data in one place, you will receive millions of hungry people waiting for it... 5. hav developers though about creating it on kind of x86 compatible platform ? I know, it could be more difficult to create energy efficient device, but having PC in pocket (with ability to running dos, windows after changing SD card) would be more than excellent Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
Hello, One additional hadrware suggestion: 6.microswitch for real hardware blocking flashing (to prevent changing firmware) Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Marcin Wiacek wrote: 6.microswitch for real hardware blocking flashing (to prevent changing firmware) Flash protection is planned for the later this year aka getting everything right this time model. The idea is to have an emergency/recovery u-boot in a separate Flash chip, which can be activated if the regular boot process got broken. This recovery Flash should never need to be changed, so making it easy to do so isn't a particularly high priority. (As in soldering iron instead of switch.) Our current hardware doesn't allow Flash protection to be done sensibly :-( So software/user input can in fact brick a machine to the point where the only recovery possible is through JTAG, e.g., with the debug board. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Werner Almesberger wrote: Our current hardware doesn't allow Flash protection to be done sensibly :-( So software/user input can in fact brick a machine to the point where the only recovery possible is through JTAG, e.g., with the debug board. I'm not saying this isn't a nice feature. Why should a phone be better in this respect than a PC? If you want to, you can brick a PC, if you've got root, to the state where it will need the flash removed and re-flashed. Surely this is a toolchain, and OS thing, rather than hardware? Permissions are set so that users can't touch the flash in question. Maybe even a patch to the driver for the flash to completely block write access to blocks specified on the bootloader command line. For September end users, you might want to go further - you can't change the bootloader params (to disable the flash blocking), or install non-signed bootloaders or kernels if you don't input a code (displayed on the bootloader) to some website, which then logs the fact that you've done it, and supplies you a key to use it at your own risk. If you've not downloaded this key, FIC fixes bricked phones free, if not, then they don't. Of course, those skilled in the art of patching the running kernel can get round this, but there should be no great reason not to use the stock bootloader and blessed kernels. (Several people unconnected to FIC are also given codes that they can assemble to a working private key for FIC to enable them to unlock phones in the event of the FIC website going away) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Ian Stirling wrote: Why should a phone be better in this respect than a PC? Well, on the PC, you don't change the BIOS very often, if ever. Furthermore, the BIOS is in storage that your system doesn't usually access either. On the Neo, your BIOS is the boot loader, so every time you upgrade the boot loader, you get a chance to brick your system. Furthermore, basically all non-removable storage is just one single Flash area, so the driver writing your data files is just a few bits away from bricking the device. There are some protections, but software is very limited in what it can do. Also, neither the MCU nor the Flash memory have any complementary protection mechanisms. (In the next device, also the MCU will have some reasonably good protection against the most common forms of accidental overwriting.) And no, I don't think we want to get into DRM ;-) - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Few comments after reading Wiki
Hello, First of all, I will introduce myself. I was creating such projects like Gammu and Gammu+ mainly for synchronizing informations from Nokia phones (non Symbian) with PC using Nokia prioprietary protocols, but also for some AT and Alcatel devices (including manufacturer commands and protocols). Currently I'm searching for new interesting task for me (for fun, but also as full time job, because I'm ending studies). I don't have 350 USD and I won't probably have OpenMoko connected hardware phone (now). My comments after reading Wiki: 1. I hope, that there will be made SAR tests and results will be very low 2. it could be good to have such phone with GSM/UMTS switching (even without all data standards like EDGE, ) 3. you can use quite easy Gammu/Gammu+ sources (or at least source from similiar Gnokii) for making import tool from Nokia/other phones. Additionaly in Gammu/Gammu+ you have some interesting snippets for decoding MMS files and many other. Maybe it will be usefull. 4. I quess, many people are really waiting for phone with GSM/hardware monitoring functions (something like in Nokia netmonitor functionality). If you will make some tool for displaying this data in one place, you will receive millions of hungry people waiting for it... 5. hav developers though about creating it on kind of x86 compatible platform ? I know, it could be more difficult to create energy efficient device, but having PC in pocket (with ability to running dos, windows after changing SD card) would be more than excellent Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Werner Almesberger wrote: Ian Stirling wrote: Why should a phone be better in this respect than a PC? Well, on the PC, you don't change the BIOS very often, if ever. Furthermore, the BIOS is in storage that your system doesn't usually access either. True, of course, though root can still brick it. On the Neo, your BIOS is the boot loader, so every time you upgrade the boot loader, you get a chance to brick your system. Furthermore, basically all non-removable storage is just one single Flash area, so the driver writing your data files is just a few bits away from bricking the device. Sure, kernel bugs can kill your system. There are some protections, but software is very limited in what it can do. Also, neither the MCU nor the Flash memory have any complementary protection mechanisms. (In the next device, also the MCU will have some reasonably good protection against the most common forms of accidental overwriting.) And no, I don't think we want to get into DRM ;-) I really think you do. I want to be able to give this phone to my (hypothetical) employees. I do not want skilled lazy, employees able to - for example - edit their GPS logs which corroberate the inspections they are required to do. This is _not_ DRM that stops the owner of the phone doing stuff. It's DRM that stops users of the phone that may or may not be authorised users from doing stuff. Think of it as a BIOS password on steroids. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
Why should a phone be better in this respect than a PC? [...] There are some protections, but software is very limited in what it can do. Also, neither the MCU nor the Flash memory have any complementary protection mechanisms. (In the next device, also the MCU will have some reasonably good protection against the most common forms of accidental overwriting.) And no, I don't think we want to get into DRM ;-) My 2 cents: I was thinking, that protection should make, that software run on device/connected to it PC can't make it brick. Nothing about DRM. In worst case device should start with default parameters and without additional apps. But definitely shouldn't be dead. Second chip isn't good idea. IMHO, the best is separating memory to two phisical chips and have main software in first (with protection) and additional software/HDD inside second (or protection should block writing to chip below specified address). Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Ian Stirling wrote: Werner Almesberger wrote: And no, I don't think we want to get into DRM ;-) I really think you do. No, you don't. OPEN-Moko. You start throwing any sort of DRM in these things and you will lose much of the community support that the moko needs. I want to be able to give this phone to my (hypothetical) employees. I do not want skilled lazy, employees able to - for example - edit their GPS logs which corroberate the inspections they are required to do. If they are skilled, then they are going to be able to circumvent any kind of protection measures you put in place. Tip: get better hypothetical employees. This is _not_ DRM that stops the owner of the phone doing stuff. Any DRM hampers the owner from doing want they want. No DRM can stop the owner, there is always a way around it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Ian Stirling wrote: This is _not_ DRM that stops the owner of the phone doing stuff. It's DRM that stops users of the phone that may or may not be authorised users from doing stuff. Think of it as a BIOS password on steroids. DRM never worked, and never will. it's a fact of life, get over it. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Users and services is NOT drm, was Re: Few comments after reading Wiki
On Wednesday 16 May 2007 18:46:03 Ian Stirling wrote: I really think you do. I want to be able to give this phone to my (hypothetical) employees. I do not want skilled lazy, employees able to - for example - edit their GPS logs which corroberate the inspections they are required to do. This is _not_ DRM that stops the owner of the phone doing stuff. It's DRM that stops users of the phone that may or may not be authorised users from doing stuff. I think we have a terminology issue here. How is this thig you call DRM (which it isn't really, since it is not dealing with copyright or authoring issues) different from a properly prepared unix environment, chroot/chmod/chown and all ? To put it another way - you say you want to give this to people but want to make sure they are unable to tinker with the data - how is this different from a browser using a web server ? You can define users, pages, rights, and keep the GPS logging on the server side, which enters the points/locations automatically with the report. If your employee can't connect to the DB or write as www-data, you are reasonably safe. If you are really paranoid, I guess you could employ a crypted filesystem (which you mount using an agent so the password is not stored in the device) to make sure it doesn't get edited on another machine, but all of this is really outside the scope of DRM, which is lawyer stuff - DRM doesn't prevent anyone from doing anything - it just gives you a legal base to punish someone who does break it. DRM enforcement software is OTOH an (arguably) futile attempt to make it harder to do something you are not supposed to do (some will argue that it makes it hard to do things you ARE supposed to do). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Marcin Wiacek wrote: In worst case device should start with default parameters and without additional apps. Our idea is that you can at least load a new boot loader, kernel, etc. over DFU. That's the minimum sane unbricking requirement. Anything else would require more space. (We may actually have enough space for also putting the kernel and a bit of user space there. But that wouldn't be a regular environment, but more something like kboot or linuxbios.) Note that there's also the option to do an emergency boot from the boot menu. This is for more benign screw-ups, e.g., incorrect touch screen calibration making the GUI unusable. For the end user, this level of protection, combined with a bit of DFU hardening will be enough. IMHO, the best is separating memory to two phisical chips and have main software in first (with protection) and additional software/HDD inside second (or protection should block writing to chip below specified address). Per-block protection is tricky. There are only very few companies out there who have chips with this, and even fewer whose chips we could actually use. I don't know of any Flash chip with useful zone protection (you get a lot that protect about 16 kB, but that's not enough). Just protecting the whole chip won't do, since we expect our users (hackers) to install their own boot loaders, kernels, and such. With the MCU we'll use in the future, you also get (useful) zone protection. We think it can be circumvented (by malware but also by well-meant tools), so it's not the 100% carefree solution we're looking for either. However, it will allow for more flexible use of the recovery Flash chip for those who choose to remove the bulletproof protection. (E.g., if they have a debug board.) - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
Per-block protection is tricky. There are only very few companies out there who have chips with this, and even fewer whose chips we could actually use. I don't know of any Flash chip with useful zone protection (you get a lot that protect about 16 kB, but that's not enough). Just protecting the OK whole chip won't do, since we expect our users (hackers) to install their own boot loaders, kernels, and such. No, no, no. You install microswitch available under battery (available for end user). When Off, you can not save anything to chip number 1 (you disconnect phisycally lines required for changing chip content). When on, you can save to chip number 1. All stuff like user disk, etc. Etc. goes into chip number 2 (you can always change it). Simple. Can be done something like that (I'm not hardware guy) ? Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Marcin Wiacek wrote: Can be done something like that (I'm not hardware guy) ? Sure, that's basically what we have in mind, except that there may not even be a microswitch (although I'd like to have at least a jumper), but just a resistor you'd have to unsolder to do this. The issue is that our users (= hackers) can also replace critical system components with their own code. So we don't only have to protect against unwanted changes, but also again users fully intending the change, say, the boot loader. Now, if there's a bug in the new boot loader that breaks it, they will have a means to restore something that works. This is a bit different from the regular consumer device, where people will at most install some nice, well-tested vendor updates. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
Can be done something like that (I'm not hardware guy) ? Sure, that's basically what we have in mind, except that there may not even be a microswitch (although I'd like to have at least a jumper), but just a resistor you'd have to unsolder to do this. Resistor - wrong. It must be available for user without technical knowledge and tools. That's all, what I wanted to say. If I will found money for device, maybe play with it in the future and for example port Gammu+ ;-) Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Users and services is NOT drm, was Re: Few comments after reading Wiki
Attila Csipa wrote: On Wednesday 16 May 2007 18:46:03 Ian Stirling wrote: I really think you do. I want to be able to give this phone to my (hypothetical) employees. I do not want skilled lazy, employees able to - for example - edit their GPS logs which corroberate the inspections they are required to do. This is _not_ DRM that stops the owner of the phone doing stuff. It's DRM that stops users of the phone that may or may not be authorised users from doing stuff. Yes, I should have commented on that. DRM is entirely the wrong phrase. I think we have a terminology issue here. How is this thig you call DRM (which it isn't really, since it is not dealing with copyright or authoring issues) different from a properly prepared unix environment, chroot/chmod/chown and all ? That's basically all I was aiming at. Make it as secure as a PC with physical access can be, from the user - _NOT_ the owner. If they are the same, then they have to do a couple of minute process once in order to get the key to install custom kernels or bootloaders forever. If FIC completely goes away, or decides to be evil, then the people given the private key distribute it, so that anyone can do it. (If FIC are unconcerned about the warranty returns aspect, then simply putting the key in the box along with the neo would work.) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Marcin Wiacek wrote: Resistor - wrong. It must be available for user without technical knowledge and tools. No, this memory is the one only users who know exactly what they're doing and have the right tools should ever change. And even those normally shouldn't even want to. The things there are strictly for disaster recovery. They're the last defense against bricking the device. (If you remove this defense, then unbricking requires JTAG, so you either need a debug board, find someone who has it, or send it back to FIC.) In normal use, this Flash is not accessed. You can still change kernels, boot loader, and all that, with maximum ease. (They're all in the regular Flash.) - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Raphaël Jacquot wrote: Ian Stirling wrote: This is _not_ DRM that stops the owner of the phone doing stuff. It's DRM that stops users of the phone that may or may not be authorised users from doing stuff. Think of it as a BIOS password on steroids. DRM never worked, and never will. it's a fact of life, get over it. It's not DRM. It's a BIOS password, which doesn't let you flash it without the password. Without it, any employee/pervert that wants to drop a logger on your childs phone can do whatever they want to any Neo phone with a minute or so alone with it. The key can as easily be supplied in a tamper-proof card with the phone, that has to be returned unopened to obtain an unbricking, otherwise you pay a small fee. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
There are many ways to make it 99.999% secure. Who cares if you can't technically secure it 100%. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raphaël Jacquot Sent: Wednesday, May 16, 2007 4:23 PM To: Ian Stirling Cc: community@lists.openmoko.org Subject: Re: Few comments after reading Wiki there's no such thing as a secure system. You can have a somewhat secure thing, that will be able to resist to X but the 100% secure thing doesn't exist. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Ian Stirling wrote: Raphaël Jacquot wrote: DRM never worked, and never will. it's a fact of life, get over it. It's not DRM. It's a BIOS password, which doesn't let you flash it without the password. Without it, any employee/pervert that wants to drop a logger on your childs phone can do whatever they want to any Neo phone with a minute or so alone with it. The key can as easily be supplied in a tamper-proof card with the phone, that has to be returned unopened to obtain an unbricking, otherwise you pay a small fee. there's no such thing as a secure system. You can have a somewhat secure thing, that will be able to resist to X but the 100% secure thing doesn't exist. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Few comments after reading Wiki
[] In normal use, this Flash is not accessed. You can still change kernels, boot loader, and all that, with maximum ease. (They're all in the regular Flash.) Of I see that we think about different things I was thinking about protecting memory with main phone software (like kernel, boot loader, main apps). In other words: if you want, after downloading and installing apps you can protect your device and nobody (wrong sms, .) can damage it. You can normally use device (memory with sms and similiar things can be changed). You were thinking about protecting lower level. Pozdrowienia/Best Regards -- Marcin Wiacek (www.gammu.org, www.mwiacek.com, I'm looking for a job) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
On 5/16/07, Ian Stirling [EMAIL PROTECTED] wrote: Raphaël Jacquot wrote: Ian Stirling wrote: This is _not_ DRM that stops the owner of the phone doing stuff. It's DRM that stops users of the phone that may or may not be authorised users from doing stuff. Think of it as a BIOS password on steroids. DRM never worked, and never will. it's a fact of life, get over it. It's not DRM. It's a BIOS password, which doesn't let you flash it without the password. Without it, any employee/pervert that wants to drop a logger on your childs phone can do whatever they want to any Neo phone with a minute or so alone with it. Suddenly it's about the children and not about spying on your employees? How convenient... Anyone given a few minutes alone with your phone could do whatever they wanted to it. The number one rule of computer security: prevent physical access. With physical access, you can accomplish pretty much anything! -Steven ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
On 5/16/07, Marcin Wiacek [EMAIL PROTECTED] wrote: 1. I hope, that there will be made SAR tests and results will be very low Why? It may help with marketing, but the worst it could do (unless it's several orders of magnitude beyond what current phones) is make you a bit warm. Non-ionizing radiation is not a cause of cancer. Better to worry about things that there is actually evidence to back up - like radon, or using the phone while driving :-) Cheers, Ben ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
5. hav developers though about creating it on kind of x86 compatible platform ? I know, it could be more difficult to create energy efficient device, but having PC in pocket (with ability to running dos, windows after changing SD card) would be more than excellent yes, i have. i don't know about any others though i'm waiting for via to release the pico-itx board they've been promising and will see what i can do with that to create a UMPC/phone/pda type combo. this board/cpu promises ultra-low power and hw accelerated video playback, looks very interesting and would be awesomely flexible/powerful as you say, the main issue is power - x86 isn't really optimized for anything as it's such a generalised architecture. my calcs at the moment on power are struggling to get more than a few hours use with a reasonable size battery ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Few comments after reading Wiki
Marcin Wiacek wrote: Of I see that we think about different things Yup :-) I was thinking about protecting memory with main phone software (like kernel, boot loader, main apps). You'll (almost certainly) be able to do this as well: the new MCU will allow you to specify which NAND Flash area can be written to. Once this is set, it cannot be changed without a reset. So this would be a hardware assisted solution. Unfortunately, you can probably bypass it if you're determined. - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
