Daemon Worshiper !
Hello all ,
I'm proposing an implantable system that uses
loadable kernel modules to interface with an FPGA . I'm calling this system "Daemon Worshiper" . The basis of this system is a stripped down custom distribution of Linux with custom drivers that interact directly with modules on an FPGA . The FPGA is used to provide high speed processing of real-time and deterministic data realized in a re-programmable hardware design .This system architecture should allow for co-processing of more CPU intensive data like cryptography engines and real-time processing of bio-feedback data on a relatively low power CPU . Forgive me for the lack of technical detail , but I am learning a lot as I undergo my research so what I'm presenting is more of an underlying vision . The FPGA will contain a module that is responsible for loading and unloading additional modules and creating buses between the modules for inter-module DMA , where appropriate . The CPU will be responsible for synthesizing the module bit-files to load onto the FPGA .
I'm proposing an implantable system that uses
loadable kernel modules to interface with an FPGA . I'm calling this system "Daemon Worshiper" . The basis of this system is a stripped down custom distribution of Linux with custom drivers that interact directly with modules on an FPGA . The FPGA is used to provide high speed processing of real-time and deterministic data realized in a re-programmable hardware design .This system architecture should allow for co-processing of more CPU intensive data like cryptography engines and real-time processing of bio-feedback data on a relatively low power CPU . Forgive me for the lack of technical detail , but I am learning a lot as I undergo my research so what I'm presenting is more of an underlying vision . The FPGA will contain a module that is responsible for loading and unloading additional modules and creating buses between the modules for inter-module DMA , where appropriate . The CPU will be responsible for synthesizing the module bit-files to load onto the FPGA .
Tagged:
Comments
AuralFeedBack : Audio feedback using E-Speak or similar voice synthesis software will allow for command-line output to be echoed back to the user via Bone Conductance Speaker or external speaker with Bluetooth interface .
ActiveAuralCommand : System commands can be executed through vocal input via external mic with Bluetooth interface and processed by Blather or other voice recognition software . GarethTheGreat has suggested sub-vocal recognition through an EMG (Electromyographic) input for similar functionality , though the effect of Gareths system is far more impressive as it gives the impression of reading your mind . The only downside is that Gareths system may be more CPU intensive .
MyoLink : System commands can be executed using sign language input through an external(or internal) EMG (electromyographical) BlueTooth interface and is processed using available EMG sign language translation libraries such as the project currently being worked on at the University of Wisconsin . To limit the complexity and size of library , signs would be limited to alpha-numeric signs and a few marco signs .
Dead : A deadman switch is implemented by monitoring body temperature through the internal temperature monitor , once the body temperature falls below a configurable threshold (anecdotally around 70°F) for a predetermined period of time the user is assumed to have expired whereupon a customizable shell script is executed . A script would generally inform next of kin of death via SMS over GMS or other available network(WIFI , WIMAX) , additionally a will and testament can be sent to a lawyer and or next of kin . The user may also want to send orders to a doctor with instructions for cryopreservation (Another great idea by GarethTheGreat ;) Other tasks may include informing first responders and or law enforcement of GPS location of the users corpse using information gathered from the GPS and sent via SMS over GMS , WIFI , or WIMAX . Traditional deadman's switch tasks may include : Wiping disks , system self-destructing , or clearing browser history .
Lost : Lost is a navigation system that creates waypoints using GPS data , the data is then translated into vectors . Information from gyroscope/compass module are used to point the correct direction of travel using the LED subdermal heads up display (HUD) the cardinally configured leds (North , East , South , West) light from red to green to indicate direction of travel . While the LED HUD is in navigation mode the auxiliary indicator is used to indicate the magnitude of travel changing color from red to green as the waypoint is approached .
Cyborg Detector : The cyborg detector is standardized a protocol used to detect other transhuman/cyborgs in a local area . Beacons are sent at set intervals while a cyborg is on the grid (broadcasting beacons/”On the line”) . Beacon frames may contain information such as cyborg name(ESSID) , GPS information , system architecture , etc . Users can then send data using UDP as suggested by GarethTheGreat . Secure communication can be be established by exchanging encryption keys(SHA) via physical handshake whereupon keys are read from RFID implants . Special information stored on RFIDs can be parsed by cyborg detector program to add cyborg contact into contact book . Exact protocol information is forthcoming GarethTheGreat and I need to work on this .
Liar : The Liar program uses voice stress and speech pattern analysis algorithms to detect the likelihood that someone is lying while in lie detection mode auxiliary LED HUD indicator will light from green to red to indicate , red indicating high likelihood that someone is lying . Additionally a training program using EEG input generates a tone in a phase locked loop will help train a cyborg/agent to lie convincingly on a lie detection test EEG . Note training undergone using this method will not train an agent to pass GSR(Galvanic Skin Response , Sweating )
Bug Detector : Using SDR(Software Defined Radio) implemented on FPGA using GNURadio a basic radio spectrum analyser is used to detect radio transmissions (optionally) generally used for law enforcement or covert surveillance . Any other Kind of radio transmissions could also be filtered and detected (WIFI , AM , FM , Ham Radio) .
Crypto :CPU intensive cryptographic functions can be carried out on hardware accelerated cryptography module implemented on the systems FPGA . Crack : The crack submodule can be used to speed up cracking of WAP and WPA passwords on systems with limited CPU power .RFID : The combination of synthesized hardware and additional external hardware should allow for field reprogramming and copying of RFID data .
This is basically a conceptual design, we need more practical implementation details.
Also, I never said anything about sending stuff to a doctor in case of death - I suggested only that it could work as an alarm system as there are false positives, it would not be appropriate to send a will etc.
Using link local addressing and an ad-hoc wifi network will get you a lot.
Bug detector: I played with this a while back. Your method is much more advanced. I was going to try to use a heterodyne to detect transmissions in 40MHz-4Ghz. I was trying not to involve software. Ideally, I wanted to be able to do a "hotter/colder" thing so I could locate the transmitters nearby.
Liar: I've messed with voice stress analysis and have been disappointed overall. I think it could be really valuable if paired with voice recognition and machine learning to catalog instances with individual subjects and improve accuracy of detection on a person by person basis. I assume this will involve a lot of processing, programming, etc., but it might be worthwhile. It doesn't require skin contact, which is nice.
Aural command: @BenBeezy has an implant he is working on with a mic. He will be testing it later this month-ish. I was working on a contact mic that could probably be used to do this too, if implanted where the clavicles meet perhaps.
Dead: I have a general distress beacon concept I've been bouncing off of a few people with similar features. In addition to the ones you listed, it would utilize (in the US) the text to 911 system. The system would also be designed to grab all device ids in the area which can be used as a witness/suspect list. So where we are kind of stuck is how to transmit the info. WiFi? Hopefully you are connected. Cellular (bluetooth to mobile?)? Hope you have coverage and your device is on and near you at the time of distress. There are cons to both. I'm not familiar with WIMAX so I'll look that up.
Myolink/Lost: Grindhouse's Northstar can be used to indicate direction just with subdermal LEDs. Same device can do gesture recognition if you didn't want to go myoelectric. I look forward to using it as a main way to interface with other devices.
This probably helps you out zero.
Shine The reason I thought of using temperature over pulse was because I thought it may be easier to implement subliminally . Part of what I want to achieve is a completely contained system with few external elements , though I supposed exo-elements could be traded off in lieu of internal ones for greater accuracy .
DirectorX , thanks for all of the great info , it's all very helpful . It's good to know that other people in the community are working towards similar goals , which affords a great opportunity for collaboration and sharing data .
I really like the idea of a witness list for the distress beacon . Transmitting that info is a problem because we can never assume any kind of connectivity whatsoever , so by providing as many options as possible may help to alleviate that problem .