The idea is to download any available media file from a DLNA server into my sequencer for processing, or even allowing a transcode through a Media Foundation interface.
After some testing I createdIUPnPDeviceFinderCallback, using it in an instantiated IUPnPDeviceFinder, searching for "urn:schemas-upnp-org:device:MediaServer:1".
I'm not sure if this string is always valid, is there a list of valid URIs ? In my system it succeeds in finding the Serviio DLNA server.
Now using the IUPnPDevice::get_Services I get an enumerator that enumerates the IUPnPService. But I'm not sure on how to proceed from now on, the documemtation seems very sparse. Now what? Some media-server specific invoke to be passed to IUPnPService::InvokeAction? What would that be?
Thanks a lot.
Related
I haven’t entirely given up on the idea of validators moonlighting as oracles for off-chain computation…based on this extensive discussion: https://gov.near.org/t/off-chain-computation-framework/1400/6
So far from studying Sputnik’s code, I have figured out the mechanics of how to upload a blob to a smart contract. Let's say that a blob represents a storage-less contract, having only stateless functions that act only on input to the function, and return those inputs modified.
Now I’m missing the piece of how Validators can download and execute the blob. As mentioned by Ilya in the link above, the NearSDK would be able to interpret the blob (if the blob is essentially a compiled contract), but it needs to be a modified version of the SDK...
Think of this like sandbox mode…blob cannot modify state of any other contract, but can read state (forget about the internet access part for now). Results of the blob execution are then fed back to a smart contract, where they have to match the results of every other validator who executed the blob. This can be done by hash comparison (rather than looping through the results individually), so it’s not an expensive comparison, especially because it’s all or nothing.
Question: how can a Validator download the blob and execute it via a sandboxed SDK, and post the result via the regular SDK to the blockchain? I am missing a lot of architectural context…and this is bringing me to the edge of giving on the idea. Please help prevent that from happening!
If you are implementing this as a separate binary, your binary will be doing next things:
Use RPC to load the WASM file from the blockchain. See RPC reference
Use runtime-standalone to run this WASM with specific inputs. An example of using runtime standalone is here, but you will need to customize this with few things.
The result should be sent as a transaction signed by this binary again via RPC.
If you want these WASM files to have access to state, you will need to load state inside this binary. There are two options:
Modify a nearcore node to also do the above items
Run nearcore in parallel, and open the database on read when you are initializing Trie (e.g. here load from disk instead).
If you want to add more host functions (like accessing internet), you will need to fork runtime-standalone to expose those functions.
If I use the IOKit methods to list USB devices, I can get something like "AirPod Case", but I don't know how to get "Francisco's AirPods". I've looked around a the various keys you can ask for, but none I've found bring up these "settable" names, only the standard "product names".
I don't know the answer as a fact, but I can give you some ideas for chasing it down:
The customised name is probably transferred as part of a higher-level protocol, or via vendor specific requests, not via standardised USB device descriptors. There is a small chance it might be advertised via a vendor specific descriptor, but this seems unlikely
I don't own any AirPods, so I don't know what kind of data protocol the AirPod case uses for communicating with a Mac, but you can try to find documentation or source code for that protocol, for example in case anyone has worked out how to use them from Linux and written a tool or library for that.
Finally, you can reverse engineer it yourself, by logging the USB traffic to and from the device when using existing software that is capable of reading the name you are after. On macOS, it's possible to do this using Wireshark. Start logging USB traffic, launch the software that talks to the device, then trawl through the logs to see if you can spot the string, then work out what request caused it to be returned.
I'm developing a specialised browser and part of that I would like to support the ipfs protocol. Thus this simple question:
How can I get a file through the ipfs protocol using Go? The browser I'm building specialised in streaming media so I need an io.ReadSeeker.
What I've tried so far:
I read the documentation... All I could find is the command line(which is useless to me as I'm considering a tighter integration/a Go API) and the shell.Get method which is undocumented and seems to require an "outdir" instead to return an io.ReadSeeker/ReadSeekCloser
We're porting our USB device dll's to use the generic WinUsb.
However, WinUsb doesn't support multiple concurrent application accss to the same device (Same VID & PID).
I wanted to know if there is a way to implement this concurrent access using WinUsb?
I read about filter drivers & services.
1. I don't want to use a filter driver because, as I understand, this will have to pass WHQL, and I rather not go this path.
2. Regarding a windows service: How exactly should I implement it? should the service get all of the calls to WinUsb, and if a different application tries to access the same device, it will close the connection to the first application, open a new connection, and back again?
Is the service the right correct solution in this case? Is there another way to implement the solution other that what I wrote?
Thanks.
A filter driver does not need to pass WHQL. You only need to sign the catalog file, needed by the driver package. This only needs a code signing certigficate from verising/... . This should be a good starting place to get to know this.
Nevertheless, a kernel driver can be hard to develop. So maybe a COM server would be a better approach. You implement this sharing from a service, by allowing COM-clients to create objects from your service and then implement some kind of sharing/mutual exclusion in your COM-server.
A COM-exe servers can be written relativly fast.
I have a windows exe app that used to sends packets to a server in the clear. This app (lets call it the client app) is definitely close sourced, but some clever hacker hex-edited the binary, and made it send packets that are scrambled.
Now, obviously, those packets are scrambled in a way that is decipherable (otherwise the server would not be able to understand it), but what I wanted to do is to write an emulator that emulates this binary app, sending the same packets to the server, and being able to unscramble the response (if it is scrambled).
The hex-ed client required an extra dll in order to run, which the old client did not. I am assuming that somehow the hex-ed client managed to load that dll (lets call it client.dll) and the function of that dll is to implement the scrambling/unscrambling, by hooking into some windows api that rerouted all packets sent from the client.exe process.
If there are anyone who can direct me on how to even get started on working out how this all works, and how I can reverse engineer the scrambing, that would be really appreciated.
I have no idea what kind of information to provide, but if there is any lacking, just reply, and I will post with more details, and if anyone wants the binaries, I m happy to provide it.
binary download for any interested parties:
http://dl.getdropbox.com/u/46623/client.dll
http://dl.getdropbox.com/u/46623/newClient.exe
http://dl.getdropbox.com/u/46623/originalClient.exe
These wont run because the resource files are required - they are about 3 gigs, so too big to upload anywhere. Names have been changed to protect the guilty =) , but that probably doesnt protect the name of the dll...
I'm assuming that the person which coded this hook which adds encryption to the packet I/O for the aforementioned program has either hooked the relevant Windows' socket APIs (WSASend, send, etc) or hooked the internal program functions used to send/receive data.
This being said, I'd suggest you use a hook detection program (e.g. RkUnhooker) to find out what is actually being hooked. Once you know what APIs are hooked you should also know where these hooks are going and from there on in you'll have to manually reverse engineer the hook functions.
As for the subject of learning how to do this, I couldn't direct you to just one tutorial to teach you everything but I highly suggest you look at the Tuts4You site, it has a plethora of tutorials which would meet all of your needs.
If possible, upload a copy of the edited client & the hook DLL, if I have the time I'll code you replica encryption & decryption functions.
You need to hook the functions exported by the additional DLL and look into the functions being called and the parameters being passed to them. This is not going to be easy since you do not have type information (e.g. the function signatures for the DLL exports.)
Look here for some information on API hooking. You will also need a good debugger try Windbg from microsoft.
As far as I can see the only option you have here is black box testing ie give known input to both systems and compare the responses against each other to find the differences and similarities.
+--------------+
Input--------->| Original App |--------->Response1
+--------------+
+------------+
Input--------->| Modded App |--------->Response2
+------------+
Now once you figure out how to use the functions from the additional dll you can use it yourself in the same way the original app does.