Cheap and reliable Node.js hosting starts at $3/month, and $1/month static HTML hosting

Created with love in Canada, visit hostnodejs.com today

Feel like to post an Ad? Learn Details

aliasrobotics / Rsf

Licence: other

The Robot Security Framework (RSF), Robot Security Framework (RSF), a standardized methodology to perform security assessments in robotics.

Labels

security framework pentesting robotics penetration-testing cybersecurity

Projects that are alternatives of or similar to Rsf

Lockdoor Framework

🔐 Lockdoor Framework : A Penetration Testing framework with Cyber Security Resources

Stars: ✭ 677 (+790.79%)

Mutual labels: pentesting, penetration-testing, cybersecurity

Docker Security Images

🔐 Docker Container for Penetration Testing & Security

Stars: ✭ 172 (+126.32%)

Mutual labels: pentesting, penetration-testing, cybersecurity

Thecollective

The Collective. A repo for a collection of red-team projects found mostly on Github.

Stars: ✭ 85 (+11.84%)

Mutual labels: pentesting, penetration-testing, cybersecurity

A Red Teamer Diaries

RedTeam/Pentest notes and experiments tested on several infrastructures related to professional engagements.

Stars: ✭ 382 (+402.63%)

Mutual labels: pentesting, penetration-testing, cybersecurity

Oscp Pentest Methodologies

备考 OSCP 的各种干货资料/渗透测试干货资料

Stars: ✭ 166 (+118.42%)

Mutual labels: pentesting, penetration-testing, cybersecurity

Sn1per

Attack Surface Management Platform | Sn1perSecurity LLC

Stars: ✭ 4,897 (+6343.42%)

Mutual labels: cybersecurity, penetration-testing, pentesting

Gorsair

Gorsair hacks its way into remote docker containers that expose their APIs

Stars: ✭ 678 (+792.11%)

Mutual labels: pentesting, penetration-testing

Breaking And Pwning Apps And Servers Aws Azure Training

Course content, lab setup instructions and documentation of our very popular Breaking and Pwning Apps and Servers on AWS and Azure hands on training!

Stars: ✭ 749 (+885.53%)

Mutual labels: pentesting, penetration-testing

Awesome Oscp

A curated list of awesome OSCP resources

Stars: ✭ 804 (+957.89%)

Mutual labels: pentesting, penetration-testing

Sudomy

Sudomy is a subdomain enumeration tool to collect subdomains and analyzing domains performing automated reconnaissance (recon) for bug hunting / pentesting

Stars: ✭ 859 (+1030.26%)

Mutual labels: framework, pentesting

Phishing Frenzy

Ruby on Rails Phishing Framework

Stars: ✭ 643 (+746.05%)

Mutual labels: pentesting, penetration-testing

Pwncat

pwncat - netcat on steroids with Firewall, IDS/IPS evasion, bind and reverse shell, self-injecting shell and port forwarding magic - and its fully scriptable with Python (PSE)

Stars: ✭ 904 (+1089.47%)

Mutual labels: pentesting, penetration-testing

Active Directory Exploitation Cheat Sheet

A cheat sheet that contains common enumeration and attack methods for Windows Active Directory.

Stars: ✭ 870 (+1044.74%)

Mutual labels: pentesting, penetration-testing

Dirsearch

Web path scanner

Stars: ✭ 7,246 (+9434.21%)

Mutual labels: pentesting, penetration-testing

Evillimiter

Tool that monitors, analyzes and limits the bandwidth of devices on the local network without administrative access.

Stars: ✭ 764 (+905.26%)

Mutual labels: pentesting, penetration-testing

Spiderfoot

SpiderFoot automates OSINT for threat intelligence and mapping your attack surface.

Stars: ✭ 6,882 (+8955.26%)

Mutual labels: cybersecurity, pentesting

Walkoff

A flexible, easy to use, automation framework allowing users to integrate their capabilities and devices to cut through the repetitive, tedious tasks slowing them down. #nsacyber

Stars: ✭ 855 (+1025%)

Mutual labels: framework, cybersecurity

Eyes

👀 🖥️ Golang rewrite of eyes.sh. Let's you perform domain/IP address information gathering. Wasn't it esr who said "With enough eyeballs, all your IP info are belong to us?" 🔍 🕵️

Stars: ✭ 38 (-50%)

Mutual labels: pentesting, penetration-testing

Passhunt

