Using SOCKS proxy from BSD connect level - ios

I am working with some network code on my client that connects to a server using BSD-level socket APIs (connect(), etc.). My program is written in Objective-C and platform is iPhone
I want to add SOCKS-proxy support to this, but I have not been able to find any way to do this at the BSD level. I have seen code that does this at the CFNetwork level, but I'd rather not rewrite all my networking code for this.
If anyone knows how I can add SOCKS client support at the BSD level, please let me know.
UPDATE: I am pretty sure I could implement the SOCKS protocol myself, but I'd like to avoid that if possible. Is there any 3rd party libraries that are recommended for this (hopefully open source)? They would have to be able to plug into my existing BSD-level socket code.

Related

Network extension framework versus kernel extension

I am looking to implement firewall/network filtering functionalities for macOS.
I am looking at the most secure way to do this, i.e. trying to make sure no network traffic is missed, and that my filtering cannot easily be by-passed.
After searching around, I can see that Apple has deprecated Network Kernel Extension. They recommend now to use the Network Extension framework.
However, I can see that firewalls for mac, for example Lulu and Little Snitch have moved to using Kernel Extension, and not the Network Extension framework.
Is there a good reason to do so? Do Kernel Extension allow a deeper, more secure filtering?
for example Lulu and Little Snitch have moved to using Kernel Extension
I can't speak for Lulu, but Little Snitch at least was developed long before the "Network Extension" API was introduced, it certainly didn't "move to" the NKE API. According to an article on their own blog it looks like they're actively investigating moving to Network Extensions. I suspect that as long as NKEs work without restrictions on all macOS versions they support, they'll keep using those, in order not to have to ship different back-ends simultaneously. But they probably have some kind of internal prototype using the newer APIs already to make sure they're prepared for when NKE APIs are finally removed from the OS.
If Network Extensions support your use case, you should probably go with them. If they don't, you should file Enhancement Requests with Apple, or you will be out of options when NKEs stop working.
Edit: To deploy NKEs, you will essentially need a kext signing certificate (Developer ID Application + Kext) if you don't already have one. The alternative is forcing your users to disable SIP's kext signing requirement, which is neither sensible nor reasonable in most cases. I hear Apple has made it much harder to obtain such a certificate in recent years.

MQTT protocol on Ingenico's terminal e.g. iCT220

Is there any way to implement MQTT protocol on Ingenico's POS devices? I am currently working on iCT220 on which I want to implement IOT project. In this project, I will be sending some bytes (may be 400-1000 bytes) of data to the broker (server).
There are lots of source codes for the library available in the internet, but all make use of Linux or Windows socket libraries, where as Ingenico's devices come with proprietary libraries.
Have anyone implemented similar project on the same devices? Can anyone guide me to the process of implementation?
Thanks in advance,
Pankaj
Surely, you will need to build it from source.
I had a look at several client libraries and it looks that dependencies come mostly from IP stack, so there's very little to be implemented to have it running.
You should expect the proprietary OS issues to be thing of the past in short time - newer terminal lines are based on linux.

Determine proxy type in Delphi XE7

I am currently working on an application which have to determine the type (CONNECT, Socks4, Socks5 etc.) of one or more given proxies and connect through them.
Unfortunately I have no approach to reach my goals and hope somebody can help me.
I saw in a tool (GSA SEO Indexer) that this bahvior is somehow possible. The tool has a built-in proxy finder and checker which is able to determine the proxy type:
I am using Delphi XE7 w/ Indy.
There are proxy detection protocols available, such as WPAD. You can use that to obtain details about proxies on a WPAD-enabled network, and then you can connect to them as needed.

Possible to create a zeroconf service with Delphi XE5?

Working on an appliance and would like to support zero configuration feature. That way users can look for the device on the network and simply double click an icon to access the web interface without having to configure it or know its ip address.
Tried to use UPNPLib_TLB but functions seem to be read-only; am I right? I can create a device using CoUPnPDevice.Create but can't set a FriendlyName or a URL.
Tried to use Deltics Bonjour service but it crashes on create (ACCESS_VIOLATION). The demo code uses a custom test unit which complicates experimentation.
After much research it does not look like there is a component available for this and would appreciate some pointers. Has anyone successfully created a zeroconf broadcast either via UPnP or Bonjour with Delphi XE2/5.. I can go back to Delphi 7 if required. Target = Windows 7.
NOTE: To be clear, I can find existing devices on the network and don't want to enumerate existing devices but what I want is to broadcast my service so that my box behaves like a network printer for example. The only service I need to expose is the URL so that users can access an embedded web server.
Appreciate the help!
EDIT
With the tips provided I did some research and getting this done the RAD way is not possible.
Using MS APIs directly is time consuming and requires a level of understanding of C that I don't have. Porting the Delphi 5/Indy 7 component to XE2/5 will require a good amount of work and debugging.
I discovered UPnP developer tools from Intel now open source here: Developer Tools for UPnP. This tools makes it really simply to create a server in 10-15 lines of code. Intel provides a DLL that I can call from VS Express as follows and it works great:
device = UPnPDevice.CreateRootDevice();
device.FriendlyName = 'My name';
device.PresentationURL = 'URLToEmbeddedServer";
..
I tried to use headconv7 tool to convert the .h file Intel's UPNP.DLL to a pascal file and call the external functions within the DLL directly from Delphi but there were too many problems with the conversion.
It's too bad because the Intel library makes it really simple to create UPnP stacks and the approach would apply itself very well to a component but for now its quicker to use .NET and VS Express to get the job done.
When using UPNPLib_TLB, you are not supposed to create a UPnPDevice object directly. UPnpDevice describes a known device on the network, which is why its properties are read-only.
Read the documentation:
Control Point API
Finding Devices
You are supposed to create an instance of the UPnPDeviceFinder class instead. Its search methods will give you a UPnDevice object for each device that is found.

Sockets (TCP/UDP) on iPad WITHOUT Objective-C

Is there a way to make use of iPad/iPhone's socket capabilities without using Objective-C? Is there any way to expose this functionality with ActionScript 3 or some über HTML5 framework?
On the Arduino forums I'm trying to find out my hardware limits, here and here (I found out that using Objective-C this would be possible, even with bonjour discovery).
(With webSockets, or with UDP. It doesn't have to be Haxe.)
I'm researching the possibility of using webSockets, which should be the easiest if it's possible.
However, I'd like to consider all options. So I know Arduino can talk raw UDP. And I know that there is a CocoaAsyncSocket library for Objective-C. Only, I'd like to NOT prototype in Objective-C...
(So, this will be the n-th post on Stack Overflow about a Wi-Fi-enabled Arduino that I'd like to talk to an iDevice. Bluetooth is not an option due to Apple's non-prototyping-friendly-MFi-program.)
You can use the C POSIX socket API (probably easiest, if you know C). Or you can use HTML5/Javascript and Haxe or socket.io.

Resources