iSuppli's business model revolves around finding you low prices for components (for a nice, hefty fee, of course) for your next big consumer electronics product; these teardowns are just advertising for that service. In order to pull customers in, they mark down the lowest plausible price for each component; it's unlikely that even Apple can get these low prices for each component.
Practially every teardown they show is low-balled, because there's no way to verify any of these numbers, and lower numbers gets them more contracting business.
This is well-written, but mostly incorrect, based on some bad assumptions about sandboxing and encryption.
The main differences are as follows: the iOS sandbox is somewhat weaker than the Android sandbox. It restricts fewer things and in the past (not sure if it was fixed these days), key first-party apps such as the web browser were not sandboxed at all, which is how several generations of jailbreak worked.
No, the iOS sandbox is stronger, in that it supports more fine-grained control over access to individual syscalls (based on the BSD-heritage Mandatory Access Control framework), as well as the API-level and filesystem permission-level isolation that Android relies upon. Jailbreaks didn't rely on a lack of sandboxing, for the most part -- they exploited kernel bugs in e.g. the graphics driver. It took until 2011 that "rooting" on Android even approached the complexity of the 2008 iPhone exploits; the neccesary exploits on Android were generally much simpler.
Android was designed from the ground up with the mentality that there should ideally not be an "us vs them" divide - Android treats all apps more or less the same, security-wise, meaning that the browser is just a regular app that runs in a permission-controlled sandbox like any other. This open design is one reason why the permissions UI on Android is more complex than for iOS - apps can do more things and the OS has to communicate that to you.
This is only partially true. Android most certainly does distinguish between "system apps" and 3rd-party apps -- why do you think people have to root their phones to remove crapware?
The main reason that Android's permissions UI is more complex is... a design issue. The Android team decided that it was better to make all users click through a screen showing a bunch of scary shit, so that they could later blame the user if the app does something strange. "Dialog fatigue" ensures that very few people actually read the whole UI, and the fact that you can't (on a stock system) individually deny any access (while still using the app) means that most people just suck it up and run the app and take their chances.
Most of the rest of what you wrote is wrong, because you base it on the statement that Android's sandbox is stronger.
With regards to other features, like drive encryption, as of the latest releases I believe both operating systems are largely comparable.
Okay, now go back and actually read the Apple paper, starting with page 8. iOS's encryption is fine-grained -- the whole partition is encrypted, and then individual files are further encrypted, depending on the application and use (e.g. you can receive new email and take new photos while the phone is locked; that stuff is then encrypted and written to flash, and cannot be accessed until you unlock the phone with a PIN. Older contents cannot be decrypted until you unlock the phone). Android only got encryption with 3.x and 4.x -- about 2 years after it appeared on iOS -- and it's a shitty implementation (requires a full battery, AC power, and > 1 hour to enable or disable; any interruption will cause data loss; must enter PIN code on boot, which then causes the whole flash to be decrypted in memory until you turn the phone off).
I think that the issue here is that Apple is required to "only allow one download per purchase, under normal circumstances" (or something to that effect). Emailing them and asking for them to make an exception and let you redownload the music may be within the terms of their license, but "automatic" redownloading apparently isn't.
How did Sony fuck that one up?
It was my(admittedly layman's) understanding that a public/private key crypto implementation, assuming it isn't deeply flawed, using key lengths suited to the computational capacities of PDP-8s, or otherwise totally fucked, was mathematically secure against anything other than a profound breakthrough in prime factorization algorithms, an unbelievable advance in computational power, or an insider leaking your private key.
Close. These algorithms only work correctly if implemented correctly. There are various known pitfalls with each of these algorithms; for example, the original iPhone was unlocked using an RSA implementation error (Bleichenbacher attack against an RSA implementation that does not correctly validate padding and uses exponent 3). ECDSA happens to have a "pitfall" that leaks information inside the signatures it makes.
This doesn't make it a bad algorithm -- it can achieve the same security of RSA using smaller keys and in less time -- but the "pitfall" here is particularly bad.
They don't have Sony's signing key, from what I've read. What they have is a flaw in the key generation process, which allows them to generate valid signed packages without the private key. In fact, here's the video from the conference itself:
http://www.youtube.com/watch?v=GPjd6gHY6A4
No, GP was right. The exact signing key used by Sony may be derived from the public components of their ECDSA signatures. Not something close; not something equivalent.
Having worked with several commercial USB protocol analyzers over the years I have yet to see one was anything more than an FPGA connected to an off the shelf USB PHY chip. As much as I like cute dog videos these guys need to post proper requirements and design specifications if they seriously want funding from me.
Click through the links to the actual Kickstarter project description. We did some handwaving to keep it accessible for J. Random (Software) Hacker, but I think we gave enough details to answer your questions.
(tl;dr: yes, you're right, and that's more or less what we're doing. Haven't decided on which PHY to use, looking at some SMSC and NXP parts.)
OpenVizsla will be a completely open design of a device that can capture USB 1.1/2.0 (high-speed, full-speed and low-speed) traffic passively between a target USB device and the connected host (usually a PC, but potentially anything that has a USB host port -- think Xbox 360 and PS3). It will be controlled by any computer using open-source client software or potentially in standalone mode (where captured traffic is stored onto an on-board SD card).
As is proper for any open and hackable design, unused I/Os on the FPGA will be exposed (via 0.1" header) for use as a primitive logic analyzer. We hope to eventually support additional sniffing interfaces (SPI, I2C RS232, SD card etc) that connect to a high-speed Mictor connector that can act as 'man-in-the-middle' and extend the device capability limitlessly.
The OpenVizsla device is built around a multi-layer PCB with around 180 surface-mount components that allow the target USB packets to be captured, buffered and delivered to the PC (or stored on SD card in standalone mode).
An XMOS event-driven processor will handle the huge amount of USB data (these little chips are fast!) and it will handle the overall communications with the host (which will be a fully published protocol!) and will provide on-board system programming, housekeeping and of course flash the status LEDs! In standalone mode, the XMOS chip will handle data acquisition and SD card storage; this processor is fully reconfigurable and can be modified and reprogrammed to improve the features or adapt to new requirements.
For the high-speed USB signals a Xilinx Spartan3E FPGA (with attached, expandable RAM) will capture, process and buffer the USB traffic from an attached USB transceiver that we use to deserialize the USB signals from the target link.
Yup, similarly to the DS homebrew scene. IIRC the libdns homebrew library had parts which were ripped of the original nintendo SDK... of course people just turned a blind eye on that
It's a subject of some debate. The Xbox homebrew scene, as I understand it, used files directly copied from a leaked Xbox SDK. libnds uses some code that is more or less directly translated from disassembled DS SDK code (though you can get most of the same code from dumped games anyway); some feel that this is morally / legally equivalent to just copying the files.
I fail to see your logic, there is no independent group in charge of banning people from the PSN. If Sony decides to ban you, there is absolutely nothing you can do about it, regardless of the reason they ban you.
Sure -- if Sony decides to ban you, you've already messed up. Sony can't "decide to ban you" if they can't tell you've done anything naughty, so it's better to avoid permanent changes to the console that can be detected by their software.
Care to explain what PCB traces are shared between D+/D- on the USB and the RAM? And what this has to do with your TomTom?
You're also confusing the service mode jig used in Sony repair centers on retail consoles with debug consoles used for development. The two are unrelated.
It's also worth pointing out that Rigol apparently makes some of Agilent's low-end scopes for them, so the fact that they aren't a household name doesn't mean all that much.
The Rigol scope has a lot of nice features that you wouldn't expect to find on a cheap scope -- it can take screenshots and store them to a USB thumb drive or print them to a USB printer, you can connect it to your computer to control it or acquire data via USB or RS-232, etc. It actually oversamples at 1 Gigasample/second -- there have been a number of EEVblog shows about it, talking about its performance, the parts that go into it (and the corners they did cut to get the price down!), etc. Google "eevblog rigol" to find the rest of them.
As for adding new functionality, Nintendo has been adding new functionality to the Wii from time to time as well (dare I say more than Sony has done with PS3). This update is the first anti-piracy-only Wii update that doesn't add new functionality (or fix other problems).
They really haven't. Let's consider the timeline of updates to the Wii software since the first exploit was demonstrated. Note that there's no technical need to update the System Menu, any version of IOS (the invisible "firmware" that implements all of the interesting security features of the system), or any channel at the same time. IOS fixes can never add functionality by themselves, they can only work around some bugs in disc-based games. Any update that claims "behind the scenes updates" or "system improvements" refers to IOS updates, most of which are to patch exploits and very few of which actually impact performance, despite their claims.
v3.4 November 17, 2008 -- Fixed anti-Twilight Hack code. Updated Parental Controls, and added USB keyboard to the Mii Channel (?). Strange attempt to block the default slot number used by a code example I released.
v4.0 March 25, 2009 -- Considerable update to the System Menu to add support for running channels that are stored on SD card.
v4.1 July 2009 -- Fixes an obscure System Menu bug. Added code to better block copy-protected saves.
v4.2 September 28, 2009 -- First attempt at blocking Bannerbomb.Also added code to delete the Homebrew Channel and DVDX. Added code to check to see if a console had its region altered, in some cases forcing a brick (!). Improved region-checking code for games. Forced a bootloader update (boot2v4) that didn't actually fix any bugs or exploits -- it just overwrote your bootloader "just in case" you had modified it, and caused a fair bit of collateral damage which Nintendo tried to blame on "hacking", even on virgin consoles. (There's a reason they tell you not to reflash your BIOS if you don't really need to...)
v4.2 June 21, 2010 -- Second attempt at blocking Bannerbomb. Deletes (again!) the Homebrew Channel and BootMii(/IOS), and patches IOS exploits used to install them.
The only update Nintendo has done in the past 2 and a half years that has actually benefitted users was v4.0, which added the SD support (as crude as it was). All the others have just been ways to fix various exploits. They fail at using the carrot; their stick is the fact that the Shopping channel will break unless you update, and many games will force you to update before you can play them.
There is carrier-specific baseband that runs on each device, so it could have something to do with that.
Untrue. Each firmware for each iPhone comes with a version of the baseband firmware that will work anywhere in the world; the only carrier-specific settings are SIM locking info (ugh), voicemail/MMS servers, etc.
Gee, thanks for "allowing" this, you're all too kind. [...] But I'm sure it will be a great innovation and a lot of fuss about it when the iPhone 4G or whatever invents video calls later on.
You do realize that the company that is "allowing this" is Skype, not Apple, right? There was an Apple-imposed restriction on apps using VOIP over 3G, but that was lifted back in January -- hell, that's even in the summary of this article! Other apps that were released or updated since then have supported it.
The news here is that Skype finally updated their own app, and Skype may start charging for their service when used over 3G -- money that would go to them, not to Apple, AT&T or anyone else. That's the only "innovation" we're talking about here.
You can develop however you like on OS X, which would be the analogous case to developing on Windows.
Find me a 10" MacBook on Apple's web site. The closest thing is iPad.
Why do you need a "MacBook mini"?
For the same reason that anyone else needs a 10" laptop: limited physical space. I seem to remember that either AT&T or a netbook maker ran a TV ad about a netbook (in flight mode) fitting into a coach airplane seat, while the seat in front got in the way of a larger laptop's screen.
And consider the "Homepage" at the top of your post. I use my Dell Mini 10 to develop homebrew games for at least one game console.
Sure; I wasn't disagreeing with you, I just didn't understand what you were saying and was asking for clarification.
When the parent poster said "You can develop however you like on OS X", I think they meant "You can write whatever programs you want on OS X" or perhaps "You can use whatever software tools you want to write programs that run on OS X". I don't think anyone ever said "Everyone who wants to develop for OS X will find hardware that fits their needs".
That being said... coming back around (tangentially) to the world of gaming, I believe the Mac builds of ScummVM are actually built on Linux boxes using a cross-compiling toolchain (based on odcctools). That's more effort than I'd care to go to, but if you were dead-set on developing apps for the Mac using your Dell Mini 10, you could go that route.
No, there are two words to explain that: Other OS. Check out this table (slightly outdated, it's a year old or so) by console hacker Michael Steil (or watch him talk about it on any of his talks). Every console post-PS2 was hacked for homebrew, and then those hacks were abused for piracy. The PS3 comes with homebrew, therefore there is little motivation to crack the native system. Pro-piracy people are rarely good hackers, and need homebrew to piggyback on.
This is just plain BS. Piracy on modern consoles (at least in the case of the Xbox 360 and Wii) involve bypassing the DVD drive's built in security check. This really has nothing to do with homebrew and you can, in fact, run homebrew on either system without modifying the DVD drive to accept pirated discs. So your statement that pro-piracy people are a) rarely good hackers and b) are piggybacking on homebrew is complete crap.
Get your facts straight before commenting on something you obviously know nothing about.
You might want to weigh your own confidence against the authority of the person making claims you disagree with before launching into an attack.
I don't really understand your objection to a), and I think Marcan's claims about b) are justified but deserve a bit of clarification. It's not so simple; as Michael Steil discusses, the efforts (piracy vs homebrew) often leverage each others' work. The only reason you can "run homebrew [on the Wii] without modifying the DVD drive to accept pirated discs" is that... we were able to bootstrap our efforts by using modified disc images, which requires modifying the DVD drive to accept burned discs. The first unsigned code execution we demonstrated used a patched Lego Star Wars disc with code injected into it. Later, we used the same technique to inject debugging code into a copy of Zelda, and then used that to facilitate making a save-game exploit that ultimately did not require hardware modification.
It might have been possible to reach that end goal in some different way, but it would have been much more difficult.
Just watch out if your computer dies and you have no way to start iTunes and click "Deactivate". 5 dead computers later and all your purchases are history.
... except for the part where you can fire up iTunes on your new computer, sign into your account without activating, and click "Deauthorize All Computers" and then activate your new computer(s).
The people who create the jailbreaking tools (or find the exploits, at least) do it for the challenge of it.
The people who use them are generally people who thought the "locked-down" out-of-the-box experience was worth the money they paid, and who find it fun to push it a bit further with a jailbreak.
"The jailbreaker who despises the restrictions imposed by the manufacturer" is a straw man. I'm sure you can find a counterexample (or at least, someone trying to be contrary) if you try hard enough, but in general, "jailbreakers" come in all of these categories but one:
Those who find exploits and hacks for fun of it
Those who want "a little bit more" out of a device they otherwise already enjoy
Those who want to install pirated apps
Those who hate Apple yet still spend their hard-earned money on a device, only to apply a hack that will only work for sum indeterminate amount of time
As with the AdMob survey numbers based on web browsing hits this survey is suspicious.
Looking through my web server logs the only smartphone browser hits I get are from iPhone clients...
"Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3"
Amazon runs their EC2 cloud computing cluster off iPhones? Something really fishy is going on here.
Yeah, 1A543a is a really really old version of the software (over 2 years old -- it's what the first iPhone launched with). If that's representative of what most of the transactions look like, they're probably bogus.
Googling for these mysterious keys turned up nothing.
Is Apple lying to the court?
You're just looking in the wrong places. There are two 128-bit constants stored in the System Management Controller chip (alongside fan speeds and temperature info) in the keys "OSK0" and "OSK1"; the first time someone accidentally dumped these seems to have been in this forum post. The scheme is documented a bit further in a couple of artictles: "TPM DRM" In Mac OS X: A Myth That Won't Die and Darwin/x86: Mac OS X Binary Protection. I'll leave it to you to manually decode the keys into ASCII, but will point out that they are normally retrieved from the hardware by a kext called "Dont Steal Mac OS X.kext". The reason your "special bootloader" works on vanilla hardware is that it replaces that kext with a version that contains the keys hardcoded into it; it will never install on any machine without replacing or patching that kext, EFI or not. (All of the bootloaders that can use unmodified installation media patch or inject this kext before passing control to the loaded XNU kernel.)
If you've gotten to the point where you're patching that kext, there's not much else that can be done to stop you, which is why they gave the kext its name and included the following plain-text string in the binary:
Your karma check for today:
There once was was a user that whined
his existing OS was so blind,
he'd do better to pirate
an OS that ran great
but found his hardware declined.
Please don't steal Mac OS!
Really, that's way uncool.
(C) Apple Computer, Inc.
A major complication is the fact that today's PDA phones are basically cellular winmodems. [...] In contrast, the humble i300 was literally a cell phone radio bolted to a PalmOS PDA, connected by LITERALLY a serial port.
[...]As I understand it, a phone running Android (or Windows Mobile, for that matter) is kind of like a PC running Linux under VMware under Windows (or vice-versa).
This is not true, at least not in the case of the iPhone (which has an Infineon baseband processor connected to a Samsung "Applications Processor" by "LITERALLY a serial port") or the Palm Pre (Qualcomm baseband, TI OMAP AP).
Qualcomm's product info page for the MSM7201 processor used in the HTC Hero says that it includes "Integrated ARM11 applications processor and ARM9 modem, QDSP4000 and QDSP5000 high-performance digital signal processors (DSP)". It would seem likely that the ARM9 core (in combination with one or both of the DSPs) does all of the modem work; I see no reason to suspect that the ARM11 ever "steals cycles from cpu #1".
There's no well-defined line of what software is expressive (and eligible for copyright) and what software is merely functional. I would argue that this software is merely functional -- there's not all that much code, and there are only a few ways you can write code that performs the same function. It's largely mechanical.
On the other hand, the Nintendo logo is actually contained in the ROM, as part of the protection mechanism. This was probably done as a "copyright/trademark trick" -- the logo is certainly expressive (and eligible for copyright), so in order to make a clone cartridge, you would have to copy this logo.
Unfortunately for Nintendo, Sega tried this trick in court and lost a couple of years later. That court case actually established the precedent I'm alluding to above... a few choice quotes from the decision:
In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for purposes of copyright. "[W]hen specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement."
[...]
Sega's trademark security system (TMSS) initialization code not only enables video game programs to operate on the Genesis III console, but also prompts a screen display of the SEGA trademark and message. As a result, Accolade's inclusion of the TMSS initialization code in its video game programs has an effect ultimately beneficial neither to Sega nor to Accolade. A Genesis III owner who purchases a video game made by Accolade sees Sega's trademark associated with Accolade's product each time he inserts the game cartridge into the console. Sega claims that Accolade's inclusion of the TMSS initialization code in its games constitutes trademark infringement and false designation of origin in violation of [...] the Lanham Trademark Act. Accolade counterclaims that Sega's use of the TMSS to prompt a screen display of its trademark constitutes false designation of origin under Lanham Act section 43(a), 15 U.S.C. Section 1125(a).
Because the TMSS has the effect of regulating access to the Genesis III console, and because there is no indication in the record of any public or industry awareness of any feasible alternate method of gaining access to the Genesis III, we hold that Sega is primarily responsible for any resultant confusion. Thus, it has not demonstrated a likelihood of success on the merits of its Lanham Act claims.
This legal issue was later revisited in a slightly different form (with mixed results) in Lexmark V. Static Control Components -- however, in that case, there was a lot more code involved than the boot ROM we're talking about here, so much more room for claims of expressive code.
Slashdot Mirror
iSuppli's business model revolves around finding you low prices for components (for a nice, hefty fee, of course) for your next big consumer electronics product; these teardowns are just advertising for that service. In order to pull customers in, they mark down the lowest plausible price for each component; it's unlikely that even Apple can get these low prices for each component.
Practially every teardown they show is low-balled, because there's no way to verify any of these numbers, and lower numbers gets them more contracting business.
This is well-written, but mostly incorrect, based on some bad assumptions about sandboxing and encryption.
The main differences are as follows: the iOS sandbox is somewhat weaker than the Android sandbox. It restricts fewer things and in the past (not sure if it was fixed these days), key first-party apps such as the web browser were not sandboxed at all, which is how several generations of jailbreak worked.
No, the iOS sandbox is stronger, in that it supports more fine-grained control over access to individual syscalls (based on the BSD-heritage Mandatory Access Control framework), as well as the API-level and filesystem permission-level isolation that Android relies upon. Jailbreaks didn't rely on a lack of sandboxing, for the most part -- they exploited kernel bugs in e.g. the graphics driver. It took until 2011 that "rooting" on Android even approached the complexity of the 2008 iPhone exploits; the neccesary exploits on Android were generally much simpler.
Android was designed from the ground up with the mentality that there should ideally not be an "us vs them" divide - Android treats all apps more or less the same, security-wise, meaning that the browser is just a regular app that runs in a permission-controlled sandbox like any other. This open design is one reason why the permissions UI on Android is more complex than for iOS - apps can do more things and the OS has to communicate that to you.
This is only partially true. Android most certainly does distinguish between "system apps" and 3rd-party apps -- why do you think people have to root their phones to remove crapware?
The main reason that Android's permissions UI is more complex is ... a design issue. The Android team decided that it was better to make all users click through a screen showing a bunch of scary shit, so that they could later blame the user if the app does something strange. "Dialog fatigue" ensures that very few people actually read the whole UI, and the fact that you can't (on a stock system) individually deny any access (while still using the app) means that most people just suck it up and run the app and take their chances.
Most of the rest of what you wrote is wrong, because you base it on the statement that Android's sandbox is stronger.
With regards to other features, like drive encryption, as of the latest releases I believe both operating systems are largely comparable.
Okay, now go back and actually read the Apple paper, starting with page 8. iOS's encryption is fine-grained -- the whole partition is encrypted, and then individual files are further encrypted, depending on the application and use (e.g. you can receive new email and take new photos while the phone is locked; that stuff is then encrypted and written to flash, and cannot be accessed until you unlock the phone with a PIN. Older contents cannot be decrypted until you unlock the phone). Android only got encryption with 3.x and 4.x -- about 2 years after it appeared on iOS -- and it's a shitty implementation (requires a full battery, AC power, and > 1 hour to enable or disable; any interruption will cause data loss; must enter PIN code on boot, which then causes the whole flash to be decrypted in memory until you turn the phone off).
I think that the issue here is that Apple is required to "only allow one download per purchase, under normal circumstances" (or something to that effect). Emailing them and asking for them to make an exception and let you redownload the music may be within the terms of their license, but "automatic" redownloading apparently isn't.
How did Sony fuck that one up? It was my(admittedly layman's) understanding that a public/private key crypto implementation, assuming it isn't deeply flawed, using key lengths suited to the computational capacities of PDP-8s, or otherwise totally fucked, was mathematically secure against anything other than a profound breakthrough in prime factorization algorithms, an unbelievable advance in computational power, or an insider leaking your private key.
Close. These algorithms only work correctly if implemented correctly. There are various known pitfalls with each of these algorithms; for example, the original iPhone was unlocked using an RSA implementation error (Bleichenbacher attack against an RSA implementation that does not correctly validate padding and uses exponent 3). ECDSA happens to have a "pitfall" that leaks information inside the signatures it makes.
This doesn't make it a bad algorithm -- it can achieve the same security of RSA using smaller keys and in less time -- but the "pitfall" here is particularly bad.
They don't have Sony's signing key, from what I've read. What they have is a flaw in the key generation process, which allows them to generate valid signed packages without the private key. In fact, here's the video from the conference itself: http://www.youtube.com/watch?v=GPjd6gHY6A4
No, GP was right. The exact signing key used by Sony may be derived from the public components of their ECDSA signatures. Not something close; not something equivalent.
Having worked with several commercial USB protocol analyzers over the years I have yet to see one was anything more than an FPGA connected to an off the shelf USB PHY chip. As much as I like cute dog videos these guys need to post proper requirements and design specifications if they seriously want funding from me.
Click through the links to the actual Kickstarter project description. We did some handwaving to keep it accessible for J. Random (Software) Hacker, but I think we gave enough details to answer your questions.
(tl;dr: yes, you're right, and that's more or less what we're doing. Haven't decided on which PHY to use, looking at some SMSC and NXP parts.)
Yup, similarly to the DS homebrew scene. IIRC the libdns homebrew library had parts which were ripped of the original nintendo SDK... of course people just turned a blind eye on that
It's a subject of some debate. The Xbox homebrew scene, as I understand it, used files directly copied from a leaked Xbox SDK. libnds uses some code that is more or less directly translated from disassembled DS SDK code (though you can get most of the same code from dumped games anyway); some feel that this is morally / legally equivalent to just copying the files.
I fail to see your logic, there is no independent group in charge of banning people from the PSN. If Sony decides to ban you, there is absolutely nothing you can do about it, regardless of the reason they ban you.
Sure -- if Sony decides to ban you, you've already messed up. Sony can't "decide to ban you" if they can't tell you've done anything naughty, so it's better to avoid permanent changes to the console that can be detected by their software.
I think most of you are missing the fact that this is running on a debug unit
What makes you say that?
Care to explain what PCB traces are shared between D+/D- on the USB and the RAM? And what this has to do with your TomTom?
You're also confusing the service mode jig used in Sony repair centers on retail consoles with debug consoles used for development. The two are unrelated.
It's also worth pointing out that Rigol apparently makes some of Agilent's low-end scopes for them, so the fact that they aren't a household name doesn't mean all that much.
The Rigol scope has a lot of nice features that you wouldn't expect to find on a cheap scope -- it can take screenshots and store them to a USB thumb drive or print them to a USB printer, you can connect it to your computer to control it or acquire data via USB or RS-232, etc. It actually oversamples at 1 Gigasample/second -- there have been a number of EEVblog shows about it, talking about its performance, the parts that go into it (and the corners they did cut to get the price down!), etc. Google "eevblog rigol" to find the rest of them.
As for adding new functionality, Nintendo has been adding new functionality to the Wii from time to time as well (dare I say more than Sony has done with PS3). This update is the first anti-piracy-only Wii update that doesn't add new functionality (or fix other problems).
They really haven't. Let's consider the timeline of updates to the Wii software since the first exploit was demonstrated. Note that there's no technical need to update the System Menu, any version of IOS (the invisible "firmware" that implements all of the interesting security features of the system), or any channel at the same time. IOS fixes can never add functionality by themselves, they can only work around some bugs in disc-based games. Any update that claims "behind the scenes updates" or "system improvements" refers to IOS updates, most of which are to patch exploits and very few of which actually impact performance, despite their claims.
The only update Nintendo has done in the past 2 and a half years that has actually benefitted users was v4.0, which added the SD support (as crude as it was). All the others have just been ways to fix various exploits. They fail at using the carrot; their stick is the fact that the Shopping channel will break unless you update, and many games will force you to update before you can play them.
There is carrier-specific baseband that runs on each device, so it could have something to do with that.
Untrue. Each firmware for each iPhone comes with a version of the baseband firmware that will work anywhere in the world; the only carrier-specific settings are SIM locking info (ugh), voicemail/MMS servers, etc.
This sounds awfully familiar... http://en.wikipedia.org/wiki/Sleep_Proxy_Service
Gee, thanks for "allowing" this, you're all too kind. [...] But I'm sure it will be a great innovation and a lot of fuss about it when the iPhone 4G or whatever invents video calls later on.
You do realize that the company that is "allowing this" is Skype, not Apple, right? There was an Apple-imposed restriction on apps using VOIP over 3G, but that was lifted back in January -- hell, that's even in the summary of this article! Other apps that were released or updated since then have supported it.
The news here is that Skype finally updated their own app, and Skype may start charging for their service when used over 3G -- money that would go to them, not to Apple, AT&T or anyone else. That's the only "innovation" we're talking about here.
I hear RMS is a big fan of borscht: http://www.mefeedia.com/watch/26124889
You can develop however you like on OS X, which would be the analogous case to developing on Windows.
Find me a 10" MacBook on Apple's web site. The closest thing is iPad.
Why do you need a "MacBook mini"?
For the same reason that anyone else needs a 10" laptop: limited physical space. I seem to remember that either AT&T or a netbook maker ran a TV ad about a netbook (in flight mode) fitting into a coach airplane seat, while the seat in front got in the way of a larger laptop's screen.
And consider the "Homepage" at the top of your post. I use my Dell Mini 10 to develop homebrew games for at least one game console.
Sure; I wasn't disagreeing with you, I just didn't understand what you were saying and was asking for clarification.
When the parent poster said "You can develop however you like on OS X", I think they meant "You can write whatever programs you want on OS X" or perhaps "You can use whatever software tools you want to write programs that run on OS X". I don't think anyone ever said "Everyone who wants to develop for OS X will find hardware that fits their needs".
That being said ... coming back around (tangentially) to the world of gaming, I believe the Mac builds of ScummVM are actually built on Linux boxes using a cross-compiling toolchain (based on odcctools). That's more effort than I'd care to go to, but if you were dead-set on developing apps for the Mac using your Dell Mini 10, you could go that route.
You can develop however you like on OS X, which would be the analogous case to developing on Windows.
Find me a 10" MacBook on Apple's web site. The closest thing is iPad.
Why do you need a "MacBook mini"?
No, there are two words to explain that: Other OS. Check out this table (slightly outdated, it's a year old or so) by console hacker Michael Steil (or watch him talk about it on any of his talks). Every console post-PS2 was hacked for homebrew, and then those hacks were abused for piracy. The PS3 comes with homebrew, therefore there is little motivation to crack the native system. Pro-piracy people are rarely good hackers, and need homebrew to piggyback on.
This is just plain BS. Piracy on modern consoles (at least in the case of the Xbox 360 and Wii) involve bypassing the DVD drive's built in security check. This really has nothing to do with homebrew and you can, in fact, run homebrew on either system without modifying the DVD drive to accept pirated discs. So your statement that pro-piracy people are a) rarely good hackers and b) are piggybacking on homebrew is complete crap.
Get your facts straight before commenting on something you obviously know nothing about.
You might want to weigh your own confidence against the authority of the person making claims you disagree with before launching into an attack.
I don't really understand your objection to a), and I think Marcan's claims about b) are justified but deserve a bit of clarification. It's not so simple; as Michael Steil discusses, the efforts (piracy vs homebrew) often leverage each others' work. The only reason you can "run homebrew [on the Wii] without modifying the DVD drive to accept pirated discs" is that ... we were able to bootstrap our efforts by using modified disc images, which requires modifying the DVD drive to accept burned discs. The first unsigned code execution we demonstrated used a patched Lego Star Wars disc with code injected into it. Later, we used the same technique to inject debugging code into a copy of Zelda, and then used that to facilitate making a save-game exploit that ultimately did not require hardware modification.
It might have been possible to reach that end goal in some different way, but it would have been much more difficult.
Just watch out if your computer dies and you have no way to start iTunes and click "Deactivate". 5 dead computers later and all your purchases are history.
... except for the part where you can fire up iTunes on your new computer, sign into your account without activating, and click "Deauthorize All Computers" and then activate your new computer(s).
The people who use them are generally people who thought the "locked-down" out-of-the-box experience was worth the money they paid, and who find it fun to push it a bit further with a jailbreak.
"The jailbreaker who despises the restrictions imposed by the manufacturer" is a straw man. I'm sure you can find a counterexample (or at least, someone trying to be contrary) if you try hard enough, but in general, "jailbreakers" come in all of these categories but one:
As with the AdMob survey numbers based on web browsing hits this survey is suspicious.
Looking through my web server logs the only smartphone browser hits I get are from iPhone clients...
Amazon runs their EC2 cloud computing cluster off iPhones? Something really fishy is going on here.
Yeah, 1A543a is a really really old version of the software (over 2 years old -- it's what the first iPhone launched with). If that's representative of what most of the transactions look like, they're probably bogus.
Googling for these mysterious keys turned up nothing.
Is Apple lying to the court?
You're just looking in the wrong places. There are two 128-bit constants stored in the System Management Controller chip (alongside fan speeds and temperature info) in the keys "OSK0" and "OSK1"; the first time someone accidentally dumped these seems to have been in this forum post. The scheme is documented a bit further in a couple of artictles: "TPM DRM" In Mac OS X: A Myth That Won't Die and Darwin/x86: Mac OS X Binary Protection. I'll leave it to you to manually decode the keys into ASCII, but will point out that they are normally retrieved from the hardware by a kext called "Dont Steal Mac OS X.kext". The reason your "special bootloader" works on vanilla hardware is that it replaces that kext with a version that contains the keys hardcoded into it; it will never install on any machine without replacing or patching that kext, EFI or not. (All of the bootloaders that can use unmodified installation media patch or inject this kext before passing control to the loaded XNU kernel.)
If you've gotten to the point where you're patching that kext, there's not much else that can be done to stop you, which is why they gave the kext its name and included the following plain-text string in the binary:
A major complication is the fact that today's PDA phones are basically cellular winmodems. [...] In contrast, the humble i300 was literally a cell phone radio bolted to a PalmOS PDA, connected by LITERALLY a serial port.
[...]As I understand it, a phone running Android (or Windows Mobile, for that matter) is kind of like a PC running Linux under VMware under Windows (or vice-versa).
This is not true, at least not in the case of the iPhone (which has an Infineon baseband processor connected to a Samsung "Applications Processor" by "LITERALLY a serial port") or the Palm Pre (Qualcomm baseband, TI OMAP AP).
Qualcomm's product info page for the MSM7201 processor used in the HTC Hero says that it includes "Integrated ARM11 applications processor and ARM9 modem, QDSP4000 and QDSP5000 high-performance digital signal processors (DSP)". It would seem likely that the ARM9 core (in combination with one or both of the DSPs) does all of the modem work; I see no reason to suspect that the ARM11 ever "steals cycles from cpu #1".
On the other hand, the Nintendo logo is actually contained in the ROM, as part of the protection mechanism. This was probably done as a "copyright/trademark trick" -- the logo is certainly expressive (and eligible for copyright), so in order to make a clone cartridge, you would have to copy this logo.
Unfortunately for Nintendo, Sega tried this trick in court and lost a couple of years later. That court case actually established the precedent I'm alluding to above... a few choice quotes from the decision:
In some circumstances, even the exact set of commands used by the programmer is deemed functional rather than creative for purposes of copyright. "[W]hen specific instructions, even though previously copyrighted, are the only and essential means of accomplishing a given task, their later use by another will not amount to infringement."
[...]
Sega's trademark security system (TMSS) initialization code not only enables video game programs to operate on the Genesis III console, but also prompts a screen display of the SEGA trademark and message. As a result, Accolade's inclusion of the TMSS initialization code in its video game programs has an effect ultimately beneficial neither to Sega nor to Accolade. A Genesis III owner who purchases a video game made by Accolade sees Sega's trademark associated with Accolade's product each time he inserts the game cartridge into the console. Sega claims that Accolade's inclusion of the TMSS initialization code in its games constitutes trademark infringement and false designation of origin in violation of [...] the Lanham Trademark Act. Accolade counterclaims that Sega's use of the TMSS to prompt a screen display of its trademark constitutes false designation of origin under Lanham Act section 43(a), 15 U.S.C. Section 1125(a). Because the TMSS has the effect of regulating access to the Genesis III console, and because there is no indication in the record of any public or industry awareness of any feasible alternate method of gaining access to the Genesis III, we hold that Sega is primarily responsible for any resultant confusion. Thus, it has not demonstrated a likelihood of success on the merits of its Lanham Act claims.
This legal issue was later revisited in a slightly different form (with mixed results) in Lexmark V. Static Control Components -- however, in that case, there was a lot more code involved than the boot ROM we're talking about here, so much more room for claims of expressive code.