Slashdot Mirror

Clicking a link to a page containing a textbox containing File:/// will. So this is also a remote DoS for Safari.

Are you the founder of the "Shitheads who think owning guns is a good idea" community?

--

Marcan, professional asshole

The Kinect 1 already has a 640x480 depth buffer. The problem is that the depth image is built by interpolating from a series of depth samples taken from the pseudorandom dot constellation that is projected by the laser, and neither are those dots dense enough, nor is the DSP in the kinect particularly excellent at resolving them. Effectively, you have a 640x480 image built of "patches" that are several pixels wide.

If you compare the image in TFA to, say, this one, it does appear to be resolving depth more accurately (smooth edges, ability to resolve fingers at a distance, etc.)

Well, if JavaScript is the language that you're most familiar and comfortable with, and you're happy using a browser or you have a commandline JS interpreter handy, then by all means. I personally prefer Python of course, but everyone has a different taste in programming languages. However, what makes no sense is writing it in JS just because the original file ends in .js. That little fact should have exactly zero influence on the choice of language that you do pick to implement this in.

Considering the parent switched to C++ though, it seems the he hit some kind of snag. If JS is his preferred scripting language then I wouldn't expect him to switch to something else when he has trouble, that's why I kind of assumed that he picked JS just because the original file happened to be JS and not because it's what he finds easiest.

FWIW, my Python version is about 2.5x shorter than TFA's version (counting only the actual code, not the memory block or comments), though I went for a quick and dirty, shortest and simplest version that would do the job, without attempting to make it pretty-print instructions or do anything fancy, and without giving much though to readability (it was meant as a throwaway implementation that I could expand upon if I needed to analyze execution in more detail - thankfully, that wasn't needed and after adding a couple debug prints I was able to iron out a bug or two and it just worked).

If you want a steganography challenge (with a twist), try this, from this year's Hack-It ;)

