Drexel's VidUp - Ein templatebasierter Youtube Uploader

Er findet eine Playlist nicht, die in einem Upload hinterlegt ist, das sollte eigentlich nicht passieren. Hast Du irgendwas mit Playlists gemacht, eine gelöscht oder so? Die sollte dann zwar aus Uploads und Templates rausgenommen werden, aber Bugs will ich nicht ausschließen. Wenn Du mir Deinen VidUp Ordner zukommen lässt, kann ich mir anschauen, welche Playlist das ist und es Dir fixen.

Hab Dir was zurück geschickt.

Das Problem war etwas anders gelagert als gedacht:

1. fehlte die die accountlist.json komplett, da sind natürlich Deine Account- und Authentifizierungsinformationen drin, jeder Upload, jedes Template, jede Playlist ist mit einem Account verknüpft, wenn der nicht da ist, fällt VidUp natürlich auf die Nase. Zuerst werden die Playlists wieder geladen, deswegen ist er im Playlist Kontext auf die Nase gefallen, aber nicht weil eine Playlist fehlte wie ich erst dachte, sondern weil der Account der ersten Playlist schon nicht gefunden werden konnte...

2. Nachdem ich das gefixt habe, fehlte aber trotzdem eine Playlist, die habe ich hinzugefügt, mit dem Title "Gefixte Playlist von Drexel". Anhand der Playlist ID müsstest Du die auf YouTube zuordnen können und kannst die auch wieder umbenennen.

Du musst Dich jetzt einmal neu authentifizieren, über Settings->YouTube Account-> Kebap Menü->Sign in with Google.

Irgendeine Idee wie das passiert sein könnte?

Btw hab ich noch ein wenig über Deine Visualisierung des Uplaod Plans nachgedacht, ich denke ich werde das in einer neuen Version umsetzen, nur wird eine neue Version nicht allzu bald sein.

Achso, ja ist prinzipiell richtig, da stehen wie gesagt Deine Authentifizierungsinformationen drin. Wenn man man aber nochmal auf Sign In drückt werden die auch neu generiert, von daher wenn man das macht, nachdem die Datei einmal "öffentlich" übers Netz gegangen sind ist wieder alles safe. Den expliziten Sign In Button gabs ja vor ein paar Versionen noch nicht, da musste man die alte refreshtoken Datei, die es jetzt auch nicht mehr gibt löschen, um sich neu zu authentifizieren, das ist ja jetzt so ein bißchen schöner mit Sign In und Sign Out.

Zur Authentifizierung mit OAuth muss kurz ein lokaler Webserver gestartet werden über den die Authentifizierung vorgenommen wird, frag mich nicht wieso, hab mich nie mit der Technik dahinter nie beschäftigt. Den Code dafür hatte ich von einem Google Beispiel übernommen... Deswegen die 127.0.0.1, das ist ja immer die lokale Adresse. Evtl. blockt da eine Firewall was und/oder Du musst VidUp mal mit Adminrechten starten, ich hatte da noch nie Probleme mit, benutze aber in Sachen Security auch nix als Windows Bordmittel aka Windows Defender. Aber es muss ja schonmal funktioniert haben bei Dir.

Wenn Du Deine alte accountlist behalten hast, ist es normal, dass Du weiter uploaden kannst, wenn Du meine leere übernommen hast, ist das schon strange...

Also beläuft sich der Fehler doch nur darauf, dass die eine Playlist nicht gespeichert wurde, ist bei mir noch nie passiert, aber ich schau mir das mal an, ob ich irgendwo was verdächtiges dazu finde...

Neue Version 1.13.1:

https://1drv.ms/u/s!AlNGd4g1Vh9rmHAvaCyZ5nvtOkDF?e=5vhucP

Hat sich eigentlich nix geändert, nur neue API Credentials, da wieder ein Spammer am Werk war.

Hab mir heute angeschaut, wie ich das Binary besser schützen kann, aber alle Versuche sind im Sande verlaufen. Die freien Tools um ein Binary zu verschleiern, funktionieren nicht, oder haben nicht alle Funktionen die ich brauche (obfuscaten und Strings verschlüsseln) und um in was kostenpflichtiges zu investieren, wirft VidUp nicht genug ab.

ConfuserEx kann eigentlich alles, läuft aber leider noch nicht mit .Net5 oder 6, letztes Jahr im Oktober sollte eigentlich ein erster Release erscheinen der das kann, aber seitdem hat man nichts davon gehört, der Entwickler ist aber noch aktiv...

Der aktuelle Spammer ist hartnäckig, deswegen gibt es wieder eine neue Version mit neue API Credentials:

https://1drv.ms/u/s!AlNGd4g1Vh9rmHAvaCyZ5nvtOkDF?e=5vhucP

Hab jetzt versucht die Credentials besser zu schützen mit Obfuscation, dabei gelernt, dass das auch einige Fallstricke mit sich bringt...

Sollte was nicht mehr funktionieren, lasst es mich wissen.

Schau ich mir an, kann nur 1-2 Tage evtl dauern da ich gerade mit Corona flach liege und sich mit Kopfschmerzen durch Code zu wühlen ist kein Spaß....

TbMzockt Ja neben Obfuscation habe ich auch dafür gesorgt, dass die Logindaten nicht mehr im Klartext zu finden sind... Aber Obfuscation mit GUI Binding und Serialisierung ist echt kacke, da muss man echt aufpassen, dass man sich nicht Sachen zerschießt...

So hab gerade doch mal geschaut, bei mir gehts einwandfrei.

Sicher, dass Du die 1.13.2 nutzt?

Und unter Settings hast Du YOUTUBE API CRDENTIALS 'Enable Custom Credentials' deaktiviert?

