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 . 

Comments

  • To give you a better idea of what is possible here are some ideas for potential modules :

    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 .

  • edited September 2015

    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 . 
  • Here is a crude system block diagram . Keep in mind that this diagram is only meant to show functional relationships and is in no way used to illustrate the physical layout .image
  • I'll repeat what I said on IRC:
    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.
  • Oh, you also misunderstood what I said about UDP: I suggested only using UDP broadcasts as a beacon, not for actual communication - just a "i'm here" type signal.

    Using link local addressing and an ad-hoc wifi network will get you a lot.
  • I thinking using your pulse instead of body temperature for the deadman switch would be better.
  • I have a lot to add here. I'll type something out later tonight.
  • edited September 2015
    I dig this and hope you do it. I've worked on some of these things with my limited skills, usually trying to tie it into audio output.

    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.
  • garethnelsonuk and you're right this is just a concept for the time being , which has yet to see any real world application . While I do plan on eventually having what I proposed worked out in the way shape or form , maybe even greatly scaled back , these are ideas for features to hopefully keep things fresh and exciting . Perhaps I have a backwards method of working , but over time I will have worked out what features can and can't be implemented by implementing them or failing to do so .
    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 .
  • This is the kind of thread I should be avoiding like the devil right now. This could easily suck up 6 months of my life.
  • I suggest that we follow the sayian blueprint and build from there
  • edited October 2015
    it sounds as though you want to build a smart arduino.   Or rather an array? There is already a fairly small single board computer that runs on linux and has low power consumption.  Has anyone worked with raspberry pi? The A+ model is smaller and a bit stripped down but its good.  Also, orange pi makes slightly larger models with integrated wifi.  If you havent seen it, it may be worth it to look into.  It could save the conceptual project time in breadboarding and design if it has what u require to make this happen.  Then u can spend more time on software development.

  • See my implantable edison project
  • That said though, the A+ looks like it could be another platform to add to a CyborgNet network.
  • I think this a great idea, and I'm all for it. The amount of change this could bring is massive, and in an awesome way. I do think there should be a feature for other users to be able to opt out of detection, in the event that they desire privacy.
  • Sure that is a possibility. Garethnelsonuk is actually doing great work implementing the actual code for the inter cyborg communication protocol. I've kind of been on hiatus because of work, current financial situation, and health problems.

Sign In or Register to comment.