@ebaena,
I will try here to put your questions in perspective. There is a lot going on here, much more beyond Carloop, including things like Honda’s engineering, the technologies, your designs and your judgement.
Let me start off with question 2, since I can answer that factually.
The protocol that Carloop does is CANbus. Carloop can send and receive ANY and ALL CANbus messages. That includes exchanging OBDII messages over CANbus. That makes Carloop a very powerful tool. Is it the right tool?
Here in Canada, it is regulated that cars must provide the OBDII messages over CANbus through a connector located near the steering column (I am not using the legal wording here).
So, if your car is a Honda in Canada, it will do OBDII over CANbus. Most likely, if your car is in the USA or the EU, it will be the same. There is also nothing legal to say that is the only bus in your car, or what protocols may be used on other buses. For example, in @dubb45’s vehicle, there is another bus accessed in behind the radio inside the dashboard; it just so happens that it uses CANbus but it could have been something else.
The conclusion is, to know your protocol requirements, you have to know what your car uses. If it is some propriety protocol, you will have to reverse-engineer it to be able to communicate on it.
Now, I am going to mix the first part of question 3 with part of question 1.
You do not write directly to the car computer. What you do is send a message to a module (which is pretty much a computer). There may be many different modules in your car: ECU for the engine, BCM is body control module, ABS, Airbags, etc could all be different modules.
The question is what the module does with the message. That depends on the design of the module and the design of the car. The module might store something in memory, it might control a function, it might send a message back, it might send a message to another module, it could even ignore the message. So it all depends on the design of the module.
Now the rest of question 3.
What is possible depends on the module. If a module allows the control of something and is capable, then it can be controlled. Again, it depends on the car. For example, to control the lights then the lights have to be connected to a module and the module has to allow that control. Maybe you can or maybe you cannot.
Modules may use security measures like encryption, call-backs, confirming with another sensor. You would need to know the design of the car, or be able to reverse-engineer it. Then again, they may not have any protection.
As for danger; it is absolutely dangerous if you are messing with a safety system. What are the safety systems in your car? What things are connected with the safety systems? … that is complicated to answer. For anything you do, you will have to evaluate all the risks and decide if you accept the risk or not. You will have to take responsibility for what you do, or not do.
@dubb45 was able to brick a module in his car. Can you do the same in your car? Only if your car uses the same module. You might be able to brick your car in totally different ways.
In general, you are going to have to research your car. How you go about it is up to you.
For example, I am working on adding the K-Line protocol to Carloop; it is nicknamed CarloopRetro since it is an older protocol. If it works, then ISO9141, KWP2000 and KWP Fast Init messages will be able to be exchanged. OBDII can be done in those messages also. I bought a scrap Subaru Impreza to take out the modules and put on my bench lab so I can work on K-Line. It is not cheap, but it is pretty safe working on a bench instead of a real car.
I hope this gives you a sense of some of the details and some of the bigger picture at the same time. What you accomplish is what you make of it!
the carloop is like a bridge in between your code and the car or atleast that’s how I see it and that makes it easy to control whatever you want. If you have the right info then you can do what you want to these “computers on wheels”