Reverse engineering van de TrackerOne / WanWay S20 Pro GPS-tracker

Sc0ps · August 3, 2026, 2:18pm

Hoi allemaal,

Afgelopen vrijdag ben ik voor het eerst bij RevSpace langs geweest. Ik wilde graag eens kennismaken en de sfeer proeven. Daarnaast leek het me leuk om te ontdekken wat RevSpace precies is en of ik me er thuis voel. Wie weet word ik in de toekomst wel deelnemer.

Tijdens de IRC-chat heb ik mijn project gedeeld, omdat ik op dit moment niet goed weet welke stap ik het beste als volgende kan zetten. Er kwamen meteen leuke reacties en de suggestie om hiervoor een forumtopic aan te maken, zodat ik mijn bevindingen kan delen en anderen kunnen meedenken.

Bij deze dus.

Het project

Ik ben bezig met het reverse-engineeren van een TrackerOne / WanWay S20 Pro GPS-tracker.

Het doel is om de tracker met mijn eigen Traccar-server te laten communiceren in plaats van met de cloud van de fabrikant. Ik wil hem gebruiken om Roparun Team 245 tijdens de Roparun live te volgen, zonder afhankelijk te zijn van de servers van de fabrikant.

Tot ongeveer vier maanden geleden was dit eenvoudig mogelijk via SMS-commando’s zoals SERVER#, PARAM# en APN#. Na een FOTA-update van de fabrikant zijn deze commando’s uitgeschakeld en gebruikt de tracker nu een nieuw, grotendeels onbekend commandosysteem. Instellingen uitlezen lukt nog wel, maar wijzigen lijkt volledig geblokkeerd.

Dit is mijn eerste echte reverse-engineeringproject. Mijn doel is niet alleen om deze tracker weer volledig onder eigen beheer te krijgen, maar vooral ook om onderweg veel te leren.

Tot slot

Het lijkt me leuk om hier op RevSpace eens samen naar te kijken. Zo hoop ik niet alleen verder te komen met dit project, maar ook veel te leren van de kennis en ervaring die hier aanwezig is. Tegelijkertijd lijkt het me een mooie manier om wat mensen te leren kennen en een beter beeld te krijgen van hoe alles binnen RevSpace werkt.

Ik zal dit topic gebruiken om mijn bevindingen, foto’s van de printplaat en nieuwe testresultaten te delen. Als iemand ideeën heeft, een keer wil meekijken of gewoon nieuwsgierig is, laat het vooral weten.

Sc0ps · August 3, 2026, 2:34pm

Eerste technische bevindingen

Zoals beloofd hierbij mijn eerste technische bevindingen. Een deel hiervan had ik eerder al op het Traccar-forum gedeeld, maar ik plaats het hier ook zodat alle informatie op één plek staat.

De tracker is een WanWay S20 Pro (TrackerOne) en maakt gebruik van een BC78(S) CAT1-module, gemarkeerd als EigenComm. Met het commando <CKVER> krijg ik de volgende firmware-informatie terug:

<VER:SDK:BC78SV2.07S250508,APP:#S20Pro#***************>

Intern verwijst de firmware naar:

BC78_V2.07 250508

UART

Tijdens het opstarten krijg ik via UART onder andere de volgende output:

^boot.rom'v'!
RDY
enter factory test timeout ...

Daarna volgt een uitgebreide debug-uitvoer met onder andere:

Q:one.gpsog.com:9760
T:0.0.0.0,0,10

IP:47.52.50.49,1234
LOG IP:47.52.50.49,4542

AGPS DNS:iot.bsjyun.com:9885

Daarnaast verstuurt de tracker regelmatig berichten zoals:

<TXT*S:*********** *3G:...>##

Tot nu toe heb ik vastgesteld dat de UART wel uitgebreide debug- en statusinformatie geeft, maar dat het mij nog niet is gelukt om via deze interface commando’s naar de tracker te sturen. Via USB meldt het apparaat zich heel kort als meerdere ACM-devices aan en verdwijnt daarna weer. Ook daar heb ik nog niet kunnen achterhalen wat er precies gebeurt.

SMS-commando’s

Sinds de FOTA-update werken de oude SMS-commando’s zoals SERVER#, PARAM#, STATUS# en APN# niet meer.

Wel blijkt de firmware gebruik te maken van een nieuw commandosysteem. De volgende commando’s werken onder andere nog wel:

<CKVER>
<CKPARA>
<CKNET>
<CKGPS>

