Debugging

iOS Simulator and Android Emulator HTTP Proxy

Fabio Bombardi

UPDATE 2020

Use Proxyman!

https://proxyman.io/blog/

Proxyman dashboard - HTTP Web debugging on macOS

—

For iOS and Android developers, it’s very important inspecting HTTP/HTTPs traffic in order to have a better understanding of what’s happening during a debugging session.

During these years, setting a proxy for simulators (or emulators) has became more and more easy and today I’m pretty happy to show you how to do on your Mac.

On Windows you could, of course, set a proxy only for Android and I will write a dedicated post and we will use a different proxy program.

But for now we must focus on OS X.

What do we need to do that?

  • BurpSuite (HTTP proxy)
  • Android Studio (for Android developers)
  • XCode (for iOS developers)

Let’s download BurpSuite free edition from its official site: https://portswigger.net/burp/

After you have been installed the program, lunch it and choose “Temporary Project” and for this very first time “Choose Burp Default”.

Go to Proxy and then disable interception, then go to Proxy -> Option and check whether the standard proxy port is okay for your, otherwise change it with the edit button on the left.

I need to listen on port 8888 instead to port 8080 and for Android we need to add another rule for listen specifically to your Mac IP Address.

Your final configuration should look like that (except for the IPv4 192.168.1.2 because your machine should have another one).

Then if you wanna save your settings (except for the interception that must be removed every time you start Burp) you can go to Burp -> Project Options -> Save project options and save your settings so at the next start you can say Burp to load settings from the file you saved

Android

With BurpSuite running, open Android Studio and lunch your Emulator.

Open Emulator settings and use a manual configuration for proxy.

Set host as 192.168.1.2 and port as 8888. Save and close.

Open the Browser and go to 192.168.1.2:8888. We need to install the Proxy CA Certificate in order to listen to SSL traffic.

Click above on the right the CA certificate button and Download it.

If your version of Android lets you install it from the Download folder you can try to open it directly from there. Otherwise the path that works in any case is the following one.

Go to Downloads App and rename cacert.der in cacert.cer and move it on SD Card,

Then go to Settings -> Security -> Install from SD Card choose our certificate.

Then click on it and follow the instruction.

At the end open the Browser and navitgate to https://www.google.it and you can now sniff your HTTP and also HTTPS traffic.

We have left a very final step to do, and It’s to enable proxy also to our Data Connection on the Emulator. This because we wanna sniff traffic of our Apps and not only of the Browser.

And finally if you have a web call on your Application you can easily inspect it.

Pay attention to the Filter section (the red arrow highlights it) in which by default Burp filter CSS, images, etc. If you want to see also this HTTP calls you must enable it by clicking on the filter section and check the right choices.

I hope this could help you, as an Android Developer, debugging all your Rest API.

UPDATE: As of targeting SDK API 24 or higher you must follow this configuration for your Android APK in order to be able to sniff SSL Traffic: trusting debug CA.

