Software Restore

[Christoph.Krn]

Umm, I don't think people who steal electronics carefully consider what particular device something is before they take it.
It's got a screen and buttons, so they can sell it to a fence for a few bob. What else do they need to know?

• Additionally, people who would buy a stolen Pandora would only do so if they knew what it is and how to use it.

You're right, but even if the thief's customer is so stupid, do you think he will just throw it away if it doesn't work? Don't you think he would rather give it to / ask someone who may know what to do with it first?

Keep in mind: it's not TOO difficult to recover a password-protected, encrypted or otherwise software-secured Pandora to a usable, "as new" state, it pretty much resembles stealing a password-protected netbook. (Except that it's ARM and you can't just pop in a Windows DVD, but other than that, it's pretty much a standard procedure for anyone vaguely interested in IT)

Either that, or it's a conspiracy to get all the Pandoras and re-sell them as "Second batch^H^H^H^H^Hhand". h34r:


English is not my native language, and I have to apologize for any "smart ass" tone. It's not my intention to sound that way but I seem to tend to sound like this in English, sorry.

 

[Gary13579]

the operating system is Linux , so you need a password by default, if you want more security then use an encrypted file system on top, although, to be honest, most IT people I speak to think any PC that has physical access can be owned to some extent, though if you use an encrypted file system they might need a few centuries to hack it.

This is simply not true. Look into cold boot attacks.

Take a notebook that is powered on but files are encrypted. Insert USB drive containing hacked linux distro, reboot. The Linux distro will dump the RAM to the USB drive, and then you have weeks to sit there and dig through it to find encryption keys used for filesystem encryption. If you take the RAM out (not possible on the Pandora), super cool it, then you have hours to let the RAM sit before you dump it.

However, on the Pandora, it's much safer. RAM can't be removed without amazing desoldering skills, and you can't boot from USB devices. It'd be pretty hard to break a good encryption for the Pandora. If someone was truly malicious and knew what they were doing, they could just leave the Pandora powered on so the key sits in RAM until they get the time to compile their custom linux kernel for ARM and copy it to an SD card... but most won't bother with that, and would just ebay it.

A BIOS password is not really increasing security, it's very easy to find a suitable password. Also, it's indeed true that as soon as an attacker gains physical access to your machine, he basically won. To take the BIOS password as an example, with physical access to a machine it would be pretty easy for an attacker to just open up the machine (if it's not physically locked, but that wouldn't really be physical access then) and reset the BIOS so the password is gone.

Although this is true for most desktops and notebooks, it's not ALWAYS the case. ThinkPads actually store their BIOS passwords on a dedicated NAND chip. The *only* way to get past the password is to desolder the chip, build a serial device to dump the data, then get the password. It's quite nice, and one of the few reasons I buy ThinkPads.

 

[Gary13579]

Ontopic, I'd like to lock my Pandora also. Is there user management in the current Ångström images? I'm sure it couldn't be hard to add, it's Linux after all. (And of course I mean without changing the code for a recompile).