My opinion, as someone who has both solved and organized several challenges of this sort, is that the challenge is neither hard (at least by the standards of the ones I've dealt with) nor well designed. In fact, it kind of degenerates: it starts out OK but the ending is terrible.

Stage 1 is interesting: it combines recognizing executable code (the first thing I thought when I stared at that hex dump is "this looks like x86 code", but being able to recognize binary architectures is a valuable skill) combined with some steganography (fishing out the rest of the required data from the PNG. Fair enough, and OK for a first round.

Stage 2 starts out well: virtual machines are used for obfuscation and make fun challenges. However, the execution is backwards. Being given VM bytecode and a specificiation to implement a VM isn't a hacking or reverse engineering challenge; it's just work ("go implement this for me"). A much better challenge would be to be given either the spec or (preferably) code that implements it, and then have to reverse engineer the bytecode itself to solve the puzzle. That involves writing a custom disassembler, which is a much more interesting task.

Stage 3 is a clusterfuck. It's just an executable that checks for a few constants in a file and then builds a URL out of the rest of it. There's a hash (old-school DES crypt() salted password) that the input has to match, but even though it's crackable using a dictionary, you don't even have to do that because the URL includes the hash (which is in the executable), not the plaintext! The rest of the URL isn't checked, and it's basically a guessing game where you have to fish out constants from previous levels. It's just a glorified way of saying "okay, now take a wild guess as to what numbers to stick in the URL". It's not realistic in the slightest.

Anyone interested in a "better stage 2" might want to check out a level that I put together for the Hack-It competition at the 18th Euskal Encounter (2010). Your goal is to figure out the 64-bit input key that works (if you don't know what "works" means, compile and run the code and it should be obvious). The full set of challenges can be found here: 2010 2011 (unfortunately, the website / problem statements are in Spanish, but I'm sure you can work it out with a bit of copy/pasting into Google Translate - if there's enough interest I'll translate them to English).

My opinion, as someone who has both solved and organized several challenges of this sort, is that the challenge is neither hard (at least by the standards of the ones I've dealt with) nor well designed. In fact, it kind of degenerates: it starts out OK but the ending is terrible.

Stage 1 is interesting: it combines recognizing executable code (the first thing I thought when I stared at that hex dump is "this looks like x86 code", but being able to recognize binary architectures is a valuable skill) combined with some steganography (fishing out the rest of the required data from the PNG. Fair enough, and OK for a first round.

Stage 2 starts out well: virtual machines are used for obfuscation and make fun challenges. However, the execution is backwards. Being given VM bytecode and a specificiation to implement a VM isn't a hacking or reverse engineering challenge; it's just work ("go implement this for me"). A much better challenge would be to be given either the spec or (preferably) code that implements it, and then have to reverse engineer the bytecode itself to solve the puzzle. That involves writing a custom disassembler, which is a much more interesting task.

Stage 3 is a clusterfuck. It's just an executable that checks for a few constants in a file and then builds a URL out of the rest of it. There's a hash (old-school DES crypt() salted password) that the input has to match, but even though it's crackable using a dictionary, you don't even have to do that because the URL includes the hash (which is in the executable), not the plaintext! The rest of the URL isn't checked, and it's basically a guessing game where you have to fish out constants from previous levels. It's just a glorified way of saying "okay, now take a wild guess as to what numbers to stick in the URL". It's not realistic in the slightest.

Anyone interested in a "better stage 2" might want to check out a level that I put together for the Hack-It competition at the 18th Euskal Encounter (2010). Your goal is to figure out the 64-bit input key that works (if you don't know what "works" means, compile and run the code and it should be obvious). The full set of challenges can be found here: 2010 2011 (unfortunately, the website / problem statements are in Spanish, but I'm sure you can work it out with a bit of copy/pasting into Google Translate - if there's enough interest I'll translate them to English).

My opinion, as someone who has both solved and organized several challenges of this sort, is that the challenge is neither hard (at least by the standards of the ones I've dealt with) nor well designed. In fact, it kind of degenerates: it starts out OK but the ending is terrible.

Stage 1 is interesting: it combines recognizing executable code (the first thing I thought when I stared at that hex dump is "this looks like x86 code", but being able to recognize binary architectures is a valuable skill) combined with some steganography (fishing out the rest of the required data from the PNG. Fair enough, and OK for a first round.

Stage 2 starts out well: virtual machines are used for obfuscation and make fun challenges. However, the execution is backwards. Being given VM bytecode and a specificiation to implement a VM isn't a hacking or reverse engineering challenge; it's just work ("go implement this for me"). A much better challenge would be to be given either the spec or (preferably) code that implements it, and then have to reverse engineer the bytecode itself to solve the puzzle. That involves writing a custom disassembler, which is a much more interesting task.

Stage 3 is a clusterfuck. It's just an executable that checks for a few constants in a file and then builds a URL out of the rest of it. There's a hash (old-school DES crypt() salted password) that the input has to match, but even though it's crackable using a dictionary, you don't even have to do that because the URL includes the hash (which is in the executable), not the plaintext! The rest of the URL isn't checked, and it's basically a guessing game where you have to fish out constants from previous levels. It's just a glorified way of saying "okay, now take a wild guess as to what numbers to stick in the URL". It's not realistic in the slightest.

Anyone interested in a "better stage 2" might want to check out a level that I put together for the Hack-It competition at the 18th Euskal Encounter (2010). Your goal is to figure out the 64-bit input key that works (if you don't know what "works" means, compile and run the code and it should be obvious). The full set of challenges can be found here: 2010 2011 (unfortunately, the website / problem statements are in Spanish, but I'm sure you can work it out with a bit of copy/pasting into Google Translate - if there's enough interest I'll translate them to English).

The simple trig will give you the nominal separation at the surface. Then, when you run the trig in reverse to calculate the pixel separation at the camera... you end up with exactly the same reparation regardless of depth. The camera has a radial field of view just like the projector, and pixels correspond to a fixed angle. Since the camera and the projector are on the same plane, it cancels out. Ignoring brightness (which is unreliable) and dot size (which isn't accurate enough), a flat far surface looks exactly the same as a near flat surface, except one will be horizontally shifted as a whole when compared to the other.

Many people make this mistake, probably because they're imagining the pattern from a steep angle when viewed from outside the Kinect (or have seen YouTube videos to that effect). Our brains are also very good at associating the same angular (pixel) separation on an object that is (apparently) far away with a larger actual separation (this is why those optical illusions where two objects look different in size due to false depth cues work). However, when you view the pattern from the Kinect on the same plane as the source, and ignoring any previous knowledge of how deep parts of the image are (since, of course, finding out is the whole point), the average separation between dots is the same across the entire depth range where local depth difference is zero. Separation between dots is proportional to the derivative of the depth (local depth difference) only, but it is not proportional to absolute depth.

For example, look at this IR dot image, as seen by the Kinect (note: half resolution, since getting the fullres raw image out via USB is problematic). If you look closely and ignore the varying dot brightness and dot size (the dots are laser beams so the virtual point source for each beam is very far behind the Kinect, and thus isn't on the same plane as the camera so dot size varies as seen by it), you'll see that the dot density is basically the same across all depths (measured in dots per area, not dot pixels per area - don't be misled by the larger dots on surfaces near the camera).

It may lead to a more open PS3, but will result in the PS4 being considerably less open as an attempt to counter the hacking.

Sony already blew it by pulling OtherOS. If the PS4 is less open, then, as usual, chances are it will be attacked earlier and by more dedicated homebrew hackers, and it will lead to piracy earlier. The PS3 was the most open system this generation, and also the one that lasted the longest without piracy. This isn't a coincidence. Sony can either learn the lesson and open up the PS4, or not do so and end up like all the others (somewhat outdated table).

http://marcansoft.com/transf/mist_table.png

That's what OtherOS was, indeed.

We all love to call out Apple when they design deliberate incompatibility into their devices, but there is a perfectly valid technical reason for what Apple is doing here, and, in fact, they are following a USB specification (which LadyAda unfortunaterly didn't even test).

Without data communications or when suspended, devices may legally draw no more than 2.5mA from a host, which is useless for charging. In fact, even if you're generous and pretend they're connected, devices are not allowed to draw more than 100mA without negotiating for a higher current, which requires actually talking to the host, and 100mA is still too little to charge properly. 500mA is the maximum allowed by the USB spec, but devices must negotiate it (there may be too many devices on the bus for negotiation to succeed).

Before there was a spec for "dumb" USB chargers, Apple used the resistors as a sentinel to avoid drawing too much current from undersized chargers in order to avoid damaging the host. This is a hack, but it works, and honestly, we're smart enough to figure out a couple resistors on the data lines. It's not like they're using crypto auth on the charger. They have a perfectly valid reason to do this. Devices which charge from "dumb" chargers aren't following the spec, though this is a common industry practice.

As it turns out, the USB-IF came up with a USB Battery Charging spec. The spec is long and boring, but it boils down to: short together the data lines (no resistors required) and you indicate that you're a dumb charger that can supply anywhere from 0.5A to 1.5A.

Guess what happens when you short the data lines of an iPhone 3G and supply 5V. Did Apple just follow a standard? Incredible!

(Yes, I'm not following the USB spec there by in turn using a USB cable to supply the 5V and not negotiating over its data lines. I didn't feel like grabbing a dedicated 5V PSU for the shot, so sue me.)

Is the ability to run Linux the main reason why the PS3 haven't been broken for so long, as people wanting to play with homebrew could be satisfied with the Linux ability?

Yes (slightly outdated).

If so, won't that mean that with Other OS gone, that enthusiasts will do their very best to crack that machine open any which way they can to enable homebrew, this time with the goal being full access?

Yes, and piracy advocates will come out with a piracy tool shortly after it is completely broken.

Yes, Sony is shooting itself in the foot bigtime.

Quite the contrary, it's not ridiculous, it's true. Sony's good drive security prevented drivechips (which is where the money's at), and Other OS prevented homebrewers from exploiting the system, which inevitably leads to softmod piracy (which is usually developed by people piggybacking on homebrew hackers for all the hard work). Consoles are hacked for homebrew which is then abused for piracy.

I know quite a few console hackers, and until the Slim's release (no Other OS) the interest in breaking out of the Other OS sandbox was near nil.

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.

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. In fact, the reason the PS3 was recently attacked was neither homebrew nor piracy; instead, geohot attacked it solely as an ego boost and to get media coverage (note how he hasn't even tried to develop a useful application for his exploit, such as GPU access under Linux).

Blu-ray is a minor inconvenience. There are a myriad potential ways of copying PS3 games that don't involve blu-ray discs.

Sony are shooting themselves in the foot by removing Other OS, and pissing off legitimate customers on top of it.

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.

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. In fact, the reason the PS3 was recently attacked was neither homebrew nor piracy; instead, geohot attacked it solely as an ego boost and to get media coverage (note how he hasn't even tried to develop a useful application for his exploit, such as GPU access under Linux).

Blu-ray is a minor inconvenience. There are a myriad potential ways of copying PS3 games that don't involve blu-ray discs.

Sony are shooting themselves in the foot by removing Other OS, and pissing off legitimate customers on top of it.

You can. They tried really hard, not just by using proprietary everything but also using ridiculously obfuscated crypto, but we broke it again. No jailbreaking needed.

For those who love magic 16-byte keys, the magic "freedom for Apple music players" number this time around is 618ca10dc7f57fd3b4723e08157463d7 ;)

You clearly haven't tried it, at least not with calm music. Here, try this. That's a single-sample, single-channel glitch at around second 16, created by changing a single byte in a WAV file with a hex editor (and then encoding to Vorbis for bandwidth reasons - this does not affect the effect of the glitch significantly). It's quite obvious.

It's probably regional targeting. I suspect Bing is a lot better in America. I'm in Spain, which explains the Spanish result and to some extent explains the German results (though they're terribly useless: even though English literacy levels are pretty mediocre around here, German is definitely worse off).

Here's a screenshot for the paranoid.

However, I did miss something: my Google settings were configured to an English UI, which I've noticed changes the targeting of the results (said targeting exists even if you're not using any of the "show me results in such and such language" options). The updated Google results for the default (Spanish) targeting are:

"Wii homebrew":

1. Spanish site about Wii homebrew
   • Homebrew channel subpage
2. Homebrew Channel at Wiibrew (former first result)
   • Main Page at Wiibrew (former second result)
3. Some Spanish tutorial on installing the Homebrew Channel
4. Another Spanish tutorial

Clearly more emphasis on Spanish results, but the good English results are still there and there are no random results in other languages that happen to be spoken in other parts of the continent. No scams either.

"Homebreware" results: two "did you mean 'homebrew'" results, followed by antiscam, spanish-antiscam, antiscam, video:[antiscam, scam, scam, scam (scammers love videos)], antiscam, unrelated, scam, ...

Still primarily antiscam results (lots of scam videos because not many make videos about how these products are a scam).

I believe that at least for Google you can replicate these results by simply changing your UI language to Spanish (or adding hl=es to the URL), and maybe try using google.es. I don't know whether there's an equivalent for Bing.

You tell me how they do that. Not software - the ROM bits have no recovery functionality. Hardware? Massive props for you if you can find any kind of JTAG or similar port on the board, because quite a few people have wasted lots of time trying and failing to do so. As far as we can tell, they preflash the NAND chips before soldering, and I'm not aware of anyone who hasn't just had their motherboard replaced after this kind of unrecoverable brick.

Here's a pinout diagram of the Hollywood with everything that's definitely not a recovery port marked. Let me know if you find any flashing/recovery functionality on the remaining pins ;)

EFI isn't rocket science - in fact, lots of it is publicly documented, which is much better than the completely proprietary old-school BIOS implementations. You can already mod UEFI-based BIOSes without much trouble.

This. Locking multiple groups of people out of your hardware with the same system is a great way to get it cracked faster. It's doubly stupid when the group that you've just locked out is the more technically capable one (Linux users and serious researchers), while the other group (piracy) tends to feed off of what other people have already done for them.

Just read this table. Let's see how long it takes for that black pair of boxes to become grey and red.

My prediction:

- The PS3 slim will be hacked. Now that there is no Other OS support, there is the same incentive as there has been for running homebrew on every other console.
- Said hacks will be used for warez, probably by people other than those who developed the hacks.

Linux hackers tend to be much more successful at system reverse engineering and exploitation than the kids who want warez. This is why Other OS is a Good Thing for Sony: it removes the incentive to bypass their security for a lot of people. By removing this option, they're setting themselves to have their security broken. And we all know how long it takes for "other" people to use these hacks for less than legal purposes (I learned this the hard way).

I firmly believe Other OS is one of the main reasons why there is no PS3 software piracy so far. Check out this table from our 25C3 presentation.

See

http://marcansoft.com/blog/2009/06/enabling-intel-vt-on-the-aspire-8930g/

Maybe a similar trick also works for Sony notebooks (if it is UEFI based).

And another: http://marcansoft.com/blog/2009/06/enabling-intel-vt-on-the-aspire-8930g/

Honestly, that's my last link... Google for others. It's not hard. I suggest looking for: "laptops with locked out vt"

He found that if he created certificates for his own Internet domain that included null characters -- often represented with a \0 -- some programs would misinterpret the certificates.

That's because some programs stop reading text when they see a null character.

This is the same exploit used in an older Nintendo Wii jailbreak - people just keep on using strcmp and its cousins to compare hashes.

I blogged about it and submitted the patches to the ALSA tree. It should hit mainline eventually (I'm not sure how often they sync up with ALSA).

Linux doesn't work with which iPods? My girlfriend and I have two different iPod models and they both work fine in Amarok (the KDE3 one, haven't tried in Amarok 2).

iPhones and current iPod Touch models require hacking for the iTunesDB to be usable with non-iTunes managers. Doing so rules out using the AppStore. More details.

And they heavily obfuscate the software that deals with that signature, both on the host and the device, to prevent any reverse engineering.

On the iPhone 2.x firmware you can just turn the check off if it's jailbroken, but I imagine you're pretty screwed when it comes to a closed device like the iPod.

Someone's been living under a rock since December 2007.

I'll just point you to the recent 25th Chaos Community Congress Console Hacking talk (slides, video) which neatly summarizes a year of hacking and how much of a horrible failure Nintendo's security has been.

Spoiler: their signatures used to have 8-bit security. Literally.

We've had lots of fun.

Here's one that's practically a steal: http://www.digilentinc.com/s3e/

For $150 you get an XC3S500, 16MB Flash, 64MB DDR SDRAM, Ethernet, a character LCD display, built-in programmer, ADCs and DACs, a whole bunch of smaller Flash/EEPROM memories, serial ports, one-bit-per-color VGA port, and a PS/2 mouse/keyboard port. I've been using it as a logic anazyer lately, and I'm going to try to write a NAND Flash emulator for it (interfaced via Ethernet to a PC). Great for beginner projects, and it can also implement quite a bit of older hardware :)

transKode almost got it right!