I have a similar problem with this. How to program a simple CANopen layer .
I read the answers but I have to program a CANopen layer on my own I cannot get a commercial one. So are there any basics of writing a CANopen stack (or layer I'm not certain about the difference)? I don't know even where to start..
If it's required here's some information :
My master device is a beagle bone black with QNX. QNX has a generic CAN library I think but not specific to CANopen. And my slave is a militarized brushless motor controller. I'm writing in C++.
I have a documentation about the general requirements of my system.
There are 2 RPDOs and 4 TPDOs, transmission is synchronous, there is no stopped mode( so no heart-beat and node guarding) and all message informations are stated (size, format, related node IDs etc.)
There are actually at least 4 open source projects that implement CANopen:
CanFestival is the oldest and might be the most mature solution. License: LGPLv2.
CANopenNode is aimed at micro-controllers. License: GPLv2.
Lely CANopen is a library for implementing CANopen masters and slaves. License: Apache version 2.
openCANopen is a master that runs on Linux. License: ISC. Note: I am the author of this project.
I would have posted links, but apparently I don't have enough "reputation".
openCANopen also includes some utilities such as a daemon for forwarding traffic over TCP and a program that interprets and dumps CANopen traffic to standard output.
Lely CANopen is actually of pretty decent code quality and I might have used it if it'd been available when I started writing my own implementation. However, I have not tried using it, so I can't really say which implementation is "better". I can only say that they are different and one or the other may suit your needs better.
Now, I doubt that any of those implementations will work straight out of the box on QNX. They will either have to be adapted or you can copy individual parts of the code into your own implementations. At least that should save you some time.
The quick and dirty work-around is to only implement the bare minimum (just don't market it as CANopen or claim CANopen compliance):
Support for those specific RPDOs/TPDOs that the other node will send/expect to receive. Use fixed COBID (CAN identifiers). Forget about PDO mapping and PDO configuration, use fixed settings.
Implement a NMT bootup message.
Implement NMT state transitions between pre-operational and operational (your node needs to respond to these from the NMT master).
Implement some means to set the node id. Easiest might be to hard code it as a program constant.
If you are lucky, this is all that is needed. If you are unlucky, there will be SDO commmunication, meaning you will have to implement the SDO protcol and also the whole Object Dictionary. Otherwise, the above is fairly straight-forward and not that much work.
In case you need the Object Dictionary, then there might be no other way around getting a full-blown protocol stack. You'll also need to apply for a vendor id from CAN-in-Automation, but it's a one-time fee (no royalties).
I'm from Embedded Office and want to add my penny to your search, even if it's late. First I want to mention, the reason why we didn't put drivers into the canopen-stack repository is the complexity of embedded software development on multiple targets with multiple compilers and my goal to provide running software wherever possible. With just a library is hard to identify problems during usage.
The good news, I setup an environment to get the different targets and compilers managable by a single maintainer (me). So the canopen-stack is developped with LLVM on host machines, and a first demo is provided for STM32F7xx microcontrollers. More is coming, so stay tuned :-)
Related
I'm trying to debug a chunk of code that's mostly a straightforward 16-state state machine, although there are some cases where the transitions are not very simple (the data the state changes operate on are about 200 bytes of data in a couple C++ classes).
We're finding the machine ending up in a "final" state much earlier than expected. Since I'm not yet intimately familiar with the code, I'm hoping I can try to make out the different states and transitions in a way that will make it easier for me to quickly identify and debug the different transition paths.
Are there any useful tools or techniques for mapping out a state machine like this?
It might be worth noting that I'm doing this from a reverse-engineering standpoint, so there is no planning documentation for the system available to me.
You can look into formal model checking tools, such as UPPAAL. This tool can be used for modelling and verification of any system that can be modelled as networks of timed automata - this includes state machines. I have used it previously to verify e.g. invariants and reachability of possible states.
Abis is the signals which are passed from BTS to BSC in mobile networks. The work they want to do is to collect the messages from BTS, analyse it to find some specific errors etc. So for doing these, I have to actually know how to do protocol analyser. the language which i am told is to use is c or CPP.
There are three main stages on analysing data for any protocol:
Capturing or generating the network traffic: For mobile networks, that generally involves very expensive receiver hardware - hardware that usually comes with its own analyser software that will be far better than anything you might code yourself. Base stations may allow for a way to monitor their operation and capture data. It is also theoretically possible to repurpose other hardware (e.g. a cell phone or a lab instrument), or to generate the data using a simulator.
Extracting the data of interest: You need to extract and isolate the data for the protocol that interests you. Depending on the encapsulation and encryption properties of the network, that might be impossible for data captured in the wild - in that case you'd need something that would act as a node in the network and provide access to its inner workings.
Analysing the protocol of interest: You need a piece of software that will not only implement the protocol, but that will provide far more extensive logging and error-recovery capabilities than any production implementations. That way it will be able to point out and handle misbehaving nodes.
If you intend to write a protocol analyser of your own, you need to aqcuire the protocol specification and code such an implementation. You should be warned that even the simplest protocols are in fact quite difficult to implement correctly.
Without more information on your development and target platforms, the source and format of the data and the resources that you have available, there is no way for us to provide more information.
PS: It would also help if your question contained an actual question that we could answer.
I am writing a piece of software in C++ which is targeted at a market in which software is traditionally heavily cracked (or at least, attempted to be). I realise that nothing can be completely protected, however I feel that trying would be a good idea and also I think some of the specifics of the situation that I'm in might be helpful.
Firstly, it would not be annoying to the user that they must have an internet connection to use the software. I hate it when games etc. do this too, but the software requires an internet connection to function anyway due to its purpose, so this wouldn't hinder a normal user.
Secondly, it depends fairly heavily on external scripts written by me and/or supplied by third-parties, so I can have these stored on some website somewhere meaning that people who crack the software will have to also track down new copies of the scripts, which may annoy them into becoming legit.
Thirdly, new versions will, by definition due to what the app does, have to be released very often, weekly or every two weeks max. The program will obviously have an autoupdater, but since I am churning out (required to function) updates so often, any sort of key-based encryption or whatever could possibly have the keys/method change every update, and I am capable of breaking existing cracks when they do happen.
Does anyone know of any available solutions or techniques I could implement which fit the bill?
If you application is doing some sort of data processing or analysis, you can protect it by putting that part into a web service (maybe in a cloud) that your client application connects and authenticate to and then receive results from. So even if your client application is reversed engineered, it would be missing that important piece of processing.
If your application is web based, you get the same effect too.
I've previously used CrypKey successfully.
I'm going to guess that older copies of the software are far less useful than the latest copy.
If that's the case, then you already have a powerful anti-cracker technology in place: your update mechanism. When you become aware of a hacked version of your software, then you can immediately check for it, and cause trouble for users of the hacked software.
I need to calculate a machine id for computers running MacOS, but I don't know where to retrieve the informations - stuff like HDD serial numbers etc. The main requirement for my particular application is that the user mustn't be able to spoof it. Before you start laughing, I know that's far fetched, but at the very least, the spoofing method must require a reboot.
The best solution would be one in C/C++, but I'll take Objective-C if there's no other way. The über-best solution would not need root privileges.
Any ideas? Thanks.
Erik's suggestion of system_profiler (and its underlying, but undocumented SystemProfiler.framework) is your best hope. Your underlying requirement is not possible, and any solution without hardware support will be pretty quickly hackable. But you can build a reasonable level of obfuscation using system_profiler and/or SystemProfiler.framework.
I'm not sure your actual requirements here, but these posts may be useful:
Store an encryption key in Keychain while application installation process (this was related to network authentication, which sounds like your issue)
Obfuscating Cocoa (this was more around copy-protection, which may not be your issue)
I'll repeat here what I said in the first posting: It is not possible, period, not possible, to securely ensure that only your client can talk to your server. If that is your underlying requirement, it is not a solvable problem. I will expand that by saying it's not possible to construct your program such that people can't take out any check you put in, so if the goal is licensing, that also is not a completely solvable problem. The second post above discusses how to think about that problem, though, from a business rather than engineering point of view.
EDIT: Regarding your request to require a reboot, remember that Mac OS X has kernel extensions. By loading a kernel extension, it is always possible to modify how the system sees itself at runtime without a reboot. In principle, this would be a Mac rootkit, which is not fundamentally any more complex than a Linux rootkit. You need to carefully consider who your attacker is, but if your attackers include Mac kernel hackers (which is not an insignificant group), then even a reboot requirement is not plausible. This isn't to say that you can't make spoofing annoying for the majority of users. It's just always possible by a reasonably competent attacker. This is true on all modern OSes; there's nothing special here about Mac.
The tool /usr/sbin/system_profiler can provide you with a list of serial numbers for various hardware components. You might consider using those values as text to generate an md5 hash or something similar.
How about getting the MAC ID of a network card attached to a computer using ifconfig?
Is there a good C++ framework to implement XA distributed transactions?
With the term "good" I mean usable, simple (doesn't imply "easy"), well-structured.
Due to study reasons, at the moment I'm proceeding with a personal implementation, following X/Open XA specification.
Thank you in advance.
I am not aware of an open-source or free transaction monitor that has any degree of maturity, although This link does have some fan-out. The incumbent commercial ones are BEA's Tuxedo, Tibco's Enterprise Message Service (really a transactional message queue manager like IBM's MQ) and Transarc's Encina (now owned by IBM). These systems are all very expensive.
If you want to make your own (and incidentally make a bit of a name for yourself by filling a void in the open-source software space) get a copy of Grey and Reuter.
This is the definitive work on transaction processing systems architecture, written by two of the foremost experts in the field.
Interestingly, they claim that one can implement a working TP monitor in around 10,000 lines of C. This actually sounds quite reasonable, as what it does is not all that complex. On occasion I have been tempted to try.
Essentially you need to make a distributed transaction coordinator that runs as a daemon process. You will need to get the resource manager protocol working from it, so starting with this as a prototype is probably a good start. If you can get it to independently roll back or commit a transaction you have the basis of the TM-RM interface.
The XA API as defined in the spec is the API to control the transaction manager. Strictly speaking, you don't need to make a 3-tier architecture to use distributed transactions of this sort, but they are more or less pointless without a TP monitor. How you communicate from the front-end to the middle-tier can be left as an exercise for the reader. You are probably best off using an existing ORB, of which there are several good open-source implementations available.
Depending on whether you want to make the DTC and the app server separate processes (which is possibly desirable for stability but not strictly necessary) you could also use ACE as a basis for the DTC server.
If you want to make a high-performance middle-tier server, check out Douglas Schmidt's ACE framework. This comes with an ORB called TAO, and is flexible enough to allow you to use more or less any threading model that takes your fancy. Using this is a trade-off between learning it and the effort of writing your own and debugging all the synchronisation and concurrancy issues.
Maybe quite late for your task, but it can be useful for other users: LIXA is not a "framework", but it provides an implementation for the TX Transaction Demarcation specification and supports most of the XA features.
The TX specification is for C and COBOL languages, but the integration of the C version inside a C++ project should be effortless.
Other option is open source Enduro/X distributed transaction processing framework which allows to write simple C/C++ services which may operate with resource managers (e.g. databases) and gives capability to commit or abort works done by several different executables on same/different physical servers worked with different resources/databases.
Internally XA 2PC is used there.