> In the 40s and 50s you "needed" to get a (land line) phone, then it was cars, email, and now cell phones. What's next?
It's not about keeping up just for keeping up's sake; it's new technologies that are useful and become part of most peoples' lives. To explain, let's go back in history... these things were all new-fangled at one time, but now, even though some people live without them, seem pretty "essential":
- 4 walls and a water-proof roof. - clean water, delivered to your faucet. - sanitation system - sewer, garbage, etc. - health insurance, vacinations for diseases you don't even have yet! - 911, police, and fire services - a legal system, property ownership - currency, bank accounts, lending, credit cards - a regular job (as opposed to self-empolyed farmer/blacksmith/etc. and directly bartering your skills with others) - prerecorded music, books. - transportation (taxi, rail, plane, boat, postal system) - automation (copy machines, computers)
The vast majority of us integrate these into our lives because we feel they have value that exceeds their costs, and not just to keep up.
1 TB at 923 Mb/sec is 144 minutes of transfer, or almost 2 and a half hours. Still far longer than I would want to be uploading data at this rate for. But, it will be cool to download a RH ISO in 5.5 seconds (if only my hard drive could keep up!)
Slashdot needs an edit function. I proofread it before submitting, but obviously not well enough.
I worked for an employer that a lot of people who had worked overtime, found out that they were wrongly classified as salaried, and now needed to be paid extra to make things legal. Rather than pay straight time-and-a-half, they offered a complicated formula that offered less and less money for each hour beyond 40 worked per week. They were thinking that we were less productive after 40 hours, and thus were worth less (personally, after 40 hours, my time becomes more valuable, regardless of my productivity). Anyway, we reduced their obfuscated formula to a simple parabolic equation and found that the peak was at 80 hours/week. If you worked 81 hours, you'd get paid less than if you worked 80. We had had a crunch time (in satellites, it's called "space chicken" where the rocket people and the payload people both bluff saying that they'll meet the deadline, hoping to put the costly blame on the other), and, sure enough, people were sleeping over and working > 100 hours/week. The company never thought anyone would ever do that!
Unfortuantly, it seems that the laws of supply & demand don't help here and depresses game testers' salaries. I wonder what their overtime-pay situation is; it doesn't look too good.
I worked for an employer that found that a lot of us had worked overtime and now needed to be paid. Rather than pay straight time-and-a-half, they empolyer offered a complicated formula that offered less and less money for each hour worked after 40 per week. They were thinking that we were less productive after 40 hours, and thus were worth more (personally, after 40 hours, my time becomes more valuable, regardless of my productivity). Anyway, we reduced their math to a simple parabolic equation and found that the peak was at 80 hours/week. If you worked 81 hours, you'd get paid less than if you worked 80. We had had a crunch time (in satellites, it's called "space chicken" where the rocket people and the payload people both bluff saying that they'll meet the deadline, hoping to put blame on the other), and, sure enough, we had people sleeping over and working > 100 hours/week. The company never though anyone would ever do that!
Unfortuantly, it seems that the laws of supply & demand don't help here and depresses game testers' salaries. I wonder what their overtime-pay situation is; it doesn't look too good.
Actually, even checking all of the compiled code can't guarantee a back door. Check out this incredible article. You've got to have either:
- a chain-of-custody for every tool that touches your code (compiler/linker/OS, and the compiler that compiled the compiler/linker/OS, and so on) that's known back-door free.
- a thorough investigation of the executable code on a different (known back-door free) system.
It's tough, but to be totally safe you have to ensure that an undetected virus isn't in your tools.
Different compainies actually make dell's notebooks... The Inspiron 5000 (which is similar to the 7000 and 7500) is made by compal, while your Latitude was made by Quanta. That's got to be quite a problem for Dell... you'll only hear the horror stories from the worst notebook they sell. Personally, my PII Inspiron is still going great after 5 years... I cleaned/jiggled the backlight inverter board to fix an intermittent outage, and replaced a broken hinge (It's stood up very well to the abuse I give it!), and it still works like new!
Another method to detecting an executable that contains hidden data is to work out whether the executable uses the most unusual method of implementing its assembly.
You're very close with your second paragraph -- this is basically the correct answer, but I'll just clarify it a bit:
Compilers usually mark the executable with their name. I know GCC does this; I'm pretty sure it's part of the ELF standard. Knowing this, you can tell what code would be generated by the compiler and/or linked-in libraries; any other code in these regions would indicate tampering. Two examples:
1. Check all library functions, including startup/exit and DLL-load functions. If these functions are different, then you've found a steg. Of course, some of these functions (usually those not in pure assembly) will change with compiler versions, so there are multiple non-steg possibilites.
2. Check the function start-up code. If, for example, a compiler adjusts the stack by subtracting a fixed value, then if you ever see it add the negative value here you found a steg. This is so simple, it's unlikely to change between compiler versions.
You could also check the above two regions for self-consistancy. If the function-start code varies between functions, then maybe you've found the steg.
The big exception here is when code from different compilers is linked together. This usually happens only when you've got a closed source library. Summary: "unusual" is easy to detect for a given compiler.
Oops, I forgot that part! I was thinking of the built-in support of BASIC - "ab" + "cd" = "abcd" and its keywords (not library functions) like MID$ and LEN. I was thinking of how C makes no distinction between a pointer to a single character and a pointer to a null-terminated string.
Yeah, there are no goto's, but there is every other kind of structured branch statement: for/while/do-while/continue/break/return. Most C programmers get by with only these (although a do-while-repeat loop would be helpful), and some don't even know that C has a goto.
Pointers aren't supported (just like in java and Fortran), and I suspect the reason for that is that pointer aliasing can only be detected at runtime, so a lot of very useful compiler optimizations can't be done. In fact, that's why a lot of super-computer applications still use fortran (besides the large existing math library base). Graphics rendering is speed-oriented, and in a special-purpose language like this, it's a good tradeoff.
GLSlang has a lot of functions built-in (like texture lookups, vectors, and matricies) for things you may want to use pointers for. The benefit of supporting them natively is that they can be hardware-optimized extremely well. One cool thing that Cg does (and it appears that GLSlang does, too) is allow floating point indicies into texture-maps -- the inbetween position is automatically interpolated.
Also, for the record, C doesn't have strings, either. The only string support is in libraries; not natively.
If you're willing to step away from a pc-architecture, you can one heck of a video card from sgi. Some cool features:
- drives up to 8 displays at once - up to 80GB frame buffer, 8GB texture memory, 65 Megapixel resoultion, and 8 pipelines. - 48 bit RGBA - wicked fast with lots of hardware acceleration
Good thinking. I know you acknowledges this already, but it's far worse than you mention: I ran the numbers a bit, and assuming a 10 pound bowling ball, that 'bolt' would have to weigh only 53mg to have the same KE.
Using a density of steel of 7.87g/cc, that would be 6.775 mm^3. or 1mm x 1mm x 6.775mm: about the size of the sheath on the end of my mechanical pencil.
Or about the size of the tiniest bolts in my watch.
Or, probably the size of that paint flek -- we certainly can't tell from that awful picture because there is no sense of scale!
ASICs are much faster, and if you're going to throw a lot of horsepower at brute-forcing a problem, then a low-volume ASIC run is a better. Here's the EFF's DES cracker, which used ASICs. If you want to crack DES, you can use the mask sets they've paid for. Or, you can use upcoming one-mask technology that allows you to build a mostly-custom chip at 1/10 the cost.
Actually, that's pretty funny! Exactly not the type of attention I'd like to attract. Maybe just one flash per 30 seconds, so hopefully it gets triggered when they are far away, and then they pass me before it can be retriggered. Thanks.
I've seen that, too. It was pretty neat, but is more visible to cops. Plus, it wouldn't help if the license plate cameras are mounted directly over the traffic lanes (like near the stoplights) so they would see a head-on picture. For flash-activated cameras, you can always put a flash slave next to the license plate so that when your picture is taken, the secondary flash at the plate also illuminates, overexposing the plate and making it unreadable.
Someone had a solution for this... A pair of LCD shutters for the license plate, each covering half of the digits. They turn on and off rapidly (so it wouldn't be too noticable to the eye) and exactly out of sequence. Thus, any photograph taken with a reasonably short exposure would capture only of the plate. A video camera would capture the whole plate on successive frames, but no single frame would have the entire plate number. Thus, the OCR would fail.
A spinning fan in front of the plate would also do the trick, but might take off someone's fingers.
Yeah, I drooled over this, too. Even though this dev board has just one PPC, there are others with 4.
But then I found out that the PPC cores are very slow relative to state-of-the-art standalone processors - its in the range IIRC 266-366 MHz each. Even multipling by 4 and it doesn't fare well compared to 1 GHz PPC's. Xilinx explained that the process they were using just didn't allow for fast processors, so I doubt they'll ever catch up.
What I'd like to see is a 1 GHz 4-PPC core with either no programmable logic or just a little (enough to implement some simple communications fabric and maybe a little left over for a simple coprocessor).
But, that's just me. This would be more sellable to my old company, which used a Virtex II and a discrete PPC. This combo woould save some realestate (they had 2 Virtex's, 2 ppcs, and a whole lot of other big parts on a 6U VME card; it was crowded!!)
Check out this press release... he claims to have given the algorithm to Bill Gates, AT&T, HP, Intel, and DELL for cracking. I guess if the crypto community shuns him, then he should take it somewhere else.
I love how he subtly calls these people his peers (as if!), but even more masterful, the press release is on the AT&T website, so it looks like it has a bit of an endorsement. Of course, I think Bill Gates is the world's greatest cryptographer and Microsoft has by far the most secure products. (I'd bet microsoft has some very good cryptographers, but that's not the problem; they just have holes in their software).
Actually, you don't even need to crack it... you just have to mess it up. For example, you could combine 3 copies of the same song and hopefully lose the tracking info.
Thanks - that's a good analysis; I didn't realize that the number could be so high. But I still worry....
The aim is to track each time a record label, online retailer or distributor such as Microsoft's (NASDAQ:MSFT) MSN or Italian Internet service provider Tiscali (MI:TIS) sells a song in the form of a Web stream or download. (emphasis mine)
It's still tracking each sale, and by extension, each buyer. Also, they are charged for their ID's annually... that's either the licensing model (fixed number of ID's, yearly cost), or they expect to sell millions of ID's per year (which I'm not sure the music industry puts out millions of songs/format combinations per year).
Slashdot Mirror
> In the 40s and 50s you "needed" to get a (land line) phone, then it was cars, email, and now cell phones. What's next?
It's not about keeping up just for keeping up's sake; it's new technologies that are useful and become part of most peoples' lives. To explain, let's go back in history... these things were all new-fangled at one time, but now, even though some people live without them, seem pretty "essential":
- 4 walls and a water-proof roof.
- clean water, delivered to your faucet.
- sanitation system - sewer, garbage, etc.
- health insurance, vacinations for diseases you don't even have yet!
- 911, police, and fire services
- a legal system, property ownership
- currency, bank accounts, lending, credit cards
- a regular job (as opposed to self-empolyed farmer/blacksmith/etc. and directly bartering your skills with others)
- prerecorded music, books.
- transportation (taxi, rail, plane, boat, postal system)
- automation (copy machines, computers)
The vast majority of us integrate these into our lives because we feel they have value that exceeds their costs, and not just to keep up.
1 TB at 923 Mb/sec is 144 minutes of transfer, or almost 2 and a half hours. Still far longer than I would want to be uploading data at this rate for. But, it will be cool to download a RH ISO in 5.5 seconds (if only my hard drive could keep up!)
Slashdot needs an edit function. I proofread it before submitting, but obviously not well enough.
I worked for an employer that a lot of people who had worked overtime, found out that they were wrongly classified as salaried, and now needed to be paid extra to make things legal. Rather than pay straight time-and-a-half, they offered a complicated formula that offered less and less money for each hour beyond 40 worked per week. They were thinking that we were less productive after 40 hours, and thus were worth less (personally, after 40 hours, my time becomes more valuable, regardless of my productivity). Anyway, we reduced their obfuscated formula to a simple parabolic equation and found that the peak was at 80 hours/week. If you worked 81 hours, you'd get paid less than if you worked 80. We had had a crunch time (in satellites, it's called "space chicken" where the rocket people and the payload people both bluff saying that they'll meet the deadline, hoping to put the costly blame on the other), and, sure enough, people were sleeping over and working > 100 hours/week. The company never thought anyone would ever do that!
Unfortuantly, it seems that the laws of supply & demand don't help here and depresses game testers' salaries. I wonder what their overtime-pay situation is; it doesn't look too good.
I worked for an employer that found that a lot of us had worked overtime and now needed to be paid. Rather than pay straight time-and-a-half, they empolyer offered a complicated formula that offered less and less money for each hour worked after 40 per week. They were thinking that we were less productive after 40 hours, and thus were worth more (personally, after 40 hours, my time becomes more valuable, regardless of my productivity). Anyway, we reduced their math to a simple parabolic equation and found that the peak was at 80 hours/week. If you worked 81 hours, you'd get paid less than if you worked 80. We had had a crunch time (in satellites, it's called "space chicken" where the rocket people and the payload people both bluff saying that they'll meet the deadline, hoping to put blame on the other), and, sure enough, we had people sleeping over and working > 100 hours/week. The company never though anyone would ever do that!
Unfortuantly, it seems that the laws of supply & demand don't help here and depresses game testers' salaries. I wonder what their overtime-pay situation is; it doesn't look too good.
Actually, even checking all of the compiled code can't guarantee a back door. Check out this incredible article. You've got to have either:
- a chain-of-custody for every tool that touches your code (compiler/linker/OS, and the compiler that compiled the compiler/linker/OS, and so on) that's known back-door free.
- a thorough investigation of the executable code on a different (known back-door free) system.
It's tough, but to be totally safe you have to ensure that an undetected virus isn't in your tools.
Different compainies actually make dell's notebooks... The Inspiron 5000 (which is similar to the 7000 and 7500) is made by compal, while your Latitude was made by Quanta. That's got to be quite a problem for Dell... you'll only hear the horror stories from the worst notebook they sell. Personally, my PII Inspiron is still going great after 5 years... I cleaned/jiggled the backlight inverter board to fix an intermittent outage, and replaced a broken hinge (It's stood up very well to the abuse I give it!), and it still works like new!
Another method to detecting an executable that contains hidden data is to work out whether the executable uses the most unusual method of implementing its assembly.
You're very close with your second paragraph -- this is basically the correct answer, but I'll just clarify it a bit:
Compilers usually mark the executable with their name. I know GCC does this; I'm pretty sure it's part of the ELF standard. Knowing this, you can tell what code would be generated by the compiler and/or linked-in libraries; any other code in these regions would indicate tampering. Two examples:
1. Check all library functions, including startup/exit and DLL-load functions. If these functions are different, then you've found a steg. Of course, some of these functions (usually those not in pure assembly) will change with compiler versions, so there are multiple non-steg possibilites.
2. Check the function start-up code. If, for example, a compiler adjusts the stack by subtracting a fixed value, then if you ever see it add the negative value here you found a steg. This is so simple, it's unlikely to change between compiler versions.
You could also check the above two regions for self-consistancy. If the function-start code varies between functions, then maybe you've found the steg.
The big exception here is when code from different compilers is linked together. This usually happens only when you've got a closed source library. Summary: "unusual" is easy to detect for a given compiler.
Here's the manufacturer's product page with exactly what you'd think it looks like. And, yes, it looks a bit odd. Thanks for the text!
Oops, I forgot that part! I was thinking of the built-in support of BASIC - "ab" + "cd" = "abcd" and its keywords (not library functions) like MID$ and LEN. I was thinking of how C makes no distinction between a pointer to a single character and a pointer to a null-terminated string.
Yeah, there are no goto's, but there is every other kind of structured branch statement: for/while/do-while/continue/break/return. Most C programmers get by with only these (although a do-while-repeat loop would be helpful), and some don't even know that C has a goto.
Pointers aren't supported (just like in java and Fortran), and I suspect the reason for that is that pointer aliasing can only be detected at runtime, so a lot of very useful compiler optimizations can't be done. In fact, that's why a lot of super-computer applications still use fortran (besides the large existing math library base). Graphics rendering is speed-oriented, and in a special-purpose language like this, it's a good tradeoff.
For comparison, (and for the same reasons) nvidia's cg doesn't have goto's or pointers, either.
GLSlang has a lot of functions built-in (like texture lookups, vectors, and matricies) for things you may want to use pointers for. The benefit of supporting them natively is that they can be hardware-optimized extremely well. One cool thing that Cg does (and it appears that GLSlang does, too) is allow floating point indicies into texture-maps -- the inbetween position is automatically interpolated.
Also, for the record, C doesn't have strings, either. The only string support is in libraries; not natively.
If you're willing to step away from a pc-architecture, you can one heck of a video card from sgi. Some cool features:
- drives up to 8 displays at once
- up to 80GB frame buffer, 8GB texture memory, 65 Megapixel resoultion, and 8 pipelines.
- 48 bit RGBA
- wicked fast with lots of hardware acceleration
The london financial district was a target 7 years ago!
Good thinking. I know you acknowledges this already, but it's far worse than you mention: I ran the numbers a bit, and assuming a 10 pound bowling ball, that 'bolt' would have to weigh only 53mg to have the same KE.
Using a density of steel of 7.87g/cc, that would be 6.775 mm^3. or 1mm x 1mm x 6.775mm: about the size of the sheath on the end of my mechanical pencil.
Or about the size of the tiniest bolts in my watch.
Or, probably the size of that paint flek -- we certainly can't tell from that awful picture because there is no sense of scale!
I suggest ketchup with your hat.
ASICs are much faster, and if you're going to throw a lot of horsepower at brute-forcing a problem, then a low-volume ASIC run is a better. Here's the EFF's DES cracker, which used ASICs. If you want to crack DES, you can use the mask sets they've paid for. Or, you can use upcoming one-mask technology that allows you to build a mostly-custom chip at 1/10 the cost.
Actually, that's pretty funny! Exactly not the type of attention I'd like to attract. Maybe just one flash per 30 seconds, so hopefully it gets triggered when they are far away, and then they pass me before it can be retriggered. Thanks.
cunningly placed black bolts
I can see it now...
you see officer, I really don't want my license plate to fall off and injure someone, so that's why it's held down with 24 very large bolts.
I've seen that, too. It was pretty neat, but is more visible to cops. Plus, it wouldn't help if the license plate cameras are mounted directly over the traffic lanes (like near the stoplights) so they would see a head-on picture. For flash-activated cameras, you can always put a flash slave next to the license plate so that when your picture is taken, the secondary flash at the plate also illuminates, overexposing the plate and making it unreadable.
Someone had a solution for this... A pair of LCD shutters for the license plate, each covering half of the digits. They turn on and off rapidly (so it wouldn't be too noticable to the eye) and exactly out of sequence. Thus, any photograph taken with a reasonably short exposure would capture only of the plate. A video camera would capture the whole plate on successive frames, but no single frame would have the entire plate number. Thus, the OCR would fail.
A spinning fan in front of the plate would also do the trick, but might take off someone's fingers.
Here's a googled automatic license plate reader.
Yeah, I drooled over this, too. Even though this dev board has just one PPC, there are others with 4.
But then I found out that the PPC cores are very slow relative to state-of-the-art standalone processors - its in the range IIRC 266-366 MHz each. Even multipling by 4 and it doesn't fare well compared to 1 GHz PPC's. Xilinx explained that the process they were using just didn't allow for fast processors, so I doubt they'll ever catch up.
What I'd like to see is a 1 GHz 4-PPC core with either no programmable logic or just a little (enough to implement some simple communications fabric and maybe a little left over for a simple coprocessor).
But, that's just me. This would be more sellable to my old company, which used a Virtex II and a discrete PPC. This combo woould save some realestate (they had 2 Virtex's, 2 ppcs, and a whole lot of other big parts on a 6U VME card; it was crowded!!)
From this page, you can call up the inventer with technical questions:
Saul Backal - Meganet Corp.
818-757-3890
matrix@meganet.com
Reporters can call these people. Hey, if their professional email ends in "juno.com", they must be legit!
Kenny Spitler or Bernie Kiesel - Absolute Results Inc.
615/843-8710
Absoluteresults@juno.com
Check out this press release... he claims to have given the algorithm to Bill Gates, AT&T, HP, Intel, and DELL for cracking. I guess if the crypto community shuns him, then he should take it somewhere else.
I love how he subtly calls these people his peers (as if!), but even more masterful, the press release is on the AT&T website, so it looks like it has a bit of an endorsement. Of course, I think Bill Gates is the world's greatest cryptographer and Microsoft has by far the most secure products. (I'd bet microsoft has some very good cryptographers, but that's not the problem; they just have holes in their software).
Actually, you don't even need to crack it... you just have to mess it up. For example, you could combine 3 copies of the same song and hopefully lose the tracking info.
thanks; I learned something!
Thanks - that's a good analysis; I didn't realize that the number could be so high. But I still worry....
The aim is to track each time a record label, online retailer or distributor such as Microsoft's (NASDAQ:MSFT) MSN or Italian Internet service provider Tiscali (MI:TIS) sells a song in the form of a Web stream or download. (emphasis mine)
It's still tracking each sale, and by extension, each buyer. Also, they are charged for their ID's annually... that's either the licensing model (fixed number of ID's, yearly cost), or they expect to sell millions of ID's per year (which I'm not sure the music industry puts out millions of songs/format combinations per year).