DEV Community: Damjan Cvetko

VSCode PHP Debug Release September 2021

Damjan Cvetko — Fri, 15 Oct 2021 21:29:46 +0000

This is a small writeup on the September 2021 release of VSCode PHP Debug adapter extension. A cover issue describing all work can be found on GitHub issues.
I intended to do a "release" every month, but I just do incremental releases and write up a monthly (or so) report... It was summer :)

## No-folder debugging

A large task was the No-folder debugging. This is when VS Code has the purple status bar, no folder is open at that time, and so no launch.json file is available. I was actually brought to my attention by Microsoft's VS Code PM. We had a conf call and discussed what can be done to make PHP debugging in VS Code simpler. Especially the initial setup.

The changes that came out of this are the no-folder debugging and VS Code settings for the location of the PHP binary. And the quick run/debug icon in the editor. The extension had to transition from a pure DAP implementation into a hybrid one. Now there is also native extension code being activated when debugging starts.

There are plans to further improve PHP and Xdebug setup for new users.

xdebug_notify()

This is a new feature of Xdebug that I helped to define. It is very similar to console.log(). If a DBGp connection is active it will send whatever is the parameter to the IDE in the form of a property.
The ide was to provide similar facilities to Windows Debug channels. My initial idea was to use the stream concept of Xdebug, but we later decided to go with notify.

Logpoints

A long standing Pull Request was cleaned up and merged. Logpoints are like breakpoints but they do not stop execution, just print text to the console.

Hit-Count conditional breakpoints

Another old Pull Request was cleaned up and merged. Hit-count conditional breakpoints allow the user to set when the breakpoint will actually stop, depending on the number of hits a breakpoint receives. This functionality is provided by Xdebug. Only conditions >=, == and % are available.

Facets

With PHP 8 came readonly properties and enums. Xdebug provides this information in the facets attribute of the property structure. This is now processed, but does not have a real impact on the UI... yet. Both readonly and enum cannot be edited. Processing this flags allows us to prevent that on the UI.

Max connections

Another late feature that came in - altho already in october - is the maxConnections launch parameter. It restricts how many connections at a time can be active. When max connections are reached any new connection will be dropped and PHP will continue execution without debugging.

Conclusion

I'm always happy about feedback and would always like to know how to make debugging experience better. I'm currently focusing on DBGp Proxy and Xdebug Cloud support.

VSCODE PHP DEBUG RELEASE MAY 2021

Damjan Cvetko — Fri, 11 Jun 2021 08:20:58 +0000

This is a small writeup on the May 2021 release of VSCode PHP Debug adapter extension. A cover issue describing all work can be found on GitHub issues.

Switch to Xdebug 3 port

Since Xdebug 2 has been deprecated for a while now, this plugin has switched to default port 9003 - from previous, 9000. The change in Xdebug was introduced by Derick due to often conflicting default PHP-FCGI port also being 9000.

Now when a new launch.json file is created, the default listen port will be 9003.

Auto local port

This feature allows the user to explicitly set port parameter to 0 and this instruct the operating system to allocate a random TCP port to listen on. There are two reasons for this feature/change.

First this is a stepping-stone for implementing DBGp Proxy support. In that case you should use a random local port because more than one user can be working on one system and the well-defined port 9003 is already used by the proxy.

Second this gives a nice way to completely separate debugging of Launch currently open script. Let me explain.

Xdebug/DBGp debugging works so that the debugging engine (PHP+Xdebug) connect back to the IDE (VSCode and this extension). This means that the IDE must LISTEN on a TCP port and the engine connect to that port. This extension must implement Microsoft Debug Adapter Protocol and the way things are designed different debugging sessions cannot interact with each other.

When launching a script for debugging the DAP instance creates a process, tacks is and at the same time creates a DBGp listener and waits for the Engine to connect. What if you want to debug two scripts in parallel?

You can start the Listen for Xdebug configuration and run both scripts from command line, but the adapter cannot track their execution and display output. That might be ok for a lot of cases.
If you try to start two of them in the IDE, you will get a PORT IN USE error for the second, because the first debug session is already listening for connections. You can create a different debug configuration and specify a different port. And then also ask the second php script to connect to that different port. So, possible, but a hassle.

The solution for this is to allocate a random port and pass the port configuration to the script.

What happens here is that using the environment variables we configure Xdebug to start the debugging process right away and with correct port. See Xdebug docs. So the only thing that needs to be taken care of is to make sure that Xdebug extension is loaded into PHP. Even that could be solved with runtimeArgs if we made sure that the downloaded xdebug.so is in the right place.

Of course, all these defaults can be changed.

Built-in webserver start configuration

The third configuration change is the PHP built-in web server. There is a generic launch.json attribute serverReadyAction. It is used for this specific situation, where you run a program that exposes a web server and the IDE detects the host/port combination and opens a web browser.

You could already use the launch configuration to start the Built-in server, but as a requirement you needed to pass a router script. This limitation was removed and an example configuration is now provided.

Here the DBGp port is fixed (9003) and the web server port is randomized. This can easily be changed to, for example: "localhost:8080". The same way a randomized DBGp port could be used by setting "port": 0 and adding env "XDEBUG_CONFIG": "client_port=${port}".

In fact, if you cluck Add Configuration... and select Launch Built-in web server the IDE will guide you through placeholders.