NOTE: on Windows the procedure is exactly the same if you use always Burp Suite. But on Windows environment I prefer to use Fiddler from Telerik (http://www.telerik.com/fiddler). You have to do a litte change in Fiddler regarding the CA Certificate, I hope to write a post soon.

iOS

iOS Simulator has not a specific settings section for Proxy. It uses the System Proxy, so that we have to set the proxy directly on the Advanced Settings of our current network interface.

Go to System Preferences -> Network and choose your current interface, click Advanced and go to Proxy tab to set Proxy settings. In this case, differently from Android, you could use the localhost address.

Set the same configuration either for HTTP and for HTTPS. Ok and Save.

Now let’s try:

It works! The only drawback is that having set a global system proxy, we proxy all the traffic of our Mac, not only the one of the simulator like for Android.

Note: If you test, like me, an image HTTP Request, check the Filter section of BurpSuite and opt-in for images too because, by default, images are filter out. The Filter section is just below “HTTP history” tab. You have only to click on it to expand its configurations.

Also in our iOS simulator in order to be able to sniff HTTPS traffic we need to install BurpSuite CA Certificate.

Similarly as we have done for the Android emulator we must open the browser and navitagate to http://127.0.0.1:8888 and install the certificate.

Here the process it’s simpler but on iOS 11 we need to do one more thing. Enable the Full Trust from the About Settings menu.

And it works!

So we have finished our setup. We can now start coding happier!

NOTE: of course you can set a proxy also on a real device. If you do that (the proxy settings are on the netwok configuration of the device you use) remember that the device and the PC where is the proxy must belong to the same Network and they must be reachable from each other.
Moreover if you wanna sniff the SSL traffic you must install the CA Certificate of the proxy but that exposes your device to the MITM Attack (it’s that what we do here, we act like a Man In The Middle) if you use it in your real life. So… remember to remove the certificate once done.

iOS Simulator and Android Emulator HTTP Proxy

Visual Leak Detector per Visual C++

Fabio Bombardi

Ho utilizzato questo prezioso strumento per diversi progetto durante la mia carriera e mi sono accorto di non aver mai scritto un articolo al riguardi! Gravissimo! 🙂

La pagina del progetto è questa: https://vld.codeplex.com/

Con vld è possibile riconoscere se nel nostro codice nativo (C/C++) abbiamo dei memory leak direttamente dopo un solo ciclo di utilizzo del nostro programma dalla console di Output di Visual Studio.

Sul sito del progetto la documentazione è chiara. Vi mostrerò qui ora un semplice esempio.

Per prima cosa scarichiamo l’eseguibile da https://vld.codeplex.com/ e installiamolo sul PC sul quale abbiamo il nostro Visual Studio (nel mio caso la versione 2015).

A questo punto creo un progetto Win32 Console Application con il seguente main.cpp

Se scrivete il codice prima di impostare i path per gli include di vld, la riga 10 vi darà errore. Non preoccupatevi, la sistemiamo subito.

Come vedete il nostro bel programmino è fatto apposta per sprecare memoria all’infinito. La alloca e non la rilascia mai… che bravo! 😀

La documentazione ufficiale è ben fatta e la trovate qui.

Uma volta lanciato il setup.exe di VLD quello che dovete fare è andare ad impostare sul progetto in cui lo volete utilizzare per la build di Debug che vi interessa (x86, x64 o entrambe) i path delle librerie e dei file di include di VLD.

A questo punto compiliamo in Debug e lanciamo il nostro codice. La riga 10 non darà più errore e in console vediamo l’avvenuto corretto caricamento del nostro Leak Detector prendendo i suoi parametri di configurazione dal vld.ini nella directory di installazioine del VLD.

Al termine del programma ecco quali utili informazioni vld ci offre nella cosole di output di Visual Studio!

E questo è tutto, gente!

Visual Leak Detector per Visual C++

Debug Diagnostic Tool

Fabio Bombardi

Oggi vedremo un caso di utilizzo del Debug Diagnostic Tool che è uno strumento molto utile per fare del debugging e del profiling sia in ambiente di Sviluppo ma sopratutto in ambiente di Produzione.

Il caso in particolare è andare ad analizzare una applicaizone ASP che in produzione, sotto stress quindi, ogni tanto manda il processore del server al 100%.

Come primo workaround si è subito messo in linea uno script di Power Shell che andasse a verificare lo stato del processore e nel caso fosse rimasto al 95% per più di 20sec, andasse a fare un IIS Reset.

Poi subito dopo seguendo questo articolo su Debuggin IIS High CPU siamo andati a impostare:

  1. Data Collection con il Performance Monitor
    In particolar modo:

    • Richieste Correnti Totali (ASP .NET)
    • Richieste in Coda (ASP .NET)
  2. Creazione di un Dump tramite Debug Diagnostic Tool 2 Collection
    In particolare:

    • Se il processore rimaneva al 90% per più di 5 secondi

E siamo rimasti ad aspettare che nuovamente succedesse lo scenario incriminato.

Abbiamo lasciato in piedi la cosa per tutta la notte: il data collection continua finchè non lo si stoppa, mentre il dump è one-time (una volta scattato, va riattivato manualmente il trigger, altrimenti si ferma).

Nella notte abbiamo avuto ben 4 casi di processore al 100% e durante il primo caso si è generato il Dump e durante tutti i casi abbiamo collezionato i dati dei contatori per le Richieste Correnti e per le richieste in Coda.

Ecco come abbiamo poi analizzato la cosa.

Per quanto riguarda i dati collezionati dal Performance Monitor si è visto che le richieste correnti schizzavano in occorrenza dell’evento incriminato:

Andando ad analizzare anche le richieste in coda:

si evince che aumentano proporzionalmente alle richieste attive.

Questo ci fa sospettare che sia effettivamente un problema di performance e non un problema di “attacco” in quanto le richieste in coda ci sono solamente durante gli eventi incriminati e quindi IIS non riesce ad evadere le richieste perchè è impegnato nell’operazione che porta il processore al 100% e questo scenario è coerente con il fatto che facendo IIS Reset la situazione ritorno normale.

Andiamo quindi ora ad analizzare il dump con il Debug Diagnosti Tool 2 Analysis.

Vediamo subito che l’analisi del Dump conferma High CPU Usage.

Andando a vedere quindi i Topo 8 Thread scopriamo da dove parte il tutto:

Dalla pagina “RivestimentiDettagli” ed è scatenata dal metodo “.get_data()” (Tutto Codice Utente).

Andando quindi ad analizzare il codice si è scoperto che si era fatto un uso improprio di variabili statiche e quindi c’erano problemi di concorrenza che si vedevano solo in presenza di forte carico del server.

 

 

 

Debug Diagnostic Tool

Debugging .NET application con WinDbg

Fabio Bombardi

E’ possibile creare un file minidump anche per applicazioni .NET nello stesso modo descritto nell’articolo per le applicaizoni native:

http://www.versionestabile.it/blog/dubugging-with-windbg/

Per le applicazioni .NET è più difficile avere la riga di codice esatta, soprattutto se non si è tenuto il file .pdb della versione che ha fatto il “crash” a casa del cliente e non vengono caricati correttamente anche i symboli delle classi .NET relative al Framework con cui è stato compilato il programma in question.

Per prima cosa lanciare il caricamento del framework

.loadby sos clr

Comunque anche se si dispone solo del file .dump (vedere come generarlo nell’articolo citato sopra) se lo si apre con WinDBG e si analizzano al suo interno le eccezioni con il comando

!analyze -v

Si può vedere lo stack trace che ci porta al punto di programma incriminato.

Vediamo un esempio.

Il programma C# del nostro esempio è il seguente:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace WinDbgCrashTest
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();
            badMethod();
        }

        private void badMethod() {
            Object o = null;
            String s = o.ToString();
        }
    }
}

