I'm developing a product connected to a CAN bus with the J1939 protocol.
In address claiming process, it is supposed to be mandatory to send the NAME of my product, which includes, among other data, a manufacturer code. This manufacturer code is 11 bits length, and it is supposed to be assigned by SAE committee.
But I am a bit confused about this.
With only 11bits length, there are only 2048 different codes. This seems not too many for all manufacturers in the world (and there are some of them that have more than one code assigned).
On the other hand, do I REALLY need a manufacturer code? Is there any strategy that I can use to avoid getting one? Is there any commonly used strategy for this purpose?
On the other hand, do I REALLY need a manufacturer code?
It depends on the nature of your device, if it's intended for mass production, then you'll need to register yourself and get an id.
Is there any strategy that I can use to avoid getting one?
You can use 11'b0 as your ID, but only for experimental/development purposes, othewise you won't be J1939 compliant.
The NAME is used only during the address claiming procedure, where in the case of two ECUs claiming the same address compare their names to check who's keeping it.
The contention basically compares the NAME as a numerical value, the lowest the value, the higher the priority. Depending on what is your device priority the name may not even taked into account.
You need to evaluate the function that your device is playing the the system and assing a higher NAME if it's not critical or lower NAME if is safety related.
Related
Rather new to Bluetooth Low-energy devices, and having recently purchased a bunch of trackers off Amazon, decided to write a little application to see what type of information I can get from these.
The trackers are from a Chinese company, and they don't have a ton of information around advertisement information, so I'm playing by best guess here.
What I've been able to achieve so far, through Flutter Reactive BLE, is to find the devices by their ID (filter out additional noise I don't care about) and pull information like RSSI, Name and ID from it.
Now I want to interpret the manufacturerData object, screenshot attached of just one of them, and can't seem to get anything concrete from it.
I half assumed that reactive_ble would've stripped the leading checks and only supplied the the necessary portions of the data object that's relevant to interpret, however, this does not seem to be the case.
My first feel was to just convert this UInt8List to String utf8.decode(device.manufacturerData), however, this returns either a 1x spaced string or nothing at all.
I've tried using ByteData with a start of 3 and end of 4, and that's not very helpful either.
Is there something I'm missing in it's interpretation? I've read the Bluetooth spec and as I don't come from a CompSci background, is rather foreign to me, so would appreciate a layman response.
The first 16 bits (little endian) in manufacturer data contain the manufacturer id (Bluetooth SIG's web site has a list). The layout of the rest of the bytes are totally up to the manufacturer. If you can't guess what they mean, you'll have to ask the manufacturer.
I am reverse engineering a driver that implements HID for the purposes of searching for vulnerabilities.
The main IOCTLs it implements are all from the HID minidriver libraries in the WDK.
I am in particular interested in sending malformed values to the IOCTL_HID_SET_FEATURE IOCTL. However, based on Microsoft's documentation:
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/hidclass/ni-hidclass-ioctl_hid_set_feature
It is somewhat unclear as to how I would set a feature for one particular HID device as opposed to any other from the documentation. It is a little hand wavy as to what is expected to be in a feature report.
The input buffer size, in bytes, must be large enough to hold the feature report -- excluding its report >ID, if report IDs are used - plus one additional byte that specifies a nonzero report ID or zero.
The Irp->AssociatedIrp.SystemBuffer member points to the input buffer that contains a feature report. If >the collection includes report IDs, the requester must set the first byte of the buffer to a nonzero >report ID; otherwise the requester must set the first byte to zero. The feature report -- excluding its >report ID, if report IDs are used - is located at ((PUCHAR)ReportBuffer + 1).
The documentation refers to the IOCTL as targeting a "top-level collection." but based on my reading of my own driver's disassembly it looks like you can specify features on a granular level, specific to an individual device.
Two interrelated questions here:
Is it possible to target these IOCTLs toward a specific device rather than a class of devices? If so how? If you can point me toward an example of a client that does this, that would be awesome.
What specifically is in a HID feature report/where can I find a spec that defines it?
I have 2 devices, and I am looking for a way to sync random number generation between them.
More background: The 2 devices connect, one device sends the other a file containing a data set. The data set is then loaded on both devices. The data is displayed with randomization at various levels. I want the display to be synced between the devices, however still randomized.
A conceptual example: Take a stack of pictures. A copy of the stack is sent to the remote device and stored for future use. The stacks are then shuffled the same way on both devices so that drawing the first picture on each device will result in the same output. This is overly simplified, there are far more random numbers required in my application so optimizations such as sharing the sort order are not applicable...
Breaking it down: I need a simple way to draw from the same random number pool on 2 devices. I do not know how many random draws may occur before the devices sync, but once synced it should be predictable that they will draw the same number of random numbers since they are using the same data sets, however there is a chance one could draw more than the other before proceeding to the next batch (which would require a re-sync of the random data).
I'm looking to avoid having to transfer sort orders, position info etc. for each entity already transferred in the data set at display time (which also raises structural concerns since the project wasn't initially designed to share that info) by being able to generate the same placement, which requires the random numbers come out in the same order.
Any thoughts or suggestions would be much appreciated.
You can use an LCG algorithm and set the same seed for the generation. Because an LCG algorithm is deterministic, as long as you seed both devices with the same seed, they will produce exactly the same pseudo-random numbers.
You can find more information on the LCG algorithm here:
Linear congruential generator
This LCG is used for example by java.util.Random.
If you give rand() the same seed on each device, i.e. srand( SEED );, the (pseudo-)random numbers that come out are guaranteed to be the same every time, and you can keep pulling numbers out indefinitely without reseeding.
Most random number generators let you set the "seed". If you create two random number generators, implementing the exact same generation algorithm, on two different machines (need not even be of the same type or running the same operating system) and then supply both machines with the same "seed" value, they will both produce the exact same random number sequence.
So your "sync" should really only need to transfer one number (generally itself a randomly-chosen number) from the first machine to the second. Then both machines use that same number as the "seed".
(I'd look up the specifics for the iPhone random number generators, but the Apple documentation site has apparently been affected by the Minnesota government shutdown.)
If you do not always want to specify the seed, you could simply designate one device as the master. When the master generates a random number, it sends a message to the other device containing that random number.
If it is truly random no seed number will generate the same number on second machine. It is implied that both random and chaos theories would apply.
I am looking at UUID generation in Blackberrys.
I need to be able to generate 128 bit UUIDs from last generation Blackberrys.
I have just looked through the API and it looks like the javax.bluetooth.UUID class is the way to go.
Can I assume that this API will be available for all Blackberrys? Is there another, more standard/better, way of generating 128 bit UUIDs from a Blackberry?
Edit: I also found this other class net.rim.device.api.synchronization. UIDGenerator. All I need to know is if this is available for all new Blackberries, since I'm not going to develop the app but require a 3rd party developing it to send me a 128 bit UUID.
The Bluetooth UUID class doesn't actually generated UUIDs, it's just a data representation of a UUID for Bluetooth purposes. I don't think there's a native API on the BlackBerry for actually generating UUIDs - you may need a third party library for that.
UUIDs (depending on the definition) are usually just a hash sum of the current time and the hardware (MAC) address (as those are considered being unique) of a/the network device, e.g. bluetooth or WiFi devices. If you don't need to build UUIDs conforming with specific UUID algorithms but just need unique IDs, you could just roll your own easily. Otherwise it shouldn't be too hard to implement a standardized algorithm either.
Look here for some UUID algorithms: http://en.wikipedia.org/wiki/Universally_Unique_Identifier (there are also links to Java libraries for generating UUIDs)
I have question how to generate unique serial number of machine in Delphi? I tried to do this using the ID the motherboard or processor, but unfortunately it's unfortunately supported. Partition serial numbers, etc. fall off, because it is changing after the formatted. I'm looking for something that doesn't change after the formatted. Has anyone any idea?
Inside JCL library, there are several functions very usefull for this topic:
function CPUID: TCpuInfo;
function GetMacAddresses(const Machine: string; const Addresses: TStrings): Integer;
function GetVolumeSerialNumber(const Drive: string): string;
function GetBIOSName: string;
What you're after is actually some sort of "hardware fingerprint", not an "serial number". The problem with this approach is that it's not 100% reliable. Proof: Microsoft didn't manage to find a way to properly limit OEM software to any single computer, you can actually re-install a OEM license on a new computer after a while! Once you agree there can't be a perfect solution you may look at your options and try getting something that's good enough.
For my applications I'm creating a fingerprint based on info returned by GetSystemInfo, GetVolumeInformation and (for the 'C:' partition) and a selection of registry keys from HKLM\HARDWARE (lots of registry keys actually, everything but usb, keyboard and mouse stuff). I'm reading hardware information from the registry because a Windows application can't really access hardware directly (DOS-style approaches can't work), and because I don't have time to figure out ways to determine hardware-related information for many different devices.
My approach has the following disadvantages:
Uses the partition serial number, as set up by Format. An format would clearly change the fingerprint.
Uses information about the installed drivers. Updating an driver might actually change the fingerprint! Moving a card from one PCI port to an other might change the fingerprint.
None the less, even with all of this changing information taken into account, I get collisions: Something like 1/1000 computers! There are several factors at work here:
Big OEM build many computers using the same hardware. They also clone HDD's in order to speed up software installation so different PC's might get the same partition serial number.
I'm building a very short hash from all that information, short enough so people can read it to me on the phone without too many mistakes.
This system works for me, but it will not work for you if you expect to re-identify computers once they're reinstalled.
You can test GLibWMI that extract information of several components on Windows.
It's free and source included. You can find it on my Web or in Sourceforge.
alt text http://img175.imageshack.us/img175/1250/imagen344.png
Include components for BIOSInfo, DiskInfo, ProcessorInfo,...
With this three components you can obtain information like this:
alt text http://img690.imageshack.us/img690/6006/imagen349.png
You can find the BIN/EXE of GenericDemo (all components) here; You can test all information that you can retrive with this components.
I had a similar problem back in the good old DOS days. I found out that the ROM of the installed hardware ie. video card, disk controllers seriel ports etc. was accessible directly, since they are memory-mapped. This means that I was able to create a list of installed hardware, and use it to generate a "serial number", that uniquely identified each computer (until the hardware setup was changed). I'm sure something similar is possible today as well.
Check out http://duartes.org/gustavo/blog/post/motherboard-chipsets-memory-map, if you want to use this approach.
Regards
Frank
Often the MAC address of the (a) network card is used, there are several ways to query the mac address (in Delphi) but the easiest/cleanest way is probably to use the GetAdaptersInfo API.
Here is a simple solution
Generate a GUID
Save the Guid value in the registry
Use the value of the guid as the serial number
If you a worried about security use a
hash over the ( Guid + some secret data)
I tend to agree with the "it can't be done" camp. At least not 100%, but it can probably be done "good enough" to keep the average user in line.
And if it can be done then it probably has been done. Did you check Torry's Delpi300, etc (maybe even sourceforge, although you might have to translate into Delphi).
http://www.google.com.sg/search?hl=en&source=hp&q=How+to+generate+unique+serial+number+of+machine+in+Delphi actually looks promising