More on launch.json attributes can be found in the official documentation.

Launch configuration for Xdebug 2

For legacy support, some Xdebug 2 specific snippets were also provided. They do not appear by default in a newly created launch.json but can be added later by clicking the Add Configuration... button.

Bug fixes

A bug in how virtual files were handled was fixed.

Support for extended properties was added and turned on by default. This causes all variable names to be decoded in UTF-8. Altho this is not necessarily correct for all scenarios it does cover a lot of them.

Default Exception filters

The default exception filers are now turned off by default. This was done to mimic other PHP IDEs.

There is currently no real support in VSCode to flexibly control Exception breakpoints. Ideally one could have a way to specifically define what Exception class to break on and wat to ignore. Currently the best thing one can do is use the ignore attribute.

Logging

I currently ask users that open bug reports to provide a xdebug.log output. This shows what DBGp commands were exchanged between Xdebug and this extension. This proved to be problematic in a lot of cases. This is why I decided to included all received DBGp protocol data in the log output. Just add "log": true to your configuration and you should see a lot of protocol data.

Conclusion

Although not a lot of visible changes in this release, we are one step closer to a more current debug experience while also preparing the field for bigger changes coming ahead. As always drop me a GitHub issue if there's something broken or if you can't seem to get debugging to work.

Mysterious Camera Pairing

Damjan Cvetko — Fri, 13 Nov 2020 23:25:53 +0000

This is a report from my own [blog].(https://damjan.cvetko.org/blog/2020-11-06-camera-pairing/)

While working on an Android project, one of my tasks was to integrate a home camera into the app. Its a popular Chinese product and the vendor provides an SDK and (barely) some english documentation. The SDK uses an “audio pair” feature, where sound is used to transfer Wi-Fi type, SSID and password information to the camera. However after performing an SDK upgrade the pairing process started to work without sound, like magic. This is a dive into this mystery.

The What

For some more context, why this was an “adventure”: The vendor provides the SDK for various platforms, among others: Android, iOS, Windows, Linux. Given that the functionality in the SDK includes at least network protocol implementation, encoding/decoding, remote file handling and device pairing it's almost natural that the bulk of the code would be provided in a cross-platform manner. So the SDK provides a few .so (.dll) libraries and some platform specific wrappers. In case of Android some JNIs. Naturally, the .so files were NOT accompanied by their respective C source equivalent.

The Why

As said, after an (incompatible) upgrade of the SDK the pairing process changed. There was no more sound that carried the Wi-Fi data, however the camera still received the entered Wi-Fi parameters and successfully connected the the network.

How is that possible? How could it be? Are the Chinese sending the data over some spy satellite??

What can a guy do. Reverse it.

The Tools

Seeing as we'll only get an answer from the code this seemed a great opportunity to try out something that just came up on my radar. I read about Ghidra available on https://ghidra-sre.org/. It's a free and OSS reverse engineering tool from the NSA.

After struggling a bit with the Java madness, learning about setup, options and navigation, I could look at the (not great, not terrible) restored C code of the pairing routine.

What we can see is that it constructs an address (sprintf) and sends some static data to it with sendto, typical for UDP traffic. After digging through some more code I knew that the routine took a pre-constructed byte array of data containing the Wi-Fi parameters and was processing this byte by byte, effectively encoding one byte at a time into the sending address. This can also be seen on a network dump using Wireshark.

But for the love of it, how did the Camera, that was not connected to the Wi-Fi, not knowing the encryption parameters of the Wi-Fi, get this information?

The How

Actually, after getting this far, I already knew the answer. I knew that 239.x.x.x was Multicast, and that when sending Multicast part of the address gets encoded into the MAC destination. An example for the first packet from Wireshark would read:

Ethernet II, Src: 0x:xx:xx:xx:xx:xx (0x:xx:xx:xx:xx:xx), Dst: IPv4mcast_2d:00:29 (01:00:5e:2d:00:29)

And a little bit of research confirmed the other part pd the mystery. On Wi-Fi, even though we have encryption, the L2 layer, the MAC addresses are actually in plain text.

This means that the camera can listen on popular Wi-Fi channels for multicast packets, with specific contents. The first 3 MAC octets are 01:00:5e for IPv4 multicast, the forts is a checksum, used to verify the validity of the data, the fifth is a sequence and the last one is the data byte. And each data byte gets sent 4 times.

Conclusion

Any technology, no matter how primitive, is magic to those who don't understand it.¹

What did I learn: Knowing your basics is important. Ghidra.

A variant of Clarke's third law: https://en.wikipedia.org/wiki/Clarke%27s_three_laws ↩

Bridge ssh.exe to Pageant

Damjan Cvetko — Sat, 22 Jun 2019 22:41:52 +0000

I do a lot of PHP and was a really early adopter of remote debugging (XDebug) however last few years my work setup just didn't let me do this. Then I wanted to trey Visual Studio Code Remote Development that seem to be just the right thing I was looking for, however there was big red stop light right at the start:

Note: PuTTY is not supported on Windows since the ssh command must be in the path.

This just cant be! I know too much of the SSH protocol to let this stop me.

The end result of an all-nighter was this script that allowed me to use my existing ssh keys stored in Pageant and try out VS Code Remote...

https://github.com/zobo/weasel-pagent-win32