Se lo si lancia andrà in Crash immediato.

Apriamo il suo minidump con WinDBG e lanciamo !analyze -v

Lancirare WinDbg come amministratore in modo che possa scaricare (dal sito di Microsoft) nelle cartelle di sistema i simboli che eventualmente non trova in locale.

Ecco il risultato:

windbg_net_crash1
Anche se non è riuscito a caricare i simboli

crash_net_windbg_0
ci dice che alla riga 2 del metodo badMethod all’interno della classe Form1 si è verificata l’eccezione!

Se diamo a WinDBG il path del .pdb e dei sorgenti che fanno riferimento a quell’eseguibile con il comando

!clrstack

Abbiamo anche più info: il file e la riga dove è avvenuta l’eccezione.
crash_net_windbg

Debugging .NET application con WinDbg

Debugging native applications with WinDBG

Fabio Bombardi

Configurare windows perchè tramite (WER – Windows Error Reporting) crei un user-mode minidump quando un’applicazione va in crash:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx

“Starting with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1), Windows Error Reporting (WER) can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crashes. Applications that do their own custom crash reporting, including .NET applications, are not supported by this feature (for those see http://www.codeproject.com/Articles/1934/Post-Mortem-Debugging-Your-Application-with-Minidu).

This feature is not enabled by default. Enabling the feature requires administrator privileges. To enable and configure the feature, use the following registry values under the

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

key.

Value Description Type Default value
DumpFolder The path where the dump files are to be stored. If you do not use the default path, then make sure that the folder contains ACLs that allow the crashing process to write data to the folder.For service crashes, the dump is written to service specific profile folders depending on the service account used.For example, the profile folder for System services is %WINDIR%\System32\Config\SystemProfile.
For Network and Local Services, the folder is %WINDIR%\ServiceProfiles.		 REG_EXPAND_SZ %LOCALAPPDATA%\CrashDumps
DumpCount The maximum number of dump files in the folder. When the maximum value is exceeded, the oldest dump file in the folder will be replaced with the new dump file. REG_DWORD 10
DumpType Specify one of the following dump types:

  • 0: Custom dump
  • 1: Mini dump
  • 2: Full dump
 REG_DWORD 1
CustomDumpFlags The custom dump options to be used. This value is used only when DumpType is set to 0.The options are a bitwise combination of the MINIDUMP_TYPE enumeration values. REG_DWORD MiniDumpWithDataSegs | MiniDumpWithUnloadedModules | MiniDumpWithProcessThreadData.

These registry values represent the global settings.

You can also provide per-application settings that override the global settings.

To create a per-application setting, create a new key for your application under

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps 
(for example,HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApplication.exe).

Add your dump settings under the MyApplication.exe key.

If your application crashes, WER will first read the global settings, and then will override any of the settings with your application-specific settings.

After an application crashes and prior to its termination, the system will check the registry settings to determine whether a local dump is to be collected.

After the dump collection has completed, the application will be allowed to terminate normally.

If the application supports recovery, the local dump is collected before the recovery callback is called.

These dumps are configured and controlled independently of the rest of the WER infrastructure.

You can make use of the local dump collection even if WER is disabled or if the user cancels WER reporting.

The local dump can be different than the dump sent to Microsoft.”

Testiamo quindi il tutto:

Creiamo un’applicazione nativa che vada in crash e chiamiamola WinDbgMinidumpTestCrash.exe (ecco il codice che utilizzerò per questo esempio)

#include <iostream>

using namespace std;

void main() {
	cout << "Hello, World!\n";
	cout << "Type a key\n";

	char c = 'a';
	cin >> c;

	// Crash!
	char *p;
	p[1] = 'b';
}

Abilitiamo quindi la generazione dei minidump per questa applicazione:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\WinDbgMinidumpTestCrash.exe]
"DumpType"=dword:00000001
"DumpFolder"=hex(2):43,00,3a,00,5c,00,74,00,65,00,6d,00,70,00,00,00