Linux always has 'user management'. If you mean on bootup, you get greeted with a nice message asking you to select account... then it varies. If you're running E17, GNOME, KDE... then it's installed by default. However, Xfce does not come with one. When you boot up your Pandora (assuming they don't pre-install something), you get a terminal window which asks you for your username/password. You enter that, then type "startxfce4" and it loads up X and Xfce.

Either XDM, or preferably SLiM (since XDM looks like shit) will be preinstalled. http://en.wikipedia.org/wiki/SLiM

 

[Christoph.Krn]

ThinkPads actually store their BIOS passwords on a dedicated NAND chip. The *only* way to get past the password is to desolder the chip, build a serial device to dump the data, then get the password. It's quite nice, and one of the few reasons I buy ThinkPads.

Interesting, never heard of that before.

Poor Thinkpads, I wish they still were what they used to be, I'd buy one of the new ones immediately.

 

[Kramy]

Kruft in the linux filesystem from uninstalled programs really doesn't affect performance that badly -- certainly not like registry creep on a Windows box; I've never had to reinstall a linux system simply because it got bogged down. That said, I will probably make a backup of the firmware just in case something else goes wrong and I'm unable to boot from NAND.

This is correct, and yet not for the reason expected.

Most uninstalled programs leave stuff in the registry. This is bad, but doesn't affect performance on Windows. (Okay, it does, but 16MB vs 32MB is something like a 2% performance drop)

What hits performance the worst is programs that don't uninstall everything. And this, unfortunately, is tons.

IMO all app config stuff should be redirected to the SD card. I read that /pandora/apps will be the .pnd dir, so maybe /pandora/config should be the app specific config stuff? That way when you "uninstall" an app, you can easily clear it from the config folder right next to it. Someone might even whip up an app that gives you the option of deleting both.

 

[Kramy]

ThinkPads actually store their BIOS passwords on a dedicated NAND chip. The *only* way to get past the password is to desolder the chip, build a serial device to dump the data, then get the password. It's quite nice, and one of the few reasons I buy ThinkPads.

Interesting, never heard of that before.

Poor Thinkpads, I wish they still were what they used to be, I'd buy one of the new ones immediately.

Atmel AVR CPUs can take it one step further. Some have irretrievable regions, where you can dump passwords and executable code. You need an electron microscope to breaking into those.

You could try to brute-force the password(which is laughable - the secure region would notice the attempt and lock itself down for a while), or you could try de-soldering the chip and replacing it with an identical chip. If you do that, you have the issue that nothing that talks to the chip will receive the expected output, and will itself lock down.

So how do you beat it? Best bet seems to be keyloggers.

 

[Yoyobuae]

So how do you beat it? Best bet seems to be keyloggers.

Or social engineering.

 

[Gary13579]

ThinkPads actually store their BIOS passwords on a dedicated NAND chip. The *only* way to get past the password is to desolder the chip, build a serial device to dump the data, then get the password. It's quite nice, and one of the few reasons I buy ThinkPads.

Interesting, never heard of that before.

Poor Thinkpads, I wish they still were what they used to be, I'd buy one of the new ones immediately.

I agree! Back when I used my first ThinkPad, the NAND chip was basically undefeated. No one had built the device to dump it. The only way to get around the BIOS password, even in the case where you legitimately lost your password, was to send it into IBM where they would literally replace the entire motherboard, and charge you several hundred for it.

As for quality, I will admit that it has dropped. After handling both an IBM x31 and a Lenovo x300, you can easily tell the x31 is superior. But the x300 is still *gorgeous* and would be my absolutely top pick for a notebook.

ThinkPads actually store their BIOS passwords on a dedicated NAND chip. The *only* way to get past the password is to desolder the chip, build a serial device to dump the data, then get the password. It's quite nice, and one of the few reasons I buy ThinkPads.

Interesting, never heard of that before.

Poor Thinkpads, I wish they still were what they used to be, I'd buy one of the new ones immediately.

Atmel AVR CPUs can take it one step further. Some have irretrievable regions, where you can dump passwords and executable code. You need an electron microscope to breaking into those.

You could try to brute-force the password(which is laughable - the secure region would notice the attempt and lock itself down for a while), or you could try de-soldering the chip and replacing it with an identical chip. If you do that, you have the issue that nothing that talks to the chip will receive the expected output, and will itself lock down.

So how do you beat it? Best bet seems to be keyloggers.

How exactly would you keylog this? I assume it would exist in a level below ring0, which would be in the BIOS, so there would be no way to keylog the password (other than hardware keyloggers). Unless you're assuming the person uses the same password for everything.

Where exactly is the data stored? Is it literally in the CPU, or on a NAND chip like the TPs? If it is literally in the CPU, what stops someone from building a corrupt BIOS whose goal is to dump the password? Maybe I'm just not understanding the technology...

 

[Kramy]

You Keylog between the keyboard and the motherboard.


I'm not 100% certain, but if I recall correctly, AVR security works like this:

The secure regions act as fully functioning core inside the chip, with a limited amount of flash storage also inside the chip. The difference is, it has no IO access - it talks to the regular core/program. (most MCUs only have a single task/program running)

The regular core can talk to the secure core through methods at fixed points. Once the secure region is burned, it cannot be overwritten, although it obviously has its own SRAM for doing things. So long as you avoid creating a method that returns anything in secure memory, there's no way to get at that data. All you have access to is whatever the methods at fixed points return.

So you could safely run an encryption or authentication method and only someone with an electron microscope could snoop it. The regular core handles communications out of the chip. It's up to other chips to react if they get the wrong response.

How this differs from NAND is, you can't "dump" it. Best case scenario, you could record the signals going to/from the chip and repeat them, or keylog the password. However, if the signals have a time component, then even this would fail. Hardware keylogging seems like the best option.


Note: I'm not actually in the field of computer security. I was just reading up on keyloggers and shit a few years back, and kept investigating. Atmel had the most impressive writeup on their countermeasures.

 

[Christoph.Krn]

How exactly would you keylog this? I assume it would exist in a level below ring0, which would be in the BIOS, so there would be no way to keylog the password (other than hardware keyloggers). Unless you're assuming the person uses the same password for everything.

Where exactly is the data stored? Is it literally in the CPU, or on a NAND chip like the TPs? If it is literally in the CPU, what stops someone from building a corrupt BIOS whose goal is to dump the password? Maybe I'm just not understanding the technology...

I think he meant another usage case. This is more like a TPM than the TP's NAND (assuming the use of the latter is limited to storing the BIOS passwords).

 

[Aninhumer]

You're right, but even if the thief's customer is so stupid, do you think he will just throw it away if it doesn't work? Don't you think he would rather give it to / ask someone who may know what to do with it first?

Keep in mind: it's not TOO difficult to recover a password-protected, encrypted or otherwise software-secured Pandora to a usable, "as new" state, it pretty much resembles stealing a password-protected netbook. (Except that it's ARM and you can't just pop in a Windows DVD, but other than that, it's pretty much a standard procedure for anyone vaguely interested in IT)

