Wazuh API returned an error message. Error: Error executing internal command. Exit code: 1

[OsipkinVV]

Hello!

Thank you for your amazing software.

But, the issue #20 is still actual.
I think that the reason in a inconsistency of the charsets.

On the server side:

sqlite3 /var/ossec/var/db/global.db
attach database '/var/ossec/var/db/global.db' as "dbname";
pragma dbname.encoding;
UTF-8

I looked at the commit #b3c734a "Fix bug when microsoft version command has cyrillic characters" and saw that all the changes were in the file src/shared/file_op.c. In this file used function "fopen":
648 finalfp = fopen(finalpath, "w");
But on the MSDN support page

fopen supports Unicode file streams. To open a Unicode file, pass a ccs flag that specifies the desired encoding to fopen, as follows.

FILE *fp = fopen("newfile.txt", "rt+, ccs=encoding");

Allowed values of encoding are UNICODE, UTF-8, and UTF-16LE.

So, all file-IO functions should be rewritten for UTF-8 support. For example like this:
finalfp = fopen(finalpath, "w,ccs=UTF-8");

With the best regards,
Vladislav.

[OsipkinVV]

As a temporally solution I made a trigger on the 'agent' table. It's "after update" trigger. May be the best way is to create before trigger on create and on update events. But the count of OS names is not so huge, so I don't care about it. :)
So, I made the following:

1. Open DB:
   sqlite3 /var/ossec/var/db/global.db
2. Take list of all OS names:
   select os_name,hex(os_name) from agent group by os_name;
select os_uname,hex(os_uname) from agent group by os_uname;
   In my case, 'os_name' is equal 'os_uname'.
   So, I worked only with 'os_name'
3. Detect wrong OS name and take hex value of it. I had only this value: '4D6963726F736F66742057696E646F777320382E31208FE0AEE4A5E1E1A8AEADA0ABECADA0EF'
   In "Windows PowerShell ISE" write this code:

$v='4D6963726F736F66742057696E646F777320382E31208FE0AEE4A5E1E1A8AEADA0ABECADA0EF'
$([regex]::Matches($v,'..') | % {[char][byte]$('0x'+$_.Value)}) -join ''

Microsoft Windows 8.1 �à®ä¥áᨮ­ «ì­ ï
then I copy a result string to the clipboard, open URL https://www.artlebedev.ru/decoder/advanced/ and paste a string from the clipboard. The decoder has detected an algorithm: "ISO-8859-1 to CP866" and wrote the string in readable format:
Microsoft Windows 8.1 Профессиональная
4. I created a temporary file \tmp\sql.sql , opened it in the editor and wrote a code for the trigger:
nano \tmp\sql.sql

CREATE TRIGGER upd_os_name_upd AFTER update
  ON agent WHEN (SELECT count(*) FROM agent where hex(os_name) like '%4D%') > 0
BEGIN
  update agent set os_name = 'Microsoft Windows 8.1 Профессиональная', os_uname = 'Microsoft Windows 8.1 Профессиональная' where hex(os_name)='4D6963726F736F66742057696E646F777320382E31208FE0AEE4A5E1E1A8AEADA0ABECADA0EF';
END;

If you have more then one wrong name, you can add 'update' command in the BEGIN-END section.
5. Add trigger to the table:
.read /tmp/sql.sql
if you catch an error, just drop existing trigger:
DROP TRIGGER upd_os_name_upd;
6. For inactive clients, you can update the information manually:
update agent set os_name = 'Microsoft Windows 8.1 Профессиональная', os_uname = 'Microsoft Windows 8.1 Профессиональная' where hex(os_name)='4D6963726F736F66742057696E646F777320382E31208FE0AEE4A5E1E1A8AEADA0ABECADA0EF';
7. Check that all is correct by executing the step 2.

[mgmacias95]

Hello @OsipkinVV,
The solution we made for #20 was a temporary patch while we study new alternatives to deal with character encodings. Our main problem is that those characters don't come from a fopen function but from popen, so it's not that easy to fix it.

We're glad you found a temporary solution for your problem. We're working on a real solution to prevent more character encoding problems.

Best regards,
Marta

[duzvik]

Same issue.
@OsipkinVV saved my day!

[mgmacias95]

Hello,

This issue has been solved in wazuh/wazuh#478. The fix will be available for Wazuh 3.2.2 😄 !

Thank you so much for your patience,
Marta