La cartella DumpFolder è “C:\temp”, il tipo di Dump è 1 (minidump).

Lanciamo quindi l’applicazione che andrà in crash e genererà a questo punto il suo minidump all’interno di C:\temp
windbg_crash1

windbg_crash2
A questo punto dobbiamo andare a lanciare WinDBG e caricare il file di dump appena creato:

Solo caricando il file… ci ammonisce che abbiamo un’eccezione…
windbg_crash3

Configuriamo la cartella dove mettere i simboli delle classi di Microsoft

*** configure symbols to be downloaded from Microsoft
.symfix c:\symbols

Ricarichiamo il tutto (lasciamo il tempo al download dei simboli)

*** Reload anything which has been loaded so far
.reload

windbg_crash4
Poi andiamo ad eseguire il comando che WinDbg ci diceva di lanciare per accedere alle informazioni sulla nostra eccezione

.excr

E boom! Ecco la riga incriminata! 😀
windbg_crash5
Se andiamo a lanciare anche il comando

!analyze -v

Ecco che WinDBG ci mostra esattamente il punto anche nella finestra di comando:

windbg_crash_analyze_v

 

Nel caso in cui il progetto con cui è stato compilato l’eseguibile non si trovi più nello stesso percorso (il modulo da errore di caricamento symboli):

crash_windbg7
occrre andare a dire a WinDBG dove trovare il .pdb e i sorgenti con gli appositi menu:
crash_windbg8
E richiamare nuovamente .ecxr

crash_windbg9

Ed ecco riapparire il nostro codice incriminato!

Ecco perchè a volte è bene tenere sotto versioning anche i file compilati e i file con i simboli di debug 😉
crash_windbg10

 

Debugging native applications with WinDBG