The first time I read the headline it said "Software Developer says MegaMan Master keys are Retrievable" so I thought it in regards to was some kind of ROM DRM. Second time I read it, it said "Software Developer says Sega Mega Keys are retrievable". So I googled Sega Mega only find that the Sega Genesis (or some variation) was marketed with that name in some parts of the world. This made some sense, although didn't really seem to belong in YRO. Is my mind deteriorating faster than I expected or is the Illuminati **cking with me?
That statement seemed pretty silly given that most applications will be to transcode the encrypted stream into something more portable, and transcoding doesn't have to be in real time.
Too early to tell what "most applications" will be.
I bet only the kooks who made the forums so awful in the first place will pay the fee. They'll be the only ones with enough motivation to pay the money for the privilege of commenting.
Don't use use your personal assets for work. Beyond the trouble you're already experiencing, it causes other problems: it prevents management from understanding the total cost of IT operations; it's likely to create unrealized dependencies on personnel (which will be realized upon their departure or transfer); and it complicates the creation of Disaster Recovery and Continuity of Operations plans.
The measures your hospital is taking may be draconian, but in the face of countless new articles trumpeting that latest XYZ agency/company/government who lost a laptop with account records full of very personal and very accessible information, it's understandable. It's very, very difficult for a corporation to maintain appropriate level of control over their own mobile assets. It's an unsolved problem, and to me at least, not obviously solvable without substantial changes to the underlying operating system and communication technology. (And then, will the resulting Internet be open, extensible, and autonomous like the one we have today?) But I digress...
If the system isn't bootable, and you have the right drive controller, carefully connect the old drive to a new system and use something like "ddrescue" ( http://www.forensicswiki.org/wiki/Ddrescue) or "dd_rescue" ( http://www.forensicswiki.org/wiki/Dd_rescue) to take a disk image. Both those programs try to recover from bad blocks, whereas standard dd usually will error out. (Personally, I'd make an image even if the system is bootable.)
With the disk image extracted, you can pack the hardware away or do whatever with it. Then you can focus on finding (or writing) tools to read the disk image. If you find that there is a Linux filesystem driver, you can use the loopback behaviour (see the man pages for "mount" or "losetup") to treat the disk image as if it were a drive. If you don't find a driver, perhaps you'll find some specialty command-line tools that can extract information, or documentation to write your own. At worst, you could use the "strings" command to read any text found on the image. Since you're working against an image, you can take your time, experiment with ad hoc techniques, make mistakes (remember to make backups), and try again and again.
There's a job sometimes called System Engineering that you might like. At its simplest, it deals with gathering, understanding, organizing, and solving customer requirements. The type of problem solving involved lies along the lines of figuring out the best prioritization of potentially conflicting concerns (e.g. size vs performance vs cost vs supportability vs logistics vs vs vs VS!!!! oh it's so maddening.)
A lot of software-only houses typically expect the programmers to also do the system engineering so the distinction is not always clear. (In fact, the Agile/Extreme Programing crowd get mad if you talk about system engineering and requirements, but in fact they're doing system engineering too, just in a way that is arguably more appropriate for rapid software development.)
But there are a lot things in this world that need to be built which include but are not limited to software: aircraft, military systems, factories, robotics, militarized flying robot factories, etc. Basically, it it used in the development of any complex system, whether or not it's called System Engineering. Being a System Engineer with a CS background is very valuable, because you better understand what's important, say, to define as a a managed interface within a software architecture, and what to leave to the software developer to solve according to the performance requirements.
System engineering can eventually lead into System Design (often called System Architecture, but that's insulting to real Architects, and illegal to represent yourself as one in Texas).
In general, no employer will start a new college hire as a designer, because they'll want you to have the experience of implementing someone's design first By the same token, system engineers aren't the only ones who go on to be System Designers. Any experienced engineer, including programmers, find it a legitimate career aspiration in, say, the second decade of their careers.
For some applications, I find it useful to look at how the app makes use of system calls, via `strace' for most Unixen or `truss' on Solaris or `ktrace' Mac OS X. (I don't know of a similar tool for MS Windows.) strace and it's ilk show what system calls the app makes into the operating system, including decoded arguments and results. The basis for these tools is the `ptrace()' system call.
Analysis at the application/OS boundary isn't as generally useful a technique as having a good debugger or other source code analysis tools, but can be useful in certain circumstances. It may be a good starting point to understanding unfamiliar code since it shows you exactly how the application interacts with the outside world. It bypasses the indirection/obfuscation that comes from OO languages or interpretters/VMs, and can let you know what to look for when you start diving into the code. Among other things, it can help you figure out useful breakpoints to use in subsequent source-level debugging.
Also, if you're in a situation where you don't even know how to run the application (due to absence of documentation), looking at the app/OS boundary can show you what the app is trying to do (e.g. connect to a server, find a config file, etc).
It can help you understand the overall of behaviour of an application, esp. if that application is a daemon, service, or other semi-autonomous or agent-like piece of software. Using it on GUI intensive apps can be painful because you end up seeing a lot of low-level drawing routines (for example, the ultimate result of using GTK/QT/Xlib/X11 are a bunch of calls to the X server via shared memory, and are unintelligible to mere mortals).
All that said, strace is probably a better troubleshooting tool than discovery tool, and it certainly requires that you understand Unix/Posix APIs (or at least know how to read man pages). Better said, strace is good for understanding how a strange or malfunctioning application works, and thus is a useful starting point when trying to understand strange or malfunctioning source code.
I've used a similar tool called `ltrace', which intercepts calls into libraries, but I've found a good source level debugger to subsume and exceed its value most of the time.
Slashdot Mirror
The first time I read the headline it said "Software Developer says MegaMan Master keys are Retrievable" so I thought it in regards to was some kind of ROM DRM. Second time I read it, it said "Software Developer says Sega Mega Keys are retrievable". So I googled Sega Mega only find that the Sega Genesis (or some variation) was marketed with that name in some parts of the world. This made some sense, although didn't really seem to belong in YRO. Is my mind deteriorating faster than I expected or is the Illuminati **cking with me?
Oh boy, instead of buying a $US0.50 stylus, I can buy a $US20.00 pair of gloves!
That statement seemed pretty silly given that most applications will be to transcode the encrypted stream into something more portable, and transcoding doesn't have to be in real time.
Too early to tell what "most applications" will be.
I bet only the kooks who made the forums so awful in the first place will pay the fee. They'll be the only ones with enough motivation to pay the money for the privilege of commenting.
Instigate a revolution, successfully overthrow the government, and instate a new government with more liberal social policies.
Once the power comes back on, and telecommunication services have recovered (and reconfigured) enjoy free western-style Internet access!
McAfee Stinger
http://vil.nai.com/vil/stinger/
Does even 1% of the population know or care if someone steals your car?
Does Cisco care that their IOS product name is being infringed? I don't think the USPTO differentiates case.
Nice to see that America’s elected officials can be culturally aware while remaining ignorant and ironic at the same time.
Don't use use your personal assets for work. Beyond the trouble you're already experiencing, it causes other problems: it prevents management from understanding the total cost of IT operations; it's likely to create unrealized dependencies on personnel (which will be realized upon their departure or transfer); and it complicates the creation of Disaster Recovery and Continuity of Operations plans.
The measures your hospital is taking may be draconian, but in the face of countless new articles trumpeting that latest XYZ agency/company/government who lost a laptop with account records full of very personal and very accessible information, it's understandable. It's very, very difficult for a corporation to maintain appropriate level of control over their own mobile assets. It's an unsolved problem, and to me at least, not obviously solvable without substantial changes to the underlying operating system and communication technology. (And then, will the resulting Internet be open, extensible, and autonomous like the one we have today?) But I digress...
If the system isn't bootable, and you have the right drive controller, carefully connect the old drive to a new system and use something like "ddrescue" ( http://www.forensicswiki.org/wiki/Ddrescue) or "dd_rescue" ( http://www.forensicswiki.org/wiki/Dd_rescue) to take a disk image. Both those programs try to recover from bad blocks, whereas standard dd usually will error out. (Personally, I'd make an image even if the system is bootable.)
With the disk image extracted, you can pack the hardware away or do whatever with it. Then you can focus on finding (or writing) tools to read the disk image. If you find that there is a Linux filesystem driver, you can use the loopback behaviour (see the man pages for "mount" or "losetup") to treat the disk image as if it were a drive. If you don't find a driver, perhaps you'll find some specialty command-line tools that can extract information, or documentation to write your own. At worst, you could use the "strings" command to read any text found on the image. Since you're working against an image, you can take your time, experiment with ad hoc techniques, make mistakes (remember to make backups), and try again and again.
There's a job sometimes called System Engineering that you might like. At its simplest, it deals with gathering, understanding, organizing, and solving customer requirements. The type of problem solving involved lies along the lines of figuring out the best prioritization of potentially conflicting concerns (e.g. size vs performance vs cost vs supportability vs logistics vs vs vs VS!!!! oh it's so maddening.)
A lot of software-only houses typically expect the programmers to also do the system engineering so the distinction is not always clear. (In fact, the Agile/Extreme Programing crowd get mad if you talk about system engineering and requirements, but in fact they're doing system engineering too, just in a way that is arguably more appropriate for rapid software development.)
But there are a lot things in this world that need to be built which include but are not limited to software: aircraft, military systems, factories, robotics, militarized flying robot factories, etc. Basically, it it used in the development of any complex system, whether or not it's called System Engineering. Being a System Engineer with a CS background is very valuable, because you better understand what's important, say, to define as a a managed interface within a software architecture, and what to leave to the software developer to solve according to the performance requirements.
System engineering can eventually lead into System Design (often called System Architecture, but that's insulting to real Architects, and illegal to represent yourself as one in Texas).
In general, no employer will start a new college hire as a designer, because they'll want you to have the experience of implementing someone's design first By the same token, system engineers aren't the only ones who go on to be System Designers. Any experienced engineer, including programmers, find it a legitimate career aspiration in, say, the second decade of their careers.
For some applications, I find it useful to look at how the app makes use of system calls, via `strace' for most Unixen or `truss' on Solaris or `ktrace' Mac OS X. (I don't know of a similar tool for MS Windows.) strace and it's ilk show what system calls the app makes into the operating system, including decoded arguments and results. The basis for these tools is the `ptrace()' system call.
Analysis at the application/OS boundary isn't as generally useful a technique as having a good debugger or other source code analysis tools, but can be useful in certain circumstances. It may be a good starting point to understanding unfamiliar code since it shows you exactly how the application interacts with the outside world. It bypasses the indirection/obfuscation that comes from OO languages or interpretters/VMs, and can let you know what to look for when you start diving into the code. Among other things, it can help you figure out useful breakpoints to use in subsequent source-level debugging.
Also, if you're in a situation where you don't even know how to run the application (due to absence of documentation), looking at the app/OS boundary can show you what the app is trying to do (e.g. connect to a server, find a config file, etc).
It can help you understand the overall of behaviour of an application, esp. if that application is a daemon, service, or other semi-autonomous or agent-like piece of software. Using it on GUI intensive apps can be painful because you end up seeing a lot of low-level drawing routines (for example, the ultimate result of using GTK/QT/Xlib/X11 are a bunch of calls to the X server via shared memory, and are unintelligible to mere mortals).
All that said, strace is probably a better troubleshooting tool than discovery tool, and it certainly requires that you understand Unix/Posix APIs (or at least know how to read man pages). Better said, strace is good for understanding how a strange or malfunctioning application works, and thus is a useful starting point when trying to understand strange or malfunctioning source code.
I've used a similar tool called `ltrace', which intercepts calls into libraries, but I've found a good source level debugger to subsume and exceed its value most of the time.