Bijvoorbeeld geeft <CKNET> de volgende reactie:

<CKIP*Q:one.gpsog.com:9760>

Mijn huidige vermoeden

Op basis van de UART-output lijkt het erop dat de firmware een nieuwe commandostructuur gebruikt.

Mijn huidige vermoeden is dat:

CK de read/check-commando’s bevat.
BSJ en SPWW gebruikt worden voor schrijfcommando’s.

Daarnaast zie ik in de debug-output:

Q:one.gpsog.com:9760
T:0.0.0.0,0,10

Mijn vermoeden is daarom dat Q verwijst naar de standaard cloudserver van de fabrikant en T bedoeld is als gebruikersserver (override).

Pogingen om de server te wijzigen

Ik heb inmiddels verschillende BSJ- en SPWW-commando’s geprobeerd om de serverinstellingen te wijzigen, bijvoorbeeld:

<BSJ*T:xxx.xxx.xxx.xxx,5015>

en

<BSJ*T:xxx.xxx.xxx.xxx,5015,10>

Tot nu toe zonder succes. De tracker blijft na controle met <CKNET> steeds terugvallen op:

<CKIP*Q:one.gpsog.com:9760>

Servercommunicatie

De tracker communiceert standaard met:

one.gpsog.com:9760

Wanneer ik handmatig verbinding maak met deze server via netcat en de gebruikelijke login stuur:

##,imei:**************,A;

krijg ik als antwoord:

LOAD

Dat doet vermoeden dat de eerste communicatie met de server in ieder geval nog plaintext verloopt.

Huidige status

Op dit moment kan ik:

de firmwareversie uitlezen;
parameters uitlezen;
netwerkinstellingen uitlezen;
GPS-informatie uitlezen.

Wat nog niet lukt is:

de server wijzigen;
de APN wijzigen;
een eigen server configureren.

Mijn vermoeden is dat de FOTA-update deze functionaliteit bewust heeft geblokkeerd. Mijn volgende stap is daarom om verder te kijken naar de hardware, de bootloader en uiteindelijk een manier te vinden om een firmwaredump te maken. Ik ben benieuwd of iemand ideeën of suggesties heeft voor een goede volgende stap.

shiz · August 3, 2026, 4:16pm

Leuke eerste post, van harte welkom!

Ik ben even naar de website van de maker gegaan, en die lijkt een configuratieprogramma te hebben met “remote update function”. Zelf ben ik altijd groot fan van de firmware dat op het ding draait verkrijgen en door een disassembler halen zodat je kunt zien wat 'ie doet, dus misschien kan dat programma firmware-updates van het internet halen zodat we die kunnen analyseren.

Afijn, het programma lijkt een .NET-binary te zijn:

IOPConfig.dll: PE32+ executable (GUI) x86-64 Mono/.Net assembly, for MS Windows

.NET-binaries zijn best goed te reverse-engineeren, aangezien het een vrij high-level programmeeromgeving is. Één rondje door ILSpy heen later kunnen we al wat dingen zien:

Mijn ogen vielen op een klasse genaamd IOPConfig.Controls.FP_DownloadBatchView, met het idee dat het ófwel dingen ván de vendorserver zou kunnen downloaden, ofwel náár het device (terminologie voor het programmeren van een device kan nog wel eens verwarrend zijn). Either way is het interessant, en de nested klasses lijken veelbelovend:

InstallDownloaderToolAsync klinkt interessant, en wat gerommel in async C#-code later geeft ons dit:

CS$<>8__locals6.UpdatePrompt("Fetching downloader package list...", (Brush)(object)Brushes.Orange);
ServiceApiAuth.Load();
Uri requestUri = new Uri(GetServiceBaseUri(), "/api/public/download-tool-drivers");
<listRequest>5__2 = new HttpRequestMessage(HttpMethod.Get, requestUri);

ServiceApiAuth lijkt lekker overeen te komen met een bestandje in de Config-map:

{
  "BaseUrl": "https://iopconfig.com",
  "HeaderName": "X-Api-Key",
  "ApiKey": "XtKYfG1VDGk9kqyfBWqKg0Q6u0aU1A8Djhndb5FojE68Nl5ZU0Yup9ISWAwyRPGXOi2IQpcFBldTw8y55htc3CcNuPjmrZrXuSbYCb7P4dpkRekrVukMWDHll8YIxO7P"
}

En dit lijkt al ons genoeg info te geven om zelf eens dit endpoint aan te roepen:

$ curl --header 'X-Api-Key: XtKYfG1VDGk9kqyfBWqKg0Q6u0aU1A8Djhndb5FojE68Nl5ZU0Yup9ISWAwyRPGXOi2IQpcFBldTw8y55htc3CcNuPjmrZrXuSbYCb7P4dpkRekrVukMWDHll8YIxO7P' https://iopconfig.com/api/public/download-tool-drivers | jq
[
  {
    "id": 1,
    "manufacturer": "IOPConfig",
    "chipset": "EG915",
    "typicalDevice": "QMulti Downloader",
    "fileName": "qmulti_v4.1_nolic.zip",
    "fileSize": 188291195,
    "sha256": "79772d98a18fdbc8ba4b058e630a5b85161a8f721ecb2772dd98d146a1453f75",
    "downloadUrl": "/api/public/download-tool-drivers/1/download"
  }
]

We kunnen dezelfde API gebruiken om dat specifieke bestand te downloaden, waar een treasure-trove aan tools en firmwares in lijken te zitten. Nergens wordt er specifiek gerefereerd naar onze BC78-chip, maar we zien wel een referentie naar EIGEN in EFlashTool, waarschijnlijk voor Eigencomm:

$ rg -i eigen
EFlashTool/1/config.ini
11:arg_pkg_path_val =F:\14_Firmware\EIGEN\EG915Q\EG915QNALGR01A01M04_01.001.01.001V01\at_command.binpkg
45:filepath = F:\14_Firmware\EIGEN\EG915Q\EG915QNALGR01A01M04_01.001.01.001V01\ap_updater.bin

Het is in ieder geval een device wat draadloze connectiviteit heeft, dus moet het bij de Amerikaanse FCC geregistreerd worden, die (beperkte) documentatie publiek beschikbaar stelt. fccid.io is een (third-party) interface voor de normale wat minder bruikbare officiële site, dus misschien komen we zo iets meer te weten over wat erin zit. S20 leeft niet veel nuttigs op, maar de BC78-markering wel: FCC ID 2AQSK-BC78-NA - 4G module

De handleiding op de FCC-website heeft een mooi blokdiagram wat ons vertelt welke chip er ín zit:

Oftewel, een Eigencomm EC718! Daar vinden we véél references naar in het gedownloade tooltje:

$ rg -i ec718
QMulti_DL_CMD_V4.1_WanWei_NoLic_R2/EFlashTool/1/config_pkg_product_uart.ini
13:arg_pkg_path_val_comment1 = .\image_ec718\named_product\ec718s\pkgdir\at_command.binpkg
16:arg_pkg_path_val = .\image_ec718\named_product\ec718s\pkgdir\at_command.binpkg
22:selected_product = EC718S_PRD
24:selected_base_inicfg_rec = C:\Users\ivan\Documents\projects\ec616_00\release_ec616_01\jwzhuang20191121_20191031_flashtoolcli\FlashToolsEC618\FlashToolCLI_V4.1.9_20231124\product_sets\ec718_products\ec718s\base_config_files\config_ec718s_prd_uart.baseini@hash:3e4f9ea5bacfa839f07c0804796cb896ef1778dc48695186186875064d323c8a
29:agpath = .\product_sets\ec718_products\common_data\agentboot_uart\agentboot.bin

...

Ook erg fijn is dat in de EFlashTool-directory een handleiding staat die je precies lijkt te vertellen hoe de bootloader en updateprocedure werkt:

Door een BOOT-pinnetje kort te sluiten naar ground lijkt ie in bootloader-mode te gaan, waarna je er met FlashToolCLI tegenaan kunt praten. Dit was even een resultaat van een uurtje vervelen, misschien dat je met deze info al verder kunt?

Sc0ps · August 4, 2026, 9:16pm

Goedenavond,

Ik heb de UART- en USB-tests nog eens opnieuw uitgevoerd. Dat was inmiddels alweer even geleden en inmiddels hebben we ook wat nieuwe informatie gevonden. Daarom leek het me handig om alle huidige bevindingen nog eens overzichtelijk op een rij te zetten.

UART0

Korte druk op de powerknop

Bij een korte druk zie ik:

boot rom try normal boot start!
Start power on debounce. Delay=2000
Start power off

Lange druk op de powerknop

Bij een langere druk start de tracker volledig op. Daarbij zie ik:

boot rom try normal boot start!
Start power on debounce. Delay=2000

