Are pointers safe against online change of running PLC program in TwinCAT 2.10 and in CoDeSys 2.3 on which the first one is based? What happens if memory block gets reallocated as part of online program change and there are pointers pointing to that memory block?
ADR (Address Operator) description in TwinCAT's help says:
Attention:
After an Online Change there might be changes concerning the data on certain addresses. Please regard this in case of using pointers on addresses.
It looks to me like pointers cannot be stored permanently if someone pretends to use online modification of the program. Otherwise if pointers are stored (for example as a binding between some data structures) online change should be avoided.
Related
I can not find any documentation or code that describe what SIGEMT was originally invented for.
All the code I can find (e.g. with debian code search) seems to just handle it like all the other signals that terminate the process or just map the signal number to a name (or name to number).
From the short descriptions it looks like this is used in some kind or instruction emulation that has a kernel and a user space part. Is there any software that actually uses this?
I could find code in the linux kernel that might emit the signal, but it's not documented either.
I am curently looking for a dictionary that contains all (or a lot) of interfaces names for routers and switches.
For instance a dictionary that would look like this :
[[Cisco : GigabithEthernet1/0/0, ..., GigabithEthernet1/0/28, FastEthernet1/0/0, ...],
[Juniper : ge-0/0/1, ..., ge-0/0/12,fa-0/0/1, ...,fa-0/0/12]]
I would like it to contain as much of interfaces names of as much of brand as possible.
I have already been looking for it for a long time now, but I have not been able to find anything so far. So if anyone has something to share on this it would be very much appreciated.
Thanks for reading.
A quick update to inform you that I have not been able to find a dictionnary and that after some research I find out that you don't need one if your problem is to identify interfaces on a switch or router.
Using SNMP, you can find which one of the interfaces on your machine is a physical or logical interface. So I used this reference to know which one of my interfaces are physical interfaces or not.
The OID is : 1.3.6.1.2.1.2.2.1.3
Thanks for the help I have been given so far !
so basically I've been online trying to research this the whole day and I seem to only be able to come across specific setups that people have for their own specific needs rather than a generic list of hardware needed.
What I want to do firstly using my raspberry pi 2 running raspbian, and secondly a laptop running kali, is to be able to do penetration testing along with some extras.
What I Am looking for is a list of hardware that I need (other than the rpi2 for the first case and laptop for the second) that will enable me to sniff out WiFi signals, and attempt to get onto the network. I believe the general name for this is wardriving.
I know that I need a portable power supply for the rpi2, and a screen or some sort (I want a small screen that I can see the rpi gui desktop from. Not just terminal), so any suggestions of examples of those would be appreciated.
Where I get confused is about the WiFi antenna that I need. From what I understand is that it needs to be one that can monitor as well as connect to a WiFi, but I don't really know of any examples or of what the actual difference is between it and a normal usb WiFi stick.
I'm also not sure what else I need to have beyond that to successfully accomplish my stated goal.
Any further help would be greatly appreciated, and I think beneficial to anyone else who's looking to get started doing the same thing.
Any extra information would be good too what I mean is when I was doing my research I saw some people mentioning radio attachments, gps attachments, etc. But I'm not really sure if they're necessary to start or things that can be added further down the road with experience.
Thanks.
Ok so I seem to have found a good article that answers at least the general part of my question. It can be found here.
http://lewiscomputerhowto.blogspot.ca/2014/06/how-to-hack-wpawpa2-wi-fi-with-kali.html?m=1
It also gives tips on the process of pen testing.
Are there any tips for reading source code samples from manufacturer of MCUs'.
I am a newbie for mcu programming, currently I have a MCU, datasheet and sample codes for them. But problem is sample codes are seems written for experienced users. Too many questions about why they initialized RS232, why they set 4th bit of port 1 and etc.,
Do you have a tips for reading or links where can I get info about how to read datasheets and sample codes of MCU?
I guess experience is the only answer I can give. Just like with programming in general, with time you acquire experience as well as learn buzz words and concepts. With microcontrollers you learn to read datasheets, schematics, etc. Learn about open drain, open collector, weak pull ups, etc. And for serial ports for some reason they are always overcomplicated. The hardest part with microcontrollers and the serial port is usually figuring out what to program to get the right clock divisors, some microcontroller serial ports are straight forward, others are overly complicated, some docs are good some docs are bad, etc.
Another answer is datasheets are always wrong. There are always gaps in the information that you have to hack to figure out. Do not write thousands of lines of code in a vaccuum using only a datasheet, write a small amount of code a few lines to a few dozen, test, and move on, you can get more lines written and debugged in a day when programming from a datasheet than the other path. The datasheets are often not written by the engineers that actually designed the hardware, sometimes it is a junior engineer or a non-engineer. Sometimes the information is simply wrong, sometimes the document is for a different but similar part than the one you have. If they provide software that actually does stuff it is sometimes (not always) more accurate than the datasheet (when I say datasheet assume the users manual, programmers reference manual, whatever the vendor calls the doc with the registers, addressses, and bit definitions for the hardware).
With time and experience you may find, if you take a wide enough view, that some vendors tend to do a better job at providing information to users, others do not, some bury the secrets in libraries, sometimes in binary form and not source. Sometimes the secrets are buried in compilers and other tools they provide (well that is back to apis and libraries). I tend to blacklist such companies, but sometimes you cant always. ARM for example does a very good job of providing the information. the problem is they have so many cores with a number of options each, that are very similar in nature (support the same instruction sets) that it can be difficult to sort through what the one processor you are using that moment does and does not from the docs. Atmel, something about atmel that is hard to put a finger on, the docs are generally well above par, but more than that something about atmel makes them popular with the customers. You will never see an arduino like following, culture, pick a word, with a microchip pic for example. There are a lot of pic followers but it is not like the atmel world (which was there well before the arduino thing happened).
Another note, you might not understand with a single example program and single datasheet the history of a product, there might be code that has been used for a number of chip generations, and there might for example be a bit that is required by an older chip or newer chip and to share the same code that bit is manipulated. that bit might make sense looking at one datasheet and no sense looking at another. this is where hacking comes, in try it without, see what happens. maybe study other parts in the family that this code is said to support it might make more sense.
google is your friend or whatever favorite search engine, find as much open source code and other items for the particular device or whatever. At this level hacking is required, I dont use that term in the bad sense, hacking in the sense that you have to try some of the bits documented in the datasheet, see if that actually works, if not then see what it does if possible, look at other source code and see from that if you can figure it out. Just like there is no perfect car that gets infinite miles per gallon, completely safe, lasts forever, and is inexpensive, there is no perfect chip with the perfect datasheet and sample code. If you want to work at this software/hardware level you have to get your hands dirty, have to not be afraid to let some smoke out of the chips (there is a finite amount of smoke in a chip if you let even a little bit out it wont work), etc.
If the reason you wont ask specifically about the mcu or register you are working with is because it is closed source products or behind an NDA then you probably have access to the company that makes that product and you should be able to get support from them. Usually better support than you would get from a company that you dont have to sign an NDA for. Not that open document, open source companies are bad, just that if the company you buy from is interested in you to the point of showing internally protected information they are interested enough to give you better access to the real engineers that made/know the product. If this is not the case and you are able to talk about it, dont be afraid to just post a question to SO about the register and bits you are wondering about.
Sample code and flow charts in the MCU datasheets are good starting point to initialize a specific peripheral (like RS232).
You just start from there, and track the bit information and what it does, in MCU datasheet.
I am attempting to write a userspace application that can hook into an OS's network stack, sniff packets flying past and edit ones that its interested in.
After much Googling, it appears to me that the simplest (yet reasonably robust) method of doing so (on any platform) is Linux's libnetfilter_queue project. However, I'm having trouble finding any reasonable documentation for the project, outside of the limited official documentation. Its main features (as stated by the first link are)
receiving queued packets from the kernel nfnetlink_queue subsystem
issuing verdicts and/or reinjecting altered packets to the kernel nfnetlink_queue subsystem
Emphasis is my own. How exactly am I meant go about this? I've tried modifying the sample code provided, but perhaps I am misunderstanding something. The code is operating in NFQNL_COPY_PACKET mode, so I am receiving the whole packet -- but my modifications to it seem to be restricted to my own application -- as one would expect, given the "copy" semantics.
My feeling is that I am meant to make use of NF_QUEUE somehow, but I haven't quite grokked it. Any pointers?
(If there is a simpler mechanism for doing this, which is also cross-platform, I'd love to hear about it!)
I can't believe I missed this previously. As reticent as I am to post questions on SO, I thought I would never work this one out myself. :)
I didn't look at the function prototype properly. It turns out in the "verdict" function (outlined below),
int nfq_set_verdict(struct nfq_q_handle *qh,
u_int32_t id,
u_int32_t verdict,
u_int32_t data_len,
const unsigned char *buf
)
The last two parameters are for the data to be returned to the network stack. Obvious in hindsight, but I missed it completely as the print_pkt function doesn't take the packet data as a parameter, but extracts it from the struct nfq_data.
The key is to NF_ACCEPT the packet and pass the suitably modified packet back to the kernel.
Just a wild guess from digging around the source code: try explicitly adding the mangled payload using nfnl_addattr_l(…, NFQA_PAYLOAD, …)?