Passhunt is a simple tool for searching of default credentials for network devices, web applications and more. Search through 523 vendors and their 2084 default passwords.

Stars: ✭ 961 (+1164.47%)

Mutual labels: penetration-testing, cybersecurity

Resources

A Storehouse of resources related to Bug Bounty Hunting collected from different sources. Latest guides, tools, methodology, platforms tips, and tricks curated by us.

Stars: ✭ 62 (-18.42%)

Mutual labels: pentesting, penetration-testing

View All Similar Projects ➔

The `Robot Security Framework` (RSF)

Robot Security Framework (RSF) is a standardized methodology to perform security assessments in robotics.

Version: 1.1

How to cite our work

@ARTICLE{2018arXiv180604042M,
   author = {{Mayoral Vilches}, V. and {Alzola Kirschgens}, L. and {Bilbao Calvo}, A. and
	{Hern{\'a}ndez Cordero}, A. and {Izquierdo Pis{\'o}n}, R. and
	{Mayoral Vilches}, D. and {Mu{\~n}iz Rosas}, A. and {Olalde Mendia}, G. and
	{Usategi San Juan}, L. and {Zamalloa Ugarte}, I. and {Gil-Uriarte}, E. and
	{Tews}, E. and {Peter}, A.},
    title = "{Introducing the Robot Security Framework (RSF), a standardized methodology to perform security assessments in robotics}",
  journal = {ArXiv e-prints},
archivePrefix = "arXiv",
   eprint = {1806.04042},
 primaryClass = "cs.CR",
 keywords = {Computer Science - Cryptography and Security, Computer Science - Robotics},
     year = 2018,
    month = jun,
   adsurl = {http://adsabs.harvard.edu/abs/2018arXiv180604042M},
  adsnote = {Provided by the SAO/NASA Astrophysics Data System}
}

Physical layer

Aspect: Ports

Criteria: Presence of external communication ports
Objective	Identify presence of unprotected external ports
Rationale	Unprotected external ports can let attackers in physical proximity to perform a variety of attacks and serve as an entry point for them
Method	Inspect documentation, consult developers and inspect robot’s body and components. Look for accessible ports (e.g. Ethernet, USB, CAN, etc.) Open all doors, which are not protected by locks and look for ports inside

Criteria: Presence of internal communication ports
Objective	Identify presence of unprotected internal ports that typically correspond with sensors, user interfaces, power or other robot-related components
Rationale	Unplugging robot components can potentially lead to the exposure of internal communication ports. Often, these internal communication ports are typically not protected in robots. This may allow attackers in physical proximity to perform a variety of attacks and serve as an entry point
Method	Open all doors, which are not protected by locks, even those protected, and look for robot components and their buses Investigate ventilation holes and see if they are wide enough to access internal communication ports

Criteria: Security of external and internal communication ports
Objective	Verify if attackers can sniff or modify any critical data during communication with a docking station or by connecting to the ports
Rationale	Unprotected external and internal ports can let attackers in physical proximity to perform a variety of attacks and serve as an entry point for them
Method	Try to connect to the identified communication ports: Determine if authentication is required(e.g. Network access control for Ethernet)? Assess whether the communication is encripted Try communicating with them, attempt fizzing to discover if robot’s state can be affected. If a robot connects to a docking station to transfer some data, try to use sniffers to see how data exchange is being done (verify if some sensitive, configuration or control data is transferred in clear text)

Aspect: Components

Criteria: Availability of components from outside
Objective	Identify internal hardware that is accessible from outside without a need
Rationale	Directly accessible components can be physically damaged, stolen, tampered, removed or completely disabled causing the robot to misbehave. The most obvious example is the removal of critical sensors for the behavior of the robot
Method	Inspect robots body and look for accessible components (e.g. sensors, actuators, computation units, user interfaces, power components, etc.) Open all doors which are not protected by locks and look for accessible components inside.
Notes	All cables should also remain inside of the robot. Some components require to be partially outside of the body frame (e.g. certain sensors such as range finders, or the antennas of certain wireless communication components) in such a case only the required part should stick out, but not the whole component

Criteria: Monitoring and alerting capabilities
Objective	Identify whether rogue access to the internal hardware of the robot can be detected
Rationale	Having no verification whether the internals of the robot were accessed or not means that attackers can easily tamper with any components or install a hardware trojan unnoticed
Method	Identify all parts of the frame that can be opened or removed to get access to the components or modules. Check whether there is an active (tamper switches) or passive (tamper evident screws and seals) monitoring capability present. In case of active monitoring capability, verify that operator receives a real-time alert and the incident is being logged and acted upon by reviewing procedures.
Notes	Passive monitoring provides information upon inspection whether internals were accessed or not. However, there is still a time window between inspections when exploited robots can be abused

Criteria: Review logs of physical changes in the robot
Objective	Verify the logs of the robot and look for tampering actions. Log examples include powering on/off events, connection/disconnection of physical components, sensor values or actuator actions. Detect potential tampering based on this information
Rationale	Most robots register logs of a variety of events going from powering on/off the robot to each individual component data. Specially, some robots detect physical changes on their components and register it. Such changes could lead to an undetected tampering of the system. Reviewing the logs could lead to discovering physical tampering of the robot
Method	Review the logs of powering on and off routines of the robot. Review the logs of physical changes in the robot. Review the logs of each individual component and look for anomalies.

Network layer

Aspect: Internal robot network

Criteria: Network accessibility
Objective	Determine and assess network accessibility and the corresponding protection mechanisms.
Rationale	Internal networks could be pass
Method	Validate authentication mechanisms and verify that no known vulnerabilities are present on such. If internal network is password protected, attempt common password guessing. Verify whether the robot logs both successful and unsuccessful login attempts.

Criteria: Network fingerprinting
Objective	Mitigate the fingerprinting impact on the internal networks.
Rationale	Network fingerprinting is useful to understand the internal network structure and its behavior, and to identify components’ operating system by analyzing packets from that component. This information could be used for malicious purposes, since it provides fine-grained determination of an operating system and its characteristics.
Method	Perform fingerprinting attacks on the internal networks. Evaluate obtained information with the manufacturer’s available data and assessits impact. If necessary, propose a mitigation strategy through the use of ”scrubbers”, whichwill ”normalize” the packets, and remove the unique identifying traits that the attacker is seeking. Refer to [18] for more details about the use of ”scrubbers”.

Criteria: Communication protocol security
Objective	Check if used communication protocol is up-to-date, secure and has noknown vulnerabilities.
Rationale	Vulnerabilities in communication protocols can allow attackers to gain unauthorized access to the internal network of the robot and intercept or modify any transmitted data.
Method	Identify all present communication capabilities by inspecting documentation, byconsulting developers or by manual analysis. Analyze if used protocol versions provide encryption and mutual authentication. Verify that used protocol is hardened according to industry standards.

Criteria: Monitoring, alert and response capabilities
Objective	Identify whether internal network activity is monitored, alerts are issuedand corresponding actions are taken based on known signatures or anomalies.
Rationale	Proper security controls on the internal network might be challenging due to hardware limitations or performance requirements, although it is critical for robots to introspect, monitor, report and act on issues that could appear on their internal networks. Security by obscurity is unfortunately a commonly accepted approach in robotics, nevertheless, it has been demonstrated that this approach leads to critically unsecured robots. Monitoring and control capabilities should be implemented on the internal network of the robot either through the manufacturer or through additional or external solutions. The decision of applying counter-measures to the attack or only alerting should be determined by the impact of possible false positives on the operative of the robot.
Method	Sweep the internal robot network and enumerate entry points (e.g. open ports, existing component information, network map of components, etc). Try to match the fingerprints identified and to map known vulnerabilities. Connect to the network and attempt to perform network-based attacks (e.g. ARPpoisoning, denial of service on a particular component, etc.) Verify whether the robot detects and registers incidents. Verify whether the robot acts upon such events and either: (The robot) responds to insult proactively. An operator receives a real time alert and acts based on procedures.

Criteria: Firewall
Objective	Identify whether internal network is separated from the external by thefirewall.
Rationale	Firewalls can help to further protect components, modules and communications from the outside and ensure that they cannot accidentally leak data to the external network.
Method	Inspect documentation, consult developers and inspect components which are responsible for external communications. Identify that such components have firewalls. Inspect firewall settings and verify that no components or modules are allowed to communicate to the external network unless it is necessary. If a VPN is used, verify that there are rules which allow components or modules to communicate with the outside world only via the VPN tunnel.
Notes	There should be a firewall per each interface with external networks. That means that each communication component interfacing with an external channel should have a firewall behind it or use third party solutions. For example, WiFi hotspots in robots or LTE/UMTS transceivers.

Aspect: External network

Criteria: Availability of components from outside
Objective	Determine and assess network accessibility and the corresponding protection mechanisms.
Rationale	External networks could be password protected. If that is the case, the corresponding mechanisms should be up to date and ensure that only authenticated users are able to access the network.
Method	Validate authentication mechanisms and verify that no known vulnerabilities are present on such. If external network is password protected, attempt common password guessing. Verify whether the robot logs the users connected to the network.

Criteria: Network fingerprinting
Objective	Mitigate the fingerprinting impact on the external networks.
Rationale	Network fingerprinting is useful to understand the network structure and its behavior, as well as to identify devices’ operating system by analyzing packets from that network. This information could be used for malicious purposes since it provides fine-grained determination of an operating system and its characteristics.
Method	Perform fingerprinting attacks on the external network. Evaluate obtained information with the manufacturer’s available data and assess its impact. If necessary, propose a mitigation strategy through the use of ”scrubbers”, which will ”normalize” the packets, and remove the unique identifying traits that the attacker is seeking. Refer to [18] for more details about the use of ”scrubbers”.

Criteria: Communication protocol security
Objective	Check if used communication protocol is up-to-date, secure and has no known vulnerabilities.
Rationale	Vulnerabilities in communication protocols can allow attackers to gain unauthorized access to the external network of the robot and intercept or modify any transmitted data.
Method	Identify all communication capabilities being present by inspecting documentation, consulting developers or by manual analysis. Analyze if used protocol versions provide encryption and mutual authentication. Verify that used protocol is hardened according to industry standards.
Notes	If providing encryption on the protocol level is not possible for some reasons, VPN or application level encryption should be used.

Criteria: Network ports exposure
Objective	Identify whether only necessary network ports are exposed to the external network.
Rationale	More open ports mean a bigger attack surface and therefore their number should be as low as possible. Services that are exposed should have no known vulnerabilities due to the ease of their exploitation.
Method	Connect to the network that is being used by the robot for communication and scan all robot ports to find the open ones. Verify with manufacturer manuals whether their presence is required. Identify, if possible, services running behind an open port and its version. Verify whether identified services are still receiving security updates and have no known vulnerabilities.

Criteria: Monitoring, alert and response capabilities
Objective	Identify whether the external network activity is being monitored, alerts are issued based on known signatures or anomalies and appropriate actions are taken.
Rationale	Properly configured external network monitoring can spot network based attacks in their inception even if other security mechanisms are compromised.
Method	Sweep the external robot network and enumerate entry points (e.g. open ports, protocol information, network map of components, robot components etc). Try to match the fingerprints identified and map to known vulnerabilities. Perform network based attacks (e.g. ARP poisoning, denial of service on a particular component). Verify whether the robot detects and registers incidents on the external network. Verify whether the robot acts upon such events and either: (The robot) responds to insult proactively. An operator receives a real time alert and acts based on procedures.
Notes	In those cases where it is not possible to implement external robot network monitoring, alerting and response due to limitations on the robot capabilities, manufacturers should extend their capabilities or refer to third party solutions that could offer such.

Firmware layer

Aspect: Operating System (OS)

Criteria: Underlying OS updates
Objective	Verify that the used Operating System (OS) is still supported by the manufacturer and there is a mechanism to perform system updates.
Rationale	Outdated operating systems can have security vulnerabilities.
Method	Check if the underlying OS is still maintained and receives security patches. Check whether the latest security updates are applied. Check if there is an update mechanism present and enabled. Check if the updates are encrypted when transferred to the robot.

Aspect: Middleware

Criteria: Verify code compliance (if accessible)
Objective	In those cases where it applies (white box assessment), ensure compliance of middleware code against established compliance mechanisms. A common middleware such as ROS 2 should comply with the Motor Industry Software Reliability Association (MISRA) guidelines. Other middlewares might use different guidelines.
Rationale	As robotics and autonomy grow, especially in certain fields of robotics, users of middlewares need to be able to determine if the software is able to be used in a safety-critical environment. With suitable guidance and modification, it is expected that middleware code could be integrated as part of certain compliant system. For this purpose, code should be developed and reviewed following certain guidelines. The most common one is the Motor Industry Software Reliability Association (MISRA), widely used in many safety-critical environments and adopted by the ROS 2 middleware.
Method	Determine the exact set of guidelines that are being applied. Validate whether these guidelines have been implemented.

Criteria: Middleware updates
Objective	Verify that the used middleware is still maintained and supported by the manufacturer. Verify to perform system updates in the middlware.
Rationale	Outdated middlewares in robotics are subject to have security vulnerabilities. This is specially true with ROS, ROS 2 and other robot-related middlewares
Method	Check if the underlying middleware is still maintained and receives security patches. Check whether the latest security updates are applied. Check if there is an update mechanism present and enabled. Check if the updates are encrypted when transferred to the robot.

Criteria: Middleware strict values validation
Objective	Verify that the used middleware introduce strict value ranges into messages.
Rationale	Messages define what data a listener can accept, but to avoid bugs and/or errors, the listener should only consider a set range of values valid for any given field. When values out of this range are received, the listener should error out in a controlled manner.
Method	a) Middleware should provide primitives for range-checking ( a message type with built-in range checks can be denied on the publisher’s side before the listener ever has to interact with it) or b) listeners must implement their own range-checking.

Criteria: Middleware provides safe mode for computational nodes
Objective	When nodes fail, it is essential that core functionalities are still available
Rationale	In a safe mode, basic functionalities will be pro-vided to recover the robotic system, such as when in tele-operation.
Method	Middleware should provide primitives for implementing a safe mode within the software lifecycle. Ideally, such lifecyle should connect to the hardware (lifecyle) one and coherently provides means of recovery.

Aspect: Firmware

Criteria: Firmware updates
Objective	Check if manufacturer firmware can be securely updated.
Rationale	If new vulnerabilities are discovered it is important to ensure that there is a way to provide updates to all the devices that are already sold to customers. However, update mechanisms can be circumvented by an attacker to deliver malicious update. Therefore, it is important to verify the origin of the update prior to installation.
Method	Identify if there is a mechanism to deliver firmware updates. Verify that updates are cryptographically signed. Verify that the signature is verified prior to installation.

Application layer

Aspect: Authorization

Criteria: Access control
Objective	Verify that resources are accessible only to authorized users or services.
Rationale	Access to the restricted functions by anonymous users or users with lower access control rights diminishes all the benefits of access control.
Method	Log in with authorized credentials and attempt to perform different actions, record the requests that are being made. Log out and attempt to send the same requests as an unauthenticated user. Verify whether it is successful. Log out and log in again as a user with lower access rights. Attempt to send the same requests again. Verify whether it is successful.

Aspect: Privacy

Criteria: Privacy assessment
Objective	Identify whether the robot is compliant to the privacy policies that apply.
Rationale	Not complying with privacy standards could result in a breach of personal data.
Method	Verify that minimum Personally Identifiable Information (PII) is collected and transmitted over the internet. Verify that if PII is collected users are made aware of it (e.g. in case of a video recording people can be warned by stickers or signs on the robot). Verify that all PII is stored and transmitted in a secure manner.

Criteria: Data protection
Objective	Identify whether the robot manufacturer emplaces mechanisms to ensure compliance to the data protection regulations and laws that apply. Particularly, General Data Protection Regulation (GDPR) in the EU.
Rationale	Not complying with regulations could result in penalties.
Method	Assess the legitimate interests. Assess the consent. Assess the information provisions. Assess the third party data. Assess the profiling. Assess the legacy data
Method	It is not relevant to the security of the robot itself. However not complying with data protection regulations can result in financial penalties and should therefore be taken into consideration.

Aspect: Integrity

Criteria: Integrity check
Objective	Identify whether the system performs an integrity check of critical components and takes action if they are not present or modified.
Rationale	Tampering with any of the critical components can make the robot cause physical damage to people and property.
Method	Consult documentation and developers to find whether integrity check for critical components is present. Try disabling or modifying critical components (e.g. safety sensors or range finding systems) of the robot and check if the operator receives a real-time alert and the incident is being logged. Check whether the robot continues to function afterwards. Its operation should be stopped as soon as any critical component is disabled or modified, (e.g. if a proximity sensor is disabled the robot should not be able to move, because it will not be able to spot obstacles and can easily do some physical damage).
Note	Critical components are those that can directly influence the robot’s operation, functionality or safety.

Aspect: Accounts

Criteria: Default passwords
Objective	Identify presence of default passwords.
Rationale	Default passwords are easily accessible online and remain the most popular and effortless way to exploit internet connected devices.
Method	Review documentation and consult developers to identify whether default passwords are used. Attempt to log in with commonly used passwords. If default passwords are used, verify whether their change is encouraged on the first use. If unique passwords are created on a per device basis, ensure that they are random and not in a sequential order.
Note	When trying commonly used passwords, beware of account lockouts and verify that there is a recovery mechanism present.

Criteria: Password complexity
Objective	Verify that password complexity is enforced.
Rationale	Weak passwords may take little time to guess.
Method	Attempt to change the password to a weak one and verify whether this change succeeded.
Note	Password complexity requirements depend on the sensitivity of the application. In general, the minimum requirements that should be in place are: A password length of, at least, 8 characters. Enforce the usage of 3 of this 4 categories:lower-case, upper-case, numbers, special characters.

Criteria: Login Lockout
Objective	Identify whether the login lockout is present.
Rationale	Having strong and non-default passwords may not be enough. Brute force attempts should be prevented by implementing a login lockout mechanism.
Method	Attempt to log in with incorrect credentials multiple times. Verify that the account has got a lockout.
Note	The lockout threshold depends on the sensitivity of the service. In general, there should be 5 login attempts or less. Prior to testing, verify that the lockout recovery mechanism is being present. Accounts can be either locked out for a specific duration of time and/or they can be recovered by physical interaction with the robot.

Criteria: Hardcoded or backdoor accounts
Objective	Identify presence of hardcoded or backdoor accounts.
Rationale	Hardcoded or backdoor credentials pose the same danger as default passwords. However, their identification is usually harder due to the need for reverse engineering or possession of the source code.
Method	Consult documentation and developers to identify whether hardcoded or backdoor credentials are used. Analyze the source code for hardcoded or backdoor credentials.

Criteria: Cleartext passwords
Objective	Identify whether passwords are stored in cleartext.
Rationale	Cleartext passwords can be leveraged by an attacker for privilege escalation or lateral movement.
Method	Review the source code and documentation, consult developers and identify whether passwords are stored in a cleartext.
Note	Lockout threshold depends on the sensitivity of the service. In general, there should be 5 login attempts or less.

Aspect: Communication

Criteria: Encryption
Objective	Ensure that all sensitive data is transmitted over an encrypted channel.
Rationale	If data is transmitted in a clear text attackers can easily gather sensitive information (e.g. credentials, audio and video streams, private data).
Method	Intercept connection between a robot and a control center application or a cloud server. Use protocol analyzer to verify that transmitted data is encrypted.

Criteria: Replay protection
Objective	Ensure that transmitted data cannot be replayed.
Rationale	If replay protection is absent, attackers can record legitimate packets and then arbitrary replay them to achieve desired actions.
Method	Intercept the connection between the robot and a control center application or a cloud server. Record the control or configuration packets sent to the robot. Attempt to replay the packets and verify whether the desired action is executed.

Aspect: 3rd party libraries and components

Criteria: Vulnerabilities
Objective	Verify that 3rd party software components do not have known vulnerabilities.
Rationale	It is quite common to blindly rely on 3rd party components. However they can easily introduce a vulnerability into the product where they are used.
Method	Identify which 3rd party libraries and components are used and what are their versions. Look for known vulnerabilities in the current version. Verify whether the identified component is still receiving security updates and has no unpatched vulnerabilities. Verify that the latest security updates are installed.

Aspect: Control center application

Criteria: Web application
Objective	Perform a security assessment of the web application.
Rationale	The robot can be indirectly compromised if the attacker exploits a web control center application.
Method	Identify web interface that is being used (hosted on the robot itself or a cloud server). Use OWASP methodology to test web application against OWASP Top 10 Web application vulnerabilities.

Criteria: Mobile application
Objective	Perform a security assessment of the mobile application.
Rationale	The robot can be indirectly compromised if the attacker exploits a mobile phone control center application.
Method	Identify whether the robot has a mobile app that can be used to control or interact with it. Test the application against OWASP Mobile Top 10.

License

GPLv3.

Glossary

component: a part of something that is discrete and identifiable with respect to combining with other parts to produce something larger (source: ISO/IEC 24765).
- Note 1 to entry: Component can be either software or hardware. Even a component that is mainly software or hardware can be referred to as a software or hardware component respectively.
module: component with special characteristics to facilitate system design, integration, interoperability, re-use.
interoperability: the capability to communicate and transfer data among modules and combine modules physically in a manner that requires the user to have little or no knowledge of the unique characteristics of those modules.
firmware: (in the context of robotics) software that is embedded in robots.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].

Stars: ✭ 76

Visit Git Page 🔗Visit User Page 🔗Visit Issues Page (1) 🔗