I wasn't saying passwords were necessary.
It's just that you seemed to be arguing that the Pandora being a niche product made it less likely to get stolen, which I don't think is true at all.

I agree, password protection is pretty useless (except for protecting files).
Regardless of whether it's easy to bypass, the thief would only find out it had a password after they'd already stolen it.

What happens after it gets stolen is mostly irrelevant to the person who doesn't have it any more.

 

[lulzfish]

So there was a huge flamewar and someone said:

"Because the Pandora can't boot from USB"

But last I heard it can. Edit: Wait, I can't remember. Maybe not. What was the conclusion on that?
The rest of the flamewar was silly speculation about whether or not people would steal a Pandora. The answer is yes. People would steal a pencil . Electronics are all worth at least $5.

 

[Pleng]

I seem to remember somebody saying that it *can* boot from usb but you need to have some kind of serial device attached to it to enable it to do so.

 

[urjaman]

I seem to remember somebody saying that it *can* boot from usb but you need to have some kind of serial device attached to it to enable it to do so.

The OMAP3530 can boot "from usb" but as a booting device attached to a PC over the OTG port.

See http://focus.ti.com/lit/ug/spruf98d/spruf98d.pdf 25.4.5.3 USB:

The ROM code supports booting from a USB interface with the following characteristics:
• HS USB interface
• USB 2.0 transceiver macrocell interface (UTMI)+ low pin interface (ULPI) 8-bit data transceiver support
(single data rate)
• TPS65950 device detection and automatic configuration of its USB transceiver using I2C1
• The enumeration time-out is 3 seconds.
The ROM code USB driver conforms with the USB 2.0 specification and the USB on-the-go (OTG)
supplement. It supports transactions at HS (that is, 480 Mbps) and FS (that is, 12 Mbps). During
peripheral booting, only the USB device functionality is used. The driver resides in the on-chip memory
(OCM) ROM, which is small. The driver therefore contains the minimum functionality needed as a USB
device and is not a full-fledged driver. It does not contain the functionality needed for a USB host. The
device functionality of the USB OTG controller is used for the peripheral booting process in the ROM
code.