Die Spammer gehen mir echt auf den Sack. Scheint alles nix gebracht haben. Ich überlege, ob ich es komplett öffentlich nur ohne Api Zugang veröffentlichen soll und mit Api Zugang nur auf Anfrage/an bekannte Leute...

Oder Google einfach weiter mit Quota Requests nerven soll, bis sie mal ihr Api Zugangs System überdenken...

Zitat von strohi

Oof, das ist blöd...

Mal ganz blöd gefragt: Kannst du absolut sicher sagen, dass jemand die Credentials misbraucht?

Danke für Deine Hinweise Strohi, ich habe das gedanklich auch alles schon durchgespielt

Ja ich bin sicher, dass abuset wird, ich sehe in der Google Cloud Console folgende Requests in den letzten 24 Stunden:

VideoRatingService.Insert, also Bewertungen abgeben, ist definitiv nichts was mein Tool tut. Manchmal sind auch Subscriptions dabei.

Zitat von strohi

Was, wenn irgendjemand das Tool nutzt, um wie gestört Videos hochzuladen? Kannst du das sicher ausschließen, z. B. indem du in die nächste Version ein Rate-Limiting von 20 Videos pro Tag pro Benutzer einbaust?

Das würde dann erklären, wieso die ganzen Verschleierungsmaßnahmen nicht helfen..

Ja es könnte jemand wie gestört Videos hochladen, kenn da auch mind. einen Nutzer der das genutzt hat um ziemlich viele Shorts zu spammen. Ist zwar auch nicht doll, aber im Rahmen der Nutzungsmöglichkeiten, müsste ich akzeptieren. Habe schon probiert, das über die Google Cloud Conole zu limitieren, da kann man ein tolles Setting einstellen, Quota pro User pro Minute, das muss ich auf 1600 stellen, damit überhaupt ein Upload funktioniert, wären immer noch 1440 Uploads pro Tag pro user und noch mehr sonstige Requests... Quota pro Tag wäre einfach zu viel verlangt...

Ich könnte ein User Limit einbauen, dass irgendwo lokal gespeichert wird, im Zweifel löscht man das und es geht wieder von vorn los.

Zitat von strohi

Andere Frage:

Könnte es sein, dass der Angreifer sich erst später als Man in the Middle einhängt und den Webtraffic deines Programms via Fiddler oder ähnlicher Tools abgreift und so an die Credentials kommt?

Weiß nicht, ob es geht, aber auch das könnte erklären, wieso er trotz allem leichtes Spiel hat.. Weil wenn er sich in die Requests reinhängt, hilft keinerlei Obfuscation im Code...

Klar, die Obfuscation war auch nur ein Test, wie schlau der Hijacker wirklich ist, ob er nur den ILSpy anwerfen kann oder ob er noch weitreichendere Kenntnisse hat. Hat er offensichtlich.

Zitat von strohi

Wenn es letzteres ist, stellt sich mir die Frage, ob es überhaupt irgendwie möglich sein könnte, das Abfangen zu verhindern.

Eigentlich nur eine Serverlösung, bei der User ihre Videos hochladen und du die vom Server aus an Youtube schickst. Darüber könntest du Rate-Limiting einbinden, hättest dann aber ne Shitload an DSGVO und hohe Serverkosten an Bord...

Ja keine Alternative. =)

Aber ganz ehrlich: Was soll die Doppelauthentifizierung? Alle Requests sind OAuth Authentifiziert, sie wissen wer da was macht, sollen sie doch diese Accounts einfach sperren. Und die Quota Limiterung an den Account hängen. Da könnten sie doch einfach sagen, jeder Account darf max 20 Videos am Tag hochladen und gut ist.

Wenn ich ungehindert spammen will muss ich auch nicht über die API gehen sondern bau mir einen Robot/BrowserPlugin/whatever der über den Browser geht...

Man kann lokale Apps einfach nicht absichern, das weiss selbst Google, es steht ja in ihren FAQs. Was soll das dann überhaupt?

So ich hab mich ein wenig auf stackoverflow mit jemandem ausgetauscht und auch nochmal selbst ein wenig nachgedacht und analyisiert wie man die API Crdentials besser schützen kann. Idee war die Authentifizierung auf einem (Web-)Server vorzunehmen und die Authentifizierungsinformation für weitere Requests, also das refreshToken an die App weiter zu geben, erstmal per manuellem Copy&Paste, später evtl. auch automatisch.

In der Analyse habe ich aber festgestellt, dass das auch nicht so wirklich geht, zumindest ist der Aufwand deutlich höher, als in der ersten Idee gedacht.

Die API Credentials werden bei der initialen Authentifizierung genutzt, darüber erhält man das refreshToken. Mit dem refreshToken kann man accessTokens abrufen, die die eigentlichen Requests authentifizieren. Aber auch die Erzeugung der accessTokens benötigt die API Credentials, das hatte ich nicht mehr auf dem Schirm. Ich habs zwar hinbekommen, mir das refreshToken über ein PHP Skript auf einem Webserver zu erzeugen und in der App weiter zu nutzen. Aber um die API Credentials sicher nur auf dem Server zu halten, müsste die App halt auch jedes accessToken vom Server abfragen... Und die AccessTokens ändern sich jede Stunde. Das macht es dann doch deutlich komplizierter, man müsste sich auch das refreshToken oder den YouTube Account oder irgendwas um den Connect zur App hinzubekommen auf dem Server merken oder ein Account System nutzen, mit dem man sich auf der Webseite und in der App anmeldet und die Kommunikation sicher gestalten.... Das ist alles kacke und aufwendig...

Nein keine Begrenzung und kann bei mir auch nix derartiges feststellen... Was heißt langsamer konkret?