We don't require all kids to know automotive design or repair, nor manufacturing techniques for flat panel displays, nor cellphone antenna design, etc.
That's the root of the issue: that programming is seen in the same light as design and manufacturing, in other words, something that only professionals with years of training should do.
It's not. Most computer users could benefit from having some (very basic) programming knowledge. For example, my dad does software translation, and he doesn't really know much about "proper programming" (I did try, unsuccessfully, to get him to learn Python), but over the years he's worked with a number of scripting languages to automate parts of his job. These days, he tends to use AutoHotkey scripts, but a number of years ago he also used Windows analogs of shell scripting and sed to automate a number of tasks, including munging (ASCII-based) document formats in various ways. He understands the basics (variables, while loops, etc.) and can use them with a simple language to make his life (much) easier.
What could Joe Average Computer User do if he knew a bit about programming? For example, he could write a userscript to fix up a gripe in website that he visits frequently. Or write a batch file or shell script to automate a daily task. Or add some more complex logic to a spreadsheet. Or write a tool to organize his music collection in exactly the way that he wants it. Or write out a long mathematical calculation into a script so that he doesn't have to type it into a calculator over and over.
Keep in mind that the steepest part of the learning curve for an average person is figuring out the initial concepts (and the younger you start, the more likely it is that you'll "get it"). Once you know the basic constructs of computer languages, you can quickly pick up on any special-purpose language. Anyone who knows, say, Javascript (or any half-decent BASIC dialect for that matter) should be able to breeze through the Python tutorial.
Now, say, teaching Software Engineering to everyone would be a silly idea. Most people couldn't care less about MVC, or proper object-oriented design.
2K and 4K refer to the horizontal resolution. QuadHD/3840x2160p (which is what this is) is only slightly smaller than 4K horizontally, so it is often referred to as 4K (same with regular 1920x1080p and 2K).
Sadly, it has nothing to do with Flash (though Flash may well tear once everything else is fixed, but I don't care about Flash). Vsync is broken in various ways on Sandy Bridge and Ivy Bridge, both using a driver compiled with SNA enabled and not. Basically, any non-fullscreen video (or GL) will likely tear - and on a multihead display, fullscreen never happens (since "fullscreen" on on head is just a portion of the combined framebuffer). There's some attempt at vsync, since the tearing isn't random like on a completely unsynced display, but obviously it's not managing to do it correctly.
Running certain compositing window managers will "fix" this, especially dumber ones like compiz in a mode where they flip screen buffers every frame, effectively turning the whole desktop into a fullscreen GL window. However, that's not a real solution, and it doesn't work for saner window managers like KWin, which do partial screen updates. It also still doesn't work in multihead mode, because you can't do a fullscreen buffer flip synced across two different displays.
Actually, the upper layers of the Intel driver contain clever code that computes the overlap of a video/GL window with each display head, and syncs to the head with the highest overlap, which means tear-free video without having to specify which output to sync to via a control panel or environment variables (which was an annoyance with the nvidia blob driver). If only the underlying low-level sync mechanism actually worked, it would be perfect. It's the only gripe I have with the open drivers; everything else seems to work fine, but this issue really bugs me.
I actually did the math for the pressure variations in a small airtight room (3x3x3 meters), and came up with 5 microliters - that's the RMS delta volume of air that would be required to produce a sound pressure of 0dB for large wavelengths. At 40dB, that becomes half a mililiter, which should be achievable for a human, perhaps with the aid of a glass bottle. By blowing, though. Not with your vocal folds.
The ability to produce sound without a rigid airtight compartment depends on the inertia of air - this is why a speaker is able to compress air in front of it even though it is not connected to an airtight compartment (and also why speaker cabinets help; they effectively increase the apparent inertia of the air behind the speaker, making it harder for it to escape, thus increasing the amplitude of the pressure waves created). To produce a measurable SPL at 0.189Hz, a bare speaker cone would have to be very large and move a very large distance, because there is a very poor impedance match with the air at a frequency that low. In an airtight room, you could do with a smaller speaker placed between it and the outside, or equivalently, between it and an airtight compartment. The same concept applies to the human body: to produce a measurable SPL at that frequency without the aid of a rigid compartment (i.e. using your vocal folds), they'd have to move huge distances and be much larger. With an airtight compartment (blowing into a bottle or just compressing air in your lungs with your mouth closed) you can get away with a smaller system, but that's no longer using your vocal chords, and it requires an airtight room for efficient coupling. This is how rotary subwoofer works, which is probably the only currently practical way to reproduce audio in the 0Hz-10Hz range.
Put another way: what makes you think that his vocal folds can produce a higher SPL at 0.189Hz than simply waving your hand or breathing at that same frequency? The latter, although not particularly efficient, are certainly going to be more effective at creating very low frequency air pressure differences than the world's largest larynx.
I'm certainly not claiming that this man cannot produce fundamental tones (significantly) lower than most people, but when you go 8 octaves lower you need more than your voicebox, no matter how large or special, to produce pressure variations at a frequency that low.
Actually, we can all produce something resembling a pure "sound" at 0.189Hz. All you have to do is compress and uncompress air in your mouth (or lungs, or a bottle) at that rate. The small air volume variation (translating to a variation in the volume of your body) should be enough to produce a sound pressure level of a few decibels at that frequency, particularly if you're in a small airtight room.
I doubt Tim's voice, in practice, produces more energy at frequencies that low than the above method. More likely, the sound that he produces is pretty much entirely composed of harmonics (i.e. "clicks" at that rate, not a fundamental tone). The human voice just isn't capable of producing sinusoidal tones that low. Just listen to him (or anyone else with a deep voice) talk. His voice doesn't sound like a deep pure tone, it sounds like a deep growl (i.e. a series of higher frequency noises repeated at that rate).
For the record, you can get ARM SoCs that are almost entirely open - the TI OMAP series does a pretty decent job, and last I checked they have excellent open documentation. Sure, the PowerVR graphics crap is proprietary, but you don't have to use it - it's purely a coprocessor that renders to a framebuffer. The video output hardware is independent, open, and documented (i.e. the equivalent of an S3 VGA adapter).
Broadcom, though, is pretty much the antithesis of open documentation.
The GPU boots the Pi. Without the GPU blob, it won't run anything at all.
The reason for this, reportedly, is that the team responsible for that SoC at Broadcom is officially a GPU team, so in fact the GPU is the main processor, and the ARM core is tacked on to the side. You're basically running a fully proprietary processor and firmware that just so happens to run Linux on an ARM coprocessor.
It's Broadcom. Anyone who expected it to work flawlessly with Linux hasn't been following that company's past.
Sure, it'll mostly-work-with-bugs-and-binblobs-and-old-kernel-versions, just like anything else Broadcom. If people want better than that, they should've used an SoC vendor that is actually friendly to the open source community and publishes real documentation..
Actually, I'm of the opposite opinion for the same reason. I gave up on Amarok ever since 2.0, and I'm much more interested in Clementine releases. As soon as Clementine gets arbitrary labels ("tags" in the "web 2.0" sense) and fixes up their device support a bit (I'm particularly looking forward to the day MTP works smoothly with Android devices), it'll pretty much have covered all Amarok 1.4 features I cared for.
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.)
The Ouya is *significantly* more powerful than the Wii, both GPU-wise and CPU-wise (and memory-wise, for that matter).
Given what is public of the WiiU and some deductive skills, it seems the Ouya will also beat the WiiU's CPU (which looks like it'll be underpowered), particularly at SIMD/vector processing. It probably won't beat its GPU (AMD R700), but not by too much. Given how mobile GPUs are developing, I'd expect them to catch up pretty soon.
There's one upside to newer console generations though: as consoles get more complicated, developers stick to APIs and don't do as much register-level fiddling or depending on things like hardware timing. That means that it's easier to perform higher-level emulation of newer consoles (as opposed to the cycle-accurate emulation often required to get good results for older 8-bit and 16-bit machines) and still have things work. Newer consoles are also more similar to a PC, which simplifies emulation.
For example, the Dolphin GC/Wii emulator managed to get pretty accurate graphics emulation in less time than PCSX2 because the GC/Wii's GPU is a lot saner and has a model that is relatively easy to map to OpenGL/DX, unlike the PS2's GPU and vector units which are horribly painful to emulate. The 360's and PS3's and WiiU's GPUs are pretty much bog-standard PC GPUs (which does mean they will be more complex to implement full emulation for, but at least it will map more easily onto standard graphics APIs). The higher-level software frameworks also make it easier to use high-level emulation for chunks of the system - e.g. Dolphin doesn't emulate the Starlet ARM CPU of the Wii, but instead performs high-level emulation of its APIs. Therefore, it gets away without emulating the USB, SD, WiFi, flash, and other hardware, which greatly simplifies the implementation and makes it more user-friendly.
It'll be challenging, but it's not an entirely dark future.
You don't "switch" to IPv6, you add IPv6. Nobody expects IPv4 to go away any time soon. What everyone's talking about is supporting IPv6 plus IPv4. So all your old sites work, but you can also reach any new hosts that have IPv6 addresses only directly, and get the benefits of avoiding NAT. Those hosts will likely be mobile customers at first, since that's one of the first places where ISPs are having to use v6. As for those users, they will be able to talk to IPv4 sites via DNS trickery and IPv6-to-IPv4 NAT, or just via plain old IPv4 NAT.
So you expect a virtual AVR running on Java running on a real ARM to be a 5x speedup over native code, even though your massively more powerful PC could barely manage 5x real time speed emulating the same AVR?
Sorry, that's not how it works.
Although it is theoretically possible for a very optimized emulator/dynamic translator to be faster at running poorly optimized native code on the same CPU than the actual CPU itself (by optimizing it), I'm not aware of any circumstances where something like this has actually been used in practice and been useful. And certainly not anything written in Java. The closest thing I've heard of were x86 emulators for Itanium beating the Itanium's built-in x86 support, but the emulators were of course translating to IA64, not to x86, so it doesn't count.
Where the form says “Comment number(s) of proposed classes of works to which you are responding,” enter a “3” if you’re writing about game consoles or a “5” if you’re writing about smartphones or tablets. You might consider also entering a "4" to submit your comments in support of an exemption request proposed by the Software Freedom Law Center to allow jailbreaking of "personal computing devices."
I am getting the impression that there is an "self.ip += 1" missing in the implementation of the jmp(e) when mod == 1.
You're right. The problem isn't the lack of "self.ip += 1" inside the condition (that would do nothing, as the branch target specifies the new value for self.ip anyway); the problem is that when a conditional branch with mod == 1 isn't taken, the second byte is executed as a new instruction instead of skipped. I guess this variant isn't used in the provided bytecode so it didn't break things.
I agree that code useful in the long term should be easy to read, but the chances of me wanting to go back to this code in the future are very, very slim, so I didn't bother with that aspect.
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).
Well... I do know someone who is capable of staring at an unknown, undocumented binary blob for a new/proprietary architecture and working out enough of the ISA to write a fairly comprehensive disassembler and then an emulator. Just by staring at the hex and making educated guesses as to what each opcode means, which he later refines as he makes sense of the program. How he can do that boggles the mind, but he can (I've seen him do it at least three times already).
I don't know if the intelligence agencies happen to employ anyone like him though.
Your experience has you quite biased towards these sorts of things. You only watched this video, I can tell, and didn't pay attention.
I solved stage 2 entirely on my own and reverse engineered enough of stage 3 to realize exactly what it was doing. I had glossed over stage 1 (after I realized it was x86 I just googled it and saw that others had solved it already) so I didn't immediately know about the unused instructions, but I did correctly guess that the "firmware" stuff from stage 2 was used for the second two 32-bit words in the URL.
Basically, I had no interest in playing the guessing game portions of the challenge, especially since I found out about it late and plenty of people had solved all of it already. I have no incentive to beat it entirely on my own: this isn't a contest and I already have a full-time job so I am not interested in applying; I was just curious to see what kind of problems they were and whether any of them were interesting to me.
In the disassembly for stage 3, the messages "loading stage x license key", when they clearly said you were on "stage 2 of 3", were good hints. The unused firmware bits were fairly obvious because they had the right size and served no other purpose, and the unused bytes from stage 1 were obvious after you get your mind on the "unused bits from each stage" track.
Of course it was obvious, but that doesn't make it interesting. This is the kind of problem that is testing no useful skill other than whether the player has been on the lookout for unused stuff that may or may not be useful later. That's not really how real life problems work. If something is used, there will be pointers to it in real applications. Reverse engineering isn't about pulling numbers from strange places and "trying to see if they work".
Mind you, some people enjoy this kind of puzzle. I'm just saying it's the wrong kind of puzzle.
And the VM part wasn't trivial. This guy did it in python, but it was intended to be done in javascript.
Why, because the file happened to end in.js? The only information in it was a memory array, a few constants, and comments. If, as a reverse engineer, you pick the language that you're "supposed to use" instead of the language that you prefer or which is most practical or useful in a given situation, you're doing it wrong. I played in a CTF once where we were given a Linux box running a few services, including one written in shell with a bunch of shell injection and path traversal vulnerabilities. I just rewrote it in Python: it was faster than trying to wrap my head around the existing shell code and its bugs, and I could easily guarantee that all of those holes were gone (and the service was simple enough that I knew there wouldn't be any unexpected exploitable problems). Fixing the original would've taken longer.
The implementation doesn't really matter, but understanding the bit fiddling needed to implement it is a valuable skill.
So they had people implement a VM in order to prove that they know how to shift and mask bits? The are a myriad other ways of doing that that don't involve a VM. If you're going to have a challenge based on a VM, it should be because you want the player to be able to understand a program written in a novel architecture and write their own disassembler, or something similar. The whole point of a VM in a security system is to obfuscate the code running on it - if you don't have to disassemble or understand that code to achieve your goal, then the VM has failed its purpose.
If you have the skills to disassemble, but not write anything more complicated than hello world, you're probably not useful to them.
If the intent is to test that the player can program, then it's still a much better challenge to provide the VM code and a description of the architecture, but still require th
It took me about 30 minutes using Python (why would you use JavaScript? The mind boggles.), but yes, I agree, the specification wasn't terribly clear especially if you've never worked with segmented memory. The jump instructions also are confusingly described as jumping to r2:r1 in the mod=1 version (it should be imm:r1). Personally, I quite dislike this memory model (and x86 in general), but I've had the "pleasure" of working with an embedded system integrating a 80186 core so I had a fairly good idea of what they look like.
Recognizing unknown architecture binaries is an important skill to have when reverse engineering, especially for embedded systems. Very often you'll get a firmware file and you have to figure out what it is. Each architecture has its peculiarities, so it doesn't take long to get a feeling for what their opcodes look like. For example, 32-bit ARM code sticks out like a sore thumb (no pun intended:) due to the condition code field, which means that every 32-bit word almost always starts with 0xEx (and whether that's the first or last byte in the word tells you the endianness). Variable length architectures like x86 look very different from RISC ISAs with a fixed instruction length like PowerPC.
Stage 3 isn't worth the effort. It's very little hacking/reverse engineering and mostly silly guesswork with no sensible sequence of steps to get there. Spoiler ahead:
The primary challenge is to guess what bits of stage 1 and stage 2 to stick into a URL (or a file which the exe then formats into a URL). You have to go back to stages 1 and 2 and fish out the most likely candidates for "3 32-bit numbers that do nothing and stick out like a sore thumb".
Slashdot Mirror
That's the root of the issue: that programming is seen in the same light as design and manufacturing, in other words, something that only professionals with years of training should do.
It's not. Most computer users could benefit from having some (very basic) programming knowledge. For example, my dad does software translation, and he doesn't really know much about "proper programming" (I did try, unsuccessfully, to get him to learn Python), but over the years he's worked with a number of scripting languages to automate parts of his job. These days, he tends to use AutoHotkey scripts, but a number of years ago he also used Windows analogs of shell scripting and sed to automate a number of tasks, including munging (ASCII-based) document formats in various ways. He understands the basics (variables, while loops, etc.) and can use them with a simple language to make his life (much) easier.
What could Joe Average Computer User do if he knew a bit about programming? For example, he could write a userscript to fix up a gripe in website that he visits frequently. Or write a batch file or shell script to automate a daily task. Or add some more complex logic to a spreadsheet. Or write a tool to organize his music collection in exactly the way that he wants it. Or write out a long mathematical calculation into a script so that he doesn't have to type it into a calculator over and over.
Keep in mind that the steepest part of the learning curve for an average person is figuring out the initial concepts (and the younger you start, the more likely it is that you'll "get it"). Once you know the basic constructs of computer languages, you can quickly pick up on any special-purpose language. Anyone who knows, say, Javascript (or any half-decent BASIC dialect for that matter) should be able to breeze through the Python tutorial.
Now, say, teaching Software Engineering to everyone would be a silly idea. Most people couldn't care less about MVC, or proper object-oriented design.
2K and 4K refer to the horizontal resolution. QuadHD/3840x2160p (which is what this is) is only slightly smaller than 4K horizontally, so it is often referred to as 4K (same with regular 1920x1080p and 2K).
Sadly, it has nothing to do with Flash (though Flash may well tear once everything else is fixed, but I don't care about Flash). Vsync is broken in various ways on Sandy Bridge and Ivy Bridge, both using a driver compiled with SNA enabled and not. Basically, any non-fullscreen video (or GL) will likely tear - and on a multihead display, fullscreen never happens (since "fullscreen" on on head is just a portion of the combined framebuffer). There's some attempt at vsync, since the tearing isn't random like on a completely unsynced display, but obviously it's not managing to do it correctly.
Running certain compositing window managers will "fix" this, especially dumber ones like compiz in a mode where they flip screen buffers every frame, effectively turning the whole desktop into a fullscreen GL window. However, that's not a real solution, and it doesn't work for saner window managers like KWin, which do partial screen updates. It also still doesn't work in multihead mode, because you can't do a fullscreen buffer flip synced across two different displays.
Actually, the upper layers of the Intel driver contain clever code that computes the overlap of a video/GL window with each display head, and syncs to the head with the highest overlap, which means tear-free video without having to specify which output to sync to via a control panel or environment variables (which was an annoyance with the nvidia blob driver). If only the underlying low-level sync mechanism actually worked, it would be perfect. It's the only gripe I have with the open drivers; everything else seems to work fine, but this issue really bugs me.
I actually did the math for the pressure variations in a small airtight room (3x3x3 meters), and came up with 5 microliters - that's the RMS delta volume of air that would be required to produce a sound pressure of 0dB for large wavelengths. At 40dB, that becomes half a mililiter, which should be achievable for a human, perhaps with the aid of a glass bottle. By blowing, though. Not with your vocal folds.
The ability to produce sound without a rigid airtight compartment depends on the inertia of air - this is why a speaker is able to compress air in front of it even though it is not connected to an airtight compartment (and also why speaker cabinets help; they effectively increase the apparent inertia of the air behind the speaker, making it harder for it to escape, thus increasing the amplitude of the pressure waves created). To produce a measurable SPL at 0.189Hz, a bare speaker cone would have to be very large and move a very large distance, because there is a very poor impedance match with the air at a frequency that low. In an airtight room, you could do with a smaller speaker placed between it and the outside, or equivalently, between it and an airtight compartment. The same concept applies to the human body: to produce a measurable SPL at that frequency without the aid of a rigid compartment (i.e. using your vocal folds), they'd have to move huge distances and be much larger. With an airtight compartment (blowing into a bottle or just compressing air in your lungs with your mouth closed) you can get away with a smaller system, but that's no longer using your vocal chords, and it requires an airtight room for efficient coupling. This is how rotary subwoofer works, which is probably the only currently practical way to reproduce audio in the 0Hz-10Hz range.
Put another way: what makes you think that his vocal folds can produce a higher SPL at 0.189Hz than simply waving your hand or breathing at that same frequency? The latter, although not particularly efficient, are certainly going to be more effective at creating very low frequency air pressure differences than the world's largest larynx.
I'm certainly not claiming that this man cannot produce fundamental tones (significantly) lower than most people, but when you go 8 octaves lower you need more than your voicebox, no matter how large or special, to produce pressure variations at a frequency that low.
Actually, we can all produce something resembling a pure "sound" at 0.189Hz. All you have to do is compress and uncompress air in your mouth (or lungs, or a bottle) at that rate. The small air volume variation (translating to a variation in the volume of your body) should be enough to produce a sound pressure level of a few decibels at that frequency, particularly if you're in a small airtight room.
I doubt Tim's voice, in practice, produces more energy at frequencies that low than the above method. More likely, the sound that he produces is pretty much entirely composed of harmonics (i.e. "clicks" at that rate, not a fundamental tone). The human voice just isn't capable of producing sinusoidal tones that low. Just listen to him (or anyone else with a deep voice) talk. His voice doesn't sound like a deep pure tone, it sounds like a deep growl (i.e. a series of higher frequency noises repeated at that rate).
For the record, you can get ARM SoCs that are almost entirely open - the TI OMAP series does a pretty decent job, and last I checked they have excellent open documentation. Sure, the PowerVR graphics crap is proprietary, but you don't have to use it - it's purely a coprocessor that renders to a framebuffer. The video output hardware is independent, open, and documented (i.e. the equivalent of an S3 VGA adapter).
Broadcom, though, is pretty much the antithesis of open documentation.
The GPU boots the Pi. Without the GPU blob, it won't run anything at all.
The reason for this, reportedly, is that the team responsible for that SoC at Broadcom is officially a GPU team, so in fact the GPU is the main processor, and the ARM core is tacked on to the side. You're basically running a fully proprietary processor and firmware that just so happens to run Linux on an ARM coprocessor.
It's Broadcom. Anyone who expected it to work flawlessly with Linux hasn't been following that company's past.
Sure, it'll mostly-work-with-bugs-and-binblobs-and-old-kernel-versions, just like anything else Broadcom. If people want better than that, they should've used an SoC vendor that is actually friendly to the open source community and publishes real documentation..
Actually, I'm of the opposite opinion for the same reason. I gave up on Amarok ever since 2.0, and I'm much more interested in Clementine releases. As soon as Clementine gets arbitrary labels ("tags" in the "web 2.0" sense) and fixes up their device support a bit (I'm particularly looking forward to the day MTP works smoothly with Android devices), it'll pretty much have covered all Amarok 1.4 features I cared for.
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.)
The Ouya is *significantly* more powerful than the Wii, both GPU-wise and CPU-wise (and memory-wise, for that matter).
Given what is public of the WiiU and some deductive skills, it seems the Ouya will also beat the WiiU's CPU (which looks like it'll be underpowered), particularly at SIMD/vector processing. It probably won't beat its GPU (AMD R700), but not by too much. Given how mobile GPUs are developing, I'd expect them to catch up pretty soon.
There's one upside to newer console generations though: as consoles get more complicated, developers stick to APIs and don't do as much register-level fiddling or depending on things like hardware timing. That means that it's easier to perform higher-level emulation of newer consoles (as opposed to the cycle-accurate emulation often required to get good results for older 8-bit and 16-bit machines) and still have things work. Newer consoles are also more similar to a PC, which simplifies emulation.
For example, the Dolphin GC/Wii emulator managed to get pretty accurate graphics emulation in less time than PCSX2 because the GC/Wii's GPU is a lot saner and has a model that is relatively easy to map to OpenGL/DX, unlike the PS2's GPU and vector units which are horribly painful to emulate. The 360's and PS3's and WiiU's GPUs are pretty much bog-standard PC GPUs (which does mean they will be more complex to implement full emulation for, but at least it will map more easily onto standard graphics APIs). The higher-level software frameworks also make it easier to use high-level emulation for chunks of the system - e.g. Dolphin doesn't emulate the Starlet ARM CPU of the Wii, but instead performs high-level emulation of its APIs. Therefore, it gets away without emulating the USB, SD, WiFi, flash, and other hardware, which greatly simplifies the implementation and makes it more user-friendly.
It'll be challenging, but it's not an entirely dark future.
Yes, it can (because PS2 disks, thankfully and unlike e.g. Wii ones, are readable as-is on a PC).
Making an image is probably a good plan though, if only for the reduced seek times.
You don't "switch" to IPv6, you add IPv6. Nobody expects IPv4 to go away any time soon. What everyone's talking about is supporting IPv6 plus IPv4. So all your old sites work, but you can also reach any new hosts that have IPv6 addresses only directly, and get the benefits of avoiding NAT. Those hosts will likely be mobile customers at first, since that's one of the first places where ISPs are having to use v6. As for those users, they will be able to talk to IPv4 sites via DNS trickery and IPv6-to-IPv4 NAT, or just via plain old IPv4 NAT.
So you expect a virtual AVR running on Java running on a real ARM to be a 5x speedup over native code, even though your massively more powerful PC could barely manage 5x real time speed emulating the same AVR?
Sorry, that's not how it works.
Although it is theoretically possible for a very optimized emulator/dynamic translator to be faster at running poorly optimized native code on the same CPU than the actual CPU itself (by optimizing it), I'm not aware of any circumstances where something like this has actually been used in practice and been useful. And certainly not anything written in Java. The closest thing I've heard of were x86 emulators for Itanium beating the Itanium's built-in x86 support, but the emulators were of course translating to IA64, not to x86, so it doesn't count.
From TFA:
Sounds like you want to support comment "4", which is the SFLC's attempt at getting *all* personal computer devices exempted.
You're right. The problem isn't the lack of "self.ip += 1" inside the condition (that would do nothing, as the branch target specifies the new value for self.ip anyway); the problem is that when a conditional branch with mod == 1 isn't taken, the second byte is executed as a new instruction instead of skipped. I guess this variant isn't used in the provided bytecode so it didn't break things.
I agree that code useful in the long term should be easy to read, but the chances of me wanting to go back to this code in the future are very, very slim, so I didn't bother with that aspect.
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).
Well... I do know someone who is capable of staring at an unknown, undocumented binary blob for a new/proprietary architecture and working out enough of the ISA to write a fairly comprehensive disassembler and then an emulator. Just by staring at the hex and making educated guesses as to what each opcode means, which he later refines as he makes sense of the program. How he can do that boggles the mind, but he can (I've seen him do it at least three times already).
I don't know if the intelligence agencies happen to employ anyone like him though.
I solved stage 2 entirely on my own and reverse engineered enough of stage 3 to realize exactly what it was doing. I had glossed over stage 1 (after I realized it was x86 I just googled it and saw that others had solved it already) so I didn't immediately know about the unused instructions, but I did correctly guess that the "firmware" stuff from stage 2 was used for the second two 32-bit words in the URL.
Basically, I had no interest in playing the guessing game portions of the challenge, especially since I found out about it late and plenty of people had solved all of it already. I have no incentive to beat it entirely on my own: this isn't a contest and I already have a full-time job so I am not interested in applying; I was just curious to see what kind of problems they were and whether any of them were interesting to me.
Of course it was obvious, but that doesn't make it interesting. This is the kind of problem that is testing no useful skill other than whether the player has been on the lookout for unused stuff that may or may not be useful later. That's not really how real life problems work. If something is used, there will be pointers to it in real applications. Reverse engineering isn't about pulling numbers from strange places and "trying to see if they work".
Mind you, some people enjoy this kind of puzzle. I'm just saying it's the wrong kind of puzzle.
Why, because the file happened to end in .js? The only information in it was a memory array, a few constants, and comments. If, as a reverse engineer, you pick the language that you're "supposed to use" instead of the language that you prefer or which is most practical or useful in a given situation, you're doing it wrong. I played in a CTF once where we were given a Linux box running a few services, including one written in shell with a bunch of shell injection and path traversal vulnerabilities. I just rewrote it in Python: it was faster than trying to wrap my head around the existing shell code and its bugs, and I could easily guarantee that all of those holes were gone (and the service was simple enough that I knew there wouldn't be any unexpected exploitable problems). Fixing the original would've taken longer.
So they had people implement a VM in order to prove that they know how to shift and mask bits? The are a myriad other ways of doing that that don't involve a VM. If you're going to have a challenge based on a VM, it should be because you want the player to be able to understand a program written in a novel architecture and write their own disassembler, or something similar. The whole point of a VM in a security system is to obfuscate the code running on it - if you don't have to disassemble or understand that code to achieve your goal, then the VM has failed its purpose.
If the intent is to test that the player can program, then it's still a much better challenge to provide the VM code and a description of the architecture, but still require th
It took me about 30 minutes using Python (why would you use JavaScript? The mind boggles.), but yes, I agree, the specification wasn't terribly clear especially if you've never worked with segmented memory. The jump instructions also are confusingly described as jumping to r2:r1 in the mod=1 version (it should be imm:r1). Personally, I quite dislike this memory model (and x86 in general), but I've had the "pleasure" of working with an embedded system integrating a 80186 core so I had a fairly good idea of what they look like.
If you want a steganography challenge (with a twist), try this, from this year's Hack-It ;)
Recognizing unknown architecture binaries is an important skill to have when reverse engineering, especially for embedded systems. Very often you'll get a firmware file and you have to figure out what it is. Each architecture has its peculiarities, so it doesn't take long to get a feeling for what their opcodes look like. For example, 32-bit ARM code sticks out like a sore thumb (no pun intended :) due to the condition code field, which means that every 32-bit word almost always starts with 0xEx (and whether that's the first or last byte in the word tells you the endianness). Variable length architectures like x86 look very different from RISC ISAs with a fixed instruction length like PowerPC.
Stage 3 isn't worth the effort. It's very little hacking/reverse engineering and mostly silly guesswork with no sensible sequence of steps to get there. Spoiler ahead:
The primary challenge is to guess what bits of stage 1 and stage 2 to stick into a URL (or a file which the exe then formats into a URL). You have to go back to stages 1 and 2 and fish out the most likely candidates for "3 32-bit numbers that do nothing and stick out like a sore thumb".