(E) Welcome to EiGENCOM D-Fota Time!

 ___      _____ ___ _____  _
| _ \    |  ___/ _ \_   _|/ \
|| \| -- | |_  || || | | / _ \
||_/| -- |  _| ||_|| | |/ ___ \
|___/    |_|   \___/ |_/_/   \_\

(C) Copyright 2020, All Rights Reserved.

(V) Version(2.5), Built @Mar 12 2025 12:09:21

uart(1) urc baud: 115200

total length(40):
[1/1] ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

no par(0xffff) found!

exit...

bootloader flashXIPLimit(0x8099d8), try normal boot system start!

Na deze uitvoer verschijnt er geen verdere tekst meer.

UART1

Korte druk op de powerknop

Bij een korte druk zie ik:

^boot.rom'v'!

Lange druk op de powerknop

Bij een langere druk start de tracker volledig op. Daarbij zie ik:

^boot.rom'v'!
RDY

enter factory test timeout ...

▒▒▒▒ļ▒▒ж▒ȡϵͳ▒▒▒▒,len=1024,1024,1024

get_sys_param:back=0x0,0xa8.main:0x0,0xa8

▒▒▒ļ▒▒ж▒ȡ▒û▒▒▒▒▒,len=1024,1024,1024

get_user_param:back=0x0,0x88.main:0x0,0x88

******************▒ϵ▒▒▒Ϣ******************
--->Ӳ▒▒▒汾▒▒S20 Pro_V1.00
--->▒▒▒▒汾▒▒#S20Pro#ITOJTS20707D260414
--->▒▒▒▒ʱ▒䣺Apr 14 2026_15:07:05
--->RTCʱ▒䣺2000-01-01 00:00:00
--->▒▒汾▒▒BC78_V2.07 250508
******************▒▒▒▒▒******************
--->▒▒▒▒one.gpsog.com
--->IP:0.0.0.0,0
--->▒▒ܼ▒IP:47.52.50.49,1234
--->▒▒־▒▒▒▒▒▒IP:47.52.50.49,4542
--->AGPS DNS:iot.bsjyun.com9885
--->APN:internet4gd.gdsp,,
--->▒▒▒▒▒:[DEVICE_ID_VERWIJDERD]
--->▒▒▒ټ▒▒:0,5
--->▒▒▒▒ֵ:75
--->ȱʡ▒▒ʱ▒▒▒:10
--->▒▒▒߶▒ʱ▒▒▒:300
--->▒▒▒▒:0
--->▒▒λ״̬:<▒▒▒▒▒> 1

read_active_int: 20
read_byte id: 0x13

▒▒▒▒▒▒->>>>>>▒▒▒ä▒▒

Uitvoer enkele seconden na het opstarten

Na enkele seconden verschijnen meerdere berichten in het formaat:

<TXT*S:[DEVICE_ID_VERWIJDERD]*3G:SDK:BC78_V2.07_250508,...

Hierin zie ik onder andere:

*T:0.0.0.0,0,10
*Q:one.gpsog.com:9760
*62:internet4gd.gdsp,,,

Ook zie ik velden zoals *68: en *82: veranderen tussen opeenvolgende berichten.

Persoonlijke gegevens zoals Device ID, IMEI, ICCID en GPS-coördinaten heb ik in bovenstaande voorbeelden verwijderd.

USB

De USB D+ en D− signalen zijn rechtstreeks op de module aangesloten.

Onder Linux wordt de module herkend als:

VID: 19d1
PID: 0001
Manufacturer: EigenComm

Direct daarna verschijnen vier CDC ACM-interfaces:

ttyACM0
ttyACM1
ttyACM2
ttyACM3

Na ongeveer één seconde verdwijnen alle vier de interfaces weer automatisch.

Ik heb dit meerdere keren getest:

USB zonder overige aansluitingen.
USB terwijl UART aangesloten was.
USB met het BOOT-testpad naar GND.
Meerdere keren opnieuw aansluiten.

In alle gevallen bleef het gedrag gelijk:

USB aangesloten
↓
4 × ttyACM interfaces verschijnen
↓
ongeveer 1 seconde later verdwijnen alle interfaces weer

eightdot · August 5, 2026, 7:26pm

ik ben geneigd om in die seconde dat ttyACM0..3 bestaat er een of meerdere te openen, en dan te kijken of ze blijven bestaan, kan ook zijn dat ze in die seconde een commando moeten krijgen om te blijven bestaan..