Moderator's introduction
I invite everyone to come back into the event hall. We're starting our third part now. You can bring along whatever you haven't finished eating, that's no problem at all. We'll finish it all right here.
I'll say right away that our curtain is about to close.
Testing, one-two — and like this? OK, anyway, let's just carry on. We continue with our talks. In today's world, on the road there are almost always small witnesses with us that we probably don't even notice. These witnesses are stuck under our windshield, always amassing information, collecting it. But, again, the question is how to process and analyze that information afterwards. Sergey Eremin from LAN PROJECT will tell us about that today. Let's give him a round of applause.
So, Sergey, the floor is yours. The mic, the clicker is right here too. Go ahead. —
Talk and Q&A
Hello, dear colleagues.
My name is Sergey Eremin. I represent LAN PROJECT. At the start of my talk, I'd like to note that our company turned 25 this year, and throughout those years we've been developing hardware-software systems and software solutions for acquiring and analyzing digital information.
We supply all law enforcement and security agencies, and we hope that the products supplied by our company satisfy you in terms of quality and the completeness of the information you obtain and can use in solving and investigating crimes, as well as in detecting them. And today our systems and our software are aimed at various kinds of software — or rather, digital information objects, whether that's mobile phones, personal computers, or cloud data of some kind. We cooperate with many vendors located in the Russian Federation, and we develop various solutions together with them.
We also have extensive experience cooperating with foreign vendors. Yes, under current conditions, supplies of foreign software are difficult, but at least we see what's going on in the Western market and know their capabilities. And, where possible, we also try to implement some of those capabilities on our market. I'd also like to note right away that, to mark our company's 25th anniversary, we'll be holding an additional prize drawing from our company. To take part, please come to our booth, register separately, and after the event ends there'll be a drawing, and the lucky winners will get prizes from our company.
In today's talk I won't cover the full range of solutions we have, that we've created; instead I'll focus on one niche that we've been working on very intensively for two years now — a niche in which, on the Russian market, no equivalent Russian software existed before. That's video recorders — a large class of devices, video recording devices, both stationary and in-car. During the talk I'll go into this in more detail and tell you what we've managed to achieve and what we're planning in the near future.
That's not my presentation.
So, today I'll talk about the functionality we've already implemented, what we're planning, and we'll briefly try to compare our software with foreign counterparts. First, for those who are seeing my talk for the first time and aren't familiar with our product, I want to say that our software is called VR-Expert, and this year it was registered in the Russian software registry, which makes it fairly easy to supply to government agencies.
We essentially have two main areas we work in, which are already fairly fully implemented, and we're also working on dashcams — I'll tell you what's been done there and where the problem lies, too. Well, stationary surveillance systems are a fairly widespread type of object — in Moscow, perhaps less so, because the Safe City system there is implemented very well, practically all video systems are tied into one network, and getting information from them is fairly easy. But in the regions, Safe City isn't so widely developed everywhere, and you quite often come across standalone DVRs in various offices, institutions, and perhaps homes.
And these objects are an additional source of operational intelligence and evidentiary information. But the main problem with them is that we can't always get access to it. What's the reason for that? Practically all stationary DVRs have their own proprietary data storage system, which ordinary operating systems don't recognize. And most often — very often — we've run into situations where a disk comes in for examination, the disk gets connected by whoever received it — either a forensic expert or some officer the disk was sent to — who figures they'll just take a quick look at it, and plugs it into their workstation.
A cheerful window pops up, saying, "I've found a disk here, let me initialize it for you." The person clicks "well, yeah, initialize it" — what happens after that? The information becomes inaccessible. Whereas before, back with Windows XP and 7, only a fairly small part of the boot sector got overwritten, now Windows 10 and 11 stuff roughly the first forty megabytes with their own information. And in many cases, on most DVRs, it's exactly this area that holds all the metadata and the allocation table showing where the video streams are located. After all, essentially, most recorders on the market have no file system as such at all. That's why Windows doesn't understand it either; the recorder just knows which disk sector its video stream is stored in, and which disk sectors hold the markers indicating where each video stream lies. That's exactly what's needed to decode this data.
And what's more, every manufacturer builds this structure their own way. And what's even more interesting, over time, for some reason, they like to periodically take this information, the allocation table, and modify it in some way. At the moment we support the main file systems found in DVRs, but over the last three years a certain trend has emerged. There seem to be widely used file systems already, but for some reason manufacturers like to change them periodically. Just last week — our program is currently being piloted in several agencies — and from the feedback we received, in the past week alone two new varieties of file systems were identified: one we've classified for ourselves as TSFS, from Tantos DVRs, and we also came across a TESAM recorder, a real hybrid of the VFS file system — it uses a structure from VFS, VFS2 — and right away, let's say, the program couldn't recognize it, but after running experiments on our bench, the video became accessible, and we'll add this system in the next release.
On top of that, our programs are the only ones that can work with Dozor video recorders, which are quite widespread in various law enforcement systems. Patrol police use them, the Penitentiary Service (FSIN), etc. — you've seen them. We can work with those too and extract information from them.
Wrong direction again.
Briefly about the functionality that's already been implemented. We can work both directly with the storage media — hard disks — and with previously acquired images of storage media. We can work with data that's present explicitly, and we also do carving. The only thing is, in the course of our work we realized one thing: the method we've implemented, the carving, is very deep and takes quite a long time. So we recommend from the start: first we scan the disk, grab the data that's present explicitly, and only then start searching for deleted data. Plus, soon we'll be adding — in test form, it's already passed testing — simply pulling out parts of the video stream by signature search. This has proven itself well precisely on recorders whose disks had been initialized.
In testing we tried initialized disks; when we run them through carving, the process still takes quite a long time — a one-terabyte disk takes us about three weeks to process, unfortunately.
The file system is built in such a way that we can't speed up the process yet, but that's exactly why we decided to add another algorithm: a search by video stream signature. We've tried it, it works quite well, the main data you need is already accessible.
After processing the image we get the disk contents, and we immediately sort it by camera, by date, by time; there are various filtering and search options. And we tried to make the interface, the program, accessible and easy to understand not only for specialists who deeply understand the structure of the process — forensic experts, for example — but we tried to make it intuitively simple so that even untrained officers could, in principle, analyze the disk contents and conduct an inspection. For example, so that in certain cases an investigator could, with no specialist, conduct an inspection and quickly review the disk contents. Because, as you know, in practice specialists are in high demand, and you can wait a long time until one frees up. And, well, since it's perfectly safe, you can look at the contents yourself.
So there's a video viewer, you can view the contents right away, export what you need, and we can export video files individually, and we can also do a frame-by-frame breakdown of a specified region, of the frames you need, for further analysis or for attaching to the report. Plus we also generate a report, quite a detailed one, with information about the disk contents. But there's also a mechanism for deeper examination of the disk contents: there's a built-in hex viewer, which you can use to analyze part of the information and obtain any additional information you need, in case for some reason it wasn't found by our automatic mode. In such cases, please let us know as well.
And briefly, let's go over once more what we've already done to make our program work. We reworked the user interface, simplified it a bit taking into account the feedback from users who had already been using our program. We updated and added a logging mechanism for all the actions the program performs. We optimized the file system detection algorithm. And now there's additional functionality where we can manually specify right away which file system it is. We can even look manually in the hex editor at what's there, if auto-detection didn't work. We look at the disk contents, and if we see clear signs that a file system is present — say, just last week we came across a disk that had been initialized perfectly normally in the recorder, but we noticed an interesting peculiarity. Before the disk was put into the recorder, it had been used as a storage drive in some personal computer, after which the user pulled it out of the PC and moved it into the video recording device, the DVR.
Then it was formatted using the recorder's own tools, it recorded normally, but it turned out that when the recorder was creating its file system, seeing that sector zero was already occupied, it initialized it not from sector zero, as it usually does, but a bit further on. Starting somewhere around sector 40, its initialization table began, and in automatic mode we missed it. But we tried the mode where we manually say, yes, this is exactly this file system, and the program ran and picked up the file system, and everything worked normally from there. We added support for working with E01 images, because, well, everyone knows it's a widely used forensic data storage format.
We optimized the algorithm — originally, when the program first came out, ordinary file systems like FAT32, that is, ordinary car dash cams, basically weren't recognized. Well, the program's original concept didn't call for it, but one of our users asked us — they wanted the program to handle ordinary file systems too, and we added that mechanism. And later I'll say what else, basically, what for, and what exactly we now plan to finish implementing. We already have test builds ready; I hope we'll include it in a release soon. And most importantly, we've developed a new module for analyzing video data that uses artificial intelligence algorithms.
If you've already visited our booth today, you may have already seen it — basically, what results this module can offer us at the moment.
What's special about the module is that we don't tie it specifically to data obtained from VR-Expert; it simply imports ready video streams directly. And those video streams don't necessarily have to be obtained with VR-Expert — they can come from any storage media you have. Say you've analyzed a phone, and in the phone you saw there are some video images — and not just video, actually: our module works not only with video, it also works with ordinary static images, JPEG, BMP and all the formats. And with our new module we can analyze those too. That is, we can either load a single file into it, or we can load a batch of them and run the analysis. And the result of the analysis — moreover, we get it as ready-made fragments of specific images, I'll say which ones in a moment, and then we store all the necessary information about the results in an SQLite database, which later lets us run various data analysis and cross-match the data.
So, the first thing it's needed for is detecting different types of objects in an image. Either across the whole image, or we can define separate zones that the processing will work on. Why the separate zones? To improve the results considerably and to solve specific tasks.
Also, at the request of one of the units, we added a feature: if an object enters a monitored zone, and if you enable the tracking function, then once it enters that zone it will continue to be detected everywhere it has been spotted.
So, at the moment we already have the following classes: people, bicycles, cars, motorcycles, buses, trucks, and we've also added a detection feature.
Right at the start of the job we specify whether to search only within the area or to track the object's entire path. And we've also added license plate recognition. And specifically for this object we added the option of applying an unsharp mask filter and magnification. Again, plate recognition depends on the image quality. And now we're also adding a function where, once a plate is recognized, we accumulate the license plate images from that object, so that later we can pass that data on to the VD-Expert program, which is designed for video-technical forensic examinations and research, and which also includes image enhancement analysis functionality. That's exactly one such method. I think those who've worked with it know this mechanism was widely… You can do it manually in Photoshop, of course, or in GIMP. This mechanism is well implemented.
It used to be in the foreign Amped FIVE. Now this mechanism is implemented quite successfully in VD-Expert. I think if there are people here working in the video-technical field, familiar with it, I think you know this program, you're a forensic expert, a good enough professional.
So in this case we can determine the plate's contents with the help of a video-technical expert. For now our model is tuned specifically to Russian license plates. Going forward we'll be adding models for other countries.
What happens after the processing is finished? We've set the parameters we need for the processing. After the program has finished its run, we can now export, either by class or by a specific object, the resulting image and the information stored in the database. We can save only the individual frames we're specifically interested in. It all depends on what you want.
So what is our program's mechanism based on? We use modern PyTorch models, and moreover, we create our own models. Sometimes, at your request, we can add some specific category you're interested in. Also, during analysis, right away, if you already have some specific model you're interested in, you can load that model during analysis, and the program will work with precisely that model, the one you loaded yourself. We think it's a fairly convenient solution. If you have any suggestions or wishes on this topic, please also come up and talk to us. We'll gladly take your opinion into account and try to implement it.
We added GPU support for data processing, which let us significantly increase image processing speed. In our tests, when working with a single object, a 30-minute video initially on the CPU alone, the processing took, unfortunately, 25 minutes, but when using a graphics card, one object, a 30-minute video, takes around 3 minutes. And there we already have our result. Again, you have to understand that it all depends on the input image quality. There are no miracles: if little information was captured in the video, unfortunately, there's nothing we can do. That was what we've already implemented. And now, what we plan to do in the near future and our plans going forward.
First, we're currently training additional models. In the near future we'll add electric vehicles and certain types of weapons. If you have any other wishes or ideas, we'll also gladly hear your opinion and implement it. There will also be additional filtering by object color — car color, clothing color. That will also be an additional classifying feature that we'll take into account in searches. Face search functionality will be added soon, and much more. Here, of course, we could go on forever inventing scenarios to our own taste, but the better approach is your feedback — which tasks you encounter most often. That's what we'll implement. We're waiting for your feedback.
Also, in the near future there'll be a full port of the engine to a cross-platform system. On Linux, the program started working in test builds roughly six months ago, but, let's say, the engine wasn't quite, let's say, fully ported. We ran it through workarounds; now it'll be fully cross-platform. That is, the engine will work fully both under Linux and under Windows. And we're testing on all the operating systems recommended for use in the internal affairs agencies. And I think we'll fully implement that by the end of the year.
We also plan in the near future to finish what I mentioned earlier about car dash cams. What's the most painful problem with car dash cams? 90% of car dash cam tasks are dash cams that come in for examination after road traffic accidents with the last file's recording unfinished. I don't think it makes sense to explain the recording algorithm. I think you all know why this happens anyway. First comes the video stream, and only then the metadata about where that video stream is located. So, manually, we've already almost fully implemented this algorithm for most file systems. Now we're finishing automating this process, so that the program recovers this data practically in automatic mode. But if you happen to run into such a task right now and can't solve it, we have our own lab. Please get in touch, we'll help you obtain the video information you need.
And now, briefly, let's go over where our program matches its foreign counterparts and where it differs. Well, support — extraction from various data sources — here we match. On most of the points we analyzed, we match. Except that we found the Korean program doesn't always work correctly with password-locked DVRs. But the problem is solvable. We know how to bypass that, and we do. This mostly applies to the "Dozor" line of DVRs. We can crack and bypass passwords on "Dozor".
MD-VIDEO has no explicit support for proprietary formats; we have it, and DVR does.
The version of DVR Examiner available in Russia has no artificial intelligence capability; we have it, and MD-VIDEO has it. Recovery of deleted video files is an implemented feature in all the software products.
Here there's parity too. We tested the speed of our program against the foreign counterparts. In terms of speed we basically match them. Unfortunately, deleted files are extracted slowly everywhere, but to speed things up we're now adding signature search as well, and on most DVRs, on most video streams, that'll be useful, it'll work.
And we also currently have video storyboarding in development, which isn't explicitly implemented in DVR Examiner or MD-VIDEO. A HEX viewer is also implemented only in ours. And we're also now working on support for, let's say, RAID systems found in DVRs.
Unfortunately, those are showing up more and more often these days. And most importantly, only our program has a Russian-language interface. The foreign counterparts don't have Russian in the interface at the moment.
And after all, only our software is registered in the Russian software registry, but we noticed that for full-fledged operation you still need fairly high-performance hardware.
On weak machines it runs quite slowly. We're now fully defining the system requirements that will be the most future-proof.
And as is our tradition, given that, for the most efficient operation, we generally prefer the software to ship together with hardware optimized for working with our software, which will let you get full access in any situation to the necessary information and, where possible, get it fairly quickly. The kit includes, where possible, various disk imagers and write blockers to ensure data integrity. Quite often. What are the imagers for? In the kit we deliberately prefer to supply additional storage media. Why? Quite often, from my own experience I can say, it has happened: you absolutely need the information from a specific DVR. Large volume, requiring lengthy analysis.
And there it is, a DVR from a garage cooperative. The garage cooperative had to be left without surveillance for a week, because at the time it took a week to pull the video. If there'd been a VR, it'd have been much faster. So, even arriving at the scene, you'll have somewhere to copy the information and then examine it later at your leisure.
We also include a set of tools in the kit — for all occasions. And if needed, the hardware kit can also include our software. If the drives in the DVRs are already quite problematic, the kit can also include ACE Lab equipment for working with worn-out DVRs. In an alternative configuration you can also use foreign software, for example, from SalvationData or from GMDSOFT, MD-VIDEO — Hancom is now called GMDSOFT. Because the wider the functionality and the more software products you have at your disposal, the greater the likelihood that you'll fully cover all the different formats and peculiarities of video data layout, and get the information you need sooner.
I'd also like to say that this year our company obtained a license to conduct educational activities and we've developed training courses on working with software, covering all the software products available on the market for extracting information from various sources, including phones, hard drives, and DVRs. In some cases we can develop additional training programs to your wishes and needs, on some specific topics. If you need them, if you want to look into them in more depth. If you have such requests, come to our booth and we'll discuss it. Or you can write to our contacts and we'll discuss it.
We're customer-oriented and will try to find the best deal for you. And moreover, as I've already said, our company has its own laboratory, where we also help law enforcement officers obtain information from various devices. If you've got some object where you can't get access to the information with your own tools, contact us, we'll try to help you. Always glad to see you.
For any questions, you can contact our Telegram support channel. All the contacts are at our booth; come by, we'll be glad to see you. What questions do you have, dear colleagues? Sergey, thank you. Colleagues, questions?
Alexey, please come over with the microphone.
Hello, thank you for the talk. Could you tell me, there's one point that's still a bit unclear. The AI-based video data analysis module. You said any data source can be added. Do you mean any data source at all? I mean, any video recording, not necessarily obtained from a DVR. You have a set of video files, you can load it, and it'll be analyzed. So do I understand correctly, if, say, it's a file system extraction from a mobile phone, you can also add the archive?
Yes. The only thing is, for now it doesn't go into the archive itself; you just need to pull the video file out of it, hand it to the program, and it'll process it. Thank you. Plus, in the near future an image categorization module will be implemented as well. If you have wishes about which types of objects you'd like to see, get in touch, we'll implement them. There's already a draft version, almost ready. —
— Colleagues, more questions? Alexey, I see another hand over there.
Tell me, please, Sergey, isn't LAN PROJECT working on determining the speed of a moving object? —
— No, we're not, and we don't plan to. That task has already been implemented quite well by the company OT-Kontakt in their software product DTP-Expert.
We work in very close cooperation with OT-Kontakt, and basically it's possible to supply VR-Expert and DTP-Expert as a bundle, which would let you solve this task in one package right away.
Sergey, good afternoon. Could you tell me, can you search by the objects your software has detected?
— Search by object type? It sorts it all by object type precisely, and then we can search by them. We deliberately made it so all the information we've extracted from there is also stored in SQL, and then with SQL queries you can quite quickly find information by a given criterion.
Does it work with additional sensors, for example, a gyroscope, G-sensor? Not yet, nothing implemented. We could think about it, we'll see. One more question. Is there GPS support and visualization, if we're talking about… Not yet. In principle, if it's in the video stream, yes, we could try, we could extract it as well. I think that's a good idea. But that'd be in some separate window, right? Yes, plus we haven't fully finished it. We'll finish it by file creation times, and we also plan to add that when there's a date and time shown on screen, we'll additionally recognize it and compare. We're planning that now too, to determine the recording date and time more exactly. Okay, thank you. —
— So, colleagues, let's send Sergey off with applause. We're running a bit over time again. And colleagues, once again, a reminder about the extra prize draw in honor of our company's 25th anniversary. Come by our booth. —
— All right, thanks.